Path: utzoo!utgpu!news-server.csri.toronto.edu!qucdn!leek
Organization: Queen's University at Kingston
Date: Wednesday, 12 Dec 1990 09:24:32 EST
From: <LEEK@QUCDN.QueensU.CA>
Message-ID: <90346.092432LEEK@QUCDN.QueensU.CA>
Newsgroups: comp.sys.amiga.hardware
Subject: A1000 Expansion bus interface question - tristates fights ??

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 0x00ef8000