Each time I return to a platform there's the ramp-up time where I re-learn what I knew before. And Knight Lore on the Coco3 is no different. It has been a few years since Lode Runner after all... but then I also find I learn something new as well.
Today's exercise was getting 20KB of data loaded into memory from disk, preferably independently of the main executable - something I did for Lode Runner. In the end it's almost trivial, but when you can't recall how to do it, and then you encounter some corruption along the way, it chews up your spare time. In the end it was all resolved and I learned something new about the Coco3.
The data - location and graphics data in this case - resides in a single .ASM file generated by a custom utility from a memory dump of Knight Lore running in MESS. The same utility I used to generate all the C data structures and arrays. This .ASM file is then .included in a very small file which is then built and LOADM'd from BASIC before loading and running the main executable.
For the curious, here's that file
.include "coco3.asm"
; $2000,$4000,$6000
.org MMUTSK1+1
.db DATA_PG1, DATA_PG2, DATA_PG3
.org 0x2000
.include "kl_dat.asm"
; $2000,$4000,$6000
.org MMUTSK1+1
.db 0x39, 0x3a, 0x3b
This loads directly into the GIME's MMU registers on-the-fly, allowing the data to be loaded into pages of 128KB memory not mapped by default. And lastly it restores the default page mapping. It doesn't even have to be executed, simply loading it does the trick. When the main executable runs, it simply re-maps the pages into memory and the data magically appears.
Friday, 26 February 2016
Thursday, 25 February 2016
Turning the first sod on the Coco3
In preparation for my work trip, more than anything else, I decided to set up the toolchain and a template project for the Coco3 port of Knight Lore.
I started with my Coco3 initialisation code from Lode Runner (most recently used to display the ZX Spectrum Knight Lore, Alien 8 and Pentagram title screens on the Coco3), and added all the labelled addresses and routines from the original disassembly, with appropriate RTS/BRA instructions added for the most part. I then simply copied-and-pasted the variables from the Z80 listing - a benefit of using the same assembler family. The result is a 6809 .ASM file that contains all the variables and stub routines of the original, and assembles and runs.
I couldn't stop there of course and started coding the initialisation and main routines, including the main menu display and requisite font display routines.
Now I only have to flesh out a few routines and it's all done - right!?!
Of course the challenge of translating Z80 to 6809 is already at the forefront of the process, and it's fair to say that the code thus far - in stark contrast to the Lode Runner port - bares little resemblance to the Z80 original. I suspect that will be par for the course on this project, and will no doubt bolster my 6809 coding skills. I just hope I don't get to the end of the port wanting to re-write the first half!
Unfortunately there's a significant amount of coding to be done before anything else gets displayed. However I do now know which routines are crucial in getting the correct display, and which ones can be omitted for the purposes of seeing something.
I started with my Coco3 initialisation code from Lode Runner (most recently used to display the ZX Spectrum Knight Lore, Alien 8 and Pentagram title screens on the Coco3), and added all the labelled addresses and routines from the original disassembly, with appropriate RTS/BRA instructions added for the most part. I then simply copied-and-pasted the variables from the Z80 listing - a benefit of using the same assembler family. The result is a 6809 .ASM file that contains all the variables and stub routines of the original, and assembles and runs.
I couldn't stop there of course and started coding the initialisation and main routines, including the main menu display and requisite font display routines.
 |
