That was supposed to say "...until after Ø2 goes high." I type faster than I think, so words sometimes get lost in the process.

The 65C816's spec for tMDS is 30ns maximum. As with some of the other timing values listed for the '816, that number is suspect. If 30ns were true and Ø2 were 14 MHz, there would be only 5ns before the fall of Ø2, leaving the addressed device scant time to fetch from the data bus. Attempting to run the '816 at 15 MHz or faster would mean that tMDS will never be met, since the fall of Ø2 would occur first. However, the CMD SuperCPU cartridge ran its '816 at 20 MHz, which is a 25ns half-cycle time By all accounts, that cartridge was very stable, which implies that tMDS is no more than 20ns or thereabouts, which is still cutting it real close.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Wait... people attach the clock (Ø2) to chip select inputs? I must be misunderstanding what "qualification" means.

Why don't people simply just attached the chip select input to the output of the address decoding circuitry to access that chip? Actually, come to think of it, as an example, I seem to recall that EPROM chips such as the 2764 have both an output enable and chip select- they accomplish different things, but couldn't they both be attached to the output of an address decoder? It's been awhile since I've looked at a schematic that required me to worry about these things .

Of course I'm simplifying a bit- the address decoder would need to be combined with the '816s VDA/VPA to determine whether to actually access CE.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Possibly the case with the 65C02, but not with the 65C816, which can tell the chip select logic when a valid address is present.


As I emphasized a few posts ago:

"RWB should be directly connected to RWB on the microprocessor, Ø2 on the device should be directly connected to Ø2 on the microprocessor, and the glue logic that selects the device must do so without qualification by Ø2."

As should be done with all devices. RAM and I/O silicon should also have its /WE (write-enable) qualified by Ø2 to avoid the possibility of a wild write and data or register content corruption. Again, none of this applies to the 65C21, 65C22 and 65C51, whose control lines (RWB, etc.) should be directly attached to their counterparts on the MPU.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Probably not. However, for the sake of clarity and in the context of our discussion, "qualification" means that an /OE (output enable) or /WE (write enable) control input on a device is not to be asserted unless Ø2 is high. The data bus should be considered to be invalid during Ø2 low on the 65C02. During Ø2 low, the 65C816 emits the bank address on the data bus.

Enabling /OE during Ø2 low in a 65C02 system is probably harmless (although the addressed device's timing may be violated), but will cause data bus contention in a 65C816 system. Said contention, in addition to possibly producing significant transients, may result in an improper effective memory address being generated if the bank address is being latched, as a undefined bit pattern may be present on D0-D7 at the time when the latch is closed (on the rise of Ø2).

Enabling /WE during Ø2 low may violate timing on some devices and in the case of the 65C816, may cause the device to accept the bank address as valid data. If the addressed device is I/O hardware, the acceptance of the bank address as data may cause the device to behave in an undefined or unexpected manner, e.g., the occurrence of an unintentional change to the device's configuration.

I will reiterate that the above scenarios don't apply the W65C21, W65C22 and W65C51. These devices "understand" the 65C02/65C816 bus protocol and should not be subjected to Ø2 qualification of any kind.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks again, after reading the thread on high speed digital design and I don't think I'm going to get near 10Mhz anyway.

The reason for that is that my design will use ISA style connectors for peripherals connected to the cpu bus, and as I understand it'll be too noisy to get above a few mhz, not really an issue though since I'm just doing this for fun and probably won't be able to tax the system enough to need that much speed, at least for a while.

It'll depend a lot on physical layout and construction techniques, as well as prop delays through the logic. When I designed my POC V1.0 unit, a primary goal was the achievement of 8 MHz operation. I met that goal by some 50 percent, as V1.0 could run at 12.5 MHz, using 74AC logic. Attaching the SCSI host adapter (HBA) forced me to run the unit at a slower pace (10 MHz), as the HBA effectively took the MPU's buses off the board and significantly increased bus loading.


Have you considered employing the socket used for PCI cards? It's a more compact design than the old ISA-style socket, and has been specifically designed for higher frequency operation.

The 32 bit PCI standard, the most commonly used in x86 machines, clocks the bus at 33 MHz, so we know those connectors are up to it. Of course, the PCI bus is not directly attached to the MPU's buses like the old VESA local bus (VLB) was, so PCI cards can't load down the MPU. You may find yourself using bus drivers to get reasonable performance and stability.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Brilliant idea, I'll get my hands on some PCI Slots!

Bus loading is something I hadn't considered enough, though I'm told the W65c02 can drive a lot more than the old NMOS chips I'm sure I'll still need to make sure each of my cards is buffered

My current design has CPU, RAM and ROM on the one board, which will then plug into a passive backplane. I'm thinking that it should be fine provided the buffers I use are fast enough, the only other concern there becomes bus termination as far as I can tell, though I'm a newbie at this so there's probably a whole lot of things I'm missing.

Sometimes I fool humans with my smarts routine.


It is true that the W65C02S and W65C816S can drive the buses harder than the NMOS devices. However, the data sheets don't really say just how hard—their numbers are always suspect. For example, the data sheets say output currents are 700/1600 microamps at 5 volts. Yet experience suggests that the numbers are much higher than quoted. If that 700/1600 number were really true my POC V1.1 unit would not function at the speed (12.5 MHz) at which it is running.


One step at a time. You should build a simple working unit that doesn't take the buses off-board so you can get your feet wet. As soon as you introduce a backplane you may introduce all sorts of potentially intractable problems. Slots on the mainboard, driven from a buffered I/O bus, while technically more challenging to design, has a much greater likelihood of succeeding.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!