01659@AECLCR.BITNET (Greg Csullog) (05/23/89)
Once again, for those who missed earlier postings, STOP using the AUTO folder
to load all your boot-time codes in during startup. It makes much more sense
to use the batch file processor STARTUP.PRG (see sample listing below) to
run codes from any pathway. If you precede a code call with 'ask' you will
be issued a prompt to confirm or cancel execution; save yourself a lot of
grief with infinite reboots when you put a crappy code in AUTO.
Simply put STARTUP.PRG and STARTUP.INF in your AUTO folder. When you want to
add more codes, just insert a call to them in STARTUP.INF. Why mess around
with the order of files in AUTO?
You can get STARTUP.PRG from Accusoft's PD library.
;============== STARTUP.INF for my 1040 ST =============================
display off ; turn echo off
output off ; stop all echo to monitor
;
clear ; clear the display
;
if ($res == high) then ; display a high res DEGAS picture on
graphics 0 c:\choose.pi3 ; the screen if using a mono system
endif ; (this screen asks if I want my ST to
; be an ST, a PC or a Mac)
;
set jumper = $<< ; capture a single character keyboard input
;
if ($jumper == e) then ; exit start up routine if letter e is pressed
exit
endif
if ($jumper == m) then ; if m is typed, become a Mac under Spectre
echo d:\spectre\1spectre.prg >c:\startgem.inf
d:\utility\startgem.prg
exit
endif
if ($jumper == i) then ; if i is typed, become a PC under PC Ditto
echo c:\pc_ditto\ibm_pc.prg >c:\startgem.inf ; let's become a slow XT
d:\utility\startgem.prg
exit
endif
;
; run in Atari mode if e, m, or i not selected (also load in NeoDesk)
;
clear
;
echo c:\neodesk\neomastr.prg >c:\startgem.inf
;
; NO ONE SHOULD USE A HARD DISK WITHOUT NEODESK
;
d:\utility\startgem.prg
;
res medium ; boot in med res if colour monitor is used
;
if ($res == high) then ; display a high res DEGAS picture on
graphics 23 c:\startup2.pi3 ; the screen if using a mono system
else ; else display a med res DEGAS picture
graphics 23 c:\startup2.pi2 ; if booting using a colour system
endif
;
;**********************************************************************
;* run boot-time codes from outside of AUTO - simply change order of *
;* lines to change order of execution. NOTE!!!!!, FOLDXXXX.PRG, *
;* AUTODATE.PRG and some other codes MUST be run from AUTO since they *
;* look for themselves in this folder. *
;**********************************************************************
;
d:\utility\multivec.prg ; load in the UIS file selector utility
d:\utility\uis_ii.prg ; (cannot see using my ST without this!)
d:\utility\diskfree.prg ; speed up for DISPLAY INFO on a disk req.
d:\utility\g+plus.prg ; use G+PLus instead of GDOS
d:\utility\nite.prg ; screen saver
d:\utility\pr960.prg ; 960 pixels/line screen dump configuration
clear
;
accask ; select accessories to load indbrooks@osf.OSF.ORG (David Brooks) (05/24/89)
In article <8905231618.AA24695@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >Once again, for those who missed earlier postings, STOP using the AUTO folder >to load all your boot-time codes in during startup. It makes much more sense >to use the batch file processor STARTUP.PRG (see sample listing below) to >run codes from any pathway. When I tried using a startup program, (don't remember if it was this one) I had the following problem. The STARTUP program loads itself in the bottom of user memory. Then it loads other resident programs above itself. Then it terminates, leaving a hole where it used to be, and GEMDOS can't use that hole. In other words, STARTUP reduces the memory available on my ST compared with using the AUTO-folder ordering. I guess it's OK to use for configuring if you *don't* run any other resident programs from it. So do order your AUTO folder, and put STARTUP (if you use it) last. There was a utility on the net a while ago that did re-order the AUTO folder (among other things), but I accidentally trashed it. Anyone remember? -- David Brooks dbrooks@osf.org Open Software Foundation uunet!osf.org!dbrooks 11 Cambridge Center Personal views, not necessarily those Cambridge, MA 02142, USA of OSF, its sponsors or members.
dag@per2.UUCP (Daniel A. Glasser) (05/24/89)
In article <8905231618.AA24695@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg Csullog) writes: > Once again, for those who missed earlier postings, STOP using the AUTO folder > to load all your boot-time codes in during startup. It makes much more sense > to use the batch file processor STARTUP.PRG (see sample listing below) to > run codes from any pathway. If you precede a code call with 'ask' you will > be issued a prompt to confirm or cancel execution; save yourself a lot of > grief with infinite reboots when you put a crappy code in AUTO. > > Simply put STARTUP.PRG and STARTUP.INF in your AUTO folder. When you want to > add more codes, just insert a call to them in STARTUP.INF. Why mess around > with the order of files in AUTO? > > You can get STARTUP.PRG from Accusoft's PD library. > [ Sample deleted ] This is a rather broad generalization, and one that is a dangerous one to make. The problem is that many programs that are put in the /auto directory are of the "Terminate and stay resident" (TSR) variety. Running these from a batch processing program such as STARTUP.PRG creates a gap in memory when STARTUP.PRG terminates. The program is loaded above STARTUP.PRG and stays in memory. I have no direct experience with STARTUP.PRG, but if it does further Mallocs after running your TSR, it may screw things up by assuming that it owns memory between the end of its old block and the beginning of the new one. Programs like STARTUP.PRG are good for running programs like clock setters, some RAM disks, and the like, but should not be used for programs like the hard disk driver, screen-savers, folder limit fixes, resident debuggers, font switchers, OS call tracers, GDOS, disk caches, and other resident programs of that sort. I have a DANGEROUS program which can be used to reorder the files in a directory, get rid of empty entries in the middle and mark the ones at the end as unused (to speed up directory searches) rather than deleted. I have used this program without any problems since I got it working, but if ANYTHING goes wrong while it's doing its dirty work, look out! I will submit this program (and source) to comp.binaries.atari.st and comp.sources.atari.st sometime in early June (I'm going on a vacation soon and don't have time to dig it out just now.) Note that this program has not been tested under TOS 1.4. Daniel A. Glasser -- _____________________________________________________________________________ Daniel A. Glasser One of those things that goes uwvax!per2!dag "BUMP!!!(ouch)" in the night. ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
ritchie@hpldola.HP.COM (Dave Ritchie) (05/25/89)
And who is Accusoft? Dave
neil@cs.hw.ac.uk (Neil Forsyth) (05/25/89)
In article <957@osf.OSF.ORG> dbrooks@osf.org (David Brooks) writes: >There was a utility on the net a while ago that did re-order the AUTO >folder (among other things), but I accidentally trashed it. Anyone >remember? I do. I wrote it! It was called Disk Toolbox (now DT). The program was originally menu driven but is now command line driven. I'll E-mail you and the binaries moderator a copy. >-- >David Brooks dbrooks@osf.org >Open Software Foundation uunet!osf.org!dbrooks >11 Cambridge Center Personal views, not necessarily those >Cambridge, MA 02142, USA of OSF, its sponsors or members. _____________________________________________________________________________ / DISCLAIMER: Unless otherwise stated, the above comments are entirely my own \ ! "So your father was a woman" - "No No ROMAN (crack) Argh!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh ! ! Scotland ! \_____________________________________________________________________________/
bob@cmpfen.UUCP (Bob Breum) (05/25/89)
In article <957@osf.OSF.ORG> dbrooks@osf.org (David Brooks) writes: >In article <8905231618.AA24695@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >>Once again, for those who missed earlier postings, STOP using the AUTO folder >>to load all your boot-time codes in during startup. It makes much more sense >>to use the batch file processor STARTUP.PRG (see sample listing below) to >>run codes from any pathway. > >When I tried using a startup program, (don't remember if it was this >one) I had the following problem. The STARTUP program loads itself in >the bottom of user memory. Then it loads other resident programs >above itself. Then it terminates, leaving a hole where it used to be, >and GEMDOS can't use that hole. > >In other words, STARTUP reduces the memory available on my ST compared >with using the AUTO-folder ordering. Wrong. The version of STARTUP.PRG which I have used for quite a long time now actually consists of two parts: STARTUP.PRG and STARTUP.TOS. The former runs from your \AUTO folder and loads the latter into high memory. It is this latter program which performs the startup processing. When it terminates, it leaves no hole in memory, because it was out of the way in high memory. It works extremely well. Murray put a lot of work into this program. Don't trash it when you don't know what you are talking about. -- Computer Fenestrations Bob Breum Post Office Box 151 {uiucuxc|hoptoad|petsd|ucf-cs}!peora!cmpfen!bob Lake Monroe, FL 32747 USA +1 407 322-3222 "C is the new BASIC"
saj@chinet.chi.il.us (Stephen Jacobs) (05/25/89)
In article <861@per2.UUCP>, dag@per2.UUCP (Daniel A. Glasser) writes: > > I have a DANGEROUS program which can be used to reorder the files in > a directory, get rid of empty entries in the middle and mark the ones > at the end as unused (to speed up directory searches) rather than deleted. > I have used this program without any problems since I got it working, but > if ANYTHING goes wrong while it's doing its dirty work, look out! > I will submit this program (and source) to comp.binaries.atari.st and > comp.sources.atari.st sometime in early June (I'm going on a vacation soon It's not especially difficult to re-order the entries in a subdirectory by hand, using an absolute sector editor (DRFLOPPY is available on a lot of BBS-s). In my experience, this produces the appropriate amount of terror while one is screwing with critical disk information. Since every sector editor I've seen lets you finish the whole sector before writing it back, there is some VERY MINIMAL protection against errors. Once Dan distributes his program, I'll probably quit doing this. Steve J.
covertr@gtephx.UUCP (Richard E. Covert) (05/27/89)
In article <957@osf.OSF.ORG>, dbrooks@osf.OSF.ORG (David Brooks) writes: > In article <8905231618.AA24695@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: > >Once again, for those who missed earlier postings, STOP using the AUTO folder > > There was a utility on the net a while ago that did re-order the AUTO > folder (among other things), but I accidentally trashed it. Anyone > remember? > -- I have a program called 'autosort.prg' which is great. it reads the auto folder, copies the files into RAM, and then lets you move the programs around in a list on the screen. Once you are satisfied with the order of the list, you can rewrite the new list of files back into your auto folder. It is one of the BEST utilities that I have seen to re-order your auto folder. If you can't find it I will post it to binaries.atari.st. Richard (gtephx!covertr) covert
dbrooks@osf.OSF.ORG (David Brooks) (05/27/89)
In article <210@cmpfen.UUCP> bob@cmpfen.UUCP (Bob Breum) writes: :In article <957@osf.OSF.ORG> dbrooks@osf.org (David Brooks) writes: :> :>When I tried using a startup program, (don't remember if it was this :>one) I had the following problem. The STARTUP program loads itself in :>the bottom of user memory. Then it loads other resident programs :>above itself. Then it terminates, leaving a hole where it used to be, :>and GEMDOS can't use that hole. : :Wrong. : :The version of STARTUP.PRG which I have used for quite a long time now :actually consists of two parts: STARTUP.PRG and STARTUP.TOS. (etc) [...] :Murray put a lot of work into this program. Don't trash it when you don't :know what you are talking about. OK, so I'm not up to date. Not a reason to flame me, though; there *was* a STARTUP.PRG that left a memory hole, and please note my parenthetical phrase. I'm glad the problem has been addressed. -- David Brooks dbrooks@osf.org Open Software Foundation uunet!osf.org!dbrooks 11 Cambridge Center Personal views, not necessarily those Cambridge, MA 02142, USA of OSF, its sponsors or members.