So everything is looking doable for a 3.3 V design -- except the ROM. All I seem to be able to find are ICs with 200 ns timings -- yes, "two hundred" -- which is clearly unacceptable, not so much because of the boot time, but because of the interrupt vectors. This can't be a new problem, so I'm wondering if I am missing something.

If worst comes to worst, would it make sense doing the (waves hands) magical level translation thingie for one 8 kByte ROM chip? Or does that bring its own speed penalty?

Gardening season has just started in Germany, so I'll have the next couple of weeks to decide which voltage path I'll take. You need something to think about when planting radishes ...

I'd be tempted to skip having a ROM in the system at all, except for (possibly) at powerup/reset. I would then have a ROM mapped into the system (with wait states), copy the ROM content into RAM, map the RAM into place, possibly write-protect it, and disable the wait states. As an alternative to a ROM, I would probably try to have a small controller bootstrapping the main processor (done before, by a number of people on this site, as well as other places.)

The level translators used on OHO's FPGA boards only add a few nanoseconds to the path, if I remember correctly.

I'd probably go with the level shifter, but another option would be to use a battery backed 3.3V SRAM (one of the 10 year type ones which are built into the IC) and then design a small 6502 system who's only job is to copy the ROM contents to the SRAM, then move the SRAM to your new design. I.e. put in two ZIF sockets. Obviously you'd use the level shifter in this 6502-copy design, but not need one in your new design. This way you'd solve your problem and also have a faster-than-EEPROM access time for your OS.

This one might do the trick: http://uk.mouser.com/ProductDetail/Texa ... O5PA%3d%3d

All-in-one battery-backed SRAMs are all really slow though, right? The ones I've seen are slower than EPROM.

_________________
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've just had a look and you're right with most of them, but this one is 70ns which seems ok:
http://uk.mouser.com/ProductDetail/Texa ... O5PA%3d%3d
Bit small at 8K, but it depends on the firmware/OS needed and perhaps could use more than one?

32Kx8, 55ns EPROM: http://www.jameco.com/webapp/wcs/stores ... _266079_-1

And although this EPROM is OTP (one-time-programmable), I find it encouraging that it's 45ns: http://www.jameco.com/webapp/wcs/stores ... _394986_-1 . Being OTP is not really a problem if you develop a tiny program to load the rest of the kernel into RAM; and you could develop it using slower, non-OTP (E)EPROM and then move it to the faster OTP when it's working right and turn up the clock speed. (Or, maybe someone else has the 45ns EPROM in an erasable version.) Now if only they had a 45ns one in 2Mx8 or 4Mx8...

_________________
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 use the 55ns EPROM in POC at 12.5 MHz. The part that JAMECO has been supplying when I've purchased it is made by AMD.

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

Woops-- The ones I referenced are 5V, and the OP wanted 3.3V.

_________________
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?

It's weird that you have some areas seemingly headed for 3.3V and leaving 5V behind (CPLDs for example), but others are almost the inverse such as EEPROMs, SRAMs.

Here are two OTP EPROMs rated at 70ns. They'll run on 3.3V or 5V.

• 8K by 8 AT27BV256
• 128K by 8 AT27LV010A

If 70ns is too slow -- or if you prefer a windowed, erasable EPROM, and it is too slow -- you should at least consider using a Wait State. Of course no-one likes wait states; they are very plainly a compromise solution. But the trade-off may not be as loathsome as you suspect, and engineering principle suggests we should investigate before choosing.

If you limit yourself to a single wait state, the circuitry for its implementation can be as simple as one J-K flip-flop; ie: 1/2 of a 16-pin DIP. (For '816, you'll also add a gate on the enable input of the Address Latch.) As for fetching an interrupt vector, the total penalty is just two cycles. (There are two bytes to fetch. Each of those accesses will take two cycles instead of one.)

Will one wait state be enough? Remember that, for full-speed operation in a 65xx system, memory must respond in about 1/2 a cycle. Thus -- somewhat counterintuitively -- adding a one-cycle wait state roughly triples the time available for the ROM to respond. (The ROM gets the original time plus one entire extra cycle.)

ETA: The 3:1 gain declines if you're not pushing the CPU to its limit. But the ratio will always exceed 2:1. For more on 65xx timing see Visual Guide to 65xx CPU Timing.

Also, I'm not saying wait states are the right choice for the OP -- there's no right or wrong to it; it's up to him to weigh the options based on his priorities. (And right now it sounds as if his first priority is gardening! )

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hi,

I suggest to use an external processor that loads the ROM image into a later-on write-protected portion of the RAM. How about using a AVR/PIC MCU that during power-up disables the CPU bus using BE and the RESB line takes over the CPU Address, Data and Address bus and loads a ROM image into the RAM. Similar approaches have been discussed already several times. The good thing is you could use the MCU flash to hold several ROM images that can be selected during power-up or even have a feature to load a ROM image via one of the USARTs built into MCU.

cheers

Peter

I think my next one will use a microcontroller to pre-load the RAM from small (like micro-SD size, but thicker) plug-in EEPROM modules similar to the one shown below, for different ROM images.

The I²C connector spec is shown at viewtopic.php?f=4&t=2155 .

_________________
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 quite like the idea of booting with a slow clock and a ROM mapped in, and having the first bit of code copy the ROM into the underlying RAM, then mapping out the ROM and moving up to full speed.

(Also, making the ROM code a minimal bootstrap which loads the full OS from elsewhere - whether SPI, I2C, serial, or something else. Then, as Garth says, the minimal bootstrap is relatively easy to finalise and burn into OTP ROM)

But it does sound like we have quite a range of possible approaches.

(Edit: some previous conversation on these lines at
viewtopic.php?t=1526
and
viewtopic.php?t=2705
)

Thanks for the suggestions, guys -- I'll take a look at the AT27BV256, I'd missed that. I should now have all the stuff together for a first design, will try to get it on paper in the next weeks (between building planters and whatnot).