[Please note that I've directed followups to comp.sys.apple2.programmer again - this discussion isn't appropriate on comp.sys.apple2.marketplace or comp.sys.apple2.usergroups.] Bryan Parkoff wrote: > If it is true that Apple II has no language card for Interger BASIC > and/or Applesoft BASIC, it will jump to ROM Monitor that will appear with > "*" prompt. It is interesting. That is not what I was saying. The language card and availability of BASIC has nothing to do with it. The original Apple ][ firmware ("Old Monitor ROM") behaves differently from the later firmware ("Autostart Monitor ROM") which was introduced with the Apple ][+. The F8 ROM chip (containing the monitor) can be swapped between an Apple ][ and ][+, so you can run either machine with either version of the monitor. In addition, Apple made a ROM card which was typically installed in slot 0. They had a version of this card which came with Applesoft BASIC and another which came with Integer BASIC. The Applesoft version included the Autostart Monitor, and the Integer version included the Old Monitor. These cards use the same ROM chips as the Apple ][ and ][+, so you can also swap chips between these cards and the motherboard. The card has a switch on the back which specifies whether the card or motherboard ROM will be activated when the computer is reset. If you were running DOS, it would recognise this card (as long as it was installed in slot 0) and let you switch between Integer and Applesoft BASIC using the INT and FP commands. The card also had a "solder blob" modification option which lets you specify that the motherboard F8 ROM should always be used, rather than switching between the card and motherboard ROM. This means you can install your preferred monitor ROM (probably the Autostart one) on the motherboard and still get access to both Integer and Applesoft BASIC through the use of the switch. The language card came along later. It was also designed to work in slot 0, so you typically cannot use it at the same time as the Integer/Applesoft ROM card (unless you patch DOS 3.3, and even then it isn't a good idea). The language card provides 16K of RAM (with two 4K banks at $D000-$DFFF, allowing the whole thing to fit into the 12K address space $D000-$FFFF). Using the language card for supporting both Integer and Applesoft BASIC requires booting into DOS 3.3. At startup, the HELLO program (or a utility program called by it) detects the language card, works out which version of BASIC is on the motherboard, and loads the other one into the langauge card from the INTBASIC or FPBASIC file. Early versions of DOS 3.3 had a 50 sector version of these files which included the entire $D000-$FFFF area, i.e. it included the monitor as well as BASIC. I think that both INTBASIC and FPBASIC included a copy of the autostart monitor. In later versions (designed for the IIe) the size of the INTBASIC and FPBASIC files dropped to 42 sectors and they added a binary file called LOADER.OBJ0 which did the loading of whichever one was appropriate. With this variant, the monitor was copied from the motherboard to the language card, rather than using a version buried in the file. It is also worth noting that the IIe 80-column firmware has some support code which copies the monitor into the language card if it detects that BASIC is being used. I haven't looked closely enough at the enhanced IIe or the IIc or IIgs to see whether this practice has continued. The language card is also used for other purposes. For example, when booting ProDOS, the operating system kernel and several device drivers end up in the language card, leaving most of main memory free for use by SYS applications. (BASIC.SYSTEM occupies roughly the same amount of space as all of DOS 3.3, so you don't get any extra memory for Applesoft BASIC programs.) The language card is also used to hold part of the Apple II Pascal operating system. Another factor which comes into play here is that for the Apple ][ and ][+, the language card enable state is not affected by a hardware reset. This means that if the computer is reset while the language card is active, it is the code in the language card which controls the reset operation. For Pascal, the operating system reinitializes itself and returns to the main menu. For ProDOS, the operating system transfers control to the firmware reset routine. For DOS 3.3, the reset will be handled by the copy of the monitor in the language card, typically the autostart version, which will end up doing a warm reset via the $03F2/$03F3 vector, which will warm start DOS. This behaviour does not apply to the IIe and later machines. They have the equivalent of the language card built into the motherboard, but a hardware reset will always switch control back to the ROM, so the monitor will handle the reset. (This means that it is not possible to warm reset the Pascal operating system on a IIe and later, because the monitor's reset code overwrites some Pascal system variables, and Pascal doesn't attempt to regain control via the $03F2/$03F3 vector.)