Playing with Galaxian on MAME

[Kelloggs]

I toyed with putting this in "Playing the games..." because it fit in so many ways, but fundamentally this isn't Playing Galaxian, this is Playing with Galaxian. And please excuse me if, in your particular case, this is teaching Grandma to suck eggs.

It's intrigued me for several years now that MAME is essentially an emulation of an arbitrary number of CPUs and support chips, glued together in software, and I'd like me some of that, but I'm buggered if I'm going recompiling it all the time just to find that a) it doesn't work and, ultimately, b) it's boring when it does. So, I went looking for a Z80-based game (because Spectrum) from a long time ago (because small and simple) and with some decent sprites and colours (because Spectrum... you know it's true) and Galaxian was where I ended up. So, I've got the Galaxian ROMs (ahem) which are, of course, Read-Only... no, of course they're not. But, MAME checksums its zips and has a robust approach to running one it doesn't recognize, unless you do a custom build with a new checksum - see above. Or...

Unzip the zip file into a folder. MAME'll run the ROMS from there quite happily, but whinge if any are modified. It'll still let you play, though - the keys to the kingdom. So, I ran the 2k ROM files through a decompiler, giving me some Z80 to play with. Sadly, they all start at $0000 if you do that, which can't be right, so I pulled down the Galaxian owner's manual, including schematics, which gave me some clues as to where in the memory map each chip lived. Then I found some enterprising chap called Scott Tunstall had already done an annotated decompilation, so that was handy.

However, there's this 32-byte ROM image, that doesn't seem to fit anywhere in the memory map. 32 bytes is bloody small for a ROM where its colleagues are 2k, as well. Back to the schematics, and this 'ere 32-byte ROM has outputs that go, via a set of binary-valued weighting resistors, out to "R", "G" and "B" lines off the board. It's the video chip. Or, I suppose, the sprite palette ROM would be a more precise name. Each memory location within is a BBGGGRRR value, and setting them to different colours allowed me to see what "ink" was used for each "thing". Duly noted.

Then, I started looking through the code proper, and found that the chip on location 9N on the board was used to control some things which, if tweaked, would be obvious - the starry background and the horizontal and vertical flip (think cocktail two-player games). Now, I'm used to a Z80 having both memory and I/O, but most of the other 8-bit stuff that wasn't Z80 had memory-mapped hardware, and that's what this is (the IORQ line might not actually be connected to anything, but the schematic's smaller than my eyesight can handle) so in the init code, it shoves "1" into the A register, then writes the contents of A into a few locations where this chip lives, turning on the stars and setting things upright. OK, I thought, I don't want to move anything round too much, but I want to put "0" into the star bit rather than one. Z80 to load "1" into "A" is two bytes (the opcode "LD A,1" - mentally, I pronounce that "load A with 1") so I deleted that (hex-capable text editor) and replaced it with XOR A (which puts a "0" into A because of maths) saving a byte. Then write that into the star control bit, then do "INC A" to get our actual "1" (that's the previously-saved byte accounted for, so the ROMs are the same length) so the screen flipping gets set correctly. Start the game in MAME, and agree to it ignoring the checksum... and fume at the game itself checksumming its own ROM space. Grrr...

So. Have a look through the code to see where the checksum gets calculated (just a little earlier than the screen init, as it happens) and there's a three-byte opcode to test if the checksum failed. Zero each byte (Z80 "0" is NOP, for No OPeration), run it again, and marvel as not only the game runs, but also the stars go out. Emboldened by this, I then went looking for other stuff - and found the test for collision between player and enemy shots. Another few NOPs, and I'm INVINCIBLE! And then a little alien fighter crashes into me, and now I need to go looking for a different piece of code...


I don't know if this will go anywhere. It's essentially focussed curiosity, but I'm finding it fascinating. I'm used to programming on 8-bit stuff where there's a fixed bit of hardware that you talk to in a fixed way (because even that was a stretch), and that's it, but here, for example, there isn't any code driving the stars. There's a flag to turn them on and off, but they're generated in hardware by a couple of chips doing an LFSR (sort-of pseudo-random number generator) and throwing pulses onto the "R", "G" and "B" lines in sync with the electron beam, and the flag bit controls a data line which inhibits these chips. Can't wait to see how it generates sprites!

Thoughts, anyone?

[Dio]

Welcome to the rabbit hole of reverse engineering.

It's great fun. It's basically Sudoku, but much more interesting: "Here is something I know does something. How does it do it?"

The tiny rom is typically called a "color PROM" - they were small programmable ROMs. One of the things to note about arcade hardware is seemingly obvious: it uses ROM instead of RAM. This turns out to have some subtle advantages - while if you were programming an 8 or 16-bit computer, generally everything happens in two steps (first upload it into RAM then it goes from RAM to the screen) you can avoid the upload step. Which, in turn, makes the hardware much cheaper and easier to design, because you don't need to supply any ways for the CPU to access the ROM at all. It just gets read directly by the video hardware and that saves loads of complexity in mapping a system bus to BOTH CPU and video and arbitrating their access - instead the ROM has just a single use.

