Page 1 of 1
Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 3:16 am
by MiraLagatta
While I won't dispute the fact that it works, why does Ben Eater (and so many others) gate the RAM chip enable on the clock signal rather than the R/W signal? Simplicity? Chip count? Something else?
With the gated chip enable, the only time the RAM would do anything is on the high end of the clock cycle. Am I wrong in this assumption?
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 3:55 am
by GARTHWILSON
Welcome. You've come to the right place.
It is explained approximately 70% of the way down the page of the address-decoding section of my 6502 primer, at http://wilsonminesco.com/6502primer/addr_decoding.html . The R/W\ signal is not guaranteed to be valid and stable before the address is; so if you don't wait for phase 2, you risk writing to an invalid address before you write to the correct address. If your RAM is slow enough to need more time for the access, you can bring its CE\ low with just the address and then bring its WR\ (or its OE\ if it's a read cycle) low when phase 2 rises. RAM might be the fastest thing on your bus though, so you may not need to go that route. Regardless, you must not write to it outside the phase-2-high time. The basic whole-computer diagram is at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU .
Ben Eater seems to have gotten much of his material from the 6502 primer. I recommend going through the whole thing, as it was written to answer the questions and problems that kept coming up over and over on this forum in its early years. It gets frequent updates. It's in 22 logically organized chapters. I posted the actual addressing scheme here over 21 years ago, after I had been using it since 1992.
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 5:17 am
by MiraLagatta
The legendary Garth Wilson himself answers my first post! I am so honored!
So, if I understand everything I've read, it is only after the clock goes high that everything - address, data, and R/W, are guaranteed to be valid coming from the 6502, and throwing the chip select low triggers either the read or write with no need to pray that the timings are correct because everything is already where it needs to be.
As I found stated elsewhere in this forum "Dumb questions are more easily handled than dumb mistakes." I'm definitely taking that to heart on my bucket-list project of building a computer and understanding every bit of how and why it works.
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 6:29 am
by GARTHWILSON
So, if I understand everything I've read, it is only after the clock goes high that everything - address, data, and R/W, are guaranteed to be valid
Address, R/W, ML\, Sync, and VP\ are guaranteed to be valid and stable no more than tADS time after Φ2 falls, meaning they'll be valid and stable the remainder of the half-cycle time before Φ2 rises again. The latter is basically a set-up time for whatever needs them. Before the tADS time is up, there's no guarantee, or even implication, about the order in which these signals may become valid, let alone that R/W would be and stay high until some amount of time after the address is completed.
coming from the 6502, and throwing the chip select low triggers either the read or write with no need to pray that the timings are correct because everything is already where it needs to be.
Right. Doing it this way, you can know that they'll be correct before you select the SRAM.
And again—if you have a slow RAM that needs more time, you can select it before Φ2 rises, as long as you don't bring its WE\ line low until Φ2 rises. That will require deriving separate RD\ and WR\ signals though, for its OE\ and WE\ pins, respectively, like BDD shows here. If your RAM is fast enough (which it probably will be, as 10ns SRAM has been common and cheap for a decade or two), the simpler one-chip glue will work fine.
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 1:54 pm
by MiraLagatta
To clarify, I'm using the RAM that came in Ben Eater's kit: HM62256BLP-70, which has a 70ns minimum access time according to its datasheet. The fastest I plan to run is 1MHz, which is the oscillator that also came in the kit. With 1000ns per cycle at 1 MHz, I don't think timing will be much of an issue. I'm also using 5V to power the system which should allow the 6502 (WDC model) to run at its fastest speeds (I read somewhere that the 6502 timings are
voltage dependant), referring to the column for 5V, 14MHz in the timing table of the datasheet.
In short, everything is brand new, not salvaged from an old computer.
You mentioned using a clock qualified R/W signal, which I previously saw in this thread:
viewtopic.php?f=12&t=7371 which I think threw everything I thought I knew into question. According to my understanding of what you wrote, I could do it that way, and it might work, but it would be unnecessarily complex given the speed of modern RAM.
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 4:49 pm
by BigDumbDinosaur
The legendary Garth Wilson himself answers my first post!
Legendary!

