iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (01/01/89)
[In "Re: SDB and tracing through the ROMs", Bob Page said:] : : mcp@ziebmef.UUCP (Colin Plumb) wrote: : >What I'd really like to do is put breakpoints in the ROMs and work through : : Here's something Kim posted around September 86. Might be useful. : : vvvvvvvvvvvvvvvvvvvvvvvvvv from Steve Schoettler vvvvvvvvvvvvvvvvvvvvvvvvvvvvv : : Making Kickstart RAM writable. : : There are three methods you could use to disable the write protect: : : [...] : : (2) Replace the PAL with one that had a different equation for the : WPRO*. This has the glamor of not needing any solder. : The equation could be set up to never write protect the RAM, : but that's probably not such a good idea. : : : If you like the PAL method (2), you're on your own for now. I have : figured out how to make the new PAL, but I can't post the equations : : [...] : Steve Schoettler : : Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page : Have five nice days. : The Kickstart Eliminator follows method (2). On a machine in which this modification is installed, if you boot from the Kickstart disk instead of the ROMs, the WCS is write-enabled and you can set breakpoints. -- --Bill Kinnersley Physics Department Montana State University Bozeman, MT 59717 INTERNET: iphwk@terra.oscs.montana.edu BITNET: IPHWK@MTSUNIX1
BRENNER_%DULRUU51.BITNET@cunyvm.cuny.edu (01/02/89)
In article <5599@cbmvax.UUCP> George Robbins <grr@cbmvax.uucp> writes: >There is no magic flag. What you must do to reenable writing to the >control store is issue a 68000 reset instruction, then get things started >up again. This is, in general, non-trivial task, though I suspose for a >stand-alone game it isn't that hard. >The "memory overlay bit" or "OVR" bit simply controls whether ROM or >"chip" memory is mapped at location 0. This is neccessary so that the >processor can find it's way to the normal "ROM" area. >It is of course fairly simple to modify the RAM/ROM tower board to >disable the ROM write protect feature... Not long ago a discussion around this topic was going on in the Bitnet List Info-Amiga. Excerpts follow... ----------------------- Olaf 'Rhialto' Seibert <U211344@HNYKUN11> writes: >Recently I got the 1.3 Kickstart disk. As usual, I tested it to see if >it works (and of course, it does!), so then came the time to make a >backup copy for daily use. Of course, I also have a daily- use-backup >disk of Kickstart 1.2 (and 1.1 for that matter). And I have a Kickstart that uses internal memory from 80000 to 100000, an Anti-Virus-Kickstart and one that has the Pal-Bug fixed and a cleaner font in it. Lucky to be an A1000 owner. >Unfortunately, you need a _whole_ disk of 880K to store that 256.5K >worth of data... just a bit wasteful, I think. I did not want to tie up >an entire extra disk for that. So do i. >... >Suppose you wrote a simple program that you place at the beginning of >the Kickstart disk, so that it would be loaded and run. Then it would >somehow determine what kickstart you really wanted to use, and load >that in. Of course, there should be some default in case you dont >select anything. >... >Would it, despite some problems like the one mentioned above, be >possible to make such a Kickstart selector? It would be a pretty neat >trick! Darn, if I lived in Germany I would do it myself :-) :-) :-) Thought about that for a long time. The simple solution you mentioned is impossible. Things run the following way when the Amiga 1000 is switched on or rebooted: (simplified) The memory configuration is a bit different from what it is normally (after exec and all devices are up and running). Kickstart memory is at location $fc0000 but WRITEABLE. And there is the Bootrom at address $f80000. Normally there is a mirror image of Kickstart there. When the Amiga is rebooted, execution starts at location $f80000. The Boot Rom checks if the Kickstart checksum is all right. If it is, the Kickstart memory gets write protected and, simultanously, its mirror image is placed at $f80000. If the checksum is wrong (either because Kickstart is not yet in memory or because some ugly bug in a program caused a write in the Kickstart memory (ChangeKick does the trick)) the bootrom loads the tracks 0 to 22 from the internal drive into kickstart memory. Then it write protects Kickstart and jumps into Kickstart. Now my suggestions: First possibility: Modify Kickstart so when it is entered a selector menu appears to choose from various Kickstarts on disk. Then do a RESET instruction (this write enables Kickstart but at the same time disables the chip RAM (this is because the processor should find the reset address at location $000000 - there is a mirror image of the Bootrom at $000000) Enable the RAM and copy the loader program into RAM. Jump there and load the selected Kickstart into the Kickstart RAM. Then protect the Kickstart RAM and jump there. This method would require to load the default Kickstart each time you switch on your computer. And it would require that each kickstart is patched with the selector program. Second possibility: Modify the Boot Rom. This is contained in two Roms with 32KByte each. But only 8KByte are really used! So write your own Boot Rom that includes a selector program and burn two 27256 eproms and place those in the rom sockets. I did that once to disable the write protect of Kickstart. -Martin ----------------------- I have found an easier way to look at the BootROM. There is a RESET instruction in Kickstart at location $FC00D0 (if my merory is right). When you jump there, a warm reset is performed, but the write to the BootROM is never done, of course. The only problem: This code should be performed in Supervisor mode (RESET is a privileged instruction). The easiest way when you are in a monitor/debugger: edit location $80 and enter the address (hope $FC00D0 is right). Then perform a TRAP #0 and after booting the workbench Kickstart RAM will be write enabled and the BootROM readable. -Martin @ @ ---------------------------------------------------------------------- ===V=== "Do Arcade Machines Dream of Multitasking?" // !^! -Martin (BRENNER_M@DULRUU51.BITNET) Uni Ulm/F.R.Germany \X/AMIGA ^ ^ ---------------------------------------------------------------------- %SYSTEM-W-POWERFAIL, power failure occurred