olivier@hpgnd.HP.COM (Olivier BORDES) (01/19/90)
Many users of Amiga's (500 and 2000) with the 1.3 ROM complain about the fact that their machine will not reboot from RAD: even though RAD: perfectly survives the reboot. Any similar experiences or hints ? P.Ardichvili ( posted by O.Bordes)
aleneis@jarthur.Claremont.EDU (Tony Leneis) (01/20/90)
In article <1700007@hpgnd.HP.COM> olivier@hpgnd.HP.COM (Olivier BORDES) writes: >Many users of Amiga's (500 and 2000) with the 1.3 ROM >complain about the fact that their machine will >not reboot from RAD: even though RAD: perfectly >survives the reboot. >Any similar experiences or hints ? >P.Ardichvili ( posted by O.Bordes) If you are using arp, you need to either (a) add "BootPri = 0" to the mountlist entry for RAD: or (b) replace the arp mount command with the normal AmigaDOS 1.3 mount command. Apparently arp's mount doesn't have the same default values as its corresponding AmigaDOS command. Tony Leneis aleneis@hmcvax.claremont.edu aleneis@jarthur.claremont.edu
olivier@hpgnd.HP.COM (Olivier BORDES) (01/24/90)
Autoboot from RAD: First, thanks to all of you who posted replies to the question: "Any idea why one could not reboot from a RAD: which has survived the reboot ?" The final answer is: You MUST use the COMMODORE MOUNT command and NOT the ARP command. Now, about BootPri: After extensive tests, I found out that the only significant value for BootPri in the RAD: mountlist entry is -129. For that value, the system will never reboot from RAD:. This is well explained in the 1.3 documentation. For ANY other value, negative 0 or positive, or in the absence of the BOOTPRI line, the system will ALWAYS boot from RAD: if there is no disks in DF0: and ALWAYS boot from Disk if there is a bootable disk in DF0:. The machine is a 2000B with rev 6.0 mother board. P.Ardichvili Posted by O.Bordes (olivier@hpgnd.hp.com)
pds@quintus.UUCP (Peter Schachte) (02/03/90)
In article <1700008@hpgnd.HP.COM> olivier@hpgnd.HP.COM (Olivier BORDES) writes: >Autoboot from RAD: >The final answer is: > You MUST use the COMMODORE MOUNT command and NOT > the ARP command. I've been autobooting from RAD: mounted with ARP mount with no problems. No problems, that is, once I added BootPri = 0, as someone here suggested. I go from 3-finger salute to completed boot in under 30 seconds. I also got my RAD: down to about 40-50K by removing almost everything. I'll post a list of what's in my RAD if anyone's interested. This is on an A1000 with Escort hard disk and a 1M Insider. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
big@shumv1.uucp (Alan Porter) (02/04/90)
In article <1319@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > I also got my RAD: down to about 40-50K by removing almost > everything. I'll post a list of what's in my RAD if anyone's > interested. Please do. A post or e-mail would be GREATLY appreciated! // big@shumv1.ncsu.edu Alan Porter \X/ rap@cscaza.ncsu.edu Amiga Box 21536 NCSU / Raleigh, NC 27607 / (919) 737-6156
pds@quintus.UUCP (Peter Schachte) (02/08/90)
In response to overwhelming demand (2 people asked me) here's what I put in RAD: for transfering to harddisk boot: C directory: Mount 5432 bytes (Note: NOT ARP mount) SetPatch 3844 bytes Execute 4712 bytes (Note: NOT ARP execute) L directory: FastFileSystem 12204 bytes (No OFS partition on HD) DEVS directory: harddisk.device 6132 bytes mountlist 366 bytes (just dh0: entry) system-configuration 232 bytes S directory: startup-sequence 87 bytes T directory: empty FONTS directory: empty LIBS directory: empty My rad:s/startup-sequence contains just 3 lines: c:SetPatch >NIL: ;patch system functions c:mount dh0: c:execute dh0:s/complete-startup My dh0:s/complete-startup contains: dh0:c/realassign l: dh0:l dh0:c/realcd ram: dh0:c/bindnames system dh0: echo "transfered bootup to hard disk script" cd c: mount newcon: speak: aux: pip: null: failat 30 assign >NIL: rad: exists if warn echo "rad: doesn't exist -- mounting" mount rad: relabel drive rad: name RAD if not exists rad:devs copy bench:admin/rad-boot/#? rad: all quiet endif endif failat 11 ; personalizations, like dmouse, noclick, FF, set clock, workbench, etc. endcli >NIL: My dh0:names/system (used by bindnames) looks like this: T: ram:t ENV: ram:env CLIPS: ram:clipboards c: sys:c l: sys:l libs: sys:libs s: sys:s devs: sys:devs fonts: sys:fonts sys: bench: (Note: bench: is the volume name for dh0:) The mountlist entry for RAD: in my hard disk's mount list: RAD: Device = ramdrive.device Unit = 0 Flags = 0 Surfaces = 1 BlocksPerTrack = 1 Reserved = 2 Interleave = 0 LowCyl = 0 ; HighCyl = 93 Buffers = 5 BufMemType = 1 BootPri = 0 # NOTES: There's some strange stuff here because I use ARP, but don't want to put ARP.library in RAD:, and because I use Dave Haynie's bindnames. First, the executables in RAD:c must be regular DOS versions, not ARP. Second, the empty fonts, libs, and t directories in RAD: are there because bindnames seems to toss its cookies if they're not there (mouse cursor freezes). You could replace bindnames with calls to assign, but bindnames cleans things up a bit. Third, dh0:c/realassign and dh0:c/realcd are the real (non-ARP) versions of assign and cd. What I'm doing here is making sure RAM: is available. Unfortunately, if this isn't done, bindnames doesn't create it, and T:, ENV:, and CLIPS: wind up not assigned. (Dave, are you listening? It would be nice if bindnames could create RAM: if it doesn't exist and I'm trying to assign something to it. Besides this and crashing as I mentioned above, bindnames is great.) The reason for calling dh0:c/realassign and dh0:c/realcd is is that at the time this is called, C:, L:, and LIBS aren't yet assigned to the hard disk (this is done by bindnames). Since C isn't assigned, we must explicitly call DH0:C/whatever. Since LIBS: isn't assigned, we can't use ARP versions (since they can't find ARP.library). And since L isn't assigned, we have to assign it (because that's where Ram-Handler is, which allows us to create RAM:). Kind of a nuisance, isnt' it? I have a directory dh0:admin/rad-boot which contains everything I list above as being in rad:. The complete-startup script copies this directory to rad: (after mounting it), if it doesn't exist. I also have a floppy with exactly the same stuff on it. I boot from this when I shut off Ami (which I never do). Note the BootPri entry in the mountlist entry for RAD:. This is necessary if you use ARP's mount to mount RAD:. Note that the mountlist entry for RAD: is nonstandard, so I can tune its size to exactly what is needed. This RAD: blows ~45K, plus the device, buffers, etc. I'm not really sure what it adds up to. But it does let me boot in under 30 seconds, including a bunch of customization. I'd rather have autobooting, but this is a lot better than booting from a floppy. A question for anyone who knows the answer: do I need to do the SETPATCH before mounting the hard disk, or could I put it off until I transfer to the harddisk. This would save a few more K in RAD:. I hope I've covered everything. Good booting to all non-autoboot controler owners out there. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds