No updates reflect the fact that I've had very little time to work on Knight Lore, and even less time to blog about it. I can say that I've got (2-button) joystick input working, after rolling my own joystick routines.
I've been optimising the code from the cocopedia article, moving much of it into a one-off initialisation. In fact it makes supporting either the left or the right joystick at run-time trivial (as-is it's a simple .define build option). The sampling routine now only needs to select the axis, write the sound register (twice) and read back the comparator output (twice). Repeat for 2nd axis.
One issue is the button reading, and the phantom key presses that result. I've still got some research on that to do, and I think I know how to avoid the problem (in Knight Lore) whilst retaining the current key mapping. Once it's all working I'll post my joystick initialisation and sampling routines and (hopefully) explain how I negated the phantom key press issue.
Saturday, 9 April 2016
Tuesday, 5 April 2016
No real joy... yet!
Added support for directional controls. Joystick is still emulated with arrows plus two extra keys, but it has allowed me to test the directional code. All that remains now is to change the emulated joystick routine to read the real Coco3 joystick.
After having been sent some sample code with explanation from James, and reading up on a few blogs, most notably John Linville's The Making of Fahrfall: Reading The Joystick, it's clear that I only need to sample each of the two axes twice in order to obtain a digital reading - something best done internally in my Knight Lore code.
I haven't really looked into joystick support for the Coco3 in MESS, so I have no idea if I can even test it under emulation, but I do have a pair of the standard single-button Tandy joysticks. In the interests of productivity, the best option is probably Drivewire or, failing that, CocoSDC (which I've yet to use). Either of those options is certainly better than erasing and programming EEPROMs...
UPDATE: Was hoping I'd get time to implement reading the joysticks tonight, but after reading a great article on coco3.com that details everything I need to know, it's become apparent that it's a little more involved than I first thought. I'm sure at least some of the PIA configuration need only be done once for Knight Lore, since I have total control over the machine, but it will take some analysis to determine exactly which bits. For another night...
FORGOT TO MENTION: I have it reading the joystick buttons now at least.
After having been sent some sample code with explanation from James, and reading up on a few blogs, most notably John Linville's The Making of Fahrfall: Reading The Joystick, it's clear that I only need to sample each of the two axes twice in order to obtain a digital reading - something best done internally in my Knight Lore code.
I haven't really looked into joystick support for the Coco3 in MESS, so I have no idea if I can even test it under emulation, but I do have a pair of the standard single-button Tandy joysticks. In the interests of productivity, the best option is probably Drivewire or, failing that, CocoSDC (which I've yet to use). Either of those options is certainly better than erasing and programming EEPROMs...
UPDATE: Was hoping I'd get time to implement reading the joysticks tonight, but after reading a great article on coco3.com that details everything I need to know, it's become apparent that it's a little more involved than I first thought. I'm sure at least some of the PIA configuration need only be done once for Knight Lore, since I have total control over the machine, but it will take some analysis to determine exactly which bits. For another night...
FORGOT TO MENTION: I have it reading the joystick buttons now at least.
Monday, 4 April 2016
CPC and fake joysticks
I couldn't resist starting to add support for CPC graphics. First task was to reorganise the memory map to cater for the 2BPP video display and buffer; it was a tight fit and for a few minutes I thought it wasn't going to work. But all good.
Ripping and adding the CPC sprite data was trivial. Adding support, however, won't be. The nature of the changes for the Coco3 are actually quite different to both the Amiga (planar bitmap memory) and the Neo Geo (hardware sprites pre-rendered in ROM). In addition, the panel sprites are quite different so there's a fair bit of work to do - likely too much to do before CocoFEST.
And so I returned to the issue of joystick - and directional - support. Since there was no code behind the main menu for input method selection, I added support for selecting Keyboard, Joystick and Directional Control, removing the other two ZX Spectrum-specific joystick options in the process.
The ZX Spectrum uses flashing attributes to denote options selected in the menu - noticeably absent on the Coco3. Instead, I modified the text display routine to simply invert the character if the flash attribute was set, then added a blit to update the relevant lines on the menu each iteration through the main menu loop. Later I may invoke a timer and actually have it flash, but there's more important things to do first and CocoFEST is fast approaching.
Finally, I added a fake joystick read routine that - for now - simply reads an alternate set of keys from the keyboard. This will facilitate adding directional controls without complicating the issue with untried joystick code. I would expect that I'll have directional control working next session, which means all that remains is to replace the fake joystick read routine with the real one.
Ripping and adding the CPC sprite data was trivial. Adding support, however, won't be. The nature of the changes for the Coco3 are actually quite different to both the Amiga (planar bitmap memory) and the Neo Geo (hardware sprites pre-rendered in ROM). In addition, the panel sprites are quite different so there's a fair bit of work to do - likely too much to do before CocoFEST.
And so I returned to the issue of joystick - and directional - support. Since there was no code behind the main menu for input method selection, I added support for selecting Keyboard, Joystick and Directional Control, removing the other two ZX Spectrum-specific joystick options in the process.
 |
