The fastest through-hole EEPROM I can find is 70ns and 128K. At least from Mouser.

The popular AT28C256 (32K) runs at a whopping 150ns. At a 1MHz clock, that gives you 500ns of half-cycle time and minus some (fast) glue logic propagation, you're OK.

But what are you guys using that are running 4 MHz, or 8 MHz or even 20! MHz?

Are you generating wait-states or do you know of some super fast ROM I don't know about?

I guess SMD would open the doors to faster components. I presume that's what you're using for faster clocks?

I'm really wondering if it would be easier to get some 12ns SRAM and just load it at startup with a micro-controller..then mark it read-only if I needed to.

Thanks

_________________
Cat; the other white meat.

70ns seems to be it with EEPROMs. EPROMs are somewhat faster: 55ns for UV-erasable parts like those I used in my POC units, or 45ns for OTP parts, which I've also tried.


I don't use EEPROMs at all, and POC V2 inserts one wait state when ROM or I/O is selected in order to support 20 MHz operation. The highest speed at which I've been able to reliably run with a 55ns EPROM is 12.5 MHz. I did get POC V1.1 to boot at 15 MHz with an OTP ROM, but the SCSI host adapter couldn't keep up.


Packaging usually doesn't factor into device speed, at least not in the sort of parts we routinely use in our systems.


You could do the same with an EEPROM. However, it might be a challenge designing a circuit built solely with discrete gates that will run fast enough and have enough logic to know when to wait-state, as well as be able to shadow ROM into RAM. This is where programmable logic makes sense.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Or use an SRAM, a small (E)EPROM, and a serial flash. Program the EPROM with a bootloader that reads the serial flash and copies it to SRAM.

Sorry if I'm miss-understanding, but couldn't you just copy the ROM to RAM using the CPU? There'd be a small penalty at startup while the system wait-stated through the ROM reads, but it sounds much simpler then using a MCU.

_________________
8 bit fun and games: https://www.aslak.net/

I tend to use flash rather than eeprom for larger roms.

Microchip's SST39 range go up to 512k x 8 and are nominally 70ns, but seem to be quite reliable at 14.3mhz attached to one of WDC's 65C02's with a 7.5ns PLD doing select logic.

Rated even faster, RS apparently have some 55ns Amic A29010A in stock.

Both are available in 5v 32pin DIP for easy prototyping.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I think we discussed this before (not too long ago). It shouldn't be too hard to design a circuit for shadowing: put the ROM and RAM in the same address space and add some glue logic to control the Output Enable line of the ROM, and the Output Enable and Write Enable of the RAM.

Example 1: When the system is reset, it runs at 1MHz (or whatever speed that's slow enough for the ROM to keep up, or a circuit is used to generate wait cycles with RDY). Some circuitry enables the Write Enable of the RAM chip (let's call it RAMWE) at the same time as the Output Enable of the ROM chip (say ROMOE) so that whatever is read from the ROM is copied to the RAM. The boot code just has to do a quick loop to read all addresses of the ROM, and then it has to switch the hardware so that the RAM Output Enable (RAMOE) now gets activated for reads in the ROM address area. For example, the circuitry may be controlled by a Set-Reset flipflop that resets on the system reset signal and sets on an output of the address decoder that will never get activated while the shadowing loop executes. Then the boot code does a dummy read from the "magic" memory area and the SR flipflop is set, which also speeds up the CPU. The hard part of a circuit like this is probably that you need to make sure the RAM gets disabled before the ROM, so that the ROM doesn't take the data off the address bus before the write is complete.

Example 2: When the system is reset, it runs at a slower speed or generates wait states with RDY, and the address decoder enables the ROM for the ROM address area when the CPU reads from that area. When the CPU writes to the area, the RAM is activated. This way, there is no timing "gotcha" because the data has to be copied from ROM to RAM by the CPU. The boot code loops through the ROM but after reading each byte, it writes it back to the same location (which activates the RAM and stores the data into it). Then using a similar trick with the address decoder as mentioned above, the circuit state gets changed to enable the RAMOE instead of the ROMOE when reading from the ROM area (and the CPU can be sped up).

The second example will require more circuitry but has some interesting advantages. For example the ROM area is now a RAM area so you can implement some sort of way to patch the ROM code on startup (e.g. test if an input pin somewhere is held low, and if so, download updated firmware from the serial port). You can add more circuitry to let the system write its own EEPROM by copying from the RAM, once it's satisfied that the downloaded code is legitimate (or once you, the user/programmer are satisfied that the updated firmware works correctly).

If you want to protect the RAM from being overwritten once the system is up and running, you can also do so by disabling the RAMWE line once the ROM has been copied of course.

===Jac

I agree, and in fact, the BIOS for POC V2 will do exactly that, shadowing the $00E000-$00FFFF ROM range (HIROM) into underlying RAM. The 65C816's MVN instruction is tailor-made for the purpose. The glue logic is such that a write to a ROM location automatically "bleeds through" to underlying RAM at the same address. I also have the logic rigged up so HIROM can be write-protected after shadowing. So the process will be to copy, write-protect and then map out HIROM.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!