I've been making very good progress over the last week. I've managed to find time for a few sessions of coding but I soon discovered that there was more code to write than I'd reckoned on.
I'd taken a few shortcuts previously on both the Z80 and 6809 ports. But now I'd reached the stage where I had to fill in the gaps.
First, I needed to implement the second hires page. I'd reserved the memory, but hadn't coded the routines to read the current page from the zero-page variable(s), so I implemented that. Relatively trivial, but I should note that the Coco now requires 2*8KB=16KB just for the mono screens (as does the Apple II, incidentally) . With the Coco ROM's that doesn't leave a lot of memory, and in fact for now I've removed the title page so I don't need to worry about loaders and switching out the ROM's just yet...
When the level data is first read from disk, a full sector (256 bytes) is read into a disk buffer in low memory. Since each level is 28*16=448 bytes, the level data is packed into nibbles. Thus the sector is subsequently unpacked - not into one but two (2) different buffers - static & live. I had only coded the one copy in order to display the level. Now it does both of course.
And when the level is rendered, it is actually rendered to the 2nd hires page, and then copied to the 1st during the famous circular wipe transition. The program then goes through and wipes the player and enemies from the 2nd page, which is used as the background tile-map during the game to make the sprite emulation more efficient.
So I had to render to the 2nd page, and then I do a straight copy to the 1st (as I'm not attempting the circular wipe at this point). I also added some debug code to toggle the displayed hires page with the <ENTER> key.
Then it was on to the player movement routines, which comprises reading the keyboard, checking the aforementioned level data to ascertain if the player can move, and then emulating sprites using the two hires pages. Here there was a reasonable amount of code to implement, including two basic rendering routines that weren't used for the level rendering, and a handful of support routines that calculate address offsets, pixel shifts, sprite-to-character mappings, etc. It was tedious and error-prone more than anything.
I've discovered that in some cases, the 6502 is actually more efficient than the 6809 - or at least my limited knowledge of the 6809 is preventing me from a line-by-line translation. On the 6502 it's possible to specify an offset (in a register) from a 16-bit address stored in zero-page memory; on the 6809 I can't see how to do this, so for now I've been using 2 instructions to compensate. Otherwise, the main source of confusion is mapping the A,X & Y registers to A,B & X/Y on the 6809. For the most part I've been able to get away with just A&B, since most routines only return one or two values (though sometimes in X and sometimes in Y) - but there's one routine that returns three values in the three 6502 registers, so it gets a little messy with the 6809's 16-bit X register.
As for actual progress, the player can now both run and swing left & right and climb up ladders. In truth, there's a few ladders on the 1st level that you can't (yet) climb, so I need to find that bug. But otherwise, it's working perfectly. Climbing down is just a matter of cranking the handle, and I've simply run out of time.
The good news is that most of the hard grind - the mechanics of rendering - has been done and the movement routines are relatively straight-forward. I also need to add gravity, but I recall seeing that in the Apple II disassembly so that shouldn't be too difficult either.
Once I've got the player moving around everywhere, and falling, I'll post a video of the Coco3 version on this blog. And then I guess I'll roll up my sleeves and bring the Z80 version up-to-date. To be honest, I'm not looking forward to that as there's a lot of index-indirect addressing mode code and the Z80 is going to be horrible (ADD HL,DE).
No comments:
Post a Comment