Knight Lore all-but-complete!

Today/tonight I fixed the RNG seeded by the ZX Spectrum FRAMES system variable, which determines starting location, amongst other things. Now, at least, the starting location is actually random.

The final fix was the sun/moon graphics glitch on the left/right sides of the frame, invisible on the ZX Spectrum because of the video attributes in use. For the Coco3 port the easiest fix turned out to be simply manually extending the frame sprites, with respective masks, which (IIRC) is what the Amstrad CPC port (and likely others) do.

No more sun/moon graphics glitch left/right of the frame!

The only thing left is to tweak the ballast code in the main loop to slow down 'empty' screens. I've made a quick attempt but will probably spend more time comparing against the ZX Spectrum version before it is finally released.

I've sent out a few copies for testing and review... so hopefully it'll appear on YouTube at some point in the near future!?!

Still undecided on release options...

A (K)Night of Random (Number) Thoughts

It actually took a couple of more sessions but I've finally got joystick support working in Lode Runner. Thankfully there don't appear to be any key ghosting issues. I've packaged up a release which is available from the download page (link to the right).

I need to talk to a few people about cartridge hardware, but I'm leaning towards simply releasing a floppy disk version for free, rather than have it sitting on my hard disk for another 3 years! It was never about the money, but rather the satisfaction of releasing something tangible for the Coco3.

I also did some further work on Knight Lore tonight, in preparation for another release to a tester and a reviewer. I beefed up the random number generator which 'emulates' the Z80 R register. Research indicates that the register is incremented every M1 cycle, which can be once or twice per instruction fetch. That's certainly beyond software emulation, so instead I implemented a 16-bit maximal Galois LFSR which is very efficient to implement in assembler. The LFSR is clocked every 1/20th of a second, using the GIME TMR function and 6809 FIRQ, and the Z80 R register 'emulated' by reading the LSB of the LFSR value. Plenty random enough for the purposes of Knight Lore.

One more seed in the original code is read from $5C78, and is used to generate (amongst other things) a random starting location in the map. Tonight I discovered that this is in fact the LSB of the FRAME (frame counter) system variable on the ZX Spectrum - so when loading manually from disk, relatively random. Right now I don't have a good substitute, so the start location tends to be, well, not so random.

Once I fix the seed above, I need to fix the sun/moon frame glitch in the panel, which is invisible on the ZX Spectrum courtesy of the video memory attribute bytes. On the Amiga/Neo Geo C ports I used the panel graphics from the Amstrad CPC version, which overcomes this issue. However on the Coco3, the easiest solution (I think) will be to implement a hack.

Then I will be able to release for beta testing & review; and then subsequently decide whether to release it (again) for free on floppy, or have a cartridge produced. I'm leaning towards the former, with the possibility of releasing the CPC graphics version on cartridge, possibly together with Alien 8 and Pentagram!?! That's a longer term project though...

For now I just want to tick off all outstanding incomplete projects.

I've forgotten more than I know...

The perils of leaving a project for months - or even years - is that it takes some time to come back up to speed, and even then for a while you're subsequently discovering plenty of details that you've completely forgotten - most of which, unfortunately, result in head-scratching bugs.

A case in point is the joystick support for Lode Runner, which would have been trivial had I implemented it back when I first released it. Now, however, it has taken two sessions and I still don't have it working correctly.

I've spent the last hour or more trying to make sense of the crash I introduced when adding the joystick read routines. For at least 20 minutes nothing at all was making sense; the disassembly in MESS wasn't matching the 6809 assembler listing. Finally I figured out that I was specifying the wrong file as a cartridge image. What made it more elusive was the fact that it actually displayed the (corrupt) splash screen...

That stupid mistake finally sorted, it wasn't getting much easier as the code still crashed, albeit in a different manner. Cutting out code line-by-line I finally got it running again, and then narrowed it down to a single call to the joystick read routine. I couldn't see anything wrong there... but then noticed the length of the ROM image in the makefile output was suspiciously pushed over a 256-byte boundary when crashing. Further analysis revealed that the code was now too long and as a result I was overwriting high memory. Easily fixed by removing the 10th level from the image.

Unfortunately after all this I don't have the time or the energy to muck about with getting analogue joystick emulation to work in MESS and finalise the joystick support. I am however, reasonably confident it'll only take one more session.

I'm now leaning towards releasing both Lode Runner and Knight Lore for free as disk images. The latter could also be programmed into an EPROM or FLASH cartridge as it doesn't require any special banking support or otherwise... I simply don't have the time to dedicate to getting the cartridge productions under way.

Joystick 'routine'

Now that our holidays are over and we are settling into the routine for the new year, I've allocated some time to working on outstanding projects that need to be finished before I start any others. The freshest in my mind is the addition of joystick support to the Coco3 port of Lode Runner.

So tonight I did exactly that, and implemented routines to read the Coco3 joystick and buttons in the same manner as the original code (as far as possible). The good news is that the joystick axes are only read in a single place in the code, and the buttons only a handful of places - which I've coded. I had it starting a game and digging left/right with the joystick buttons.

The bad news is that after configuring the PIA to read the axes, it subsequently crashes when you start a game. I haven't had a chance to look into this any further, but presumably it won't be too difficult to track down. I still suspect ghosting will be an issue though...

Then there's the '86 GIME crash issue to get to the bottom of...

I also need to reconsider holding off on a release until I design a cartridge. It's been an embarrassingly long time since I released the demo, and I have to question whether or not I will ever get around to producing a cartridge for it. If not, I need to code DOS routines so that the game will load the level data from the floppy disk and just get it out there.

Next task should be to release Knight Lore. All it requires is tweaking the speed against the Spectrum original - and confirming it runs no slower - and it's good to go. It also requires nothing more than a standard cartridge, so it could be released with minimal effort.

I suspect once I release Knight Lore on cartridge I'll be able to make up my mind on whether or not I want to release Lode Runner on cartridge as well, or simply release it for free on disk.