SoftBoot Documentation Last Updated 11/09/92 for SoftBoot 3.31 INTRODUCTION Well, you've just bought that 68040 card for your A3000 or just thought putting ROMs in your A3000 was a good idea. Commodore has begun to ship A3000s with 2.04 (or later) Roms built-in. You've lost your SuperKickstart feature, haven't you? This means that you can't run, in a recoverable fashon, new Beta versions of the A3000 AmigaDos Operating System or can't even run measley old 1.3. Until Now. Introducing 'SoftBoot', the new SuperKickstart Emulator for the A3000. Supporting the 68040 and the built-in 68030 CPU of the A3000, you can now run any version of the operating system (including 1.3!) in a completely reboot-survivable way. Many hundreds of hours and many hundreds of power cycles on my poor old A3000 have resulted in a near bullet-proof implementation. The process of reboot recovery is clean and unobtrusive to the new OS. There is no old OS aftertaste, so to speak. Cold|Cool|WarmCapture are not used. Program failure will result only if the ROM image, ExecBase structure, MMU tables, or reboot recovery routines are corrupted by an errant program. What do you need to run SoftBoot? Besides this very powerful program, you need SuperKickstart files. SoftBoot will load the devs:Kickstart file for 2.04+ versions of AmigaDos (including 3.0), or it can load the Devs:Kickstart1.3 file for AmigaDos 1.3. Note these must be the SuperKickstart versions with attached 'bonus' areas. Some interesting variations will be discussed later on. You must use OldFileSystem or FastFileSystem for your system paritions. I highly recommend creating a System2.0: partition and a System3.0: partition and using HDToolBox to enable the one you wish to boot from. If you create a unique filesystem partition, like MS_DOS or DCFileSystem partitions, PLEASE: MAKE SURE THAT THE FILESYSTEM IS LOADED INTO THE RIGID DISK BLOCK (RDB)!!!!! Failure to do so may render the data unreadable under 2.04 and who knows what damage may occur. Softboot is not responsible for any damage if that occurs. In general, this software is provided as-is and the user accepts all risks in using it. SoftBoot V3.31 and later There are a number of powerful operations possible with SoftBoot. Some which work on other machines besides the A3000. For example, the SOFTBOOT parameter performs a soft reset of any Amiga. If you try to use a feature of SoftBoot that your Amiga does not support, it will (usually) tell you. If you invoke SoftBoot with the '?' parameter, you will get the following text printed on your Shell: SoftBoot V3.31 [NOCACHEZ2][KILLROM][NOCATCHROM][ONETHREE] [BOTH][SOFTBOOT][NOBUSERRORS][FASTROM] [ENTTX][OVRMMU][NOCACHEZ3][Z3ALL] Each of the parameters will be discussed next: FASTROM The FASTROM parameter causes the current motherboard ROM to be copied into fast RAM and remapped with the MMU. While you can do this with a 68030 and the 'CPU' program, SoftBoot works with both 68030 and 68040 systems. It will even accomodate non-A3000 68020/68851 systems! The FASTROM setup will die on any hardware reset (Ctrl-LAmiga-RAmiga). KILLROM To kill any MMUed ROM setup and reboot the machine, use the KILLROM parameter. Note that it takes effect with no time delay. Make sure all files are closed and that there is time for the final write to occur before performing this command. KILLROM wipes out RAD:, too. SOFTBOOT The SOFTBOOT Parameter will work with any Amiga. It simply performs a system friendly reboot. It also takes effect immediately. The SOFTBOOT parameter is to be used primarily for forcing a MMUed OS to load a floppy disk-based game or program without going through the reboot recovery procedure. This guarantees that you will get the purest OS that money can buy! The same warning in KILLROM applies here: Make sure all files are closed and there is time for the final write to occur before executing the SOFTBOOT parameter. This routine simply calls the ColdReboot() function. Avoid making 3.0 EPROMS and running SoftBoot's FASTROM option. This option just temporarily allocates the memory for the ROM and MMU tables. If the MMU is on, then upon reboot, that same memory will be up for grabs and will likely be stomped on by some application program, corrupting the system. By the same token, it is OK to FASTROM a softloaded OS, although the reasoning for doing so is questionable. ColdReboot() is SetFunction()ed when a softloaded OS is made, so any foreign MMU environment will be converted back to the protected MMU environment prior to system reset. OVRMMU The default operation of SoftBoot is to check to see if the MMU is in use and print a warning message and quit if it is in use. Because 68040.library may build a MMU table, you may want to force SoftBoot to kill a foreign MMU setup. To do so, use the OVRMMU option. The SoftBoot options which do not result in a system reset are written as carefully as possible to build a new MMU setup and switch over without crashing the machine. Using the OVRMMU option, you can run multiple FASTROMs until you fragment/run out of memory. Note that with Softboot3.31, you can change Dev:kickstart files and load another MMU setup over a previously existing softloaded rom. The safer and more recommended way is to copy the kickstart file and issue a SoftBoot KILLROM command and have your startup-sequence SoftBoot command reload the new OS file. ONETHREE The most difficult mode to support: ONETHREE forces SoftBoot to load the Devs:Kickstart1.3 file instead of the 2.0 or 3.0 SuperKickstart. Certain things need to be known before using this parameter: 1) Reboot recovery is via ColdCapture() for this option only. Any program which obliterates ColdCapture() will cause the motherboard ROM OS to be reloaded on the next hardware reset. 2) All disk partitions will be visible; this means that 1.3 will probably try to boot from your 2.0 partition. I didn't want to monkey with your Rigid Disk Blocks, so you need to do one of two things: You can use HDToolBox to increase the Boot Priority of your 1.3 partition before running 1.3, or you can make a boot floppy which performs the assigns to your 1.3 partition and then jump to its startup-sequence. If you choose the former, you must hold down both mouse buttons when rebooting back to 2.0 so you can select the 2.0 partition to boot from. The 68040 doesn't like the Bonus code real well. Kickstart 1.3 will only load off a hard disk drive if it is the first partition on the drive and needs to be the highest SCSI address, with six being preferable. If you forget to change with HDTOOLBOX, a repeatable guru may be possible in 040 mode. Stick any bootable floppy into the drive to stop it. The drives are accessable, and softboot can be directly addressed from the CLI. However, it may just be easiest to boot from a 1.3 Workbench floppy disk. By the way, ZorroIII is not supported in 1.3. Other than that, it works just fine folks! Really! Remember the 68040 and 1.3 barely work together. The 68030 and 1.3 work pretty OK: Crashes are pretty frequent. Be forewarned and forearmed! All partitions must have the filesystem loaded in the rigid disk block! The stability of other than OFS and FFS partitions cannot be guranteed under OS 1.3! Personally, I only would use 1.3 for floppies and try not to use the hard disk at all. However, I have a lot of CDTV discs which only play under 1.3, so I will occationally use a special partition I've set up. AmigaDos 2.0 AND ON Actually invoking SoftBoot with no parameters or any of the remaining ones not yet discussed will load the Devs:Kickstart file for an alternate operating system. The following describes what these parameters are and how, why and when to use them: BOTH One of the really interesting features of SoftBoot is that it works with both the 68030 and 68040 processors. If you invoke the BOTH parameter, MMU tables will be built to support both the 68040 and the 68030. There really isn't much of an overhead as the 030 MMU tables require only 32K bytes of additional RAM. The 68040 can be a bit better or quite a bit worse. The 68040 MMU tables require 9K for the basic A3000 motherboard. That's not too bad! However, if you have a Zorro III card, SoftBoot must build additional MMU tables to the tune of 66K bytes per 256 megabyte segment. This memory is all dynamically allocated as required. The great thing about the BOTH parameter is when you have a 68040 card that can be switched back and forth to/from the 68030: If your switch program works, you can stay in the same RAM-based OS without having to go through the motherboard ROM! (OK for just a few milliseconds! Truth in advertising, you know!). If you don't invoke the BOTH parameter, then MMU tables will be built for whichever CPU is currently in operation. The question naturally arises: What if I switch CPUs? Heaven forbid, disaster surely won't come will it? No. The RAM formerly used for the ROM and MMU tables are always allocated. You will see a 532K (approx) loss of ram, but will be running on the motherboard ROM. Switch back to the other CPU and the Ram-based OS will again take effect! Neat Huh! If you want all your RAM back, use the SoftBoot KILLROM option. You will lose everything in both modes then. So, in conclusion, You can have one CPU running a RAM-based OS, the other, or both running RAM-based. Or be a spoil sport and run neither. Note that with the Workbench V39.26 and later (Commodore's) 68040.library, Progressive Peripherals 68040s will become unable to switch modes. You can fix this by running a 'SoftBoot FASTROM OVRMMU'. SoftBoot's default setup will then allow the PPS Switch program to work. Since you are rebooting to change processors, the loss of 600K for the FASTROM will be temporary. ENTTX The MMU tables that 68040.library builds all assume ZorroIII I/O cards are present. One of the things it does is turn the transparent translation registers off. Theoretically there is a performance hit, as it only takes one clock cycle to pass through the transparent translation registers and three memory cycles to obtain a translation if the MMU page translation is not stored in the 68040 address translation cache. At first glance, there should be a major performance hit. Apparently Motorola did a wonderful job in the ATC design as it stays there over 90 percent of the time, minimizing the perfomance loss to about 2 percent. If you do not have Zorro III I/O, using the ENTTX option turns on the transparent translation registers, giving back some speed. The down side is that this may affect how reads/writes to non-existant memory areas are handled in the A3000. 68040.library's MMU tables will catch all accesses to non-existant RAM without going through the jerky 350 msec hardware bus timeout. You will lose this, in some memory areas, without using the NOBUSERRORS option, discussed elsewhere. NOCACHEZ2 If a Bridgeboard is detected, the ZorroII space will be automatically declared non-cacheable. Otherwise, it is fully data and instruction cacheable (No parameter required!). If you have any other I/O device that winds up in the area reserved for Zorro II RAM (0x00200000-0x009fffff), then you need the NOCACHEZ2 option. Note this also works for the 68040/1.3 mode. The 68030/1.3 MMU setup is defined in the 'Bonus' section of the Devs:Kickstart1.3 file and is not alterable. NOCACHEZ3 The default behavior of SoftBoot is to cache all Zorro III space. If you have a ZorroIII I/O card, you may need to use the NOCACHEZ3 option. This option causes both the MMU tables and the transparent translation registers to be be declared as non-cachable. Note that this parameter has an affect when creating a softloaded operating system and also when the ENTTX option is invoked. In the latter case, the data transparent translation regisers are declared serialized noncachable. If you are running the newer 68040.library, it will make the proper I/O sections non-cachable, and leave Zorro III RAM at nearly full speed. Z3ALL There has been some talk about possible changes in the location of ZorroIII autoconfiguration addresses to suit the 68040's tranparent translation registers. When you run SoftBoot, it assumes the memory map is going to remain the same from one OS to the next. There is no way to figure out where the next OS might place a Zorro III board until it has gone through the autoconfiguration process, in which case it is too late for SoftBoot to build MMU tables. The only solution is to use the Z3ALL parameter until you can get new ROMS/EPROMS in your A3000 which reflect the new memory mapping. The Z3ALL parameter builds MMU tables for ALL of Zorro III space. This is very expensive and requires over a megabyte of additional RAM. This is the only way to make ZorroIII work if the memory map does change. That way, there will be valid MMU tables no matter where the OS decides to put a board. Note that the Z3ALL parameter is a NOP if there isn't a Zorro III card in your machine. NOBUSERRORS When I first got my 040, I was disgusted at the number of applications which die with an 80000004 or 80000003 Guru. Through some careful sleuthing, I discovered that these were caused by the A3000 Bus Error control hardware. I also discovered that the 040 was very difficult to recover from a bus error as an RTE command just reruns the cycle. Not good unless you remap RAM to all of the memory space (68040.library does something just like that). Even better is that all 2.0 Kickstarts to date assume an 030 Stack frame in the Bus Error exception handler. Apparently the 030 can fiddle with the stack and 'fake' the access. With an 040, this 'Twiddling' causes the aforementioned Gurus. At least it winds up in a mode that brings up a requester from which you can terminate the task or reboot. The motherboard Bus Error generation hardware responds whenever an access is made to an address in the machine which doesn't physically exist. This will happen on a read or a write. Yucch! Since the ROM just ignores the cycle for the 68030, why even activate the bus error hardware? Even worse, the hardware bus cycle takes 350 milliseconds to generate. That is why you get those funky and jerky mouse pointers when accesses to non-existant memory occurs. Fortunately, there is a solution. Turn off the Bus Error generation hardware. The NOBUSERROR parameter will perform this magic for you, enabling all those programs which run on 68040s on the A2000 and don't on the stock- programmed A3000 motherboard to have a chance at working. No guarantees! Any program which accesses RAM outside of its own space is broke. Many programs do not hurt as they only _READ_ these locations. As far as writes goes, well there isn't RAM there anyway. But it is indicative of a sick program. As a result, the default behavior is to let bus errors crash a task. Use of the NOBUSERROR parameter is at your own risk. Note that the NOBUSERROR parameter is a NOP when the 68030 or 1.3 is in use. NOCATCHROM The NOCATCHROM parameter enables a custom error trapping handler to be installed in the Bus Error exception vector. This handler only catches and corrects writes to ROM space or areas declared invalid in the MMU tables. A real genuine BUS error or any other type of exception which generates a 68040 access error besides an invalid access or an illegal write will be forwarded to the ROM Guru-handler. This is the default operation of SoftBoot. If the NOCATCHROM parameter is involked, SoftBoot is prevented from patching the vector. Again, this command is a NOP under 1.3 or the 68030 processor. TRICKS AND TIPS 1) Now that you've fallen in love with some future OS, and are very tired at having to open a CLI/Shell and run SoftBoot manually - have I got a trick for you! If you put SoftBoot in the Startup-Sequence, just ahead of SetPatch, you will get a power-on SuperKickstart-like effect. The Workbench screen does not normally open until IPrefs is run. The screen stays white (3.0+ is black). When SoftBoot is loaded via the Startup-Sequence, it will load your favorite version of the OS and reboot. You will see a second dark grey/light grey/white sequence, but you will not see the Workbench screen until you are softloaded. The second time through, SoftBoot will detect the MMU is in operation and abort with no operation, allowing the startup-sequence to continue! The following is the suggested use for AmigaDos 2.0 and 3.0: SoftBoot > nil: [OPTIONS] SetPatch > nil: SoftBoot > nil: ENTTX [OPTIONS] Note: BOTH is a recommended option if you can switch CPUs and want to always stay in the same OS. The second SoftBoot command (ENTTX) is to reenable the transparent translation registers. This is optional. The only parameter for SoftBoot ENTTX is NOCACHEZ3. Note: When installing a new Workbench via the Installer, do not let it automatically reboot the machine when it is finished. Exit and edit the new s:startup-sequence to reflect the SoftBoot command lines. If there is a new kickstart file, copy it to devs:. Then reboot the machine into the new OS via the SoftBoot KILLROM parameter. HOW TO MAKE A 1.3 OR 2.0 OR LATER KICKSTART As a developer, you can obtain a new superkickstart image from CBM or via closed listing sections on BIX. UnLharc the file and copy it to the devs: directory to a file called Kickstart. If you have a SuperKickstart Disk, on your 2.0 A3000 install disk is a script file called Update2.0x. This script will create an A3000 kickstart from your Superkickstart disk as Devs:Kickstart. For 1.3, you need the A3000 1.3 SuperKickstart Disk and use the following command from the tools directory of the A3000 1.3 Install disk: Makefiles df0: 1.3 devs:Kickstart1.3 Note that you need to have the 2.0 (or later) fastfilesystem installed on all your hard drive partitions when you use 1.3 via the ONETHREE option. Use HDToolBox to load the proper fastfilesystem from the l: directory of your 2.04 A3000 Install disk (or wherever it may reside on future releases). VISUAL DIFFERENCES Whenever you reboot with the Vulcan Neck Pinch (Ctrl-LAmiga-RAmiga), you will see a slight difference in screen behavior compared to what you are accustomed. You will see two cycles through the black to white screen transitions (V37 only. V39 keeps the screen black, so the second trip through the ROM is not as obvious). The MMU is turned off on a hardware reset. The first set of color changes is the motherboard ROM taking over. SoftBoot magic then restores the MMU and jumps to the RAM-based ROM image, causing the second trip through the monochrome spectrum. You will get used to it and will use it to know when you are RAM-based versus motherboard-based. DOWNERS You must obey the following rules concerning RAD: 1) Never, repeat Never ever mount RAD: and then try to SoftBoot. Softboot first, then mount RAD: (Note the way the DOSDRIVERS drawer is accessed in Kickstart 3.0 really helps you run SoftBoot before mounting RAD). Use the KILLROM option to remove RAD: before SoftBooting. RAD: works from the top of memory down. SoftBoot also wants to put the ROM at the top of memory. As you might guess, neither wins when SoftBoot is executed! 2) Always use the BOTH option if you are going to use both CPUs and expect RAD: to recover. RAD: seems to work much better then because memory allocation is similar between CPU states. If you don't use the BOTH option, RAD: will lock up the machine up when switching CPUs. It will recover until you make the switch, however. Usually it will either hang at the white (Black for V39) screen or continously cycle through the shades of grey. You will have to power down to recover. I tried hard to make this program work on the A2500/030/020. The major problem was that the Reset command caused the loss of all chip and fastram and the program would lock up. As a result, this version of SoftBoot is very A3000 specific. I will be coming out with special versions to support particular A2000/040 combinations. Also CBM does not generally make newer beta versions of the A2000 operating system available linked at F80000, but rather at 200000. The ONETHREE option and the Devs:Kickstart1.3 file are specific to the A3000 and a stock 1.3 kickstart image must not be used in its place. It must be understood that you have replaced your Alpha superkickstart ROMs with some later version, probably V2.04. Softboot requires V2.04 or later ROMS in your machine. My A3000 is running custom-made Eproms of a much later verison. I suspect that 3.0 ROMs will not give SoftBoot any problems. VUNERABILITIES Softboot can be killed in one of several ways. They all require an errant program to write over a sensitive area of memory. First, the ROM image itself can be corrupted if the transparent translation register is enabled. Second, the MMU tables cannot be protected. Third, the Romtag used for reboot recovery may get written over. And finally, the ExecBase structure could be corrupted. To help protect the tables (and ROM in 68040 mode), I allocate an extra 256 bytes around each item, to help prevent the OS (MemList tails) and broken programs from overwriting critical data. The ROM is write protected at the logical address but is vunerable if the transparent translation registers are enabled as the physical address would not be protected; the MMU tables are ignored in areas where the transparent translation registers are active. SoftBoot has been made as safe as it can be. ENFORCER Please use the new Enforcer, V37.26 or later. It is foreign MMU tolerent. When it exits, it will return to the previous SoftBoot MMU setup. HISTORY Current Version is 3.31 3.31 - All memory allocations are now checked to see that they are on the motherboard RAM. Should any MMU table not be allocated in the proper area, the program will print an appropriate message and exit after returning all resources back to the old OS with no damage to the old OS. Reordering of functions allowed the used of _LVOSumKickData() again. The in-line code was removed. 3.30 - The MMU table fill routine was pulled out of main() and made into two separate routines: one for 1.3 and one for 2.0+. This allows me to change the code so I can delay the final Disable() until just before the new OS is launched. Caches are turned off early in the program. This required additional flushing at several points to prevent hanging. Supervisor() was SetFunction()ed to guarantee it would be available after the old ROM was corrupted; SumKickData was in-lined. Now Softboot cannot hang because the new OS has different LVOs than the last one or depend on certain instructions & data to be in the cache. The net result is that you can reload any OS on top of another without worrying about corruption, or the need to make a special boot disk for ONETHREE, for example. You can go directly from 3.0 to 1.3 now no matter what the status of the MMU or memory allocation situation. 3.27 - It was realized that older SoftBoots can now crash because the OVRMMU option allows one rom image to be written over the same memory area. Previous version worked (sometimes) because LVOs didn't change or the instruction cache contained the old rom code, while the data cache had (from the copy of) the new ROM image. The first cut at minimizing the problems with this was made, in particular, getting the ONETHREE option to work with a MMUED OS. It didn't. And led to experimental versions 3.28 & 3.29. 3.26 - Romtag assembled under SAS/C asm V6.00 (Previously used A68K PD assembler). Compiler made to use near data and code except for assembly functions and data. Romtags Headers made invalid if SoftBoot will not be loading a new OS and rebooting. Executable 800 bytes smaller than 3.22. 3.25 - Same as 3.25 but C code compiled under SAS/C 6.00, previously used SAS/C 5.10b. 3.22 - Another bug found in Zorro III when tested with Progressive ProRAM64: Index to 3rd level MMU tables incorrectly generated. Larger of 64K*SlotSize or BoardSize is now used to determine span of board. System Memory lists also scanned. Should run better on A4000. 3.21 - Tested on A4000, was intermittant, but OK if run from bootup. 3.20 - New Z3ALL option added, NOCACHEZ3 option made effective in MMU tables and ENTTX mode. Program code for SOFTBOOT parameter removed and ColdReboot() used instead. 4K page mode removed. 68040 ROM patch search area increased from first 20K to first 50K of ROM. ROM checksum patch search area increased to first 10K of ROM. ColdReboot() setfunctioned to restore protected MMU setup before system reset to prevent an unprotected ROM from getting allocated and corrupted, hanging the machine. ColdReboot() disables and dumps all caches (data, instruction, ATC) prior to reset. 3.14 - Version which had an option to make 4K or 8K page MMU Tables; Added the ENTTX option; New ZorroIII MMU table generation algorithm; OVRMMU option added. 4K mode known unstable in Softloaded OS, but stable in FASTROM. 3.0 - Changed patch to Exec to make all 68040 MMU opcode nops rather than looking for a specific code sequence and branching around it. This will not break again unless the patches are moved away from the beginning of the ROM. 2.50 - Final Cleanup for Beta release to developer community for ADOS 2.0. It worked until exec changed in 3.0.