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:

6540outline

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.

6540_timing

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.  

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: