Vince Briel wrote: > The card is an integer basic rom card. When in monitor mode, ctrl-c > puts me into integer basic. > > However, when I type "new" everything is ok, I get the ">" prompt. If I > type "10 print" it freezes up. > > Anybody know why? You probably haven't initialized Integer BASIC correctly. After starting up the machine or resetting with the card enabled for the first time, you will initially be in the monitor (* prompt). The first time you enter BASIC, you have to use the "cold start basic" command, which is Ctrl-B. If you subsequently enter the monitor using CALL-151, you can return to BASIC with Ctrl-C ("warm start" command). Ctrl-B jumps to location $E000, while Ctrl-C jumps to $E003. The same situation applies to Applesoft BASIC - it has to be cold started the first time you use it. This is normally done automatically by the Autostart monitor (if you don't boot from a floppy), or by DOS 3.3 (or ProDOS). You need to repeat the "cold start" command if you switch between Applesoft and Integer BASIC (or vice versa). DOS 3.3 normally handles this for you, but you have to do it by hand if you are using the ROM card to switch between BASICs. -- David Empson dempson@actrix.gen.nz Bryan Parkoff wrote: > I did an experiment to switch from ROM to RAM at $D000 through $FFFF. I > mean that $D000 through $FFFF are set to read/write instead of read-only > mode. I can be able to modify monitor routines and autostart routines. For > example, I change from $A5 + $22 (LDA $22) to $60 (RTS) at $FC58 (HOME) by > typing "*FC58: 60 (CR)" using Apple II+'s keyboard. You type, "CALL - 936" > or "HOME" to clear the screen, but it will never clear the screen. > I start to test Integer BASIC and Applesoft BASIC by typing, "*E003G > (CR)". "> 65535 " appears for Integer BASIC and Applesoft BASIC crashed. Not surprising. You can't start Applesoft or Integer BASIC from this entry point (warm start, Ctrl-C command from the montior) unless you have previously done a cold start of the same BASIC (E000G, Ctrl-B command from monitor). Note that if you're using DOS, you shouldn't use either of these entry points: use 3D0G instead. The cold start routine is responsible for setting up the zero page variables required by BASIC. If you bypass this step, critical zero page variables might contain arbitrary data which results in strange side effects if you attempt to enter BASIC by doing a warm start. For example, Applesoft BASIC has a self-modifying function on zero page which fetches the next token from a program. This function is placed on zero page by the cold start routine. If it is missing, Applesoft will crash as soon as you try to execute a command. Another likely problem is the memory limit variables (HIMEM and LOMEM), as they will not be set correctly, possibly resulting in BASIC trying to overwrite memory in the zero page, stack, text screen, DOS (if present), I/O space and the language card. > I did discover that $F000 through $F022 routine after I typed "*E000G > (CR)" is used to modify from $00 to $FF each page ($0000 through $FFFF). I > suspect that this routine is used to test RAM available like 4K, 8K, 16K > through 48K. If it is only 8K on RAM, it will stop scanning until it > reaches $1FFF. If it is only 48K on RAM, it will stop scanning until it > reaches $BFFF. If it is only 64K on RAM, it will stop scanning until it > reaches $FFFF. There probably is a routine which does a memory size test, as part of the cold start function. It is designed to test memory starting at 0800 and stopping at BFFF. I don't remember how this interacts with RAM-based versions of Applesoft (loaded from tape into low memory) or with DOS/BASIC.SYSTEM. -- David Empson dempson@actrix.gen.nz