Since 17th August 2015, I've worked on Knight Lore almost daily, throughout reverse-engineering the original in its entirety, reassembling it to run on the TRS-80 Model 4/4P, porting it to C on the PC, then Amiga and then Neo Geo, then adding the Amstrad CPC graphics to each of the aforementioned C ports and then - finally - re-writing it all in 6809 assembler for the Coco3.
It's fair to say that I've lived, breathed and slept Knight Lore over that period and I'm sure it won't surprise some at all, particularly the programmers amongst you, that I often think about it when trying to get to sleep, or shortly after waking up. And this morning was no exception. In particular, this graphics corruption on the cauldron screen.
I guess it's testament to my familiarity with the code that I was able to pinpoint the likely culprit whilst lying in bed without reference to the listing. In short, it's (another) bug in the original code, one that I've since verified in the ZX Spectrum emulator under MESS. This bug has reared its ugly head before (writing to ROM address space), just under slightly different circumstances and in another section of code; the Coco3 port has video memory where the ZX Spectrum ROM resides, hence the graphics corruption. Simple fix, all done.
I can absolutely guarantee, without a shadow of a doubt, that there are now zero (or more) bugs remaining in the Coco3 port.
Tonight's exercise will be to get it running on real hardware. I'd like to see it running from a cartridge, at least initially, but I also have Drivewire and CocoSDC options as well. Would especially like to see it running from CocoSDC too. Now to find that Coco3 of mine...
Thursday, 31 March 2016
One last bug! Famous last words!
Tonight I debugged and tweaked the cauldron room; the end of game animation, game percentage complete calculations (which had a bug - doesn't come much easier than transcribing 16-bit hex constants, but I still got that wrong) and the routine to wait for a key press which was, up until tonight, labelled and working as a routine to wait for key release! Hmm...
Anyway, as far as bugs go, that just leaves the spurious graphics at the top of the screen when exiting the cauldron room which I noticed tonight, also happens if/when you die in that room. I'm yet to investigate any further, but hopefully having two triggers will make it easier to track down. Then I can tentatively consider it bug free!
Bugs aside, that just leaves performance, or more specifically, the slow-down in busy rooms. But after more play testing and comparison against the ZX Spectrum version, I'd have to say that even as-is, the Coco3 isn't actually noticeably slower at all! And the speed-up / slow-down within rooms, which I thought was limited to the Coco3 port, occurs on the original as well.
So this all begs the question - do I optimise it until its actually faster - or perhaps more accurately, less slow - than the original? Is there a point where I cross the line between improving it, and changing the game play? I'd say definitely yes, but I still think it could do with a bit of a speed boost on the slowest sections. I'll have to play around with it.
Once I've fixed the remaining glitch though, I'm going to haul out the Coco3 and burn an EPROM. Can't wait to see it running on real hardware! Worst case, that'll be the image I send to CocoFEST.
Anyway, as far as bugs go, that just leaves the spurious graphics at the top of the screen when exiting the cauldron room which I noticed tonight, also happens if/when you die in that room. I'm yet to investigate any further, but hopefully having two triggers will make it easier to track down. Then I can tentatively consider it bug free!
Bugs aside, that just leaves performance, or more specifically, the slow-down in busy rooms. But after more play testing and comparison against the ZX Spectrum version, I'd have to say that even as-is, the Coco3 isn't actually noticeably slower at all! And the speed-up / slow-down within rooms, which I thought was limited to the Coco3 port, occurs on the original as well.
So this all begs the question - do I optimise it until its actually faster - or perhaps more accurately, less slow - than the original? Is there a point where I cross the line between improving it, and changing the game play? I'd say definitely yes, but I still think it could do with a bit of a speed boost on the slowest sections. I'll have to play around with it.
Once I've fixed the remaining glitch though, I'm going to haul out the Coco3 and burn an EPROM. Can't wait to see it running on real hardware! Worst case, that'll be the image I send to CocoFEST.
Tuesday, 29 March 2016
More play and less work...
Just enough time tonight to set the build for (almost) invincibility, set the start location two screens to the east of the cauldron room, run under the spiked balls, jump over the fire, and enter the cauldron room. I watched the wizard head west, turn north, take a few steps, and then the screen filled up with garbage. At least it's consistent!
The C port doesn't have the same issue, but it also doesn't have bubbles in the cauldron. Bug #4 for that port. Time for some serious play testing.
UPDATE: Fixed the bug in the Coco port with the screen filling with garbage. However I noticed an issue with some rubbish on the top few lines of the display whenever you exit the cauldron room. That can wait until I finish testing the rest of the cauldron room; next is to drop a special item into the cauldron.
UPDATE #2: The cauldron room is all-but-complete. There were a few bugs, thankfully easy to find and fix. You can add objects to the cauldron, and adding the last object triggers the end-of-game animation (I won't spoil it for you) and the game ends. Some nigglies; still the rubbish at the top of the screen, the animation isn't quite right, and the end of game screens don't wait for key press. But it's very, very close now.
I also borrowed an EPROM programmer today, so I'll be able to test the cartridge image on real hardware - looking forward to seeing that!
The C port doesn't have the same issue, but it also doesn't have bubbles in the cauldron. Bug #4 for that port. Time for some serious play testing.
UPDATE: Fixed the bug in the Coco port with the screen filling with garbage. However I noticed an issue with some rubbish on the top few lines of the display whenever you exit the cauldron room. That can wait until I finish testing the rest of the cauldron room; next is to drop a special item into the cauldron.
UPDATE #2: The cauldron room is all-but-complete. There were a few bugs, thankfully easy to find and fix. You can add objects to the cauldron, and adding the last object triggers the end-of-game animation (I won't spoil it for you) and the game ends. Some nigglies; still the rubbish at the top of the screen, the animation isn't quite right, and the end of game screens don't wait for key press. But it's very, very close now.
I also borrowed an EPROM programmer today, so I'll be able to test the cartridge image on real hardware - looking forward to seeing that!
Monday, 28 March 2016
Lode Runner update complete!
I've fixed the issues introduced with the new architecture/build. I've also added an amber monitor mode to the monochrome builds, and with RGB/composite selected on the splash screen now, I've removed the in-game option to toggle.
The Project List & Downloads page has a link to the new beta demo, which includes the fix to the monochrome versions of the GAME OVER rotating banner. I've only uploaded the cartridge images this time, purely to save myself some work and they're easier and quicker to boot in an emulator. If anyone specifically wants to run from floppy on a real system, contact me.
So it's back to the Coco3 port of Knight Lore tomorrow, or whenever I get time next. Either play testing for the cauldron screen, optimising the performance, or perhaps even starting on the Amstrad CPC graphics. I should probably tackle them in the order I've mentioned them here... but I know which is the most fun...
The Project List & Downloads page has a link to the new beta demo, which includes the fix to the monochrome versions of the GAME OVER rotating banner. I've only uploaded the cartridge images this time, purely to save myself some work and they're easier and quicker to boot in an emulator. If anyone specifically wants to run from floppy on a real system, contact me.
So it's back to the Coco3 port of Knight Lore tomorrow, or whenever I get time next. Either play testing for the cauldron screen, optimising the performance, or perhaps even starting on the Amstrad CPC graphics. I should probably tackle them in the order I've mentioned them here... but I know which is the most fun...
Lode Runner revisited.
Tonight I revisited my Coco3 port of Lode Runner, bringing the build mechanism into line with Knight Lore. Again, this means a single build for cart/disk and I also added a splash screen to the game code rather than patching from a BASIC loader. On the down side, mono and colour variants are now different builds and different images - but the pros outweigh the cons.
I still need to fix some very minor issues, all introduced with the new build mechanism, and then I'll release the latest beta demo; I fixed the GAME OVER graphics in the monochrome build many many months ago.
I should probably get the cart designed and built once Knight Lore is complete so I can actually release the full game, before starting on the next port! ;) After all, no point developing it and have it sit on my hard disk unable to be enjoyed by anyone else, especially since Lode Runner is such an awesome game!
I still need to fix some very minor issues, all introduced with the new build mechanism, and then I'll release the latest beta demo; I fixed the GAME OVER graphics in the monochrome build many many months ago.
I should probably get the cart designed and built once Knight Lore is complete so I can actually release the full game, before starting on the next port! ;) After all, no point developing it and have it sit on my hard disk unable to be enjoyed by anyone else, especially since Lode Runner is such an awesome game!
Saturday, 26 March 2016
Losing my direction... and optimisations.
Since my survey suggested that using directional controls on Knight Lore was more popular than rotational, I decided to look further into adding directional support. I fired up the ZX Spectrum version in MESS, selected directional, and started a game. The controls were still rotational.
So tonight I studied the portions of the input handler that I've previously ignored until now, and duly discovered that directional controls are only supported for joystick input. Odd, but it explains my confusion. A bit lazy on the input menu; they should have disabled selection of directional input when the keyboard is selected. Obviously these Stamper guys were complete amateurs, and likely never amounted to anything.
So for now, rotational it is. There's still just under 2KB free, so we'll see.
As for the CocoFEST demonstration, it's almost there. I do need to tweak the adaptive delay routine that is meant to temper the speed in the emptier rooms to make it more playable, and closer to the limit of the game (ie. when things get busy). I wonder how they did that back in the day - I certainly haven't decided on the most efficient course of action yet. I was thinking something along the lines of a FPS (or more likely, FPM) counter based off the GIME (slow) timer to get some idea of the effect of each object wiped and rendered.
At its worst, it probably is a tad slower than the Spectrum, though of course I haven't done a scrap of optimisation in the rendering, let-alone anywhere else in the code. There is a rather simple optimisation I can do, given the 128KB available to the Coco3, the 8KB banks of the GIME MMU, and the convenient fact that the sprite data is almost exactly 16KB and (by design) resides from $8000-$BFFF. And that is, create a second bank of sprite data that is HFLIP'd already. As you can imagine, flipping a sprite about its vertical axis (horizontally) is quite computationally expensive, and this optmisation would reduce a flip to setting a pair of bytes (or a single word) in the GIME MMU.
That aside, and play testing aside, I'm pretty happy with it. I've added a text-mode splash screen that lets the player select between RGB and composite palettes, though I might need to re-visit the choices I made for the composite palette that I cooked up in a hurry. It's pretty awesome that MESS emulates both display types!
I might spend a night with Lode Runner - sooner rather than later - and set up the build as I have done with Knight Lore, and also add the splash screen rather than using the cumbersome BASIC loader to select the display. Maybe I can talk someone into demonstrating Lode Runner at CocoFEST too?
The only additional aspect I'd like to explore, once the above are complete, is adding support for the Amstrad CPC graphics (it'll be a separate cartridge image). If the optimisations are successful and I get even a little headroom, there should be ample performance for the 2BPP graphics. Then I can finally put this to bed and release the finished product. Then retire on the proceeds.
So tonight I studied the portions of the input handler that I've previously ignored until now, and duly discovered that directional controls are only supported for joystick input. Odd, but it explains my confusion. A bit lazy on the input menu; they should have disabled selection of directional input when the keyboard is selected. Obviously these Stamper guys were complete amateurs, and likely never amounted to anything.
So for now, rotational it is. There's still just under 2KB free, so we'll see.
As for the CocoFEST demonstration, it's almost there. I do need to tweak the adaptive delay routine that is meant to temper the speed in the emptier rooms to make it more playable, and closer to the limit of the game (ie. when things get busy). I wonder how they did that back in the day - I certainly haven't decided on the most efficient course of action yet. I was thinking something along the lines of a FPS (or more likely, FPM) counter based off the GIME (slow) timer to get some idea of the effect of each object wiped and rendered.
At its worst, it probably is a tad slower than the Spectrum, though of course I haven't done a scrap of optimisation in the rendering, let-alone anywhere else in the code. There is a rather simple optimisation I can do, given the 128KB available to the Coco3, the 8KB banks of the GIME MMU, and the convenient fact that the sprite data is almost exactly 16KB and (by design) resides from $8000-$BFFF. And that is, create a second bank of sprite data that is HFLIP'd already. As you can imagine, flipping a sprite about its vertical axis (horizontally) is quite computationally expensive, and this optmisation would reduce a flip to setting a pair of bytes (or a single word) in the GIME MMU.
That aside, and play testing aside, I'm pretty happy with it. I've added a text-mode splash screen that lets the player select between RGB and composite palettes, though I might need to re-visit the choices I made for the composite palette that I cooked up in a hurry. It's pretty awesome that MESS emulates both display types!
I might spend a night with Lode Runner - sooner rather than later - and set up the build as I have done with Knight Lore, and also add the splash screen rather than using the cumbersome BASIC loader to select the display. Maybe I can talk someone into demonstrating Lode Runner at CocoFEST too?
The only additional aspect I'd like to explore, once the above are complete, is adding support for the Amstrad CPC graphics (it'll be a separate cartridge image). If the optimisations are successful and I get even a little headroom, there should be ample performance for the 2BPP graphics. Then I can finally put this to bed and release the finished product. Then retire on the proceeds.
Friday, 25 March 2016
The... castle... is alive, with the sound of music!
Very quick update - sound is fully implemented and (I think) fully working!
Details to follow...
UPDATE: Knight Lore uses the ZX Spectrum 1-bit sound output to produce, well, rather ordinary sound if we're being honest here. The sound was often criticised back in the day, but it still adds to the game play. Sound programming was never my strong suit, but it didn't take much to coax some beeps out of the Coco's 1-bit interface that sounded vaguely familiar.
I started with the music, reasoning that would be the easiest to compare playback speed. There's a table of notes in the code and each of the 4 tunes consists of an array of bytes that correspond to notes and a few bits of duration. It was straightforward to reverse-engineer and similarly trivial to re-implement in 6809. First cut sounded like music - just not a lot like Knight Lore music.
Not being able to see the issue in my code, I turned to MESS and recorded the main menu theme from both the original and my port. Loading them both up in Audacity, and aligning them approximately, I could confirm which counters were working and which weren't, as well as see the frequency difference. It wasn't too long before I spotted the bug in my code and viola - unmistakably the same tune! And as an added bonus, adding a single NOP in the inner loops slowed the speed to pretty much perfectly match the original.
With the low-level sound I/O and music done, it was a simple matter of working my way through the dozen or so sound routines, most fairly trivial and most worked first time.
There was one minor sticking point that resulted in a discussion with a few Coco gurus via FB. A couple of routines used the Z80 RLCA/RRCA instructions, an 8-bit rotate. The 6809, OTOH, only has 9-bit rotation instructions - all through the Carry bit. It wasn't too long during my aforementioned discussion that I'd hit upon a solution; if both accumulators on the 6809 have the same value, then LSLA, ROLB will effect a single RLCA. And as it happens, one routine used five (5) consecutive RRCA instructions, which I could replace with just 3 consecutive LSLA, ROLB instructions.
Although I haven't painstakingly compared all the sound effects just yet, what's there is pretty close and given the nature of the original effects, largely sufficient in any case.
Overall, I'm pretty happy that I was able to implement all the sound in a single day. I wasn't sure whether it would make the cut for the CocoFEST demo, but there it is!
Details to follow...
UPDATE: Knight Lore uses the ZX Spectrum 1-bit sound output to produce, well, rather ordinary sound if we're being honest here. The sound was often criticised back in the day, but it still adds to the game play. Sound programming was never my strong suit, but it didn't take much to coax some beeps out of the Coco's 1-bit interface that sounded vaguely familiar.
I started with the music, reasoning that would be the easiest to compare playback speed. There's a table of notes in the code and each of the 4 tunes consists of an array of bytes that correspond to notes and a few bits of duration. It was straightforward to reverse-engineer and similarly trivial to re-implement in 6809. First cut sounded like music - just not a lot like Knight Lore music.
Not being able to see the issue in my code, I turned to MESS and recorded the main menu theme from both the original and my port. Loading them both up in Audacity, and aligning them approximately, I could confirm which counters were working and which weren't, as well as see the frequency difference. It wasn't too long before I spotted the bug in my code and viola - unmistakably the same tune! And as an added bonus, adding a single NOP in the inner loops slowed the speed to pretty much perfectly match the original.
With the low-level sound I/O and music done, it was a simple matter of working my way through the dozen or so sound routines, most fairly trivial and most worked first time.
There was one minor sticking point that resulted in a discussion with a few Coco gurus via FB. A couple of routines used the Z80 RLCA/RRCA instructions, an 8-bit rotate. The 6809, OTOH, only has 9-bit rotation instructions - all through the Carry bit. It wasn't too long during my aforementioned discussion that I'd hit upon a solution; if both accumulators on the 6809 have the same value, then LSLA, ROLB will effect a single RLCA. And as it happens, one routine used five (5) consecutive RRCA instructions, which I could replace with just 3 consecutive LSLA, ROLB instructions.
Although I haven't painstakingly compared all the sound effects just yet, what's there is pretty close and given the nature of the original effects, largely sufficient in any case.
Overall, I'm pretty happy that I was able to implement all the sound in a single day. I wasn't sure whether it would make the cut for the CocoFEST demo, but there it is!
Thursday, 24 March 2016
A (messy) splash of colour
A quick post on lunchtime progress, which I may update later tonight.
Fixed the bug I mentioned in the last post, which turned out not to be related to the new sprite update handler, but actually a latent bug in an existing one.
This means that there are no KNOWN bugs. I won't even pretend that are aren't any bugs at all, since the cauldron screen and game complete special effects have not been tested at all. This will of course require more extensive game testing. It's a rough job but someone has to do it!
I also dabbled with getting the correct colours on the menu screen, using well known trickery (no prizes for guessing what's going on) in 2-colour mode.
Not sure that I like it at all. It also takes a pretty heavy toll on the CPU, so can only be run when text screens are displayed. Having said that, I still need to work out how I'm going to flash the menu items that are selected, such as keyboard/joystick and directional controls.
It's time to get it running as a cartridge image.
UPDATE: Knight Lore is now running as a cartridge image. I've improved a little on the arrangement I had for Lode Runner; the cartridge image is now converted directly to a DECB .BIN that loads itself into the correct memory pages. A small boot binary displays a splash screen, sets up the MMU and jumps into the game. As a result, there's only a single version - the cartridge version - that is subsequently massaged to run from disk.
Fixed the bug I mentioned in the last post, which turned out not to be related to the new sprite update handler, but actually a latent bug in an existing one.
This means that there are no KNOWN bugs. I won't even pretend that are aren't any bugs at all, since the cauldron screen and game complete special effects have not been tested at all. This will of course require more extensive game testing. It's a rough job but someone has to do it!
I also dabbled with getting the correct colours on the menu screen, using well known trickery (no prizes for guessing what's going on) in 2-colour mode.
 |
| Better, or worse than monochrome? |
Not sure that I like it at all. It also takes a pretty heavy toll on the CPU, so can only be run when text screens are displayed. Having said that, I still need to work out how I'm going to flash the menu items that are selected, such as keyboard/joystick and directional controls.
It's time to get it running as a cartridge image.
UPDATE: Knight Lore is now running as a cartridge image. I've improved a little on the arrangement I had for Lode Runner; the cartridge image is now converted directly to a DECB .BIN that loads itself into the correct memory pages. A small boot binary displays a splash screen, sets up the MMU and jumps into the game. As a result, there's only a single version - the cartridge version - that is subsequently massaged to run from disk.
Wednesday, 23 March 2016
Is that the Fat Lady I hear doing her voice exercises?
With the kids in bed and the wife out to dinner, I made it my mission to plow through the remaining routines (with the exception of sound) and get them all coded, if not tested. And I'm very happy to report - mission accomplished!
I also fixed the bug in pickup/drop, which wasn't a bug in that routine at all.
However, I have encountered another bug on another screen, but that does involve sprite update handlers I've just added tonight, so I'm not overly surprised. One for tomorrow...
So, where is it at now? In total - 5,315 lines of 6809 ASM (compared to approximately 7,000 lines of Z80 - not bad!) not including location and graphics data. Code resides from $4000-$63F2 (9,203 bytes). Data resides from $8000-$CE57 (20,056 bytes). Together that's $724B of code/data that needs to go into ROM, leaving just $DB5 or 3,509 bytes free. Plus there's sound code/data. Not quite enough for the title screen (6KB+) unfortunately, so that'll have to wait for a bank-switched flash cart with all three filmation games! ;)
As for performance; with no attempt at any optimisations, speed is still looking very good, with empty rooms still way too fast, and busy rooms slow but not too slow, even with a quick 'n' dirty hack of a delay routine. Once the code is tweaked I think the Coco3 will actually out-perform the ZX Spectrum's 3.5MHz Z80!
So, what's missing? Sound, for one. I've an idea for adding a splash of colour to the title screens, even in 2-colour mode. And player controls; the original offers both directional and rotational options, whilst atm I've only implemented rotational (purely arbitrary). After a survey on the ZX Spectrum forums, it seems directional was more popular, so I'd like to add that option as well. As for joystick... hmm...
Amstrad CPC (2-tone or 4-colour) graphics is also on the cards, but unlikely for the demo. And a possible port to the Coco2 (even if just a proof-of-concept) running out of cartridge ROM.
Right now though, after fixing any remaining bugs, I need to get it running as a cartridge image, rather than loading from disk as it does now. That means re-arranging the memory map quite significantly, and also writing a loader of sorts to move the ROM into RAM.
I also fixed the bug in pickup/drop, which wasn't a bug in that routine at all.
However, I have encountered another bug on another screen, but that does involve sprite update handlers I've just added tonight, so I'm not overly surprised. One for tomorrow...
So, where is it at now? In total - 5,315 lines of 6809 ASM (compared to approximately 7,000 lines of Z80 - not bad!) not including location and graphics data. Code resides from $4000-$63F2 (9,203 bytes). Data resides from $8000-$CE57 (20,056 bytes). Together that's $724B of code/data that needs to go into ROM, leaving just $DB5 or 3,509 bytes free. Plus there's sound code/data. Not quite enough for the title screen (6KB+) unfortunately, so that'll have to wait for a bank-switched flash cart with all three filmation games! ;)
As for performance; with no attempt at any optimisations, speed is still looking very good, with empty rooms still way too fast, and busy rooms slow but not too slow, even with a quick 'n' dirty hack of a delay routine. Once the code is tweaked I think the Coco3 will actually out-perform the ZX Spectrum's 3.5MHz Z80!
 |
| Just because this blog needs more eye candy |
So, what's missing? Sound, for one. I've an idea for adding a splash of colour to the title screens, even in 2-colour mode. And player controls; the original offers both directional and rotational options, whilst atm I've only implemented rotational (purely arbitrary). After a survey on the ZX Spectrum forums, it seems directional was more popular, so I'd like to add that option as well. As for joystick... hmm...
Amstrad CPC (2-tone or 4-colour) graphics is also on the cards, but unlikely for the demo. And a possible port to the Coco2 (even if just a proof-of-concept) running out of cartridge ROM.
Right now though, after fixing any remaining bugs, I need to get it running as a cartridge image, rather than loading from disk as it does now. That means re-arranging the memory map quite significantly, and also writing a loader of sorts to move the ROM into RAM.
Not very random at all, not even remotely
Wow. A bit of a slow work day and perhaps over-estimated the amount of sprite update handlers (some share common routines) and I've really been plowing through it today. In fact, there are only - at last count - 4 sprite update handlers to complete (albeit towards the more complex end of the scale). I'd estimate I'm a good 95% done now, although I haven't been able to test every single routine just yet.
I also encountered another (sigh) pick-up/drop bug whilst wandering around the map. I've yet to attempt to reproduce it, so not even sure how elusive it is. I'm a bit surprised because I thought I'd tested it rather thoroughly. Obviously not thoroughly enough.
Oh, I've hit 5,000 lines of source code tonight; so one outstanding bug isn't too bad.
I also discovered that the GIME timer registers are write-only, and that my temporary pseudo-random number hack - reading the timer LSB - was in fact returning a constant value. It wasn't particularly noticeable until I discovered the bouncing ball that is supposed to move away from Sabreman and move towards Sabrewulf was only tracking one axis, not both. Each update randomly chooses an axis to track.
So I bit the bullet and wrote a GIME TIMER (F)ISR to simulate the Z80 refresh register - a first for me - that took a while to fix a few newbie mistakes. For now it simply increments an 8-bit value every 250ms - but it's enough to get the ball behaving roughly right.
And another first for me - I wrote a couple of self-modifying routines in 6809, admittedly mirroring the Z80 version (obviously with completely different patches). It's worth noting that these particular routines use self-modifying code to reduce code-size, rather than for performance. This might be an issue if I manage to get it running on the Coco2, since I'll want it to run as much code as possible directly out of ROM.
So aside from the ghost, the remaining handlers are associated with the cauldron room which, I must admit, I haven't seen a lot of even when play-testing the C port. It's definitely something I'll have to test thoroughly though before the proper release of each port of course.
And speaking of C ports, while comparing the C and 6809 behaviours today I actually discovered a bug in the C port. I'm not overly surprised because I really still haven't given it a thorough play-through, mainly because I've already noted three (3) outstanding bugs in the source file that are earmarked for fixing first. I'll get to those once the Coco3 demonstration cartridge image has shipped.
So it looks like I'll be ready well before the deadline for a CocoFEST demonstration. I may get the opportunity to experiment with a few extra features that I had expected to miss the demonstration, such as sound, 2-tone (4-colour graphics) and maybe even a Coco2 version. Time will tell...
I also encountered another (sigh) pick-up/drop bug whilst wandering around the map. I've yet to attempt to reproduce it, so not even sure how elusive it is. I'm a bit surprised because I thought I'd tested it rather thoroughly. Obviously not thoroughly enough.
Oh, I've hit 5,000 lines of source code tonight; so one outstanding bug isn't too bad.
I also discovered that the GIME timer registers are write-only, and that my temporary pseudo-random number hack - reading the timer LSB - was in fact returning a constant value. It wasn't particularly noticeable until I discovered the bouncing ball that is supposed to move away from Sabreman and move towards Sabrewulf was only tracking one axis, not both. Each update randomly chooses an axis to track.
So I bit the bullet and wrote a GIME TIMER (F)ISR to simulate the Z80 refresh register - a first for me - that took a while to fix a few newbie mistakes. For now it simply increments an 8-bit value every 250ms - but it's enough to get the ball behaving roughly right.
And another first for me - I wrote a couple of self-modifying routines in 6809, admittedly mirroring the Z80 version (obviously with completely different patches). It's worth noting that these particular routines use self-modifying code to reduce code-size, rather than for performance. This might be an issue if I manage to get it running on the Coco2, since I'll want it to run as much code as possible directly out of ROM.
So aside from the ghost, the remaining handlers are associated with the cauldron room which, I must admit, I haven't seen a lot of even when play-testing the C port. It's definitely something I'll have to test thoroughly though before the proper release of each port of course.
And speaking of C ports, while comparing the C and 6809 behaviours today I actually discovered a bug in the C port. I'm not overly surprised because I really still haven't given it a thorough play-through, mainly because I've already noted three (3) outstanding bugs in the source file that are earmarked for fixing first. I'll get to those once the Coco3 demonstration cartridge image has shipped.
So it looks like I'll be ready well before the deadline for a CocoFEST demonstration. I may get the opportunity to experiment with a few extra features that I had expected to miss the demonstration, such as sound, 2-tone (4-colour graphics) and maybe even a Coco2 version. Time will tell...
Monday, 21 March 2016
Working towards a demo at CocoFEST
Another major milestone; all special objects code and end of game is done (if not tested) and now it's just down to the sprite update handlers.
And I've started making headway on those too, adding the portcullis, up/down bouncing balls and extra life (which has a bug atm).
Some useless metrics; the 6809 .ASM file is now 4,636 lines, and that doesn't include the location or graphics data, so it's almost all code. By comparison the Z80 listing (.LST) file is around 7,000 lines ignoring the above-mentioned data.
There are around 30 sprite update handler routines yet to be completed, of varying complexity. Tonight I managed to get through three (3) decent samples. Adding lunchtimes I'd hope to get through perhaps 5 per day, so if all goes smoothly, it could be done in about a week. Add another week for debugging, testing and the cauldron screen bells & whistles. Then it should be in decent enough shape to at least demonstrate it at CocoFEST.
And I've started making headway on those too, adding the portcullis, up/down bouncing balls and extra life (which has a bug atm).
Some useless metrics; the 6809 .ASM file is now 4,636 lines, and that doesn't include the location or graphics data, so it's almost all code. By comparison the Z80 listing (.LST) file is around 7,000 lines ignoring the above-mentioned data.
There are around 30 sprite update handler routines yet to be completed, of varying complexity. Tonight I managed to get through three (3) decent samples. Adding lunchtimes I'd hope to get through perhaps 5 per day, so if all goes smoothly, it could be done in about a week. Add another week for debugging, testing and the cauldron screen bells & whistles. Then it should be in decent enough shape to at least demonstrate it at CocoFEST.
Sunday, 20 March 2016
5 bugs and a red herring
Weekends are traditionally harder for me to find time to work on my projects but the lack of updates in recent days has more to do with a lack of progress than a lack of time.
I've finally fixed pickup/drop but not before finding - by last count - no less than 5 bugs in my code. Some related to pickup/drop, and some not - and one that didn't affect game play at all. But there's no doubt this was the hardest issue to debug in the port thus far.
What was more interesting is that the process highlighted the fact that, even after rewriting in C and porting to 3 different platforms, and now a two-thirds complete port in 6809, some of the finer points of the code's operation still escaped me. Indeed, this was the very cause of a major red herring over the weekend, spending a few hours tracking down a 'bug' that wasn't actually a bug at all. The exact cause is - in my opinion at least - interesting enough to warrant its own post and even video - so I'll leave that for later in the working week.
But for now, I'm happy to report that I can finally continue on with the port. There's still a small amount of code to finish off the special objects, then as I reported, that just leaves the cauldron room, end of game, and the remaining sprite update handlers. Not sure at this point the best way to tackle them, though I'll probably look at end of game first since the cauldron room is largely implemented as a sprite update handler.
Hopefully it's all pretty smooth sailing from here-on in.
I've finally fixed pickup/drop but not before finding - by last count - no less than 5 bugs in my code. Some related to pickup/drop, and some not - and one that didn't affect game play at all. But there's no doubt this was the hardest issue to debug in the port thus far.
What was more interesting is that the process highlighted the fact that, even after rewriting in C and porting to 3 different platforms, and now a two-thirds complete port in 6809, some of the finer points of the code's operation still escaped me. Indeed, this was the very cause of a major red herring over the weekend, spending a few hours tracking down a 'bug' that wasn't actually a bug at all. The exact cause is - in my opinion at least - interesting enough to warrant its own post and even video - so I'll leave that for later in the working week.
But for now, I'm happy to report that I can finally continue on with the port. There's still a small amount of code to finish off the special objects, then as I reported, that just leaves the cauldron room, end of game, and the remaining sprite update handlers. Not sure at this point the best way to tackle them, though I'll probably look at end of game first since the cauldron room is largely implemented as a sprite update handler.
Hopefully it's all pretty smooth sailing from here-on in.
Thursday, 17 March 2016
So good, you can't put it down!
Not much to report as I've been struck down with what is probably a stomach bug my son had a few days ago. So between re-installing broken M$ development tools for work, trying to reacquaint myself with code I wrote about 7 years ago, juggling the demands of a wife and two young kids, whilst trying not to throw up, doesn't leave a lot of time for frivolous pursuits. Or even really, really important ones like Knight Lore, either.
I have however finished coding the routine that displays objects you're carrying in the panel. That appears to work almost flawlessly, except for a stray pixel on the other side of the screen. But you can pick up a special object, and cycle it through the three carrying slots, and then drop it again - before all chaos lets loose; half the wizard and a scroll appears to replace Sabreman, and the game freezes.
Having said that, I'd maintain it's still very close to having pick-up/drop working. And that, in turn means that aside from the cauldron room and the game over screen, it's pretty much all done except for a bunch of sprite update handlers. Approaching the home stretch now (although it's a decently long stretch, maybe up to 30% of the code base).
I have however finished coding the routine that displays objects you're carrying in the panel. That appears to work almost flawlessly, except for a stray pixel on the other side of the screen. But you can pick up a special object, and cycle it through the three carrying slots, and then drop it again - before all chaos lets loose; half the wizard and a scroll appears to replace Sabreman, and the game freezes.
Having said that, I'd maintain it's still very close to having pick-up/drop working. And that, in turn means that aside from the cauldron room and the game over screen, it's pretty much all done except for a bunch of sprite update handlers. Approaching the home stretch now (although it's a decently long stretch, maybe up to 30% of the code base).
Wednesday, 16 March 2016
Pixel perfect!
Somehow managed to get some Knight Lore in before work this morning!
The graphical glitches and extraneous wipes were all caused by a 6809 register not being preserved in the sprite flipping routine. I found that very late last night and patched it, but this morning I implemented the proper fix. All rendering looks spot-on now - another major milestone!
I also found the bug when jumping off the top of the screen; that was (Z80) NEG transcribed as COMA instead of NEGA - used when calculating the actual number of lines to render for the sprite.
So at this point, there are no outstanding bugs that are apparent from my (admittedly) limited testing, although I have wandered around several dozen screens and jumped and climbed all over the contents. I would imagine that most, if not all, of the rendering logic has been reasonably thoroughly exercised by now.
There is one very minor glitch that seems to appear on only the initial screen, in that exiting the south arch causes a pixel or two from the panel to be wiped. However I have confirmed that this is actually an issue with original ZX Spectrum version, so it's something that I will not be fixing. After all, the idea is to provide a completely authentic experience.
Next on the agenda is the nightly transformation to sabrewulf and adding the special objects and the ability to pick them up and drop them. I'm tempted to say that it'll be quite straightforward, but I don't want to jinx myself!
UPDATE: Sabreman/sabrewulf (day/night) transform done.
UPDATE #2: Special objects appear.
UPDATE #3: Pickup/drop is coded and half-working - need to code object display to debug.
The graphical glitches and extraneous wipes were all caused by a 6809 register not being preserved in the sprite flipping routine. I found that very late last night and patched it, but this morning I implemented the proper fix. All rendering looks spot-on now - another major milestone!
I also found the bug when jumping off the top of the screen; that was (Z80) NEG transcribed as COMA instead of NEGA - used when calculating the actual number of lines to render for the sprite.
So at this point, there are no outstanding bugs that are apparent from my (admittedly) limited testing, although I have wandered around several dozen screens and jumped and climbed all over the contents. I would imagine that most, if not all, of the rendering logic has been reasonably thoroughly exercised by now.
 |
