$64,000 question: 2x 8 bit --> 1x 16bit - how?
 

This may be a 'software' question, but I'd expect better answers here.
I am trying to rescue a guy with a stone aged industrial pc in an otherwise functional but long obsolete machine.

The pc board went funny, he's buying new, and the software is 16 bits wide in 2x8bit eproms which I will only be able to recover in 2x 8bit hex files. I will need to pair them this way

Eprom 1 | Bits 0-7
Eprom 2 | Bits 8-15

in a single file. This file will be the new pc software. How can that be done, matching byte offsets? :-Q (=:-\ + :-O)

BTW, it could also be done by writing a byte, skipping 1, writing 1, skipping 1 etc and then doing the others.

Bizarre and obtuse ideas welcomed.

Wouldn't the byte order depend on the specific processor? And, unless the processor in the new board is identical to the one in the prehistoric board, why would you expect the old binary code to work in the new board? :scratch:

Not sure that this is bizarre enough or obtuse enough for you but:

• I assume that the original processor is something like an 8088 and the replacement is similar but with a 16 bit bus...that is not enough to guarantee that the same code will run, given that peripherals may be different and the code will run faster, and it sounds as if you are in a bad position to cope with any code revisions that might be necessary
• you'll have to use an eprom programmer to program the new eproms, some of these can do fancy shuffle functions
• perhaps better still, if you look at the the format used to download the data from a computer to the eprom programmer (Motorola Hex or Intel Hex, most likely), you can do a fair amount of rearrangement of the data, so you could upload the data to a computer, (back up!), process with awk/sed or something else, and send it back to the programmer and it doesn't have to be sent in the right order, because the addresses are embedded in the file download format

Just be a bit careful with the upload/dowloads as it easy to lose a few bytes here and there, if the receiving end can't cope with the speed using RS 232 (probably because flow control is wrong)

So the old processor was like an 8088 (8 bits databus), and the new one a 8086 (16 bits databus)?

What makes you think the EPROM layout was like but 0-7 on one EPROM and 8-15 on the other? It is equally likely that EPROM #1 contained a lineair range from (say) 0 - FFFF and EPROM #2 10000 - 1FFFF instead of what you expect: EPROM #1 all even addresses from 0 to 1FFFE and EPROM #2 all odd adresses from 1 to 1FFFF. Unless you have the schematic of the old board you cannot be sure, but it was unusual to design boards with such a low bits / high bits scheme.

Does the new board indeed a 16 bits EPROM path? In the early days of 16 bits processors it was not unusual to use 2 8-bit EPROMs being addressed at the same time. This would fit in with your idea that 1 EPROM holds the low bits and the other one the high bits BTW.

jlinkels

I was intending to reverse engineer that bit when I get my hands on it.

Let's say you're right, and I'm wrong. The old board had these 2 eproms as drive A: (I think). I imagine the new will have ssd or hd, or maybe I can run a floppy. The company making the machines closed about 10 years ago. There is also a Mostek Battery Backed Ram chip with the internal battery which will be dead, and the data probably gone.

Have I a snowball's chance in hell of getting this guy going? If so, I'll need to transmogrify whatever I get from the eproms to 16 bit code. How?

I didn't examine the eproms in detail. There are 2 large eproms. The way this came at me is that somebody preyed on me to have a look at one last circuit board(I used to fix pcbs in times gone by, but closed up in 2006). I said it was perfect(Always the hardest call) and dropped it back, and took a look. When the machine powered on, I saw a bios screen. I told them there was a pc in there somewhere, (news to them!) and presently extracted the pc board. It had a boot error, and no drives were connected. So I laid it on the manager's desk, told him to buy one, and ran. He's taking a punt on a non compatible one, and hoping I can work another miracle for them.

I would just write a C program or Perl script to rearrange the bits like you said, and then try it out. Chances are low, but maybe it'll work.

Isn't that irritating, when you want to have an answer to a simple question, and then people start telling you you question is wrong?

Anyway, let's assume this really is the case:
Then simply create a socket from IC sockets, connect the address lines and read strobes to both EPROMS, and connect D0-D7 of EPROM#1 to D0-D7 on the board, and connect D0-D7 of EPROM#2 to D8-D15 on the board. This is exactly how the original layout of a 8086 was designed.

But then again, it is highly unlikely that the memory was organized in this way in the 8-bits design.

Furthermore, I would study the 8086 data sheet to see how byte addressing is performed, using a combination of BHE\ and A0.

jlinkels

It wasn't really a simple question, or I wouldn't have asked it ;-)

It doesn't really matter how the data is arranged, as long as I get the reverse engineering right. I can read them in by making hardware to do it, but I'll have to think of something to read them into. If I have to design & manufacture a complicated device to do this job once, that's a royal PITA which affects the viability of the project.

/BHE? It's running on a '486. The usual thing is that as the address is set, the data bus is floated (high) and pulled low in places by the data on a read. I don't see what A0 in particular has to do with it? I haven't grokked a data sheet on 80xx in (many) years.