Finally got a-round to it!

Today lunchtime and tonight I tackled the circular wipe function. I'm pleased to say that it's working in both 1BPP and 2BPP mode. Again, somewhat paradoxically, it's (slightly) faster in 2BPP mode.

It's not enough to simply draw concentric circles; that leaves gaps which give rise to the moiré patterns we so often marvelled at in our BASIC type-in listings. So you need to draw thicker circles to overwrite the gaps. Although three (3) pixels is sufficient in this case, in assembler it's a nightmare, and slow. So I settled on 4 pixels - or a whole byte in 2BPP mode - and I defy you to detect a difference with the original Apple version. In fact, I strongly suspect it's doing the same (I haven't reverse-engineered the actual function itself).

After some first-pass optimisations the 2BPP mode is about 15% faster than the Apple version, so I've left it at that. 1BPP mode is roughly the same speed. I won't bother throttling it at all because after a while it is actually a bit annoying (but all part of the experience).

That just leaves sound and high score load/save, before I add all the levels.

Memory is really tight; in fact the stack is perilously close to the data in the latest build. There's still a bit of shuffling and slight memory optimisation I can do, and I'm also considering revisiting the title screen compression. But all this can wait until after the beta.

Unfortunately I didn't get the chance to order my DriveWire cable components today. I'll endeavour to do so tomorrow.

Back to BASIC(s)

Whilst I wait until I can get a DriveWire cable sorted, I've started looking at the circular wipe.

Tonight I was reacquainting myself with ECB (BASIC) graphics commands and prototyped the code, using Bresenham's circle algorithm (a.k.a. the midpoint circle algorithm). Straightforward stuff, and I don't see that it's going to be particularly troublesome in 6809 assembler. Looking forward to giving it a go, in fact!

Might even be able to sneak it into the beta release...

The Universe conspires...

After mucking about with 80 column text mode, the one last thing I wanted to do was grant myself the small honour of being the first to see Lode Runner running on a real Coco3 in glorious colour.

Given there are several ways to transfer a coco program to a real Coco - cassette, floppy or DriveWire to name a few - I figured it shouldn't be that difficult. So I gave myself a few hours off this afternoon and set up my Coco 3, which has been sitting on the shelf for a few years now.

The first hurdle was video display and, with no suitable monitors at hand, I hooked up my custom analogue RGB to DVI box that worked a few years ago. Except all I got out of it was a solid blue screen. With limited time, I abandoned that idea and instead hooked up the TV's composite input, a process that involved going out and buying some batteries for the remote since there was no other way to switch to AV mode. Finally, at least I had some manner of display.

Next step was the floppy disk drive. The drive I used last time - several years ago - clunked when selected but wouldn't spin up. Fortunately I had a stack of them on hand, but I was fast running out when the 4th one I tried finally sprung to life. Popped-in my (Sockmaster) Donkey Kong floppy that I wrote all those years ago, and it loaded! I had also acquired a pair of joysticks since then, and couldn't resist a quick play since I'd never been able to actually play it before - wow!

Last time I wrote Coco disks with a 5-1/4" floppy in my PC; that machine is now long-gone and the floppy drive whereabouts unknown at this point. I found a few PC floppy drives, but unknown capacities. A moot point though, because I soon discovered my office PC BIOS doesn't support floppy drives. Next option was to power-up a few of the old PC motherboards sitting out the back, but I was running short on monitors and the state of the few power supplies I'd found was dubious at best. It just wasn't looking like it was going to happen that way.

Next option, DriveWire,but I needed to boot-strap the driver. CLOADM (cassette) seemed to easiest option so I grabbed my cable and attempted to download via the WAV file from the PC. All I could manage was "BOOT FAILED", and gave up after 10 attempts. Then I remembered my custom cartridge PCB's; after powering-up the positively ancient laptop connected to the EPROM programmer and waiting 35 minutes for an erase, I managed to burn a copy into ROM (and subsequently found another with HDBDW (HDBDOS-DriveWire) written on it!). That resulted in "BOOT FAILED" again, though I suspected this time what I needed was a DriveWire server on the other end.

Unable now to find my DriveWire cable, I was scratching my head because I knew I'd used it before. In the end I gave up, and on the drive home I realised that I'd used it on Coco3FPGA running on the TerASIC DE1 board, so the cable was different anyway - Doh!

Last resort was converting the Lode Runner files to WAV files and then loading the via CLOADM. When I finally found a utility to convert Coco BIN files to cassette WAV, I was disappointed to discover that it wouldn't work with multi-segment BIN files, and Lode Runner is definitely multi-segment. As an experiment I tried one of my small files and it wouldn't work anyway. I was defeated.

So at this point I am unable to get Lode Runner across to my Coco3, without either setting up a PC with a floppy drive (my preferred option) or making up a DriveWire cable. So I'm afraid I'm going to take my bat and ball and go home (not release the Beta) until I've done so. Sorry!

Beta 2 release imminent!

Found and fixed the 'last' bug! The demo runs through all three levels in lock-step, as far as I can ascertain with the naked eye. As I mentioned, it's pretty solid evidence that the game logic is spot-on.

