My first 6502 build, which followed Ben Eater’s 6502 computer project, uses two pretty pedestrian memory chips, an Atmel AT28C256 32k byte EEPROM and a 62256 32k byte SRAM. The EEPROM has a relatively slow 150 nanosecond access time. The SRAM access time is faster at 70 nanoseconds. The significance of these access times become clear when trying to increase the clock speed at which the project runs. I was able to run this build at up to 4 MHz, but failed at 8 MHz, which was the speed of my next fastest crystal oscillator.
This is about what I expected considering the 65C02 and memory chip timing and the address decoder propagation delay. Do you need a refresher on 6502 and memory timing? Ben Eater has a great video explaining it. For a very helpful visualization of all this check out this link as well.
Consider for example, reading from the Atmel AT28C256 EEPROM, which should be the constraining component with its 150 nanosecond access time. With a 4 MHz crystal oscillator, the 65C02 clock cycle is 250 nanoseconds long. Some of this time is consumed by the 65C02 in setting the address bus to the proper address which the datasheet provides a maximum value of 30 nanoseconds at a 5 volt operating level. Then the address decoder has a propagation delay that takes up some of the cycle time before the EEPROM receives the chip enable signal. Let’s use 10 nanoseconds. The EEPROM then requires some time to assert the value for the requested address to its output pins. This is its access time, or 150 nanoseconds for this EEPROM. Finally, the 65C02 requires some additional time to set up the data before the cycle ends, up to another 10 nanoseconds. That’s a total of 200 nanoseconds from the 6502 starting a read cycle to its completion of it. That leaves about 50 nanoseconds to spare with a 4 MHz clock.
The problem with increasing clock speeds is that these delays are constant, leaving less margin in the clock cycle as clock speed increases. For example, with a 5 MHz crystal oscillator, 200 nanosecond cycle time, the 50 nanosecond margin we had at 4 MHz is now gone. With an 8 MHz crystal oscillator (125 nanosecond cycle) we fall 75 nanoseconds short for this EEPROM. We would need an EEPROM with an access time of 75 nanoseconds or faster to work properly at 8 MHz.
How Fast Can You Go?
One of the first things I wanted to test with my second build was faster clock speeds. The WD65C02 is rated at 14 MHz and I was interested in how close to this I could get. I knew from some research that breadboard builds weren’t ideal platforms for pushing clock speeds, but for me, that added to the appeal of trying.
From tests on my first build, I knew I needed faster memory. Repeating the analysis above for the various crystal oscillators I had, I knew I’d need memory faster than 50 nanoseconds to run the 6502 at 10 MHz. Running at the rated 14 MHz would require at least 20 nanosecond memory. I don’t have a 14 MHz crystal oscillator though so it looked like 10 MHz would be as fast as I could push the build for now.
I decided to get several memory chips with a range of access times not knowing what I might get to work with the 65C02. The first thing I noticed when looking for memory was that memory chips don’t come in as broad a range of sizes as I expected. For example, I couldn’t find a 16k or 24k EEPROM that would fit in well with memory maps I was considering for my second build. That meant I wouldn’t be able to optimize my memory chip selection based on my memory map and would likely have unused memory in my build. It turned out that unused memory isn’t much of a concern in optimizing the design though as higher capacity chips are often not much more expensive than lower capacity ones.
More limiting though is the selection of breadboard friendly DIP chips. This is more of an issue with EEPROM chips that at best had access times that wouldn’t even allow operations at 8 MHz. I did find a one-time programable EPROM with an access time of 45 nanoseconds. That’s good for 10 MHz, but being one-time programable is more suited for a final build, not for testing.
At this point in my search, I became skeptical that I’d be able to push the speed of my breadboard 6502 much due to the limited speed of DIP EEPROMs. Adapters and breakout boards are available for some chip packages but they tended to be expensive or require surface mount soldering. I wanted to avoid those complications if possible.
Searching for EEPROM alternatives, I found that NOR flash is an acceptable replacement. EEPROM is more flexible in that it is byte erasable. NOR flash is block erasable, but as I intend to use it as read-only memory in my build this isn’t a factor. With NOR flash I could get as fast as a 45 nanosecond access time, but not in a DIP which were 70 nanoseconds at their fastest. I’d have to spring for a PLCC adapter after all.
I ended up buying two 32k byte SRAM chips with 55 and 12 nanosecond access times and two 256k byte NOR flash chips with 70 and 55 nanosecond access times. Access time was the main consideration here. The NOR flash chips are inexpensive, so the unused memory isn’t important at this point, and it adds other design opportunities for future testing. Banked memory immediately came to mind as a use for this extra memory, but I put it aside as I had too much on my plate already.
In hindsight buying multiple chips was a mistake. I should have just bought the fastest chips I could but, considering shipping time and costs, I wanted to have fallbacks should the faster chips not work out. I tried the faster, 12 nanosecond, SRAM chip first because it came in a slim DIP and allowed easier wiring in my second build. It worked well and I never even tried the slower SRAM chip.
Not Very Fast!
I started my clock speed tests on my second build with the 70 nanosecond NOR flash chip because it came in a DIP. The 55 nanosecond NOR flash chip was a PLCC and required an adapter. I knew from the start that my second build was not suited for these tests. It was much bigger than my first build, with components widely spaced with long wire runs from the address/data busses. Still, with the faster memory, I hoped to get at least the 4 MHz that my first build achieved.
I had no such luck though. I was only able to run my second build up to 2 MHz. After a lot of troubleshooting, I tracked the issue to my address decoder where propagation delay differences in the various signal paths created spurious nanoseconds long chip enable/select signals that caused havoc on the data bus.
At this point, I felt that I had gone far enough with speed testing. My testbed after all wasn’t designed for this, nor was my program. I had a lot of other components to test and so that’s where I turned my attention next.
Third Times the Charm
I had more luck with speed testing on my third 6502 breadboard build which is a more compact, tightly wired build (I plan to say more on that build in another post). I successfully ran this build at up to 10 MHz (with the 55 nanosecond NOR flash) at which point my monitor program would successfully run its startup tests but would thereafter continually reset. This is likely due to a bus timing problem where the 6502 is misreading an instruction as a BRK (opcode $00) which I’ve programmed as a soft reset.
Knowing that my third build design accommodates faster clock speeds, I may use a crystal oscillator socket in my final PCB build of this designed to allow further speed testing. Normally such a socket isn’t recommended for best performance, but as my builds are mainly educational in nature, that’s really not an issue for me.
Have you pushed the clock speed of your 6502 builds? How fast have you gotten? Let me know in the comments.