Space invaders repair

Project Space invaders repair
My attempts in repairing a Space Invaders Console from 1977
Status	In progress
Contact	Mahjongg
Last Update	2017-05-09

I was asked if I could repair a defective space invaders console by my friends at Awsomespace, and I said yes. This describes the vicissitudes I experienced while attempting this feat.

Note this isn't actually a RevSpace project, (as all the work is none at the Awesomespace location in Utrecht) but I still thought it was note worthy to document my experiences somewhere, as actual information is hard to come by.

The symptoms of the problem were that the console when turned on only displayed a screen full of "garbage", that is, a screen filled with a repeating pattern of seeming random pixels repeating something like eight times over the screen, with no discernible motion in this pixels.

The console had been found standing in a few inch of water in a cellar somewhere, so we feared the worst for the condition of the electronics, luckily our fears were not met by reality, as the electronics looked fine, only the very large mains transformer on the bottom of the console had been a bit wet and the woodwork has suffered.

The console came with an original document "Midway's SPACE INVADERS PARTS CATALOG" dated October 1978, "game no 739", and heavily yellowed hand drawn schematic of the main (CPU) board, and a secondary sound and I/O board. My first task was to create electronic copies from them.

after quickly verifying all the relative power supply voltages were okay, (they were) I realised that to debug these boards I had to get them on a workbench, power them independently from the consoles power supply, which wasn't really portable in any sense, so I started creating a suitable power supply from an old PC power supply. I also started looking at further documentation and soon found out that any kind of detailed description about how it all worked internally wasn't available at all, and looking at the schematics I soon found out that it was an Intel i8080 based system and was really designed very strangely, which isn't surprising as it really was the very first design incorporating a microprocessor, and video logic. It looked like something an alien being had designed, and went against all modern design concepts of an 8-bit computer system, the only thing it somewhat resembles was an old S100 bus based system, as it didn't have a bidirectional databus, but two unidirectional ones. and also incorporated what looked like data-line multiplexers. https://en.wikipedia.org/wiki/S-100_bus

I discovered some valuable documents, the main being the official repair manual, File:Midway8080testSpaceInvader.pdf.

I also discovered that the board generated a composite (monochrome) video signal, meaning I could hook it up to a test monitor.

I decided that the CPU did not run, or crashed in a loop without doing something, as the random data it was displaying (being RAM content) wasn't affected at all. After measuring that the CPU wasn't in reset state, note that pin 12 on the i8080 has to be high for the CPU to be in reset, and it was low permanently. I decided that for further testing I needed an oscilloscope (or at least a "logic probe", but these are very hard to come by these days, as they are not used anymore). Awesome space has a few very old analog oscilloscopes, one of these would do, but unfortunately there were no oscilloscope probes, so I had to wait for another repair day.

As I suspected the CPU, the intel 9316 ROM's or the 2107 RAMs (which are notoriously unreliable, as one was obviously already replaced in the past) could be defective, I needed a know good test-ROM to test them, unfortunately the system uses old intel mask ROMs (not even EEPROM's) which are also prone to get bad, but the schematic noted that 2716 EEPROMS could be used instead, and provided some very sketchy re-jumpering pictures (but note that you should NOT trust these, they are IMHO incredibly difficult to decipher, and also WRONG). Problem is that four 2716 EEPROMs these days are almost impossible to get hold of, but I did find a 27C64, which in theory could replace all four, in principle I only needed one 2716 for the (original) RAM test code, the one that would write a single digit to RAM in the middle of the screen, hoping that enough of the RAM's would be working so you could actually recognise the digit. In the end benadski found a much more involved test ROM, which did much more than that, but used all four 2K regions (for 2716's), and we programmed this into the 2764 taking care to write the first of the four test roms (test.h) in the lowest of the four locations in the ROM, and test.g test.f and test.e in the succeeding ones, aso as to create one blok of 8K code. Initially I thought that benadski had used the old 2K test and did not understand why he had written four files to the ROM, but once I saw a screenshot of the testrom in action I realised what I had.

