I am currently trying to build myself a basic dual-core W65C816S system, and I'm having some issues understanding the bus timing.
My current understanding is that unlike the W65C02, it latches data during read cycles and attempts to write data during the falling edge of PHI2. All this should work with the recommended schematic listed lower in the datasheet. I planning to pair this with an HM62256 (32k x memory chip controlled by the CS# pin. OE# is connected to the inverted RW# signal on the '816, and WE# is connected to a non-inverted RW#. CS# is connected through with a a NAND between an inverted PHI2 and the address decoding logic. Is this a typical design that would work semi-reliably?
Also this is my first post here. Much help appreciated
I am currently trying to build myself a basic dual-core W65C816S system, and I'm having some issues understanding the bus timing...
My opinion (which a few others here may challenge it) is that chip selects should not be qualified with Ø2. This is especially the case with the 65C816, due to the dual function of the data bus. Chip selects should be determined by the effective address and (optionally, but highly recommended) the states of VDA and VPA. The 816 will start emitting the effective address during Ø2 low (observed with a logic analyzer to be around 12 nanoseconds after the fall of the clock—checked on four different 816s), which characteristic should be taken advantage of to give the glue logic as much time as possible to select the appropriate device. The expression VDA || VPA will be true when the emitted address is valid.
Using Ø2 to qualify chip selects will not work with any 65xx peripheral device that has a Ø2 clock input, e.g., the 65C22. 65xx peripheral silicon is slaved to the clock and “knows” what the MPU is doing according to the clock phase. Connect their R/W inputs directly to the MPU’s RWB output.
For non-65xx peripherals, the below circuit may be used to generate properly-qualified /OE (/RD) and /WE (/WD) signals in either a 65C02 or 65C816 circuit:
Fully-Qualified Read/Write
The outputs of the above circuit lag the clock by one gate delay. With 74AC logic, that will be no more than 6-or-so nanoseconds on 5 volts, depending on loading. 74AHC logic will exhibit about the same performance, but with less-aggressive edges, which may help to reduce ringing.
Note that during Ø2 low, the 65C816 emits bits A16-A23 (the bank bits) on the data bus. This condition persists around 8-or-so nanoseconds after the rise of the clock (also observed with a logic analyzer) and creates a window of opportunity for data bus contention to briefly occur right after the rise of the clock—I refer to that brief period as the “data bus turnaround time.” During turnaround, if MPU is in a read cycle, the expression Ø2 && RWB will be true, telling the addressed device to emit output while the MPU itself is emitting output, potentially causing contention. I say “potentially” because the speed of the addressed device determines how quickly it will respond to /OE when it is asserted. Relatively slow devices, such as a 70ns EPROM, aren’t likely to be a problem, but a 10ns SRAM could be quick enough to start talking during turnaround.
While the above circuit will eliminate any possibility of bus contention during Ø2 low, turnaround contention is still possible. This is best countered by inserting an octal transceiver, such as a 74AHCT245, between the MPU and the system’s data bus. See the below example.
MPU-to-Data Bus Interface
Use of the AHCT logic in a 5 volt system also makes the transceiver act as a sort of level converter—a lot of EPROMs and SRAMs emit TTL-level outputs, not CMOS.
During Ø2 low, the transceiver will high-Z both sides. While this is of no concern to the MPU, it does theoretically expose anything on the system side of the data bus to noise. which may or may not cause trouble, depending on timing, the temperature at the South Pole and the phase of the moon. Being the cautious sort of dinosaur I am (in part caused by some 55 years of monkeying with this...er...stuff), I use a resistor array to pull the system side of the bus up to VCC—2.2K is my favorite value. As usual, YMMV.
BTW, forum member Dr Jefyll has a page on his website about 6502 timing. It’s a good, short and to-the-point read. Also, be sure to take a gander at his drawn-to-scale 65C816 timing diagram. It’s definitely clearer than the one published in the data sheet.
OE# is connected to the inverted RW# signal on the '816, and WE# is connected to a non-inverted RW#. CS# is connected through with a a NAND between an inverted PHI2 and the address decoding logic.
Welcome, Snippyrow. In your sentences I quoted above regarding the SRAM, the logic you describe is acceptable. There are alternative approaches which are also acceptable, but the pros and cons are weighed differently by different people and according to different circumstances. I myself lean toward BDD's approach but I don't consider it a hard and fast rule. Just be sure, as BDD noted, that the Chip Select for a 65C22 or other 65xx peripheral is not qualified by Phi2.
Another comment, if I may. I'm all for ambitious projects, but I have a strong apprehension that the goal of a dual-core W65C816S system is one that you need to set aside until after you've managed to get a single-'816 system designed, built and debugged.
...I'm all for ambitious projects, but I have a strong apprehension that the goal of a dual-core W65C816S system is one that you need to set aside until after you've managed to get a single-'816 system designed, built and debugged.
I too would be interested in seeing how a dual-core 816 system would come together. However, I’ll second what Jeff said about getting a single-MPU machine running. Or, to put it in aviation terms: master a light aircraft before taking off for Tokyo in a 747.
memory chip controlled by the CS# pin. OE# is connected to the inverted RW# signal on the '816, and WE# is connected to a non-inverted RW#. CS# is connected through with a a NAND between an inverted PHI2 and the address decoding logic. Is this a typical design that would work semi-reliably?
Being the cautious sort of dinosaur I am (in part caused by some 55 years of monkeying with this...er...stuff), I use a resistor array to pull the system side of the bus up to V
