Article 172408 of comp.sys.apple2: Newsgroups: comp.sys.apple2 Subject: Re: IIgs and call-151 From: dempson@actrix.gen.nz (David Empson) Date: Sat, 6 Jan 2001 01:07:28 +1300 Message-ID: <1ems9x1.1mxlbcf1b6x8seN%dempson@actrix.gen.nz> References: <3A54C82D.44DD10FE@usb.com> <3a54db94.235135163@news1.on.sympatico.ca> Organization: Empsoft User-Agent: MacSOUP/2.4.2 NNTP-Posting-Host: 202.49.157.176 X-Original-NNTP-Posting-Host: 202.49.157.176 X-Trace: 6 Jan 2001 01:45:09 NZST, 202.49.157.176 Lines: 41 Path: news1.icaen!news.uiowa.edu!norand.com!avalon.net!HSNX.atgi.net!usenet.INS.CWRU.Edu!nntp.msen.com!newsxfer.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-xfer.siscom.net!news.iprolink.co.nz!news.actrix.gen.nz!dempson Xref: news1.icaen comp.sys.apple2:172408 Jeff Blakeney wrote: > On Thu, 04 Jan 2001 12:59:57 -0600, Dennis Jenkins > wrote: > > > On my ROM1 GS, running either ProDOS or Dos3.3, I can not seem to use > >the monitor rom program correctly. I expect "F819L" to disassemble the > >code that does HLIN. The code that it displays has nothing to do with > >lowres graphics. Yes when my assembly and C programs 'jsr $f819', HLIN > >is performed. > > When you get to the monitor prompt, instead of just typing F819L, type > FF/F819L. That appears to be the code you are looking for. > > I have no idea why the code in 00/F819 is different from what is at > FF/F819. The IIgs monitor has special support for the "language card" RAM ($D000-$FFFF). This means that whenever you examine memory in banks 0, 1, $E0 or $E1 within this address range (using a memory dump or a disassembly), you will always see the language card memory, not the ROM. There is also a special command to select the language card bank for monitor commands. Without going and looking it up, I think it is 1=L and 0=L (case sensitive). This selects between the two banks in the $D000-$DFFF area. The $E000-$FFFF area only has one bank. If you want to see the ROM code that would normally be accessed in these memory areas, you have to refer to it in bank FF (which is never switched out). The G (go) command always restores the language card bank switching to the normal (or configured) state before calling the specified location. This means that you can safely call monitor or BASIC routines in bank 0 (or call machine code programs which in turn make calls into the ROM). Note that you can't use the G command unless the monitor's active bank is set to 0, because the G command always executes code starting out in emulation mode, and emulation mode cannot be used to run code outside of bank 0 (at least, not safely). If you've just done FF/F819L, you will have to use 0/300G (or whatever) to call a routine in bank 0. Article 172421 of comp.sys.apple2: Newsgroups: comp.sys.apple2 Subject: Re: IIgs and call-151 From: dempson@actrix.gen.nz (David Empson) Date: Sat, 6 Jan 2001 16:45:12 +1300 Message-ID: <1emtkzb.1ghj6uptpy9l6N%dempson@actrix.gen.nz> References: <3A54C82D.44DD10FE@usb.com> <934cfe$9vc$1@nnrp1.deja.com> Organization: Empsoft User-Agent: MacSOUP/2.4.2 NNTP-Posting-Host: 202.49.157.176 X-Original-NNTP-Posting-Host: 202.49.157.176 X-Trace: 6 Jan 2001 17:23:01 NZST, 202.49.157.176 Lines: 55 Path: news1.icaen!news.uiowa.edu!norand.com!avalon.net!HSNX.atgi.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-xfer.siscom.net!news.iprolink.co.nz!news.actrix.gen.nz!dempson Xref: news1.icaen comp.sys.apple2:172421 Rubywand 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.