Atari QuadGames

Well, the first prototype adapter is finished, Quad-Joust is undergoing testing (ie making my kids come down to the basement and play it with me), and I'm almost done with the 2nd game to be included on the QuadGames multicart: Quad-Combat (or Quad-Tank).  Basically, just a 4-player variant of the original tank/combat game.

Using the same basic code layout as Joust was a great starting point, and made it easy to the game 99% of the way there.  The problem, though, was time.  Most of the time during gameplay, it worked great. But under a few worst-case conditions, I ran out of processing time, and the screen would roll.   It didn't help that there were really 8 objects that had to be dealt with every frame -- 4 tanks and 4 bullets.  (as opposed to just the 4 birds from joust)  Reading over the code a few times, there wasn't anything grossly inefficient.

Which meant it was time for optimizing.

Because I wrote this all in batari basic to save programmer time, I wasn't sure how efficient the compiled assembly was.  Step one was to just read through the assembly that bB generates. Which turned out to be not too bad.  Very little that was egregious.  But a lot of places where I could do a tiny bit better by hand.

So I tonight I ended up rewriting about half the game into assembly. Having the compiled basic code to work off of made it pretty fast, but it was easy to find places where it was being dumb. For example, I had code like:

temp1 = player0x + 4
temp1 = temp1 / 4

which naively got transformed into:

lda player0x     ;3
clc              ;2
adc #4           ;2
sta temp1        ;3
lda temp1        ;3
lsr              ;2
lsr              ;2
sta temp1        ;3
                 ;total: 20 clock cycles

Not terrible, but a bit wasteful. Knowing the state of the carry flag going in, I was able to rewrite it


lda player0x     ;3
adc #4           ;2
lsr              ;2
lsr              ;2
sta temp1        ;3
                 ;total: 12 clock cycles


8 clock cycles isn't much, but doing this sort of thing in a handful of places throughout the game ended up making it work!

Now it's time to test some more....

Don't look too closely, turns out I'm REALLY bad at making holes in plastic boxes.

4-player adapter progress

The past few weeks have been a fun balance between working on my NES game (still slogging through getting my scrolling engine right!) and the Atari 4-player adapter.

I'm too tired tonight to go into too much detail, but the adapter is moving along great!  The way it works is this:

• The Atari allows setting 4 of each joystick port's pins to either input or output mode. Normally you want them on input mode, because they are the pins that read the 4 directions of the joystick. But they planned well for future-proofing the console, and set it up so that you can control them as outputs as well.
• So to allow 4 controllers, I use a really simple multiplexing scheme -- the first joystick port is used in normal input mode for reading all 4 controllers, and the second joystick port is used in output mode to select which controller to read at any given time.

So with just a few multiplexer ICs and some pull-up resistors, we have a working adapter!

Well, mostly-working. So far, the left, right, and up directions work. I still need to finish wiring up the down and fire buttons!

Right now my desk is just a giant mess of wires waiting to be soldered.

I was a bit nervous at first that the Atari wouldn't let me write to the output pins fast enough to switch to each joystick during a frame, or that the input might be latched once in a frame and not updated as I switched it.  But neither of those were the case, and so far, it seems to be working perfectly!

Next step: finish wiring the last pins, and put this thing into some sort of sturdy box. Then hopefully get it all cleaned up to possibly show off at PRGE!