johnf@ssl.berkeley.edu (John Flanagan) (05/04/91)
Hi, I am trying to come up with a fix to get my Products ByNery shareware XT HD interface to work with my A500/LUCAS/FRANCES at a clock speed above 12 MHz. I think I know how to solve this problem if I can get some pointers on how expansion devices are supposed to behave. The basic problem is that I need to be able to control (delay) DTACK* when the interface card gets a R/W request. At least, this is what I can glean from the 68000 handbook. The problem is that GARY seems to be in control of DTACK*. I've pored over the A500 schematics and the 1.3 Hardware Reference Manual, and have come to the conclusion that I need to have my board let GARY know that it is not yet ready for DTACK* to go out, and that this is probably accomplished through the use of XRDY and/or OVR*, which are available from the expansion interface. Unfortunately, the Hardware Reference Manual provides absolutely no information on the use of the expansion bus signals, and the A500 manual only provides a rough block description of GARY, so I've tried to guess at how the signals are used. My first guess was to lower XRDY until I'm ready for DTACK*, and hope that GARY will generate DTACK when I let up on XRDY. No luck. Now I'm thinking that maybe I should pull OVR* (override) down, and generate DTACK* myself. But before I get into pulling random bus signals down in the hopes of hitting the right combination, I thought I'd tap into the knowledge pool of the net hardware hackers and any passing Commodore employees to ask how this is supposed to be done. I think this is a fairly simple problem, and I hope I have provided enough information, but I can provide more details on what exactly I am trying to do, if needed. Thanks in advance for any help, John -- John Flanagan Center for EUV Astrophysics johnf@ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720
daveh@cbmvax.commodore.com (Dave Haynie) (05/07/91)
In article <JOHNF.91May4033239@gualala.ssl.berkeley.edu> johnf@ssl.berkeley.edu (John Flanagan) writes: > The problem is that GARY seems to be in control of DTACK*. GARY does in fact control DTACK*. We think of it as the way things are supposed to behave, not as a problem :-) >I've pored over the A500 schematics and the 1.3 Hardware Reference Manual, Neither of which are the right books for hardware design, you should get the "A500/A2000 Technical Reference Manual", which can be ordered somehow from Commodore. >and have come to the conclusion that I need to have my board let GARY >know that it is not yet ready for DTACK* to go out, and that this is >probably accomplished through the use of XRDY and/or OVR*, which are >available from the expansion interface. Exactly! > My first guess was to lower XRDY until I'm ready for DTACK*, >and hope that GARY will generate DTACK when I let up on XRDY. Well, that is what XRDY does. First of all, you need to generate XRDY very quickly for it to work, in about 35ns if memory serves. Secondly, you'll probably get a glitch on DTACK* anyway, since for expansion memory, GARY generates DTACK* from AS* alone. That's no problem, though, since the 68000 (or anyone else monitoring DTACK*) can only look at DTACK* by sampling it on falling edges of the 7MHz clock after 68000 state S4. Any DTACK* glitch generated this way will be over in S2 or so. Finally, make sure you only generate XRDY (or OVR*) for your own devices. There is no way you can alter the timing of DTACK* for any other device in the system. >Now I'm thinking that maybe I should pull OVR* (override) down, >and generate DTACK* myself. You could do that, too. OVR* needs to go in 60ns or so from AS*, a little easier to generate than XRDY. You'll still get a glitch on DTACK*, which again won't be a problem. And as with XRDY, you can only generate OVR* for your own device. >John Flanagan Center for EUV Astrophysics -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
johnf@ssl.berkeley.edu (John Flanagan) (05/08/91)
In article <21304@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
[Lots of useful information. Thanks!]
Actually, I've just realized that since GARY
presumably generates the same DTACK* timings regardless of processor
speed (since it is clocked at the motherboard's 7.14 MHz), my problem
can't be with the hardware but rather with the software; the
interface does work at slower CPU speeds. I'll have
to try adding some delays, or readiness polling, to the device
driver's data transfer loops, whenever my registration package
arrives. I hope the registration package does contain the source code.
Thank you, Dave.
John
--
John Flanagan Center for EUV Astrophysics
johnf@ssl.berkeley.edu University of California
(...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720