Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bpa!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Bus Latency
Message-ID: <8691@cbmvax.UUCP>
Date: 23 Nov 89 04:49:01 GMT
References: <18387@watdragon.waterloo.edu>
Organization: Commodore Technology, West Chester, PA
Lines: 35

in article <18387@watdragon.waterloo.edu>, himacdonald@lion.waterloo.edu (Hamish Macdonald) says:
> Keywords: fast ram exception vector table
> Summary: Why not fast RAM exception vector table?

> In article <8652@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>>...
>>With CPU driven I/O, you'll need a few cycles, since interrupt
>>vectors are currently stored in chip memory, but it's not that bad.

> It seems to me that a program such as Dave's SetCPU could either:
>   1) copy the exception vector table to fast RAM and remap
>      using the MMU (w 68030 or 68851) (a la 32 bit Kickstart RAM).

As long as no one's counting on the low areas of memory actually being
Chip memory, this would certainly work.  I've thought of it before, but
never got around to it.  Now Commodore-Amiga is in charge of SetCPU.
They could add this, but I think the better solution would be to teach
Exec to use VBR on 68010 on up (SetCPU uses it).  I've never tried to
remap things by changing VBR, but long ago someone told me it didn't
work.

> This could be a problem if anything other than the CPU alters the
> exception vector table, however.

I think that would be a very bad idea.  DMA device should assume they
have access to generic RAM within their address space and of course
chip memory, but they shouldn't believe they know anything about
CPU vectors or I/O registers (some of which are inaccessible in 
hardware with the current system anyway).

> Hamish.
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough