Recommendations for a ROM chip that will work at 10Mhz?

[BigDumbDinosaur]

GARTHWILSON wrote:

BigDumbDinosaur wrote:

Reads and writes to non-65xx peripheral devices should be qualified by Ø2, as the data bus is not guaranteed to be valid until Ø2 goes high. In particular, enabling a device's write input during Ø2 low could cause data corruption in RAM or a write to the wrong register in an I/O device.

Actually, the 65c02 is not guaranteed to put valid write data on bus until tMDS (25ns in current-production WDC 65c02's) after phase 2 rises. It's not a problem though, as long as the address is correct and any invalid data gets fixed in time for the device's data set-up time.

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.

[cr1901]

BigDumbDinosaur wrote:

GARTHWILSON wrote:

Quote:

So for other things that don't need Ø2 qualification, that'd be things like the ACIA/VIA etc yeah?

not only don't need them, but must not have them.

To clarify what Garth is saying, the 65xx support chips (6521, 6522, 6551) must have all control inputs, meaning RWB, chip selects and register selects, valid before Ø2 goes high. Otherwise, they will not respond. 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.

Use of Ø2 to qualify chip selects seems to be lamentably common in 6502 hobby systems, and is incorrect design practice.

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.

[GARTHWILSON]

Quote:

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

Not directly of course.

For some I/O ICs however, phase 2 will need to be brought into one of the inputs of the chip-select logic (not the IC itself), if not also to the write-enable logic and/or the output-enable logic. It may be for example that the IC should only be selected if there's a specific combination of address-line states along with phase-2 high, and not otherwise.

ICs like the 65c22 have R/W\ and phase-2 inputs, and phase 2 must not be brought into the chip-select logic for these ICs, as their chip selects need to go true before phase 2 rises.

Quote:

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?

You can do it with a 6502 (in fact that's what I've been doing for 25 years), but don't do that with an '816, because it would have the EPROM trying to drive the bus with the output data byte during the phase-2-low time when the processor is trying to drive the same bus with the bank byte. It would be best to select the EPROM when the address matches (to give the EPROM an early start in fetching the data), but not enable its output until phase 2 goes up.

[BigDumbDinosaur]

GARTHWILSON wrote:

For some I/O ICs however, phase 2 will need to be brought into one of the inputs of the chip-select logic (not the IC itself), if not also to the write-enable logic and/or the output-enable logic. It may be for example that the IC should only be selected if there's a specific combination of address-line states along with phase-2 high, and not otherwise.

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

Quote:

ICs like the 65c22 have R/W\ and phase-2 inputs, and phase 2 must not be brought into the chip-select logic for these ICs, as their chip selects need to go true before phase 2 rises.

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

Quote:

Quote:

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?

You can do it with a 6502 (in fact that's what I've been doing for 25 years), but don't do that with an '816, because it would have the EPROM trying to drive the bus with the output data byte during the phase-2-low time when the processor is trying to drive the same bus with the bank byte. It would be best to select the EPROM when the address matches (to give the EPROM an early start in fetching the data), but not enable its output until phase 2 goes up.

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.

[BigDumbDinosaur]

cr1901 wrote:

I must be misunderstanding what "qualification" means.

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.

[LIV2]

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.

[BigDumbDinosaur]

LIV2 wrote:

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

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.

Quote:

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.

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.

socket_pci_molex.pdf

Molex PCI Socket

(108.25 KiB) Downloaded 124 times

[LIV2]

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.

[BigDumbDinosaur]

LIV2 wrote:

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

Sometimes I fool humans with my smarts routine.

Quote:

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.

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.

Quote:

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.

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.