The issue was an uninitialised zero-page register that is used in determining when to update (move) the guards. Not sure exactly where it's initialised in the Apple II code (perhaps the bootloader, or maybe not at all), but I had to add explicit initialisation to a single byte to bring it into sync with the Apple II version.

Interestingly, this byte is never re-initialised, so subsequent iterations of the demo mode - if interspersed with an actual game - may end with slightly differing results on the 3rd level. This has been confirmed on the Apple II version as well.

Right now the game is running slightly faster than the Apple II version, but still pretty close. I won't bother fine-tuning it yet because the sound code will change all of this again.

The 2nd beta release will likely be tomorrow (Friday AEST) now. Although I don't plan to do any more tweaks to the program itself, there are a few things I'd like to do before the release. One of those things is to get it up and running on my real Coco3 - something I haven't personally done yet.

That just leaves the circular wipe, sound, all 150 levels and (hopefully) high score load/save!

One last subtle bug

I found the bug I mentioned in the next-to-last post, namely the guard dropping the gold in the wrong place right at the end of the 3rd demo level. I actually found it quite quickly - yet another missing piece of code! Although guards always drop the gold when falling into a hole, they also drop them under other conditions - at least when the code to do so has actually been written! Doh!

So having fixed the "last" bug I fired up the demo's again side-by-side - only to notice that the guards were re-spawning in different places at the end of the 3rd level. Since the whole game is deterministic (otherwise the demo wouldn't run) this can only mean a bug in my port. Damn!

After an hour or two of debugging I've discovered that the game state is out of sync somewhere in the first demo level, between the time the 1st guard is killed to the time the 2nd is killed. I know this because the re-spawn column, which is incremented every main in-game loop, is wrong for the 2nd guard. This can only be the case if the guard movements (guard state update) are inaccurate. Further debugging reveals that the state of the 3rd guard is wrong by the time the 2nd guard is killed.

Further debugging has thus far been fruitless but I'm yet to exhaust all avenues - it's just very, very late now and time to get to bed. One area of possibility I've yet to explore is the AI... and I'm not looking forward to that. So I'll continue when I next get the chance.

The one positive to come out of all of this is that, by the time I've found this bug, I can be 99.9% sure that all of the game logic has been ported accurately. The demo mode has been an invaluable tool in that regard!

Wish me luck!

Front and center

I thought I'd upload a quick video showing what I've been working on, including centering the display (thanks Jason) which I neglected to mention in the last post.

Note the centering of the display, the GAME OVER animation, and the high score initials entry.

And if for some reason you still prefer the monochrome graphics, they're still supported.

Hopefully I'll be in a position to release the final beta later tonight (AEST time).

EDIT: This morning I've been fine-tuning the 2BPP game speed and running it side-by-side with the Apple II. I've noticed that the demo seems to be running lock-step until right at the end of the 3rd level, just as the guards get to the top of the ladder... so there can't be too much amiss?!?

A whole stack of bugs!

Tonight I found no less than three stack-related bugs!

The most glaring was the fact that I was initialising the user stack, instead of the system stack (cut-and-paste error) which would eventually (due to the other bugs) overwrite the zero-page variable area and cause all sorts of issues - and almost certainly explains the crash and corruption reported by Keith! Yah!

I also noticed that the stack was ever growing downwards as I cycled through several games; by three (3) bytes if I obtained a high score, and two (2) if I didn't. In the high score entry routine I was pushing B onto the stack to juggle the 6502 registers, and branched over the pull in some instances. That explained the 3rd byte.

The other two bytes were a mystery, until I noticed that the high score entry routine was called from the main loop, but jumped back to it! A quick test on the Apple II version under the MESS debugger confirmed that the original version has the same bug! But because of the circular nature of the 6502 stack, I suspect it never manifests itself as an actual bug in the game. A different story of course on the 6809, hence the aforementioned overwriting of the zero-page area. I fixed it by pulling the extraneous two bytes from the stack before jumping back to the main loop.

All that remains now before the next beta release is a curious inconsistency that I noticed a week or so ago but ignored until now. It may occur elsewhere but where I noticed it was right at the end of the 3rd demo level, where the guard on the Coco3 version drops the gold on a different square than on the Apple II version. Perhaps related is the slightly different spawn-point of another guard and slightly different ending to the demo. I'm not sure at this point how difficult this will be to track down... it's subtle but of course does affect the accuracy of the game-play!

But the good news is that the only other features left incomplete are the circular wipe function, high score load/save, all 150 levels, and the sound. Everything else is there and running - and in 128KB (not 512KB as was required for the first beta)!

Taking another quick look at the circular wipe code today, I'm almost certain that I won't attempt to port it from the 6502 code, but rather write my own. And for the high score load/save, I've had an idea that utilises the task-switching capabilities of the Coco3 GIME that should allow me full access to the DECB ROM (and therefore the disk routines) relatively easily. That just leaves sound.

And then Castle Wolfenstein! ;)