| It was previously impossible to get to this block without crashing the game |
There is one very minor glitch that seems to appear on only the initial screen, in that exiting the south arch causes a pixel or two from the panel to be wiped. However I have confirmed that this is actually an issue with original ZX Spectrum version, so it's something that I will not be fixing. After all, the idea is to provide a completely authentic experience.
Next on the agenda is the nightly transformation to sabrewulf and adding the special objects and the ability to pick them up and drop them. I'm tempted to say that it'll be quite straightforward, but I don't want to jinx myself!
UPDATE: Sabreman/sabrewulf (day/night) transform done.
UPDATE #2: Special objects appear.
UPDATE #3: Pickup/drop is coded and half-working - need to code object display to debug.
Tuesday, 15 March 2016
3 - 3 = 3?
Back on home soil, adjusted to the timezone and found a little time to continue with Knight Lore. The immediate task is to (completely) debug the code before adding any more.
The good news is that I've fixed three (3) bugs thus far.
One was interesting; the moon freezing on Day 02 for a minute or more turned out to be from a source I would never have guessed. The game has three (what I call) "seeds" used for randomising certain elements of the game, each having a different distribution. Seed #2 is simply incremented each time through the game loop, and drives the sun/moon moving across the frame.
Although the seed is only ever used (read) as an 8-bit value, the code does a 16-bit increment. On a Z80, that means the lower address - the one read using an 8-bit read - is incremented every loop. On the 6809 however, it's the higher address that is incremented every loop (and the lower address every 256 loops of course). My fault for translating that verbatim without analysing the consequences; a trap for young players!
Once fixed, that in turn revealed another bug where I'd transcribed an AND operation to an INC operation - a simple typo that was, thankfully, immediately discovered. So the sun/moon now continues smoothly throughout the 40 days and nights.
The third bug was due to the fact that I made no attempt to port the original sprite rendering routines, but rather attempted to write (more) efficient 6809 code. No point going into too much detail here, but the original code ends up adjusting the sprite width for non-byte aligned renderings, whereas my code has no need to do so. The problem is that the adjusted value is (also) used later in the code for wiping and blitting - so I had to store the adjusted value but use the original width within the rendering routine itself.
So given that I estimated there were 3 bugs to fix, that only leaves 3-3, err, 3 more by my reckoning. The auto-adjust near the arches still isn't working properly, there's still some (albeit much less) extraneous pixels appearing at the edges of sprites (I believe this is actually corruption of the sprite data, possibly during the flipping operation), and the sprite wiping appears to wipe larger areas than required, leaving occasional gaps in the background. Given today's efforts, it wouldn't surprise me if a couple more surface before I'm done.
That said, this really is the core of the game engine and once it's fully debugged the home stretch is relatively straightforward and any bugs that I add along the way should, for the most part, be immediately apparent.
I was going to release a pre-alpha demo shortly, comprising a much cut-down version with simple objects but no special objects or pick-up and/or drop, but I've decided now to instead press ahead in an attempt to have the game all-but-finished for demonstration (only) on cartridge at CocoFEST. It may lack some polish such as title screen and/or sound, but hopefully it'll be otherwise complete. This of course depends on me getting it finished in time, and also lining up the requisite hardware (programmable cartridge) and someone to show it off for me.
UPDATE: And another bug; jumping off the top of the screen has disastrous effects.
UPDATE #2: I've fixed another 2 bugs - and still have 3 left! Fixed the issue of auto-adjust on the arches, only to notice another issue when in the vicinity of arches. Fixed that, and now exiting screens is a little easier and appears to behave the same as the original.
UPDATE #3: Commenting out the sprite flip code eliminates all the extraneous pixels!
UPDATE #4: Found the bug causing both glitches and wipe issues! Almost perfect now!
The good news is that I've fixed three (3) bugs thus far.
One was interesting; the moon freezing on Day 02 for a minute or more turned out to be from a source I would never have guessed. The game has three (what I call) "seeds" used for randomising certain elements of the game, each having a different distribution. Seed #2 is simply incremented each time through the game loop, and drives the sun/moon moving across the frame.
Although the seed is only ever used (read) as an 8-bit value, the code does a 16-bit increment. On a Z80, that means the lower address - the one read using an 8-bit read - is incremented every loop. On the 6809 however, it's the higher address that is incremented every loop (and the lower address every 256 loops of course). My fault for translating that verbatim without analysing the consequences; a trap for young players!
Once fixed, that in turn revealed another bug where I'd transcribed an AND operation to an INC operation - a simple typo that was, thankfully, immediately discovered. So the sun/moon now continues smoothly throughout the 40 days and nights.
The third bug was due to the fact that I made no attempt to port the original sprite rendering routines, but rather attempted to write (more) efficient 6809 code. No point going into too much detail here, but the original code ends up adjusting the sprite width for non-byte aligned renderings, whereas my code has no need to do so. The problem is that the adjusted value is (also) used later in the code for wiping and blitting - so I had to store the adjusted value but use the original width within the rendering routine itself.
So given that I estimated there were 3 bugs to fix, that only leaves 3-3, err, 3 more by my reckoning. The auto-adjust near the arches still isn't working properly, there's still some (albeit much less) extraneous pixels appearing at the edges of sprites (I believe this is actually corruption of the sprite data, possibly during the flipping operation), and the sprite wiping appears to wipe larger areas than required, leaving occasional gaps in the background. Given today's efforts, it wouldn't surprise me if a couple more surface before I'm done.
That said, this really is the core of the game engine and once it's fully debugged the home stretch is relatively straightforward and any bugs that I add along the way should, for the most part, be immediately apparent.
I was going to release a pre-alpha demo shortly, comprising a much cut-down version with simple objects but no special objects or pick-up and/or drop, but I've decided now to instead press ahead in an attempt to have the game all-but-finished for demonstration (only) on cartridge at CocoFEST. It may lack some polish such as title screen and/or sound, but hopefully it'll be otherwise complete. This of course depends on me getting it finished in time, and also lining up the requisite hardware (programmable cartridge) and someone to show it off for me.
UPDATE: And another bug; jumping off the top of the screen has disastrous effects.
UPDATE #2: I've fixed another 2 bugs - and still have 3 left! Fixed the issue of auto-adjust on the arches, only to notice another issue when in the vicinity of arches. Fixed that, and now exiting screens is a little easier and appears to behave the same as the original.
UPDATE #3: Commenting out the sprite flip code eliminates all the extraneous pixels!
UPDATE #4: Found the bug causing both glitches and wipe issues! Almost perfect now!
Saturday, 12 March 2016
Farewell Fremont
It's my last night here before heading home, and although I didn't add much tonight, I look back at my first post whilst over here (29th Feb) and can't believe how much I've achieved on Knight Lore in just 2 weeks! Further proof that the most significant impediment to this hobby is time, i.e. Real Life getting in the way of porting games to 8-bit platforms. Spending sad, lonely nights in a hotel room eschewing sleep for coding 6809 assembler is the key to retro game development nirvana; the only drawback being that it is, well, sad and lonely.
I fixed the reincarnation problem and I've little choice now but to tackle the glitches. I've long noticed that the moon freezes in the middle of Day 02 - for a minute or so at least - and now another side-effect is that dying after this point also prevents Sabreman from reincarnating. This is actually a good thing, because it offers another angle to finding this bug. I would hazard a guess that there are currently three (3) bugs to be found and fixed before moving forward again.
These will have to wait until I'm back home now though, as tomorrow I'm packing up, doing a bit of shopping, visiting Nickel City in San Jose, then jumping on a plane for about 15 hrs (combined) of hell. I just hope the spell isn't broken when I get home and I can't find the time, the motivation, or the fixes for these bugs! Well, I don't seriously think motivation will be an issue, this has been a blast!
CocoFEST is coming up in late April and it would be fantastic if Knight Lore was available on cartridge by then. Two weeks ago I'd have declared it'd be no chance, but it's possible that the code at least will be ready. Whether the hardware is available in time, is another thing.
Signing off for now from Fremont, CA.
I fixed the reincarnation problem and I've little choice now but to tackle the glitches. I've long noticed that the moon freezes in the middle of Day 02 - for a minute or so at least - and now another side-effect is that dying after this point also prevents Sabreman from reincarnating. This is actually a good thing, because it offers another angle to finding this bug. I would hazard a guess that there are currently three (3) bugs to be found and fixed before moving forward again.
These will have to wait until I'm back home now though, as tomorrow I'm packing up, doing a bit of shopping, visiting Nickel City in San Jose, then jumping on a plane for about 15 hrs (combined) of hell. I just hope the spell isn't broken when I get home and I can't find the time, the motivation, or the fixes for these bugs! Well, I don't seriously think motivation will be an issue, this has been a blast!
CocoFEST is coming up in late April and it would be fantastic if Knight Lore was available on cartridge by then. Two weeks ago I'd have declared it'd be no chance, but it's possible that the code at least will be ready. Whether the hardware is available in time, is another thing.
Signing off for now from Fremont, CA.
Friday, 11 March 2016
Solid blocks and deadly spikes!
Some free time tonight - enough to finish the object collision/interaction code! Basically Sabreman walks around and is constrained by any objects he encounters. He can jump onto blocks, and dies when hitting spikes, for example. This is a major milestone, as all the physics and all the rendering is now complete - glitches and bugs not withstanding.
I decided to press on with the porting rather than get bogged down with searching for bugs which appear, at this stage, to be purely cosmetic. Having said that, tonight's effort has introduced a bug whereby Sabreman doesn't reappear correctly after dying - this is one bug I'll need to find before progressing any further. I shouldn't imagine it'll be too difficult to find.
The performance (speed) is still very encouraging.
Once I fix the reincarnation of Sabreman, I think it's time to fix the glitches. Then I can release a 'playable demo' that allows the player to walk around the map, interacting with a few simple objects. I may add some of the simpler animated objects, such as moving/collapsing blocks and bouncing balls, to give a better feel for what's in store in the full game.
 | ||
