Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!mvb.saic.com!ncr-sd!se-sd!cns!dltaylor
From: dltaylor@cns.SanDiego.NCR.COM (Dan Taylor)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: GVP Acceloraters
Message-ID: <882@cns.SanDiego.NCR.COM>
Date: 1 Apr 91 20:17:14 GMT
References: <871@cns.SanDiego.NCR.COM> <1991Mar29.003740.18783@unislc.uucp>
Organization: NCR Corp. SE-San Diego
Lines: 32

In <1991Mar29.003740.18783@unislc.uucp> dave@unislc.uucp (Dave Martin) writes:

>From article <871@cns.SanDiego.NCR.COM>, by dltaylor@cns.SanDiego.NCR.COM (Dan Taylor):

>So, what is the problem with GVP boards?

No problem with the boards, that I've heard of.  But, you have to
understand UNIX, so....

>Is the memory strange?  Unix ported to run on a 68030 should run
>on a 68030.  Now admittedly you could have different bus/hardware things to
>worry about if it were a different architecture

Ahhh, but it IS a different architecture, in small, but significant ways.
Most importantly, the disk support is different, IDE, not SCSI, and a
different interface.  Since UNIX disk drivers are part of the kernel, not
read from ROM ( I know, I know, some do,  But if you have UNIX ROMs, can
you still run AmigaDOS? ), the distributed kernel won't have GVP disk
drivers in it.  Why not?  That's really GVP's responsibility, not C='s.
The same holds for all other disk controller makers.  Also, I believe
( please, GVP, correct me if I'm wrong ) that the memory on some of
the GVP accellerators may be physically mapped to different address, both
auto-config and other.  If this is true, then the early initialisation
code in the UNIX kernel will have to know to search those locations, in
order to create memory management tables for it.

There wouldn't be major changes to the kernel, nor any changes to non-
disk-format utilities, but at least these would have to be done.

Hope this helps.

Dan Taylor