On Sun, 22 Mar 1998, Hotze wrote: A "language card" basically had an additional 16K of memory that mapped into the upper 16K of the Apple's memory and was accessed by bank switching. To switch to the RAM bank, you would access memory location $C083. To switch back to the ROM, you would access memory location $C081. The Apple ROM (including the monitor and BASIC interpreter) was also located in this region. If you switched to the RAM, your computer would lock up because all of a sudden its monitor code disappeared (you just turned on the RAM which overrode the ROM space) and it would execute an invalid instruction and halt. A reset is required. A neat thing you could do if you wanted to play around with the memory up there is to copy the monitor ROM into the language card RAM and then switch to the RAM. Since the same ROM instructions were now in the RAM, switching to the RAM was no big deal because the system just continued executing ROM code in RAM. So to do this, first get into the monitor if you're not already there by doing: ]CALL -151 * Now do: *D000<D000.FFFFM This moves the ROM code starting from $D000 through the end of memory at $FFFF (which includes BASIC and the monitor) to the RAM. Any writes to locations $D000-$FFFF will still be stored in the RAM (but since the ROM is active, any reads will return the bytes in the ROM). By executing this move instruction, you're copying ROM to RAM. Now turn on the language card memory: *C083 This simple memory access gates the RAM. You now have before you a fully modifiable Apple ROM! You can start haphazardly poking bytes between $D000-$FFFF which will eventually have the effect of royally screwing the system up, but just temporarily...a simple reset will restore the ROM. However, the changes you made to the RAM are still in effect! So if you switch back over to your corrupted ROM images you'll likely still run into problems. A more amusing thing to do besides having fun killing your system is to change the BASIC keywords. These are stored starting at location $D0D0. All but the last character of each command has their high bit off. The last character of the command has the high (8th) bit set. This is how Applesoft BASIC knows when it has reached the end of a command when its parsing a statement (more clever than using an end-of-command byte, such as $00, which would be a waste of a byte). So the END command (which starts at $D0D0) is stored as: *D0D0- 45 4E C4 E N D <-- 'D' = 44 + 80 = C4 You could change the END command to FIN by putting in: D0D0: 46 49 CE F I N <-- 'N' = 4E + 80 = CE Of course, renaming all the BASIC keywords is fun but rather pointless. A better thing to do would be to re-write BASIC altogether if you were so inclined, and perhaps add features to the monitor ROM (which occupies $F800-$FFF). But in order to do this, you had to strip out unneeded features of the ROM since the code was so compact to begin with there is absolutely no space left (a testament to the coding brilliance of the Woz!) Some people would remove the montior cassette routines (which were used to write/read blocks of raw memory to/from cassette) which were generally of limited usefulness after disk drives and replace them with routines to help them crack games. If you made your own ROM, you could simply save it as binary to disk, then every time you booted your system you could have your "HELLO" program BLOAD it back into the RAM and then switch to RAM. A customizable home computer! Of course, you could also burn your code into an EPROM and and replace Apple's ROMs, but the beauty of the Apple was that you didn't have to go through all this trouble...it was so damn easy to hack!!! Sam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------- Computer Historian, Programmer, Musician, Philosopher, Athlete, Writer, Jackass Coming Soon...Vintage Computer Festival 2.0 See http://www.siconic.com/vcf for details!