Latching the bank address the right way
Latching the bank address the right way
I was just looking at the timing diagrams in the Western Design 65C816 and I noticed the answer to bank address latching made easy.
My first clue is these two signals that are supplied by the CPU are already used in every design I've seen. All you need to do is look at lines 2,3 and 4 of the timing diagram. The answer...right there.
20 questions anyone?
My first clue is these two signals that are supplied by the CPU are already used in every design I've seen. All you need to do is look at lines 2,3 and 4 of the timing diagram. The answer...right there.
20 questions anyone?
Re: Latching the bank address the right way
A0CBM wrote:
I was just looking at the timing diagrams in the Western Design 65C816 and I noticed the answer to bank address latching made easy.
My first clue is these two signals that are supplied by the CPU are already used in every design I've seen. All you need to do is look at lines 2,3 and 4 of the timing diagram. The answer...right there.
20 questions anyone?
My first clue is these two signals that are supplied by the CPU are already used in every design I've seen. All you need to do is look at lines 2,3 and 4 of the timing diagram. The answer...right there.
20 questions anyone?
-Gordon
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Re: Latching the bank address the right way
Always interested in ideas about this.
Can you maybe post a schematic, A0CBM, as Gordon suggested?
In the thread linked below l posted several variations on the usual '573 scheme. Included is a FET Bus Switch approach which features near-zero ( < 1 ns
) propagation delay, making it attractive for anyone intent on running the '816 as fast as it can possibly run!
.
When is a Latch not a Latch? (Capturing the '816 Bank Addr)
-- Jeff
In the thread linked below l posted several variations on the usual '573 scheme. Included is a FET Bus Switch approach which features near-zero ( < 1 ns
When is a Latch not a Latch? (Capturing the '816 Bank Addr)
-- Jeff
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
-
kernelthread
- Posts: 166
- Joined: 23 Jun 2021
Re: Latching the bank address the right way
Dr Jefyll wrote:
In the thread linked below l posted several variations on the usual '573 scheme. Included is a FET Bus Switch approach which features near-zero ( < 1 ns
) propagation delay, making it attractive for anyone intent on running the '816 as fast as it can possibly run!
.
When is a Latch not a Latch? (Capturing the '816 Bank Addr)
-- Jeff
When is a Latch not a Latch? (Capturing the '816 Bank Addr)
-- Jeff
Re: Latching the bank address the right way
Last edited by Dr Jefyll on Fri Mar 31, 2023 5:45 pm, edited 1 time in total.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: Latching the bank address the right way
Thanks Dr. Jefyll.
My thought was to just use *(VDA # VPA). This does tell us that the whole address is available, including the bank bits. The timing diagram below the PHI2 diagram shows that VDA and VPA change at the right time, the same way you validate addressing memory. The bank is held until T ah. It is automatically updated in the middle of phase1, so it's ready for PHI2. The table in the Datasheet of the 65C816, the table in the description of VDA and VPA gives the values that give the status of the address bus. My logic only latches in a cycle that VDA or VPA are valid, so during a NOP the latch doesn't change.
It seems so easy, a cave man could do it.

My thought was to just use *(VDA # VPA). This does tell us that the whole address is available, including the bank bits. The timing diagram below the PHI2 diagram shows that VDA and VPA change at the right time, the same way you validate addressing memory. The bank is held until T ah. It is automatically updated in the middle of phase1, so it's ready for PHI2. The table in the Datasheet of the 65C816, the table in the description of VDA and VPA gives the values that give the status of the address bus. My logic only latches in a cycle that VDA or VPA are valid, so during a NOP the latch doesn't change.
It seems so easy, a cave man could do it.
- BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Latching the bank address the right way
A0CBM wrote:
My thought was to just use *(VDA # VPA). This does tell us that the whole address is available, including the bank bits.
VDA || VPA is best used to qualify chip selects. The bank bits are “don’t care” when VDA || VPA == 0, so let them fall where they may during a so-called “dead” bus cycle. That basic concept has been well-proved in my POC V1.3 unit, as well as other 65C816-based systems.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Latching the bank address the right way
I was thinking more like !(VDA || VPA) == 0, so when there is a valid address as shown in the timing diagram, the bank address is available. This been tried? Oh, wait, I see a 3 ns gap between the VDA/VPA becoming valid and the bank address being available.
Re: Latching the bank address the right way
Do a latch need a complete clock cycle to do its job?
I'm thinking about a latch, buffer or whatever, that would run at twice the clock of the system. Let's say, having a clock @20Mhz that would feed a counter, and that counter would have bit 0 feeding the latch and bit 1 feeding the CPU.
That would mean that for every clock phase in the CPUm there has been a complete clock tick in the latch.
If this idea has sense, that would mean that when the CPU goes low, the latch already has the address bank there so a direct memory access could be done.
What do you think?
I'm thinking about a latch, buffer or whatever, that would run at twice the clock of the system. Let's say, having a clock @20Mhz that would feed a counter, and that counter would have bit 0 feeding the latch and bit 1 feeding the CPU.
That would mean that for every clock phase in the CPUm there has been a complete clock tick in the latch.
If this idea has sense, that would mean that when the CPU goes low, the latch already has the address bank there so a direct memory access could be done.
What do you think?
Re: Latching the bank address the right way
The best way I can think of describing how to latch the bank address from the D pins is: just keep the '573 LE high the entire time PHI2 is low.
Initially as PHI2 falls the '573 will start latching "garbage" (whatever was already on the data bus) but it will latch the bank address correctly when it appears. The address is also "garbage" (whatever it was previously) as PHI2 falls but soon correctly appears. Then stop the '573 latching by bring LE low as PHI2 rises. This means it takes half a clock cycle to latch the bank address. VDA and VPA are completely separate concerns and have nothing to do with correctly latching the bank address; they indicate what is in the address the '816 is fetching (opcode, program, data or nothing). VDA and VPA and the bank address will change once per clock cycle during an instruction. Although sometimes VDA, VPA and BA will change to the same value they already had.
To get a nice clean PHI2 and /PHI2 run your clock at twice the frequency through a D-Type flip flop and use Q and /Q as PHI2 and /PHI2. That will give you a perfect instantaneous inverse for PHI2. If you don't want to double your clock frequency then you could run your clock into a buffer to get PHI2 and into an inverter to get /PHI2. That will still give you a better inverse than just using an inverter on it's own but depending on your timing characteristics it might not be important.
The latch only needs a half clock cycle to latch. Its output should always be enabled so it is outputting 'something' the entire cycle.
If by 'CPU goes low' you mean when PHI2 goes high in the second half of the cycle then, yes, at that point the memory access can be done as the latch contains the bank address.
You control when PHI2 goes high and you can think of that as signalling to the '816 that you've latched the bank address and would like it to start writing (or reading) data on the D pins. The bank address and address are output long before you bring PHI2 high unless you're running at silly high frequencies.
Initially as PHI2 falls the '573 will start latching "garbage" (whatever was already on the data bus) but it will latch the bank address correctly when it appears. The address is also "garbage" (whatever it was previously) as PHI2 falls but soon correctly appears. Then stop the '573 latching by bring LE low as PHI2 rises. This means it takes half a clock cycle to latch the bank address. VDA and VPA are completely separate concerns and have nothing to do with correctly latching the bank address; they indicate what is in the address the '816 is fetching (opcode, program, data or nothing). VDA and VPA and the bank address will change once per clock cycle during an instruction. Although sometimes VDA, VPA and BA will change to the same value they already had.
To get a nice clean PHI2 and /PHI2 run your clock at twice the frequency through a D-Type flip flop and use Q and /Q as PHI2 and /PHI2. That will give you a perfect instantaneous inverse for PHI2. If you don't want to double your clock frequency then you could run your clock into a buffer to get PHI2 and into an inverter to get /PHI2. That will still give you a better inverse than just using an inverter on it's own but depending on your timing characteristics it might not be important.
tokafondo wrote:
Do a latch need a complete clock cycle to do its job?
tokafondo wrote:
that would mean that when the CPU goes low, the latch already has the address bank there so a direct memory access could be done.
You control when PHI2 goes high and you can think of that as signalling to the '816 that you've latched the bank address and would like it to start writing (or reading) data on the D pins. The bank address and address are output long before you bring PHI2 high unless you're running at silly high frequencies.
- BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Latching the bank address the right way
AndrewP wrote:
The best way I can think of describing how to latch the bank address from the D pins is: just keep the '573 LE high the entire time PHI2 is low.
That is what I am doing in POC V1.3. /LE is gated by Ø1 and when the latter goes low, the latch closes before the 816 has “turned around” the data bus...and we’re off to the races.
One could qualify the gating of /LE with VDA || VPA, but I’ve concluded from observations with the logic analyzer that it is unnecessary. The bank bits will have stabilized in plenty of time before Ø1 goes low, and are a “don’t care” during “dead cycles,” since the main glue logic should be qualifying chip selects with VDA (and optionally, VPA).
x86? We ain't got no x86. We don't NEED no stinking x86!
- BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Latching the bank address the right way
A0CBM wrote:
I was thinking more like !(VDA || VPA) == 0, so when there is a valid address as shown in the timing diagram, the bank address is available. This been tried? Oh, wait, I see a 3 ns gap between the VDA/VPA becoming valid and the bank address being available.
Try re-reading what I earlier posted.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Latching the bank address the right way
I've kept reading about this and wondered about using a flip-flop instead of a latch. Would be of any benefit the fact that a flip-flop acts on edges and is clocked?
- BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Latching the bank address the right way
tokafondo wrote:
I've kept reading about this and wondered about using a flip-flop instead of a latch. Would be of any benefit the fact that a flip-flop acts on edges and is clocked?
The latch used to generate the bank bits is a transparent latch, meaning when the latch is opened, its outputs follow its inputs. A flop doesn't have that characteristic.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Latching the bank address the right way
BigDumbDinosaur wrote:
AndrewP wrote:
The best way I can think of describing how to latch the bank address from the D pins is: just keep the '573 LE high the entire time PHI2 is low.
That is what I am doing in POC V1.3. /LE is gated by Ø1 and when the latter goes low, the latch closes before the 816 has “turned around” the data bus...and we’re off to the races.
One could qualify the gating of /LE with VDA || VPA, but I’ve concluded from observations with the logic analyzer that it is unnecessary. The bank bits will have stabilized in plenty of time before Ø1 goes low, and are a “don’t care” during “dead cycles,” since the main glue logic should be qualifying chip selects with VDA (and optionally, VPA).
I tried to do latching combined with RDY but somehow this didn't work and I went back to clock stretching instead of using RDY
André
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/