| Sabreman pushed the table, jumped onto it, then onto the top of the arch |
I decided to press on with the porting rather than get bogged down with searching for bugs which appear, at this stage, to be purely cosmetic. Having said that, tonight's effort has introduced a bug whereby Sabreman doesn't reappear correctly after dying - this is one bug I'll need to find before progressing any further. I shouldn't imagine it'll be too difficult to find.
The performance (speed) is still very encouraging.
Once I fix the reincarnation of Sabreman, I think it's time to fix the glitches. Then I can release a 'playable demo' that allows the player to walk around the map, interacting with a few simple objects. I may add some of the simpler animated objects, such as moving/collapsing blocks and bouncing balls, to give a better feel for what's in store in the full game.
Catching some (ordered) Z's
It turns out that flying interstate for the day is quite tiring and I fell asleep around 8:30pm last night, only to be woken at 5:30am by the alarm that I'd set for the morning before. So not a lot of Knight Lore work done, but some progress none-the-less.
I did manage to code the Z-order algorithm yesterday during my lunch break, and today during the same I debugged it.
I also ported the delay loop code verbatim from the ZX Spectrum and although it does produce more consistent results between screens, it still runs too fast on empty rooms. Overall the results are encouraging, and although there is still code to be added, I think the performance of the original game is within reach of the Coco3.
What remains includes jumping, object collision/interaction, pick-up/drop and a few details like handling player dying, end of game, etc. Finally of course is filling out all the stub routines for the sprite update handlers. If I had another week here I could probably finish it off before returning home.
The immediate task however is to find and fix the handful of glitches I have with the rendering. These glitches cause occasional extraneous pixels and/or wiping of small rectangular areas that shouldn't be wiped, or perhaps should be re-rendered. They might take some effort to track down, but the fixes should be trivial.
UPDATE: In between FPGA builds I've got Sabreman jumping. It required only a handful of lines to initiate the jumping; the rest is handled in the already-ported routine that moves the player.
I also took an audit of the outstanding code. Simply counting lines and comparing Z80 and 6809 listings suggest I'm about 60% done; that sounds about right, keeping in mind the most challenging code is well behind me now. I also listed the routines that are still remaining, and there's certainly nothing technically challenging in there. From here-on in it's just a matter of finding the time and cranking the handle.
When I started this, I thought how cool it would be to release a cartridge with all three filmation engine titles - Knight Lore, Alien 8 and Pentagram. The thought of porting all three to 6809 seemed terribly daunting at the time. Right now however, it is definitely something I would consider, depending on the level of interest in Knight Lore when it's eventually released.
I did manage to code the Z-order algorithm yesterday during my lunch break, and today during the same I debugged it.
 |
