Gravitar on Space Duel PCB

[Mitchell Gant]

I have an Atari vector Space Duel cab and a couple of spare PCBs.

I've fancied a Gravitar for a while, but they're not that common and even finding a Gravitar PCB and making an adapter to plug into the Space Duel cab is not that easy either.

How about running Gravitar on a Space Duel PCB itself then? The Gravitar PCB looks pretty similar to a Space Duel PCB, just a few more EPROMs for more memory space for extra code and graphics. It's obvious that Gravitar is an evolution of Space Duel hardware.

Surely if I just fix some Gravitar EPROMs to the Space Duel PCB with electrical tape that would do it, wouldn't it? Won't the software code diffuse down into the PCB tracks and all just work?

Unfortunately it looks like it might be a **bit** more complex than that. A good look at the schematics for both Space Duel and Gravitar show a great deal of similarities, even a lot of the chips are in the same PCB locations on the Gravitar as the Space Duel.

The main obvious difference is the larger ROM space for both CPU program ROM and vector ROM. 24K rather than 18K for CPU ROM, and 14K instead of 6K for vector ROM. Gravitar has twice as much CPU RAM with 2K instead of 1K, and it has a bank switched area similar to Asteroids, and I guess this is for the same reason to switch banks for 2 player games and keep the software routines simpler.

Another difference is that Gravitar has analogue vector scaling, which is used to scale or 'zoom' vector out to smaller sizes smoothly. Space Duel only has digital scaling in steps of powers of 2, although the older Tempest and Battlezone do have this analogue scaling too.

This analogue scaling circuitry is what actually started me on this quest, I spotted that there are some empty chip locations (E8 and D9) on a Space Duel PCB that are NOT shown on the schematics, but match exactly the scaling DAC and latch that is used on Gravitar.

Mitchell Gant2016-02-09 22:33:08

 

[Alpha1]

You have my interest!!!

 

[bonehead]

Me too.
Tell us more!!!!

 

[Mitchell Gant]

The larger CPU ROM and RAM space could be fixed by making a plug in PCB for the 6502 CPU that adds it's own single large flash ROM and RAM rather than the many EPROMs and RAM chips on the original game.

Philmurr has just done exactly this for a Z80 CPU so he can use it on a Galaxian or Pacman board.

Rather than design and build my own, I thought someone must have already made such an obvious PCB. A quick search found this device:

http://blog.tynemouthsoftware.co.uk/2015/09/commodore-pet-rom-ram-replacement-boards.html

An email on a Saturday afternoon prompted a reply in about 10 minutes and after a few questions I had two bare PCBs in the post to me. This should allow me to re-map the ROM address space and store both Space Duel and Gravitar code in a single large flash ROM. I had to write my own GAL equations though, as Tynemouth only had Commodore PET equations.

(RAM not installed yet on this photo)

Next problem is that although I can now use this ROM/RAM expander board to replace the game ROMS, I need to shift the address map around as Gravitar and Space Duel have some major differences here:

Space Duel hardware

0x0000-0x03FF RAM (size 0x400)

0x0800-0x0EFF I/O

0x0F00-0x0F3F EAROM write

0x1000-0x100F POKEY #1

0x1400-0x140F POKEY #2

0x2000-0x27FF VRAM (size 0x800)

0x2800-0x3FFF VROM (size 0x1800)

0x4000-0x87FF ROM (size 0x4800)

************************************************

Gravitar hardware

0x0000-0x07FF RAM (size 0x800)

0x2000-0x27FF VRAM (size 0x800)

0x2800-0x5FFF VROM (size 0x3800)

0x6000-0x600F POKEY #1

0x6800-0x680F POKEY #2

0x7000 EAROM read

0x7800-0x8FFF I/O

0x9000-0xEFFF ROM (size 0x6000)

The biggest problem here is that Gravitar expects to see a 16K 'slot' for vector memory starting at 0x2000, but Space Duel only has an 8K slot.

A 74LS21 4-input AND gate and a bit of pin cutting and re-wiring can do this on a Space Duel PCB though.

This still leaves all the I/O and POKEY sound chips at different address locations though...

OK, all I need to do is disassemble all the Gravitar software into assembly instructions, then re-assemble in a new location, along with all the references to I/O, POKEYs, etc remapped to the same locations they are in Space Duel.

I've already done the same thing for Star Wars and Asteroids, so I applied the same technique to Gravitar. Then I did the same for Space Duel too.

Now I have both a Space Duel and Gravitar code that lives at ROM address 0x8000-0xFFFF. And Gravitar code now looks to the correct addresses for a Space Duel PCB. Both those can now be burned into the single flash ROM that is on the Tynemouth ROM/RAM expander.

Mitchell Gant2016-02-09 22:34:51

 

[Hurray Banana]

Amazing effort

 

[Equites]

Awesome, I knew it would not be long before someone does this.

