More than meets the eye

Tonight I finally got the colour mode working - or at least I think it's working with the limited testing I've had time to do. I've literally seen it running for about 4 minutes and it's time for bed!

Turns out the complexities of the Apple II artifacting introduce subtleties that aren't immediately apparent when you're trying to reproduce it on a 4-colour display. I first noticed this when I got to the stage where my 2BPP rendering routines should have produced a faithful static display - yet I had gaps between my brick tiles.

After chasing red-herrings for a while it occurred to me that the tile data I had imported wasn't quite right - the bricks, for example, were only 9 pixels wide, not 10. So I went back to the MESS algorithm in my import routine, and deduced that the root cause was the fact that the artifacting is dependent on the bytes following the pixel in question! Because I was rendering single tiles in isolation, the artifacting algorithm wasn't producing the 10th blue pixel on my bricks.

I subsequently modified my import routine to render two (2) of each tile next to one-another, and lo-and-behold the gap disappeared! After (eventually) realising that I had to wipe the 2nd tile before importing the tile data, I finally had no gaps in the bricks and the graphics all looked, as far as I could tell, correct.

On this point, it is actually impossible to 100% accurately render the artifacting, because bricks adjacent to gaps or ladders or ropes are actually rendered only 9 pixels wide on the Apple II, whilst adjacent bricks are 10 pixels wide. It's also somewhat evident via the gaps next to the ladders. However, the effects are so subtle that they're practically undetectable, and they certainly have no bearing on game-play what-so-ever.

Similarly, there's some fringing effects on the guard and player sprites; however for the most part they are identical to what gets produced on the Apple II (according to MESS at least), except for complex interactions with multiple guards and backgrounds etc, and even then, they're subtle and again, have no bearing on game-play.

Overall, I'm very happy with the colour version and it certainly captures the look and feel of the Apple II version. And after several months of play-testing the monochrome version which, incidentally is the version I'm traditionally familiar with, it does look quite a bit nicer!


I'll do a bit more testing, and I want to attempt to centre the screen and also add the high score initials entry (tedious but trivial) before I release the next beta demo. That will probably be the last beta before the full release, which will include sound.

More is less

Somewhat paradoxically, the tile data for 2BPP mode is actually less than that required for 1BPP mode.

Why? Because in 1BPP mode, 2 bytes are required per scanline to store 10 pixels (10 bits) of tile data. In 2BPP mode, 3 bytes - only 50% more - are required to store 10 pixels (20 bits). Note however that whilst four (4) copies of the tiles are required for 1BPP mode (corresponding to shifts of 0, 2, 4 & 6 pixels), only half as many copies (2) are required for 2BPP mode (shifts 0 & 2 pixels only). Hence the smaller data requirement.

This is also somewhat fortuitous because the title screen data has increased in 2BPP mode, and now it fits without having to beef up the compression.

I've imported the 2BPP mode tile data and hacked the rendering routines just enough to get the left-most 16 pixels of each tile displayed. Results below:

WIP modification of the rendering routines for 2BPP mode

The remainder of the modifications to the rendering shouldn't take too much time - I've already been through this with the TRS-80 Model 4 (Z80) port when implementing the pixel-doubling, which is actually equivalent from a memory-usage perspective.

At this rate I might even have the next beta - in colour - available for release in a few days!

Mysteries of Apple II artifacts

