Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!dkuug!imada!micro
From: micro@imada.dk (Klaus Pedersen)
Newsgroups: comp.sys.atari.st
Subject: Re: Two New Computer Announcements - CeBIT
Message-ID: <1991Apr3.180910.7427@imada.dk>
Date: 3 Apr 91 18:09:10 GMT
References: <2867@atari.UUCP>> <gbux2Yy00WC0ImXbxT@andrew.cmu.edu> <2885@atari.UUCP> <1991Mar28.075533.11530@jato.jpl.nasa.gov> <2887@atari.UUCP>
Sender: news@imada.dk (USENET News System)
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Lines: 42

trh@atari.UUCP (T R Hall) writes:

>	Actually, the way the Glue chip "Bus Errors" is that it has a
>(minimal) timer that watches /AS. If /AS is longer than 1uS (1000nS) than
>it generates a /BERR. 

Using the /AS to generate the BERR?? What a great hack!!! Even motorola don't
mention that it can be done that simple - instead they say (quote) :
        "BUS ERROR AND HALT OPERATION
         ...
         External circitry must be used to determine
         the durtion between address strobe and data
         transfer acknowledge before issuing a bus
         error signal..."

/AS and /DTACK is coupled very closely... (great hack)

There is one thing that worries me though - 1uS timeout??? From what
I can see in the motorla docs. then a Read-Modify-Write Cycle have
the /AS low for 8.5 cycles (at 8Mhz this is sligthly longer than 1uS??)
Don't you mean something like 64 cycles (or 8uS???).
One thing is sure - the read-modify-write instruction TAS, don't trigger
a bus-error (it's used to check if the blitter is ready).

>	[I probably shouldn't say this part, but what the heck...]
(Please do...)

>	For those who really want to kludge, you could even respond to
>accesses that are in spaces the Glue decodes, but doesn't respond to, such as
>WRITES to ROM spaces. Of course, you can't READ what you wrote (because of ROM
>responses to read), but the writing part of the kludge would work.

Kind of WOM (write only memory), it's very cheep to manufacture - there is
one problem though (it's kind of hard to get the information back out) ;-)

Even better than generating a /DTACK on internal ROM, is generating it
on the ROM port - remember to put the R/W signal through a hole in the box...

Keep up the good work, TRH - and let us know all the details...
---

Klaus (micro@imada.dk)