Author: Johan Klockars (62.13.18.80)
Date: 08-07-2003 14:27
> I suppose all TOS is in RAM after the boot sequence
As someone else said, TOS is never (normally) copied to RAM. Naturally, it has to keep all data that can change in RAM, though.
> otherwise you won't be able to load an external TOS as I suggest in my previous writing.
That's simply a matter of overriding all the OS trap and interrupt vectors (see below).
> I can't imagine VDI, AES, BIOS, XBIOS and GEM functions dynamicly changing their call pointer depending on the way TOS have been load...
But, you see, there are no call pointers when accessing the OS functions, so this is not a problem.
(Of course, the OS uses subroutines and such internally. Anything that uses absolute rather than relative addresses would need to be modified if the OS was copied somewhere else. Unlike for normal programs, the OS does not contain the information needed to do this, however.)
A normal function in a program, or in a library for that matter, is indeed usually called via some kind of pointer. The assembly code generated by a C compiler for a call to the memory allocation function malloc() might look like this, for example:
move.l #1024,-(a7) ; Amount of memory to allocate
jsr _malloc
addq.l #4,a7
_malloc above is indeed an address to the code for the allocation function and would need to be changed if that function was moved somehow.
Now, if you take a look at the equivalent TOS (GEMDOS) call, that would rather be:
move.l #1024,-(a7)
move.w #72,-(a7) ; Malloc
trap #1
addq.l #6,a7
Here we have a function number (72 for Malloc) instead of a pointer to a subroutine, so there's no need to know where the function actually is. The 'trap #1' instruction jumps to a special routine whose address is located at address $84 (in the trap vector table). That routine looks at the stack, finds the numeric code for Malloc, and jumps to the appropriate subroutine.
> Especialy when you need to load a patch for your TOS. TOS ROM are not EEPROMs !!! No device is available to flash them like BIOS on PCs...
TOS patching is really ugly, but there's nothing strange about it.
As I mentioned above, the 'trap' instruction that causes the OS to be called finds the address of the OS code in a specific place in memory. You can modify the contents of that address to point somewhere else.
So, if you wanted to intercept the Malloc call and do something else with it, you would do something along the lines of (this is simplified):
...
move.l $84,old_trap1 ; Remember old trap address
move.l my_trap1,$84 ; Insert address of my own routine
...
my_trap1:
cmp.w #72,6(a7) ; Was it a Malloc?
beq my_malloc ; Yes, go to my code instead
move.l old_trap1,-(a7) ; No, continue to previous trap 1 code
rts
Now, any Malloc call will end up at 'my_malloc', while all other GEMDOS calls will go where they used to.
It should be obvious that you can 'chain' any number of these kinds of patches on top of eachother. It will obviously cost some time on every OS call, though.
It's not unusual for a normal Atari system to have to go through three or more of these chained routines before ending up in the code that actually performs the requested job. That can easily waste a hundred clock cycles or more.
I think I have more than half a dozen of these things chained on some of the OS trap vectors in my Falcon.
> Boot sequence on the (Mega)ST(E)s is cartridge slot, floppy, (hard disk?) and ROM.
Wherever TOS is found, it is loaded to the bottom of the RAM.
The machine always boots from ROM. At the very bottom of the memory map there is an address that tells the CPU where to begin executing (the bottom 8 bytes are mapped to ROM). In the ROM there is code that looks at the cartridge port and the boot sectors of the floppy and/or hard disk.
That code does not look for a TOS, however, it only looks for something that appears to be executable. That's how a diskette based game usually starts, for example.
The executable code that is found may or may not load a TOS. If it does, it is not loaded at the bottom of RAM, since that's reserved for trap vectors, system variables etc. The place to locate a RAM TOS is right at the top of RAM, since everything (except the amount of available RAM) will then look exactly as it would in the normal case.
Anyway, it's most likely, IMO, that a TOS replacer would allow normal TOS to start up and then have some kind of AUTO folder program that loads a TOS image from a normal file (or has it built in), relocates it, kills the original OS (by replacing all the trap and interrupt vectors etc), and reboots into the new OS.
That's how MagiC does it, for example.
|
