[comp.sys.atari.st] New TOS versions

larserio@IFI.UIO.NO (LarsErikOsterud) (04/24/91)

As I sit here testing things on my MEGA STE I discover two things:

a)  PINHEAD won't work on TOS 2.05
b)  SYSMON  won't work on TOS 2.05

Does any body know if there are (or will be) new versions out soon that
supports TOS 1.6, TOS 2.05 and TOS 3.05 ?

 Lars-Erik  /  ABK-BBS +47 2132659  /   ____ ______ ________________________
  Osterud  /  larserio@ifi.uio.no  /   /___    /            The norwegian ST
__________/ ______________________/   ____/   /   Klubben,  user association

Shervin.Shahrebani.Of.250/744@f744.n250.z1.FidoNet.Org (Shervin Shahrebani Of 250/744) (04/27/91)

You don't need Pinhead if you have TOS 1.4 and above.  I have a Mega STE and
have experienced the problem as well but Pinhead is nothing compared to the
TOS's built in fast load.  Why bother when TOS has it already?  I know
pinhead may be compatible with a few more packages but there is nothing to
it.
S.S.

adamd@rhi.hi.is (Adam David) (05/02/91)

In <672747111.0@egsgate.FidoNet.Org> Shervin.Shahrebani.Of.250/744@f744.n250.z1.FidoNet.Org (Shervin Shahrebani Of 250/744) writes:

>You don't need Pinhead if you have TOS 1.4 and above.  I have a Mega STE and
>have experienced the problem as well but Pinhead is nothing compared to the
>TOS's built in fast load.  Why bother when TOS has it already?  I know
>pinhead may be compatible with a few more packages but there is nothing to
>it.

Doesn't Pinhead simply compress executables into a self-extracting form that
takes less disk space and therefore less time to load?
Is this what TOS 1.4 fastload does, or is there any benefit in using both
methods?
The time to load an application program is perhaps not a very significant
factor if the program is just to be loaded in and much time then spent working
in the program. On the other hand major savings in disk space matter quite a
lot to most users - from single floppy machines up to Gigabyte hard disks.
The shorter load time is just a useful side effect of the data compression and
is paid for by the time taken to compress the files (also the extra CPU load
during uncompression in a multiprogramming environment). 

--
Adam David.  (adamd@rhi.hi.is)

vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/03/91)

In article <3092@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
>In <672747111.0@egsgate.FidoNet.Org> Shervin.Shahrebani.Of.250/744@f744.n250.z1.FidoNet.Org (Shervin Shahrebani Of 250/744) writes:
>
>>You don't need Pinhead if you have TOS 1.4 and above.  I have a Mega STE and
>>have experienced the problem as well but Pinhead is nothing compared to the
>>TOS's built in fast load.  Why bother when TOS has it already?  I know
>>pinhead may be compatible with a few more packages but there is nothing to
>>it.
>
>Doesn't Pinhead simply compress executables into a self-extracting form that
>takes less disk space and therefore less time to load?
>Is this what TOS 1.4 fastload does, or is there any benefit in using both
>methods?
TOS 1.4 and pinhead both suppress filling all of (allocated) memory with
zeroes before loading and executing the program.  That's all.  I got a
program that compressed programs, which then un-compressed upon executing,
but I had a lot of trouble with it.  I got it from atari.archive, but, since
having all the trouble, I haven't used it much, and therefore already
forgot the name.
-- 
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp

ekrimen@ecst.csuchico.edu (Ed Krimen) (05/03/91)

In article <3092@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
>In <672747111.0@egsgate.FidoNet.Org> Shervin.Shahrebani.Of.250/744@f744.n250.z1.FidoNet.Org (Shervin Shahrebani Of 250/744) writes:
>
>>You don't need Pinhead if you have TOS 1.4 and above.  I have a Mega STE and
>>have experienced the problem as well but Pinhead is nothing compared to the
>>TOS's built in fast load.  Why bother when TOS has it already?  I know
>>pinhead may be compatible with a few more packages but there is nothing to
>>it.
>
>Doesn't Pinhead simply compress executables into a self-extracting form that
>takes less disk space and therefore less time to load?

No, that's DC Squish, or any similar packer.

>Is this what TOS 1.4 fastload does, or is there any benefit in using both
>methods?

The fastload bit doesn't let the ST clear the remaining memory before it
loads a program.  Pinhead does the same; actually, I've heard that Pinhead
is actually faster than the fastload bit setting.  I tried it on a 2 meg
machine and the difference was one second.  I run Pinhead and have my
programs with the fastload bit set on my 4meg machine.

