But I am interested in getting responses from the greybeards hereabouts to the one source of advice I've had so far. And I know some people are going to have an allergic reaction to this, but that's really why I'm doing this.
I asked an AI for help.
And yes, I'm an AI sceptic, while also finding some AIs to be useful in certain contexts. I'd just be interested in hearing opinions on how well the AI did in responding to the question.
Which was: with my 1MHz 65C02-based homebrew computer, what was working fine with 150ns EEPROM is now seeing crashes with 55ns flash. Most operating system commands work fine and shorter programs also perform without problems. But some longer programs crash, and always in the same places. So I asked Perplexity whether it's possible that the flash ROM is too fast.
And this is what it said:
Quote:
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.
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.
).
