Defender Conversion for the CoCo 3 – Part 4 – Two out of Three Attract Screens are converted

I’ve been working hard on the Defender conversion and am happy with the progress and how well things are going.  I uploaded a video on YouTube showing that I now have two out of three attract screens working.  The code for writing the Williams logo was pretty cool.  The particle routines that Defender has for the “Beam In” effect was a big pain to work out on the CoCo 3.  The Defender hardware is optimized for handling the particles but I have written some pretty optimized code to emulate it.  The CoCo 3 version is now a few more CPU cycles slower than the speed of Defender.  Since the CoCo 3 is running at 1.78 Mhz and Defender runs at 1 Mhz, I feel pretty confident that the speed of the CoCo 3 version should be the same as the real thing.

Screen Shot 2018-01-24 at 11.25.58 PM


Screen Shot 2018-01-24 at 11.27.31 PM

The next attract screen is going to be a killer, as it pretty much has most of the game on screen.

Defender has a unique IRQ that is triggered every 4 milliseconds that is tied to the VBLANC/VSYNC.  It has hardware that can be checked to see where the scanline is being drawn.  With a 4 millisecond IRQ that means the screen is split up into 4 sections.  This allows Defender to update parts of the screen without the need for double buffering.  For example if the scanline is checked and found that the scanline in drawing the bottom half of the screen then Defender will draw sprites on the upper half of the screen.

I have figured out a way to emulate this IRQ on the CoCo 3 and it is being used in my version right now.  It hasn’t been tested with moving sprites yet as I haven’t got that far in the conversion yet.  Once I have it tested with running sprites on screen and I know it’s working properly I’ll go into details of how it works.  If it works the way I think it should then it could be a really nice way for game developers to put sprites on the screen without the headaches of double buffering and the extra  memory needed for handling two screens worth of graphics.

At this point I have all the hardware emulated so I’m in pretty good shape to move on to the last attract screen.  Then it will be on to the game itself!  I still haven’t come across the code that draws the land on the bottom of the screen which I’m looking forward to seeing how they pulled that off.  The last attract screen shows the land so I’ll be coming across that code soon.

See you in the next post… Glen

This entry was posted in CoCo Programming, Emulation and tagged , , , , , , , . Bookmark the permalink.

3 Responses to Defender Conversion for the CoCo 3 – Part 4 – Two out of Three Attract Screens are converted

  1. Good stuff here. I am particularly intrigued by the “no double buffering needed” approach. If I understand the implications, that means a game using a 32K screen would no longer need a full second 32K screen for the double buffering?

    • nowhereman999 says:

      Hi Allen, you are correct. Defender didn’t have the memory space for two copies of the video RAM so this is how they got around it. If you are making a game with a complicated background behind your moving sprites then you might want a copy of your background in another 32k of RAM so you can quickly and easily erase your sprite by copying the data from the backup screen. Defender didn’t have this problem since it’s all a black background.

  2. Ted KC9LKE says:

    Watched the video Great work Glen!

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