Yes, the different mapping is the stumbling block.

 

[Mitchell Gant]

The next big problem is the vector ROM space, which is twice the size on Gravitar. Not only is the vector memory space doubled as seen by the 6502 CPU, but also as seen by the vector generator.

Again looking at the schematics shows that Gravitar has 14 vector memory address lines compared to Space Duel's 13 lines. But the chips used on Gravitarare the same on Space Duel, just that Space Duel doesn't use some of the chip parts!

There's a 74LS157 multiplexer at M8 that has spare pins that can be manually wired in to implement A13 and AVG13 signals that are present but not used on Space Duel. The custom Atari AVG address controller chip has DVY12 and AVG13 unused, so I just needed to wire them to the appropriate chip pins.

 

[Mitchell Gant]

That still leaves the problem of more vector ROM that Gravitar requires though.

I could hack on a large EPROM, as fortunately the vector RAM is still only 2K in Gravitar, same as Space Duel.

But I already have a vector ROM/RAM expander board that I designed a few months ago that will do the trick.

This board actually stores ALL Atari vector game ROMs in it, and also has a large RAM for future homebrew use. It can also be configured to select which ROM bank (game) is switched in by writing to certain ROM address locations. The intention here is to allow a multigame to switch between vector ROMs.

It plugs into the 2532 EPROM socket of the Space Duel PCB, but I also had to remove the four 2114 vector RAM chips, as the Space Duel decoding left them enabled as mirror images beyond 0x4000. That took me a while to figure out! And I made a bit of a mess desoldering the chips in my hurry and the fact that the tracks seem much thinner than the Asteroids PCBs I'm used to desoldering.

There needs to be some wire links to provide AM12, AM13 and R/W to the vector expander too.

I spent a lot of time writing the GAL22V10 equations to get the Gravitar addressing correct.

One interesting fact I found out is that Gravitar has 14K of vector ROM, but one of the EPROMs from 0x5000-0x6000 is in fact used to store CPU game code! Atari must have under estimated the CPU ROM size required and stolen vector ROM for the extra code.

I have removed the need for this as I now have 32K of available CPU ROM space on the Tynemouth ROM/RAM expander, so I've moved that CPU code into that space.

Along with a Biltronix Address Controller replacement, my pimped up board now looks like this.

The result of all that now gives this on my 'scope. I was pretty chuffed when that image appeared!

There's still more to do though, CPU RAM bank switching, EAROM high score handling and the different way that Gravitar reads in the player buttons to debug.

I'll explain more in the next part tomorrow perhaps.

 

[bonehead]

This is looking awesome!!!!!

A great write up of what you have done so far with lots if detail.

I look forward to the next instalment.

 

[Del Griffith]

Great work so far

 

[Nes4life]

This is all kinds of awesome. Hats off to you sir!

 

[DanP]

Wow, amazing stuff. How about squeezing Black Widow in there and have the full multi game set!

 

[Ordyne]

Thats pretty impressive!

 

[forcefulfil]

Great work
Thx for sharing

 

[Mitchell Gant]

Wow, amazing stuff. How about squeezing Black Widow in there and have the full multi game set!

Yes that would be the next step to make it complete, though I would not be able to play it in my cab without changing the control panel.

Apart from disassembling the software to move to the new ROM address, there's nothing to stop it working on this setup that I can see. There's plenty of vector ROM and CPU ROM space now.

The next obvious problem is the high score EAROM memory. The Gravitar setup I have here should work with the Space Duel EAROM, but it will trash any scores/settings that Space Duel had written.

I'm thinking that I really do need to make my own CPU ROM/RAM expander that will do the RAM bank switching and also have a modern EEPROM that has plenty of space. We use lots of MCP25LC256 32K EEPROMs at work, so that's favourite for me.

I think that's how the Braze Asteroids high score kits work, I'll have to have a good look at the one in my Asteroids cab.

I'd need to modify the code to read/write to such an EEPROM, not sure my 6502 skills are up to that.

 

[philmurr]

This really is excellent stuff Neil.

I've a Braze high score kit not yet installed so can do a bit of reverse engineering on that if you don't want to take your cab apart?

 

[ColinD]

Super cool....

 

[DaveAS]

What a cool project. Top work.

 

[Mitchell Gant]

The next problem I face is the different way that Gravitar reads in the player control panel buttons.

Space Duel used a pair of 74LS251 multiplexers (at N9 and L9) wired to data bus DB6 and DB7. This was a common trick on 6502 based hardware as it makes good use of the 6502 BIT instruction which directly tests bits 6 and 7, potentially saving some precious ROM bytes.

For some reason Gravitar hardware changed this to a pair of 8 bit wide buffer chips also at locations L9 and N9.

The schematic I have (SP-206 2nd printing) shows these chips to be 74LS224s, not a chip I am familiar with. A search show a '224 to be a 16x4 FIFO memory. Surely this a misprint and they're actually the common 74LS244 8 bit buffers? Anyone have a real board that can confirm what's in L9 and N9?

