Gravitar – PCB Repair Logs

I came across a pretty decent Gravitar cabinet that had everything except a PCB and a working monitor. I’ll be restoring the cab a bit soon. I was able to get a Gravitar PCB pretty reasonably priced from an operator I’ve done some repairs for..

Board#1 – My board

Triage:

  • Board didn’t look very good at first glance.
  • Missing the AVG chip – which had a machine pin socket.

First time through it failed RAM @N/P1 and Passed ROM testing. I had an AVG chip but could not get it into the machine pin headers.. I don’t like them anyway and replaced it with a dual wipe socket.

After swapping the bad RAM and running all the tests.. The board booted up but had broken vectors in a couple parts of the high score table attract screen. The VG would eventually crash if you let it cycle through 4-5 attract screens. It was very strange. I checked all the outputs into the DACs even though they could not cause a crash, but I kept going back to the VG RAM.. Swapping in different chips caused the VG do to very different things. From a couple of bad vectors to full VG crash resulting in playing blind. The built in RAM check did not flag any issues.

In the middle of all of this it ran fine in diagnostic mode.. I was testing buttons and ‘Thrust’ crashed the machine. Didn’t matter if I was in diagnostic mode or switched to game. Thrust = program crash. At first I thought it was somehow my test rig. Swapped in the other Gravitar board (#2) below .. and Thrust was fine..

Turned out to be an interesting failure. First – LS224@L9 is a misprint (thankfully) it is actually an LS244@L9. The ‘Thrust’ input is on Pin 17 and should be read from Pin 3. Left, Right, Fire, Shields all worked correctly. Replacing LS244@L9 fixed ‘Thrust’ and the game no longer crashed. Oddly – the chip tests fine in my cheap chip tester.

Back to the vector RAM… Diag wasn’t flagging anything.. But the board seems to be exceptionally picky.. I finally rotated back in the original 2 RAM (@N/P1 is now working.. maybe dirty socket? I had not done any cleaning yet) and the game runs perfect.

I’m going to experiment a bit more.. The specs call for 150ns RAM. I’m using 55ns RAM. It should work fine (I would think)

Board works!

Board #2 – Friend’s Gravitar

Plug in and tested RAM, ROM, VG – no issues.

Connected to my monitor and the graphics were distorted. After a bit more testing – decided it was an analog issue. The DACs were already socketed from prior work. Swapped the X and Y DACs and the distortion changed..

Replaced the X DAC @A/B9

Board works!

Board #3 – Board in for repair

Did full maintenance – cleaned chips, Deoxit, etc..

Bad ROM – replaced

AVG BAD – replaced.

Full test cycle

Board works!

Board #4 – Board in for repair

My first step for all board repairs, remove all the chips, inspect the board, clean and Deoxit chip legs and sockets. Really dirty boards get a bath. This work I do at my desk with my coffee in the AM – often while watching arcade related YouTube videos. 

Once I got it all back together and on the bench – it read having 6 bad ROMs. These were clearly recently burned and labeled. The bad ROMs read correctly in mt reader, but not in the game board. I pulled them all and used my Gravitar ROMs and they verified in place. No issues on the PCB. The 6 ROMs in question were Fujitsu MB-8532’s – which are 2732 compatible. Gravitar wants 2532’s. So that mystery got solved. I burned a set of replacement EPROMs.

Once the RAM, ROM and the vector generatorwere verifying – I tried to boot the game but it was watchdogging. Pulled the Pokey and the game was able to boot into the diag screens and the game, progress!

Here is the DIAG window on the scope and next to it the game screen it is much too big! But evenly too big both X and Y axis.

For comparison – a working board. DIAG screen and the game screen fitting properly. Last crazy symptom..

Gravitar logo perfectly rendered, but it didn’t do the bouncy letters. It was perfectly stationary. At first the two did not seem related. I had no idea how why the logo wasn’t moving. Size issue first. Looking around the schematic I was looking for a scale or size reference for both X and Y. Specifically because the DIAG screen was the correct scale and the game screen wasn’t – but it wasn’t correct – evenly..

When I got here it all made sense. Scale data is buffered@E8. The DAC08@D9 gets the data and varies the X and Y reference voltages. The reference voltage is fed into the XY DACs. Changing the reference voltage easily changes the size/scale of the vectors w/o more complex computations (is how I’m interpreting it) Replaced DAC-08@D9 fixed the game scaling AND fixed the GRAVITAR Logo bounce.

Board works!

Leave a comment