Not very random at all, not even remotely

Wow. A bit of a slow work day and perhaps over-estimated the amount of sprite update handlers (some share common routines) and I've really been plowing through it today. In fact, there are only - at last count - 4 sprite update handlers to complete (albeit towards the more complex end of the scale). I'd estimate I'm a good 95% done now, although I haven't been able to test every single routine just yet.

I also encountered another (sigh) pick-up/drop bug whilst wandering around the map. I've yet to attempt to reproduce it, so not even sure how elusive it is. I'm a bit surprised because I thought I'd tested it rather thoroughly. Obviously not thoroughly enough.

Oh, I've hit 5,000 lines of source code tonight; so one outstanding bug isn't too bad.

I also discovered that the GIME timer registers are write-only, and that my temporary pseudo-random number hack - reading the timer LSB - was in fact returning a constant value. It wasn't particularly noticeable until I discovered the bouncing ball that is supposed to move away from Sabreman and move towards Sabrewulf was only tracking one axis, not both. Each update randomly chooses an axis to track.

So I bit the bullet and wrote a GIME TIMER (F)ISR to simulate the Z80 refresh register - a first for me - that took a while to fix a few newbie mistakes. For now it simply increments an 8-bit value every 250ms - but it's enough to get the ball behaving roughly right.

And another first for me - I wrote a couple of self-modifying routines in 6809, admittedly mirroring the Z80 version (obviously with completely different patches). It's worth noting that these particular routines use self-modifying code to reduce code-size, rather than for performance. This might be an issue if I manage to get it running on the Coco2, since I'll want it to run as much code as possible directly out of ROM.

So aside from the ghost, the remaining handlers are associated with the cauldron room which, I must admit, I haven't seen a lot of even when play-testing the C port. It's definitely something I'll have to test thoroughly though before the proper release of each port of course.

And speaking of C ports, while comparing the C and 6809 behaviours today I actually discovered a bug in the C port. I'm not overly surprised because I really still haven't given it a thorough play-through, mainly because I've already noted three (3) outstanding bugs in the source file that are earmarked for fixing first. I'll get to those once the Coco3 demonstration cartridge image has shipped.

So it looks like I'll be ready well before the deadline for a CocoFEST demonstration. I may get the opportunity to experiment with a few extra features that I had expected to miss the demonstration, such as sound, 2-tone (4-colour graphics) and maybe even a Coco2 version. Time will tell...