julius@yugas.UUCP (Julius OKLAMCAK) (02/26/88)
This is a short little program I found on a local BBS:
DiskFree V1.0 By Timothy Purves
Diskfree is a short little Autofolder program that speeds up the
Gemdos Diskfree() function. This little jewel will perform a
"diskfree" function in under 2 seconds on my 60 megabyte supra drive.
Atari's takes over 20 seconds to do the same. Any program that calls
gemdos(0x36,..) will increase in speed 10 fold. This program is
in the Public Domain. Enjoy with good health.
-Tim Purves
--------------------------<cut here>--------------------------
begin 644 diskfree.prg
M8!H -D 4 & QQ$25-+1E)%10 u
M u
M u
M u
M u
M u
M u
M u
M u
M u
M u
M u
M !.:# 7" #6< 9![P &2.<_/BQ(#%8 u
M-F8 -I*;@ &9@ $#\\ !E.052/4H ]0 &#&X 0 &;P NC N 930#\ u
M/SP !TY-6(\J0$J 9P HD)Y "$#/\ ( (2""T 19P BG[_4D>^u
M;0 (; 6# N 930#\ /RT "M]7/SP 4GY $"\,0F<_/ $3DU/[P .u
M2D!F !>?/]21KQ\ 0!LP# Y "$K!M YL 44GD (22EQFX%)Y "u
M$(&X D* ,#D (0(, P+0 .(, P%2# ,"T B# 3-]\_$* 3G-,WWS\u
M+SD ,3G5,WWS\</].<TAY #9#\\ E.05Q/0J<_/ @3D%<3R\ (_@ u
MA PA_ A0 A#\\ "!.05Q/0?D ,BD>\ !$)G+P@_/ Q3D$;141Iu
M<VM&<F5E('8Q+C L(%!R;V=R86T@8GD@5&EM;W1H>2!0=7)V97,-"@H (" @u
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ FP(+B0."@XD$!P&u
"$ u
end
--------------------------<cut here>--------------------------
Enjoy!engst@batcomputer.tn.cornell.edu (Adam C. Engst) (03/01/88)
What exactly does this "diskfree" program really do for those of us who
don't speak fluent C?
Adam
--
Adam C. Engst engst@tcgould.tn.cornell.edu
pv9y@cornella.bitnet
"If it's not interactive fiction, it's not fun."apratt@atari.UUCP (Allan Pratt) (03/02/88)
From article <705@yugas.UUCP>, by julius@yugas.UUCP (Julius OKLAMCAK): > This is a short little program I found on a local BBS: > > DiskFree V1.0 By Timothy Purves I'm sure this works fine, and most of us know why Dfree is slow in the current (old and MEGA) ROMs, and I've already sped this code up in the new GEMDOS, but ... If you start with a virgin hard disk, create a file on it, write 253K to it, and then do Dfree, you will see that *no* space has been used -- the 253K is not counted against you. This happens because until you close the file, the FAT sector (which you've filled with the one chain for this file) is still in a GEMDOS buffer, not on disk, and this utility (necessarily) subverts the GEMDOS buffers. With that caveat aside, I'm sure this is a fine utility which people should use to speed up the Dfree operation ("Show Info" from the desktop when a disk drive icon is selected) until the new ROMs come out. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
Thomas_E_Zerucha@cup.portal.com (03/03/88)
Perhaps RTX is doing something to fix this, but when I download in the background, I notice the freespace dropping each time I write a buffer to the disk, but the size stays at zero until file closure. There are some other odd things (ARC.TTP will move to the last byte and change the size) and if you hit reset, the allocated clusters will be left hanging, unattached to the file - and undeletable.
Dave_Ninjajr_Flory@cup.portal.com (03/07/88)
Just a small warning if you use Zoomracks II. It will not function with Diskfree. With diskfree loaded ZR will not save to disk. This is real nasty as it will read in your file and then after you have worked on it perhaps for hours, you find you can't save to disk. The first try will rename the original file to backup and create a 0 bytes file. The second try eliminates the backup and makes another 0 byte file. If you don't have a backup of the original file, you are &^()* out of luck.
john@viper.Lynx.MN.Org (John Stanley) (03/12/88)
In article <3728@cup.portal.com> Dave_Ninjajr_Flory@cup.portal.com writes: >Just a small warning if you use Zoomracks II. It will not function with >Diskfree. With diskfree loaded ZR will not save to disk. This is real >nasty as it will read in your file and then after you have worked on it >perhaps for hours, you find you can't save to disk. The first try will >rename the original file to backup and create a 0 bytes file. The second >try eliminates the backup and makes another 0 byte file. If you don't >have a backup of the original file, you are &^()* out of luck. This sounds supiciously familiar, but in my case, I found the problem when trying to do a ymodem-batch download using Flash 1.52. Unfortunately, I was doing the transfer using a Un*x utility that would remove the files from the sending machine when my machine signaled correct reception. I ended up with 5 files, all 0 bytes long and no way to recover... Since I've used Flash 1.52 for batch file transfers in the past with no problems, this seemed very odd. Then I went back to Flash 1.51 and it worked fine. My assumption at that time was that my in-use copy of Flash had taken some non-fatal damage and the 1.51 version was ok... Now it's starting to look like there's a bug in DiskFree... but how DiskFree would have such a fatal effect on renaming a file from Zoomracks is beyond me... One other possibility is that TOS may be cheating when it trys to allocate new sectors. I could see TOS checking some secret counter (possibly one that's suppost to be set by the system diskfree) and saying "nope, no more room" if some special value was found... I know several very knowledgable people at Atari read this newsgroup. Perhaps we could get a little high level debugging help with such a useful utility?? If it is a TOS/BIOS level problem, there's no way anyone but Atari can confirm it. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john
apratt@atari.UUCP (Allan Pratt) (03/15/88)
From article <704@viper.Lynx.MN.Org>, by john@viper.Lynx.MN.Org (John Stanley): > I know several very knowledgable people at Atari read this > newsgroup. Perhaps we could get a little high level debugging > help with such a useful utility?? If it is a TOS/BIOS level > problem, there's no way anyone but Atari can confirm it. I forget if I actually responded to the original article -- I think I did. Part of the problem with DISKFREE is that it circumvents GEMDOS's internal FAT buffers. There are up to two of these, meaning two sectors of the FAT can be out of date with respect to the data on the media. This will only happen when there are open files on the media which have been extended by GEMDOS writes. But this still doesn't explain the wholesale zero-length file problems, because at most this could account for DISKFREE overestimating by 1MB. If DISKFREE causes a media change somehow, that would do it -- because created, unclosed files get closed with zero length and the handles become invalid (reads and writes return EIHNDL). If your term program is dumb enough not to check the return code from the write, and DISKFREE causes media change on the device, this could be the problem. Failing that, I just don't know. I do know, as a "knowledgeable person at Atari," that this kind of extra-curricular stuff at the GEMDOS level is dangerous: the only place I would want a disk utility (a cache, for instance) is at the RWABS level, which has a well-understood interface with the rest of the system. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
singer@XN.LL.MIT.EDU (Matthew R. Singer) (03/16/88)
I have got to comment on the following from Allan Pratt discussing Tim Purves' DISKFREE TSR program: Failing that, I just don't know. I do know, as a "knowledgeable person at Atari," that this kind of extra-curricular stuff at the GEMDOS level is dangerous: the only place I would want a disk utility (a cache, for instance) is at the RWABS level, which has a well-understood interface with the rest of the system. DISKFREE is probably the most useful utility outside of a disk cache that exists for the ST. Why in hell, a system that was announced with a hard disk takes so f*(&ing long to check disk space is without excuse. We wont even mention the delay in first writing to a new file. Atari has known of this problem since early 1985 and in 3 years has yet to fix it (or almost any other bug for that matter). Any you wonder why support for the ST is dying????? Matthew R. Singer Commnet Systems