| Z-order implemented; contrast this with the previously-posted screen shot |
I also ported the delay loop code verbatim from the ZX Spectrum and although it does produce more consistent results between screens, it still runs too fast on empty rooms. Overall the results are encouraging, and although there is still code to be added, I think the performance of the original game is within reach of the Coco3.
What remains includes jumping, object collision/interaction, pick-up/drop and a few details like handling player dying, end of game, etc. Finally of course is filling out all the stub routines for the sprite update handlers. If I had another week here I could probably finish it off before returning home.
The immediate task however is to find and fix the handful of glitches I have with the rendering. These glitches cause occasional extraneous pixels and/or wiping of small rectangular areas that shouldn't be wiped, or perhaps should be re-rendered. They might take some effort to track down, but the fixes should be trivial.
UPDATE: In between FPGA builds I've got Sabreman jumping. It required only a handful of lines to initiate the jumping; the rest is handled in the already-ported routine that moves the player.
I also took an audit of the outstanding code. Simply counting lines and comparing Z80 and 6809 listings suggest I'm about 60% done; that sounds about right, keeping in mind the most challenging code is well behind me now. I also listed the routines that are still remaining, and there's certainly nothing technically challenging in there. From here-on in it's just a matter of finding the time and cranking the handle.
When I started this, I thought how cool it would be to release a cartridge with all three filmation engine titles - Knight Lore, Alien 8 and Pentagram. The thought of porting all three to 6809 seemed terribly daunting at the time. Right now however, it is definitely something I would consider, depending on the level of interest in Knight Lore when it's eventually released.
Wednesday, 9 March 2016
Faster rendering, now with added bugs
Only a quick update tonight as today I was asked to fly to Vegas tomorrow and so I'll have to get an early night tonight.
I realised overnight that there was one routine that I had inadvertently left incomplete; this was partly the reason that all objects had to be rendered every frame. The other reason - it transpires - was a bug in the routine that lists all the objects that are to be drawn. Once I had completed coding the former, and fixed the latter, the forced rendering of every object could be removed.
The good news is that objects tend to be redrawn (only) when they need to be, so the new routine isn't too far from the mark. The bad news is that the formerly occasional graphics glitch - extraneous pixels - is more frequent and far more prevalent now. And with the occasional flickering of objects when walking in front of/behind them, it's clear that I have a couple of bugs to iron out.
The new code also gives me a better insight into the performance of the Coco3 port. Empty rooms are blindingly fast whilst populated rooms are quite a bit slower, perhaps a little too slow considering there's still a bit of code to add (collision-detection and Z-ordering) for each frame. Another interesting observation was that walking in front of/behind objects slows the frame rate considerably, which I've never noticed on the original. However that could simply be due to the fact that I haven't finished porting all the code yet.
The original code tunes the frame rate based on the number of objects wiped and objects rendered each frame. Regardless, the game does slow down appreciably on busy screens, so I'm not concerned at all if the port does the same. I'll be happy if the Coco3 isn't - at its slowest - any slower than the original.
I'm undecided whether I'll continue with the Z-ordering, which effectively completes all the rendering code, or stop and fix the graphics glitches first. It's possible that the Z-order code will only complicate matters when it comes to debugging, but I should also be able to disable that routine with a simple .define. Choices, choices...
I realised overnight that there was one routine that I had inadvertently left incomplete; this was partly the reason that all objects had to be rendered every frame. The other reason - it transpires - was a bug in the routine that lists all the objects that are to be drawn. Once I had completed coding the former, and fixed the latter, the forced rendering of every object could be removed.
The good news is that objects tend to be redrawn (only) when they need to be, so the new routine isn't too far from the mark. The bad news is that the formerly occasional graphics glitch - extraneous pixels - is more frequent and far more prevalent now. And with the occasional flickering of objects when walking in front of/behind them, it's clear that I have a couple of bugs to iron out.
The new code also gives me a better insight into the performance of the Coco3 port. Empty rooms are blindingly fast whilst populated rooms are quite a bit slower, perhaps a little too slow considering there's still a bit of code to add (collision-detection and Z-ordering) for each frame. Another interesting observation was that walking in front of/behind objects slows the frame rate considerably, which I've never noticed on the original. However that could simply be due to the fact that I haven't finished porting all the code yet.
The original code tunes the frame rate based on the number of objects wiped and objects rendered each frame. Regardless, the game does slow down appreciably on busy screens, so I'm not concerned at all if the port does the same. I'll be happy if the Coco3 isn't - at its slowest - any slower than the original.
I'm undecided whether I'll continue with the Z-ordering, which effectively completes all the rendering code, or stop and fix the graphics glitches first. It's possible that the Z-order code will only complicate matters when it comes to debugging, but I should also be able to disable that routine with a simple .define. Choices, choices...
Tuesday, 8 March 2016
Foreground interest
Not a lot of time to code tonight, but I fixed the location table parsing for foreground objects, added a filter for showing only selected objects, and added the pause functionality.
Thought I had a bug in my location table parsing for a while; when a dump of the graphic objects table checked against the C version I was stumped until I realised that I hadn't added the sprite update handlers for the new objects, most of which had significant (static) pixel adjustments.
There's enough being rendered now for me to implement and test Z-order rendering and requisite support routines. It's mostly a case of instruction-by-instruction translation of Z80 to 6809. I'm not expecting anything too nasty to crop up in the process. Hopefully I can have it knocked over in a single session, perhaps tomorrow night.
As an experiment I turned off the build option to render every object every frame, and there's a significant difference in rendering performance between rooms that are mostly empty, and rooms that have a few objects. Mostly empty rooms are way too fast, however those with a few objects are a little slower than I'd hoped. There may be other factors at play here; I'll reserve judgement until the rendering routines are complete, but I suspect there's a bit of optimisation that will need to be done.
 |
