🚀 go-pugleaf

In article <90333.154505DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>In article <54811.659833076@atronx.ocug.on.ca>, rwm@atronx.ocug.on.ca (Russell
>McOrmond) says:
>
>>(Specifically, anyone know what is stored in location $16?  In $217 and $218?)

>The memory from 0 to $400 is the  interrupt vector area, and a map may be found
> in any 68000 book. Most locations are not really used for anything. The only
>location defined by the operating system is location 4. 

And across all possible Amiga configurations, the ONLY thing you can assume is
that location 4 stores the ExecBase pointer.  The vector space isn't really
started at location 0, it's actually relative to the VBR register.  Only, since
68000's don't have a VBR register, they use the default VBR value of 0.  Most
of the time, you don't want to mess with a system vector anyway, since it'll
have a global effect (tasks have a task-private exception vector that's even
easier to use and doesn't muck with anyone else), but if you do, think again
anyway.  If you still do, at least make sure it works on all Amiga systems.

Anything that has to be done like this, at a global level, should NEVER, under
ANY circumstances, become part of an application program, since that is an
operating system job.  If the current OS doesn't support that operation, 
chances are a future one will.  A good example is my SetCPU program.  It did
things that the 1.3 OS didn't properly know about, but it's basically an OS
substitute at that level.  Now 2.0 does most of the same things, and not only
does SetCPU become a little redundant under 2.0, but SetCPU V1.5 (written 
without knowledge of 2.0) doesn't completely work under 2.0.  That's easy to
fix, and I did with SetCPU V1.6, but the last thing you would want is five or
six application programs thinking they could mess with the same things SetCPU
did and all having to be updated now.  One of the major problems with MS-DOS,
more than anything, is that nearly every program out there has to do a large
number of OS level things, since the OS didn't provide for them.  That's a 
heavy load of architectural baggage that forever limits that OS.  The AmigaOS
and 680x0 architecture in general requires a split between application and
operating system functions, but if you support that split properly, all 
applications run on any member of the 680x0 family with a suitably patched
OS behind it.  C= is not going to tolerate the MS-DOS kind of ugliness on the 
AmigaOS, so if you do an OS-type thing in an application, you can expect it 
to break under future OSs.  

>-- Dan Babcock


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
		      Wheeeeeeeeeeeeeeee...........