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