<LEEK@QUCDN.QueensU.CA> (12/12/90)
I am in the processing of interfacing a Seagate SCSI controller (ST-01 , a
8-bit PC/XT or AT interface). I basically uses the R/W*, UDS*, AS*, A23-A21
to generate the RD* and WR* signals. The board has a 74LS245 buffer to the
data bus and it is enabled as soon as it sees RD* or WR* goes active.
The board has 128 bytes of static rams on it, so I decided to write a test
program to use the ram to test out the interface I built. The only time
the data was not read back correctly was when the test vector was 0xff. I
assume that it is some sort of tristate fights between the 74LS245 and the
1000's internal buffer. I sort of fixed the problem by delaying UDS*, but
the hack violates the timing for XRDY that is generated by the board after
RD* or WR* goes active. (This signal is used to sync the CPU for blind SCSI
data transfer - not used in onboard ram). This violates the rule that XRDY
should rise withing 60ns after AS* goes active.
Is that why the A500/A2000 tech. manual (P.21 Data Driver Timing) says that the
backplane drivers must not be turn on until the rising of S4, (P.47 Paragraph 3,
Slave Bus Timing) reminds that as in the expansion architecture, data drivers
should not turn on during a read cycle until S4.
One interesting thing I observe is that when the ram test code is in 32-bit ram
on the Frances board, it work fine. It is only having problems with the code
in chip ram (for both 68020 and 68000). Would adding an extra 74LS245 buffer
that only turns on after S4 between the Amiga and the board fix the 'problem' ?
Thanks in advance...
K. C. Lee
Elec. Eng. Grad. Student
P. S. Test vectors I uses are all 0's, all 1's, travelling 0 and 1.
Board address is at 0x00ef8000daveh@cbmvax.commodore.com (Dave Haynie) (12/18/90)
In article <90346.092432LEEK@QUCDN.QueensU.CA> LEEK@QUCDN.QueensU.CA writes: >The board has 128 bytes of static rams on it, so I decided to write a test >program to use the ram to test out the interface I built. The only time >the data was not read back correctly was when the test vector was 0xff. I >assume that it is some sort of tristate fights between the 74LS245 and the >1000's internal buffer. Not really likely. Where did you locate the board, in memory? >I sort of fixed the problem by delaying UDS*, but the hack violates the >timing for XRDY that is generated by the board after RD* or WR* goes active. >(This signal is used to sync the CPU for blind SCSI data transfer - not used >in onboard ram). This violates the rule that XRDY should rise withing 60ns >after AS* goes active. That's a pretty hard and fast timing contraint, too. I managed to rederive the same basic constraint myself when I did the bus controller for the A3000, in which I started over from scratch for a number of the expansion bus functions. On a normal expansion board, you'll have different signals for board select and data bus enable. The board select signal is always fed out as SLAVE*, and if necessary, makes a good XRDY too. >Is that why the A500/A2000 tech. manual (P.21 Data Driver Timing) says that >the backplane drivers must not be turn on until the rising of S4, (P.47 >Paragraph 3, Slave Bus Timing) reminds that as in the expansion architecture, >data drivers should not turn on during a read cycle until S4. It's always a good idea to follow that suggestion, wait for S4 (or DOE if you're on the backplane), though it's a little more important when you're on a real backplane, since there are buffers driving the backplane, rather than just the 68000 as on the A1000's connector edge. These buffers, which separate the expansion backplane from the motherboard (what I call local) bus, are biased to point out toward the expansion bus normally, for both address and data. It's only when a slave device actually responds and a read is in progress that the data buffers point toward the local bus. So in order to avoid contention with the data buffers, as well as any other slave device, it's good to wait until S4/DOE time to turn on. Data needs to be stable at least 10ns prior to the S6/S7 clock transition, and held at least until AS*/DS* are negated on reads. Writes are pretty easy; data is valid 40ns before DS* falls, and hangs out until 40ns after AS*/DS* are negated. >One interesting thing I observe is that when the ram test code is in 32-bit >ram on the Frances board, it work fine. It is only having problems with the >code in chip ram (for both 68020 and 68000). Would adding an extra 74LS245 >buffer that only turns on after S4 between the Amiga and the board fix the >'problem' ? It does sound like you're getting some interference on the local bus with your board. The extra buffering couldn't hurt, and will at least make your problem hunting easier if it doesn't solve the problem -- with it, you'll have a very precise knowledge of when the local data bus can and can't be affected by your board. If you still have problems, at least you can at that point rule out contention. Make real sure your XRDY timing is on, too, if you need it, since a late XRDY will not guarantee you a wait state. >K. C. Lee >P. S. Test vectors I uses are all 0's, all 1's, travelling 0 and 1. > Board address is at 0x00ef8000 Sounds like a safe place to put it, anyway. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I can't drive 55" -Sammy Hagar