rwm@atronx.ocug.on.ca (Russell McOrmond) (11/29/90)
Now that I am running Enforcer, I find programs that read/write from Low
memory (<1K). I myself am running an A3000 under 2.0, and these programs do
not cause any problems. These programs sometimes don't run on other computers,
though.
I am wondering if there is a 'memory map' available somewhere that would show
what is stored where in low memory (Specifically under 1.3, as this is what
most of the people with problems are running.)
ANY information appreciated.
(Specifically, anyone know what is stored in location $16? In $217 and $218?)
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.ocug.on.ca {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109limonce@pilot.njin.net (Tom Limoncelli) (11/30/90)
In article <54811.659833076@atronx.ocug.on.ca> rwm@atronx.ocug.on.ca (Russell McOrmond) writes: > I am wondering if there is a 'memory map' available somewhere that would show > what is stored where in low memory (Specifically under 1.3, as this is what > most of the people with problems are running.) > > ANY information appreciated. > >(Specifically, anyone know what is stored in location $16? In $217 and $218?) When I first started programming the Amiga I asked a similar question of a local guru. His response was, "Location $4 stores the value of &ExecBase; all the other locations <1K store the same thing: Nothing you should TOUCH!" :-) Seeing the number of programs that break under 2.0 due to this, I'm glad I followed the advice. Actually I had asked out of curiosity. I'm so paranoid of writing code that will break under future OS's that I try to forget any "European neat trix" that pop up on the net. -Tom -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
DXB132@psuvm.psu.edu (11/30/90)
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. The addresses you mention are pretty much unused and unuseful, so are a result of program bugs. Typically the only writing that should occur is by debuggers and similar programs, or by programs taking over the autovectors (which Commodore docs say you shouldn't do, but some people do anyway. Usually quite harmless). Hope this clears things up a bit. -- Dan Babcock
daveh@cbmvax.commodore.com (Dave Haynie) (12/06/90)
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...........