Question on retro computing (trying to combine two roms)

[Kevin Mitchell]

Without getting into great detail on what it is I'm actually working on...

I'm trying to replace two 2732 EPROMs with one 28C64 EEPROM. Folks had success replacing a single EPROM by rerouting the power pin and grounding the extra A12 address pin.

In the intended circuit the two roms are connected completely in parallel. I would like to "stack" the bin files and program them into one 28C64 (assuming this is possible).

I was looking up common ways to combine the bin files and had success converting the two 4KB bins into a single 8KB bin by creating a .bat file with the command "COPY /B file1.bin + file2.bin file3.bin" Though it produced what I wanted, I have no idea if it'll operate as I expect.

It's worth noting that some of the latest versions of what I'm working on only had a single 2732 EPROM and replaced the 2nd with NV ram with the same pins. And also this is my first time doing anything diy computer related outside of programming Arduinos.

I'm here searching for advice or a big thumbs up that I'm on the right track. Always asking for a friend.

Right now I need to know if combining two bin files as I had will work the same as running two separate eproms connected in parallel.

-KM

[vigilante397]

I don't have a solid yes/no answer for you, but it sounds like you're on the right track. I will say that one of the glorious things about digital is how simple and cheap it is to guess-and-check. In this case I think the worst-case scenario is it won't work, but it shouldn't break anything (if you fry anything from trying to improperly flash an EEPROM then you have an entirely different problem). So give it a go, and let us know!

When I flash an EEPROM I like to read the EEPROM afterwards and visually compare the machine code, which usually looks like gibberish, to the file I flashed, to make sure that it at least looks like the same gibberish and didn't get messed up anywhere. Obviously this doesn't give you any verification that it's going to work, but it at least gives a basic verification that the flash was successful. Not sure if that's helpful, but that's about the limit of my EEPROM advice I can give

[Kevin Mitchell]

And that's why I got the EEPROM instead of the 2732 (21v program voltage, UV erasable EPROM). That would be an absolute nightmare to play with trail and error style . Also the budget programmers don't support 21 volts and I'd also have to buy a UV oven to reset the damn thing.

I suppose I could do some experiments to see if the combined bins behave as expected. I just can't (or wouldn't) do it to the final circuit. God forbid something doesn't work at least I could negate the EEPROM.

Thanks! I'll report back my findings.

-KM

[pruttelherrie]

You can use a hex-editor to check if the bytes of the higher-mapped block aligns on the correct byte in the file (after merging).

[Kevin Mitchell]

Do you mean make sure the joined bin file shows the 2nd bin data starts & matches where the 1st bin data ends?

Just trying to understand. This is all new to me.

It looks like exact copies of the bin files, one after the other.

Top is the end of bin file1
Middle is start of bin file 2
Bottom is where they meet in the combined bin file (observe address lines)


-KM

[pruttelherrie]

That looks good, but what I meant was that you need to be sure that contents of the second bin, starts on the address of the PROM that you are toggling with the address line.

In your screenshots, the second bin starts at address 16.

In your case with the 32kbit EPROMS, the second bin should start after 4 kbyte.
It seems that if your first bin is exactly 4096 bytes big, it should concatenate (copy) OK. Unless I'm missing something, which I sometimes tend to do.

[pruttelherrie]

By the way, why does it say 0000 100F in the bottom screenshot? Shouldn't that be 0000 1000 ?

The line with 0000 1010 looks to continue ok, but I'm confused.

[Kevin Mitchell]

I think that's just me not knowing what I'm doing.

It is actually 00001000. I must of had the cursor at the end of the line which changed the last digit to show as a F instead of a 0. Using FLEXHEX for the first time. This is all new to me.

I'll be off to learn more about binary, hex and addressing. I just want to know if this is a sure way to combine bin files that were previously set up to run in parallel.

EDIT: I'm just now noticing that the OE pins are actually not connected together! They get separate lines from the address decoder.

Not sure what that entails but I believe it'll work as it should if all the data is on one chip. Gotta tinker.

-KM

[pruttelherrie]

Gotta tinker.

[Kevin Mitchell]