>The time to load an application program is perhaps not a very significant
>factor if the program is just to be loaded in and much time then spent working
>in the program. On the other hand major savings in disk space matter quite a
>lot to most users - from single floppy machines up to Gigabyte hard disks.
>The shorter load time is just a useful side effect of the data compression and
>is paid for by the time taken to compress the files (also the extra CPU load
>during uncompression in a multiprogramming environment). 
>

If you've never used Pinhead or set the fastload bit on a TOS1.4 and up machine,
then you should really check it out.  There is a great speed difference
when loading programs, even on a one meg machine; the difference can be 
seen especially when loading a lot of AUTO folder programs.


-- 
   |||   Ed Krimen [ekrimen@ecst.csuchico.edu or al661@cleveland.freenet.edu]
   |||   Video Production Major, California State University, Chico
  / | \  SysOp, Fuji BBS: 916-894-1261

boyd@nu.cs.fsu.edu (Mickey Boyd) (05/03/91)

In article <3092@krafla.rhi.hi.is>, adamd@rhi.hi.is (Adam David) writes:
>
>Doesn't Pinhead simply compress executables into a self-extracting form that
>takes less disk space and therefore less time to load?
>Is this what TOS 1.4 fastload does, or is there any benefit in using both
>methods?

No, you are thinking of Packer or DC Squish (or some variant therein).  What 
Pinhead does is prevent the clearing of memory before loading binaries.  Since
any well written program should not depend upon a blank "slate" to run 
correctly, this is safe and speeds up load time dramatically.  The TOS 1.4 
fastload bit does the same thing.  Note that some programs do depend upon 
"clean" memory to work.  Pinhead has a provision to allow for clearing of 
memory for only the programs that need it (and only the amount of memory 
that is needed).  I don't think Pinhead hurts anything in TOS 1.4, and it 
is more flexible than the fastload bit method.  I am sure this is discussed 
in detail in the Pinhead docs (I think 1.8 is the latest version).  It should
be on atari.archive.umich.edu.
--
    ---------------------------------+-------------------------------------
             Mickey R. Boyd          |  "Kirk to Enterprise.  All clear 
          FSU Computer Science       |      down here.  Beam down    
        Technical Support Group      |      yeoman Rand and a six-pack . ."
      email:  boyd@fsucs.cs.fsu.edu  |               
    ---------------------------------+-------------------------------------

healy@cod.NOSC.MIL (Mike Healy) (05/04/91)

Regarding pinhed, while well-written programs should not require
a blank slate, real-life programs apparently often do. I was
getting random crashes especially during booting. I was starting
to think that my power supply was getting flaky, but figured
I'd go through the auto folder analysis. Removing pinhed from
my auto folder eliminated my boot-time crashes. I have an
awful lot of junk in my auto folder. I don't think it's pinhed's
fault, but he's outta there anyway. I guess the moral is: if
things work fine with pinhed, great; but if you start getting
random crashes ...

Mike Healy

healy@cod.nosc.mil

boyd@nu.cs.fsu.edu (Mickey Boyd) (05/04/91)

In article <3043@cod.NOSC.MIL>, healy@cod.NOSC.MIL (Mike Healy) writes:
>
>Regarding pinhed, while well-written programs should not require
>a blank slate, real-life programs apparently often do. I was
>getting random crashes especially during booting. I was starting
>to think that my power supply was getting flaky, but figured
>I'd go through the auto folder analysis. Removing pinhed from
>my auto folder eliminated my boot-time crashes. I have an
>awful lot of junk in my auto folder. I don't think it's pinhed's
>fault, but he's outta there anyway. I guess the moral is: if
>things work fine with pinhed, great; but if you start getting
>random crashes ...
>

The latest version of Pinhead allows you to specify whether you wish to 
clear memory or not for any particular program.  It also allows you to 
specify exactly how much memory to clear.  The docs come with a list of 
problem programs that require the use of this feature.  Using this, you 
can still enjoy the benifits of Pinhead for the majority of your stuff.

--
    ---------------------------------+-------------------------------------
             Mickey R. Boyd          |  "Kirk to Enterprise.  All clear 
          FSU Computer Science       |      down here.  Beam down    
        Technical Support Group      |      yeoman Rand and a six-pack . ."
      email:  boyd@fsucs.cs.fsu.edu  |               
    ---------------------------------+-------------------------------------