[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IIgs and call-151



Rubywand <rubywand@my-deja.com> wrote:

>      The confusing thing about this business is that the IIgs is set up
> to act like the monitor ROM is in Bank 00 whenever it thinks you are
> doing 8-bit Apple II stuff (like when you access a monitor routine while
> in the monitor or are running a BASIC program).
> 
>      On the other hand, it drops the pretense when it comes to viewing
> memory under the monitor. There is no ROM in Bank 00. So, when you do an
> F800L, you end up looking at part of Bank 00 'Language Card' RAM.

It isn't as simple as that.

Physically, the ROM is located in banks $FE and $FF (also $FC and $FD on
the ROM 3 IIgs).  The monitor firmware occupies all of $FF/F800-FFFF,
plus a fair amount more in bank $FF, somewhere below location $C100.

The IIgs hardware is almost always set to emulate the memory map of the
8-bit Apple II in banks 0 and 1, i.e. built-in I/O and slots in
$C000-$CFFF, and bank-switched RAM or ROM in $D000-$FFFF.  The contents
of $D000-$FFFF are determined by the soft switches which date back to
the Language Card used in the Apple ][ and Apple ][+, and are built in
with the IIe and IIc.

Banks $E0 and $E1 are permanently mapped like an 8-bit Apple II, with
I/O space in $C000-$CFFF and ROM or language card RAM in $D000-$FFFF.

When the appropriate portions of the ROM are enabled, the $C100-$FFFF
area in banks $00, $01, $E0 and $E1 are is shadowed from bank $FF.

Applesoft BASIC ($D000-$F7FF) runs in emulation mode, in ROM, in bank 0.

The monitor runs in a mixture of emulation and native mode.  When it is
running in emulation mode (as it is on entry via CALL-151), the code is
executing from ROM in bank 0.  Most monitor commands and many of the
support routines switch to native mode and call extended routines in
bank $FF (below $C100), but they always end up back in emulation mode
while waiting at the command prompt, if not earlier.

If you do something like 00/F800L, the monitor will be executing code
(in native mode) in bank $FF to handle the command.  As part of this, it
turns off the ROM in bank 0, so the underlying bank-switched (language
card) RAM will be accessed by the disassembler.  The ROM in bank 0 is
switched back on again as soon as the disassembly is complete.  In fact,
it probably switches back to running from ROM after each byte is
fetched, because it is using normal monitor routines to output the text
for the disassembly, all of which must run in emulation mode in bank 0.

In other words, the monitor is bending over backwards to pretend that it
is NOT present in bank 0, when in fact it is.


If the IIgs is running in native mode under GS/OS, it would normally
have the language card area enabled and the ROM disabled in banks $00,
$01, $E0 and $E1.