Astrofighter color PROM strangeness

While dumping random ROMs and proms in an effort to identify boards Frank and I came across something interesting.  We found two color PROMs that were not able to be identified by MAME, but are very VERY similar to some already in MAME.  The color PROMs in question seem like the one used in Astrofighter but with minor differences.  We ran the game with the different color PROM and in emulation we couldn’t tell the difference so Frank whipped up this script to generate a palette based on the PROM information.  What this does is evaluate the information in the PROM to determine what color is displayed based on the analog mixing on the output, and the data bus going into the PROM.  First, let’s generate a palette based on the PROM in MAME:

Original Palette

This shows a decent variety of colors, but that alone doesn’t tell us much.  Let’s look at it against the ones we dumped (there were two identical ones, as well as one original so the dumper isn’t in question here)

Different palette

Here we can see that the orange color is replaced with red and dark red.  That seems to be the only difference between these.  In the game that orange color is only responsible for some of the colorful twinkling stars in the background so it’s unlikely that anyone would notice the difference.  Maybe that color is used by an enemy later on, but in playing the game we haven’t come upon any yet.  The technical difference is that at address 0x09 and 0x19 in the MAME version of the rom the value is 0x07, while in the one we found it’s 0x01.  That’s a two bit difference in data at only two addresses.  I can’t think of a way for two chips to be broken in the same way as to give this sort of a result, so I’m left thinking it’s just a minor variation on the released PROM.  Perhaps a different game uses the same PROM and it makes a bigger difference there, but not in Astrofighter.

We did find another, more different, PROM and run it through the same palette generator script and came up with this:

very different palette

This one only has the first half of the PROM populated with data.  Here I DO suspect hardware damage to the PROM, something about accessing the top address bit caused no output on the data bus whatsoever.  This one seems a clear case of failed hardware.  That being said, while 0x19 has data 0x00, like all the upper bytes…. 0x09 has 0x01 just like the other PROMs we found to be different than the one in MAME.  It seems that before failing this was also deviating from what the known Astrofighter PROM was supposed to be.

Is the slight variation on the star background worth archiving in MAME as a different ROM set? We don’t even have positive confirmation what game this PROM came from, just strong speculation based on what you can see above.

Partial success at reading PAL16L8s

I try to archive all the things I think might be important that come through my hands, and I’m a completionist so this usually gets me hung up on things that don’t actually matter functionally but I still feel like Need Doing.  The latest one is archiving the AMPAL16L8s on the “Kuri Kinton (World)” board.  The Roms were in MAME, but the way the driver was written it didn’t use the PALs.  Even though the emulation doesn’t need these, if you have a board and need to replace one of these chips to make it work you are out of luck.  After hunting around I landed on this clever adapter to brute force the logic equations programmed into these chips.

This is clever because it just uses the address lines as a binary counter trying every combination of inputs and using the 8 output lines as the data bus.  The interesting part comes from the 8 output lines also being able to be configured as input lines.  How do we interrogate something to figure out if it’s an input or an output? In this case we induce a little bus contention and see how the PAL moves.  The theory goes that if the PAL uses a given pin as an output then it will be strongly driven and overcome the address line trying to also drive that pin via the 4.7k resistor.  By going through all possible states of the other pins you will read all possible states of that pin and see no correlation when the only thing that changes is the address line also trying to drive that pin.  If the PAL uses that pin as an input pin then the ‘data’ line will always follow the address pin trying to drive it through the resistor and you will see 100% correlation between the address pin and the data pin.

When we tried this we seemed to see that this pin was always stuck high, regardless of the state of any other pins.  That did not turn into a functional GAL when reinstalled in the arcade board so what happened?

Those high pulses are downtime between read cycles, the top trace is on the address line, the bottom trace is on the PAL.  It would seem we have built a voltage divider.  It is our guess that based on this trace the PAL has an internal pullup of about 2.7k because the technology the chip is built on is good at pulling down and poor at pulling up.  The issue with that is we are not driving the pin strongly enough to get it to a low logic threshold,  We could change the 4.7k resistors to something a little lower resistance to up our drive strength but what would that do on an output pin? there would actually be bus contention and might that burn something out?

The question here is how do we interrogate the chips without knowing if the pins are inputs or outputs without breaking them?

 

PS: we pulled working JED files from Jammarcade and tested them, they work great.  We managed to get our own working one for the PAL that had all 8 set as outputs, we just couldn’t get any PAL to recognize our inputs through those resistors.

Reading early Commodore PET roms

This one is short and can be summed up basically with a link to someone’s suggestion and myself saying ‘yes it will work’.  Here’s the suggestion from http://www.vcfed.org/forum/showthread.php?27671-How-to-read-6540-ROM%B4s

does the 6540 need the clock impulses? to output data?

Yes. You could try to connect clock with A0 and the address lines of the 6540 with the corresponding higher address lines of the EPROM-adapter. Like this:

6540 2732
clk a0
a0 a1
a1 a2
a2 a3
…and so on.

Only each second byte of the resulting image will contain your data, but that’s better than no data 

I can confirm it works.  Here’s an image of the chip pinout we’re talking about:

There are a few things interesting about this chip, first is that it has a clock input, which for a parallel rom is a bit strange to me.  Second is that it has five chip select lines… FIVE.  It has so many chip select lines that normal 2716 chips use four fewer pins than this one of equivalent capacity, it goes up a package size just to accommodate those chip selects.  The reason for this is clear, it means less decoding hardware needed, you can hook a set of address lines up to the chip selects and it then reads as a specific memory region without any more decoding, change which lines go to the active low chip selects and which go to the active high ones and you get different memory regions.  This was accomplished in later PET revisions with the 23xx series of roms which are also bristling with chip selects.  The adapter to use a standard 2716 rom in place of the 6540 uses a 74138 to decode those chip selects.

The adapter to read this rom is pretty easy to build, but I can only tell you that it worked with our dumper which in this case was a GQ-4×4, the timing of that clock pulse is included above.  I mapped the address lines to the pinout of a 2732 with the low address to clk and the other ones shifted up one.  I tied all the active high chip selects to Vcc and the active low ones to !CS on the 2732 pinout.  Doing this resulted in the even bytes containing data and the odd bytes being all 0xFF, we used a python script to chop up the binary into one we could check against the mame archive using “mame –romident foo.bin“.  We found two bad roms already this way.