In Which We Tweak And Twiddle

I dusted-down the source code and build files for the project yesterday, and updated the version of XVIC in the Tools subfolder to the latest 2.4 release - as it happens, I hadn't got around to playing with the new VIC-20 emulation in the new package yet, and was a little surprised when I fired it up to see a new video rendering technology which yields an interesting 'scanline' effect at double-size mode. This is actually rather cool, because it now more accurately resembles what the real hardware looked like on an 80's-vintage TV - however, I found it a little distracting after a while and had to have a hunt around for the appropriate command-line parameter to turn it off when the build script launches the emulator.

With that taken care of, I then started tweaking the first candidate items I thought could move out of Zero Page, namely the four bytes used by the Countdown Clock. This, you may recall, is a reversed timer which is updated every jiffy (the exact frequency of which is determined by the video clock setting for either PAL or NTSC, and which we have the IRQ synched to) and keeps track of elapsed uptime - there is a prototyped pair of routines which convert between the countdown clock and 'normal' 24-hour mode, although they're not plugged-in to the build yet as we're still some way off needing to be able to read/set the clock.

The countdown value bytes are updated by a little routine called from the IRQ handler which decrements each byte in turn, tripping the next byte along when each reaches zero. Those four bytes have now moved to Page 3, incurring a small time and space penalty, but a barely-noticeable one - the routine is 8 bytes longer due to Absolute addressing instead of ZP, and is anywhere from 1 to 8 cycles slower, depending on how many of the four bytes 'tick over' to zero during the update. But as ever, we almost always trade time for space (or vice-versa) when writing 6502 code, and in this case the releasing of four bytes in Zero Page is worth the modest price.

Next, I moved the 3 BCD conversion bytes out of ZP and into Page 3. They're infrequently used, essentially only by the routine that converts 8- and 16-bit binary values into Binary Coded Decimal and by the corresponding bit of code that converts BCD into ASCII characters for display. These routines are currently only called by the logic that displays a memory count on the screen when the OS starts, and although they're quite quick, the conversion process is nevertheless comparatively expensive - around 150 cycles for an 8-bit value, and about 600 for a 16-bit value.

As it happens, I think I can speed these conversion routines up a bit, so that suspicion coupled with the low demand for the logic (so far) anyway means I once again don't feel too much pain in exchanging 3 bytes of ZP for an additional 70 or 140 cycles spent in them - they don't get used enough for the slowdown to hurt noticeably, and I'm confident I can speed them up in the future in any case.

So we've freed-up 7 bytes of Zero Page without much more than a small time penalty (and a few bytes increase in size for going to Absolute addressing) in a couple of routines where it doesn't matter much. That's about 4.5% of the OS ZP footprint released straight-away - not a huge amount, but we're still in the low-hanging-fruit zone; I think there might be another 4-6 bytes I can move relatively painlessly, and then we'll tackle the tougher stuff - the glyph work area, and the dirty-row table.

Stay tuned!