| Some blocks and some spikes added to the mix |
Thought I had a bug in my location table parsing for a while; when a dump of the graphic objects table checked against the C version I was stumped until I realised that I hadn't added the sprite update handlers for the new objects, most of which had significant (static) pixel adjustments.
There's enough being rendered now for me to implement and test Z-order rendering and requisite support routines. It's mostly a case of instruction-by-instruction translation of Z80 to 6809. I'm not expecting anything too nasty to crop up in the process. Hopefully I can have it knocked over in a single session, perhaps tomorrow night.
As an experiment I turned off the build option to render every object every frame, and there's a significant difference in rendering performance between rooms that are mostly empty, and rooms that have a few objects. Mostly empty rooms are way too fast, however those with a few objects are a little slower than I'd hoped. There may be other factors at play here; I'll reserve judgement until the rendering routines are complete, but I suspect there's a bit of optimisation that will need to be done.
Monday, 7 March 2016
A change of scenery
A few more hours of coding; the walking and animation are fixed and you can move from room-to-room now. There's a glitch or two but for the most part, it's working.
I decided to add a splash of colour. Although the initial version will be in monochrome - at least until I gauge the performance on the Coco3 - much like the BBC version I change the pixel colour to that of the main rendering on the ZX Spectrum version.
Speaking of performance; right now it's still rendering every object every frame. I need to go back and review exactly what's missing, but aside from Z-order it's almost all there now. As a result, it's a little slower than the ZX Spectrum version as-is, but that's to be expected as it's probably rendering 4-5 times as many objects as it needs to.
I might add a few simple foreground objects next, which requires finishing the routine that parses the location table, so that I can complete the rendering (Z-order) logic. Then I'll have to sort out the glitches. I still can't get over the progress I've made.
UPDATE: Foreground objects now appear, albeit in the wrong place & number. Just need to debug the routine that's parsing the location data, and it should be sorted. Since I don't want all the objects to appear right now, I'll actually have to patch the code to only show select objects.
 |