Either way, Gravitar expects a byte wide read of addresses 0x8000 and 0x8800, so I've had to insert some extra code to read the various Space Duel addresses 0x900-0x907 and construct a byte that matches the bit pattern of the Gravitar buttons.

This part does not work properly yet, but I noticed today that Space Duel multiplexers use the *inverted* output on to the CPU data bus, so I'll need to invert the bits in my code. I will report back when I've had chance to do this.

There are no doubt other issues to solve before I can be playing Gravitar in my Space Duel cab, but hopefully these will be caused by the disassembly not being quite correct yet. Tables of pointers are always a problem I found when doing the Asteroids disassembly.

Below are my notes of what I actually did to the PCB up to now, in case anyone else fancies doing a hack. You could probably get away without the vector memory expander and re-jig the decoding and have a single larger EPROM.

Needs following components adding for analogue scaling:

1x 74LS273 @ E8

1x DAC-08 @ D9

8x 100K 0.25W axial resistors R74-9

1x 3K9 0.25W axial resistor R89

2x 7K5 1% 0.25W axial resistor R87 R88

3x 100nF axial capacitor C70, C71, C73

Vector Memory expander

Needs solder pad linking for socket pin 18 to A11 input.

Plugs into 2532 EPROM location @ N/P7

The Space Duel PCB only has 12 address lines for the vector generator. Gravitar has 13 address lines.

Gravitar uses 74LS157 multiplexer pins 2, 3 and 4 to select between CPU inverted A13 signal and AVG13.

Gravitar inverts A13 signal using gate in 74LS04 @ J3, pins 8 and 9.

The 74LS157 @ M8 pins are unused but present on the Space Duel PCB. Inverter J3 does use the gate at pins 8 and 9, but gate at pins 10 and 11 are unused.

Pin 11 input needs wiring to A13 signal on pin 14 of 74LS42 @ R2.

Pin 10 output needs wiring to Pin 2 of 74LS157 @ M8.

Pin 3 of 74LS157 @ M8 needs wiring to AVG13 signal on Pin 22 of "AVG chip" @ J9.

Pin 4 of 74LS157 @ M8 needs a male header pin soldering to it to provide a jumper wire to expander A13 input.

Pin 4 of 74LS157 @ K8 needs a male header pin soldering to it to provide a jumper wire to expander A12 input.

Pin 27 of Address Controller @ J9 (DVY12 input) is tied to ground in Space Duel. In Gravitar it is connected to DVY12 from pin 2 of 74LS175 @ D6

Fortunately there is a nice long, fat track from the underside of pin 27 of J9 that is easy to cut and solder link wire to pin 2 of D6.

PROBLEM:

Space Duel decodes vector memory from 0x2000-0x3FFF. Gravitar expects 0x2000-0x5FFF.

Can tie DISDAT low to disable ROM decoding and let Tyne ROM board supply program code. Wire From R20 to 0V @ E3

Need to enable vector memory in the region 0x4000-0x5FFF though.

Cut pin 8 of 74LS08 @ R3 to isolate ~VMEM signal.

Add 74HCT21 4 input AND gate.

Wire output of 74HCT21 AND gate pin 8 to signal VMEM.

Wire input of 74HCT21 AND gate pin 9 to pin 3 of 74LS42 @ R2

Wire input of 74HCT21 AND gate pin 10 to pin 4 of 74LS42 @ R2

Wire input of 74HCT21 AND gate pin 12 to pin 5 of 74LS42 @ R2

Wire input of 74HCT21 AND gate pin 13 to pin 6 of 74LS42 @ R2

Must remove or disable game vector RAM and use Expander RAM, or PCB decoding does not decode above 0x3000 properly.

Remove RAM if using Vector Memory Expander, or modify vector address decoder circuit and use on board vector RAM.

PROBLEM:

Space Duel only enables 74LS245 buffer @ F2 when not ROM or POKEY addresses. Decoding thinks that 0x4000-0x5FFF is still ROM.

Cut pin 4 of 74LS00 @ E3 and tie to +5V via 1K pullup resistor. This will keep buffer @ F2 enabled when reading from old ROM space. (Actual ROM is on Tyneside expander)

PROBLEM:

Space Duel RAM is 0x000-0x03FF. Gravitar RAM is 0x0000-0x07FF with bank switch fed from pin 2 of 74LS273 @ R9.

Wire pin 2 of R9 through A10 GAL16V8 on Tyne ROM board and XOR in GAL?

Make own CPU ROM/RAM exapnder with 22V10 GAL and a serial EEPROM such as MCP25LC256. Would need software modifying to read/wrtite to EEPROM rather than game EAROM, but could then support multiple game settings/scores.

 

[backflipper]

Wow how did I miss this! Look forward to chatting to you about this at Steves meet!