ramsiri@blake.u.washington.edu (Enartloc Nhoj) (01/18/91)
Are pinhead and FATSPEED incompatible/unnecessary? with 1.4? thanks -kevin
ken@opusc.csd.scarolina.edu (Ken Sallenger) (01/19/91)
In article <14597@milton.u.washington.edu> ramsiri@blake.u.washington.edu asks:
=> Are pinhead and FATSPEED incompatible/unnecessary? with 1.4?
The Pinhead v1.4 docs claim that it loads faster than TOS 1.4, and
can be used with it. I haven't tried it myself.
--
Ken Sallenger / ken@bigbird.csd.scarolina.edu / +1 803 777-6551
Computer Services Division / 1244 Blossom ST / Columbia, SC 29208hojo@cbnewsl.att.com (HC Johnson) (01/23/91)
In article <1991Jan18.212946.24607@opusc.csd.scarolina.edu>, ken@opusc.csd.scarolina.edu (Ken Sallenger) writes: > In article <14597@milton.u.washington.edu> ramsiri@blake.u.washington.edu asks: > => Are pinhead and FATSPEED incompatible/unnecessary? with 1.4? > 1. FATSPEED was a neat upgrade for TOS 1.2 to get around the SLOW down on HD as they filled up. (Yes and other improvements as well). TOS 1.4 has fixed this, and added a good working cache. 2. pinhead allows you to take advantage of a new feature in TOS 1.4; namely whether to ZERO the Bss or not. Like MS/DOS TOS normally clears ALL unused memory that is initially assigned to a process. On multi-meg processors this is somewhat slow. (Again TOS 1.4 uses better code and does clear faster.). There is a new bit in the process header that indicates that TOS need not clear bss, as the process will do its own initialization. 3. Also a note on poolfix3 and poolfix4. poolfix3 is the OFICIAL, ATARI program, freely distributed to the net. It allows increasing the caches in TOS 1.4. We (on the net) tried to suppress the name poolfix4, but I see it raised again. This was a reverse engineered version from Germany that set out to add their protocol for TSR programs; but was also substantially improved (Authors words) which means that it is not supported or blessed by Atari. I have not seen any comment as to failures with "poolfix4" so it may well be safe. To Summarize: Dont use FATSPEED with TOS1.4 Pinhead will speed loading programs if they do not require initialized BSS. Use Poolfix3 or whatever to improve the performance of the internal caches in TOS 1.4. Howard Johnson ATT BELL LABS att!lzsc!hcj hcj@lzsc.att.com
raichle@azu.informatik.uni-stuttgart.de (Bernd Raichle) (01/23/91)
In article <1991Jan22.160120.16423@cbnewsl.att.com>, hojo@cbnewsl.att.com (HC Johnson) writes:
] 2.
] pinhead allows you to take advantage of a new feature in TOS 1.4; namely
] whether to ZERO the Bss or not.
]
] Like MS/DOS TOS normally clears ALL unused memory that is initially assigned
] to a process. On multi-meg processors this is somewhat slow. (Again TOS 1.4
] uses better code and does clear faster.). There is a new bit in the process
] header that indicates that TOS need not clear bss, as the process will do its
] own initialization.
I think, the BSS section is (and should be) always cleared!
With the "fastload" bit set, TOS 1.4 doesn't clear the heap (= memory
which could be allocated with malloc() calls).
-berndcummins@d.cs.okstate.edu (John Cummins) (01/23/91)
The stuff in a previous host about process headers sounded right (I'm not a software person...) but Pinhead is not needed with TOS 1.4, (It will work however) as TOS 1.5 uses a 'Fastload' bit in the directory to indicate whether a program needs to have memory cleared before it loads. A rather clumsy utility was available to set this bit (for faster loading... slow loading is the default! Argh!!!) but I despise clumsy utilities and am waiting for a utility that will allow selection of multiple files at a time to have the "fast bit" set. cummins@d.cs.okstate.edu
fischer-michael@cs.yale.edu (Michael Fischer) (01/24/91)
In article <1991Jan23.135900.16567@d.cs.okstate.edu> cummins@d.cs.okstate.edu (John Cummins) writes: >The stuff in a previous host about process headers sounded right (I'm not >a software person...) but > >Pinhead is not needed with TOS 1.4, (It will work however) as TOS 1.5 uses >a 'Fastload' bit in the directory to indicate whether a program needs >to have memory cleared before it loads. A rather clumsy utility was >available to set this bit (for faster loading... slow loading is the default! >Argh!!!) but I despise clumsy utilities and am waiting for a utility >that will allow selection of multiple files at a time to have the "fast bit" >set. > >cummins@d.cs.okstate.edu I wrote one, too, with a command line interface. I should just post it and save you the bother. -- ================================================== | Michael Fischer <fischer-michael@cs.yale.edu> | ==================================================
baffoni@aludra.usc.edu (Juxtaposer) (01/24/91)
In article <14597@milton.u.washington.edu> ramsiri@blake.u.washington.edu (Enartloc Nhoj) writes: >Are pinhead and FATSPEED incompatible/unnecessary? with 1.4? > >thanks >-kevin In regards to this question, I wonder: I have been having some rather disturbing problems lately. Sometimes, especially after running Cleanup (the one from ICD, not the demo), I go to open a drive that has not been accessed prior to running Cleanup, and there is nothing there! 0 out of 0 files! Also, if I trying going any deeper into an accessed drive, the directory doesn't exist! The worst part was when I tried to run Cleanup on my drive E and it had two bombs when it went to do a directory map. However, by turning the machine off and then on, everything reappears like it should, and everything is accessible. I don't believe the fault lies in Cleanup since occaisionally the same thing happens when I do not use it - I just go into my Utilities directory, only to find all the files are gone (but soon reappear by re-booting). I currently have in my Auto folder (and not neccessarily in this order as I am not at home) Copyfix. , timeset. , pinhed18., fatspeed., and QuickST2.2 (i forgot the prog name) progs. Just to show how frustrating this is, I just ran Cleanup on my E drive fine, but the F drive bombed (however, my C drive has been working and never bombs under Cleanup or DLII...Whew!). Anyone have any ideas? Comments? -Mike
ekrimen@ecst.csuchico.edu (Ed Krimen) (01/24/91)
cummins@d.cs.okstate.edu (John Cummins) writes: - A rather clumsy utility was available to set this bit (for faster - loading... slow loading is the default! Argh!!!) but I despise - clumsy utilities and am waiting for a utility that will allow - selection of multiple files at a time to have the "fast bit" set. A few months ago, I posted to atari.archive a program called FLXIFAST.LZH which lets you set the fastload bit on multiple files. If it's not there, let me know and I'll post it again. BTW, that 24-pin screen dump program I posted to atari.archive is called SDUMP1_5.LZH. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
lunnon@qut.edu.au (01/24/91)
In article <1991Jan23.135900.16567@d.cs.okstate.edu>, cummins@d.cs.okstate.edu (John Cummins) writes: > The stuff in a previous host about process headers sounded right (I'm not > a software person...) but > > Pinhead is not needed with TOS 1.4, (It will work however) as TOS 1.5 uses > a 'Fastload' bit in the directory to indicate whether a program needs > to have memory cleared before it loads. A rather clumsy utility was > available to set this bit (for faster loading... slow loading is the default! > Argh!!!) but I despise clumsy utilities and am waiting for a utility > that will allow selection of multiple files at a time to have the "fast bit" > set. If you refer to the makefast utility ??? then rename it makefast.ttp and give it a list of files to makefast. This clumsy utility will then do it for you. > > cummins@d.cs.okstate.edu BOB R.Lunnon@qut.edu.au
bill@mwca.UUCP (Bill Sheppard) (01/25/91)
In article <1991Jan23.135900.16567@d.cs.okstate.edu> cummins@d.cs.okstate.edu (John Cummins) writes: >[discussion of fast-load bit]... A rather clumsy utility was >available to set this bit (for faster loading... slow loading is the default! >Argh!!!) but I despise clumsy utilities and am waiting for a utility >that will allow selection of multiple files at a time to have the "fast bit" >set. Quick Find in the Quick Tools package from Branch Always Software will support setting/unsetting any attribute, including the fast-load bit. You specify files by wildcard, so you could easily set the fast-load bit on all *.PRG files (though you might need to individually unset a few of them if they break). -- ################################################################################ # Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill # # Microware Systems Corporation --- OS-9: Seven generations beyond __/_!! # #######Opinions expressed are my own, though you'd be wise to adopt them!#######