Defender Conversion for the CoCo 3 – Part 1

Hello, I wasn’t going to blog about my conversion of the arcade version of the William’s classic game Defender for the Tandy Color Computer 3 but I decided it might be nice to share some of my progress.  Especially when there is something to see.  I made a video showing the loading of my Defender and the startup screens and sound.  It’s kind of a boring video but it does show what it will be like eventually once the game is finished (actually it might use 4 disks!).  You can view the video here

FYI – The rest of this blog is a little techie…

I’ve gathered up all the information on Defender I could find on the internet.  Two fantastic resources are The Computer Archeology’s Defender page and the other is Sean Riddle’s William’s Arcade Games Info page

Summary of what needs to be dealt with for this conversion:

Video display – Defender uses a display size of 304×256 pixels which can show 16 colours on screen at one time.  Each byte holds 2 pixels just like the CoCo 3 320×225, 16 colour screen.  Defender has a 256 colour palette where the CoCO 3 has 64, so Defender does have a little more fidelity in the colours to choose from but it probably wont be noticeable.  Defender’s screen RAM is not laid out like normal video RAM.  The top left corner in RAM is $0000 but the next byte $0001 is not the byte to the right of it but actually the byte below it.  To move to the right you must add 256 so $0100 is actually the byte to the right of $0000, that will have to be dealt with during the conversion.  The big problem is the height of the screen.  Out of the actual 304×256 pixel screen Defender only uses 290×241, I guess to make sure overscan on the monitors isn’t a problem.  Defender displays 241 rows, the CoCo 3 only has 225 rows.  So I either cut the screen off and not show the bottom 16 rows or I could maybe shrink the top of the display where the radar is displayed.  Or I could do what I did with Pac Man and scroll those bottom 16 rows if your ship gets below the middle of the screen.  I still don’t know what I’m going to end up doing here…  Too bad the CoCo 3 didn’t have a nice standard 320×240 pixel screen.


Audio Output – Defender has a dedicated audio board that when sent a number would play a specific sound.  The hardware can only play one sound at a time.  As far as I can tell at this point Defender uses 21 different sounds even though the sound board has a few more sounds that it can create.  I’ve already converted these samples to a format that the CoCo 3 can playback using the FIRQ so this shouldn’t be too much of a problem or a hinderance to the speed on the game.  The audio is converted to 8 bit unsigned 6kHz samples.  Since I now have a CoCo flash I think I’ll output the audio to both the CoCo audio port and the CoCo Flash/Orchestra 90 audio outputs.  Audio in this format doesn’t compress well and they require 287,432 bytes!  That’s two disks just for the sounds used in Defender.  I could cut that down by 1/4 if I reduce the samples to 6 bit samples which is the maximum format the CoCo’s built in DAC can use.  But it’s still going to be huge so I figure I’ll leave it and try to get it to work with the CoCo Flash/Orchestra 90 cartridges.  It’s something new for me to learn, although I don’t think there’s much to it other then sending the data to a certain address in the CoCo 3.

Controls – Defender has a lot of buttons/controls.  I don’t think this will be a problem.  I will be coding it to use the keyboard only.

Program Code – Defender uses the awesome Motorola 6809 CPU running at 1.00 Mhz.  The CoCo 3 uses the same CPU but runs faster at 1.78 Mhz which leaves us with CPU cycles to spare!  Useful for audio playback and other things that will need to be dealt with like the screen layout conversion/scaling.  This is good news and hopefully I can just use a lot of the code as it is without having to tweak it too much!

RAM/ROM Layout – While reading through the above websites I learned that Defender and other William’s Arcade games use 4 Banked sections of code.  Which I figured I could duplicate since the CoCo 3 already has banked switching.  Defender swaps $1000 bytes of ROM in and out of location $C000 to $CFFF.  The CoCo 3 swaps out blocks of $2000 bytes and can only swap out the block at $C000-$DFFF.  Since the CoCo has a lot more RAM I decided I would just copy the code in $D000-$DFFF in each of the 4 Banks.  So now the swapping of the Banks will not change the code at $D000-$DFFF.  Another thing I realized that can save me a lot of headaches is to use the same Bank numbering scheme that Defender uses on the CoCo 3.  Namely  Bank 1, Bank 2, Bank 3 and Bank 7, so I’ll use the exact same Banks in the CoCo 3.  Anytime the Defender code changes the Bank by writing to address $D000 with the Bank #, I just have to change the $D000 to $FFA6 (Page $C000-$DFFF  Block #6) and it “should” just work.

This is what I have working so far

Audio – I have the audio samples all working and tested the playback of the single samples.  There are a couple of samples that repeat though like the player thrust sound and when the players ship slows down.  The code works, I just have to figure out where in the game the samples get used and tweak it to use my code instead.

Sprites – I’ve taken all the sprite data used in Defender and made compiled/blasted sprite versions of them.  I’ve also made compiled/blasted sprite versions of the text characters that are displayed on screen.  I’ve tweaked the draw character routine to use my compiled sprite versions of drawing text characters to the screen and  my compiled sprites render the text characters a lot faster then how the real Defender did it, which used simple Load and Store instructions to the screen memory.  My compiled sprites draws a 3×8 character takes on average 129 CPU cycles.  The real Defender code draws the same 3×8 characters but takes 291 cycles.

Defender has the benefit of drawing sprites to the screen memory as it’s video memory is laid out in a way that is useful for stack blasting.  Especially fast for erasing sprites on screen.  Which is the technique Defender uses for drawing it’s sprites on the screen.  It’s so amazing to me that the original programmers (Eugene Jarvis, Larry DeMar and Sam Dicker) back in 1980 & 1981 had already figured out that stack blasting is an amazingly fast way of moving data around using the 6809!  I should also mention that from what I’ve noticed so far of the Defender 6809 code is really top notch programming and highly optimized code.  They really did make excellent use out of the 6809.  My compiled/blasted sprites on the CoCo 3 are faster then stack blasting on the CoCo 3 but with the layout of the graphics RAM on the Defender hardware stack blasting the data is faster.  It’s not that bad though, my compiled/blasted sprites are only about %20 on average slower, some are actually faster.  The good news is our CPU is running 78% faster so it “should be” possible getting the game to run at 100% the same speed as the original.

Program Code:

  • I have the RUG pattern showing up during the RAM/ROM tests, which doesn’t really test the RAM or ROM in my version.  I want to save the space for code changes plus the code wont match the original and a true RAM/ROM test would fail.
  • Audio playback handling is good to go.
  • Bank switching locations match Defender’s Bank switching.
  • Character Text displaying routine working twice as fast as the original Defender, all code in place after the RAM/ROM test up to the point where it shows the message “INITIAL TESTS INDICATE UNIT OK”

What’s next?

Next I will add in more ROM data and go through the code and add or tweak it as I go.  I’ve really only started with the real game code so far.

Cheers, Glen

This entry was posted in CoCo Programming. Bookmark the permalink.

2 Responses to Defender Conversion for the CoCo 3 – Part 1

  1. joaquinferrero says:

    Defender have another surprise… If you run Defender with MAME, and overclock the CPU speed (select sliders to, p.e., 140 %, the game don’t run at 140 %, but the CPU have time to display all sprites every frame, so it don’t need to “teleport” them in busy situations. This is more noticeable using the bomb.

    • nowhereman999 says:

      Hi joaquinferrero,
      Thanks for this info, that makes sense as Defender does check to see if it has time to draw all the sprites and if not then it doesn’t draw them and only draws the ones it can. Overclocking I guess speeds everything else up so it will have time to draw all the sprites. Neat!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s