| The Main Menu is now tailored specifically for the Coco3 port |
The ZX Spectrum uses flashing attributes to denote options selected in the menu - noticeably absent on the Coco3. Instead, I modified the text display routine to simply invert the character if the flash attribute was set, then added a blit to update the relevant lines on the menu each iteration through the main menu loop. Later I may invoke a timer and actually have it flash, but there's more important things to do first and CocoFEST is fast approaching.
Finally, I added a fake joystick read routine that - for now - simply reads an alternate set of keys from the keyboard. This will facilitate adding directional controls without complicating the issue with untried joystick code. I would expect that I'll have directional control working next session, which means all that remains is to replace the fake joystick read routine with the real one.
Saturday, 2 April 2016
Shady dealings
I've had no luck getting my Coco 3 hooked up to anything other than the lounge room TV; none of my monitors like 50Hz composite and I can't get my fancy pants video converter to recognise the Coco RGB output either (though that's entirely my fault, I haven't modified the software to do it yet!) So no pictures of Knight Lore running on real hardware just yet unfortunately.
During the development of Knight Lore I've referenced many different resources on the net, one being the Knight Lore Walkthrough, ZX Spectrum video found on YouTube. A similar video by the same author caught my eye; Knight Lore (Graphics Mod) Walkthrough, ZX Spectrum. A chap by the name of Mick Farrow enhanced the original ZX Spectrum graphics back in 2002, adding more shading (via dithering) and sharpening the outline of some sprites. Unable to locate a binary of this version, I contacted both the video author and then eventually Mick himself, and received helpful responses from both - thanks again guys!
I received a .TAP file first, but couldn't for the life of me work out how to execute it in MESS. Before resorting to asking for help, Mick sent me a .Z80 which I had running in MESS a few moments later. After giving the game a quick spin, I restarted MESS with the debugger enabled, and dumped the entire 64KB to a binary file.
During development I wrote a utility that read the .SNA file and (besides a lot of other things) produced a text file with C data declarations (with nice names) for all the data structures in the game, figuring it would come in handy for the other filmation games as well (it did/will). When I started on the Coco3 port, I extended the utility to also produce a 2nd text file with the respective ASM data declarations. I had to add literally 3 lines of code - to instead read the above-mentioned 64KB memory dump of Mick's version - and seconds later had the modified graphics ready to compile/assemble. And as it just so happens, the sprite data resides in a separate .ASM file that is .included in the main .ASM file, so using alternate graphics is a matter of simply .including a different file. And now with a build option using a .define it's very easy to select which version to build.
So as of now, the Coco3 port has two build options - Original or Mick Farrow graphics. And to give you a taste of what they look like on the Coco3, I've got a couple of screen shots.
I should hasten to add that Mick was nice enough to grant me permission to use his graphics mods. A Coco3 cartridge with at least 128KB capacity could theoretically contain versions with Original, Mick Farrow and Amstrad CPC graphics! It will be equally as trivial to add them to the C ports (Amiga, Neo Geo) as well (binaries will support all graphics options in the one build).
But for now, I should start looking at Coco joystick support!
UPDATE: I have one, really crappy, photo of Mick's graphics running on a real Coco3!
During the development of Knight Lore I've referenced many different resources on the net, one being the Knight Lore Walkthrough, ZX Spectrum video found on YouTube. A similar video by the same author caught my eye; Knight Lore (Graphics Mod) Walkthrough, ZX Spectrum. A chap by the name of Mick Farrow enhanced the original ZX Spectrum graphics back in 2002, adding more shading (via dithering) and sharpening the outline of some sprites. Unable to locate a binary of this version, I contacted both the video author and then eventually Mick himself, and received helpful responses from both - thanks again guys!
I received a .TAP file first, but couldn't for the life of me work out how to execute it in MESS. Before resorting to asking for help, Mick sent me a .Z80 which I had running in MESS a few moments later. After giving the game a quick spin, I restarted MESS with the debugger enabled, and dumped the entire 64KB to a binary file.
During development I wrote a utility that read the .SNA file and (besides a lot of other things) produced a text file with C data declarations (with nice names) for all the data structures in the game, figuring it would come in handy for the other filmation games as well (it did/will). When I started on the Coco3 port, I extended the utility to also produce a 2nd text file with the respective ASM data declarations. I had to add literally 3 lines of code - to instead read the above-mentioned 64KB memory dump of Mick's version - and seconds later had the modified graphics ready to compile/assemble. And as it just so happens, the sprite data resides in a separate .ASM file that is .included in the main .ASM file, so using alternate graphics is a matter of simply .including a different file. And now with a build option using a .define it's very easy to select which version to build.
So as of now, the Coco3 port has two build options - Original or Mick Farrow graphics. And to give you a taste of what they look like on the Coco3, I've got a couple of screen shots.
 |
