Sunday, 29 January 2017

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.


  1. It likely doesn't matter, but note that only the bottom 7 bits of the R register are incremented every M1 cycle as only those bits are used and needed for DRAM refresh. The top bit can only be changed via "LD R,A".

    1. I did notice that when reading about it, yes.

      Most of the code that uses R directly uses only the bottom few bits anyway, for things like choosing directions for the animated/moving objects.