The color PROM is an example of that - no need for a programmable palette, just put the PROM on the output. If you want different palettes, add another line to the PROM or add another PROM; if you want the sprites and something else to have different colours, put a different PROM on the 'something else'. So, as you've observed, it's usually necessary to read the schematics along with the code on most arcade machines.

[Kelloggs]

I've not gone digging that far (because I haven't needed to) but presumably there'd be a requirement for the PROM to be able to output at pixel clock rates (or close) because, after all, it's generating (some of) the pixels. Probably why it's a tiny one, if so, because if it's a Bit Special, it'll be more expensive. Another thought that struck me, though - this gives 32 colours (and each sprite used four - background and three foregrounds - so even that's optimised to be driven by logic gates and not code) but a bigger ROM could presumably give a bigger palette. Might need to be 16-bit (R5G5B5A1?) to make the most of, say, 1024 colours... and we're back to a 2k ROM!

[Dio]

Dot clock for roughly square pixels is only 6-8MHz, that's 125-150ns and well within the capabilities of the PROMs. They aren't like EPROMs or mask ROMs, which need large row-column arrays, usually using very small transistors and so often needing some kind of sense amplifier (and that's where the long access times come in because it takes a while to charge the bitlines and then the sense amplifier takes time to settle). PROMs typically have propagation delay more like "a few TTL gates" than a ROM.

They're probably something like the 74S188, which had a 25ns delay (edit) It's an 82LS123, which is 32x8 and has a 45ns propagation delay.

The Williams boards are an interesting second one to look at - they're a bit more computer-like in that they're just basically a 4-bit framebuffer driving a 16x8 RGB332 palette. 32KB is a lot to move around with even a 6809 though which is why they added the DMA engine from Robotron on.

[gilesgoat]

If someone remembers we done a MAME version of Hovver Bovver on Scramble hardware ( that is a bit of an 'upgraded' version of Galaxian HW ).

"That damned color prom" is the one that I am planning to replace with a CPLD in an HW rebuild for the fact it seems it's difficult nowdays to find ANY sort of "eeprom" or stuff that has SO fast access time !

But yeah it's "super fun" checking what those old HWs where doign and HOW, I still never fully understood how they were generating the PAL synch signals.

[edit] because IIRC that PROM maps only 32 bytes ( or can't remember how many but not manby ) ( I think actully 16 but if I wanto be able to switch to the original Scramble Palette I need extra 16 bytes ) I can use a CPLD with a statment like :

Code: Select all

WITH address SELECT output <= 
 "00001111" WHEN "00000",
 "00101111" WHEN "00001",
 etc.

Ad thankfull a 32x8 "PROM" can fit within an XC9572XL giving me a 10ns PROM otherwise I dare you to find NOWADAYS a somethingx8 PROM/EEPROM/etc. of such access times !

( I was even thinking to modify a bit the board and add a ram but again then you can't find "small" rams )

[Dio]

It's encodeable in a GAL apparently. Also out of production but still very available if you don't mind random packages packed in cling-film.

[Kelloggs]

Strangely enough, I put an order in for 3 GAL16V8 chips on 3rd August (building a floppy drive interface for a SAM Coupe) and after ten days they hadn't turned up (this, mind you, on "1-3 days delivery"). Got back onto the vendor to warn them, and they've now sent another three and said "if the first lot turns up, let us know but keep them" and I absolutely can't fault them for that.

[gilesgoat]

It's encodeable in a GAL apparently. Also out of production but still very available if you don't mind random packages packed in cling-film.

22V10 and 10V8 and 16V8 are someway still available .. but to program them is a PITA/need stuff that is PRETTY EXPENSIVE ( or you try like me to build your own "Afterburner" which is still NOT VERY CHEAP ).

I'd go for XC9572XL, still relatively easy to find/use.

[Dio]

I've heard my EEPROM programmer (a TL866 clone I think) will do the Lattice ones but not the Atmel, not tried it though.

It's almost impossible to buy anything new that outputs 5V. Although I guess you can use 3.3V outputs and hope with most TTL logic...

[gilesgoat]

I've heard my EEPROM programmer (a TL866 clone I think) will do the Lattice ones but not the Atmel, not tried it though.

It's almost impossible to buy anything new that outputs 5V. Although I guess you can use 3.3V outputs and hope with most TTL logic...

Most 3v3 logic will work straight on with TTLs, the output '1' at over 2.4V and '0' at less than 0.4V and are TTL input tollerant.

I suppose worst case you can go with pull up resistors or such.