- laughing_baby.gif (297.55 KiB) Viewed 1479 times
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Thu Oct 27, 2022 5:23 pm
by BigDumbDinosaur
To clarify, I’m using the RAM that came in Ben Eater’s kit: HM62256BLP-70, which has a 70ns minimum access time according to its datasheet. The fastest I plan to run is 1MHz, which is the oscillator that also came in the kit. With 1000ns per cycle at 1 MHz, I don’t think timing will be much of an issue. I’m also using 5V to power the system which should allow the 6502 (WDC model) to run at its fastest speeds (I read somewhere that the 6502 timings are voltage dependant), referring to the column for 5V, 14MHz in the timing table of the datasheet.
CMOS timings, in general, are voltage-dependent, which applies to all current WDC products, as well as CMOS logic families, such as 74AHC, 74HC, etc. Furthermore, CMOS power consumption varies with logic transition rate. In other words, as you speed up the clock, your CMOS devices will use more power.
WDC’s 65C02 and 65C816 have fully-static cores, which means the Ø2 clock can be slowed way down or even stopped without detriment. Stopping Ø2 reduces the MPU’s power consumption to the microwatt range, a characteristic that is exploited in 65C02-powered implantable medical devices.
Speaking of Ø2 clocks, we have a user here who has successfully run his 65C02-powered unit at 29 MHz, some 15 MHz faster than the official WDC rating. My POC V1.2 unit runs the 65C816 at a more sedate 20 MHz on 5 volts. The 0.6µ TSMC cores being used in current WDC parts will run as fast on 3.3 volts as the older Sanyo cores could on 5 volts. So there is a wide range of voltages and speeds from which you can choose.
You mentioned using a clock qualified R/W signal, which I previously saw in this thread:
viewtopic.php?f=12&t=7371 which I think threw everything I thought I knew into question. According to my understanding of what you wrote, I could do it that way, and it might work, but it would be unnecessarily complex given the speed of modern RAM.
Something to consider is many non-65xx devices, primarily those with an Intel-compatible bus interface, will respond faster if /CE is gated before /OE or /WE. This behavior includes many different kinds of SRAM. For this reason, I don’t qualify chip selects with Ø2. Instead, I qualify /OE and /WE with Ø2 in a way that results in one of those signals being asserted within one gate delay after Ø2 goes high.

- Fully-Qualified R/W Circuit
The above is a one-chip solution. 74AC logic is mostly what I use, but other CMOS logic families (other than 74ABT) are suitable, depending on system speed.
Note that the above arrangement is not to be used with 65xx peripherals, the 65C21, 65C22, etc. Those devices are slaved to Ø2 and “know” the 65xx bus cycle. Their chip selects, RWB, address lines, etc., must be set up before the rise of the clock. Otherwise, things won’t work.
Be sure to thoroughly read Garth’s primer end-to-end, which is where much of Ben Eater’s material was gotten. A lot of questions can get answered in short order.
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Fri Oct 28, 2022 2:13 am
by MiraLagatta
And again—if you have a slow RAM that needs more time, you can select it before Φ2 rises, as long as you don't bring its WE\ line low until Φ2 rises. That will require deriving separate RD\ and WR\ signals though, for its OE\ and WE\ pins, respectively, like BDD shows here. If your RAM is fast enough (which it probably will be, as 10ns SRAM has been common and cheap for a decade or two), the simpler one-chip glue will work fine.
- GarthWilson
Something to consider is many non-65xx devices, primarily those with an Intel-compatible bus interface, will respond faster if /CE is gated before /OE or /WE. This behavior includes many different kinds of SRAM. For this reason, I don’t qualify chip selects with Ø2. Instead, I qualify /OE and /WE with Ø2 in a way that results in one of those signals being asserted within one gate delay after Ø2 goes high.
- BigDumbDinosaur
When I first saw R/W gated with the clock in another post (
download/file.php?id=16196&mode=view), it got me wondering why it works.
I've been using this circuit since the 80's without issue... even with newer 32KB SRAMs.
- floobydust
These really answer my question regarding gating the clock with CE vs R/W. I was already familiar with the "how", now I am beginning to understand the "why".
Thanks for all the help, both of you!
Re: Newbie trying to understand Ben Eater's Address Decoder
Posted: Fri Oct 28, 2022 4:37 am
by BigDumbDinosaur
That circuit is suitable for use with the eight bit members of the 6502 family, but not with the 65C816. If you are curious as to why this is so, a study of the 816’s data sheet will show you the way.
The circuit I published works with any member of the 6502 family.
"To err is human, to really foul things up requires a computer!"
I have a wall plaque with that aphorism on it. It was given to me way back in 1976, and is as true today as it was 46 years ago. 