Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!genbank!ames!pacbell!att!watmath!watserv1!watdragon!lion!himacdonald
From: himacdonald@lion.waterloo.edu (Hamish Macdonald)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Bus Latency
Summary: Why not fast RAM exception vector table?
Keywords: fast ram exception vector table
Message-ID: <18387@watdragon.waterloo.edu>
Date: 21 Nov 89 13:41:47 GMT
References: <329@berlioz.nsc.com> <8652@cbmvax.UUCP>
Sender: daemon@watdragon.waterloo.edu
Reply-To: himacdonald@lion.waterloo.edu (Hamish Macdonald)
Organization: U. of Waterloo, Ontario
Lines: 31

In article <8652@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>...
>With fast memory and DMA, you only need one cycle to chip memory, at
>worst, to get unrestricted access to fast memory at full bus speeds.
>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.
>Some devices may not work at acceptible rates with hires 4 plane
>overscan screens if you only have chip memory.  With a little fast
>memory, there's not a big problem.	
>...
>-- 
>Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"

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).
or
  2) Assuming EXEC handles all the registers correctly, copy the vector
     table to fast RAM and change the Vector Base Register (on 68020 or
     68010) to point to the new table.

This would avoid the delay accessing chip memory during an exception.

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

Hamish.
----------------------------------------------------------------
Hamish Macdonald.
himacdonald@lion                        watmath!lion!himacdonald
himacdonald@lion.uwaterloo.ca      himacdonald@lion.waterloo.edu