Attempt at '816

[and3rson]

I went through some resources, including Garth's "65816 myths", an SBC by mike42, and some threads on this forum, and I think I have a general understanding of how to do the address decoding with '816.

Still, I'd like to get some inputs in case I'm doing something wrong, plus some questions.

My address demux looks like this:

'573 looks clear to me.
However:
- I saw somewhere on the forums (update: found the link - viewtopic.php?f=4&t=2438) that main purpose of '245 is to make sure there's no data bus contention if the slave is too slow to release the data lines once Ф2 goes low - is it correct? Or are there any additional reasons for '245?
- VPA/VDA: Mike (https://mike42.me/blog/2022-02-65c816-c ... -prototype) seems to ignore them in his address decoder, but from the previous thread I learned that they can be OR'ed to ensure that A16..A23 doesn't accidentally latch onto a wrong address during "dummy" cycles. Does that mean I can leave VPA/VDA out of my chip selection logic if I'm not worried about accidental reads from my I/O chips? Or is it possible that R/W will be low during dummy cycles and accidental writes may happen?

Another issue I have is with the datasheet (I heard WDC messes up their datasheets from time to time):

Seems like the highlighted timing is tBH (BA0-BA7 hold time) - is my assumption correct?

[BigEd]

Yes, I think that's tBH.

[akohlbecker]

You can look at what the CPU does for all cycles of every instruction in the datasheet starting at page 36 (Instruction Operation). I haven't tested it in hardware, but based on that table I don't believe a case where RWB, VDA and VPA are all low simultaneously exists.

There is no need to insert VDA||VPA in the bank address latching logic, it does not matter there.

You could insert VDA||VPA either into address decoding (I/O chip select) or into bus control (read / write pulses going into chip enable / write enable, and for WDC devices, feed it directly to the active high chip select). I chose to do the latter in my system, so an external device that takes the CPU off the bus does not have to worry about this signal. Some folks also only use VDA, because you're probably never going to intentionally execute code from an I/O register, and it saves the propagation delay of the OR gate.

EDIT: Forgot to answer the main question, yes if you're not worried about spurious reads, feel free to ignore this signal. Though I think you probably should worry about reads, at least for future-proofing. In most I/O devices (the VIA, most(all?) UARTs, etc) reads have side effects.

[and3rson]

akohlbecker wrote:

Some folks also only use VDA, because you're probably never going to intentionally execute code from an I/O register, and it saves the propagation delay of the OR gate.

This is a great idea! I was actually worried about having an extra delay on OR(VPA, VDA), but this way I can eliminate one gate. Thanks!
In my case I'll probably need to route it to '22, '51, and my LCD (I'm using a 240x64 LCD powered by T6963C controller that's sitting directly on the bus, so accidental reads might mess up LCD RAM pointers.)
Conveniently, both '22 & '51 have CS1 as active-high, so VDA can go there directly.

akohlbecker wrote:

EDIT: Forgot to answer the main question, yes if you're not worried about spurious reads, feel free to ignore this signal. Though I think you probably should worry about reads, at least for future-proofing. In most I/O devices (the VIA, most(all?) UARTs, etc) reads have side effects.

That means I correctly understood VPA/VDA behavior. Neat!

[akohlbecker]

Sounds like a reasonable plan! Good luck with your project

[fachat]

Isn't the '573 OE input negative active?

If so, connecting /RES to it only enables it during reset, and disables it afterwards, the opposite of what should be.

For such a design I tend to use a '273 that actually has a /RES input, and always outputs the value to A16-A23
I don't think tri-stating A16-A23 is necessary. It may even produce strange selects during reset because of floating A16-A23

André

[GARTHWILSON]

akohlbecker wrote:

EDIT: Forgot to answer the main question, yes if you're not worried about spurious reads, feel free to ignore this signal. Though I think you probably should worry about reads, at least for future-proofing. In most I/O devices (the VIA, most(all?) UARTs, etc) reads have side effects.

The 816's data sheet's table of what's on the buses in every cycle should give all the needed information.  Even invalid reads are not at random addresses, but rather are totally predictable, even though the data that's read is not used.  The VIA reads that have side effects which may sometimes be unwanted are spelled out in the data sheet, for example that reading T1CL will clear the T1 interrupt if you happen to hit it at that very narrow window of time.  One we discussed here recently was that if you have the handshaking set up on the VIA's port A (PA), accessing PA at register 1 will trigger the handshaking, so if you don't want that, you should access it through register $F instead.  In any case, it's all predictable.  BDD used VDA to solve a problem that arose from his using non-65xx hardware that could not handle back-to-back writes IIRC (like in a RMW operation) where the first write had invalid data and the second one was the desired data.  Something like a 65c22 does not have any trouble with back-to-back writes.  His use of the non-65-family UART is perfectly valid of course, but we should understand when VDA & VPA usage is essential and when it's not.

[and3rson]

fachat wrote:

Isn't the '573 OE input negative active?

If so, connecting /RES to it only enables it during reset, and disables it afterwards, the opposite of what should be.

For such a design I tend to use a '273 that actually has a /RES input, and always outputs the value to A16-A23
I don't think tri-stating A16-A23 is necessary. It may even produce strange selects during reset because of floating A16-A23

André

Shoot, my bad! I meant to add '273 in there. Thanks!

[akohlbecker]

You don't need to reset the latch, as the cpu goes through a few internal cycles before accessing the reset vector and starting the program execution. Even though the latch powers up in an undefined state, its value will become known during the first internal clock cycle.

[fachat]

akohlbecker wrote:

You don't need to reset the latch, as the cpu goes through a few internal cycles before accessing the reset vector and starting the program execution. Even though the latch powers up in an undefined state, its value will become known during the first internal clock cycle.

But does the select logic know about reset?

RAM may be already there for example. I'd rather be on the safe side.

[akohlbecker]

Why would a bank address of 0 be safer than any other value during power up?

Also, a 273 is not recommended because it is a D flip flop, meaning the bank address only appears after the clock rising edge. You want a transparent latch so the bank address is already present, and the select logic has already propagated, before the clock rises! That's important for WDC I/O chips for example.

[akohlbecker]

Really the circuit shown in the datasheet for demultiplexing the bank address is all you need, unless you want to use BE or RDY. For the latter I go into it in more detail in episodes 3, 5 and 6 of my YouTube series.

[fachat]

A right the '273 is a d flipflop not a latch. Sorry my fault. You should use a transparent latch here.

[drogon]

Just to add another data-point:

In my ruby 816 system, I use a GAL to latch the upper N address bits and no separate data bus buffer. Works for me, but I only have one peripheral - a 65C22 and simple address decoding done in another GAL to allow for 512KB of RAM and the VIA.

-Gordon

[and3rson]

akohlbecker wrote:

Why would a bank address of 0 be safer than any other value during power up?

Also, a 273 is not recommended because it is a D flip flop, meaning the bank address only appears after the clock rising edge. You want a transparent latch so the bank address is already present, and the select logic has already propagated, before the clock rises! That's important for WDC I/O chips for example.

This is a great point, I haven't thought about it.

akohlbecker wrote:

Really the circuit shown in the datasheet for demultiplexing the bank address is all you need, unless you want to use BE or RDY. For the latter I go into it in more detail in episodes 3, 5 and 6 of my YouTube series.

Somehow, I missed that page! Good to know the recommended solution.

EDIT: In the datasheet, on the page with address demux curcuit, what does the square rotated by 45° mean? Is it some sort of buffer?

drogon wrote:

Just to add another data-point:

In my ruby 816 system, I use a GAL to latch the upper N address bits and no separate data bus buffer. Works for me, but I only have one peripheral - a 65C22 and simple address decoding done in another GAL to allow for 512KB of RAM and the VIA.

-Gordon

Are there any benefits of using a GAL instead of a 74xx latch?