Can a group of 6 bipolar PROMs be replaced with a single PLD of some sort?

[MaximRecoil]

The PROMs are 82s131. There are 6 of them; they store color information in this application, which is a mid-1980s video arcade game which has 2 monitors (red, green, and blue for each monitor's video signal). The problem is that they're expensive because they're obsolete, they are difficult to program because many, if not most, programmers don't support them, and they are notoriously prone to failure in this particular application.

In this article, someone successfully replaced a single bipolar PROM on a different arcade motherboard with an an Atmel 27C512 OTP ROM. He talked about it having a fast enough access time, so apparently that's important. I suppose the same thing could be done for my application, but a daughter board containing 6 DIP28 chips would be pretty big.

[SeanB]

Depending on the application you could even get 2 or more into the one prom chip, providing you have enough data output lines. however you can use smaller chips, and then use the surface mount versions of them. This will make the SO28 package fit into almost the same footprint as the dip part it is replacing. You just need to either use a part that is faster than the original one, and where there are enough inputs and outputs.  you can even use a different PLD device that has either SPI or other serial programming inputs, and then make the appropriate ISP header on the board to get the data in, so you just need a single board to replace any of the 82S131 chips, as they are only a 9 input and 4 output chip anyway, and pretty much any more modern pld device can be used to replace it.

[rstofer]

http://www.arcade-cabinets.com/board_hacks/82S129-82S131-to-27512/

[MaximRecoil]

http://www.arcade-cabinets.com/board_hacks/82S129-82S131-to-27512/

Nice; that's a polished version of what the guy in the article I linked to did, but that won't work in this case because the group of 6 PROMs are too small and close together on the motherboard:



They are the chips with the homemade blue tape labels.

Something that could be put on a single PCB which plugs into all 6 of those DIP16 sockets at once, and which reduces the number of chips you have to buy to 1, would be good.

[radar_macgyver]

5V programmable logic is getting rare. The Xilinx 9500 series is obsolete and hard to find, but the 9500XL (3.3V, but 5V tolerant) can still be had (5ns pin-to-pin delay, 178 MHz clock rate). Lattice ispMACH4 is 5V tolerant as well, and has similar specs. You can get up to 288 macrocels in the 9500 series, and 256 in the MACH4, which should be plenty to replace a bipolar PROM. Instead of a piggyback board, consider using a PCB with DIP cables for each of the replaced PROMs.

[stj]

tell us what game it is so we can see the schematics.

[rstofer]

http://www.arcade-cabinets.com/board_hacks/82S129-82S131-to-27512/

They are the chips with the homemade blue tape labels.

Something that could be put on a single PCB which plugs into all 6 of those DIP16 sockets at once, and which reduces the number of chips you have to buy to 1, would be good.

I would use 6 ribbon cables between the sockets on the PCB and an adapter board.  It would be larger, of course, but it wouldn't distort the existing sockets.  Make sure you understand if all 6 PROMS are in the same address space and how Chip Select works.  I haven't thought about Arcade projects in a long time and I don't recall what the PROMs are connected to.  The most important part is whether they are all in the CPU address space or some other address space.

You won't need to use more than one copy of the address bits and, probably, one copy of the data bits.  What you really need to bring over is the chip select bits plus R/W or whatever it will be called.

I looked at my PacMan emulation and it appears at first glance that all of the PROMs are in the CPU address space.  I didn't track it all the way through...

[MaximRecoil]

tell us what game it is so we can see the schematics.

Punch-Out (Nintendo, 1984)

https://archive.org/download/punchoutschematicschp102/Punchout_Schematics_-CHP1_02.pdf

The color PROMs are on the BAK board, the schematic for which is located on the last page of that PDF file. There are two other boards in the set: CPU and Video board; the schematics for those are also in that PDF file.

I would use 6 ribbon cables between the sockets on the PCB and an adapter board.  It would be larger, of course, but it wouldn't distort the existing sockets.

Wire wrap legs actually work really well in the original, old-style single-wipe sockets that are on the motherboard set. In fact, Nintendo released a conversion kit for Punch-Out called Super Punch-Out, and part of that conversion kit was a daughter board which plugged into the main CPU (Z80) socket. It uses a wire wrap socket:



Even when that daughter board has been installed for ~30 years, you can remove it and put a Z80 back in there and it still fits fine. I recently reproduced that daughter board:



(original on the left)

And I used a new-old-stock wire wrap socket which was made by Texas Instruments, and it fits in the CPU socket beautifully; better than the original wire wrap socket that Nintendo used (which was made by Yamaichi). The original had a very tight, mushy feel when inserting it, with no good tactile feedback indicating when it was fully seated, while the TI one "snaps" in there, not too tight, not too loose, as if it were designed specifically for the job. I liked it so well that I replaced the blue Yamaichi wire wrap socket on the original with one of the black TI ones, as can be seen in the pictures.

As for using ribbon cables, I don't know where I'd mount a daughter board if not directly in the original sockets. Mounting options are limited, because the whole boardset needs to be able to slide into the arcade machine's shield cage.

[stj]

as i suspected,
each group of 3 has shared address bus.
so your after a fast memory with 9 address lines and 12 data bits

i would make a small pcb that sits across 3 sockets with a small 16bit tsop flash on it.
mostly because i can salvage those flash chips from old cable / sat boxes.

[westfw]

The 82s131 was a 50ns ROM.  You can get some flash chips that are that fast, but they're not very common.
What IS common is static RAM that is that fast (in particular, the 8bit wide cache RAM from the i486 days.)  I'd be thinking about a daughter-board with a modern static RAM and some microprocessor capable of loading it with the desired initial content...

[stj]

i doubt it needs to be that fast.
it's the dot-clock speed for a 15KHz video signal that it's timed with.

[BrianHG]

For 15Khz video, 70ns = 640 pixels (14.31818Mhz pixel clock), 140ns = 320 pixels without overscan.  These speeds are for a video mode of 240p or 480i but not guaranteed since you may have odd pixel sized clock cycles which do exist.

Note that when changing between address on cmos eproms, their output usually glitches randomly until the data valid time.  Now if your 6 proms have shared address, you might consider using a 32 data bit eprom.  This would make your expansion board just a few address lines + 4 data bits to each bipolar prom connector.  Obviously the extra 8 bits data IOs would be left open and all the extra address lines of the eprom would be tied to ground.

The AT27C1024-45JU is 45ns and only 16 bit, but since it is not dip, it's difficult to deal with.  You wont get faster for an old fashioned eprom.
If it was 1 year ago before I flushed my lab, I could have mailed you a bunch of dip AM27C1024-70, but it's too late for that...

SST39SF010A-70-4C-PHE is an 8 bit 70ns flash device which is 5v eprom compatible, 32 pin dip, but, only 8 bits.  you would need 3 of these.
For some reason, 55ns versions are only available in PLCC...
Arrow electronics has stock of the DIP version.
You will still need an eprom programmer which supports this IC.

[stj]

Now if your 6 proms have shared address, you might consider using a 32 data bit eprom.

no, it's 3 of them with a shared address bus, and then the other 3 share a different address bus.
horizontal res is between 200 and 240, vertical is about 59Hz,
standard RGB, so interlaced frames.

[BrianHG]

Go with 3x 8bit 70ns flash.  Your only addressing the first 512 words, the memory wont even swap a page, your output will be clean and fast.
The forementioned bit glitching should be ignored if the data output is feeding a clocked logic gate or clocked dac as the data is only sampled on the leading clock edge after once it becomes valid.

Note that 16bit proms still exist and are also in the 1-2$ range, but you cant's erase and reprogram them if you make a mistake.  The authentic eprom versions, basically a ceramic case with the eprom window actually costs around 350$.  Yes, 349$ for a glass window!!! (What on earth?)

Just use the oversized Microchip 128k x 8 eprom compatible which is a 32 pin dip, 2$, 70ns, 8 bits, arrange your data in you programmer's memory editor to fill only the first 512 words with the upper & lower 4 of the 8 bits with your prom's contents and hand wire 3 adapter boards for the 6 proms.
On your adapter, remember to tie all the unused addressees to GND.  Double check the chip enable and output enable.

Ohhh, looking at the circuit board, I see a resistor DAC.....
You might want to add a SN74ACT574N (+/- 25 ma/pin VS the eprom +/- read the spec) on the data outs and find the common clock to drive the 574's clock in.  Keep an inverter gate handy in case you need to inverse the clk signal.  This should give you a clean strong bright picture.  Driving the resistor DAC directly from the eprom wont look as good because of low power source and sink outputs.

You can try unclocked buffers like the SN74ACT245N, or 74LS574, or it's unclocked equiv.  This will alter the picture characteristics since the sink and source currents through the resistor divider will affect the picture.  Clocking the eprom will create a clean data output delayed by 1 pixel, but, no glitching introduced by the internals of the eprom.

Without the output buffers, the eprom has a 2v high logic level.  However the 82S131 has a high of 2ma, a sink of 16ma.

[CJay]

Now if your 6 proms have shared address, you might consider using a 32 data bit eprom.

no, it's 3 of them with a shared address bus, and then the other 3 share a different address bus.
horizontal res is between 200 and 240, vertical is about 59Hz,
standard RGB, so interlaced frames.

How wide are the address and data buses?

Do they have separate /CE for all chips or are they paired, I.E. three sets of two 82S123 per /CE?

Is it just one 8 bit data bus per set of three chips?

[BrianHG]

Now if your 6 proms have shared address, you might consider using a 32 data bit eprom.

no, it's 3 of them with a shared address bus, and then the other 3 share a different address bus.
horizontal res is between 200 and 240, vertical is about 59Hz,
standard RGB, so interlaced frames.

How wide are the address buses?

If it's an 82S131, it's 9 bits.
I would also like to know if the output enables are used, or shared, 1 bank of roms could be a background color pallet while the second could be and overlay sprite.  This means only 12 bit color (4 bit red/green/blue - 4096 colors), but your would need to take care of that appropriately.


Looking at the schematic, you would need 4 8 bit eproms, or, 2 16 bit eproms.  Note that the 16bit eproms for some reason, today, only come in SMD unless you want to use an OTP.

[obiwanjacobi]

I've seen One Circuit doing a bunch of repairs on these, perhaps he has some ideas...?

[2c]

[CJay]

Yes, just downloaded and printed the schematic (I love having an a3 printer at work)

Seems the address bus is 9 bits wide with the 9th bit being used to 'bank switch' within the PROMS, the data bus only uses 4 bits from each PROM but is used to generate three independent colour channels with a simple binary DAC arrangement.

So, as you say, two 16bit wide EPROMs or four 8 bit wide ones (though I do wonder if that could be reduced to three given a large enough memory depth)

If my thinking is correct (please correct me if it's not) to generate all possible colour combinations per bank in only 4KiB (16 levels per channel, three channels per bank) so I wonder if a PSOC might be fast enough, one PSOC per bank would be cheaper than EPROM as the prototyping boards are only $4.

[BrianHG]

Yes, just downloaded and printed the schematic (I love having an a3 printer at work)

Seems the address bus is 9 bits wide with the 9th bit being used to 'bank switch' within the PROMS, the data bus only uses 4 bits from each PROM but is used to generate three independent colour channels with a simple binary DAC arrangement.

So, as you say, two 16bit wide EPROMs or four 8 bit wide ones (though I do wonder if that could be reduced to three given a large enough memory depth)

If my thinking is correct (please correct me if it's not) to generate all possible colour combinations per bank in only 4KiB (16 levels per channel, three channels per bank) so I wonder if a PSOC might be fast enough, one PSOC per bank would be cheaper than EPROM as the prototyping boards are only $4.

There are 2 banks of roms because this video game has 2 displays.
The 12 bits are for 4 bit red, 4 bit green, 4 bit blue palette.  They seem to use 8 bit input, 256 colors, and from that a 4096 possible color palette.  The 9th bit on the address input is used for blanking the CRT gun during the horizontal & vertical sync and flyback.  This may mean that when the upper address bit is on, the color may be pure black while during screen display, the color shading may be between shades say 4 and 15, not 0 and 15, 0 being extra black reserved for the H&V raster times so you dont see those horizontal swiggly line on the monitor during the vertical flyback.

[DBecker]

I wonder if that is a gamma corrected output, with 6-7-6 levels of R-G-B.  That would yield 6*7*6 = 252 colors, which would fit neatly into the ROM.

The A8 address bit appears to trigger an alternate palette, perhaps inverted?
The ChipSelect input turns off the PROM to trigger the voltage levels for the sync pulses / blanking interval.

For those that haven't looked at the schematic, the PROM output bits feed resistor DAC,   The output does need a full TTL 5V swing to match the original color level exactly.  But most of the output current is at active-low since this part (like most TTL) can barely output current at a high level.  You could easily use a lower voltage memory with voltage regulator, resistor input divider and output diodes.

[james_s]

I think if I were going to do this, I'd make a custom daughterboard with some EPROMs. 5V capable PLCC32 EPROMs are still reasonably easy to find and the board would be small enough to get 10 boards for 10 bucks plus shipping from Smart-Prototyping. Seeed Studio has similar pricing, the boards cost a bit more but shipping costs a bit less, I usually compare.

[dtxy101]

[Hoffy84]

   Digging up this old thread, as I'd like to continue with this project.

   This color prom adapter was successfully implemented a while back, but in greater depth, and has only been described, but not detailed. The arcade game (Punch-Out!!) can be modified and play both games from the original game board (Punch-Out!! & Super Punch-Out!!) by switching a group of double-stacked eeproms as well as these cluster of proms. The color prom section, comprised of (6) 82S131's looks like it was adapted by a daughterboard that switched between (2) Atmel AT27C1024 44-pin PLCC chips (One for Punch-Out!! and the other for Super Punch-Out!!).

    I'm not interested in making the entire switching PCB, as that part should be pretty straight-forward to do. What I am interested in, is building a daughterboard as the OP subject had started. Below is a pic of the working switchable adapter board that was left out of this thread. It clearly uses a couple AT27C1024's to switch back and forth between two versions of a 6-bank array of 82S131's.

   So... (6) 82S131's = total of 54 address pins & 24 data output pins. If you can use one AT27C1024 which only has 16 address pins & 16 data outs instead, how the heck does that work? Does the data dump to the eproms have to be re-arranged, or do the pins merge, somehow? Or both??  I know the address pins are shared, but not sure how to make this all work. I'm good with Eagle, and have a burner/tester, but newer at this, and not quite sure how the programming/implementation of this can be done.

Any help would be appreciated. - Thanks! Jeff

[PCB.Wiz]

    I'm not interested in making the entire switching PCB, as that part should be pretty straight-forward to do. What I am interested in, is building a daughterboard as the OP subject had started. Below is a pic of the working switchable adapter board that was left out of this thread. It clearly uses a couple AT27C1024's to switch back and forth between two versions of a 6-bank array of 82S131's.

   So... (6) 82S131's = total of 54 address pins & 24 data output pins. If you can use one AT27C1024 which only has 16 address pins & 16 data outs instead, how the heck does that work? Does the data dump to the eproms have to be re-arranged, or do the pins merge, somehow? Or both??  I know the address pins are shared, but not sure how to make this all work. I'm good with Eagle, and have a burner/tester, but newer at this, and not quite sure how the programming/implementation of this can be done.

Any help would be appreciated. - Thanks! Jeff

You need to map the unique pins in that cluster.
There is a good chance the input side has multiple connections to each 82S131, but the 24 outputs are likely mostly used, so you would need at least 2 x 16i 16o 27C2014's
Do you have the 82S131's ? - you could dump the memory and extract the boolean logic.

The boolean logic allows you to explore using SPLD/CPLD like 22V10 or ATF1502 or ATF1504

The 82S131 looks to have 9 address pins and 4 outputs, not registered, 50ns 

In boolean terms, one of those could map onto a single 16V8, assuming no boolean combination exceeds 8 lines.
A 22V10 has more product terms on some pins  and the ATF150x parts can have even more boolean equation lines.

[peter-h]

A lot of normal EPROMs do <50ns if /CE is tied to GND and especially if /OE is tied to ground.

The normal quoted access time is from the address setup to data out, and in most EPROM applications the address gets set up much earlier.

But anyway as stated above the 50ns is very unlikely to be needed. In the 1980s it would have been hard work to build a PCB full of logic that fast, so most likely somebody used those chips because they were convenient. I used 256x8 fusible link PROMs (AMD Schottky TTL - ran pretty hot) in my final year at univ, 1978, where I designed somebody's else's final year project - a sine/triangle/square waveform generator, with the PROM holding the tables. The 8 data bits went straight to an 8-bit DAC, whose output had a ~100pF cap to GND to supress the glitches I could have used a 2708 or similar EPROM but these AMD chips were just handy, and easy to program.

[harerod]

1.5kBit with 50ns access time - has anybody tried using a modern microcontroller, possibly programmed in assembly language?
If the required timing is actually more relaxed (15kHz video clock), an AVR may be sufficient. Otherwise an STM32 might do the trick.
(I haven't followed the links, so don't stone me, if they describe this concept there.)

[PCB.Wiz]

1.5kBit with 50ns access time - has anybody tried using a modern microcontroller, possibly programmed in assembly language?
If the required timing is actually more relaxed (15kHz video clock), an AVR may be sufficient. Otherwise an STM32 might do the trick.
(I haven't followed the links, so don't stone me, if they describe this concept there.)

50ns is too short to hit with MCUs running boolean logic.
Some new MCUs have modest Config Logic Blocks, and some cypress ones have significant logic included, but they are not an ideal solution here.

A lot of normal EPROMs do <50ns if /CE is tied to GND and especially if /OE is tied to ground.
The normal quoted access time is from the address setup to data out, and in most EPROM applications the address gets set up much earlier.

Some pins are also faster than others, but often not clearly defined in the data.
Memories have an XY array, so some lines are post memory MUXes and some are memory element selectors.

The 82S131 data suggests A0..A3 are faster pins than A4..A8.

[Hoffy84]

The debate isn’t really about which chip would be best. The first pic I posted shows an already working board that also has switching abilities between two different games. (which I don’t need at this time).

They successfully used (1) AT27C1024 to sub (6) 82S131's.  I’m just trying to figure out how the traces will go from that to the 6 older proms, and if I need to re-arrange the data when I burn it to the AT27C1024.

Below is the specific section of the schematic, and highlighted are the cluster of (6) 82S131's I'm trying to sub with (1) AT27C1024 .

[pcprogrammer]

Unless you reduce on the number of colors I guess you can't do it with only one chip. The AT27C1024 is 16 bits wide and you need 24 bits. And then still it would be difficult to figure out what the data needs to be inside the EPROM. Also with only 16 address lines you are two short because you need 18 for the full range.

The picture of the board you posted shows two chips, but I can't read the text on the chips.

What I think is done there is that they only use 12 of the 16 bits to route to the resistor based DAC's. So 1 AT27C1024 replaces 3 82S131's

For the address lines just ground the ones you don't use. (A9-A15)

Edit: when you look at the traces on the board and the schematic you can imagine that P1 is connected to 8F, 8E and 7F and P2 is connected to 7F, 6F and 6E.
To allow switching between the two games they may have used an additional address line (A9), which could be the wire coming from the left side of the board.

[PCB.Wiz]

Below is the specific section of the schematic, and highlighted are the cluster of (6) 82S131's I'm trying to sub with (1) AT27C1024 .

The problem here looks to be a simple output-pin count issue. You cannot map the 24 used pins onto 16 of 24C1024, without dropping 8 pins.

You will need (2) AT27C1024, so easiest done as 12 pins each.
You can however, have identical code in both memories, by using a spare address pin to select which table is used. That makes handling and design much simpler. A single file to generate and just 2 copies made.

[Hoffy84]

Below is the specific section of the schematic, and highlighted are the cluster of (6) 82S131's I'm trying to sub with (1) AT27C1024 .

The problem here looks to be a simple output-pin count issue. You cannot map the 24 used pins onto 16 of 24C1024, without dropping 8 pins.

You will need (2) AT27C1024, so easiest done as 12 pins each.
You can however, have identical code in both memories, by using a spare address pin to select which table is used. That makes handling and design much simpler. A single file to generate and just 2 copies made.

Crap. I didn't even think about the possibility that those two Eproms could have been split to accommodate all the address lines. I thought that part 1 and part 2 of the games were stored on their own respective Eproms, separately.

So if I'm going to do this, then I might as well design the PCB like the original pic I posted that switches back and forth between both games, stacking the data split onto each.

Are you saying (in the case I'd use two ATC271024's ): to have address lines A0 thru A11 serve 3 of the 82S131's and the other set up the same way? To switch banks between games, switch input A12 on both, and tie the remaining unused address lines to ground? Do I have that right? Or is there a specific pin that needs to used to bank switch the eproms? (I think you use the next one up, but not sure)

[pcprogrammer]

Take a good look at the schematics. There are only 9 address lines used for the 3 proms in the SC bank and the same for the MC bank.

Pin 14 on the proms is A8. The schematic is not showing this for each of the chips, just between the two sections, but they will be connected.

So all you need is A0-A8 for the standard system. Use A9 to select between the two games. It is not clear where CS comes from, but just connect it to both the eproms on CE.

And yes connect the remaining address pins to ground. Also make sure to ground things like output enable.

Edit: Leave the unused data lines floating. Only 12 of the 16 data lines are needed. The bank select for the two different games could just come from a switch.

[Hoffy84]

Take a good look at the schematics. There are only 9 address lines used for the 3 proms in the SC bank and the same for the MC bank.

Pin 14 on the proms is A8. The schematic is not showing this for each of the chips, just between the two sections, but they will be connected.

So all you need is A0-A8 for the standard system. Use A9 to select between the two games. It is not clear where CS comes from, but just connect it to both the eproms on CE.

And yes connect the remaining address pins to ground. Also make sure to ground things like output enable.

Edit: Leave the unused data lines floating. Only 12 of the 16 data lines are needed. The bank select for the two different games could just come from a switch.

Hmmm, this is making a lot more sense to me now. A close up pic below of the mystery board looks like it's identical to what you're describing. (The soldered pins are quite revealing now).

The red arrows show all the address lines are connected to the first socket 6E, which is shared to 6F and 7F.
Same with the other chip: all connected to 7E and shared with 8E and 8F. (None of those other subsequent address pins are needed).

The blue arrows show all the individual data outs ARE populated, accordingly.

Thank you all for your help! This is pointing me in the right direction, and now I can start exploring....

[pcprogrammer]

In your new eproms also make sure to have the not used data bits (lines) be the same value. This way the floating pins stay on the same level and won't cause interference. Probably best to keep them 1.

Success with making a board.

[Hoffy84]

In your new eproms also make sure to have the not used data bits (lines) be the same value. This way the floating pins stay on the same level and won't cause interference. Probably best to keep them 1.

Success with making a board.

Oh? How would I do that? On the Atmel spec sheet, it says to disable the outputs, designate the pins High-Z (Leave floating / I think). But to set them to 1, is that done in the hex editor (like HxD)? Or can you recommend a better one?

[pcprogrammer]

You have to program these new eproms with the data from the old ones. The old ones are 4 bits each and the new one is 16 bits.

This means you have to combine the 3 x 4 bits to 12 bits and then extend to 16 bits.

So the first action is to read the 6 proms from your board and then combine the nibbles from the 3 that belong together. The order of combining depends on how you connect the data lines on your new board.

Lets say you connect D0-D3 to 6E and D4-D7 to 6F and D8-D11 to 7F and leave D12-D15 unconnected, you have to take the first nibble of 6E and put it in the lowest nibble of the 16 bits data. Then the first nibble of 6F and put that in the second lowest, and the one from 7F goes in the third lowest. The last nibble is set to 0xF (All ones).

So the data looks like 0xFZYX, where Z is data from chip 7F, Y from 6F and X from 6E.

Edit1: yes you could use a hex editor, or if you know a bit of programming write a simple bit of code to do it for you
Edit2: Looking back I should have used "leave the not used data lines unconnected" 

[Hoffy84]

You have to program these new eproms with the data from the old ones. The old ones are 4 bits each and the new one is 16 bits.

This means you have to combine the 3 x 4 bits to 12 bits and then extend to 16 bits.

So the first action is to read the 6 proms from your board and then combine the nibbles from the 3 that belong together. The order of combining depends on how you connect the data lines on your new board.

Lets say you connect D0-D3 to 6E and D4-D7 to 6F and D8-D11 to 7F and leave D12-D15 unconnected, you have to take the first nibble of 6E and put it in the lowest nibble of the 16 bits data. Then the first nibble of 6F and put that in the second lowest, and the one from 7F goes in the third lowest. The last nibble is set to 0xF (All ones).

So the data looks like 0xFZYX, where Z is data from chip 7F, Y from 6F and X from 6E.

Edit1: yes you could use a hex editor, or if you know a bit of programming write a simple bit of code to do it for you
Edit2: Looking back I should have used "leave the not used data lines unconnected" 

Looks like I have a lot to learn! LOL! Thank you for being patient with me, and I really appreciate the guidance!

[Hoffy84]

You have to program these new eproms with the data from the old ones. The old ones are 4 bits each and the new one is 16 bits.

This means you have to combine the 3 x 4 bits to 12 bits and then extend to 16 bits.

So the first action is to read the 6 proms from your board and then combine the nibbles from the 3 that belong together. The order of combining depends on how you connect the data lines on your new board.

Lets say you connect D0-D3 to 6E and D4-D7 to 6F and D8-D11 to 7F and leave D12-D15 unconnected, you have to take the first nibble of 6E and put it in the lowest nibble of the 16 bits data. Then the first nibble of 6F and put that in the second lowest, and the one from 7F goes in the third lowest. The last nibble is set to 0xF (All ones).

So the data looks like 0xFZYX, where Z is data from chip 7F, Y from 6F and X from 6E.

Edit1: yes you could use a hex editor, or if you know a bit of programming write a simple bit of code to do it for you
Edit2: Looking back I should have used "leave the not used data lines unconnected" 

Looks like I have a lot to learn! LOL! Thank you for being patient with me, and I really appreciate the guidance!

Trying to wrap my mind around this: So using your example from above, In my hex editor every two digits is 1-Byte. Half a byte is a nibble (or 4-bits). Below is what I pulled from 6E, 6F, & 7F. Where I highlighted in blue (I'm only using that position since it is more unique than the first row). I basically need to figure out a code to get it to come out like this, and repeat that calculation left to right, top to bottom? In other words, would the next byte string where I highlighted yellow be next, and so on? Each of these sets of 4 come out to 32 bits, though. Shouldn't they be 16 to match the outputs?

 

[abyrvalg]

I've coded a quick&dirty Python script to combine the data (and used ROMs from wowroms.com, your Punch-Out dump seems to match it), ran it and packaged everything together:

[PCB.Wiz]

Below is the specific section of the schematic, and highlighted are the cluster of (6) 82S131's I'm trying to sub with (1) AT27C1024 .

The problem here looks to be a simple output-pin count issue. You cannot map the 24 used pins onto 16 of 24C1024, without dropping 8 pins.

You will need (2) AT27C1024, so easiest done as 12 pins each.
You can however, have identical code in both memories, by using a spare address pin to select which table is used. That makes handling and design much simpler. A single file to generate and just 2 copies made.

Crap. I didn't even think about the possibility that those two Eproms could have been split to accommodate all the address lines. I thought that part 1 and part 2 of the games were stored on their own respective Eproms, separately.

So if I'm going to do this, then I might as well design the PCB like the original pic I posted that switches back and forth between both games, stacking the data split onto each.

Are you saying (in the case I'd use two ATC271024's ): to have address lines A0 thru A11 serve 3 of the 82S131's and the other set up the same way? To switch banks between games, switch input A12 on both, and tie the remaining unused address lines to ground? Do I have that right? Or is there a specific pin that needs to used to bank switch the eproms? (I think you use the next one up, but not sure)

I was thinking about the case if the groups of 3 ROMs , are not identical  - ie if the patterns in 8F 8E 7E do not match  7F 6F 6E, then you can fit both patterns into the programming file, and an Address pin can be  hard wired HI for one and low for the other.

If doing a board, you may like to have resistors or a DIP sw + resistors on the extra 'unused' address lines. That lets you fill the EPROM with useful stuff, and you can experiment.
Usually unused address input pins, would pull down to GND, so that your HEX info starts from 0x0000 for simplicity.


 

[pcprogrammer]

Maybe a bit late with my reply, but need my sleep and the world has different time zones

Trying to wrap my mind around this: So using your example from above, In my hex editor every two digits is 1-Byte. Half a byte is a nibble (or 4-bits). Below is what I pulled from 6E, 6F, & 7F. Where I highlighted in blue (I'm only using that position since it is more unique than the first row). I basically need to figure out a code to get it to come out like this, and repeat that calculation left to right, top to bottom? In other words, would the next byte string where I highlighted yellow be next, and so on? Each of these sets of 4 come out to 32 bits, though. Shouldn't they be 16 to match the outputs?

The data in your picture shows that per byte only the lower 4 bits are used. See my picture with the red rectangles indicating this. These are the X, Y, Z parts I wrote about.



The first row shows all the bits set for each nibble. In your new eprom this means the first two bytes should be 0xFF, 0xFF, the ones I marked on the third row lead to 0xF6 0x88, and to know how this maps into the eprom I would have to look at the data sheet and programmers manual if it is little or big endian. This means if the least significant byte comes first or last. For your marked data it would be 0xF7 0x50 for the blue and 0xF9 0x73 for the yellow.

The order of the resulting bytes depend on how the programmer presents them to the eprom.

But it might well be that abyrvalg did what is needed with his python script and the data he found online.

[abyrvalg]

My script outputs little endian data (change “<H” to “>H” to switch to BE). Actually, nothing forces you to use specific bit/pin order at all, the only requirement is addresses to addresses, data to data. I would route the board first in a convenient way, then generate the programming data with bits shuffled according to the schematic.

[pcprogrammer]

My script outputs little endian data (change “<H” to “>H” to switch to BE). Actually, nothing forces you to use specific bit/pin order at all, the only requirement is addresses to addresses, data to data. I would route the board first in a convenient way, then generate the programming data with bits shuffled according to the schematic.

Yes that is a good point, but shuffling either the address lines or the data lines or both makes getting the correct data to go into the eproms harder and requires more software skills to get it done. I think that routing the board in the most logical order for the address and data lines is much easier.

[Hoffy84]

My script outputs little endian data (change “<H” to “>H” to switch to BE). Actually, nothing forces you to use specific bit/pin order at all, the only requirement is addresses to addresses, data to data. I would route the board first in a convenient way, then generate the programming data with bits shuffled according to the schematic.

Yes that is a good point, but shuffling either the address lines or the data lines or both makes getting the correct data to go into the eproms harder and requires more software skills to get it done. I think that routing the board in the most logical order for the address and data lines is much easier.

Holy Smokes guys! First of all: Abyrvalg, THANK YOU for writing that script. That just shot me ahead light years! I am truly grateful for that; you've saved me a ton of time. I've never used Python, but it seems similar to Arduino which I'm more familiar with. Long story short: there are actually two code variants of each (set of 3) 82S131's. I ran multiple tests with your script, compared them with my specific ones, and they were dead on. So I guess that Rom site coincidentally had my exact combo.

pcprogrammer : I like your idea of keeping things linear to the schematic, so I compared the same 3 proms as before, and I guess the script should be run in BIG Endian, because the spots weren't landing like you described a few posts earlier. They were there, but out of order. So I changed  Abyrvalg's Python script like he suggested changing the value to ">H" for BIG E , and now everything is lining up as you described. See pic below. (Most notable example in the 04 column of the original proms) Would this be written correctly (where I circled in red) for the written data to line up with how you described, and with the output data in the schematic? I think I have it right, but this whole front-to-back back-to-front data vs prom order is messing with my pea-brain!
 

[pcprogrammer]

Yes this will be correct as long as the data ends up in the eprom such that byte 0 of your file is outputted on D15-D8 and byte 1 on D7-D0, byte 2 on D15-D8, byte 3 on D7-D0 and so on.

If the eprom does it the other way round the little endian option would be needed. To make sure, I would program an eprom first and check what the outcome is on a bread board, and then design your PCB accordingly. It takes a bit of elbow grease when done with a multi meter to check the bits, but you only need to verify a couple of distinct ones.

Since the AT27C1024 are only one time programmable this would be my way of doing it without having more knowledge about it.

[abyrvalg]

AT27C1024 itself has no endianness at all (that’s a thing of dual mode 8/16 bit ROMs). The question is how does your prommer sw combines individual bytes from an input file into 16-bit words being programmed. Usually there is an option when loading a file or it is indicated somewhere or the hex view shows 16-bit values clearly. If you are not sure - follow pcprogrammer’s advice and do a test on a real programmed ROM (since it’s OTP I’d program the topmost address to something like FF00, leaving all other cells in FFFF state, so this ROM could be reused).

Shuffling bit orders - agree, keeping things clear is easier, but you can choose the most routing-friendly R, G, B order at least (by changing file orders in each group of 3, see my comments in the script).

[Hoffy84]

Agreed that the 27C1024 doesn’t care, and neither did the original 82S131’s. Neither data sheet shows any info on one format or the other.

I’m using a GQ-4x reader/writer, and hadn’t even thought of loading into that software. (I’ve been looking at everything up til now in HxD and Notepad++).  I tried the original raw data in the GQ-4X software and it reads the same way (big endian). I’m going to assume that’s just how it’ll go in and get some extra new chips to be on the safe side.

Although the GQ-4x programmer cannot do 82S proms, I have an adapter that can, and maybe I’ll take some samples of the actual chips.  Will post a follow-up eventually and let you know how it all turned out. Thank you so much for your support!

[Hoffy84]

Hey guys, one final concern: In respects to A9 being the bank switch pin between the two games, I was planning running a switching signal wire: A9 to ground for the upper address half, and A9 to 5V for the lower address half, but noticed this (pic) where I highlighted, about A9 being a "product identifier" ? Not sure what that means, and if i should use a different address pin to switch. Any ideas? - Thanks!

>> Edit: I just noticed the differences between VIH (5V) and VH (12V). Maybe as long as we're only talking 5V, all should be OK? The spec sheets can be cryptic, sometimes. 

[PCB.Wiz]

Hey guys, one final concern: In respects to A9 being the bank switch pin between the two games, I was planning running a switching signal wire: A9 to ground for the upper address half, and A9 to 5V for the lower address half, but noticed this (pic) where I highlighted, about A9 being a "product identifier" ? Not sure what that means, and if i should use a different address pin to switch. Any ideas? - Thanks!

>> Edit: I just noticed the differences between VIH (5V) and VH (12V). Maybe as long as we're only talking 5V, all should be OK? The spec sheets can be cryptic, sometimes.

Yes, that's only used by device programmers to check / confirm device ID.
Unless you were planning to program the parts on the board,  you can just treat it as a logic pin.

[Hoffy84]

Yes, that's only used by device programmers to check / confirm device ID.
Unless you were planning to program the parts on the board,  you can just treat it as a logic pin.

Well.... DUH! LOL! Thanks PCB.WIZ !!