| Knight Lore for the Coco 3 - Main Menu |
Now I only have to flesh out a few routines and it's all done - right!?!
Of course the challenge of translating Z80 to 6809 is already at the forefront of the process, and it's fair to say that the code thus far - in stark contrast to the Lode Runner port - bares little resemblance to the Z80 original. I suspect that will be par for the course on this project, and will no doubt bolster my 6809 coding skills. I just hope I don't get to the end of the port wanting to re-write the first half!
Unfortunately there's a significant amount of coding to be done before anything else gets displayed. However I do now know which routines are crucial in getting the correct display, and which ones can be omitted for the purposes of seeing something.
Wednesday, 24 February 2016
More bugs and back to the Amiga
I've completed the pickup/drop hardware sprite logic and so Neo Geo is now on par with the other ports, except for the Z-order issue.
In the process of testing I found another bug in my Knight Lore core C implementation; dropping objects sometimes causes those objects to disappear. I've added this to the to-fix list along with a couple of other bugs I've seen infrequently; one room always kills you when you first walk into it and walking into a room from a raised arch will leave you suspended in mid-air.
But for now I'm going to return to the Amiga port and get CPC graphics working. Once that's complete I should only have the above-mentioned core issues to resolve, which will of course affect all ports. I've spent far too long on this aspect of the project and really want to put the C ports to bed - make the ports playable and release the source before moving on to the original goal of this whole project!
This weekend I'm off the the US again for two weeks for work. That's another two weeks of lonely nights in a hotel room, and although last trip I didn't get much done on the project, the novelty of it all has definitely worn off and I'll make a concerted effort this time 'round.
To this end I'll be making sure my laptop has all the Coco 3 technical documentation, development toolchains and emulation environments that I'll need for the rather daunting task that lays ahead. I still don't have a feel for how I'll mirror the heavy use of the Z80 IX & IY registers on the 6809, but I'm sure I'll work out something.
Phase one will be glorious monochrome, to get an idea of how the 1.89MHz 6809 is going to handle what was being done by a 3.5MHz Z80. I'm sure it'll compare favourably, especially given the fact that the Coco 3 doesn't have the issue of video memory contention like the ZX Spectrum. Hopefully there's enough headroom for a more colourful version down the track!?! If not, it's not going to be any worse than the BBC Micro port! ;)
UPDATE: CPC graphics on the Amiga. Not as painful as I first feared. Funnily enough I had exactly the same bug as the Neo Geo port, in that the orange rooms were actually red. Of course I couldn't for the life of me recall what the issue was for at least 5 minutes - then it came to me.
Still a few palette issues to sort as the palette must be programmed on-the-fly, unlike the PC and Neo Geo ports. However I'll likely back-port the Amiga palette changes to the PC as most retro ports won't be in 256-colour mode.
UPDATE#2: Fixed the remaining palette issues on the Amiga. The border colour for the main menu and game over message screens will never be correct when running CPC graphics, as the CPC sprite routines only support 4 colours. Not exactly a deal-breaker...
In the process of testing I found another bug in my Knight Lore core C implementation; dropping objects sometimes causes those objects to disappear. I've added this to the to-fix list along with a couple of other bugs I've seen infrequently; one room always kills you when you first walk into it and walking into a room from a raised arch will leave you suspended in mid-air.
But for now I'm going to return to the Amiga port and get CPC graphics working. Once that's complete I should only have the above-mentioned core issues to resolve, which will of course affect all ports. I've spent far too long on this aspect of the project and really want to put the C ports to bed - make the ports playable and release the source before moving on to the original goal of this whole project!
This weekend I'm off the the US again for two weeks for work. That's another two weeks of lonely nights in a hotel room, and although last trip I didn't get much done on the project, the novelty of it all has definitely worn off and I'll make a concerted effort this time 'round.
To this end I'll be making sure my laptop has all the Coco 3 technical documentation, development toolchains and emulation environments that I'll need for the rather daunting task that lays ahead. I still don't have a feel for how I'll mirror the heavy use of the Z80 IX & IY registers on the 6809, but I'm sure I'll work out something.
Phase one will be glorious monochrome, to get an idea of how the 1.89MHz 6809 is going to handle what was being done by a 3.5MHz Z80. I'm sure it'll compare favourably, especially given the fact that the Coco 3 doesn't have the issue of video memory contention like the ZX Spectrum. Hopefully there's enough headroom for a more colourful version down the track!?! If not, it's not going to be any worse than the BBC Micro port! ;)
UPDATE: CPC graphics on the Amiga. Not as painful as I first feared. Funnily enough I had exactly the same bug as the Neo Geo port, in that the orange rooms were actually red. Of course I couldn't for the life of me recall what the issue was for at least 5 minutes - then it came to me.
 |
