I've ported the remaining high score routines, which leaves just two 'core' routines remaining - those concerned with the explosion of the player ship. The high score routines are almost functional; they just need a bit of debugging but don't adversely affect anything else.
So back to the mysterious end of game issue. After the addition of the high score entry routines, the nature of the issue has changed. In retrospect, the original problem was likely the very lack of the high score routines - particularly the routine that checks for a new high score - since it does change some of the state information.
The issue then manifested itself as the high score entry screen appearing briefly, then a new game starting immediately. After an hour or so of static code review and then moving on to debugging in MAME, I'd stumbled upon something that in itself didn't appear to cause the issue, but still wasn't right - a seemingly arbitrary value in the current number of credits.
However, setting a watchpoint in MAME and running not only refused to reproduce the problem, but the game started behaving correctly on the high score entry screen! Running again without the watchpoint, and it would fail. Run it again with - all OK. Inexplicable.
And then, I finally caught it. Not part of the 'core' code, but in the Coco-specific portion, I poll the keyboard every frame and increment, amongst other things, coin counters when appropriate. FTR the arcade code does this in an NMI, but for now I'm doing it once per frame. Anyway, turns out I wasn't detecting depress properly and holding down the <5> key adds multiple credits. And whilst running the debugger and watchpoint, it's slow enough to detect just one coin if you press <5> quickly.
But the universe wasn't done with me yet. In the same portion of code, I also handle the start button. In this case I was polling the keyboard correctly, but never clearing the state of the button, so once pressed, it remained in that state permanently.
And finally, to muddy the waters even further, it turns out that pressing the start button with credits in the machine will actually abort the high score entry screen altogether and start a new game!
Here I was thinking that somewhere in the core code it was exiting the high score entry state erroneously, when in fact a combination of multiple credits and a 'stuck' start button - all in my code - were to blame! At least I finally found it...
Next, debugging high score entry (which shouldn't take long) and then the exploding player ship.
Saturday, 7 October 2017
Thursday, 5 October 2017
Getting close
Today I did a quick audit of what was outstanding in the 'core':
There's also a few routines not strictly necessary for game play, but will likely be implemented at some stage to round off the port:
I could probably knock over the high score routines in a single session. The exploding ship was the one aspect of the Apple IIGS port I hadn't addressed, for two reasons; I don't (yet) understand the code and I don't have Norbert's graphics for it (nor do I understand - yet - how he implemented it).
UPDATE: I've done 4 of the remaining 7 high score routines; namely those that display the high score table. The remaining 3 comprise the high score initials entry.
I might finish off the high score and then have another look at the exploding ship code for the arcade. If it's still incomprehensible to me, I might move on to optimising the rendering for the Coco3 before returning to it in earnest.
Today I did manage to completely break the asteroids though when adding a few tweaks... so fixing that is first on the agenda.
UPDATE: I also fixed this, however although it detects the end of the game (and displays GAME OVER) it still doesn't actually end the game - you can still play. I had a look for this earlier, and it still eludes me.
- 7x routines for high score display/entry
- 2x routines to display exploding player ship
There's also a few routines not strictly necessary for game play, but will likely be implemented at some stage to round off the port:
- 4x sound routines
- 4x sundry routines, such as NMI
I could probably knock over the high score routines in a single session. The exploding ship was the one aspect of the Apple IIGS port I hadn't addressed, for two reasons; I don't (yet) understand the code and I don't have Norbert's graphics for it (nor do I understand - yet - how he implemented it).
UPDATE: I've done 4 of the remaining 7 high score routines; namely those that display the high score table. The remaining 3 comprise the high score initials entry.
I might finish off the high score and then have another look at the exploding ship code for the arcade. If it's still incomprehensible to me, I might move on to optimising the rendering for the Coco3 before returning to it in earnest.
Today I did manage to completely break the asteroids though when adding a few tweaks... so fixing that is first on the agenda.
UPDATE: I also fixed this, however although it detects the end of the game (and displays GAME OVER) it still doesn't actually end the game - you can still play. I had a look for this earlier, and it still eludes me.
Wednesday, 4 October 2017
Mostly Playable.
Quick update on the Coco3 port of Asteroids tonight.
Have managed a few sessions over the last few days...
The game is all-but-playable now. Although it detects and displays Game Over, it still continues the game and subsequently dying results in a crash as it tries to display (presumably) 255 remaining lives.
Going purely on generated code size, it's roughly 67% complete now. I'm yet to do a formal audit, but I can't actually think of a lot that is yet to be ported, aside from the high score handling and player ship explosions, plus snippets of sound code. There's certainly some AVG display list management code that will not need to be ported for the Coco3 version, plus the non-English message tables that I'm not going to support, so it could well be closer to 80% or even 85% complete in reality.
Once the 'core' code has been ported, the next task is optimising the rendering for the Coco3. That means adding compiled sprites and page-flipping for starters. Nothing too complex in there, and I've already been through the exercise for the (unfinished) Apple IIGS port.
Here is where I hope the slightly higher clock speed and 1BPP graphics mode will give it the edge over the IIGS SHR mode graphics, which still crawled despite my best efforts.
Time will tell...
Have managed a few sessions over the last few days...
- Fixed score display
- Fixed end-of-wave detection
- Added shots (player & saucer) and fixed shot direction
- Added shrapnel (explosion) rendering
- Added end-of-game detection
- Added hyperspace
The game is all-but-playable now. Although it detects and displays Game Over, it still continues the game and subsequently dying results in a crash as it tries to display (presumably) 255 remaining lives.
Going purely on generated code size, it's roughly 67% complete now. I'm yet to do a formal audit, but I can't actually think of a lot that is yet to be ported, aside from the high score handling and player ship explosions, plus snippets of sound code. There's certainly some AVG display list management code that will not need to be ported for the Coco3 version, plus the non-English message tables that I'm not going to support, so it could well be closer to 80% or even 85% complete in reality.
Once the 'core' code has been ported, the next task is optimising the rendering for the Coco3. That means adding compiled sprites and page-flipping for starters. Nothing too complex in there, and I've already been through the exercise for the (unfinished) Apple IIGS port.
Here is where I hope the slightly higher clock speed and 1BPP graphics mode will give it the edge over the IIGS SHR mode graphics, which still crawled despite my best efforts.
Time will tell...
Friday, 29 September 2017
Return To Asteroids!
Today I finally returned to Asteroids, as promised for so long. Specially, the 6809 port to the Coco3. After spending 20 minutes familiarising myself with where I was up to all those weeks ago, I managed to fix the bug that I introduced with the last addition of code, which broke most of everything.
I also deduced the actual purpose of the function I had last added and had formerly named handle_shots(). It is now called handle_collisions(), and that's probably sufficient explanation. It's not completely debugged yet - it's a decent chunk of code all-up - although running into an asteroid splits it in two and the player loses a life.
I feel like I'm back in the groove with it now, so I'll look to knock as much of it over as possible (it's a touch over 50% complete) before returning to other side projects. I have a new incentive to finish it now; I plan to port it to the arcade Star Wars hardware once the Coco3 is done.
What I have been doing in the last few days was RE'ing yet another game, this time Berzerk for the Vectrex. I wanted to get a feel for how the Vectrex was programmed and how difficult, or otherwise, it would be to port games to another platform.
As it turns out, the BIOS is used quite extensively - in Berzerk at least - so porting the game would mean also porting a significant portion of the BIOS code. On the up-side, once that was done it would be much easier to port other Vectrex games that made use of it as well.
Regardless, Berzerk isn't the easiest of games to RE. I'm slowly getting there, but I've had to work for it. I had expected 4KB of code to be a bit easier to work out, especially given the use of well-documented BIOS calls, but it hasn't been the case. I've taken it as far as I need to at this point.
Purely for fun I took the Vectrex character data from the BIOS and converted it to Star Wars AVG commands (or near enough) and wrote a routine to render a string on Star Wars hardware in the Vectrex font. That's the picture in the last blog post! It uses an insane amount of resources on that platform - somewhat paradoxically the Vectrex rasterizes its characters - but still looks cool!
But for the moment, I've done what I need to do with Star Wars (and the Vectrex) and will set them aside whilst I work towards finishing the Coco3 port of Asteroids.
I also deduced the actual purpose of the function I had last added and had formerly named handle_shots(). It is now called handle_collisions(), and that's probably sufficient explanation. It's not completely debugged yet - it's a decent chunk of code all-up - although running into an asteroid splits it in two and the player loses a life.
I feel like I'm back in the groove with it now, so I'll look to knock as much of it over as possible (it's a touch over 50% complete) before returning to other side projects. I have a new incentive to finish it now; I plan to port it to the arcade Star Wars hardware once the Coco3 is done.
What I have been doing in the last few days was RE'ing yet another game, this time Berzerk for the Vectrex. I wanted to get a feel for how the Vectrex was programmed and how difficult, or otherwise, it would be to port games to another platform.
As it turns out, the BIOS is used quite extensively - in Berzerk at least - so porting the game would mean also porting a significant portion of the BIOS code. On the up-side, once that was done it would be much easier to port other Vectrex games that made use of it as well.
Regardless, Berzerk isn't the easiest of games to RE. I'm slowly getting there, but I've had to work for it. I had expected 4KB of code to be a bit easier to work out, especially given the use of well-documented BIOS calls, but it hasn't been the case. I've taken it as far as I need to at this point.
Purely for fun I took the Vectrex character data from the BIOS and converted it to Star Wars AVG commands (or near enough) and wrote a routine to render a string on Star Wars hardware in the Vectrex font. That's the picture in the last blog post! It uses an insane amount of resources on that platform - somewhat paradoxically the Vectrex rasterizes its characters - but still looks cool!
But for the moment, I've done what I need to do with Star Wars (and the Vectrex) and will set them aside whilst I work towards finishing the Coco3 port of Asteroids.
Thursday, 28 September 2017
Saturday, 23 September 2017
Star Wars. Software Developer Kit.
Firstly, although I have not been working on Asteroids lately, I would like to reiterate that the Apple II and Coco3 ports of Asteroids are still very much alive. In fact, I'm about to return to the Coco3 port - which is about 50% complete - very soon.
So, what's up with the Star Wars screenshot in the last blog post?
It's probably obvious that it's not a genuine emulated Star Wars screen shot; in fact it's not Star Wars running at all. It is actually a crude AVG emulator - based on my Asteroids DVG emulator - 'executing' a handful of select AVG ROM routines. So... why? ... you may ask.
I was approached recently by someone who was looking for a '6809 guy' that might be interested in doing some development work on the Star Wars hardware in order to encourage/facilitate development of new games for the platform. That development work may or may not comprise code examples, demos, tutorials and even an 'SDK' if you like for the platform.
That someone also happens to be working on a related project for which any such software development may be useful to assist in testing/debugging.
Well that piqued my interest and although I didn't intend on interrupting my Asteroids projects, curiosity got the better of me and I started to not only look at the disassembly, but also learn how the AVG and various other hardware components operate. That turned out to be quite a bit of fun and only served to draw me further into the investigation.
The 6809 disassembly, at a whopping 48KB (and banked just to complicate matters) was definitely daunting but I was making decent progress none-the-less and by the time I had written my crude AVG emulator, I felt I was ready to start writing code from scratch to run on the arcade hardware.
And thus the Star Wars SDK was started. After a few examples writing vectors, calling ROM routines and reading buttons, I started looking at the math box, whose implementation has been well documented (and of course emulated) at the low level, but I could find no descriptions of the higher-level functions. I chose a few well-used functions to RE and I finally had a working example using the 3x3 matrix multiply function which I used for a simple 2D rotation of a square.
More disassembly and I turned my attention to the sound ROM. I soon had example code that played through all the sounds in the game. I decided to complete the sound ROM disassembly - as far as practical at least - and reached this point tonight. The TMS5220 routines are completely commented, and I've made educated guesses for the higher-level POKEY routines; they get very complicated at the register level. Everything else in the ROM has been RE'd, and that's as far as I'm taking it at this point. See the Project List & Downloads page for the disassembly.
As for the SDK sound functions, it should be sufficient to provide a 'source' version of the sound ROM code that can be edited with new sound data and re-assembled. Anything more would be a mammoth task in re-writing the TMS5220 and Quad POKEY routines for no good reason (other than copyright of course).
Some sound-related trivia; the game has ~60 pre-canned sound effects, the data for all of which are stored in the 6809 sound ROMs. 22 of those are samples from the movie played via the TMS5220. Another 20 are sound effects played via POKEY 1 & 2, and the remaining 11 are tunes played on POKEY 3 & 4 (actually, just 3 in reality I believe). Playing a sound from the main CPU is as simple as writing a single byte - the sound number - to the mailbox register. Some TMS5220 sounds (random sound bites during gameplay) will only be played if the TMS5220 queue is empty - otherwise it will be silently discarded.
There's still work to do on the SDK, mainly handling yoke inputs and RE'ing the remaining math box functions and coming up with (more impressive) examples that use them - like spinning 3D wireframe models. Aside from that though, there's probably enough info now to write a full-blown game from scratch on the platform.
I don't intend on doing much more in the way of commenting the main ROM disassembly, aside from sections that may assist in my understanding of the remaining SDK functions. I would like to perhaps know a little more about the states (routines) in the main state machine though. And FTR most of the banked code appears to be routines that use the math box, and they are pretty obfuscated, so I won't be commenting much of them.
For now, I aim to get back to Asteroids on the Coco3 before I forget it all. And no prizes for guessing what the next target platform will be...
So, what's up with the Star Wars screenshot in the last blog post?
It's probably obvious that it's not a genuine emulated Star Wars screen shot; in fact it's not Star Wars running at all. It is actually a crude AVG emulator - based on my Asteroids DVG emulator - 'executing' a handful of select AVG ROM routines. So... why? ... you may ask.
I was approached recently by someone who was looking for a '6809 guy' that might be interested in doing some development work on the Star Wars hardware in order to encourage/facilitate development of new games for the platform. That development work may or may not comprise code examples, demos, tutorials and even an 'SDK' if you like for the platform.
That someone also happens to be working on a related project for which any such software development may be useful to assist in testing/debugging.
Well that piqued my interest and although I didn't intend on interrupting my Asteroids projects, curiosity got the better of me and I started to not only look at the disassembly, but also learn how the AVG and various other hardware components operate. That turned out to be quite a bit of fun and only served to draw me further into the investigation.
The 6809 disassembly, at a whopping 48KB (and banked just to complicate matters) was definitely daunting but I was making decent progress none-the-less and by the time I had written my crude AVG emulator, I felt I was ready to start writing code from scratch to run on the arcade hardware.
And thus the Star Wars SDK was started. After a few examples writing vectors, calling ROM routines and reading buttons, I started looking at the math box, whose implementation has been well documented (and of course emulated) at the low level, but I could find no descriptions of the higher-level functions. I chose a few well-used functions to RE and I finally had a working example using the 3x3 matrix multiply function which I used for a simple 2D rotation of a square.
 |
| Example code running on Star Wars hardware under MAME |
More disassembly and I turned my attention to the sound ROM. I soon had example code that played through all the sounds in the game. I decided to complete the sound ROM disassembly - as far as practical at least - and reached this point tonight. The TMS5220 routines are completely commented, and I've made educated guesses for the higher-level POKEY routines; they get very complicated at the register level. Everything else in the ROM has been RE'd, and that's as far as I'm taking it at this point. See the Project List & Downloads page for the disassembly.
As for the SDK sound functions, it should be sufficient to provide a 'source' version of the sound ROM code that can be edited with new sound data and re-assembled. Anything more would be a mammoth task in re-writing the TMS5220 and Quad POKEY routines for no good reason (other than copyright of course).
Some sound-related trivia; the game has ~60 pre-canned sound effects, the data for all of which are stored in the 6809 sound ROMs. 22 of those are samples from the movie played via the TMS5220. Another 20 are sound effects played via POKEY 1 & 2, and the remaining 11 are tunes played on POKEY 3 & 4 (actually, just 3 in reality I believe). Playing a sound from the main CPU is as simple as writing a single byte - the sound number - to the mailbox register. Some TMS5220 sounds (random sound bites during gameplay) will only be played if the TMS5220 queue is empty - otherwise it will be silently discarded.
There's still work to do on the SDK, mainly handling yoke inputs and RE'ing the remaining math box functions and coming up with (more impressive) examples that use them - like spinning 3D wireframe models. Aside from that though, there's probably enough info now to write a full-blown game from scratch on the platform.
I don't intend on doing much more in the way of commenting the main ROM disassembly, aside from sections that may assist in my understanding of the remaining SDK functions. I would like to perhaps know a little more about the states (routines) in the main state machine though. And FTR most of the banked code appears to be routines that use the math box, and they are pretty obfuscated, so I won't be commenting much of them.
For now, I aim to get back to Asteroids on the Coco3 before I forget it all. And no prizes for guessing what the next target platform will be...
Friday, 8 September 2017
More vectors!
Been busy with work, investigating a new project, and being ill.
More to come...
 |
| Just finish Asteroids already!!! |
More to come...
Subscribe to:
Posts (Atom)