|
Contiki
Feb 23, 2015 17:23:03 GMT
via mobile
Post by gsteemso on Feb 23, 2015 17:23:03 GMT
For Ethernet on my Commodores I use a Flyer. It works equally well with everything from a PET through to C128 and Plus/4. (It would probably even work with the B-series and C65, though I have not personally heard of anyone trying that.) Last week I downloaded a copy of the Contiki sources. I hope to find time to make Contiki work with the Flyer at some point. It would free up a LOT of memory.
|
|
|
Post by gsteemso on Feb 23, 2015 1:01:57 GMT
Your talk of somehow adapting to the signal had me scratching my head. I didn’t think it was physically possible until I stepped through the logic, and even if you did acquire the user’s help to calibrate your software, it would NOT be straightforward. To show exactly why (and what you would have to overcome), let us step through the exact timeline of events. The following is equally applicable to VIC-IIe (no matter whether PAL, NTSC, SECAM, they’re all pretty similar if you ignore the colour encoding) and to VDC output, as the main difference between them from a timing perspective is that the VDC crams a faster-changing signal (more pixels) onto each scanline.
(1) The C128 begins to draw the first field of the frame. Standard video signals, which is what the C128 produces on both monitor outputs, always come in two fields, each consisting of every second scanline from the complete frame. Whether the even lines or the odd lines are drawn first depends on the video standard, and doesn’t really matter for our purposes here. (Unless you’ve gone to some effort to set up an interlaced display, both fields are exactly the same anyway.) The C128 begins the frame with vertical synchronization pulses prior to the start of the visible signal, which the VGA converter catches, causing it to begin buffering a new frame. It’s most likely going to still be painting the second-to-last previously buffered frame for a random amount of time, varying between roughly zero to 1/30 of a second (0–2 “ticks” in Commodore jargon, or “thirds” to more traditional horology).
(2) As the first field is partly painted, let’s call it about 3/4 done, the user (who started pressing the light pen trigger a few frames ago) finally closes the trigger switch enough to connect the sensor in the pen to the trigger input on the video chip. However, the electron beam is being directed by the VGA converter, which at this point is finally drawing the first part of the last previously buffered frame.
(3) The C128 finishes drawing the first field, puts out some more vertical sync pulses, and starts to paint the second field. The VGA converter is now filling in the missing every second line in its idea of what the current frame looks like, and since that’ll be going on for a bit yet, is probably getting ready to paint the last buffered frame for a second time. (Or, possibly, a third time. Depending on the refresh rate your VGA monitor has negotiated with the converter [generally somewhere between 54 and 85 Hz], some frames will most likely be repainted once more often than others, as the converter waits for the current frame to finish coming in at its TV-derived speed of around 25–30 Hz.) The actual currently-displayed frame could be at any stage of having been painted at this point, but going by how I have described this example so far, it’s probably about 60% of the way through painting the previously-buffered frame image.
(4) The electron beam in your monitor sweeps past the sensor in the light pen, which sends a pulse down the wire and, eventually, into the video chip, which latches the current scanline value into an output register for when your program comes looking. Light pens are not precision instruments, so this pulse is actually several pulses in close proximity, which the video chip has to adjust for. (The whole process takes a small but, to the computer, noticeable amount of time, meaning that even when you have a monitor connected directly to the C128, the value that gets latched isn’t quite the one where the electron beam actually was, so some software calibration is always needed with a light pen, no matter what.) Since the electron beam is not, in fact, controlled by the video chip like it expects, it will register a value near the top of the screen even though in this example the VGA converter is painting nearer the bottom.
(5) The VGA converter starts repainting the screen again, still using the last previously-buffered frame. The C128 has nearly finished filling in the current frame.
(6) The electron beam sweeps past the light pen again, causing another chain of trigger pulses and, eventually, a new raster number to be latched in the video controller. The user hasn’t moved the pen appreciably in the fraction of a second since the last pulse-train came in, but since the actual position of the VGA-converter-controlled electron beam at any given moment can’t be predicted at all from the video chip’s notion of what the current scanline is, your program has no way of knowing that. The scanline number recorded by the video chip is near the bottom of the screen.
**IMPORTANT**: Since the light pen trigger pulse-trains are coming in roughly 0.9–1.7 times as often as the C128 is expecting them (and the pulses are both a bit shorter and twice as numerous as anticipated), there is no guarantee that any specific video chip will be able to keep up. You’d have to try it and see.
At this point, you had better hope your program has been keeping a close eye on a CIA timer through all of this. Assuming the user really is holding the pen still, and you set up an interrupt routine to record (time, raster number) pairs with the least delay possible whenever the light pen trigger goes off, you now know the time between VGA repaints and thus the VGA refresh rate. That in turn will let you calculate the ratio of VGA frames to C128-native ones, which will (provided you’re still keeping a very close eye indeed on the CIA timer) allow you to fudge the recorded raster positions to approximate a correct value. Since this involves a large amount of multiplying and dividing and incredibly precise timing, I think the only way to get acceptable speed out of it is to use a bunch of lookup tables. You would likely have to calculate them from scratch every time you run through the “calibrate light pen” routine, too.
|
|
|
Post by gsteemso on Feb 12, 2015 3:26:50 GMT
Of course it’s not bloody possible to make it work anyway! The ratio of C128 screen repaints to VGA screen repaints is not only not exact, it also varies enormously depending on the VGA signal parameters (resolution and refresh rate). On top of that, the light pen pulses are coming in at least twice as fast as the 128 expects them to, and in no apparent relation from one pulse to the next. I’d honestly be shocked if the VIC-IIe even registered a value for it, because there’s no consistency to it at all.
|
|
|
Post by gsteemso on Feb 10, 2015 18:52:27 GMT
Running the signal through a VGA converter loses the original timing information needed to synchronize the light sensor with the computer’s notion of where the CRT is currently painting. The VGA signal draws the whole screen roughly twice in the time the C128 draws it once, so the C128 is going to get pulses from what it thinks is several places on the screen until your finger comes off the trigger a few screen repaints later.
|
|
|
Post by gsteemso on Jan 29, 2015 14:56:52 GMT
P64 and D67 images are explained in the VICE manual (http://vice-emu.sourceforge.net/vice_2.html#SEC15). P64 files are representations of the raw flux transitions on the physical disk, and a D67 is basically a D64 with a few more sectors; the buggy and unreliable CBM DOS 1.0 format had one more sector on each of certain tracks than the improved DOS 2.0 version found in the 1541 etc. Why they named it D6_7_ is completely mysterious though.
|
|
|
Post by gsteemso on Jan 29, 2015 1:59:29 GMT
There's a control bit in the MMU somewhere that dictates which CPU is active. There is no possible way to execute code without already knowing, though, so I have no idea what you might use it for.
|
|
|
Post by gsteemso on Jan 29, 2015 1:35:33 GMT
Well, I’m interested IN THEORY, but I really can’t justify paying much more than the old $25 price. (Our car has had its deferred maintenance come home to roost, you see.) How many boards would you need to have made to allow that price?
|
|
|
Contiki
Jan 26, 2015 15:40:04 GMT
via mobile
Post by gsteemso on Jan 26, 2015 15:40:04 GMT
I’m slightly embarrassed that I missed this system before. I’d like to experiment with this OS on my C128, but can’t find anything resembling a disk image or the like on the official Contiki website. Does anyone know how to install it and/or customize it?
|
|
|
Post by gsteemso on Jan 11, 2015 9:12:08 GMT
2nd annual going out of business sale. …Wow. OK. You really saw that somewhere?
|
|
|
Post by gsteemso on Jan 10, 2015 1:27:22 GMT
Virtual Reality Experience. How is that an oxymoron? It says straight up that it is a fake with some of the attributes of reality, so that part is fine, and it logically has to be experienced to be evaluated. Colour me confused!
|
|