page@swan.ulowell.edu (Bob Page) (10/25/88)
[distribution opened to world, everyone can benefit, although this information is not for the weak at heart, and should not be attempted at home unless you know what you're doing. CBM tells you to do things for good reasons, and you can only break the rules if you know how it affects you. 'nuf said.] Steve, you're way too slow. slc@hoptoad.UUCP (Steve Costa) wrote: >I don't use RAD: because it won't autoboot with FFS (even if I had >the new ROMs). There's some confusion among new 1.3 owners - RAD will autboot unless RAD is running FFS. That is, you can have FFS running on every other device in your system (except RAD) and RAD will still autoboot. Of course you need the new ROMS ... >I want to minimize the time required to boot by getting off of DF0: as >quickly as possible. >Here's my startup-sequence on DF0:s > >BindDrivers >DH0:Start/CD DH0:Start >Mount HD0: from DH0:Start/MountList >Assign Devs: HD0:devs >Assign L: HD0:L >Resident CLI L:Shell-Seg SYSTEM pure add >Mount NewCon: >Mount VD0: >Assign T: VD0: >CD VD0: >DH0:Start/Execute >nil: HD0:Set/Startup-Sequence ; customized startup Here's mine: Mount WB: DefDisk WB: Assign T: RAM: Execute S:Startup-Sequence I don't bother with BindDrivers, I only have the one drive, and it's not the 2090 controller. If you only have one device that BindDrivers is going to find, forget BindDrivers and do a Mount yourself if you can (maybe some people can't, I don't know all the possible configurations out there). BindDrivers seeks all over the place and slows you down terribly. It's nice for folks who don't want to be bothered with adding .info files to devs: and hacking startups, but speedsters don't need it. DefDisk is a PD utility to do all the common Assigns at once - much faster than six or seven Assigns. All the other magic (like SetPatch, mounting the other HD partitions, etc) comes from s:startup-sequence. The official CBM line is "we can't be responsible for the stability of your system if you don't make SetPatch the **FIRST** thing in your startup" but SetPatch doesn't FIX any of the things we do here (in the first 4 lines of the startup-sequence) so make it the first thing you do in your harddisk startup. You can throw away the CD VD0: since you touch VD0: when you Assign to it, you can also auto-start it by setting Mount = 1 in the Mountlist (I think - something tells me I tried this once and it didn't work). You can defer making Shell-Seg resident and mounting NewCon (and VD0:) and do it from the hard disk - no need to have them done from floppy. Assuming you had to have BindDrivers, and your non-FFS partition is called SLOW: your new startup sequence could be: BindDrivers DefDisk SLOW: Assign T: RAM: Execute S:Startup-Sequence ; customized startup [remember - After DefDisk, C: is on your hard disk!) Where SLOW:s/Startup-Sequence says: Mount DH0: DefDisk DH0: Execute S:Startup-Sequence [now C: is your FFS partition] If you don't need BindDrivers, you can format your small partition (the one I called SLOW: above) with the FFS and use the startup I use but that might be a *little* slower because Mount has to read the mountlist, driver and FastFileSystem from your floppy. On the other hand, you'll have all FFS partitions on your hard disk. You can speed things up just a little by mounting an old filesystem, so the FastFileSystem image won't have to be read in from floppy, but you have to keep an OFS partition. Your choice. I have a 2MB WB: FFS partition where I keep the CBM WB and Extras stuff as distributed (nix demos and printer devices, natch) and loads of fonts. So I take the startup hit to load FFS from floppy. >I've been able to eliminate activity on DF0: after "binddrivers" except for >line three. The mount still seems to cause access to DF0: even though the >mountlist and "FastFileSystem" are both in DH0:start. > >What does "mount" need that is still on DF0: ? Some have said the device driver, that isn't right, as BindDrivers loads it. Mount doesn't need anything. The reason you keep getting floppy accesses is that you haven't redefined C: so your Assign, Mount, Resident and CD commands are being fetched from your floppy. One last speedup - Execute accesses T: -- you want to reassign it to RAM: (you don't need T: on VD0: since it's temp storage that you don't need to keep - besides, RAM: is faster than VD0:). ..Bob (been speeding a long time) PS I'll post DefDisk to comp.binaries.amiga for all you budding speedsters. -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
page@swan.ulowell.edu (Bob Page) (10/25/88)
oh yeah - after you edit your df0:s/startup-sequence, remove all your unnecessary files (including all the .info files except for the ones in DEVS: if you're using binddrivers) from df0: then format a clean floppy in df1: and copy df0: to df1: (NOT diskcopy). It reshuffles the FS layout on df1: so DOS doesn't have to seek so much. Now use the disk in df1: as your standard boot disk. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:Bob Page, page@swan.ulowell.edu ulowell!page Writes:
:Here's mine:
:
:Mount WB:
:DefDisk WB:
:Assign T: RAM:
:Execute S:Startup-Sequence
Here's mine: (floppy s/startup-sequence)
binddrivers
mount dhb:
dhb:c/execute dhb:s/startup-sequence
dhb:c/endcli >nil:
My floppy startup essentially consists of two lines. The last
two are, obviously, run from my HD. The HD startup sequence starts up
ConMan, opens a new CLI window with yet a third startup file, and then
ends... the floppy sequence closes down the original CLI window and
exits while the HD continues with its boot sequence.
The HD continues running startup-2 in the new CLI (ConMan'd) window
and does everything else, including re-assigning everything, mounting
the remaining HD partitions, starting up my shell, etc... Since I have
removed all references to the floppy, including references to the original
startup sequence (because it ended), it disappears from the device list if
I eject it.
(dhb:s/startup-sequence) DHB: is a small 3MB partition on my HD.
dhb:c/stack 10000
dhb:c/assign l: dhb:l
dhb:c/assign libs: dhb:libs
dhb:c/cd ram:
dhb:c/conman -b1000
dhb:c/newcli con:40/40/600/160/AmigaDOS FROM dhb:s/startup-2
(dhb:s/startup-2) .. because the newcli command needs an execute script.
dhb:c/shell dhb:c/.rootlogin
endcli > nil:
(dhb:c/.rootlogin (for the shell))
# Executed just once
cat dhb:MOTD
echo
echo Boot in progress
cd dhb:
dhb:c/rez dasm dme cc as ln run path assign mount Set >nil:
#dhb:c/rez arc zoo compress uncompress >nil:
dhb:c/assign c: dhb:c
assign devs: dhb:devs
assign sys: dhb:
assign libs: dhb:libs
assign fonts: dhb:fonts
assign l: dhb:l
assign s: dhb:s
assign t: ram:
assign comp: dhb:
assign SYS2: comp:
assign ENV: sys:env
assign include: comp:include
assign clib: comp:clib
path reset
startime
ff
runback c:clock
mount vd0:
mount pipe:
mount path:
dmouse -c2 -l0 -C newcli "<nil: >nil: con:320/120/320/80/Shell c:shell.exe"
cd ram:
Set CLIB=comp:clib/
Set CCTEMP=ram:
Set INCLUDE=comp:include/\!comp:asm/
echo Mounting DH0 DH1 DH2 DH3
mount dh0:
mount dh1:
mount dh2:
mount dh3:
echo -n >path:c
echo Boot:c/^jGamma:c/^jAlpha:c/ >>path:c
assign c: path:c
# these files contain specific assign's for the partitions.
source dh3:c/init.sh
source dh2:c/init.sh
source dh1:c/init.sh
source dh0:c/init.sh
source c:.login
mwb i W30 H12
rez -r mount Set assign path >nil:
echo Amiga OS1.3 SHELL ready.
-Mattejkst@cisunx.UUCP (Eric J. Kennedy) (10/27/88)
In article <9832@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >All the other magic (like SetPatch, mounting the other HD partitions, >etc) comes from s:startup-sequence. The official CBM line is "we >can't be responsible for the stability of your system if you don't >make SetPatch the **FIRST** thing in your startup" but SetPatch >doesn't FIX any of the things we do here (in the first 4 lines of the >startup-sequence) so make it the first thing you do in your harddisk >startup. That's ok. SetPatch isn't even the first thing in C-A's distribution s:startup-sequence. Pretty silly to say that, then break your own rules. >Assuming you had to have BindDrivers, and your non-FFS partition is >called SLOW: your new startup sequence could be: >BindDrivers >DefDisk SLOW: ^^^^^^^ You can make that "SLOW:C/DefDisk SLOW:" and save another couple seconds--read it off the hard disk, not the floppy. >Assign T: RAM: >Execute S:Startup-Sequence ; customized startup -- +-=-=-=-=-=-=-=-=-+ Eric Kennedy | Bush & | ejkst@cisunx.UUCP | Bentsen '88 !! | +-=-=-=-=-=-=-=-=-+
darin@nova.laic.uucp (Darin Johnson) (10/28/88)
A long time ago, when execute still tried to write to the floppy even when T: was assigned, I got really annoyed with having my floppy churn away during startup even when executing from the hard disk (at that time, my startup on the floppy was only five lines). A quick speed up that I used (and still use) is to change: execute s:Startup-Sequence ; S: is on hard disk now to: newcli con:a/b/c/d/title from s:Startup-Sequence endcli >nil: This eliminated floppy access entirely after "endcli" was done, a VERY noticable speedup in startup time. Of course, in these modern times, with a patched up EXECUTE command, all you need to do is to reassign T:. However, there are still some nice advantages to using NEWCLI instead of EXECUTE. First, you can open up the new window any size you want - my favorite is to have it cover all the screen except for about an inch on the right side for icons. Second, you can have NEWCLI open up a NEWCON: or ConMAN window - Ta Da! After finishing the startup, your system is set up and ready to go, with a NEWCON: open and ready, just the size you need. Still only 2 things wrong with my startup sequence (sigh) - first, binddrivers takes way too long (along with the hard disk buzzing) - second, it is much too annoying to have Gomf2.2 run from startup since it takes too long. I have my entire startup finished and hard disk quiescent, but Gomf still has that stupid startup window for another 5 seconds.... Anyone know a way to start it up without the message window? ----------- A hint to 1.3 users who are reformatting their hard disks under 1.3 -- If you want to get an autoboot controller, you must leave the first partition under SFS. But how big do you make it? If you make it too big, you are wasting space that could be under FFS. If its too small, you'll have to reformat again when you get the autoboot capability. Since the 1.3 manual doesn't come out and tell you, I had to figure it out on my own... 2 tracks is sufficient space (on an ST225) to hold what you need to get control transferred to your FFS system (including space for harddisk.device, the FFS handler, some libraries, etc.). I used 3 tracks myself, just so that there would be a bit of elbow room for editing files, copying things around, etc. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) "I had a choice, so I bought an Amiga"