Path: utzoo!utgpu!watmath!att!pacbell!ames!sun-barr!oliveb!pyramid!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DTACK* or not to DTACK*, that is my question...
Message-ID: <7569@cbmvax.UUCP>
Date: 8 Aug 89 05:16:12 GMT
References: <119697@sun.Eng.Sun.COM> <7563@cbmvax.UUCP>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 23

In article <7563@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <119697@sun.Eng.Sun.COM>, raz%kilowatt@Sun.COM (Steve -Raz- Berry) says:
> > Keywords: hardware hairy hendersons VMA* VPA* DTACK* and their brothers.
> 
> 
> Well, it sounds like you're interested in the normal way of building a 68020
> or 68030 CPU interface for an A2000 type machine; far as I know, everyone
> does AVEC in much the same way.  It still doesn't make your 8520 interrupts
> fast, since they get vectored to a table that's in Chip memory unless you
> use the VPA register, which apparently isn't supported in 1.3, or use some
> MMU tricks.

Gawd Dave, it must be getting late.  It's the VBR register (vector base reg),
and maybe it'll be supported eventually if/when available.  However, some
discussion with the software folk reveals that simply getting the vectors
out of chip ram is only a partial solution.  The software has to make several
access to chip registers as part of the interrupt serivce/analysis processing,
so all you can do is reduce the number of "slow" accesses, not eliminate them.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)