Another question, does it matter what address and data pins connect to the ram - so long as it's reading the same pins it wrote to?

The circuit I'm looking at mismatches some of the pins. Wondering if it's only for layout conveniences and not tied to the software. Meaning one could reroute the pins in any other way without issues.

-KM

[anotherjim]

Some commercial products actually scramble A & D pins deliberately. Either to make pcb traces simpler or to hinder code stealing. A ROM taken out and plugged into a reader will give garbage code but plug it into a copier and the copies will be fine.
Like you say, if its read as it was written, the scrambling has no effect, but if you are using the same ROM in something else, you have to use the same bus connections.
I've seen static RAMs with "wrong" bus order, but that had to be for layout reasons.
There was a thing with some dynamic RAM chips where you could get corruption if adjacent cells were written sequentially, so the addressing was scrambled so it would be less likely.

[Kevin Mitchell]

Some commercial products actually scramble A & D pins deliberately. Either to make pcb traces simpler or to hinder code stealing. A ROM taken out and plugged into a reader will give garbage code but plug it into a copier and the copies will be fine.
Like you say, if its read as it was written, the scrambling has no effect, but if you are using the same ROM in something else, you have to use the same bus connections.
I've seen static RAMs with "wrong" bus order, but that had to be for layout reasons.
There was a thing with some dynamic RAM chips where you could get corruption if adjacent cells were written sequentially, so the addressing was scrambled so it would be less likely.

Wow I'm glad I had asked!

In the case of volatile memory and blank NV memory, writing and reading to different pins shouldn't be a problem - theoretically. Is this correct?

I'm wondering if I could replicate a circuit, use a copy of the ROM data and route the A and D pins to the static RAM differently without any problems.

-KM

[anotherjim]

If they're capable of random access, scrambling pins shouldn't be a problem. Some early EEPROM's were random read/sequencial write - slower write because of extra setup times inside. You might find you can freely change data pins but only the low order address pins because the cells are arranged in blocks selected by the higher address bits. With those see what the data sheets hint at - such things are often in small print notes.

PCM sound ROM scrambling is quite common...
https://zeninstruments.blogspot.com/2015/10/rom-unscramblers.html

[Kevin Mitchell]

Here's a cutout from the service sheet;


In an earlier version - with four times as many NV RAM chips all off the A and D pins coincide with the part's datasheet. The scratchpad ram routing stayed the same as the image above.

Perhaps I'll just keep it as is to avoid any mistakes. Or just breadboard the thing to indulge my curiosity.


I'll let you guys in on a secret.


-KM

[anotherjim]

I can't find data for the NVRAM, but the low order address bit scrambling suggest its ok for full random access like a plain static RAM would be. So it would only have been for ease of trace routing that they did it that way.

I think I saw some of your P5 musings elsewhere?

[Kevin Mitchell]

I think I saw some of your P5 musings elsewhere?

Yeah the synth forum. I had asked some simple questions to know how the computer board works.

This forum is home base. Lot's of nonsense happens over there. I had posted the same question about the RAM and got one irrelevant reply. There's more of a family sense at DIYSB. Folks look out for each other here.

The RAM;
2114
4334 substitute
Service note;
"The eight 6508 (1K x1) NV RAM was changed to U383/84, two 4334 or 6514 (1K x4)."

-KM

[anotherjim]

Ah, the NVRAM is only non-volatile because of a battery backed supply? Those particular chips chosen for low retention voltage, otherwise they are just SRAM.
In which case they can definately be freely scrambled.

[Kevin Mitchell]

Awesome! Thanks for confirming. I'm likely going to breadboard the computer board just to be sure.

-KM

[Kevin Mitchell]

I'm sure a few folks had thought of me as SC announced their P5 rev 4 last Friday.

The promo video shows a little of the inside of the unit. How the hell did they fit the cpu, dac, summers, demux and 5 voices with two versions of the filter onto what looks to be a 8x10 board?

I demand answers   

-KM

[pruttelherrie]

I'll let you guys in on a secret.

Nice. Is the misspelling of 'FREQUENCY' intentional?

And where do you get those buttons with leds? (Program Select etc).