Many years ago I read a great article in Computist Magazine about modifying the Apple ][+ ROM code to allow halting the computer at any point in time for debugging/cracking purposes, something I had always wanted to do as a teenager. The older Apple IIs had monitor ROMs that effectively allowed you to break into the monitor at any point in time, giving you the familiar monitor asterisk prompt. Later Apple II’s that followed, however, used different ROMs that removed this feature. Even having the ability to break into the monitor didn’t always give the user full access to the loaded code. Clever programmers would put parts of their program in the screen memory locations so breaking into the monitor prompt would then wipe key portions of the code.
The author of the Computist article had a very clever solution to solve this problem. He showed how to dump the Apple ][+ ROM code to volatile memory, reprogram key parts of the ROM code to allow halting the system at any point in time, then burn new ROMs for the Apple. He even added a clever way to move key portions of memory to high memory locations before displaying the monitor prompt in order to avoid wiping out portions of the code. With these modified ROMs you were ready to rock and roll in the cracking world.
In 2007, I came across this article again and it got me thinking that this modified EPROM code would be pretty cool to have for my recently restored Enhanced Apple //e, and it would also be really cool to run the code on an Apple II emulator. Most Apple emulators just read in the original ROM code from a binary file anyway. The only problem was that the original Computist article was written for the ][+. I have a 128k Enhanced //e and thus, this project began.
The details of the hack are below. Or if you know what you’re doing, you can go straight to the binaries here.
I recommend you read the original Computist article first. It gives great background on the hack. What we are doing is modifying the reset vectors so that anytime the user boots or presses Reset, the two reset vectors first jump to our code to allow us to decide what we want to do. Depending on the keyboard input, we either continue to reset normally, jump to the monitor, or do some strategic memory copying before jumping to the monitor.
Unlike the Apple ][+, the Apple //e uses different ROM code and two ROM chips instead of one, the CD and the EF chips. The original article modifies the cassette tape “Load” area ($FEFD) with its code. Unfortunately, the //e ROMs don’t have enough free space in that area. In fact, I couldn’t find any contiguous area of non-banked memory that I could use for the entire program so I divided the code into three parts. The bulk of the ROM modification has been relocated to banked memory in the Apple self-test area ($C600) and doesn’t trounce critical code.
Part 1 (resides at $FEFD) – Tape load area:
Handles the reset vector, bank switches, and jumps to main code at INTCX $C600
Part 2 (resides at $C600 – INTCX) – Self-test area (not normally used):
Checks keyboard input and then either jumps back to Part 1 for a normal pass-through Reset or jumps to Part 3 for a monitor exit
Part 3 (resides at $FECD) – Tape save area:
un-bank switches back to SLOTCX memory and jumps to Monitor for some fun!
Note: You lose the ability to run the Apple self-test and any cassette tape functions using this ROM modification.
– The assembly code was written and compiled with S-C MASM 1.1 which is free. The .asm source file is included on romkrk.dsk image, and a .pdf file of the source is also included here for easier viewing.
– If you’re wanting to compile the modifications and manually edit original Apple ROM files yourself (not included), you’ll need to take the machine code generated by S-C MASM and manually apply it to original ROM files. The ROM files included here have already been modified with the changes.
– The one drawback to this modified ROM is that towards the end of the Apple II era, certain games began running checksums on the ROM contents in order to combat people using ROM modifications like this. If the ROM was not a perfect match to factory versions, the program would not run. The solution to this problem is to double the size of the onboard EEPROMs and attach a switch that allows you to switch between the factory default ROM code and your modified cracking ROM code. This led me to my next project: Reverse Engineering and building the Senior Prom debug card.
Using the ROM with an Apple //e Emulator
Point the Apple emulator to use the APPLE2EKRK_V4.ROM file, reboot and follow the instructions in the How To Use section below.
Burning a set of real Apple //e ROMs
You need two 2764 EEPROMs. Label one CD and the other EF. After UV-erasing the EEPROMs, burn them with the contents of these two bin files:
Apple IIe CD Enhanced KRK – 342-0304-A – 2764.bin
Apple IIe EF Enhanced KRK – 342-0303-A – 2764.bin
Then swap out your old ROMS and boot up.
Note: the system will appear to hang at startup. It’s waiting for a key press.
How To Use
Anytime you press Reset, Ctrl-Reset or boot the system, the computer will appear to freeze. At this point, we can do one of the following:
Press ESC – Go directly to the monitor
Press Space – Copy stack and register values to $2901-$2904, copy memory from $0000-$08FF up into $2000-$28FF and then enter monitor (this is done to preserve the registers and other code that might be overwritten when we enter the monitor)
Any other key – proceed normally
You will probably want to press any key at boot time to get where you are going. You will know the ROM is working if you see “Apple //k” at boot
Files are located here and they include:
A ROM binary in the right format for an emulator: APPLE2EKRK_V4.ROM
BIN files for real EEPROMs
Source code for the EEPROM changes in PDF format
Source code for the changes compilable with S-C MASM 1.1 on romkrk.dsk
For anyone who still enjoys tinkering with their old Apple ][, I hope this helps make your hobby more enjoyable.