| CPC graphics mode on the Amiga |
Still a few palette issues to sort as the palette must be programmed on-the-fly, unlike the PC and Neo Geo ports. However I'll likely back-port the Amiga palette changes to the PC as most retro ports won't be in 256-colour mode.
UPDATE#2: Fixed the remaining palette issues on the Amiga. The border colour for the main menu and game over message screens will never be correct when running CPC graphics, as the CPC sprite routines only support 4 colours. Not exactly a deal-breaker...
Tuesday, 23 February 2016
Getting the colours right
Again, Real Life has been putting a serious dent into my spare time but at lunchtime today I finally managed to get the palette right on the Neo Geo for both ZX Spectrum and CPC graphics modes.
It's actually been quite tricky and I've gone back to the drawing board several times in several areas over the last week or so. In fact I've had to regenerate all the tiles (sprites) and FIX layer graphics, including the panel - some several times over - as I've juggled the palette.
The panel is now generated from the CPC graphics, which includes a larger mask around the frame so that the sun/moon don't show either end without further trickery.
The challenge has not been only supporting both ZX Spectrum and CPC colours, but supporting them both at the same time, since the main menu and end-of-game screens are all from the ZX version, with ZX palette - that's half the FIX layer palette gone!
And a fact that didn't click earlier when it should've - the CPC graphics support 4 colours plus transparency, in 2 bits. And here is where the mystery extra byte in the sprite data comes into play! The CPC sprite rendering routine is a mess of lookup tables and self-modifying code, but what I've managed to deduce is that the 3rd byte is a flag that denotes colour 1 should actually be rendered as colour 3, which is otherwise used as the mask colour and normally rendered black. So on the Neo Geo, I've had to duplicate and modify the palette for these sprites.
And as I sit here typing this up, I've just realised there could be a better way to do it on the Neo Geo... oh well, I'm not changing it now.
The idea was always to keep code that differentiated between ZX and CPC graphics to a minimum to keep the code tidy and easy to maintain; I've been fairly successful by keeping the palettes somewhat compatible.
And just because I think this blog needs more eye candy...
And I think I will add the CPC title screen, as ordinary as it is, just as a visual indication of which version you're about to play!
UPDATE: And now I have...
That's it for the Neo Geo version; just need to go back and fix the game play issues related to having no .data segment (should be tedious but trivial) and of course the sprite Z-ordering.
UPDATE #2: Neo Geo now copies what would be in the .data segment into RAM - as a result it now has special objects that can be picked-up and dropped. I still need to add hardware sprite handling logic to this aspect of it, but game play is almost on par with the other ports now.
 |
| One of 4 room palettes of the CPC graphics mode (Neo Geo) |
It's actually been quite tricky and I've gone back to the drawing board several times in several areas over the last week or so. In fact I've had to regenerate all the tiles (sprites) and FIX layer graphics, including the panel - some several times over - as I've juggled the palette.
The panel is now generated from the CPC graphics, which includes a larger mask around the frame so that the sun/moon don't show either end without further trickery.
The challenge has not been only supporting both ZX Spectrum and CPC colours, but supporting them both at the same time, since the main menu and end-of-game screens are all from the ZX version, with ZX palette - that's half the FIX layer palette gone!
And a fact that didn't click earlier when it should've - the CPC graphics support 4 colours plus transparency, in 2 bits. And here is where the mystery extra byte in the sprite data comes into play! The CPC sprite rendering routine is a mess of lookup tables and self-modifying code, but what I've managed to deduce is that the 3rd byte is a flag that denotes colour 1 should actually be rendered as colour 3, which is otherwise used as the mask colour and normally rendered black. So on the Neo Geo, I've had to duplicate and modify the palette for these sprites.
And as I sit here typing this up, I've just realised there could be a better way to do it on the Neo Geo... oh well, I'm not changing it now.
The idea was always to keep code that differentiated between ZX and CPC graphics to a minimum to keep the code tidy and easy to maintain; I've been fairly successful by keeping the palettes somewhat compatible.
And just because I think this blog needs more eye candy...
 |
| The CPC orange theme. Because of a bug I didn't get to see this for some time |
And I think I will add the CPC title screen, as ordinary as it is, just as a visual indication of which version you're about to play!
UPDATE: And now I have...
 |
| The CPC title screen on the Neo Geo |
That's it for the Neo Geo version; just need to go back and fix the game play issues related to having no .data segment (should be tedious but trivial) and of course the sprite Z-ordering.
UPDATE #2: Neo Geo now copies what would be in the .data segment into RAM - as a result it now has special objects that can be picked-up and dropped. I still need to add hardware sprite handling logic to this aspect of it, but game play is almost on par with the other ports now.
Saturday, 20 February 2016
CPC on the Neo Geo
Real Life has been preventing me from doing much on Knight Lore over the last few days but today I managed to get the CPC graphics converted across to the Neo Geo and also set up the palette.
I still need to tweak the palette for the panel display, which is a juggling exercise on the FIX layer palette, but it's almost there. In the above, of the panel portion of the display, only the scrolls are the correct colour.
Looking pretty nice... just need to update the Amiga port for CPC graphics rendering.
 |
