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.

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...