Oh-kay, after that little excursion into the twilight zone last week, I've been doing some other stuff to try and catch-up with my target list of objectives for a demo release. The next item was to drop the correct values into the VIA and VIC setup tables for NTSC hardware - I've had some placeholder values in there all this time, with a comment next to them saying 'FIX ME', so I thought it was time to spend 30 minutes or so calculating the right numbers. These values are hardcoded and assembled into the ROM image based on a simple conditional flag which DASM uses to switch between either PAL or NTSC settings at build time, and are used to configure the VIA #2 Timer for raster synchronisation with IRQ, and the VIC for the screen layout (both of which change noticeably because the NTSC hardware runs at 60Hz but PAL runs at 50Hz).
So I did some quick calculations and derived the appropriate values for the raster sync start/stop points, tweaked the VIC defaults until things looked right, and fired-up XVIC in NTSC mode. And it all just worked - which is what I expected, but after the last few days it's quite a relief to have something do what it's supposed to! Although there isn't a lot yet that depends on which video mode (and thus timing frequency) the system is running in, what there is has been written to use whichever constants have been built into the ROM and adjust things appropriately - so for example the little routine that synchronises the IRQ and raster counter (which lets us generate that 25th usable line at the bottom of the screen) is aware of whether it should happen on scanline 262 or 224, for PAL or NTSC displays; equally, the counters which handle the time-of-day clock know whether a jiffy is a 50th or a 60th of a second based on that video setting, and therefore correctly count the right number of jiffys before deciding a second has passed. The same code executes in both cases, but the video mode constants determine what difference PAL or NTSC setup makes.
I did also go back to the glyph renderer briefly, as I decided that I'd accept a minor speed penalty in exchange for putting the attribute table back into that spare Colour RAM slot. Having (finally) got the draw speed over 2,000 cycles per row faster than before, I traded some of that gain for 1000 bytes of memory freed-up and made available to the rest of the system. The memory counter now shows '34840 Bytes Free' at startup, which is frankly awesome - my original designs a year ago estimated maybe 30K might be accessible for user-mode programs, so to get to 34K is something I'm very pleased with.
The renderer now runs at between 7,331 cycles (no attributes set) and 7,691 cycles (inverse and underline on the whole line) per row, which at its' fastest equates to about 5.7 cycles per pixel - a rate significantly in excess of what I anticipated when I wrote the first version of this routine. It means I can now do up to three passes per frame on a PAL machine (a PAL frame corresponds to 22,150 cycles) allowing the entire text display to be fully refreshed in 9 frames - or about a 5th of a second. That's a dramatic improvement on the previous refresh rate, and it also means I can do a faster refresh on NTSC too - two passes per 16,963-cycle frame instead of just one, dropping the time for a full refresh to a quarter of a second instead of a half.
On an unrelated note, something I spotted when doing a tracing session in the XVIC monitor was that it disassembled my shiny new ZAX opcode (LAX Immediate #$00, you may recall) in a funny way. I kind of thought it would call it LAX, but after all my careful consideration regarding the name of this special instruction variant, the emulator calls it LXA! Somewhat deflated that I'm not the first to name this opcode after all, I'm nevertheless sticking to my choice of ZAX (for Zero A and X) since it seems more logical to me than simply re-arranging the letters of the original mnemonic. Hey ho, win some lose some. ;)
I've also taken half-an-hour to re-organise the sourcecode and rationalise the cosmetic style; formatting makes absolutely no difference to the assembled binary, of course, but it does make the process of working on it both easier and more pleasant, especially when there's a consistent template applied across the whole thing. I spent 10 minutes figuring-out how Notepad++ manages code-folding too, so I can now collapse stuff I'm not actively working on to tuck it out of sight. Overall, the working environment is much nicer and I spend less time looking for stuff and more actually being productive.
Next up is the task of integrating the cursor blink timer into the time-of-day clock counter, in preparation for re-introducing the cursor logic in a more elegant way. Since both the cursor and the clock require an IRQ-driven countdown, there's an opportunity to combine the two into a single routine. Essentially the clock counter will expand slightly to count half-second intervals and flip the cursor-visibility flag, and the separate cursor-blink timer will disappear. It should be a fairly quick tweak to make, and simplify things in the process.
TTFN.
No comments:
Post a Comment