| You can have this particular room in any colour you want, as long as it's blue. |
I decided to add a splash of colour. Although the initial version will be in monochrome - at least until I gauge the performance on the Coco3 - much like the BBC version I change the pixel colour to that of the main rendering on the ZX Spectrum version.
Speaking of performance; right now it's still rendering every object every frame. I need to go back and review exactly what's missing, but aside from Z-order it's almost all there now. As a result, it's a little slower than the ZX Spectrum version as-is, but that's to be expected as it's probably rendering 4-5 times as many objects as it needs to.
I might add a few simple foreground objects next, which requires finishing the routine that parses the location table, so that I can complete the rendering (Z-order) logic. Then I'll have to sort out the glitches. I still can't get over the progress I've made.
UPDATE: Foreground objects now appear, albeit in the wrong place & number. Just need to debug the routine that's parsing the location data, and it should be sorted. Since I don't want all the objects to appear right now, I'll actually have to patch the code to only show select objects.
Sunday, 6 March 2016
A wild Sabreman appears!
Got a few hours in tonight on Knight Lore. As I mentioned, there's a decent amount of code to port atm with very little to show for it, and doing half the job doesn't produce anything useful.
Still working towards getting the player moving around, and tonight I coded the routines that wipe the sprites from the screen (video memory buffer). That appears to be working now, and the cloud of sparkles disappears to leave Sabreman standing in the centre of the room.
He even looks around randomly. Moving is broken atm, however I can move forward a few steps if I also turn at the same time. His legs should be animated - in fact they were at some stage - but they're not right now. It's probably all related.
Once I get Sabreman walking again, I'll finish the out-of-bounds code so that he can walk around a room and be confined by the walls. Then it's back to the arch code, and handling changing screens. I'd like to get it to a point where I can walk around the entire map, devoid of foreground objects. Then I'll add a few of the simpler static objects, eg. blocks and rocks, and finish off the Z-order logic. From there-on in, it's a matter of cranking the handle on the sprite update routines until they're all done!
Still working towards getting the player moving around, and tonight I coded the routines that wipe the sprites from the screen (video memory buffer). That appears to be working now, and the cloud of sparkles disappears to leave Sabreman standing in the centre of the room.
 |
