tnewmanda@cc.curtin.edu.au (05/06/91)
Can I please have some help with a Frame Grabber board for the Amiga 2000? The problem is as follows: I'm using the example circuit from the A2000 technical manual for the bus interface. Having built and tried the circuit I'm unable to get it to work! I've tried using a logic analyser to monitor the bus signals which seemed to indicate the lines expected to be active during the auto-config sequence differred from the PAL equations supplied in the manual. Does anyone know if these PAL equations are correct or if there are any problems with this example design. If any can help with a better design or reference manuals that explain bus interfacing for the ZORRO2 please post to this news group or on Email. Trevor Email Address TNEWMANDA@CC.CURTIN.EDU.AU
daveh@cbmvax.commodore.com (Dave Haynie) (05/08/91)
In article <1991May6.112803.8009@cc.curtin.edu.au> tnewmanda@cc.curtin.edu.au writes: >Can I please have some help with a Frame Grabber board for the Amiga 2000? >The problem is as follows: >I'm using the example circuit from the A2000 technical manual for the bus >interface. Having built and tried the circuit I'm unable to get it to work! The autoconfiguration logic is pretty simple. But you really don't want to make exact copies of what's in the A500/A2000 Technical Reference Manual. That's provided mainly for your education, so that you can see one practical application of the general concepts in this book. In any case, while it's been some time since I looked at this, my copy of the manual seems to indicate that there are two bugs in the TESTRAM PAL on page 43. These are the correct versions of the equations: DBOE = /RES * BDSEL * /BERR * /SHUTUP * /RD + /RES * BDSEL * /BERR * /SHUTUP * RD * ASQ CONOUT = /RES * /ASQ * PRECON + /RES * CONOUT If you copied that DBOE equation verbatim, your problem was that the read term (second and term) was looking for SHUTUP asserted rather than negated, so you never turned data buffers on for reads. That's why I recommend really learning these equations; it would be an obvious problem if you looked it over very carefully. I realize that it's often hard to trust your judgement over that of some authoritative reference. But even authoritative references ain't perfect. -- 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.
aduncan@rhea.trl.OZ.AU (Allan Duncan) (05/13/91)
From article <21385@cbmvax.commodore.com>, by daveh@cbmvax.commodore.com (Dave Haynie): ... > If you copied that DBOE equation verbatim, your problem was that the read > term (second and term) was looking for SHUTUP asserted rather than negated, > so you never turned data buffers on for reads. That's why I recommend really > learning these equations; it would be an obvious problem if you looked it > over very carefully. I realize that it's often hard to trust your judgement > over that of some authoritative reference. But even authoritative references > ain't perfect. Any other annotations in your copy of the Tech. Ref. Man.? Given the flow of information to this country, I'm sure it will help our few remaining isolated hardware developers. (I'm sure one acquaintance will have banged his head on this one). Allan Duncan ACSnet a.duncan@trl.oz (+613) 541 6708 Internet a.duncan@trl.oz.au UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.