Re: IIgs and call-151

[Rubywand <rubywand@my-deja.com>]

dempson@actrix.gen.nz (David Empson) writes ...

> 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.
>

LOL! No kidding!


> 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.
>

    "Shadowing" seems to mean that something written to one address is
automatically duplicated at another address-- e.g. writing to $2000 in
one 64k bank stores a byte there and at $2000 in another bank. The
address space $C100-$FFFF for RAM in the banks mentioned may be given to
ROM located in bank $FF; but, there does not seem to be any shadowing of
$FF/C100-$FFFF to the RAM.



> 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.

     Probably. Except the "ROM in bank 0" being "switched back on" stuff
can be confusing because it sounds like there are two ROMs instead of
just the one block of system ROM which is nominally 'physically located'
at the top of memory-- e.g. banks $FE and $FF. This ROM is being
accessed at different bank locations (e.g. sometimes bank $FF and
sometimes bank $00.) to accommodate Apple's kludged design for supplying
8-bit A2 compatibility.



> 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.
>

     Guess you mean to say "it probably switches back to running from
ROM via bank $00".



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

     Okay, yes, for all practical purposes, the ROM exists in bank $00
for at least some of the time you are in the monitor, running a BASIC
program, or engaged in some other 8-bit A2 activity. However, since, at
such times, the IIgs is pretending to be an 8-bit Apple II, it seems
fair to say that the ROM is pretending to be at its expected 8-bit
location (bank $00).

     My reason for saying that the "pretense" (i.e. emulation) breaks
down when you do a 'normal' (bank 00) F800L command in the monitor is
that you do not get the expected disassem listing of ROM code. As far as
I know, only on a IIgs will you get a listing of 'Language Card' RAM
contents at $F800 ... .

     IIgs designers could have arranged to list the ROM code as though
it were present (in bank $00); but, that could have involved messy
exceptions. Listing RAM in bank $00 instead is the right solution and a
nice feature.



Rubywand


Sent via Deja.com
http://www.deja.com/