Page 1 of 2

Latching the bank address the right way

Posted: Fri Mar 31, 2023 1:22 am
by A0CBM
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?

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 5:48 am
by drogon
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?
Bank latching is already easy - it's a one or 2 chip solution. Maybe post a schematic of your thoughts?

-Gordon

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 3:05 pm
by Dr Jefyll
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 :shock: ) propagation delay, making it attractive for anyone intent on running the '816 as fast as it can possibly run! :twisted: .

When is a Latch not a Latch? (Capturing the '816 Bank Addr)

-- Jeff

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 3:52 pm
by kernelthread
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 :shock: ) propagation delay, making it attractive for anyone intent on running the '816 as fast as it can possibly run! :twisted: .

When is a Latch not a Latch? (Capturing the '816 Bank Addr)
-- Jeff
The FET switch idea looks interesting. Do you reckon you could combine it with a 74ACT573 to get effectively a <1ns propagation transparent latch? When PHI2=0, the FET switch is on and the 573 has LE=1, OE=1, so the latches are transparent but the outputs are disabled and don't contend with the FET switch. When PHI2=1 the FET switch is off and the 573 has LE=0, OE=0 so it maintains the state previously passed through by the FET switch.

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 5:27 pm
by Dr Jefyll
kernelthread, in order not to drag A0CBM's thread OT I've replied to your suggestion here.

-- Jeff

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 5:45 pm
by A0CBM
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.
:lol:

Re: Latching the bank address the right way

Posted: Fri Mar 31, 2023 8:28 pm
by BigDumbDinosaur
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.

Re: Latching the bank address the right way

Posted: Tue Apr 04, 2023 11:18 am
by A0CBM
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

Posted: Wed Apr 05, 2023 1:49 pm
by tokafondo
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?

Re: Latching the bank address the right way

Posted: Wed Apr 05, 2023 2:40 pm
by AndrewP
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.
65C816 BA Latch.png
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?
The latch only needs a half clock cycle to latch. Its output should always be enabled so it is outputting 'something' the entire cycle.
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.
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.

Re: Latching the bank address the right way

Posted: Wed Apr 05, 2023 11:48 pm
by BigDumbDinosaur
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. :D Works fine at 16 MHz, using only discrete logic—no PLDs at all.

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).

Re: Latching the bank address the right way

Posted: Wed Apr 05, 2023 11:49 pm
by BigDumbDinosaur
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. :D

Re: Latching the bank address the right way

Posted: Wed Apr 12, 2023 6:54 pm
by tokafondo
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?

Re: Latching the bank address the right way

Posted: Wed Apr 12, 2023 9:27 pm
by BigDumbDinosaur
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.

Re: Latching the bank address the right way

Posted: Wed Apr 12, 2023 9:42 pm
by fachat
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. :D Works fine at 16 MHz, using only discrete logic—no PLDs at all.

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).
But that only works right if there is no use of RDY, right?

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é