| Sabreman makes an appearance |
He even looks around randomly. Moving is broken atm, however I can move forward a few steps if I also turn at the same time. His legs should be animated - in fact they were at some stage - but they're not right now. It's probably all related.
Once I get Sabreman walking again, I'll finish the out-of-bounds code so that he can walk around a room and be confined by the walls. Then it's back to the arch code, and handling changing screens. I'd like to get it to a point where I can walk around the entire map, devoid of foreground objects. Then I'll add a few of the simpler static objects, eg. blocks and rocks, and finish off the Z-order logic. From there-on in, it's a matter of cranking the handle on the sprite update routines until they're all done!
Field trip!
I made good on my threat and dragged my business partner to the Computer History Museum in Mountain View, CA. Was also interesting to drive past all the Silicon Valley companies on the way there - Motorola, Microchip, Google, NASA Ames Research, Seagate to name but a few.
It would be fair to say that the focus was on the earlier developments, and that the 80's home computer isn't given as much real estate as I'd expected going in. Having said that, I did snap a few specimens related to Knight Lore, although they were sadly sitting cold on the shelves with little more than a few sentences printed on a card.
Of course all of my ports are based on the original ZX Spectrum version. I later added the CPC graphics to the C port from the Amstrad CPC version without changing the underlying code.
There was also an Amiga 1000 - the original Amiga model - to which I am also porting Knight Lore. Sadly though, there was no Coco to be found, although it did rate a mention on the card for the Dragon 32, a UK-based Coco (1) clone.
It would be fair to say that the focus was on the earlier developments, and that the 80's home computer isn't given as much real estate as I'd expected going in. Having said that, I did snap a few specimens related to Knight Lore, although they were sadly sitting cold on the shelves with little more than a few sentences printed on a card.
 |
| The Sinclair ZX Spectrum, for which Knight Lore was originally developed. |
 | ||
| Knight Lore received enhanced two-tone graphics for its port to the Amstrad CPC 464 |
Saturday, 5 March 2016
No walk in the park.
I'm currently working on getting the player walking so that I can move from room-to-room to test all elements of the game. There's quite a bit of code required, including sprite update handlers for multiple sprites, plus collision-detection (optional at this point) and out-of-bounds calculations (some of which are crucial). These routines are used for any objects which do, or can be, moved. By the end of tonight's session, I can actually turn and move, although there's still more code to port and some bugs to iron out.
One routine in particular, which calls a bunch of lower routines, makes heavy use of the Z80 registers. For this purpose I've defined an offset into the Direct Page for each Z80 8-bit register. Outside this branch of code, however, I've seldom had to resort to using them.
And tonight I also reviewed some earlier code and found a couple of instances where I could replace 2 instructions with a single instruction using Indirect Addressing. Another tick for the 6809!
There's still a bit of code to port for the movement, plus I need to implement sprite wiping, and then implement the logic for exiting and entering screens. Until then, there won't be much to show for my efforts.
It's the weekend now and I should probably take the opportunity to explore Fremont and its surrounds, rather than sit in front of my laptop and code 6809 assembler. The Computer History Museum in Mountain View is on the cards, and I do believe they have a Coco on display! I should donate a Knight Lore cartridge to them when I'm done, just to confuse ZX Spectum enthusiasts! ;)
One routine in particular, which calls a bunch of lower routines, makes heavy use of the Z80 registers. For this purpose I've defined an offset into the Direct Page for each Z80 8-bit register. Outside this branch of code, however, I've seldom had to resort to using them.
And tonight I also reviewed some earlier code and found a couple of instances where I could replace 2 instructions with a single instruction using Indirect Addressing. Another tick for the 6809!
There's still a bit of code to port for the movement, plus I need to implement sprite wiping, and then implement the logic for exiting and entering screens. Until then, there won't be much to show for my efforts.
It's the weekend now and I should probably take the opportunity to explore Fremont and its surrounds, rather than sit in front of my laptop and code 6809 assembler. The Computer History Museum in Mountain View is on the cards, and I do believe they have a Coco on display! I should donate a Knight Lore cartridge to them when I'm done, just to confuse ZX Spectum enthusiasts! ;)
Friday, 4 March 2016
It's all coming together
With the sprite update (stub) handlers all in place (cut & paste from the Z80 source) all I needed to do was fill in the handlers for the background objects; walls and arches. The arches are actually reasonably complicated, because they include calculations for adjusting objects that are 'close'. This enables you to, for example, walk through them without requiring pixel-perfect alignment.
With most, but not quite all, the logic in place for the arches, and the static adjustments for the walls, it all looks pretty nice now!
Taking a step back for a moment, I think it would be fair to say that much of the framework of the game is actually complete now! A large percentage of the code that remains consists of the sprite update handlers. After that, there's some maths to do collision-detection/object interaction and Z-order rendering of course, but nothing that requires more than what is effectively CPU instruction translation.
As I mentioned in my previous post I can take this one of two ways from here, but I think I'll opt for completing the maths (ie. the framework) so that I can finish off by simply adding sprite update handlers one-by-one. But first I need to (also) extract the foreground objects from the location table, and then get the player walking around so I can change rooms.
UPDATE: The player appears amidst animated sparkles.
 |
