8-bit width vs. 16-bit width?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Ok, so I'm working with a system where the ROM board at minimum needs two 8-bit-wide ROM chips; one stores the LSBs and the other stores the MSBs.

The 8-bit LSB file might have data:
x00 0101 0101
x01 0010 0010

And the 8-bit MSB file might have data:
x00 1010 1010
x01 1101 1101

So, would the combined 16-bit file would look like this:
x00 1010 1010 0101 0101
x01 1101 1101 0010 0010

??

I think that's the way it works... It shouldn't be too hard to mash the two files together with some scripting, construct a byte table, and load the new file into a uC for some testing. If the test works, I can load up a single 16-bit-wide chip and cross my fingers.

For simply emulating the new ROM chip, I need the 14 address lines, 16 data lines... and... that's all? There were ship-select signals used in the original layout, but if all the software is going onto a single chip, I shouldn't need it (right?). The Teensy 3.1 has 34x 5v level tolerant I/O pins and should be quick enough. Plan right now is to pull all the original ROM chips, and pipe the data and address lines through to the uC, keeping the original buffers in place.

Does all that sounds sane to those in-the-know? I know I got into this stuff in school, but I've never had to use it.
 
Last edited:
Hi,

If they drive a 16 bit data bus and simply share the address
bus then they are simply equivalent to a 16 bit chip.

If they don't (its an 8 bit data bus) then shenanigans are
required to read 16 bit data, usually fixed address offsets.

For the latter a 16 bit wide chip is just pointless.

rgds, sreten.
 
Last edited:
Like sreten says, the bus architecture will define whether you can use the 16b ROM. Are there 8 or 16 data lines? Do the ROMs get the same chip select signal or are they separate? You can only do this if there are 16 data lines and the two 8b chips get identical control signals.

You cannot ditch the control (CS, OE, etc) lines, they're used to make sure the ROM isn't hogging the bus when other devices in different address ranges are being accessed.

If the bus architecture is physically compatible with a 16b ROM, the easiest way to combine the two ROMs is to use a C (or other language of your choice that supports byte arrays and binary file IO) program to interleave the bytes. Or best option yet, get the original linear ROM image from the assembler before it got split into even and odd bytes. Don't faff about with text mangling, it's the quickest way to introduce byte- and bit-order errors.

Don't try doing ROM emulation with a micro, it's probably not fast enough. Get a handful of 29F040 or similar - they're cheap and come in socketable DIP, and you can program them pretty quickly/easily with a micro. Once programmed, they look just like a ROM. If you don't need the whole address space, tie the spare address lines low. If your system has an 8 bit bus (8 D lines, separate CS for each ROM) then you can use a single large chip to emulate all of the smaller ROMs by synthesising address lines to the 29F from the different CS bits.
 
I'm modifying an old oscilloscope from the 70s; the four original 24-pin ROMs went bad. A common hack is to try and rewire two 28-pin EPROMs in their place. A future version of the oscilloscope combined the RAM and ROM cards into a single board--the RAM and ROM chips share address and data busses. My plan was to replace the four original roms with (potentially) a single ROM device as well as maxing out the trace storage RAM for the thing.

All four ROM chips share address busses, while two ROM chips get data lines 0 through 7, and the other two get 8 through 15--in essence the CPU sees a 16-bit wide ROM.

The processor is a TI TMS9900. The third page of the manual says this about the architecture:

KHevb96.png



As a quick verification that there's nothing wrong with anything else is this thing, I was going to try to get a uC with a byte table built up as a way to check functionality of everything.
 
Last edited:
OK, so the TMS9900 has a 16-bit bus and you could put a 16 bit ROM in there if you want to and it will be fine.

What you're talking about building is a "ROM emulator" and it's a commonly-built thing for debugging. However you need to decode the address and get the data onto the bus very quickly in order to meet the CPU's timing requirements and a microcontroller is not fast enough. The usual approach to ROM emulation is to use either flash (as per my previous suggestion) or SRAM. You power up the SRAM, download an image to it using your microcontroller while the main CPU is held in reset and then let the main CPU start. SRAM is plenty fast enough and contains all the necessary logic to directly interface to a CPU bus like this.

Flash is really easy - you make an adapter PCB so that it can plug into a normal ROM socket, and a piggy-back interface (with access to the WE pin, etc) for flashing it via your micro. The flash is (IMHO) the best option long-term, because once it's working you just leave it in there.

Do you know the address-synthesis logic you'll need to implement when using one larger chip to represent multiple smaller ones? And for maxing out the RAM, do you know how to generate the new CS signals from the higher address bits? Specifically, do you have a diagram of the memory map showing where the additional RAM should be placed?
 
Last edited:
DigiKey has 16 bit wide devices here,

Invalid Request

Here is a 64Kx 16bit PROM from Atmel in a 40 pin DIP package for about 4$,

Invalid Request

Here is the datasheet,

http://www.atmel.com/Images/doc0019.pdf


There are many types available in RAM, EPROM, EEPROM,PROM and FlASH, depending on the size you need all of the way up to 36bits wide.

I just got a few SST39SF040 512Kx8 bit FlASH ram's from microchip in a 32-PDIP and they are under $2 I think.

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en549494

Cypress and maybe ST has 16bit versions.
I was recently looking for some 16bit wide ram's to use in a project as well and they are available.

jer :)

P.S. The links say "invalid request" but they seem to work for me as they go to Digikey's parametric search page.
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.