Some kind souls have created patches which allow one to run the superDebugger under GEOS128, most recently JeanFMajor. The problem is that the SuperDebugger on the 128 trashes the RAM Reboot code in Bank 0 of the REU. This has posed somewhat of a problem, for if one is debugging an application that has an insidious bug which spectacularily crashes the system, one would have to go through the pain of reloading GEOS128 from disk, and then recopying all of one's files to the RAMdisk.
This procedure is intended to correct this problem. Note that the procedure described here is rather "patchesque." That is, it requires you to know a little bit about your REU, and issue some commands in the 128 Monitor. This should not be a problem for anyone who is using the SuperDebugger. The rebooting will not be as smooth as issuing the "rboot" command as you can do with the SuperDebuder under GEOS64, but it sure beats reloading GEOS from disk!
@Setting Up
To use this procedure, you will need two files, both of which should have been in the archive with this documentation file: RbootMove and DB128RBOOT. The first is a GEOS application, the second is a short 128 machine language program (not designed to be run under GEOS128). RbootMove will need to be converted to a GEOS file with Convert2.5, but the other will not.
The procedure works by moving the necessary code for a RAM Rboot from bank 0 of your REU to another bank which is not used by anything else in the system. You will have to figure out which bank in your REU is safe for the Rboot code. The values in the memory locations starting at $88c7 (ramBase) may prove helpful (see the Hitchhiker's Guide, or the file 128memorymap). For example, on my system I move the Rboot code to bank 22/$16. I run with a RAM1581 on m:y 1.5 Meg REU, with GeoWizard installed in Bank 23 of the REU.
Once you have decided to which bank in your REU you will move the Rboot code, you need to tell both RbootMove and DB128RBOOT about it:
@RbootMove:
For this file, I borrow the Jim Collette's technique of using the info field in the file header as input to the program (thank you, Jim). Select RbootMove's icon, and then select "info" from the file menu. On the first line of the information box, specify your REU bank as a two digit hex number preceeded by a $. The $ must be present, and the number must be the first thing in the info box. Use lowercase letters for hexidecimal digits a-f (i.e. $0f rather than $0F, for example).
@DB128RBOOT:
The easiest way to do this is with the 128's Monitor. Boot up into 128 Basic, and issue the "monitor" command. Once in the monitor, issue the following commands:
@l "db128rboot" 8 1c000
@>1c05f
<bank> ;(substitute with the hex bank number where you will move the reboot code)
@>1c012 f0
;(this actually shouldn't be necessary, but it can't hurt to be safe)
@@8 s0:db128rboot
@s "db128rboot" 8 1c000 1c080
These complete, you should be all set.
PERFORMING THE RBOOT:
In order to successfully rboot after using the Debugger, you must perform the following steps:
@1. Run RbootMove
This must be performed sometime after you boot up GEOS (of course) but before the first time you run the SuperDebugger. The program will put up a dialog box either informing you to which bank the Rboot code was moved, or informing you that there was an error of some sort.
@Note:
Do not rename this file. If you do, it will not be able to find itself on the disk. GEOS is from Berkeley Softworks. In Berkeley, it is important that one be able to find oneself. Besides, if it can't find itself, it won't be able to read the destination REU bank from the info field of its header.
. What does this do? In RAM block 1, $fff8 is the system reset vector, through which the 128 jumps when you do a reset. GEOS redirects this to its own reset routine. Now, not only does the debugger trash the reboot code in REU bank 0, and not only it sometimes unpredictably trash the resident reboot code, but it has this disturbing tendency to trash the GEOS reset routine. In fact, I wouldn't trust the SuperDebugger with my laundry. $e224 is the 128's default reset vector; by restoring it to this, you insure that after reset you will be dumped into BASIC, and able to complete your RAM reboot.
@Important:
When you enter the debugger, your disk drives should be set up in the same manner as they were when you booted up the system (and when you ran RbootMove). Otherwise, your reboot will likely not complete successfully.
@3. Do whatever you like in the debugger
Crash the system, if you wish.
@4. Push the 128's RESET button
Do this if you wish to reboot. If you don't think you need to reboot, the "exit" command still works just fine.
@Important:
When you press the reset button, there should NOT be a bootable disk in drive 8. Otherwise, the 128 will merrily boot whatever is on this disk, and your chances of a successful RAM rboot dimish greatly.
@5. Load DB128RBOOT
Issue the commad
@l "db128rboot" 8 1c000
from within the 128's monitor. Note that you can feel free to rename this file. "2" might be a good name, for ease of typing. Also, you need not load this from drive 8; remember, however, that the monitor expects all numbers in hexidecimal, so if you are loading from drive 10, the command would be
@l "db128rboot" a 1c000
@6. Do the reboot!
The monitor command
@g 1c000
will perform a reboot. You should be quickly put back into GEOS128, with your RAM disk intact.
Six steps... sounds like a lot. Really, though it isn't as complicated as it looks. Granted, it isn't elegant, but to my best tests, it works. Any problems? Let me know:
(.txt)