6502.org

At 1 MHz, a full CPU cycle is around 1000 ns, and even old 150 ns EEPROMs are fast enough to present valid data well before the CPU samples the bus. Moving to 55 ns parts only increases this timing margin; the processor has no requirement for a minimum access time.

So if the machine ran reliably with 150 ns and crashes with 55 ns, the root cause is almost certainly:

- The faster device responds earlier to brief address or control glitches.
- The faster device has different output‑enable / chip‑enable timing, so data appears or changes while the CPU is still switching bus lines.
- Different input thresholds or drive strengths change how ringing or reflections show up on the data bus.

## Typical failure mechanisms

Common concrete ways this shows up in 8‑bit homebrew / retro builds:

- Address decode hazards: A combinational decoder that briefly asserts the ROM chip‑enable on wrong addresses (e.g. when A15..A0 are transitioning) may not bother a slow 150 ns ROM, but a 55 ns flash can output “real” data for that short hazard window. If the CPU happens to sample during that window, it may see a bogus opcode (often $$00$$ on 6502, interpreted as BRK, or similar) and “randomly” reset or crash.
- Read/write overlap: If /OE or /CS timing is marginal relative to /RD and /WR, the faster chip may drive the bus at times when the CPU or another device is also driving it, causing contention or corrupted reads.
- Missing latching for multiplexed or slow signals: If any address lines are derived via latches or glue logic, faster memory may expose setup/hold violations that used to be masked by slow ROM access.

## Things to check in your design

Given your symptom (“programs crashing after switching from 150 ns EEPROM to 55 ns flash”), worthwhile checks are:

- Verify address decode: Scope /CS and /OE for the ROM/flash while the CPU runs; look for narrow pulses when the ROM should be deselected. If you see glitches, add registered /CS, or simplify the decoding so that only stable signals feed the ROM select.
- Check data bus timing: Use a logic analyzer to confirm that data lines are stable during the CPU’s documented data‑sampling window, and that no other device is driving the bus at the same time as the ROM/flash.
- Compare control timing from datasheets: Make sure the faster flash meets all minimum pulse widths and setup/hold requirements for your CPU, and that you are respecting its own /CE, /OE, /WE timing (especially if the part supports byte‑programming).
- Power and decoupling: Faster edges mean higher di/dt; ensure good decoupling close to the ROM/flash and CPU so that supply dips or ringing do not cause bit errors at higher edge speeds.

## Practical workarounds and experiments

To narrow it down and/or make it robust:

- Try adding a small series resistor (e.g. 47–100 Ω) in the ROM/flash data lines or /OE line to tame edge rates and ringing; this often stabilizes marginal buses with very fast modern parts.
- If your CPU supports it (e.g. 6502 RDY, Z80 /WAIT), experiment with inserting a wait state on ROM reads; if crashes disappear with an added wait, that points strongly at a timing hazard rather than a logic error.
- If possible, temporarily under‑clock the CPU further (e.g. 500 kHz) with the 55 ns flash. If it still crashes at very low speed, then the failure is not “flash too fast” but some incompatibility (e.g. wrong pin function, voltage, or write‑protect feature) or decode bug triggered by the new device.

In summary, the ROM is not “too fast” in the sense of violating a minimum access time; instead, the faster device makes subtle bus‑timing or decode issues visible, and solving those (or slightly slowing / shaping the signals) should restore stability.

I'm not too happy with being asked to proof-read AI output for someone else's query.

From where are you sourcing those 5ns ROMs?    I'd like a few to play with. 

Are logic levels the other way up in Australia?

Asking for a friend. I'll just get my coat...

Neil