This is a work in progress, documenting my findings related to my 65816 build. Its rough, intending to get my findings written down before I forget them. I’ll hopefully be able to polish it as I go along.
In this post I am documenting various signals in the Western Design Center’s W65C816SXB Development Board. I’ll update the post periodically as I move through my own 65816 build and look to the development board as a reference build. So far, I’ve discussed the following:
Background
I’ve sometimes had the desire to be able to access more memory when working through some of my 6502 projects and have sometimes thought of the 65816, which can access 16 MB, as a possible solution. I hesitated working with the processor though because I wasn’t familiar with it. While I had grown up with 6502 and was very familiar with it’s assembly language, the 65816 was just different enough to keep me with the tried and true.
Having three 6502 builds under my belt and a fourth one under-development, I decided to look into the 65816. I found a lot that was familiar as well as a lot that was different. A big downside for me was the lack of a handy emulation tool for the 65816. And while the assembler I use supports the 65816, it can’t produce a full listing of a multi-file project. These were deal breakers for me that kept me from moving further with the 65816.
In my last post I mentioned working on a 65816 emulator. Besides the fun of just doing it, I I figured the only way I was going to move forward with the chip was to address the tool deficiency that was holding me back. As such I also developed a Python script that would create a full listing file for my projects. With those tools behind me I could dive into a 65816 build.
As part of writing the 65816 emulator, I got a W65C256SXB development board as an easy way to confirm how various instructions and address modes work on actual hardware. The development board has a W65C256 chip which is built around the 65816 core. It’s a handy little board and was less expensive than the W65C816SXB development board, so it was a perfect companion for emulator testing. When I started to look into my own 65816 design, I turned to the W65C256SXB to clarify some ambiguities I found online. However, the 65C256 chip internalizes much of a typical 65816 build, making it impossible to investigate many of the signals that would be available on a conventional build. In the end, I decided to buy the W65C816SXB as well, somewhat just to have it for reference, but more immediately to answer some design questions I was having right at the get-go, namely, “how did Western Design Center get by with using HC family logic chips when many online say they’re not fast enough”.
Generic 65C816 Timing
Figure 4-1 and Table 4-2 of the 65C816 datasheet give the general timing characteristics of the CPU. The diagram below shows these for a 14 MHz clock.
On the Chips used on my W65C816SXB
To provide the best information, I’ve reflected my analysis on the specific manufacturer’s datasheet where possible. I have Revision C of the W65C816SXB (datasheet, schematic).
| Chip | Manufacturer | Datasheet |
| 74HC00 | OnSemi | chip appears to be datasheet1 datasheet2 provides typical timing |
| 74HC573 | Unknown | Nexperia (markings similar but no logo) |
| 74HC245 | Nexperia | Nexperia |
Bank Address Latching
One of the first design considerations you’ll come to in your 65816 design is how to capture the bank address, the upper byte of the 24-bit address, which the 65816 multiplexes on the data bus during the low phase of the clock cycle during memory access. The timing for latching the bank address is tight and needs to be considered when selecting the logic family of the chips you’ll use in your design. As shown in the diagram above, at 14 MHz, the bank address must be latched in a window as short as 12 nanoseconds (between 33 and 45 ns) during the clock cycle. The W65C816SXB has an 8 MHz clock giving a longer window, but the bank address still needs to be done as early as 10 ns after the rising edge of clock.
Figure 5-1 of the datasheet gives a bank address latching circuit. The W65C816SXB uses the HC family of logic chips for this circuit and for address decoding. Many online discussions state that this family of chips isn’t fast enough to latch the bank address. Let’s examine some timing diagrams to find out why.
The suggested bank address latching circuit uses an inverted clock signal to drive the 74HC573’s latch enable. The propagation delay through a 74HC00 is from 8 and 15 ns (for using the datasheets from the table above). The 74HC573 has a data set-up time from 4 to 10 ns before the latch enable goes low and a data hold time from 1 to 5 ns after the latch enable goes low. For a successful latch, the data cannot change during this period. Adding the bank address latching timing to the 8 MHz timing diagram, we have:
We can see that the bank address latch circuit should work based on the typical propagation delays in the 74HC00 and 74HC573 chips used in the W65C816SXB. The bank address is latched with 2 ns to spare before the CPU’s bank address hold time. However, it’s clear that the 74HC00 propagation delay is not guaranteed to be fast enough, possibly being up to 5 ns too slow.
So, theoretically, the 74HCxx based bank address latching circuit might work out, it’s clearly not guaranteed. But how does the W65C816SXB actually perform. Let’s take of look some signals on the board to get an idea.
I got the idea for a simple test program from this post on 6502.org. Unfortunately, we can’t easily attach a logic analyzer to the W65C816SXB to examine these signals as they’re not broken out to a header. But we can easily probe the board with an oscilloscope.
Looking at the key part of the suggested code closer, we can determine what is happening on the address and data buses during each clock cycle.
Bank Byte Latch Test
data bank register is set to 3
program bank register is 0
code snippet:
loop lda $202f
bra loop
this has 7 clock cycles
cycle AB DB DB value
1 PC opcode $AD
2 PC+1 AAL $2F
3 PC+2 AAH $20
4 DBR.AA Data low $F5
1 PC opcode $80
2 PC+1 offset $FB
3 PC+1 internal op ?
The data bank register is set to 3 before the loop is entered and address $202f is $F5 so we clearly see a change on the data bus between the low and high clock phases. Looking at the D1 pin on the 65816 (purple trace) against the clock (yellow trace) we can identify the traces for the above code.
The first seven cycles correspond to the cycles shown in the code snippet above and then repeat. Zooming in on cycle 4, we see bit 1 of the data bank register going high on the data bus at 14 ns after falling edge of the clock and maintained for about 17 ns after rising edge.
So, while the datasheet indicates that the bank address hold time may be a short as 10 ns, this chip is holding it considerably longer. For now, let’s assume it’s typical. I’ll revisit this assumption on my own build later.
Now the 74HC573 needs to latch the bank address before the data changes 17 ns after the rising edge of the clock. The bank address latching circuit uses a 74HC00 to produce an inverted clock signal to drive the 573’s latch enable. Here we see the inverted clock lags by 7 ns
The 74HC573 has a hold time of 5 ns from latch enable until the data is latched. Thus, from our traces the bank address should be latched 12 ns after the rising edge of the clock. We have 5 ns to spare.
Looking at A17 on the 74HC573, we see the successful latch of the bank address during cycle 4 and the maintaining of that address for 21 ns into cycle 5. This will be important later when we look at memory and I/O devices.
Adding this information to our timing diagram, we have:
Here the bank address latch timing is well within the CPU’s actual bank address hold time of 17 ns even if the latch enable signal is delayed to its maximum value. The bank address is latched 1 ns faster than the typical case above because the 74HC00 has a slightly faster propagation delay. Unfortunately, we can’t directly measure when the 74HC573 actually latches the bank address. In the diagram above, I’ve shown it to occur 1 ns after the falling edge of LE. Note that for comparison, I’ve included the 74HC00 and 74HC573 typical/min/max values but have shifted the 74HC573 bank address values to the left to reflect the faster latch enable signal from the 74HC00.
We now have enough information to answer the question “are HC family logic chips fast enough to use with the W65C816SXB?”. I’m going to give a nuanced answer. Are you a hobbyist blinking a few LEDs? Then yes, they are. Are you building your personal Mars rover? Then no, they’re not. Somewhere in between, you decide. Are you more about putting stuff together with what you have on hand or a stickler, not happy unless all of the i’s are dotted and t’s crossed? Such folks will fall on opposite sides in this debate.
And debates there are. I’ve seen some that claim you’re only slightly less than committing a mortal sin by designing a circuit that isn’t within the guaranteed specifications of all of its components. I’m more flexible, believing it’s sufficient to be aware of the limitations of the circuit you design. For example, even Western Design Center caveats the W65C816SXB with “WDC products are not authorized for use as critical components in life support devices or systems.”.
So, my W65C816SXB works with HC family logic chips for my simple test. Is the test robust enough? It depends. The question you have to ask yourself is, what is the frequency of failure and what are the consequences when it does fail. You should consider that failing to properly latch the bank address would probably only occur intermittently, making it difficult to diagnose. If you thrive when a debugging challenge arises, then you’re good to go. If you pull your hair out at the slightest hiccup, then you may need to move on to something more robust,
Also, does this test hold true for all W65C816SXBs? What is the variability of the typical bank address hold time? For now, I’ll assume the W65C816SXB is equivalent to any generic 65C816 PCB build, meaning that 74HCxx family chips should be adequate for their bank address latching circuit as well, assuming non-critical operations. I’ll have to test this assumption on my own build. First up though is if this analysis holds for a breadboard build. That will be up next.
Data Bus Buffer
Lastly, for completeness, let’s look at the data bus buffer during cycles ? and ?. I’ll expand on this as I get further into my build.
