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.)
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.
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 .
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.
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.
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)
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.
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....
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.
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?
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"
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!
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?
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:
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.
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.
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.
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.
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!
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.
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).
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!
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.
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.
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 !!