So I attempted to re-jumper the several wire links on the board for 2716's, but this failed miserably as the instructions seemed incomplete and simply wrong. In the end I simply disconnected all jumpers and used my noggin to find out how to connect the right signals to the 24-pin (EEP)ROM sockets, in the process I discovered that the roms didn't use any Output Enable Signals, only chip selects (if you used multiple (EEP)ROMS, it seems the ROM bus didn't care if any of the ROM's were addressed (in a restricted address space) and simply always were driven with data from one of the ROM's. It seems the databus multiplexers did the address allocation. Seems old intel ROM's were not designed for tri-state bus systems.

meanwhile I had discovered that the space invaders system had a simple watch dog reset system, consisting of a counter that counted 60 Hz pulses (from the video divider chain) so that unless it was regularly reset it would time out after 256/60 is roughly every four seconds, but the watch dog wasn't running because the power supply reset signal kept it in reset, once I supplied the power supply reset signal, by tying an inverter input low, (a wire over the input capacitor on the board) the watchdog was starting and the i8080 was reset every four seconds, which was what the doctor ordered, because the previously "dead cpu" (no activity on any of its address lines) suddenly came to life, nothing visible happened though, but with the .h rome removed I finally got to see the "good vertical lines" picture, that seems to indicate that RAM is working, as there were no interruptions in the lines, indicating bad RAM bits.

Still the EEPROM did not work, and in the meantime I discovered that I had an 8K testrom not a 2K testrom, so I had satisfied the EEPROM by adding address lines A11 and A12, While measuring all the pins of the EEPROM one by one (which previously had given me the insight that the "2716 jumping scheme" was completely wrong as the right signals did not end up on the right EEPROM pins, and one address pin even had 12V on it :-( , so I completely rewired the jumping) I found out that pin 20 (Output enable) wasn't used at all! all the pin 20 pins of all eight sockets were connected together, but NOTHING was driving the /OE pin! So I wired it to A14, meaning the EEPROM would output actual data if any one of the first four roms were addressed, but tying it simply low would have worked also I think.

I was rewarded with a changed picture, instead of the "good vertical lines" picture I got a picture of either all even or all odd pixel rows being shown, alternating once every second or so. I still have no clue what this means, perhaps the documentation of the new testrom has something to say, or otherwise I have to use a logic analyser to see if the i8080 get the right EEPROM data, fortunately we seem to have just such a logic analyser at Awesome space, and old one, but it seems to work, although no one has used it yet. my latest idea as to what might be wrong, is that one of the data-bus multiplexers is bad, or it could be that the line pattern points to something specific, explained in test rom documentation. interestingly this video of a space invaders console booting this same testrom shows the exact same vertical lines I get, but then continues with other (RAM testing) patterns, this might mean that part of the boot rom is executed, but then crashes. https://www.youtube.com/watch?v=jLM_LJ-QgdE

May 5, 2017 ITS ALIVE!

Yes, there is live in the old thing! I managed to get the testprogram working, initially it was bit of touch and go, sometimes (about one in forty attempts) it started, but most of the time I only got vertical lines, but after long a work on it, I managed to get the program to start consistently, with a press on a reset button I added, and with power-on-reset tied low with a 470 Ohm resistor. here is the proof:

I'm not sure why the testprogram isn't displayed on an all black (in this case blue) background, but in any case its not random. Surely its not a coincidence that the background is laid out as a grid, don't know why it has two white rectangles in it either, but its very consistent, and doesn't seem to be the result of crashed code. The test program starts with a RAM test, and displays that RAM is okay, then displays the checksums of each 2K ROM (which are all programmed in the one 8K EEPROM), don't know why the four checksums are different, as I thought that three 2K ROM's didn't contain any code, at least the whole test also runs when I tie the two extra address lines permanently low, in which case all four checksums are the same, but the test runs just the same, to me that means it runs in only 2K. After calculating and displaying the checksums and the input ports, it enables all sounds in sequence one by one, doing that twice, then it displays the text "shifters = okay", and if you wait a bit longer the testscreen is replaced with a screen displaying eight columns of eight rows of two digit (I presume hexadecimal) numbers, all 64 displaying as "00".

If I connect the leftmost two switch input pins together, while the program is running the sound check, I see the two stars of port1 and port2 bit 4 disappear as long as I connect the pins together.

so we are making progress.

p.s. I found that the background we see is normal for this test ROM, this youtube move show the exact same test program we use in action, and it does exactly the same as ours, only afterwards it displays stripes, instead of the "hexdump", and it seems to restart. https://www.youtube.com/watch?v=J0KvcoGKL-4 perhaps we have a slightly newer version.

now where did I put my bottle of anti woodworm liquid, I used when the big decorative bamboo hand fan I brought with me from Indonesia had woodworm, I can use it again, as the Space invaders cabinet was diagnosed to have woordworm too. For the fan It worked great, just find the holes, and put a bit of liquid on each hole to kill all of them. Hope I can find that small white bottle.

If anyone still has a 2764 or 27C64 EPROM, (or a 27(c)128 EPROM) then benadski can program the Space Invaders code in it, and we can try if that works too.