Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!fernwood!portal!atari!trh
From: trh@atari.UUCP (T R Hall)
Newsgroups: comp.sys.atari.st
Subject: Re: Two New Computer Announcements - CeBIT
Message-ID: <2887@atari.UUCP>
Date: 1 Apr 91 19:03:19 GMT
References: <2867@atari.UUCP>> <gbux2Yy00WC0ImXbxT@andrew.cmu.edu> <2885@atari.UUCP> <1991Mar28.075533.11530@jato.jpl.nasa.gov>
Organization: Atari Corp., Sunnyvale, CA
Lines: 22

hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:

>.... Um, if *all* the address lines are
>present, does this mean the CPU is now allowed to address its full 16MB
>address space? Or does the GLUE still bus-error on writes outside the 4MB
>limit?

>  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

	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. So, the CPU CAN address the full 16MB space; the
circuitry in the GLUE was to make sure there is a BERR in any un-occupied
space. Your circuitry can generate a DTACK to any space (that the glue doesn't
respond to), and if it keeps /AS under 1uS, then everything is fine. 
	[I probably shouldn't say this part, but what the heck...]
	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.

					TRH