Integer BASIC & Applesoft BASIC Do Not Work

["Bryan Parkoff" <bryan.nospam.parkoff@nospam.com>]

    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.
    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.
    It is how Integer BASIC and Applesoft BASIC fail to work if it attempts
to overwrite or modify from $00 to $FF on $D000 through $FFFF because it can
modify monitor routines and autostart routines.  It is interesting.  How do
software understand memory available without hardware's help?  Who is doing
clever by writing 6502 assembly language that is $F000 through $F022
routine.  It can have bug by overwriting Integer BASIC routines or Applesoft
BASIC routines on $D000 through $F7FF, but it should be designed to prevent
overwriting like using branch.
    I switched from RAM back to ROM on $D000 through $FFFF so it can only
scan by reaching 48K before it does not modify monitor routines and
autostart routines.  Integer BASIC and Applesoft BASIC start to work fine.
    Have you done the same experiment?  I am so curious.

-- 
Bryan Parkoff