I took a look at the MESS Apple II video driver, and discovered that the artifact emulation (and there's no way of knowing exactly how accurate that is) is definitely more complicated than my quick 'n' dirty on-the-fly conversion.

So with this knowledge in mind, I hacked the MESS algorithm into my graphics conversion utility and managed to produce colourized versions of the title and tile graphics. Unfortunately the 2BPP title data is slightly larger than I bargained for, so I'll need to find a better compression algorithm, but that's for later. Here's the new colour title screen running on the Coco3, which in theory is identical to that rendered in the MESS Apple II driver:

4-colour title screen - in theory identical to Apple II display

And here is a screenshot from my utility, showing the original and colourized tile graphics:

The monochrome and 4-colour tiles, ready for import

So I now generate three (3) variations of the Lode Runner graphics; 1BPP and both monochrome and 4-colour 2BPP formats. I can build any variation simply by commenting (or not) each of a pair of .define statements.

The other area I've been working on today is the generation of the graphic data .BIN file. With thanks to Jason Law, I have a single .BIN file that contains the title and tile graphics data, that is generated not from binary data but in fact assembled from source .db statements. No more generating segments and binary data from a utility; Jason pointed out that it could all be done with .org statements in a single .ASM file! It also means that the memory map (including the graphics data addresses) can be defined in a single location in the source file - which of course is easy to tweak now!

Jason has also been hacking my code (in a good way) and has advised me on how to center the display on the Coco screen, and also get the code running on a 128KB machine. I'll be implementing his suggestions soon!

But for now, I need to finish the 4BPP tile import and then update the rendering routines to suit.

[And on this note, I've realised that the 4BPP mode will, in fact, affect the collision-detection algorithm used by Lode Runner. That's because I'm actually adding pixels to emulate the artifacting on the Apple. However, I would claim that it will not have any significant impact on the game-play.]

Game Over and Apple II colours

Firstly, I've ported the GAME OVER spinning animation. It was quite straightforward (although I had to convert the graphics format) but it looks pretty cool. Curiously enough, achieving a high score means you don't get to see the animation!

A few other fixes and enhancements; added support for the game freeze (pause) function, and fixed the key debounce on the extra life cheat and a few other CTRL key commands. I also added support for the Coco arrow keys, and also the Z & X keys for digging.

In preparation for colour mode, I've re-arranged the memory map to accommodate the larger screen memory required. To do so, I had to relocate the program code from $4000 to $8000, and the graphics data from $8000 to $C000. This presented a new challenge for me - how to load code at $8000, over the BASIC ROM.

I may have mentioned that you can load segments of a BIN file into arbitrary memory banks by having the previous segment load directly into the MMU bank registers to switch them into the 6809 address space. This is the method I've been using to load the graphics data into high memory, by writing a small utility to effectively wrap a custom .BIN file format around the raw binary data.

With the program code, however, the linker already produces a .BIN file which loads at $8000 - as I mentioned - directly over the BASIC ROM. So I wrote another small utility that relocates the .BIN file to an area of empty RAM, prepends a segment to set up the MMU bank registers accordingly, and finally appends a small loader that simply switches in the previously loaded memory pages and then jumps to the Lode Runner main program. The end result is a single binary that can load itself (effectively) over ROM.

With that working, I could turn my attention to implementing actual colours. Since I've been toying with the idea of reverting the title screen graphics data to the original 7-bit format to save some memory, I decided that I would (also) convert the graphics on-the-fly from 1bpp monochrome to 2bpp colour. After some preliminary investigation into how the Apple II colour artifacting actually works, I modified the (still 8-bit) title display routine to display 4 colours.

4-colour title screen generated on-the-fly from the original Apple II data

Not a bad result but the artifacting around the white characters is clearly emphasised, and doesn't gel with the results in MESS. I will probably need to do more thorough research, but it's a pretty good result for what amounts to a few dozen lines of assembler.

I should also note that I am preserving the ability to build 1bpp (mono), 2bpp (mono) and 2bpp (colour) versions of the game - all via .define directives. I could in theory use the same method to (inefficiently) generate the in-game graphics on-the-fly for the 4bpp modes, but there's probably little point. So my next task will be to produce 4bpp mono and colour versions of the tile data and update the rendering routines accordingly. I shouldn't imagine this will be particularly difficult, providing the colour generation falls out easily.

Once I have colour working I'll (hopefully) be able to add some more levels and release a new Beta.

Finally, there is a report of the game crashing (twice) in VCC. At this point I don't have a lot to go on so please, if you do get a crash under emulation, I'd be interested in a screenshot (if there's any corruption) at least. And if you happen to be running it under the debug build of MESS, a full dump (SAVE) of the memory space would be much appreciated!

Lode Runner Playable Demo Beta 1

The remaining 'collision-detection' bug turned out to be a typo and also missing code from the end of a routine! I normally add a place-marker for code that is yet to be ported, but I'd obviously neglected to do so in this case.

The missing code in question, which amounted to just a handful of lines, is particularly interesting because unlike the rest of the collision-detection code which uses the logical playfield, it actually inspects pixels rendered during the draw_player_sprite() routine. This will have ramifications for ports to sprite-only systems, like the Neo Geo, and will likely require that the port maintains the bitmap screens in system memory even though they aren't used for the actual display.

Here's a video of the demo mode running for the 1st level:

That aside, the end result is that Lode Runner is now complete in the sense that it is 100% playable on the Coco 3. There are a few bells and whistles that have yet to be ported, so whilst I work on those I thought I'd release a playable demo for beta testing.

Please read the included README.TXT file before submitting any comments, suggestions and/or bug reports, but feedback is most welcome.

Without further ado, here's a link for an archive with the DSK file.

EDIT: I should add that I'm yet to run this on a real Coco! I plan to do that sometime this week!

UPDATE: I've fixed the problem with not being able to exit the demo. Please re-download.

Still not quite there

Today I worked on implementing the game speed throttling accurately. The speed throttling is interleaved with the sound routines in order to maintain a constant speed; until I add the Coco 3 sound routines it's not going to be 100% accurate. But it's quite close anyway and certainly more than good enough for a beta release.

I also added a few of the easier-to-code missing features, such as high score table, update and (non-destructive) display. The only part missing is the initials entry - they stay blank for now - and of course load and save.

I also fixed the graphical glitch when digging is interrupted by a guard.

That just leaves one (that I'm aware of) niggly bug which I'll address next session; namely the 'collision detection' isn't consistent with the original. It's all done on the logical board, not the graphics screen, so it shouldn't be too difficult to track down.

Once I'm satisfied that there's no latent bugs, I'm intending on releasing a playable beta demo release that will feature the first 5 levels. The beta will otherwise be completely playable, albeit monochrome without the circular wipe and game over animations, sound and high score initials entry. The release will hopefully encourage people to help me play-test, and also whet people's appetite whilst I'm finishing up the port.

I've also tentatively added the scoring support for Championship Lode Runner which I believe is almost identical to the original, aside from the ability to enter messages on the high score list. I'll probably stay true to the original format and release the two variants separately.

I'm also seriously considering (again) releasing it in cartridge form. It would be nice to have something tangible for the Coco, but the cartridge case is the real stick-in-the-mud. Do I take the path that others have in the past for other platforms, and do a limited run using sacrificial carts?

Getting there

Fixed another 3 bugs; 2 in the AI and another in the guard re-spawn routine. In one case I hadn't flipped a BCS/BCC when translating, the other two I didn't realise that SEC, SBC actually performed a subtraction without borrow on the 6502! Why did they invert the Carry flag???

The guard AI is so close now I can't even say for sure that it's not complete and accurate. The game is certainly playable and seemingly just as challenging as the Apple II version.

What is throwing things a little off atm is the speed of the guards. It's telling on the demo screen that the guards do choose the correct path, but lag behind the Apple II somewhat and as a result the demo doesn't play properly. I implemented the guard speed logic in haste the other night so I guess it's time to go back and verify that.

Back to the 4-colour mode; I think I've deduced that it won't be possible to emulate both mono and colour modes with the same tile data. I've not sat down and thought it through properly either way yet, but I'm pretty sure I've reached the right conclusion here. No matter...