| CPC graphics on the Neo Geo |
I still need to tweak the palette for the panel display, which is a juggling exercise on the FIX layer palette, but it's almost there. In the above, of the panel portion of the display, only the scrolls are the correct colour.
Looking pretty nice... just need to update the Amiga port for CPC graphics rendering.
Wednesday, 17 February 2016
Not spritely enough!
This morning I started preparation on the Neo Geo port to support CPC graphics. Whilst enhancing my graphics conversion tool for the Neo Geo, I realised that I'd run out of sprites on the cartridge!
To develop/run a Neo Geo game under MAME, you need to hijack an existing game. That involves taking the original cartridge ROM images for a specific game, replacing select files (68K program code, sprites and FIX layer graphics) with your own content, and running under the original name.
The project template I originally used for my Donkey Kong port (WIP) and subsequently for Lode Runner and now Knight Lore was based on the Puzzle De Pon cartridge (GUID 202). With a single pair of sprite ROM images, that's sufficient for 16,384 sprite tiles. Given that the ZX version of Knight Lore has 12,032 you can see how I need more space to support the CPC graphics.
Looking through the MAME driver source code for the 'minimal' cartridge with twice the sprite ROM image size, I discovered a handful of candidates. The extra criteria was no fancy bank switching or protection schemes on the cartridge. Fortunately the first candidate, Legend Of Success Joe (GUID 029), fit the bill. I've simply chosen to ignore the fact that this cartridge is notorious for being arguably the worst game ever released on the Neo Geo.
In the process of switching the 'host' cartridge, I took the opportunity to clean up the makefile and reorganise ROM files in the development hierarchy. The only other gotcha was that the eye-catcher sprite bank for LOSJ was at $6F, residing in the 2nd pair of sprite files, which required tweaking in my conversion tool. But as of tonight, selecting legendos on MAME runs Knight Lore!
Tomorrow I'll hopefully complete the CPC graphics conversion.
To develop/run a Neo Geo game under MAME, you need to hijack an existing game. That involves taking the original cartridge ROM images for a specific game, replacing select files (68K program code, sprites and FIX layer graphics) with your own content, and running under the original name.
The project template I originally used for my Donkey Kong port (WIP) and subsequently for Lode Runner and now Knight Lore was based on the Puzzle De Pon cartridge (GUID 202). With a single pair of sprite ROM images, that's sufficient for 16,384 sprite tiles. Given that the ZX version of Knight Lore has 12,032 you can see how I need more space to support the CPC graphics.
Looking through the MAME driver source code for the 'minimal' cartridge with twice the sprite ROM image size, I discovered a handful of candidates. The extra criteria was no fancy bank switching or protection schemes on the cartridge. Fortunately the first candidate, Legend Of Success Joe (GUID 029), fit the bill. I've simply chosen to ignore the fact that this cartridge is notorious for being arguably the worst game ever released on the Neo Geo.
In the process of switching the 'host' cartridge, I took the opportunity to clean up the makefile and reorganise ROM files in the development hierarchy. The only other gotcha was that the eye-catcher sprite bank for LOSJ was at $6F, residing in the 2nd pair of sprite files, which required tweaking in my conversion tool. But as of tonight, selecting legendos on MAME runs Knight Lore!
Tomorrow I'll hopefully complete the CPC graphics conversion.
Tuesday, 16 February 2016
-cpc option
A bit more progress today. I've implemented the hflip for CPC graphics. I've also added support for the CPC panel rendering, which differs quite a bit from the ZX version because of the split scroll sprite data. Still a glitch or two to fix, but it's looking more-or-less like it should.
I've added a command-line option (soft dipswitch on the Neo Geo) for selecting the graphics set. I still need to set the palette correctly for the CPC graphics, which will require some research on my part and possibly tweaks to the panel graphics on some ports.
I've yet to create the CPC sprite tileset (ROM) for Neo Geo. I'll probably have to create another panel as well to support the correct palette - that's a bit fiddly. Lastly, I'll add the CPC title screen for when that graphics set is selected.
Oh and I somehow broke the Amiga port. It hangs on the menu screen... :(
UPDATE: Fixed the Amiga port. Need to add support for rendering CPC graphics.
One thing I could do is convert the ZX Spectrum graphics to the same format as the CPC, or better yet, a format more suitable for the target platforms to simplify code and improve performance. But I probably won't. I think the C port has been a lot more of a diversion than I originally planned.
 |
| CPC graphics with a glitch or two |
I've yet to create the CPC sprite tileset (ROM) for Neo Geo. I'll probably have to create another panel as well to support the correct palette - that's a bit fiddly. Lastly, I'll add the CPC title screen for when that graphics set is selected.
Oh and I somehow broke the Amiga port. It hangs on the menu screen... :(
UPDATE: Fixed the Amiga port. Need to add support for rendering CPC graphics.
One thing I could do is convert the ZX Spectrum graphics to the same format as the CPC, or better yet, a format more suitable for the target platforms to simplify code and improve performance. But I probably won't. I think the C port has been a lot more of a diversion than I originally planned.
Subscribe to:
Posts (Atom)