| The splash screen, with an acknowledgement to Mick |
 |
| A sample of Mick's shaded and sharpened graphics |
I should hasten to add that Mick was nice enough to grant me permission to use his graphics mods. A Coco3 cartridge with at least 128KB capacity could theoretically contain versions with Original, Mick Farrow and Amstrad CPC graphics! It will be equally as trivial to add them to the C ports (Amiga, Neo Geo) as well (binaries will support all graphics options in the one build).
But for now, I should start looking at Coco joystick support!
UPDATE: I have one, really crappy, photo of Mick's graphics running on a real Coco3!
Friday, 1 April 2016
The Real Deal!
I was hoping to have some accompanying photos to commemorate the occasion, but circumstances didn't allow it. On the plus side, I got to sample the Firefly board game, which is pretty cool!
In short, my Knight Lore cartridge boots up and plays fine on a real Coco 3. A few artifacts that aren't apparent on the emulator are noticeable, though very minor and perhaps I'll ignore them as they don't really affect the finished product. I only got to play it for about 5 minutes before I had to shut it down, but it was enough to prove that it's basically working.
The version I have now is definitely sufficient to demonstrate at CocoFEST, even with the lack of code optimisation. I'm undecided whether I'll press on and try to squeeze a few more features in before then, or take a short break and continue after CocoFEST is over.
I'm tempted to add joystick support, especially since I've had an offer of assistance with the code. Might be nice to show off the newly-designed Sega gamepad adapter that I believe will also be debuted at the 'fest. Though of course I probably won't have one in time to test with...
I'll update this post with some pictures ASAP.
In short, my Knight Lore cartridge boots up and plays fine on a real Coco 3. A few artifacts that aren't apparent on the emulator are noticeable, though very minor and perhaps I'll ignore them as they don't really affect the finished product. I only got to play it for about 5 minutes before I had to shut it down, but it was enough to prove that it's basically working.
The version I have now is definitely sufficient to demonstrate at CocoFEST, even with the lack of code optimisation. I'm undecided whether I'll press on and try to squeeze a few more features in before then, or take a short break and continue after CocoFEST is over.
I'm tempted to add joystick support, especially since I've had an offer of assistance with the code. Might be nice to show off the newly-designed Sega gamepad adapter that I believe will also be debuted at the 'fest. Though of course I probably won't have one in time to test with...
I'll update this post with some pictures ASAP.
 |
| The world's first Coco3 Knight Lore cartridge |
Thursday, 31 March 2016
Eating, breathing and sleeping Knight Lore!
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...
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...
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.
Subscribe to:
Posts (Atom)