🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #37907

Re: (none)

#37907
From: Allan Pratt
Date: Tue, 11 Apr 1989 00:21
37 lines
2481 bytes
In article <8904071506.AA22861@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK
writes:
> I've heard talk about TOS 1.4. One of the "little" things about TOS that
> is very annoying is when a program returns to desktop the OS "always" reads
> the disk, even if the disk hasn't changed! Has this been rectified on the
> new TOS or will this little problem be explained away as "necessary" from
> somebody up on these things?

When you launch an application, you do it from an open window.  When you
return, the Desktop has to redraw that window.  To do this it has to
re-read the directory for the files in that window.  To do that, it has
to read the disk. 

Well, not quite: if you have so many GEMDOS disk buffers in your system
that the directory is still cached, the Desktop's reads won't actually
hit the disk.  I don't know if this is ever true for current TOS,
because the cache is managed so badly.  Also, you only have four buffers
by default (two each in two different lists), so you rarely have
anything useful still cached.  If you add more buffers, GEMDOS
performance improves considerably, especially with TOS 1.4.

As an example, let's take copying a disk full of files onto your hard
disk.  With only a couple of buffers, you'll hear the floppy head seek
to the directory, to the FAT, out to the data area to read the file,
then back to the directory for the next file.  With more buffers in TOS
1.4, the FAT and directory are read once, and from then on the disk
simply steps through the data area, reading sector after sector of
file after file, without having to re-read the FAT or directory.

Naturally, copying *to* a floppy will involve more, because writes are
never delayed -- closing a file causes the FAT and directory to be
updated.  But reading a disk full of files is much faster & more
pleasant. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt
Technical Details
Message-ID: <1449@atari.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!apratt
References: <8904071506.AA22861@ucbvax.Berkeley.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: (none)
Message-ID: <1449@atari.UUCP>
Date: 11 Apr 89 00:21:14 GMT
References: <8904071506.AA22861@ucbvax.Berkeley.EDU>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 37