U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (12/18/88)
Responding to some of the suggestions I read on I-AMIGA about my idea to write programs in Kickstart memory. Martin (BRENNER_M@DULRUU51) explained something about the boot process: > 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 Actually, there must be a copy at 0 also, so that the initial PC and SR can be loaded. The first 2 longwords in the boot rom are $1111 4ef9 (PS) and $00f8 008a (PC), so the execution starts at $f8008a. There is also a bit of extra code that jumps to that addres. Note the similarity with the way the beginning of KickStart works... (The Kickstart itself even checks the address it is running at). > 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: [...] > 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. I am strictly a software person. If anything can be done in software, transparently to other system functions, then I prefer the software method. > PS: Why do you want to live in Germany? That was just a nasty remark intended for the programmers in Germany who don't follow all rules... (more about rules below) Then MARKV@UKANVAX told me how to read the left mouse button, which is real easy. That is why I mentioned it, though I would prefer to check a SHIFT or ALT key, though that involves setting up the keyboard, interrupts, etcetera. Tom Limoncelli replied to Markv: [> is Tom, >> is Markv] > >For the person interested in reading the left mouse button directly (ie: w/o > >input.device or Intuition or gameport.device), here goes: > > [ much deleted ] > >The /FIRE pin of each gameport (and hence the left mouse button) are directly > >connected to CIA-A, port A, bit 6 for port 0, bit 7 for port one. This > >port's address is $BFE001. It is also in cia.i or cia.h. Finally, this > >address is correct on thee Amiga 500,1000, and 2000. But like all hardware > >registers COULD change. So the correct way would be to OpenResource the > ^^^^^ > Wrong! They WILL CHANGE. Do you think that the next generation of > Amigas is going to keep every little thing the same? If you do this at > all, use the OpenResouce() call. Also, document this in your manual so > that future users of the program will understand when it breaks on an > Amiga x000. Yes I know they WILL CHANGE. But anyhow, my program will only run on an Amiga 1000 anyhow, since all other models are not likely to introduce Kickstart disks again. (But I would like new Amigas to have Kickstart on disk). > >misc.resource and get the base address of the CIA's. CIA-A port A is one byt > >up from this address. Oops, 0 bytes, the base Address of CIA-A is BFE001. > > > >Okay, the following program will simply go into a busy wait loop until the > >mouse button is depressed > > [ code deleted ] > > >MARKV@UKANVAX > > Going straight to the hardware is really the worst thing that anyone can > do. There are some very simple ways of finding if the LMB is pressed. If > you have a port to Intuition open you can get it by setting a flag. > > Worst of all, your example is a busy wait. That *kills* multitasking. > > I'm sorry. I'm not the biggest Amiga programming expert but there is so > much yelling and screaming on comp.sys.amiga right now about why not to go > straight to the hardware I would avoid it. Luckily, AmigaDOS does provide > OpenResouce() so you can find the address of the chip, even if it does > move. Just like above, when my program runs there IS NO cia.resource, Intuition ports, or multitasking. Busy waiting on hard hardware registers is the only way to go. BUT ONLY IN A PROGRAM LIKE THIS WHEN THERE IS ABSOLUTELY NO OTHER POSSIBILITY !! > Enough flaming. Happy Holliday's everyone! > > -Tom I agree on that one! To justify this posting, I want to add some new information myself. Somebody provided me with a disassembled listing of the A1000 boot rom. I haven't studied it extensively, but the following questions by MARKV can be answered: > **Here is my question: Does the BootROM load Kickstart itself, or does the > BootROM load the code in the Bootblocks which in turn loads kickstart? In > otherwords, if you want to do something flakey this early, do you have to > change Kickstart itself, or just the Bootblock? The bootrom does the entire KickStart into WOM (Write Once Memory). Then it jumps to the address at $fc0004 (just like the bootroms are started by jumping to the address at $f80004 which at that time is also $0004, which is the initaial PC value). > Okay, Kickstart is loaded at FC0000. Now is a critical point. Up to this > point the BootROM has been around. Now Kickstart does a write somewhere > between F80000 and FBFFFF. This makes the Boot ROM go away forever, there > is no way to get it back, short of another cold boot. Then it does a write > WAIT, I goofed. The BootROM is always present at F80000 immediately following > a RESET (this can be caused by a 68000 RESET instruction). When you do > a write between F80000 and FBFFFF the Boot ROM goes away, and the WCS becomes > write protected. But now Kickstart is present. Now a WARM boot happens, The write that maps out the Bootrom at $f80000 is done from the stack, (as described above), and the write that maps it out from address 0 is done much earlier, in the bootrom itself, by writing the OVLY bit in CIA-A. Though you can get the bootrom back at $f80000 by issuing a RESET instruction, this also auto-un-configures all your expansion memory. Too bad... no memory to make a copy into... (I presume). I don't know if a RESET instruction also resets the CIA so that the memory overlay bit gets set again (so that the Boot rom also appears at 0). There is a software method, however, to examine your A1000 boot rom. Simplified, do the following steps: - Create a program on a Kickstart disk that does a RESET (to get the ROM back), configures your expansion memory, or other safe memory area. Then copy the boot rom to that memory area. - Next, boot with a normal kickstart, and the expansion mem disabled, and run a second program, that configures the memory and writes the collected boot rom to a file. Maybe it can be done simpler. Maybe I will try some things. > Well, that is what I know. Now some questions? Is the Workbench Disk Image > stored as a bitmap or the code to draw it? Is it taking up space in the > Kickstart, or is this on the BootROM and kept around long enough to use? The Kickstart hand is in the boot rom, the Workbench hand is on the Kickstart disk. There are lots of people who don't have a hand anymore, but patched it into something else. The drawing is table driven; it was explained in a usenet(?) article long ago. I don't think I still have that article. > When a warm boot is done, when exactly is the Kickstart checksum checked? The Kickstart checksum is checked very early in the boot rom. If the checksum is OK, it is run. (So it also works with real KS ROMS). If not, it is loaded, but the checksum is NOT rechecked. > When a warm boot is done what exactly determines whether the Boot ROM or > Kickstart appear at F80000 (and initially 00)? How does the BootROM read > the disk? Does it contain another copy of trackdisk.device, or does it > brute force things directly from the registers? The Bootrom ALWAYS gets mapped at 0. Maybe in a 500 or 2000, the KS itself is mapped at 0, and since the start address to be run is at the correct location, that would work also. It seems there is (something like) a copy of the trackdisk.device in the boot roms. And it even looks like it was written in C... > Okay, enough on that, > > Mark Gooderum I hope to find out even more about this fascinating subject... Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)-> Olaf.Seibert; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q: How many lines does it take to screw in a disclaimer? A: Only two. --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet --- Study safely - stop deets 7167 BYTES FREE Too painful to do right *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*