| Rendering of background objects now spot-on |
With most, but not quite all, the logic in place for the arches, and the static adjustments for the walls, it all looks pretty nice now!
Taking a step back for a moment, I think it would be fair to say that much of the framework of the game is actually complete now! A large percentage of the code that remains consists of the sprite update handlers. After that, there's some maths to do collision-detection/object interaction and Z-order rendering of course, but nothing that requires more than what is effectively CPU instruction translation.
As I mentioned in my previous post I can take this one of two ways from here, but I think I'll opt for completing the maths (ie. the framework) so that I can finish off by simply adding sprite update handlers one-by-one. But first I need to (also) extract the foreground objects from the location table, and then get the player walking around so I can change rooms.
UPDATE: The player appears amidst animated sparkles.
Thursday, 3 March 2016
Room for improvement
Far from being the daunting and tedious task I thought it was going to be, I'm really enjoying the 6809 port to the Coco3. My rate of progress has far exceeded what I'd expected going into this, but I think it's more a testament to the quality of the original code than anything of my doing.
Without further ado, here's what I managed to concoct this evening.
Firstly, the sun/moon animates across the frame and the days increment. Only the background objects (which incidentally includes the player) are rendered and there's actually two more steps until they're placed in exactly the right position. First, a lot of objects have static X,Y adjustments applied during the object update routines, which are currently not implemented. Secondly, the sprite routines still only render at byte-aligned addresses. Regardless, the above screen shot suggests that things are looking pretty good otherwise.
Next task is to implement pixel-granularity sprite rendering. The sun/moon should then move smoothly across the frame and the background objects will be closer to their correct positions. I've already constructed the requisite look-up tables, just need to enhance the rendering routine. I've got a little more time tonight so I might squeeze in an update.
UPDATE: A bit of a late night but rendering is now pixel-granularity!
The question now is, how to proceed from here. I think I'll add the plumbing for the object update routines, only so I can add the simple static X,Y adjustments for the background objects. In the next screen shot, all objects should at least be at their correct pixel coordinates.
Without further ado, here's what I managed to concoct this evening.
 |
| Background objects rendered approximately correctly |
Firstly, the sun/moon animates across the frame and the days increment. Only the background objects (which incidentally includes the player) are rendered and there's actually two more steps until they're placed in exactly the right position. First, a lot of objects have static X,Y adjustments applied during the object update routines, which are currently not implemented. Secondly, the sprite routines still only render at byte-aligned addresses. Regardless, the above screen shot suggests that things are looking pretty good otherwise.
Next task is to implement pixel-granularity sprite rendering. The sun/moon should then move smoothly across the frame and the background objects will be closer to their correct positions. I've already constructed the requisite look-up tables, just need to enhance the rendering routine. I've got a little more time tonight so I might squeeze in an update.
UPDATE: A bit of a late night but rendering is now pixel-granularity!
 |
| Look closely, it is better than the above screen shot |
Wednesday, 2 March 2016
Flippin' sprites
I continue to surprise myself with my progress on the Coco3 port; hope I don't jinx myself now...
I started with a rudimentary sprite rendering routine, and then added v-flip, then h-flip. What's missing is the ability to render at non-byte-aligned pixels. But as-is that's sufficient to render the main menu border and the panel, sun/moon and frame correctly.
After displaying the panel, the code unfortunately goes into la-la land, otherwise the days should be ticking over as they were before. Haven't had a chance to track it down, but it'll be either a register not saved or a stub routine not terminating properly.
I've decided to tackle this port a little differently from the C port; this time 'round I'm going to complete all the rendering logic - including Z-order - before the bulk of the object handlers. So everything should look perfect as I'm adding objects to the game.
Once I've got the sun animating (needs the blit routines) and the days ticking over again, I'll start on the rendering of the background objects which are already built from the location data. In the process I'll add the non-aligned rendering logic as well. So next screen shot should include an empty room.
I discovered a short-cut this evening when running the game in MESS. After loading the data, which takes a number of seconds even in unthrottled mode, I saved the state of the Coco3 emulation. So now all I need to do is run MESS, press <F7>, <1> and then load the code binary. Shaves a bunch of keystrokes and precious seconds off my development-test cycle!
UPDATE: Wow - the ZX Spectrum listing is about 7K lines of Z80 code; my Coco3 port is just under 2K lines of code, and the number of instructions per routine is roughly the same, if not slightly less on the 6809. That tends to suggest I've coded between 20-25% of the game thus far! That sounds like way too much for a few days work... but I just can't see where my arithmetic is wrong?!?
I started with a rudimentary sprite rendering routine, and then added v-flip, then h-flip. What's missing is the ability to render at non-byte-aligned pixels. But as-is that's sufficient to render the main menu border and the panel, sun/moon and frame correctly.
 |
| Main Menu complete with border sprites |
 |
| Panel display |
After displaying the panel, the code unfortunately goes into la-la land, otherwise the days should be ticking over as they were before. Haven't had a chance to track it down, but it'll be either a register not saved or a stub routine not terminating properly.
I've decided to tackle this port a little differently from the C port; this time 'round I'm going to complete all the rendering logic - including Z-order - before the bulk of the object handlers. So everything should look perfect as I'm adding objects to the game.
Once I've got the sun animating (needs the blit routines) and the days ticking over again, I'll start on the rendering of the background objects which are already built from the location data. In the process I'll add the non-aligned rendering logic as well. So next screen shot should include an empty room.
I discovered a short-cut this evening when running the game in MESS. After loading the data, which takes a number of seconds even in unthrottled mode, I saved the state of the Coco3 emulation. So now all I need to do is run MESS, press <F7>, <1> and then load the code binary. Shaves a bunch of keystrokes and precious seconds off my development-test cycle!
UPDATE: Wow - the ZX Spectrum listing is about 7K lines of Z80 code; my Coco3 port is just under 2K lines of code, and the number of instructions per routine is roughly the same, if not slightly less on the 6809. That tends to suggest I've coded between 20-25% of the game thus far! That sounds like way too much for a few days work... but I just can't see where my arithmetic is wrong?!?
Tuesday, 1 March 2016
Some background information
This time 'round I've wasted no time getting into the project whilst on business travel. I even had the monster laptop out at the airport during what turned out to be a 5hr lay-over to do some porting. And this afternoon, in my room whilst trying to fight off sleep so I can get myself synced to the time zone, I've done some more.
The days tick over and after 40 days the Game Over screen is displayed, albeit incomplete. Pressing any key will then return you to the main menu. That was low hanging fruit because the text display routines were already done.
From here I can go two ways. I can start with the sprite rendering routines and display the menu border and the panel. Or I can press ahead and start parsing the location data so that the sprite routines can be used to render a room. At least for this port I know exactly which routines are key to the rendering process, and which are more cosmetic and can be left for later.
For reasons even I'm not completely clear on, I've chosen to go the latter route. The start location is randomised and chosen, and the location data is parsed to build the graphical object table from the background objects. Next step is to extend that routine to include the foreground objects.
Either way, it won't be long before I can add sprite rendering and the blit routines and have them show something interesting. I'll start with a relatively brain-dead, quick 'n' dirty routine (eg.no flip, byte-aligned only) and build on it from there. The beauty is that the sprite rendering can be enhanced and optimised at any time without affecting other parts of the code.
I have to admit that I haven't found the process as painful as I first feared - at least not yet. Whilst I'm using the Z80 code as a rough guide, I'm striving to do things the 6809 way and as a result haven't actually run into too many instances where I've run out of registers trying to mimic the behaviour of the Z80 code! Plenty of flicking through Rodney Zak's Programming the 6809 book though... As expected, some things are a little easier in Z80, and some easier in 6809. On the balance, I'm finding I (still) prefer the 6809 - something I discovered unexpectedly when I was attempting to port Lode Runner to both Z80 and 6809 simultaneously.
I'm sufficiently buoyed by my success thus far that I don't believe the task is quite as daunting as I imagined, and I may well have it finished long before I initially predicted. It's certainly encouraging to be able to page up/down the file and see the finite number of routine stubs that I need to flesh out.
The days tick over and after 40 days the Game Over screen is displayed, albeit incomplete. Pressing any key will then return you to the main menu. That was low hanging fruit because the text display routines were already done.
 |
| Boring, but everyone wants to see screen shots |
From here I can go two ways. I can start with the sprite rendering routines and display the menu border and the panel. Or I can press ahead and start parsing the location data so that the sprite routines can be used to render a room. At least for this port I know exactly which routines are key to the rendering process, and which are more cosmetic and can be left for later.
For reasons even I'm not completely clear on, I've chosen to go the latter route. The start location is randomised and chosen, and the location data is parsed to build the graphical object table from the background objects. Next step is to extend that routine to include the foreground objects.
Either way, it won't be long before I can add sprite rendering and the blit routines and have them show something interesting. I'll start with a relatively brain-dead, quick 'n' dirty routine (eg.no flip, byte-aligned only) and build on it from there. The beauty is that the sprite rendering can be enhanced and optimised at any time without affecting other parts of the code.
I have to admit that I haven't found the process as painful as I first feared - at least not yet. Whilst I'm using the Z80 code as a rough guide, I'm striving to do things the 6809 way and as a result haven't actually run into too many instances where I've run out of registers trying to mimic the behaviour of the Z80 code! Plenty of flicking through Rodney Zak's Programming the 6809 book though... As expected, some things are a little easier in Z80, and some easier in 6809. On the balance, I'm finding I (still) prefer the 6809 - something I discovered unexpectedly when I was attempting to port Lode Runner to both Z80 and 6809 simultaneously.
I'm sufficiently buoyed by my success thus far that I don't believe the task is quite as daunting as I imagined, and I may well have it finished long before I initially predicted. It's certainly encouraging to be able to page up/down the file and see the finite number of routine stubs that I need to flesh out.
Subscribe to:
Posts (Atom)