Re: Apple II Bus Timing

[dempson@actrix.gen.nz (David Empson)]

Andrew Quinn <andrew.q@ihug.co.nz> wrote:

> I have been puzzling over some strange timing related issues on my IDE
> controller board for some time and while at the local surplus electronics
> store picked up a book called "The Apple II Circuit Description" by Winston
> Gayler.  In this book I find a caution for designers that basically says:
> 
> "The 6502 data sheet specifies that at the end of a read cycle the data must
> remain stable on the 6502 inputs for a 10ns hold time after the 6502 o2
> clock falls."
> 
> The apple bus provides o0 (rather than o2) for bus timing and this appears
> to lead o2 due in the timing diagrams but I cannot find timing details of
> this lead so I can hold the data on the bus a little longer.

The 6502 data sheet shows a delay from Phi0 (IN) to Phi2 (OUT) which it
defines as "tDLY".  For a 1 MHz or 2 MHz 6502, this has a minimum of 0
ns and a maximum of 60 ns.

The bus Phi0 and Phi1 signals are generated by timing ciricuitry on the
motherboard.  In the IIe, the 6502 or 65C02 Phi0 input is driven from an
inverted copy of the Phi1 signal.

Just to confuse things, it looks like the IIe actually uses an inverted
copy of Phi1 to drive the Phi0 input to the 6502.  I can't see any
indication that Phi1 is even provided to the CPU, but this might be an
error in the circuit diagram.

The IIe Technical Reference implies that Phi1 and Phi0 to the slots are
in perfect sync (yeah, right), and that address information to slots is
held for at least 30 ns after the end of the cycle.  It doesn't say
anything in particular about the data bus hold time requirements for a
read cycle, other than referring to the 6502 data sheet.

Don't forget that the Apple II has a 74LS245 between the slot and
motherboard data bus, and this may provide some buffering at the end of
the cycle.  The CE pin is driven by (Phi0 NOR R/W), and the DIR pin is
driven by an MD_IN/OUT' signal from the MMU.

According to "Understanding the Apple IIe" by Jim Sather, for a read
cycle to the slots, the rising edge of MD_IN/OUT' follows the rising
edge of Phi0 and is delayed about 60 ns.  The falling edge of MD_IN/OUT'
follows the falling edge of Phi0 and is delayed about 50 ns.

The DEVICE_SELECT' and IO_SELECT' signals fall (go active) before
MD_IN/OUT' rises, and rise (go inactive) before MD_IN/OUT' falls, thus a
peripheral that is using these signals to drive the data bus will turn
off its data bus output slightly before Phi2 falls.  This does not cause
a problem because "data bleeds off very slowly from the floating
peripheral data bus.  In other words, Apple gets away with it, but
perhipheral card designers should be aware of the early timing." (Quote
from Understanding the IIe.)

In theory, you don't need to do anything special.  Consider that the
Apple II is quite capable of holding the last accessed video data byte
for half a clock cycle so that the CPU can read it when accessing soft
switches that don't drive the data bus.