========================================================================= (C) 1993 by Atari Corporation, GEnie, and the Atari Roundtables. May be reprinted only with this notice intact. The Atari Roundtables on GEnie are *official* information services of Atari Corporation. To sign up for GEnie service, call (with modem) 800-638-8369. Upon connection type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE and press [RETURN]. The system will prompt you for your information. ========================================================================== ************ Topic 12 Tue Oct 20, 1992 K.GERDES [TraceTech] at 19:41 EDT Sub: Data Diet, Squish II and Data Rescue Welcome to the Trace Technologies customer support area. TraceTech products includes Data Diet, Data Rescue, and Squish II. Please download the demos in the files area. 205 message(s) total. ************ ------------ Category 2, Topic 12 Message 1 Tue Oct 20, 1992 K.GERDES [TraceTech] at 19:42 EDT __________________________ || || || Introducing || || Trace Technologies || || || || A Press Release || || October 12, 1992 || || || -------------------------- Howdy! Trace Technologies is owned and operated by Keith Gerdes. You may be familiar with Keith's commitment -since 1986- to the Atari ST community through his commercial and PD endeavors - including Data Diet, Squish, STuffer and other fine utilities; many of which were distributed by or in association with Double Click Software. The first new software package to be distributed by TraceTech is Data Rescue- 'the complete data recovery solution'. Data Rescue is on schedule for a November 1992 release. Look for a demo to be uploaded shortly after this press release. And TraceTech is the new distributor and point of customer support for Data Diet. I want to thank DC for nudging me out of their "nest", giving me the opportunity to fly on my own. Version 2 is scheduled to ship in December 1992 as both an upgrade to current owners and as a new package- product announcement with full details in November. Also, please watch your online service for any change regarding the Data Diet support area. TraceTech looks forward to serving the ST userbase by producing the advanced software you've come to expect while striving for excellence in support. Oh, by the way, a glimpse into the first half of 1993 yields at least two more new products! Thank you for your valued support. Keith Gerdes, TraceTech "Just call me the new old kid on the block..." :^) ---- Contact methods: > Mail Trace Technologies PO Box 711403 Houston, TX 77271-1403 > Phone (713) 771-8332 [weekdays 1PM-5PM Central Time] > Online GEnie: K.GERDES ---- Reprint notice: Permission to reprint this document is granted as long as it's done in entirety. ---- This press release, file #26110 Data Rescue demo, file #26125 ------------ Category 2, Topic 12 Message 2 Tue Apr 20, 1993 K.GERDES [TraceTech] at 20:01 EDT Squish II Sneak Preview [April 20,1993] ======================= Trace Technologies Program by Keith Gerdes [] Windowed GUI + Dialog boxes presented in a windowed format. + Advanced user input Formdo with keyboard equivalents. See the Data Rescue demo for an example [] Compressed executables converted by Squish II + Squish 1.0/1.1/1.2/1.4 + Pack + PFX/LZS2PFX + Pack ICE + Fire-Pack + Pompey Packer + BAPack [] Compression Factor (CF) A value from 0 to 9 can be inputted. This adjustment varies the compression routine. Using a value of 0- fastest compression, least file reduction NOTE: CF0 produces files smaller than Squish v1.4 with a ~3x faster compression routine. Using a value of 3- approximately equivalent to PFX size reduction, though Squish II is faster of course. Using a value of 9- slowest compression, best file reduction [] Turbo mode [] Revised uncompress loader + Smaller + Faster + Squished ACCessories are compliant with memory protection. NOTE: Most executable compressors, if they even support compressing ACCs that is, will fail in this regard. + No more message printout- ie 'Squish-FILENAME'. [] Batch mode Batch operations now work recursively. In addition to files in the current directory, files in sub-directories are searched for too, allowing you to compress the contents of an entire drive or folder. [] Include extenders + Extenders are filtered by 'include' logic. Default list- PR?, AC?, APP, TOS, TTP, GTP + Easy user entry and editing of 16 extenders total. Only files with an extender matching an 'included extender' can be squished. This feature helps to alleviate the accidental compression of your hard disk handler and any other "non-Squishable" executable file. [] Excluded filenames + Filenames can be specified as excluded from Squishing. + Easy user entry and editing of 48 filenames total. This list is comprised of files that should not be squished or files that you do not want squished. For example, self-configuring programs. [] Intellisearch [] Improved memory allocation [] Realtime readouts The percent remaining and percent squished readouts have been junked. Replacing them is a "realtime graph" of the Squish/unSquish operation in progress, which is graphic resolution independent. Now: No VBLANK routine required and no Line-A references remain. [] FAST bit During a Squish operation, you can choose: a) Set FAST bit b) Clear FAST bit c) Keep the FAST bit as-is [] Other filters during Squish + Skip Squish + Squish only + No Compression Factor Update [] Keep TIME/DATE Stamp option [] Commandline support ==== Upgrades from all previous versions of Squish v1 will be available. This covers versions included with DCUtilities, Data Diet v1 and Data Diet v2. If you are either [1] a DCU owner -OR- [2] a DDv1 owner that has not received a DDv2 flyer, then make sure you are on the mailing list for the Squish II upgrade notice. Further details will be made available with the Squish II DEMO release. ==== Contact methods: [] Mail Trace Technologies PO Box 711403 Houston, TX 77271-1403 [] Phone (713) 771-8332 [weekdays 1PM-5PM Central Time] [] Online GEnie: K.GERDES [CATegory 2 TOPic 12] ==== Reprint notice: Permission to reprint this document is granted as long as it's done in entirety. ------------ Category 2, Topic 12 Message 3 Mon May 10, 1993 G.KICHOK [Gerry K] at 01:14 EDT Well it happened again, I let my work disk, drive C, get overcrowded again. Less than 700k free. Then I logged onto GEnie using Aladdin, did my Autopass collecting all the marked messages I hadn't read in a week and BAM! Disk full end of Autopass, quit Aladdin, watch Datadiet report the files being compressed, and reboot clean getting ready for a Diamond Edge session. The Datadiet auto program reports nothing to clean-up. I run Diamond Edge and find 706 lost clusters, which I fix. Then I check the Lost cluster files to see if they match the Aladdin files. I didn't lose any files, only time. Well I guess I should keep drive C maintained better as well as trimming large Aladdin files. Has anyone else with lost cluster associated with Aladdin/Datadiet found this to be the problem also? Brian.H could this be why you kept getting lost cluster? What Datadiet setting do you use when in Aladdin? Last Edited on 08/May/93 at 09:48 Gerry K. - HBO-AUG Librarian Hamilton-Burlington-Oakville Atari User Group ------------ Category 2, Topic 12 Message 4 Mon May 10, 1993 G.FUHRMAN [gnox] at 05:37 EDT Keith, I just noticed something odd ... On my Mega 4 / Syquest 44 system, I have Data Rescue tracking 3 partitions with RESCUE folders: C,D and E. The files are supposed to be deleted every 10 days, and this is happening on C and E, but not on D. Seems like the folder on that partition isn't being maintained at all. I'm using an ICD booter (6.0.7) on the Syquest and wonder whether that could be related to the problem. I've never seen this kind of thing on my TT system where I use HDX5. Anybody else seen this? Maybe I should switch to HDX on the Syquest and see what happens. gnox ------------ Category 2, Topic 12 Message 5 Mon May 10, 1993 BRIAN.H [ST~SysOp] at 21:02 EDT Gerry K, I don't use DD YET [grin]. I use to get the lost clusters quite often. However, now I run DE very frequently. I will be buying DD Real soon now. Brian ... Written on Monday 10 May 1993 at 08:00 p.m. ADT ------------ Category 2, Topic 12 Message 6 Tue May 11, 1993 G.FUHRMAN [gnox] at 05:00 EDT Gerry, Based on my own experience, I'd say anything that opens and closes lots of files in rapid succession increases the risk of lost clusters. That would include Aladdin and Data Diet. There could also be a hardware factor here, as Bob of ORA suggested, because Atari machines (even the same model) can differ slightly in their timing, which makes them hard to support. I saw a suggestion in another topic which I found helpful: set up a small partition just for Aladdin. This really speeds it up, too. Personally, I don't like using Data Diet with Aladdin when the DD work directory is on the hard drive - especially if both the work directory and the Aladdin directory are on the same drive. DD/Aladdin with a ramdisk work directory works _great_, though. gnox ------------ Category 2, Topic 12 Message 7 Tue May 11, 1993 K.GERDES [TraceTech] at 19:45 EDT Gnox, Data Rescue's \RESCUE delete tracking: I will check Data Rescue's auto date purge routine for your drive D skip problem. It's doubtful this is specific to a drive, but rather an option related to the RESCUE folder maintenance. A few queries- 1) DATARESC.PRG file date? 2) Oldest file's date in D:\RESCUE? 3) Total content size of D:\RESCUE? 4) Max folder size setting? - Keith ------------ Category 2, Topic 12 Message 8 Wed May 12, 1993 E.WISNIEWSK1 [Jeff - ST'er] at 14:14 EDT Gnox, I haven't noticed anything like that. What are your settings? How big does the RESCUE folder on drive D normally get?. Is is normally smaller than the ones on Drives C & E?. Gerry, >Well it happened again, I let my work disk, drive C, get overcrowded >again. Less than 700k free. Then I logged onto GEnie using Aladdin, >did my Autopass collecting all the marked messages I hadn't read in a >week and BAM! First thing, never let your disk get that full then run Aladdin. Aladdin does not like a full disk. I have lost alot of my Aladdin files in this fashion. So now Aladdin has it's own 8Meg partition. >I didn't lose any files, only time. Well I guess I should keep drive C >maintained better as well as trimming large Aladdin files. This would be your best bet. >Has anyone else with lost cluster associated with Aladdin/Datadiet >found this to be the problem also? Make that Aladdin only. Or turning off the computer while DataDiet is doing its thing. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Tuesday, May 11, 1993 - 11:08:18 pm ------------ Category 2, Topic 12 Message 9 Sat May 15, 1993 G.FUHRMAN [gnox] at 07:43 EDT Keith, re Rescue / drive D problem, DATARESC.PRG date was 5/08/93. oldest files in D:\RESCUE were 04/13/93. max folder size setting: 3000 K. I neglected to note the size of the folder before I trashed the whole thing (sorry!), but I did notice that it was taking up almost half the space used on that partition, and the 11K partition was about 60% full, which would mean it had probably exceeded the 3 meg limit. Jeff, Drive D tends to have the heaviest traffic of all (on both my systems) - I keep all the text files there, and put any files that need to be dealt with in some way on the root of D. It's also where the Data Diet work directory is, on the Mega/Syquest system. gnox ------------ Category 2, Topic 12 Message 10 Thu May 20, 1993 T.MAGEE1 [Todd] at 19:29 EDT To those who remember me from before when I was posting in the Diamond Edge topic of problems with bombs, and it being a possible problem with Diamond Back 2, Diamond Edge, or DataDiet, well, in my o pinion it was none of them, just my setup. I have put more folders in my HD count, use POOLFIX, set my fastbits OFF. Now I can't get my system to bomb. I have not rebooted in a few days, doing stuff that would definetely have caused my system to bomb before, and now I have no problems. SO, in the end, it was just my setup. Thanks to everyone who gave advice. l8r. .. Todd ------------ Category 2, Topic 12 Message 11 Fri May 21, 1993 A.FASOLDT [Al Fasoldt] at 03:24 EDT Todd, Glad to hear of your success. Them fast-load bits can fast-bomb an Atari in record time... Al ------------ Category 2, Topic 12 Message 12 Fri May 21, 1993 R.ALLAN3 at 08:21 EDT To Anybody, How can you tell if your fastbits are set to on or off? Is there some utility thats shows this setting? If so, could you please tell me the name of it. Thanks Bob ------------ Category 2, Topic 12 Message 22 Sat May 29, 1993 T.MAGEE1 [Todd] at 13:48 EDT I have found a problem with Datadiet v1.0a, though is correctable. I took a .LZH file (EDITH.LZH, found here on GEnie, which is where I got it) on G, uncompressed it to M, then copied it back to G (M is a RAM disk, weird setup of mine, I know). Then I went to Datadiet .ACC to dietize everything. Well, A starts spinning (no light from A though), then datadiet told me "Drive : not responding" (didn't list the drive name, like it should have), so I select cancel, and get 8 bombs "Priviledge violation". Then my system did a total lockup. I reboot. When DD from AUTO runs, it tries to clean all the files from my DD work folder, except "READ_ME.1ST), which tries to get compressed EVERY time a program is loaded. I check DD.TBL folder to see what is there. Well, .TBL is there, along with READ_ME.1ST, and SEAD_ME.1ST, and I have no idea where SEAD_ME.1ST came from at all. I reboot. As long as .TBL exists, it keeps trying to compress that README file, so I try to delete the stuff in DD work folder. TBL erases, SEADME erases (wherever it came from), bu I get a message "Access denied, item either a read only file (which I checked, it is NOT a read file, but a read/write file in the DD work folder) or a non-empty folder". Well, it was NEITHER. I erase TBL (like mentioend earlier), reboot, get rid of README (which for some reason CAN be erased now), and everything is back to normal. What happened? READ_ME.1ST was a READ ONLY file. The only way i found to get around this problem is to turn DD OFF when running my unlzh program. SO no problem. Just turn it off, could do that under the config options on DD2. Just a cautiom to fellow users. Though I wish DD could have solved the problem itself. I also am running Neodesk 3.02, but neodesk allows you to copy/move locked files with no problem (it just asks), so I don't believe it is neodesk. l8r Todd ------------ Category 2, Topic 12 Message 23 Mon May 31, 1993 K.GERDES [TraceTech] at 18:56 EDT Todd, Data Diet created the file SEADME.1ST in the WORK directory when a duplicate access of README.1ST occurred. The first letter is simply incremented by one. Since README.1ST was not a READ ONLY file and you got that "Access denied" alert, I assume that the file was being left open when DD was trying and subsequently failing to clean it out of the WORK dir. When you deleted the DATADIET.TBL file, DD stopped trying to cleanup 'files it knew about' and therefore you were able to delete that README file manually. FWIW, under these rare circumstances you can also bypass the cleanup operation with the modifier key on bootup and then delete WORK dir files. Let me try to recreate the procedure you described. For starters, I'll download EDITH.LZH. Which unlzh program do you use? - Keith [TraceTech] ------------ Category 2, Topic 12 Message 24 Tue Jun 01, 1993 G.KICHOK [Gerry K] at 02:04 EDT Todd, From my own experience always download and extract all files to an UN-dietized piece of drive. Then you can check to see if thing work properly, reset/set fastload, and read/write, flags. Squish the executable file and retry the program. Only then do I move the files to a permanent location, if I want them. Never delete the .TBL file, and try turning Datadiet off when deleting files inside the work folder. Keith, How are the updates/upgrades coming along. After reading the PR about DATAlite from ORA, I will be staying with Datadiet. I prefer the way Datadiet works over the way DATAlite was described, although I'm sure DATAlite will be a good product, just like Datadiet. Last Edited on 01/June/93 at 00:18 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 25 Tue Jun 01, 1993 T.MAGEE1 [Todd] at 09:04 EDT Keith, using the modifier key WILL disable DD right? Cuz I have some stuff that still needs it, that is why I just delete .TBL (not a good practice, I know) then reboot, running NO other programs between deletion and reboot. I used lharc 2.01j by Haruyasu Yoshizaki. Coul dbe the one you use, but check then name too. I wrote it down cause it was there. Oh, yeah, it's a .TTP, not .PRG. If something happens to your HD Keith, don't tell me! :( Also, I'm not trying to slam DD. Anyon etaking it that way is misinterpretating me. Gerry, I own Squish but no longer use it. No problem with it, just me. This where Maxifile comes in handy. :) l8r Todd ------------ Category 2, Topic 12 Message 26 Wed Jun 02, 1993 K.GERDES [TraceTech] at 19:05 EDT Gerry, Near-term project status: Squish II is coming along very nicely. Even I'm impressed at how far it has evolved, which is what counts most! The project is a little behind schedule....but that's normal. ;) I just need to get that last 2% done and finish the manual. Look for a demo to be uploaded soon. The "FILESIZE" update for Data Diet is progressing well and will become the priority effort once SqII is out the door. Thanks for asking. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 27 Thu Jun 03, 1993 G.FUHRMAN [gnox] at 06:49 EDT Todd, As Gerry said, there is NEVER a scenario where it is helpful to delete the .TBL file. - I admire Keith's dedication in trying to recreate your problem; I'd be tempted to simply say "what you need is the current version of Data Diet"! Gerry, So far I'm with you on the choice between Data Diet / DataLite. It looks as if DD is for those who like to customize and fine-tune their systems, while DL is for those who prefer a minimum of user interaction. Even if I was a new customer trying to make a first buying decision, I'd want to see some user testimony on which is more stable - and in DL's case it will be some months at least before the verdict is in. As an `old user', I'm not averse to switching, but it takes a lot to make me switch. (For instance I keep checking out new word processors but nothing has lured me away from WordPerfect yet.) It's not loyalty, just practicality - why spend $$$ and time replacing software that works? On my system Data Diet 2 has proven itself rock-solid (which is more than I can say for WordPerfect, actually). Anybody else out there care to comment on this? gnox ------------ Category 2, Topic 12 Message 28 Thu Jun 03, 1993 T.MAGEE1 [Todd] at 09:10 EDT Gnox, well thank you for your words of wisdom. Recreating the problem is no problem. Take a read only file (not dietized), lharc it, then undo onto a data dietized partition. This will create the problem. According to what Keith said, you get a file in the TBL directory that data diet never closes. Problem caused by data diet, sort of. Recoverable, 100%. Able to not make it happen again, 100%. I only wanted to bring up the fact that this can happen to help others out. I guess some don't appreciate these cautions. Sorry to caution you, Gnox. If DD2 fixes this (which I doubt since it is not DD's fault), then Keith can suggest either updating to DD2 or live with it. I can live with it. I don't need DD2. I have thought about upgrading, and maybe should, but it's $25 for something I don't feel I need. DD1 suffices for me. If it is not DD (which it is not), then getting the current version won't fix it obviously. The reason I don't just reboot without DD to get rid of these files is assumptions, meaning I figured if you reboot without DD, then delete the files, well, DD .TBL will still haves those files listed and still possibly try to do something with them. That is why I just delete TBL and reboot. I take Keith's view on this, which is a no-no to do, but works without damage. DD2 can automatically shut DD off when running certain programs, but so can hotkeys. If that is why I shoul dget DD2, then once again it is not needed. CTRL-ALT-minus works. I have thought about it, but maybe I should drop DD. I could interpret what Gnox said as "Give Keith $25 and he'll be happy to help you, even thought DD2 won't fix it. Otherwise don't make cautions about possible side effects of DD1." Once again, Gnox, thank you for your words of wisdom. l8r. Todd ------------ Category 2, Topic 12 Message 29 Thu Jun 03, 1993 M.MOTOGAWA [MEL] at 10:44 EDT IMO, the $25 upgrade to DDv2 is well worth the price. You get a newer version of DD that has better compression and speed, the datadiet.inf editor so you don't have to manually edit it with a text editor, the vrodisk virtual ramdisk for speedier access to ro'd files, 3 new datadiet.inf sections with automatic control of 7 of Data Diet's parameters on the fly when you boot programs thus the ability for creating custom setups for each, a (much) faster fsnext original size routine, the Reserve feature for reserving extra ram when running ram greedy prgs so you can use desk acc's within them, enlarged statistics in the datadiet.acc, you can call up the datadiet.inf editor from within the datadiet.acc, you can now edit the datadiet.inf settings in ram and have them take effect without rebooting, new Filters section in Data Diet Tools for fine tuning its actions, a new manual addendum and many other little refinements throughout the various datadiet programs. The better compression and speed, over version 1, would have sold me on the upgrade by itself. :-) I always like staying current with my well-used software since it usually means a smaller jump, dollarwise, when the next version comes out. - Mel ------------ Category 2, Topic 12 Message 30 Thu Jun 03, 1993 K.GERDES [TraceTech] at 19:05 EDT Todd, Modifier key: Per the Data Diet 1.0b update- Right before DATADIET.PRG runs in the AUTO folder, hold down the key to bypass the WORK directory cleanup on bootup. There is no "disable" key. Squish: Since I'm currently finishing up Squish II and you say that you no longer use Squish, do you have any feedback that you'd like to give? - Keith [TraceTech] ------------ Category 2, Topic 12 Message 31 Thu Jun 03, 1993 T.MAGEE1 [Todd] at 21:45 EDT I'm not saying the upgrade is or isn't is well worth/not well worth the price. I was stating that the problem I created will still be created in DD2, thus making DD2 not a solution. The disable key I talked about was CTRL-ALT-minus, which shuts data diet off. I will admit I have only v1.0a, not 1.0b. If you don't know about the hot keys for original/dietized sizes (C-A- left bracket/right bracket), and data diet on/off (C-A- -/+) keys, then I don't understand how you could be supporting it. I know you know of them, miscommunication. I have not had problems with Squish. It is just choice. I did have a problem with either Diamond Edge or Diamond Back 2 when squished, but I don't want to talk about that, as I am sure a bunch of messages are going to the Diamond topics right now letting them know I am bashing their products, as the opposite has happened before. What I don't like is making comments on a product and having people not answer, or tell me to send $25 when the upgrade won't solve the problem mentioned, and then stating that they would feel this way or that way if they were Keith. Okay, I look at it this way: If Keith wants to look into it, he should say so, which he did. If he doesn't then he should say he won't or to upgrade or something. He says he will check it, then another user posts a message suggesting that if he were Keith he would tell me to upgrade. Friendly message from a fellow user to me. Okay, I will upgrade in June/July to settle this, as soon as I am sure I have $25. With the way I have been, I hope Keith still lets me upgrade. If he doesn't then that's not being business like and then I'll not support any of his products. But I'm not going to state how some software producer should handle situations. But what when I get DD2 and create the same situation/problem? I will be told to have DD auto turn off when lharc is run. Good. But I still wish that DD could take care of the situation itself. Neodesk does. It just lets you know it is a read-only file, and do you really want to copy/move it. DD is a pretty significant piece of software, and should in my opinion be able ot get around those problems. I novice user could obviously be puzzled to heck as to what just happened, and how to fix it. User-friendly is my point. Knowledgeable user would have no problem, but not everyone is. I will stop this bickering because I probably started it, but I do want to end it. I will not erase what is above, but will not continue it either. The next little bit I will be serious and non-sarcastic about. To clarify earlier, the reason it would be nice if DD could get around that read-only file problem is because of user-friendliness. It is a sophisticated piece of software. Meaning I could take it to work (don't worry I'm not pirating to work, just a rhetorical situation they run IBM's anyway), set it up for my supervisor and let it go. It would run fine, but she wouldn't know how to change anything, but yes it would run fine. But what when she runs something and has what happened to me happen, with the LZHed read-only file. If DD was NOT yet set to turn off DD in that program, then she'd see there was a problem and have NO IDEA why or what to do about it. Then the focus would go from work to what is wrong. Then I could fix it, but she'd never understand why what happened happened. Perhaps sophisticated stuff is only for sophisticated users? I mean that as a literal question. I have thought about taking off DD because of speed and choice. NOT problems. I have heard speed is improved in DD2, and after all this, I almost feel I owe it to Keith to upgrade to check the speed. Also, to me my system is a toy, wish it were more, but at this time pretty much is. A few games (OWNED), aladdin, text editors. A system like this doesn't really need DD. Reason for not using Squish? Not sure if this could happen, but didn't want to take the risk. Meaning, I have no virus detection stuff (have ordered UVK, and am wondering WHERE IS IT!?!?! Since it has been shipped, I better get it next week at the latest), so I fear getting a program that has a virus, then Squishing it. The virus is still intact when the squished program is loaded, but if you took UVK to look at it, all it would see is the unsquished program at the beginning of the program. If I am right, that is the only thing it can find that is executed without modification. So UVK would see no viruses, though all your squished oprograms could have it. If I am wrong I apologize, but I can't see how this could NOT 100% NOT happen. Not squishes fault, not anythings fault. l8r Todd ------------ Category 2, Topic 12 Message 32 Fri Jun 04, 1993 G.FUHRMAN [gnox] at 07:29 EDT Todd, Whoa there! I didn't mean to criticize you for posting about the problem you've run into; I just commented that Keith was going the extra mile in checking it out. As Mel said, there are _lots_ of reasons to upgrade ... turning DD on and off automatically is only the tip of the iceberg of control features added in DD v.2. Whether v.2 would prevent the sort of thing you're talking about is a question I haven't found time to think about in depth, so I'll leave that to Keith. To me, version 1.0a is a distant memory, and my memory isn't all that reliable at the best of times. :) By all means report any DD problems you come across. That's what this Topic is for. gnox ------------ Category 2, Topic 12 Message 33 Fri Jun 04, 1993 K.VANDELLEN [Ken Van] at 07:31 EDT gnox, I'm for flexibility. I wonder if bman's request for a change in MaxiFile to keep eliminate the decompress and compress on moves wouldn't also eliminate some flexibility. What if I want to move to a floppy, and not keep the file compressed? It might be better to be able to turn this off and on (or DD off and on), than to be locked into having to keep the compression. A question about Todd's problem would be, is this a problem that exists only with DDv1? Ken Van Dellen d8^) ------------ Category 2, Topic 12 Message 34 Fri Jun 04, 1993 M.MOTOGAWA [MEL] at 20:06 EDT Todd, I noticed there is an update patch in the file library, file #22479, that will take your DD 1.0a to 1.0b status. I can't remember what all it adds/fixes, and no guarantee it will solve your problem with the read only file situation, but, since it can be had for the price of a d/l, it can't hurt and gives you a free update to a newer version. - Mel ------------ Category 2, Topic 12 Message 35 Fri Jun 04, 1993 T.MAGEE1 [Todd] at 21:46 EDT Mel, thanks, I'll grab it. I will be getting DD2 now anwyays. At times I want speed in compressing stuff, sometimes I want better compression. Meaning I should check DD2 and Squish 2. Also, when I mentioend I had a few things not like Squish (or something happened when squished), and I mentioned I believed it was Diamond Edge that Had a problem, well I realize that was BEFORE I changed my setup. Now that my machine works great, I should retry squish and see what happens. If it is okay when squished now, I apologize to both ORA and Trace Tech. I would want two things out of Squish 2: more compression (if even possible, squish is good), and a batch squish operation that goes INTO all folders and such, like DD does. If squish can do this then I missed something. As far as I understand it will do what is in the current folder by using "*.*" as the filename, but not go into folders. Todd ------------ Category 2, Topic 12 Message 36 Fri Jun 04, 1993 M.MOTOGAWA [MEL] at 23:39 EDT Todd, While you're d/l'ing the 1.0a->1.0b patch, take a gander at file #28487 for a sneak preview text file listing some of the features in the new Squish II. It not only compresses better and has batch features, but it also has a _ton_ of other neat stuff. Don't read this file if you have a weak heart, the list of goodies may send you into palpitations! You have been warned. :-) I've never encountered any problems with running Diamond Edge squished. - Mel ------------ Category 2, Topic 12 Message 37 Sat Jun 05, 1993 G.KICHOK [Gerry K] at 02:25 EDT GNOX, For sure, DataDiet and DATAlite will appeal to different types of people. I hope DEMO's of both product will be available so that people can get the feel of them and find out what _THEY_ prefer. As for WP, I've been using WP 5.2 for Win and I'm hooked, imagine what they could have done, WP 5.2 for Falcon030. :) Todd, Virus detection of the quality I have on my windows system is needed for the Atari, I'm just glad that there aren't as many virus's as on the IBM's. For protecting EXECUTABLE files one program called PROTECT6 runs in the AUTO folder and notifies you if ANY program tries to modify any other PROGRAM file. I think it's here on GEnie, if you can't find it and you want it, I'll upload it. Last Edited on 05/June/93 at 00:08 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 38 Sat Jun 05, 1993 T.MAGEE1 [Todd] at 04:21 EDT Mel, will get that text file also. Think my setup must have affected squish/DE then. I am not blasting either software, just stating my prior experiences, which were setup problems. Protect6 sounds neat, but won't the CPX module and other stuff in UVK do the same? ------------ Category 2, Topic 12 Message 39 Sat Jun 05, 1993 G.FUHRMAN [gnox] at 06:52 EDT Ken, > I wonder if bman's request for a change in MaxiFile to keep eliminate > the decompress and compress on moves wouldn't also eliminate some > flexibility. It definitely would, which I suppose is why Bman originally suggested it as an _option_ in MaxiFile. It's not one I would use - even on my hard drive I have several partitions and directories excluded from dietizing. I wouldn't use the custom copy utility that John E. suggested either (even if Keith went to the trouble of creating one) because it would be a nuisance to copy files with one utility and do all the other file maintenance chores with another. It's so much simpler to use the DD hotkeys, and there's no penalty for forgetting, except a few seconds' delay. Todd, I've also been using Diamond Edge squished with no problems. (I don't use the Mirror part though, as I prefer Data Rescue.) And Mel's right about Squish 2. The demo will be out soon, and you're gonna love it! gnox ------------ Category 2, Topic 12 Message 40 Sat Jun 05, 1993 M.MOTOGAWA [MEL] at 10:58 EDT Oh, that's right. Gnox brought up a good point. _Don't_ squish the auto folder program Dmirror.prg, that is a part of Diamond Edge, since it needs to be in a normal uncompressed state to work properly. But you can squish Edge.prg, the main program. This follows the same genre as programs that save configuration information to themselves (unless they support the Squish Offset Protocol). They must be in an uncompressed state, no matter which compression program you're using, to save configuration info. to them. Then you can compress them (but remember to uncompress the next time you save config. info.). - Mel ------------ Category 2, Topic 12 Message 41 Sat Jun 05, 1993 K.GERDES [TraceTech] at 17:39 EDT Todd, Before posting a preliminary status report, I was hoping to have a final (re)solution to the "Read Only" problem you ran into. But since this has gotten totally out of hand [ seems to haunt DD :) ], I'll fill you in... Right after you posted which archiver you use, I was able to recreate the scenario. That particular archiver maintains file attributes of stored files. The README file was set to Read Only. When Data Diet needs to dietize a pending file, the place holder file is deleted and replaced by the compressed version. Since the pending file was Read Only (not to be confused with the DD RO setting), the dietize process was aborted and the WORK version was left in place as part of the safety procedure. Note, DD should have removed this file entry from the TBL file to avoid the cleanup problem. And you are quite correct that the problem exists in DDv2 too. The v1.0b update was released in late Jan. 1992. The v2 upgrade, an extension of v1, was in parallel development since the Oct. 1991 debut and ready in April 1992. What caused the delay to Dec. 1992? That's part of history... ;) I have added the lines of code to address this situation. The revised _v2_ DATADIET.PRG is being sent to beta testers. For DDv1 owners, I am in the process of trying to make an update available for its last version- the 1.0b package. Not an easy task, but hopefully doable. Seems kind of odd that it took so long (>1.5 years since release and >2 years in development) to finally come up. But that's how things go sometimes. Hotkeys: Me not know about the hotkeys? Definitely miscommunication... ;) We were talking about the WORK dir cleanup process. The v1.0b update, which you did not have (sorry, my mistake), added a keypress to bypass that process on system bootup. You were asking about a disable key for bootup. There is no such key. The hotkeys that you mention are for controlling DD during normal system usage. I generally refer to them only as a _manual_ reference since I like the user to read all about them and the key assignments. DDv2 upgrade: There are no pressure tactics to upgrade from v1 to v2. Mel and Gnox were simply giving friendly user advice. They have used Data Diet for awhile are quite satisfied with it. Go figure. :) If you will look at Gnox's message about word processors, even he has stuck with a product that gets the job done. And in your case, DDv1 does just that, so there is probably no reason to move up to DDv2. It's up to the individual to evaluate the benefits of an upgrade, while keeping in mind the cost involved. TBL file: Deleting the TBL file and manually cleaning up the WORK directory -both of which will do _NO_ harm- was the only "work around" for what you ran into. And that is why the bypass method was added in 1.0b. True, the WORK dir is supposed to be off-limits since DD is supposed to be self-maintaining. But under certain rare circumstances, you may have to open that folder and do some tinkering. However most users will find that there TBL file has been on the drive a _long_ time, and the WORK directory has _never_ been worried about. Gnox's words of wisdom: I interpretted his comment (not advice mind you) as one of "Keith going the extra yard to support a product not sold by him"; _NOT_ as you stated "keep quiet, be satisfied with what you've got v1 owner". This TOPic is to support Data Diet- v1, v2, etc. The official DDv1 TOPic was neglected (and now closed) and I felt that I should pick up the ball. Did I have to do this? Nope. I could have easily restricted this to DDv2 since I am finally getting fully compensated for my efforts. I don't push the DDv2 upgrade on anyone. Flyers were sent out to the registered users on my list (sadly, a fraction of the total BTW) informing of the new support point and the upgrade availability. Questions, comments and feedback regarding _all_ Data Diet versions are welcomed and will be welcomed as long as this TOPic exists. Squish: I think the program in the Diamond Edge package that should not be squished is DMIRROR since that program writes configuration info to itself. I believe there was also a problem when updating a squished ORA file, but I think that was subsequently addressed. Squish II adds a user-definable list of excluded filenames. A text file will be included on the disk with a sample of names. Squish II: Squish II does have better _AND_ faster compression than Squish v1. Plus all operations are now recursive- ie go into sub-directories. UVK: "have ordered UVK, and am wondering WHERE IS IT!?!?! Since it has been shipped, I better get it next week at the latest" Come on, let's not have someone think I have anything to do with your UVK order! :) I'm not connected with that product in any way. Squished files: "squishing a virus infected program" If you have a virus detector that can detect a virus associated with _executable_ files (ie the infamous link), then it would be advisable to 'scan' files before squishing them. I'm not sure if virus detection programs handle a squished file specially. Uncompressing the original file and examining the contents would be a simple matter. Look at all the unpack programs that can UnSquish. So even a squished file's original data could be scanned. - Keith ------------ Category 2, Topic 12 Message 42 Sat Jun 05, 1993 T.MAGEE1 [Todd] at 19:38 EDT WOW! i didn't expect you to necessarily fix it, but just norice it can happens. I underestimate your support. Odd it took two yuears for someone to bring it up? I believe you, and makes me wonder why a person would make a readme file a read-only anyways. Also, I found the patch for DD 1.0a to 1.0b to be confusing. Guess I should print otu and read the TXT files again. But if I get DD2 updating from a to b will be unnecessary anyways. What will DD now do when it comes across a read only file? Turn the read only off? I didn't know about the WORK dir cleanup thing. Shoulda had a 1.0b! I also worried about squishing programs that saved stuff tio themselves without the offset protocol. Easy to fix, but possibly puzzling at first. I do find Squishx/DDx to be a great idea for floppy users. Saves time in my opinion. My floppies are squished/DDed because of that reason. Also partly reason why DD1/squish1 have sufficed for my usage. Oops, yes, that product should not have been mentioned, but is important. I also was complaining about the shipping service, NOT the software producer. Sorry if that was misinterpreted. Keith may have to do with any Trace Tech. order though. :) The reaosn i am concerned about viruses now is because a friend of mine and me swap stuff around a lot (graphic demos, utilites found on Atari Archive, miscellaneous but PD), and he found not too long ago he had a virus and 75 of his disks were infected! That's why I'm concerned. I finally read about squish2, and it also, like DD2, sounds very sophisticated. But very flexible at the same time. I just hope my (be it overboard) observations have made DD a bit more bullet proof. Todd ------------ Category 2, Topic 12 Message 43 Sun Jun 06, 1993 T.MAGEE1 [Todd] at 01:53 EDT Keith, I used DDUPD10B to update from 1.0a to 1.0b. Didn't work, because I already have 1.0b without knowing it. I know this because the CTRL at bootup to make DD NOT clean out the WORK dir worked, where this option is not there in 1.0a. Todd ------------ Category 2, Topic 12 Message 44 Sun Jun 06, 1993 K.VANDELLEN [Ken Van] at 23:41 EDT Todd, Glad you picked up that Read Only bug. Keith's support is right up there with the best. Ken Van Dellen d8^) ------------ Category 2, Topic 12 Message 47 Tue Jun 08, 1993 K.GERDES [TraceTech] at 19:41 EDT Todd, DD 1.0b update: Ooops, my mistake. Sorry you wasted your time with the download. I should have mentioned that the update is to Data Diet _package_ v1.0b. You could have checked the 0 byte file to see what version you had. Package v1.0a - only updated DATADIET.ACC to v1.0a. Package v1.0b - updated all modules - DATADIET.PRG became v1.0a. This was confusing at the time, so in the future I'll try to avoid skewing the version of the main program from the package version. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 48 Wed Jun 09, 1993 G.KICHOK [Gerry K] at 01:32 EDT Has anyone else had Aladdin start acting up lately with Datadiet v.2. Two AutoPasses ago I had a bunch of lost cluster left on the drive were my DATADIET.WRK is located. There was the undietized ATARISTR.MSG file in it's complete form plus another file I couldn't identify. Then after the last AutoPass I found ATARISTR.DAT in my DATADIET.WRK directory! This is IMPOSSIBLE because I have all DAT files marked to NOT dietized. So I checked the ALADDIN directory and ALL the .DAT files were dietized. I undietized all the .DAT files and will report if they again become dietized. I have TOS 1.4 and on a 520ST with ZRAM 2.5 megs and a MEGAFILE 60, and I always exit any programs before turing my computer off, (alway exiting NeoDesk 3.03 LAST before switching off). Last Edited on 08/June/93 at 23:25 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 49 Wed Jun 09, 1993 T.MAGEE1 [Todd] at 02:06 EDT No problem. Was confusing though. Is there anything between DD1 v1.0b and DD2? Or is the next update step to go to DD2? I believe so, just making sure. Is the fix for the read-only (bug?) done with testing? i think you mentioned giving it to beta-testers. If so, I will wait till it is done testing before I get DD2. Mayube I don't feel I need DD2 now, but I could in the future. Also, because you really seem to support your osftware very well, the read- only fix being a good example. Would that be considered a bug though? When and how much is Squish2? I noticed something unexpected from DD. I turned find next file to original size, checking to see how long it would take to read folders when going into them. Of course I noticed the bigger the folder the longer it took. Then I noticed it did it with my Aladdin folder, which is not dieted and is excluded int eh datadiet.inf file. If you want another little project (nobody shoot me!), how about having data-diet nor bother to check original sizes in a folder that is excluded anyways? I don't know if that has changed in DD2 of course though. I just realized you coul dhave a dietized file in a exlucded folder, but I don't see why you/d want to, but to keep it running okay, you'd have to check all the files. Never mind... Todd ------------ Category 2, Topic 12 Message 50 Wed Jun 09, 1993 G.FUHRMAN [gnox] at 06:26 EDT Todd, Yes, I'd call it (the read-only thing) a bug, and you should be congratulated for finding and reporting it, considering that the beta testers all missed it (for two years!). It's a fairly tiny bug, true ... but it's so seldom that bug reports turn up in this Topic! Just goes to show that the loose talk one occasionally sees elsewhere about DD "horror stories" is exactly that: loose talk. As for copying files, that's what we were discussing a few messages back ... when you want to copy dietized files and keep them dietized, or copy normal files and keep them normal, the quickest way is to turn off DD with the hotkey just before the move, and then turn it back on afterwards. It doesn't hurt to have dietized files in a folder or partition that's excluded. DD will still read them properly. New files written there will not be dietized, that's all. Gerry, If you have DAT files excluded, the only way I can see them getting dietized is if DD couldn't find its INF file on bootup for some reason, or you changed the INF in memory after booting. If you can reproduce this you've found a bigger bug than Todd's, I'd say! By the way, after trying Aladdin many different ways, I've found that the best (for me) is to give it a little partition of its own which is excluded from DD (and not tracked by Data Rescue). This way there's never any delay upon exit from the program, and never any lost cluster problems, at least on my system. I back up that partition once a week or so. (Of course I won't mention how I messed up my hard drive in the process of creating that little partition ... :) gnox ------------ Category 2, Topic 12 Message 51 Wed Jun 09, 1993 M.MOTOGAWA [MEL] at 10:51 EDT Gerry, I haven't had any lost cluster problems with DDv2 and my Aladdin partition. If you find your .dat files becoming dietized when you thought they were excluded, you might also want to call up the INFo Editor and check out the Compression Type for Extenders/Paths sections. At the bottom of p. 18 of the v2 manual addendum, it describes how one is recursive, but the other is not. It could cause what you're describing without your being aware of it. Hope this helps. Thanks! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A tip for all Aladdin/DD users: If you're getting tired waiting for files to dietize after exiting Aladdin with Terminate/Type B, you can try switching to Terminate/Type A, Realtime/Type B, Realtime/Type A, Realtime/Type A and a ramdisk work dir., getting DDv2 if you haven't already (since the speed is better), excluding larger Aladdin files or excluding the whole folder for the best speed possible. - Mel ------------ Category 2, Topic 12 Message 52 Thu Jun 10, 1993 K.VANDELLEN [Ken Van] at 07:54 EDT Gerry, If you're using DD, but have the DD ACCs in MultiDesk Deluxe, and then boot with MDD disabled in order to save memory, your INF file will be inoperable. Ken Van Dellen d8^) ------------ Category 2, Topic 12 Message 53 Thu Jun 10, 1993 K.GERDES [TraceTech] at 20:21 EDT CT Fest goers, Craig Harvey @ Clear Thinking will have TraceTech's current offerings in his booth this weekend. Drop by and check out the show specials on Data Diet v2 and Data Rescue, _plus_ the Data Diet v2 Upgrade will be available. Oh, BTW, you may also get a sneak preview of Squish II... ;) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 54 Fri Jun 11, 1993 G.KICHOK [Gerry K] at 02:15 EDT gnox, Tell me more about you partitioning pitfalls, I am currently thinking of reorganizing my megafile 60. Do know if it is true that you can only have 4 partitions at the most using AHDX 5 on a single drive. I'm thinking: C - 10 megs bootup and fonts D - 5 megs for TEMP files and DATADIET.WRK dir E - 30 megs work dir F - 15 megs for Aladdin, STalker, BB saved messages, and dls I will monitor for dietized .DAT files and lost clusters after AutoPasses and exiting Aladdin, and if I find dietized .DAT files I will check to see that the DATADIET.INF file is currently in memory. Mel, It's really a kick in the teeth, every month as I get my Clubs library disks together, Aladdin/Datadiet start getting temperamental, this may be due to having a very full drive. Having Compression Type for Paths, I wouldn't think would cause a file extension that is excluded to be compressed. I don't know what would happen if I had the Extenders set to DAT:B compression. What I have done: I had Exclude Path F:\ALADDIN\ then I removed that from good advice here. Let Datadiet treat it like any other folder and used Datadiet Tools to dietize *.* to B inside the folder and subdirectories. Slow. Then I had Datadiet control by filename Default compression set to A from the normal B and Use type-X filesize > 50k. Tried it didn't like it, I thought it might make Datadiet a little faster since most of my files were under 50k. I then removed that configuration and again used Datadiet Tools to change any files that dietized A to dietized B. There are no special settings for Datadiet NOW but I due have .DAT files excluded. Thanks for you help, are you suggesting an alternative Terminate/Type A with the Compression Type for Path or set in the compression type Controlled by the program? Last Edited on 11/June/93 at 00:36 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 55 Fri Jun 11, 1993 A.FASOLDT [Al Fasoldt] at 07:40 EDT Gerry, AHD is limited to four partitions, unless the very latest version is different. If you want to minimize the C: partition, why not make it smaller than 10 megs? I ran for years with a 1-meg partition, but I'm sure that's too small these days (with boot managers and a lot of DAs and sound files); a 2- to 3-meg C: might be ideal. Al ------------ Category 2, Topic 12 Message 56 Fri Jun 11, 1993 K.VANDELLEN [Ken Van] at 07:55 EDT I gave out some misinformation here, previously. The modules do not have to be enabled for DD to read the INF file. Ken Van Dellen d8^) ------------ Category 2, Topic 12 Message 57 Fri Jun 11, 1993 M.MOTOGAWA [MEL] at 10:44 EDT Gerry, One thing to keep in mind,when using the INFo Editor, is what's mentioned in the manual addendum about it, that some sections of the INF file take priority over others and some area operations are recursive and some aren't. Until I discovered this, I was wondering why some files weren't getting compressed when I thought they should, etc.. What I do with my Aladdin setup is to use the DD Control by Program Name section of the INFo Editor to force my Aladdin sessions to Type A compression and Realtime mode. My online sessions proceed well and I exit instantly. The saving of messages and topic/file lists (.msg, .dat, .top) with type A compression, as Aladdin visits the msg base and file library, only takes a few extra seconds, which is no biggie to me. I'm using a ramdisk (Codehead Ramdisk) for a work directory, which also speeds things up a bit (and it's a reset proof ramdisk). - Mel ------------ Category 2, Topic 12 Message 58 Fri Jun 11, 1993 K.GERDES [TraceTech] at 19:06 EDT Gerry, Aladdin and Data Diet: I can put in my 2 cents....that's all it's worth to some. ;) During pre-DDv1 development, there were alot of problems encountered when Aladdin was run due to its intense file usage. This got ironed out in short order and I have found no problems with any Data Diet versions since DD's release. All of my Aladdin folder is dietized. There has been no files left in the WORK directory. And there have been no files or clusters lost on the WORK drive- 0 "defects" on that drive. What does this all mean? Not much... :) I would periodically run your "drive check" program after Aladdin or any other program which you think have data files related to your lost clusters. Excluded DAT files: You should first normalize files you want to exclude in DATADIET.INF, since a) newly created files follow the configuration settings you setup and b) currently dietized files that are only modified, stay as-is. I assume you just added DAT to the 'Excluded extenders' INF section. Todd, Versions: The latest version of the Data Diet v1 package is DDv1.0b. The next step, an _UPGRADE_, is to go to Data Diet v2. Read-only files: Beta testers have been using the "fixed" version of Data Diet v2 for a few days. How long before the availability of a v2 patch update?- undetermined at this time. Changes like this must be thoroughly tested... Please don't let this be an excuse for putting off DDv2. The update will be available as a patch, similar to the old v1.0b patch update. Classification: Yes, this would be considered a bug. Are you satisfied? I call it an oversight that has been hidden for >2 years, but a problem nonetheless. Some programmers have a hard time calling software flaws "bugs"- that's why other descriptors are used. Myself included. I consider bugs as typos, logic errors, (stupid) mistakes, etc. Squish II: Squish II's "last" beta release is in the hands of testers. I've been working on the manual and when it's completed -this month hopefully-, there's another short delay waiting for the printer. Look for Squish II to ship in July. The "upgrade" price from Squish v1 to Squish II is $20. Final pricing for each upgrade type (DDv2, DDv1 and DCU) has not been determined. Most likely Data Diet v2 owners will get a discount. This will all be spelled out in detail by the mailout notice before final release and maybe in the demo version this month. The MSRP is not finalized. Little project: [Find next file in excluded folder?] You seemed to answer your own question. Thanks! I wish more tech support was this easy... ;) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 59 Fri Jun 11, 1993 G.KICHOK [Gerry K] at 23:45 EDT Ken Van, I always make sure I have ONE version of DataDiet loaded, ussually in MDD resident. But I wonder if I had say Spelling Sentry a MDD resident left open, would it block the pipeline to other accessories such as DD. Last Edited on 11/June/93 at 22:13 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 60 Sat Jun 12, 1993 T.MAGEE1 [Todd] at 01:47 EDT Keith, I never called it a bug. Oversight sounds right. I only questioned others opinion of what it was. As long as the patches are easy to install, no problem. I know you are busy Keith, but I have always used B-compression for max comp. How faster/more-comp. can I anticipate DD2 to be? Hard to answer I know. I do know DD and Squish are great ideas for floppies. In the time it would take the read the whole thing, it is already read and decomp. One definite reason i have never dumped either. Wow, I didn't think (seemingly) little changes can be so delicate to have to test. Shows you are definetely NOT going to put out something that has problems, or even creates more. I'm very impressed with your support, Keith! :) Do we have to send in our disks to get Squish2? If so, I'll just send what is needed for Squish 2 when I send the disk to go from DD1 to DD2. Or would that be bothersome to keep track of? Eagerly awaiting! This has nothing to do with Trace Tech., but I have it with Aladdin that when I type every once in a while a window that comes that says "really abort?" That comes up when you hit UNDO, but my hand is not near UNDO. Seems to happen when I am typing on keys on the right side of the keyboard, but I am positive I never have hit UNDO. Aladdin problem? Atari problem? Dunno, but it happened twice in writing this message. Todd ------------ Category 2, Topic 12 Message 61 Sat Jun 12, 1993 G.FUHRMAN [gnox] at 07:01 EDT Gerry, You don't need to have the DD accessory resident. It has nothing to do with the _operation_ of DD - just allows you to change the setup on the fly. I always use it as an MDX myself, as it loads real fast. My partitioning problem was described in the Diamond Edge topic last week; I tried to split a partition into two without affecting the other partitions, and you can only do that in certain circumstances. You _can_ have more than four partitions on a drive if you have Diamond Edge and (I think) a recent TOS - don't know how recent. For your 50 megs, I would recommend one for Aladdin (3 or 4 meg at least) and one of maybe 5 for the DD work directory (neither one used for any other purpose). My own setup now is 15 megs each for C-E, 6 for F (Aladdin only), and work directory on the root of G. But then I have 260 megs available all the time. :) gnox ------------ Category 2, Topic 12 Message 62 Sat Jun 12, 1993 K.VANDELLEN [Ken Van] at 08:36 EDT Gerry, I'm not competent to answer your question, but I'll bet someone else here is. Ken Van ------------ Category 2, Topic 12 Message 63 Sat Jun 12, 1993 M.MOTOGAWA [MEL] at 10:38 EDT Todd, Yes, Squish is doubly great if you're booting up your system off a floppy. I recall that it was quite a bit faster when the prgs in your auto folder and the desk acc's were squished. Would no doubt be the same speed increase when accessing large data files since some of the reading is from ram, which is much faster than floppy access. Another cool thing about DD is that when backing up your hard drive to floppies, you can turn DD off and drastically cut the number of floppies needed for a backup, since you're now copying compressed files to the floppies. - Mel ------------ Category 2, Topic 12 Message 64 Sat Jun 12, 1993 BRIAN.H [ST~SysOp] at 17:19 EDT I use AHDX 5.0 and I have partitions up to "H". I keep Aladdin on a separate partition and this cuts down on the number of DE runs I must do. ~~~~Brian ... Written on Saturday 12 June 1993 at 04:15 p.m. ADT ------------ Category 2, Topic 12 Message 65 Sun Jun 13, 1993 G.KICHOK [Gerry K] at 02:34 EDT Mel, "Some sections take priorities over others" what part of the manual are you refering to. Is there a list of operation priorities somewhere? Keith, Thanks, I think that the .DAT files were previously dietized and so, remained dietized, and I never noticed until now. Now would a setting of ALAD.PRG to dietized A have priority over exclude .DAT files? (No right) All the help I receive here is always worth more than two cents, although the amount will be half as much in July . Last Edited on 13/June/93 at 02:12 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 66 Sun Jun 13, 1993 M.MOTOGAWA [MEL] at 11:00 EDT Gerry, I was referring to the section of the version 2 manual that deals with the INFo Editor. Starting on p. 17 to p. 20, although reading the whole section is good, particularly the "Notes" parts. There is no list of operation priorities, but several tips to keep in mind on how some sections of the INFo Editor take priority over others and some are recursive/nonrecursive. - Mel ------------ Category 2, Topic 12 Message 67 Sun Jun 13, 1993 T.MAGEE1 [Todd] at 15:33 EDT Mel, Unless your back-up software already does compression. :) Though I never have sat down to see which is better as far as compression % goes, but I have tried both ways, with the same number of disks always being needed, unless something was added ont he partition, but that doesn't count. ------------ Category 2, Topic 12 Message 68 Sun Jun 13, 1993 K.GERDES [TraceTech] at 18:05 EDT All, Since there seems to be a bit of confusion... DDv2's System: DATADIET.PRG runs in the AUTO folder. On bootup, it reads the optional file, DATADIET.INF, located in the AUTO folder. It then reads DATADIET.TBL in the WORK directory and then cleans up that directory if necessary. DATADIET.INF is used to configure DATADIET.PRG's system operation. This info can be editted with a text editor or DDINFOED. DATADIET.APP/ACC is used to control&configure DATADIET.PRG parameters. These settings can be written to DATADIET.PRG when you choose [Save]. Some of these params are controlled on-the-fly by the #C INF section. DD_TOOLS.APP/ACC is a utility designed to do file operations related to Data Diet. DDINFOED.APP/ACC is the editor for DATADIET.INF. Todd, DDv2 compression: Yes, it is very hard to say how much faster or better DDv2's compression would be for a system. Why? Because the compression/uncompression routines are the same. The advantage in DDv2 comes with the utilization of available memory for each of these routines. In v1, an internal, fixed-size buffer was used. In v2, all available memory is used- gaining speed by minimizing the spooling of data to/from disk and giving additional file reduction under certain circumstances. Stats were never derived for the DDv1 to DDv2 upgrade. Too bad the public never got to experience the awesome v0 to v1 changeover... ;) Floppies: Correct, there are distinct advantages to squishing files on a floppy! Floppies only transfer data at 32000 bytes/second, a speed easily outpaced by uncompression routines- making load times significantly faster. Squish II: Upgrade details are forthcoming. Please continue to be patient... :) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 69 Sun Jun 13, 1993 M.MOTOGAWA [MEL] at 19:47 EDT Todd, I've found DDv2's compression to be better, and since everything's already compressed, you don't have to spend time compressing during a backup. The best of both worlds. - Mel ------------ Category 2, Topic 12 Message 70 Mon Jun 14, 1993 K.GERDES [TraceTech] at 19:16 EDT Gerry, INF sections: Exclusions take priority over compression type (A/B) specification. And specifying a compression type for a path takes priority over compression type for an extender. Control section: Correct, setting the default compression type when you run a program would _not_ have priority over an exclusion. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 71 Tue Jun 15, 1993 G.KICHOK [Gerry K] at 07:16 EDT gnox, Having the Datadiet accessory resident may not be necessary but it is convenient, small, and reassuring. I read your message in Diamond Edge but wondered what the circumstances were. Diamond Edge sure is a great product, I have TOS 1.04 and my MEGAFILE 60 and I wanted to have 7 partitions and update to AtariHDX 5.03. I formated the drive and used Diamond Edge to create the Extended GEM Partitions. One BONUS is that the new Atari driver marks all the bad sectors, as usual, but now I don't have Diamond Edge or Hard Disk Sentry telling me about them all the time. It took me all day sunday and a bit of monday but as you can see I'm back and all is well. I'm also thinking about buying a faster and larger HD from Toad, but I'll try this for a week first. Brian, Thanks for the note, after I read it I made my mind up to create the seven partitions using AHDX 5.03 and partitioning with Diamond Edge, really easy. Keith, I had no problems resetting Datadiet up for the work dir on drive F and changing the setting for the things I did move. Also, I have NOT found any dietized .DAT files in the ALADDIN directory in the past 4 AUTOPASSES, and NO lost clusters (bad vibes cause lost clusters). Last Edited on 14/June/93 at 22:47 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 72 Thu Jun 17, 1993 T.MAGEE1 [Todd] at 02:34 EDT Does DD2 use available memort only as needed, or do I lose a big chunk of my memory at one time that is configurable, or neither? I don't want to see "out of memory" on my system, though I highly doubt that happening. I'll check it out when I get DD2. If the compression speed is slower on some of the Squish2 options (like 9 levels of compression I believe the text file mentioned), does that mean it will be that much slower uncompressing, like when you run the squished program? Also, i don't knwo where would be the right place to put this, but it coul dhave to do qith Squish, so I'll just throw it here. I know if a program saves info back to itself (like config info), you (on some of them) have to unsquish them first, change it, then re-squish it. Sopme have that offset protocol so you don' thav eto do this. Anyways,w hat I am getting at is WHAT is the advantage to save info back into the program? What is wrong with a .INF file or something? I like it better that way. Mr. Impatient Patience, ;) Todd Mel, true. I just wish back-ups were more fun, though DB2 gets close. ------------ Category 2, Topic 12 Message 73 Thu Jun 17, 1993 S.DEITZ [Steve] at 04:35 EDT HELP! I just brought home a Falcon a few days ago and I can't get to any of the data on my SyQuest carts. DataDiet doesn't run on the Falcon and my STE died the day I brought my Falcon home. I get the eror message: (DING) Can't Install - Is it a registered version? I used the original disks of v1 and v2 w/ the same results. They were bought direct so needen't be installed. Thanx in advance. ----STEVE---- /*s ------------ Category 2, Topic 12 Message 74 Thu Jun 17, 1993 G.FUHRMAN [gnox] at 05:58 EDT Gerry, Glad to hear your drive reorganization went well. Where'd you get HDX 5.03? I'm still using 5.00. (Not that there's anything wrong with it ...) Hard drive prices have come down so much that it's hard to resist adding a couple hundred megs - and for a few $$ more you can add an external drive instead of replacing the internal one. That's what I did, a couple months ago. Todd, I'm with you, I like separate config files. Keith on the other hand is one of those who has his programs save to themselves. Of course in his case you can always be sure the Squish offset protocol will be used. :) gnox ------------ Category 2, Topic 12 Message 75 Thu Jun 17, 1993 A.FASOLDT [Al Fasoldt] at 07:40 EDT Todd, The advantages of having an application that saves its configuration back in itself rather than in an .INF file are many. The major one, of course, is that no separate files are needed. This is especially helpful if the configuration information is merely a few bytes in the file header. An .INF file, on the other hand, is very handy if the info is rather extensive. A desktop.inf or newdesk.inf file is a good example of this kind of file; it's editable from a text editor, which a program file is not. Al ------------ Category 2, Topic 12 Message 76 Thu Jun 17, 1993 K.GERDES [TraceTech] at 21:09 EDT Steve, I have talked with Atari Dev and we figured out the problem with Data Diet on the Falcon. Nobody's fault, I'm just glad DD dealt with this new situation safely. It has to do with DD's country distribution restriction check- ie "USA version". I had planned to make a "Country Independent" version sooner or later, and sooner came today... :) GEmail is down so I have been unable to send you this version in fmail. I will continue trying that route. If you want to get it transferred directly, give me a call tonight before 10PM Central or tomorrow (10a-10p) at the tech support #. The archive is small, ~12K. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 77 Fri Jun 18, 1993 S.DEITZ [Steve] at 19:05 EDT Thanx Keith, I will call. ------------ Category 2, Topic 12 Message 78 Fri Jun 18, 1993 A.FASOLDT [Al Fasoldt] at 19:10 EDT Gnox, HDX 5.x/6.x is here on GEnie! Al ------------ Category 2, Topic 12 Message 79 Sat Jun 19, 1993 M.SILVERSTE3 [SYNCHRON] at 01:11 EDT I wrote a program in GFA which calls LZH to extract a file via the EXEC command. With DD2 on, I get 2 or 3 bombs after the file is extracted and goes into a 64 byte buffer I've MALLOCed (we're talking MIDI SYSEX here). My default compression mode is set for terminate and my default type is B. Adding my PRG to the list in the DDINF editor with D0 passed or hitting the CTl/Alt/-minus before running my PRG doesn't seem to work. But passing all three D0,T0, and M0 does the trick! I always thought that if you turn the handler off, it doesn't make a difference what mode or type the compression is set at since DD is turned off. So great! I've fixed it. But why!?? Be in Synch with the Synchron from Camarillo, CA!! Datestamp: Friday, June 18, 1993 Timestamp: 10:04:26 pm ------------ Category 2, Topic 12 Message 80 Sat Jun 19, 1993 K.GERDES [TraceTech] at 13:14 EDT Data Diet v2 owners, File #29050, DD2UPD0A.LZH, is available in the download area. This updates DATADIET.PRG from v2.0 to v2.0a. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 81 Sun Jun 20, 1993 G.KICHOK [Gerry K] at 00:00 EDT gnox, Thanks, the only possible problem I've been having is the TIME it takes the new AHDI 6.05c to decide that the Identification is Unavailable. Keith, I patched my DATADIET.PRG without problem and after following the instructions in on pages 8-11 everything is GREAT, thanks for the PATCH. I was wondering if the original DATADIET.PRG had the fastbit turned OFF instead of ON would your checksum routine report an error? Last Edited on 19/June/93 at 19:02 hrs Gerry Kichok Hamilton-Burlington-Oakville Atari User Group Librarian ------------ Category 2, Topic 12 Message 82 Mon Jun 21, 1993 S.DEITZ [Steve] at 04:57 EDT Keith, Thanx for the quick service on the Data Diet patch. It installed easily on my Falcon, but now I still seem to be having problems. The ACC comes up w/ DD_TOOLS and DDINFOED greyed out, and I can't get it to save it's configuration (Save Error. DATADIET.PRG not found). Am I doing something wrong? Thanx again. ----STEVE---- ------------ Category 2, Topic 12 Message 83 Mon Jun 21, 1993 T.MAGEE1 [Todd] at 08:48 EDT Keith, after reading a text file of you talking about DD's future, I came across a part where you were talking about a possibility of DD 2.5, and getting rid of the find next filesize dietized/original thing. That's great, but the only problem I have with that is like whenb I am backing up my HD, I like to turn DD off and use the dietized filesize. True my backup software will compress if told to, but since DD stuff is compressed, I would rather turn DD off amd have tghe program just read the compressed DD files, rasther than uncompress the DD files then recompress them with the backup program. It's faster to do that. This find next file original size always is great, except for a few cases, like above. If I made my question/statement more confusing then I'm not surprised. :) Also, will Squish 2 have a exclude folder option? I think I would exclude the AUTO folder. IS there any possible problems (except for programs that save to themselves) with squushing AUTO prgorams? Why would there be? I dunno, bu thoguht I would ask. Todd ------------ Category 2, Topic 12 Message 84 Mon Jun 21, 1993 K.GERDES [TraceTech] at 19:37 EDT Todd, [posted here awhile ago and reprinted in DDv2's README.1ST file] Operational clarification: Data Diet has to spool file access during compression and uncompression. Data Diet v2 uses available memory to reduce the spooling of file reads and writes- gathering data in bigger chunks & sometimes in entirety when enough free memory exists. The extra memory buffer that v2 allocates is temporary. When files need to be compressed or uncompressed, a) memory is allocated, b) the operation performed and then c) allocated memory freed. Using the Reserve memory option assures that extra memory is available under certain circumstances. Data Diet v2's memory requirement is ~25K larger than v1's for the equivalent setup. Squish II: Compression speed can be adjusted by both the activation of [Turbo] mode and the compression factor (0-9) setting. These change certain parameters in the compression routine and the end result being the degree of data analysis. Uncompression speed is independent of compression. No matter what setting(s) you used during a Squish operation, the uncompress routine will always be the same speed per se. Keep in mind though, the same file compressed with CF9 will uncompress faster than at CF0 because there is less data to process. As the file data becomes smaller, overall _load time_ becomes faster- fractions of a second on a hard disk. Thus you will have to decide the default settings you want to use according to the amount of space savings and compression time. CF6 seems to be the consensus among testers. Configuration saving: In the end, it's a programmer's choice. The usual reason given for saving in the program is to avoid the user mistake of not keeping the INF file with a program during a "move". Another one, INFs take up disk space which could easily be part of the main program. Looking back, in my biased opinion, executables should not have been allowed to be self-modifying. Life would have been much easier and possibly safer. Synchron, Please see email about your GFA program. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 85 Mon Jun 21, 1993 K.GERDES [TraceTech] at 22:42 EDT Gerry, Patch: Checksum/FAST load bit change: That's a very good question! The DDv2.0a patch is based on the code I wrote for the DDv1.0b patch update. At that time I ran into your question of changing the FAST bit and how it affects checksums in executables. My checksum is based only on the data composing an executable file, excluding the header. The header includes reserved bytes/program flags. I only do a checksum on the program data since program flags can be edited by a user. An oversight that some programmer's run into when doing patchers. And since I follow the Squish OFFSET Save Protocol, I can import the old configuration info into the new file version. And FWIW, it's quite simple to alert a user -when necessary- that the executable is squished: Programmer's docs for detecting a Squished executable ===================================================== An executable starts with the first 2 bytes $60 $1A. Squished executables contain the standardized ascii text "DCSq" at offset $26 from the beginning of the file. [example code] cmp.w #$601a,(a0) cmp.l #'DCSq',$26(a0) Steve, DATADIET.ACC: When Data Diet Accessory's Main dialog is initially brought up, the files DD_TOOLS.A?? and DDINFOED.A?? are searched for in DATADIET.ACC's path; and if they are not found, searches for the memory resident applications DD_TOOLS (ACC) and DDINFOED (ACC) are tried. a) If these files are not found, the buttons in the Main dialog are disabled- aka greyed out. b) If the files are found, but there would not be enough memory to load the files from disk, the buttons are disabled. I would first verify the path of DD_TOOLS and DDINFOED and then check the filenames. Free memory is not your problem, I'm sure... :) The [Save] configuration procedure looks in 2 locations for DATADIET.PRG: 1) boot:\AUTO\DATADIET.PR? and 2) current_path\DATADIET.PR?. There should be no difference in the operation of DATDIET.PRG v2.0a that would cause these two problems. And I don't think it is TOS4/Falcon related. Woops, spoke too soon. Got another Falcon owner report just like yours. Kind of odd how TOS1-3 work fine. Guess it's time to get one of those birds.... Todd, DD "2.5": At the moment, there are _NO_ plans to eliminate the Data Diet ON/OFF option. It is completely separate from the Find Next File option. As you pointed out, there would be no way to copy dietized files in their compressed form without turning Data Diet OFF. When DD is OFF, certain GEMDOS functions are ignored by DD, allowing you to save data in uncompressed form and "maintain" dietized files in compressed form without the normalize(+dietize) step. Squish II: Boy howdy....you must read minds or have access to a mole. Soon after the preview text was posted, an 'Excluded ROOT folders' section was added in the configuration dialog. Two examples: 1) ?:\AUTO, excludes AUTO programs, which some people don't want squished as you stated and 2) RESCUEd executables. I am not aware of any problems with squishing AUTO programs. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 86 Tue Jun 22, 1993 S.DEITZ [Steve] at 05:55 EDT Keith, So your advice is to upgrade my brand new Falcon. Not good :( ----STEVE---- ------------ Category 2, Topic 12 Message 87 Tue Jun 22, 1993 T.MAGEE1 [Todd] at 08:36 EDT Keith, Regarding Squish II, what is "turbo" mode? Too bad Squish II couldn't detect programs that write to themselves that do NOT use the offset protocol. Then there would be no worry. it just wouldn't mess with them. I'd find it easier to figure what data files go to what programs than the other way around. So I wouldn't have a problem with that. Hopefully this offset protocol becomes used more. Or is it already widely known and used? I also like the fact that squished files will now be able to retain their original time/date stamp. That's one thing that bugged me about Squish. Will data Diet 2 be able to identify Squish 2 files? I ask because I'd like to use DD2 to check my total compression on my HD, including squished executables. I know DD1 can do this with squished files up to 1.4c(?) My floppies will love this. Todd Also, I would think it would be pretty difficult to write a program that saves to itself. I wouldn't want to try it. ------------ Category 2, Topic 12 Message 88 Tue Jun 22, 1993 K.GERDES [TraceTech] at 19:37 EDT Steve, No, my advice was not to upgrade your computer! Please, let's not misinform someone that casually reads this topic... Re-read my reply. 1) Check the path of DD_TOOLS.A?? and DDINFOED.A??. Are they in the same location as DATADIET.ACC? 2) Do the filenames match DD_TOOLS.A?? and DDINFOED.A?? ? 3) At the desktop you would need less than 100K available memory to load either of these modules. 4) Try running DD_TOOLS and DDINFOED as accessories. Can you call them up from DATADIET.ACC? The [Save] configuration alert would appear if DATADIET.PRG is not found or if the information could not be written to the file. You're system boots up with DATADIET.PRG installed from the AUTO folder, so I'm looking into other possibilities. As I said, I don't see what the difference can be in operation of DATADIET.ACC under TOS4, since it works okay on TOS1, TOS2 and TOS3. Todd, Squish II: Turbo mode works like the Compression Factor setting. When in Turbo mode, Squish II analyzes much less data, speeding up the compression routine. Since less data is analyzed, the space savings is less. Comparing the 'speed difference' of CF0 w/Turbo OFF to CF0 w/Turbo ON would be similar to having Turbo OFF and comparing CF0 to CF6. Test driving the demo version will let you see firsthand. When? Patience... Saves: There's no easy way to detect during the squish process that a program writes to itself. That is why the 'Excluded filenames' section is available, and a text file on the disk will give a sample listing. OFFSET save protocol: I'm afraid that this protocol has been out long enough that the current support level is all you'll ever see. Why? The usual reasons... ;) ID Squish: All versions of Data Diet's modules and Squish will be able to identify Squish II compressed executables. It turns out I standardized the detection of squished files in the first version, Squish v1.0. Also, the squish version and _original filesize_ have always been placed at specific offsets in the squished file. This is continued in Squish II and its new features also. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 89 Tue Jun 22, 1993 T.MAGEE1 [Todd] at 23:20 EDT How much time will there be between the release of the Squish2 demo and the actual product of ordering? I'm sure many know it is going to be very much well worth upgrading to Squish2 anyway. Well, at least it is to me! :) Todd ------------ Category 2, Topic 12 Message 90 Wed Jun 23, 1993 C.NICHOLLS [BILL] at 01:24 EDT Keith, I find the new patch doesn't work for me, and I am very puzzled. If I try to patch my back-up disk, I get a message that this is not the same file (I forget the exact text of the message.) If I try the original master disk, I get a check sum error message. If I try the copy on my hard disk, I get an Open Error message. Yet the hard disk copy from the original master works okay. What could be wrong? Bill ------------ Category 2, Topic 12 Message 91 Wed Jun 23, 1993 S.DEITZ [Steve] at 04:29 EDT Keith, My apologies; I read your post quickly and incorrectly (that happens when your terminal clock counts $$ and not time). I interpreted your comments to mean I should upgrade my TOS 4.02 to 4.04 I'm glad that's not the case and I'm sorry for the confusion. Keep us posted on TOS 4 compatibility. I set up DD the way I like it on my ST and moved the PRG to my Falcon. Not very convenient, but nothing so horrible. I'm very pleased w/ DD's performance on the 16mHz 030 and the IDE drive. ----STEVE---- / ------------ Category 2, Topic 12 Message 92 Wed Jun 23, 1993 K.GERDES [TraceTech] at 21:44 EDT KC AtariFest goers, Craig @ Clear Thinking will be representing Trace Technologies at the show this weekend. Pick up these TraceTech products at SPECIAL _LOW_ SHOW PRICES: Data Diet v2 Data Rescue (at a bargain price!) and the Data Diet v2 upgrade Also, drop by Craig's booth to pick up a Squish II flyer, signup for the mailout notice and maybe get a sneak preview of Squish II's demo. Todd, Squish II: When the demo is released, full upgrade details and an approximate release date will be included in the doc file. From that info, users can order Squish II. A mailout notice, going to users on file, will be worked on when the manual is at the printer. The flyer's arrival will signal that Squish II is shipping. Bill, DDv2.0a patch update: a) You can't update using a backup disk as the original, unless it's an exact copy. b) Since you received the pre-registered upgrade directly from me, I'm not sure why updating from the original did not work. c) An "Open Error" would occur if either DATADIET.PRG or DATADIET.DIF were not found in the temp directory. To save you the trouble of re-reading the docs and going through the process again, I have sent your v2.0a program in GEfmail. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 93 Thu Jun 24, 1993 T.MAGEE1 [Todd] at 00:18 EDT I'll try and get a sneak at Squish II. I'm also curious on these SPECIAL _LOW_ SHOW PRICES, though I don't need DR and already sent my DD2 upgrade. Probably wouldn't have saved anyway. Curious, do you accept GEnie's GOT's (Gifts of Time) as payment? Assuming not, but may as well ask. Todd ------------ Category 2, Topic 12 Message 94 Thu Jun 24, 1993 C.NICHOLLS [BILL] at 02:22 EDT Keith, Thanks so much. That's real service! Bill ------------ Category 2, Topic 12 Message 95 Thu Jun 24, 1993 K.GERDES [TraceTech] at 20:29 EDT Todd, Show prices: I make it a policy not to post or disclose show prices- before, during or after. Suffice to say, the prices at KC are geared for bargain hunters and I hope to sell out. I'll send you email about your upgrade order since it hasn't arrived. Payment: Sorry, I don't accept Gifts of Time. That's generally used for shareware payments... - Keith [TraceTech] ------------ Category 2, Topic 12 Message 96 Sat Jun 26, 1993 B.MENAGH [Bill] at 14:17 EDT I just unLZHed the DD update and, as recommended, did NOT dietize the DIF file. Contrary to the documentation, the DIF file is 13058 bytes instead of 13084. Is the problem mine or the update file? I hesitate to proceed with this apparent discrepancy. Bill ------------ Category 2, Topic 12 Message 97 Sat Jun 26, 1993 T.MAGEE1 [Todd] at 18:45 EDT Well, saw the demo of Squish 2 today at the KC Atari Fest. If okay with Keith, I will post my opinions/facts on the demo, along with suggestions for the product. Suggestions may already be in it, not sure. I got to play with it a little bit. Craig (though I understand) couldn't answer a lot of my questions. I was surprised to seemingly be the only one there interested in seeing Squish 2 (demo) run. Did anyone else know it would be there? l8r Todd Also got DD2 today. I will take the stats from DD1, DD2 my HD, then take the DD2 stats and check the difference. Though it won't show speed difference though, so it will not show the true difference between dd1/dd2. ------------ Category 2, Topic 12 Message 98 Sun Jun 27, 1993 K.GERDES [TraceTech] at 00:31 EDT Bill, DDv2.0a update: The DIF file dietizes with Type B compression to 13058 bytes. You should have no problems with the update process. Todd, Squish II demo @ KC AtariFest: Yes, I'd like to hear your opinions and suggestions about Squish II. But let's wait for the demo to be released before delving too deeply into "facts". And I will be happy to answer all of your questions now that you've _finally_ gotten your sneak preview. :) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 99 Sun Jun 27, 1993 T.MAGEE1 [Todd] at 11:53 EDT Well, you said "too deeply into facts", implying I can state a couple facts! I was playing with Squish2 on the Edhak3.acc, which was approx. 90K. Using Compression Factor (CF) at "0" (squish 1.4 level I'd say), I had to double- check I had double-clicked on a file, it was so fast! Also, turbo mode was on. CF0 did about 30K/sec! The info section on squished files shows a great deal of info. You will never be asking any questions about a squished file, it will tell you all info you'd ever want to bother to ask. I did notice CF0 did 46% comp., CF9 did 52%, and CF6 did 56%. CF6 better than CF9? If you use CF9, I'd recommend having a cup of coffee while it squishes your files. I'd also recommend flying down to Brazil for the beans. Don't worry, your files will still be squishing when you get back. IAW, CF9 is great, but slow. With turbo on, CF9 did approx. 629 BYTES/sec. Okay, no more facts. Just facts on the comp. stuff. Also note all tests were done on one file, so those %'s will vary. Suggestions/Questions: Q: At included exts, it has PRG and PRX. Why not just "PR?"? Q: When squishing, a graph appears. Somtimes the graph would disappear. Only graph about the first 10% of a file, then the last 10% of a file. What happened to the graph inbetween? Someone mentioned "oh, a bug" but I highly doubt that. But it did seem odd. NOTE: this is only the demo! Q: does the save config save to the PRG file? ARG! :) S: May already be there, but if not this could be a nice touch. Let's say you want your whole drive as small as possible. You could run a file through CF0- CF9, and it would be as small as possible, Would take time, but I think could be very worth it. Could work in batch also. One night set it to CF0 verything, next night set it to CF1 everything, and so on. That way if it finds CF1 to be better than CF0, it will update the squished file to CF1. But if it found CF0 to be better than CF1, it would do no update. Like I said, would take a while, but it could do each compression update during the night or something. Did that make sense!? ;) Q: Is the BUFFER configurable for ACC uses, or do I not understand why it is there? OVERALL, my impression of Squish II is this: I PITY ANYONE WHO DOESN'T UPGRADE! And anyone who has talked to me knows that statements like that don't easily come from me. Or perhaps I was bribed? (just kidding!) Lastly, the pamphlet on Squish 2 was very nice! ;) Todd ------------ Category 2, Topic 12 Message 100 Sun Jun 27, 1993 K.GERDES [TraceTech] at 19:28 EDT Todd, Actually I should have proviso'd "no stats"... Isn't there a saying about stats and facts? :) I'm definitely not much of a stats-man. Your limited sample, ie one file, IMHO is not very representative, as you stated. An interesting hands-on tour for the amount of time you had, but that's about it. I ran some numbers on EDHAK300.ACC- Your CF6 and CF9 values were swapped I think. Turbo ON: CF0=46%, CF6=51%, CF9=52% Turbo OFF: CF0=47%, CF6=54%, CF9=55% Turbo ON: CF9 - 2 mins 11 secs Turbo OFF: CF9 - 4 mins 10 secs Pack-ICE v2.11 compressed the file to 55% in 10 mins 15 secs. [NOTE: The percentages are the amount of file reduction- a 100K file reduced by 40K would be 40%.] "While squishing with CF9, get a cup of coffee or fly to Brazil for the beans". Come on now, that's the kind of under informed, misleading that unfairly gets stuck to a product. CF9 is available when you want to get the best compression out of Squish II. It did give equivalent compression to Pack-ICE -a packer noted for file reduction, not speed- but at a speed considerably faster. An option to 'Exclude files > xxxxK' was put in for those times you want to crank up the CF on smaller files. Even I have heard stories of people setting up PACK programs to compress overnight and only a small batch of files were processed. I would never make a person put up with that kind of lousy performance... :) Answers to questions: 1) 'PR?' is not used since that would match with data files during the search process. Also, some executables match that extender which should be excluded. You can use 'PR?', but that will not be the default setting. The same holds true for 'ACC/ACX' instead of 'AC?'. 2) Graph glitch. You will have to help me on this one. If you can give the file and scenario to recreate the problem, then I will look into it. Your "oh, a bug" quote from a bystander is a reason I shy away from using "bug" under certain circumstances, just like this one. ;) 3) Yes [Save config] does write to the program file SQUISHII.APP. Hey, _I_ follow the OFFSET save protocol! Plus I have already built-in the capability to automatically import old configurations for newer versions. 4) 'Deep thought analyze' option. Yup, that suggestion has been given for two products so far... Each time you bump the CF value up, the compression will improve. However, there may not be any _space savings_ going from say CF0 to CF1. That's why it is best to go with two varied CF values- ie maybe use CF0 when you first get a file to test it out, then change it to CF6 later on when you move it or do a batch Squish on the drive. 5) The BUFFER readout tells you the amount of memory currently available to Squish II for the file operations, Squish & UnSquish. SQII allocates memory only when you choose an operation, it does not take any memory away permanently. It's sort of like the method Data Diet v2 uses. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 101 Mon Jun 28, 1993 T.MAGEE1 [Todd] at 00:54 EDT oops! Actually Double oops. I stated what probably won't change. Liek options and cosmetics could change, but I doubt comp[ression stuff will. Sorry... Well, CF9 was with turbo, CF6 without turbo. Probably the reason for different numbers. Other packers sure sound slow... If someone took my coffee joke as a negative, then I help I made it very clear I am IMPRESSED (very) with this program! Does that mean no batch to give each file its definite best cokpression will not be there? What if you do a file with CF9, then with CF6, and founf CF9 is better. Will it keep it at CF9, or change to CF6? The graph glitch happened ont he Edhak.acc, that's the only file I messed with. Ask Craig to find out EXACTLY what I was playing with. I thought it was edhad3, but nevertheless it was some version of Edhak ACC. The glitch either came on CF0, CF6 or CF9. Try all of those with turbo on, then wirth turbo off. If you don't see anything weird, let me know. Craig didn't know what was going on, but maybe Craig remembers the exact file and tell you. It also did it more than once, so you should see something. I believe the monitor was color, a 1040 STf. I dunno. Also, I never (personally) called anything a bug. Also, it's a demo. Todd ------------ Category 2, Topic 12 Message 102 Mon Jun 28, 1993 G.FUHRMAN [gnox] at 06:34 EDT Todd, Unless you change the Turbo setting, a higher CF will _always_ give better compression; so there's no point in trying different CFs for the same file. Most users will decide on a default CF factor based on their preferred balance of speed/compression and not bother to change it after a while. The reason PRX should be included as well as PRG is to allow for those file renaming bootup programs such as DeskManager, Superboot etc. (If you had one that disables programs by renaming with something other than X, you'd want to add that to the inclusion list. gnox ------------ Category 2, Topic 12 Message 103 Mon Jun 28, 1993 V.PATRICELL1 [Vince] at 19:32 EDT Todd, If you have a file compressed with CF9 and do an update with CF6, Squish II will not mess with the CF9 file since it has better compression than the lower compression factor you are trying to update with. This is the case with any file that has a higher Squished value than the update. If you try to update a file that is CF6 to CF9 (the reverse), though, it will update the file with better compression. Neat, huh? ................................Vince ------------ Category 2, Topic 12 Message 104 Mon Jun 28, 1993 K.GERDES [TraceTech] at 19:47 EDT Todd, Squish II Demo: The demo that you saw is basically the same as the current version of Squish II in testing. The look and operation have not changed. Squish II: During a Squish operation, the compression factor (CF) of the file is compared to the current CF value in the Main dialog. If the new setting is lower or the same, SQII will procede to the next file. The main reason is to keep the CF as high as possible. Once you've compressed files, you would like them to stay small. So per your question, a file with CF9 is skipped during a Squish w/CF6. There's no reason to lower the CF of a file. If for whatever reason you want to, you would have to UnSquish the file and then re-Squish the file with the new, lower setting. Graph glitch: When I ran the stats posted yesterday, I didn't run into any glitches for the settings you suggested. Most likely it is a series of events that need to be duplicated. I'd bet it involves doing an end batch or abort Squish. Also, for reference, did you ever have multiple windows open? - Keith [TraceTech] ------------ Category 2, Topic 12 Message 105 Mon Jun 28, 1993 E.WISNIEWSK1 [Jeff - ST'er] at 21:43 EDT I have my CF set to 7. It compresses good and does it fairly quickly. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Monday, June 28, 1993 - 8:24:40 pm ------------ Category 2, Topic 12 Message 106 Tue Jun 29, 1993 T.MAGEE1 [Todd] at 01:02 EDT Gnox, I think you may have misunderstood me. I know about PRX and PRG and the like and DeskManager. What I was saying is that with Squish 2 if you want both PRG and PRX included, you have to put in PRG and PRX, not just "PR?" which would do the same thing, and only take one slot, not two like PRG and PRX. If you don't get what I mean, then check out the demo when it is available. If you are correct about the CF stuff, then you're correct, and good. No messing around all the time trying to get the best. The higher you go, the better CF you get. Great! Keith, is there ANY situation where a higher CF may not compress as well as a lower one? Just curious. Todd Gnox, are you a beta-tester of Squish II? ------------ Category 2, Topic 12 Message 107 Tue Jun 29, 1993 T.MAGEE1 [Todd] at 01:46 EDT Keith, it was run as a program, no multiple stuff. I never did any aborts or batch stuff either. Always just with that edhak file. When I get Squish 2, if I ever see that glitch I will let you know the exact circumstances. It however does NOT effect Squish 2's main job, and that is compressing. Glad I got that CF stuff straight. Wonder how it will act in 16mhz mode? Todd ------------ Category 2, Topic 12 Message 108 Tue Jun 29, 1993 G.FUHRMAN [gnox] at 06:04 EDT Todd, > Gnox, I think you may have misunderstood me. I guess I did. Fortunately Keith didn't, and his explanation said it all. > are you a beta-tester of Squish II? Affirmative. Several of us in here have been just itching to tell the world in detail how great it is, and your post about the demo kind of opened the floodgates. ;) > Wonder how it will act in 16mhz mode? I don't know, but it sure flies on the TT! gnox ------------ Category 2, Topic 12 Message 109 Tue Jun 29, 1993 K.GERDES [TraceTech] at 19:47 EDT Todd, Squish II's included extenders: You are mistaken. 'PR?' can be inputted as an included extender. However, that is not the default specifier- PRG and PRX are used. FWIW, the default list has 7 empty slots out of the 16 total. Please see my previous reply regarding this... CF: So far I have not run across a situation where a higher CF does not compress better than a lower CF. Of course I don't make a habit of going incrementally from CF5 to CF9 for comparisons. :) Although depending on the filesize and content, I would expect there to be times where negligible gains are found. Speed: The faster the computer....the faster Squish II can compress and squished programs will uncompress when executed. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 110 Wed Jun 30, 1993 S.DEITZ [Steve] at 05:24 EDT Keith, >Try this: > > a) Close all windows at the desktop. > > b) Open drive C's window and set the path to the AUTO folder. > > c) Choose [Save] in DATADIET.ACC. Same result? Yes, same result. I even tried every conceivable combination as an Installed Application, and nothing seemed to help. >If you have a program that can view system memory, give me the 2 bytes >at address $446. Sorry Keith, you got the wrong guy :-) ----STEVE---- ------------ Category 2, Topic 12 Message 111 Wed Jun 30, 1993 T.MAGEE1 [Todd] at 08:10 EDT Gnox I like this stuff because I think compression is amazing. and ten different settings!? Keith gave the idea that to find out what prg save to themselves, turn the RO bit on (NOT the DD thing!) and see what programs bring up an error message. I don't run Squish right now, but will definetely use Squish II. And if I knew the price, I'd mail my check now. Keith I guess if you needed more than Squish has (config speaking) you could just keep two copies on HD with different configs. Though I highly doubt anyone needing that. And I misunderstood you earlier. I just noticed the topic name has Squish II in it, did you just change it, or has it been there? Todd (I wish I was beta-tester!!!) ;) ------------ Category 2, Topic 12 Message 112 Wed Jun 30, 1993 K.GERDES [TraceTech] at 19:05 EDT Todd, When I released the Squish II sneak preview text, I requested 'Squish II' be added to this TOPic name. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 113 Sun Jul 04, 1993 J.TOWLER1 [John] at 01:39 EDT Keith, What's the current price to upgrade from DD1 to DD2? I have the flyer you sent out several months ago, but wasn't sure if the prices were still valid. - John ------------ Category 2, Topic 12 Message 114 Sun Jul 04, 1993 R.SCHILLING [Rob] at 11:30 EDT Hi Keith, I have noticed a problem using DC Shower/Show Text to view files dietized with Data Diet 2.0a. When attempting to view a file from the desktop, Shower only seems to kick in if the file is too small to be dietized, or for larger files if they are manually normalized. This is kind of annoying, but not a critical problem. Any ideas or suggestions would be appreciated. BTW, I'm using version 1.0d of DC Shower on MSTE4 with TOS 2.06. Thanks--Rob ------------ Category 2, Topic 12 Message 115 Sun Jul 04, 1993 K.GERDES [TraceTech] at 20:42 EDT John Towler, DDv1->DDv2: Yes, the prices in the Data Diet v2 upgrade flyer are still valid. Rob Schilling, Shower & DD: I think the solution is the AUTO folder sequence. Shower monitors for a certain GEMDOS sequence by the desktop show routine, therefore it should run _after_ Data Diet. By running DCSHOWER.PRG before DATADIET.PRG, I was able to recreate your problem. This just started since you updated, right? ;) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 116 Thu Jul 08, 1993 R.SCHILLING [Rob] at 21:17 EDT Keith, Thanks for the tip. Resorting the auto folder fixed the conflict between Shower and DD. Yes, this was just since the upgrade. Thanks again--Rob ------------ Category 2, Topic 12 Message 117 Sat Jul 10, 1993 G.FUHRMAN [gnox] at 05:02 EDT Any other Data Diet users bought big new hard drives lately? I'm interested in comparing notes - Since I added an external Maxtor 7213 to the 50-meg Seagate in my TT, my Data Diet setup has changed quite a bit. Instead of a ramdisk work directory I'm now using the root of a Seagate partition. Here's the whole setup: Seagate C: boot and utilities D: data files in progress E: DD work directory F: Aladdin Maxtor G: major applications H: archive of text files etc. I: archive of graphics and PageStream docs J: fonts Everything on the Seagate I treat as temporary, and therefore not dietized. (As soon as a file is `done' it's either moved to the archives or deleted.) Executables on C and G are all squished, but other files such as RSCs are not dietized, nor are the fonts - I decided the space savings weren't enough to bother with. Everything on H and I is dietized - thus I have all the files I might ever want to re-use instantly available, without having to mess with floppies or LZH or ZIP files. With EdHak and Bill Aycock's Finder 2, I can find any text string in the archives _very_ quickly, even if I don't have a clue where it is. I estimate it will take me two or three years to fill up those dietized partitions (twice as long as it would take without DD, of course). And having the DD work directory on the root of a dedicated partition makes it almost as fast as a ramdisk - thus saving me lots of RAM. I'm very happy with this setup! It makes the most of the hardware. And of course I'm happy that through all this tinkering with DD I ran into no problems at all. I know this isn't of much interest to those without 200+ megs of HD space, but it gets so quiet in here when nobody posts about anything except problems ... :) gnox ------------ Category 2, Topic 12 Message 118 Sat Jul 10, 1993 K.GERDES [TraceTech] at 23:48 EDT Rob, Your quite welcome. Glad to be of service. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 119 Thu Jul 15, 1993 K.VANDELLEN [Ken Van] at 23:40 EDT Keith, Just a note that I'm stilling looking for the cause of the lost files problem. I haven't kept records, but it seems they often are .IMG files. I just had two again, and both were .IMGs I made last night with TouchUp and tried to OutPrint. I'm wondering if TouchUp or OutPrint might be at least partly responsibility. I'll let you know if a pattern of any kind emerges. Ken Van ------------ Category 2, Topic 12 Message 120 Tue Jul 20, 1993 BRIAN.H [ST~SysOp] at 22:22 EDT Keith, Does the DD "Control by Program Names" take precedent over the setting in the accessory? What I did was turn off DD for Diamond Back via the configuration setting. I then ran DB and presto DD was still on and returning original size! I have now changed "program names" to D0. BTW, why can't DD be turned off AND compression on in DB? Won't this then compress those files/directories excluded by DD and this save B/U disk space? The DD shouldn't be affected or possibly compressed even further, right? Wrong? Today I was using Zip and unzipping a zip file of 1.8 meg. It won't unzip all the files. My work directory was over 2 megs free. Therefore, my question is, DD doesn't write to path until the ard/lzh/zip process is totally finished? Am I correct? Do people normally keep ARc and Zip shells "D0"? ~~~~Brian ... Written on Tuesday 20 July 1993 at 11:05 p.m. ADT ------------ Category 2, Topic 12 Message 121 Wed Jul 21, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 00:36 EDT Brian, >Does the DD "Control by Program Names" take precedent over the >setting in the accessory? What I did was turn off DD for Diamond Back >via the configuration setting. I then ran DB and presto DD was still >on and returning original size! I have now changed "program names" to >D0. It somewhat depends on how you want your backup data, if you want the data backed up in the dietized format, then turn DD off with the D0 'Control by Program Name' option, otherwise leave DD on with 'Return Original Size'. >DD doesn't write to path until the ard/lzh/zip process is totally >finished? Am I correct? Do people normally keep ARc and Zip shells >"D0"? This would depend on weither you have DD set to (T)erminate or (R)eal-Time. Terminate would wait until it is finished before it does it's thing. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Wednesday, July 21, 1993 - 12:17:06 am ------------ Category 2, Topic 12 Message 122 Wed Jul 21, 1993 BRIAN.H [ST~SysOp] at 05:36 EDT Thanks Jeff. I have mine set for terminate. ~~~~Brian ... Written on Wednesday 21 July 1993 at 06:35 a.m. ADT ------------ Category 2, Topic 12 Message 123 Fri Jul 23, 1993 K.GERDES [TraceTech] at 19:06 EDT Brian, DDv2's 'Control by Program Name': DATADIET.APP shows the current configuration settings for the Data Diet handler, DATADIET.PRG. Using 'Control by Program Name' will tell the handler to automatically change the specified DD parameters whenever you run a particular program. Suppose Data Diet is ON at the desktop. You run FILENAME.PRG. If you specify 'Data Diet OFF' when you run FILENAME.PRG, then you should see that Data Diet is OFF when you bring up the Main dialog in DATADIET.ACC. When you exit the program, Data Diet should be turned back ON at the desktop. See page 7 and page 20 in the DDv2 manual addendum for further details. I hope I answered your questions... DD and DBII: "why can't _DD_ be turned _off_ AND _compression on_ in _DB_" a) You want to backup your files in dietized form- DD OFF. b) You then want to compress files that are not compressed already- DBII's data compression option. No problem at all. Yes, you would then "compress those files/directories excluded by DD and save backup disk space." Dietized files would not be compressed much, if any. The only side effect would be a noticable loss of time trying to compress compressed data. The format of dietized files and squished files is documented. Maybe someday these will be automatically excluded from DB's compression during backup... File archivers: All file archive extenders are excluded in DATADIET.INF. Yes, some users turn 'Compression Mode' OFF for archive programs. Turning Data Diet OFF, D0, would not be advisable if you create archives since dietized files would not be uncompressed. I need to get some info on your ZIP file- Compressed size? Uncompressed size? Data Diet does not "flush" the pending file(s) from the WORK dir until you quit the program in DD's Terminate compression mode. I am currently looking at the "out of room on the WORK drive" detect routine. If you run out of room, DD should flush files to make room and continue the operation. That may be part of the problem you are running into... - Keith [TraceTech] ------------ Category 2, Topic 12 Message 124 Fri Jul 23, 1993 BRIAN.H [ST~SysOp] at 19:51 EDT Keith, >Dietized files would not be compressed much, if any. The only side >effect would be a noticable loss of time trying to compress compressed >data. Time, no problem. I use my 520 for a game every time I B/U my HD. The only time I can play a game {grin}. As long as the files are valid, I am hpaay. > need to get some info on your ZIP file- >Compressed size? 1,854,720 Uncompressed size? approximately 3.2 K Work Directory drive free over 2.3K. Thanks for the help Keith! ~~~~Brian ... Written on Friday 23 July 1993 at 08:40 p.m. ADT ------------ Category 2, Topic 12 Message 125 Fri Jul 23, 1993 P.WALDING [Phil Walding] at 20:51 EDT Hello all ... a small problem someone may be able to help me with. I have recently installed Data Diet V2 as an upgrade to V1. I tried , last night , to do a back up with Diamond Back , turning Diet off on the accessory control panel and sending the files to floppy A. No matter what I did I couldn't get Data Diet to stop expanding the files out and in the end had to set 'Find next file' to normal , set Diamond Back to compression and transfered the files accordingly. It's a lot easier to just turn Diet off and it always worked when I did it with V1. Anyone have any suggestions ? Many thanks Phil Walding ------------ Category 2, Topic 12 Message 126 Sat Jul 24, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 00:37 EDT Phil, >I tried , last night , to do a back up with Diamond Back , turning >Diet off on the accessory control panel and sending the files to >floppy A. Did you know that you can set DD to automatically turn itself off/on (or any of the other flags) when you run a program?. Please read page 21 in the 'DD Version 2 Manual Addendum'. The following section from my INF file tells DD to turn itself off whenever any of the three programs are run. Then DD will turn itself on after you exit the programs. #C EDGE.PRG:D0 DMIRROR.PRG:D0 CLEANUP.PRG:D0 >No matter what I did I couldn't get Data Diet to stop expanding the >files out and in the end had to set 'Find next file' to normal , set >Diamond Back to compression and transfered the files accordingly. You can also set DD to toggle this for you also. Just use F1/F0 in the above example. F1 - for original filesize and F0 - for the dietized filesize. It depends on how you want your data on your backup disks to be. If you want them backed up in the dietized format then turn off DD. And if you want them in their original state, leave DD turned on and use F1 instead. Just be aware that if you back them up in a dietized format you will not be able to use the data if something happens to your DD program. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Saturday, July 24, 1993 - 12:03:26 am ------------ Category 2, Topic 12 Message 127 Sat Jul 24, 1993 P.WALDING [Phil Walding] at 16:30 EDT Jeff - I set the D0 flag yesterday and it worked fine. I still don't quite understand why it doesn't work from the ACC panel anymore , but since that no longer causes problems , I guess it's a bit academic. Thanks for the info. Phil Walding ------------ Category 2, Topic 12 Message 128 Sun Jul 25, 1993 K.GERDES [TraceTech] at 23:10 EDT Brian, Backup: The integrity of dietized files with Data Diet _OFF_ is up to the file maintenance utility's routine. For example, a B/U app's compression routine would probably either act like an "archiver" and store the file, or write out the compressed data that it produces. WORK dir: Thanks for the additional info. I am currently delving into the "auto flush WORK dir" routine's logic. Phil, Data Diet ON/OFF via ACC: At what point were you turning Data Diet OFF via DATADIET.ACC? At the desktop or inside the application? If you did it at the desktop, please refer to page 7 in the addendum. You can easily test this parameter- Run a text editor. Bring up DATADIET.ACC and click on the [Data Diet ON/OFF] button so that it reads Data Diet OFF. Load a dietized text file and you _should_ see the file in dietized form- begins with 'DIET'. Turn Data Diet ON and load the same text file to see the original, uncompressed contents. JSW, Good advice. Thanks for the assist! :) And your comment about storing files in dietized format is one reason why some people backup data in non-compressed form. You have instant access to your original data. This isn't just related to Data Diet, but any program that creates "proprietary" compressed files. Yes, including backup programs. Right, [?].....wish I could remember the user's name. ;) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 129 Mon Jul 26, 1993 K.GERDES [TraceTech] at 19:45 EDT >>>> ANNOUNCEMENT <<<< File #29500, SQIIDEMO.ZIP, has been uploaded to ST-RT Lib #10. This is a demo of TraceTech's new product, Squish II. Full docs are included, along with upgrade details for Data Diet v2, Data Diet v1 and DC Utilities owners. Squish II upgrade notices: Upgrade notices were mailed last Thursday. This mailout was sent to- 1) All Data Diet v2 registered owners. 2) Data Diet v1 owners entered in that database before March 1992. If you received TraceTech's DDv2 flyer in late '92, then you will be getting this one too. 3) DC Utilities owners entered in that database before the end of 1991. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 130 Mon Jul 26, 1993 BRIAN.H [ST~SysOp] at 20:08 EDT Any special arrangements to run with Codekeys? Codekey works but when I access the accessory, there is no file loaded. Obviously it was loaded otherwise the keys won't work. However, upon accessing it, nada! ~~~~Brian ... Written on Monday 26 July 1993 at 09:05 p.m. ADT ------------ Category 2, Topic 12 Message 131 Mon Jul 26, 1993 R.SCHILLING [Rob] at 21:24 EDT Keith, It it recommended that DD2 be turned off when using Diamond Edge and D. Mirror? If so why? I've been using them together, hope I haven't ruined anything. Rob ------------ Category 2, Topic 12 Message 132 Tue Jul 27, 1993 G.FUHRMAN [gnox] at 07:59 EDT Brian, > Any special arrangements to run with Codekeys? You mean with Data Diet? No - > Codekey works but when I access the accessory, there is no file > loaded. Obviously it was loaded otherwise the keys won't work. > However, upon accessing it, nada! The accessory won't show you the KEY file that is active? Odd, never seen that before ... better try the CodeKeys topic. (Are you multitasking by any chance?) Rob, No need to turn off DD2 with Diamond Edge or Mirror, but if you do any file validation with Edge, you have to use Find Next File: Original Size. I have an INF file entry to switch to Original Size with Edge. gnox ------------ Category 2, Topic 12 Message 133 Tue Jul 27, 1993 BRIAN.H [ST~SysOp] at 21:07 EDT Gnox, >The accessory won't show you the KEY file that is active? ... (Are >you multitasking by any chance?) Nope, I want to get DD set up for a few weeks before going back to MTOS. Brian ------------ Category 2, Topic 12 Message 134 Wed Jul 28, 1993 K.GERDES [TraceTech] at 19:02 EDT Brian, Codekeys: You may want to verify that DATADIET.PRG is running before any file that needs to access dietized data support files- ie CODEKEYS.PRG. Rob, DDv2: Turning OFF Data Diet is an option when using any program. This is generally only used when copying dietized files in compressed form. For Diamond Edge and Mirror, the recommended setting is to use 'Find next file Original size'- per the supplied DATADIET.INF and READ_ME.2ND files. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 135 Wed Jul 28, 1993 BRIAN.H [ST~SysOp] at 19:44 EDT Thanks Keith, however, I placed Codekeys at the end of my auto folder and still the same. ~~~~Brian ... Written on Wednesday 28 July 1993 at 08:42 p.m. ADT ------------ Category 2, Topic 12 Message 136 Thu Jul 29, 1993 J.WILES1 at 21:09 EDT Keith, Could you go over the Data Diet - Geneva information one more time? I guess I must be brain dead after a rough day at work as I have read over your message in Geneva's topic and am not sure what's going on. Are you saying that if we run a program setup to shut Data Diet off in the #C entry, Data Diet will be off for all other programs running at that time until we quit the #C entry program? I'm a little confused so be gentle. Also, regarding FIND NEXT FILE, I run this in ORIGINAL mode. Do I need to shut off DD to run Diamond Back II or can I leave it on? If I leave it on, will all of the backup files end up in the work directory? Until now I have been shutting DD off with the #C entry when running Diamond Back II. One more and I'll leave you alone. Since I'm running DD in ORIGINAL mode, do I need to use LOADMAXI.ACC or can I run Maxifile without this special code? Thanks for the support and eagerly await Squish II. The check is in the mail. Jeff ------------ Category 2, Topic 12 Message 137 Fri Jul 30, 1993 G.FUHRMAN [gnox] at 07:25 EDT Jeff, (We meet again! :) The only real problem, apparently, is with an INF file entry that turns DD off. But I don't have Geneva so I'll leave the explanation to Keith. If you're in Original Size mode all the time, then you can use MaxiFile without LoadMaxi and you can leave DD on when using Diamond Back. The only problem is that if you're backing up to floppies, your files _will_ go through the work directory (thus imposing a slowdown) and they will _not_ be dietized on the backup. Or maybe you wouldn't consider that a problem. ;) gnox ------------ Category 2, Topic 12 Message 138 Fri Jul 30, 1993 K.GERDES [TraceTech] at 21:36 EDT Jeff, Squish II: Your package went out Thursday, July 29! DDv2 & DBII: When using any file maintenance utility, you have 2 choices: 1) Keep DD ON and use 'Find next file Original size' Dietized files will be backed up in uncompressed form. Correct, the WORK dir will be used during the uncompression process. 2) Turn DD OFF Dietized files will be backed up in compressed form. Please see the READ_ME.2ND file for details. LoadMaxi: If you use 'Find next file Original size', you do _NOT_ need to use LoadMaxi. Data Diet v2 & Geneva: When using Geneva with Data Diet v2 installed, for simplicity, I recommend having a second DATADIET.INF file without a #C section. However, if you completely understand the operation of the handler and #C usage, then 'DD Control by Program Name' can still be used... If you run a program that has a #C entry which turns Data Diet OFF, yes, DD will be OFF for all processes currently in the system. Think of the situation with TOS... You run FILENAME.PRG which turns DD OFF, via #C FILENAME.PRG:D0, when run. Then if you try to use an accessory to view a dietized text file, you can only see the compressed text because Data Diet is OFF. Right? When you exit FILENAME.PRG, the previous process's DD parameters are restored. This is linear and works perfectly under TOS. A simple process counter can be used. Linear? Process counter? Process1 is the desktop. You run FILENAME.PRG, Process2. First, DD's parameters for Process1 are stored in a table under process #1. Then the process counter is incremented by 1, the new parameters figured out and stored under process #2. You exit Process2. The process counter is decremented by 1 and the old parameters for process #1 are retrieved. 1 -> 2 -> 1 [let's call it linear, I'm not up on tech'ese] How does this relate to MTOS, Geneva and Mag!x? Well, the process execution is not linear... ;) And you can't use a process counter. In a multiprocessing environment, each sub-process is an individual branch connected to the main process- the desktop, task manager, etc. Likes spokes on a wheel. For example, 2 | 5-1-3 | 4 Under the current implementation of #C's logic- If Process5's #C entry turns Data Diet OFF, all other processes (1-4) will have DD OFF. Process counting can not be used since you have multiple processes active at one time. For now, the best way to use a #C entry under Geneva, is to run these _few_ programs as the only process. If you do run multiprocess, specifically which DD "global" parameter do you have to worry about? _ONE_- DD ON/OFF. You probably would not want to access dietized files in compressed form in your other apps. ;) The other params will cause no problems to other processes... Currently I am trying to find a way to identify the process name that is making a GEMDOS call. Each time a call is made, I would setup the 7 "custom" parameters to get the #C section working on a per-process basis. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 139 Fri Jul 30, 1993 J.WILES1 at 23:41 EDT Keith, Thanks. That was really an excellent explanation of what is going on in the multitasking world. The only program I have set up in the #C section is Diamond Back II and I use that without any other programs running in the background except Geneva and NeoDesk. For now I'll just set up that 2ond INF file and wait for you to figure out a way to identify the processes. You developers really amaze me! As for DB II, that is the way I thought it would work but just wanted to check for sure in case I had to remove the #C section from Data Diet. Remembering to manually turn Data Diet ON or OFF doesn't always work with my memory so the #C section is a blessing. Also, thanks for the info on Maxi File. I picked this up about a month ago and have used the Load Maxi.ACC because I wasn't quite sure and didn't want to lose any data. Jeff ------------ Category 2, Topic 12 Message 140 Sun Aug 01, 1993 G.FUHRMAN [gnox] at 08:32 EDT Over in the DATAlite topic, more user reports are starting to come in. The big surprise (to me) is how slow it seems to be, compared to Data Diet - but as I said over there, comparisons are difficult unless someone is using both on the same system, which hasn't happened yet (and maybe never will). Anyway, here's my observations on speed ... With my TT system, I now have some partitions dietized and others not, so it's easy to compare loading and saving times of dietized files with those that aren't. The difference is barely noticeable even with Type B (highest) compression. Back when I was using a ramdisk work directory, the difference was undetectable - in fact my impression was that it was sometimes _faster_ to load a dietized file. Certainly in my year-and-a-half of using Data Diet I have never seen a dietized file take several times as long to load or save, as some DL users have reported. (There _are_ ways to slow the system down with Data Diet in certain circumstances, but I've never seen the need to do that. :) When I run PageStream, which is Squished, it takes approximately four seconds to load. Even allowing for the speed of the TT, this seems _much_ better than the results DL users are reporting. With Squish you get space savings (about the same as DATAlite, apparently) with _no_ penalty in speed. I've found this to be true even on an 8-mHz ST or Mega. So far, anyone who's trying to choose between DATAlite and Data Diet / Squish has nothing to go on but testimonials from their respective users. So here's mine: Data Diet 2 is rock solid, fast and very flexible. gnox ------------ Category 2, Topic 12 Message 141 Sun Aug 01, 1993 M.MOTOGAWA [MEL] at 10:37 EDT Yes, even on an 8mhz machine, Data Diet 2 is great in it's speed of compression using type B and even faster with type A. I was getting around 20k bytes per second compression at 8mhz, but now around 80-90k bps at 25mhz (T25). Decompression speeds were around 80k bps, and now they're around 250k bps at 25mhz. These figures are from the Data Diet Accessory's statistics section, which continuously keeps tabs on your current system's performance since bootup. Executables squished with Squish 2 execute only a tad slower than normal size, from a hard disk, and much faster from floppies. And you can use any cache you're cozy with, just like before. Any users of Data Diet version 1 or DC Squish 1.x should seriously think about upgrading. The new versions are light years ahead of their predecessors. Thanks! - Mel ------------ Category 2, Topic 12 Message 142 Sun Aug 01, 1993 M.MOTOGAWA [MEL] at 10:56 EDT BTW, I don't recall if it was mentioned earlier, but the demo of Squish 2 has been u/l'd to the file libraries. File #29500, only a 22k d/l. The demo won't save a squished file, but you can investigate the program's many new features, see how long a squish would take at the various compression factors and do a batch squish of each partition to see how much space you'd save with Squish 2, without it doing anything to your executables. Nice! - Mel ------------ Category 2, Topic 12 Message 143 Sun Aug 01, 1993 K.VANDELLEN [Ken Van] at 18:03 EDT Keith, My order for Squish II went out Friday. I'm looking forward to it, but will be gone for a couple of weeks, so it should be here when I return. Like gnox, I've been very happy with the speed of DCSquish and Data Diet 2, also. I've always pretty much followed the manual suggestions for setting various parameters, but probably should try to use some of the flexibility that DD2 has. One of the parameters I haven't messed with is the reserve memory size. I see that that can be set in the Tools configuration and also in the InfoEd #C section. Does the InfoEd setting override the configuration setting? How do I know if I need to change one or both of these? Maybe if it ain't broke I shouldn't fix it, but it would be interesting to know about. Ken Van ------------ Category 2, Topic 12 Message 144 Sun Aug 01, 1993 M.MOTOGAWA [MEL] at 18:34 EDT Ken, I believe the Reserve Memory setting for the INFo Editor, which is tied to the prgs you set up custom parameters for, does take priority over the Data Diet Accessory's Reserve Memory setting for the time that prg is run, then the default setting of the Accessory takes over when you exit the prg with the custom setup. If you are in a ram greedy app. and find that a desk accessory gives you an "out of memory" alert, try increasing the amount of Reserve Memory either for that app. (via the INFo Editor) or the default (via the Data Diet Accessory). I used to get "out of memory" alerts all the time in various word processors (which is where it seems you always need to call up accessories) or in some archiver shells, until Data Diet's Reserve Memory came along. - Mel ------------ Category 2, Topic 12 Message 145 Mon Aug 02, 1993 K.VANDELLEN [Ken Van] at 07:32 EDT Thanks, Mel. The purpose of RM was a little obscure to me. Ken Van ------------ Category 2, Topic 12 Message 146 Mon Aug 02, 1993 K.GERDES [TraceTech] at 19:22 EDT Jeff, DDv2 #C INF & Geneva: The way you run DBII under Geneva (essentially the sole task), I'd bet that you can still use the #C entry as you have been under TOS... Give it a try! Mel, Speed: Just a minor clarification for readers... You mentioned '20k bytes per sec' then later used 'k bps'. The 'k bps' still meant Kbytes/second. That's right folks, _Kilobytes_, not Kilobits as you may see in some speed benchmarks! Using bits allows you to get a very misleading 8x performance rating... Other times, quoted stats are for the _TT only_, a 32Mhz 68030 machine. I give numbers from the machine I use- a stock 8Mhz MegaST2. They may not seem impresive to some, but I assure you that they hold there own with realtime compression programs on any platform. I like to see that the Data Diet/Squish stats are always comparatively very good on whatever machine is used. Mel gave both 8Mhz/ST stats and 25Mhz/ST stats. You'd see even faster performance on a Falcon or TT! Ken, Reserve: Data Diet's 'Reserve Memory' option can be set in Data Diet Accessory's Configuration dialog. You can also customize this setting for a specified program by using the #C INF section. As with the other parameters you can set on-the-fly, this reserve setting will override (ie take the place of the default setting) when you run that program. And it will be restored when you quit the program... "When to use reserve?" If you use reserve, your default setting should be at least 64K- per page 3. Basically, reserve allows Data Diet to allocate a bigger (vs the built-in) compression/uncompression buffer when needed. Some programs try to allocate all memory when they run. Reserve's job is to keep a preset memory size free for Data Diet or whatever "resident" application needs memory. The default Reserve setting is up to the user. Whatever amount of free memory you think you can spare for a _temporary_ buffer. This "reserved" memory can be allocated by any program, so it is not "lost". If you want to tailor the Reserve setting for a certain program, say for speed, then you can make the size bigger. Or, you could make the size smaller or zero if you need just that extra amount of free memory. Maybe somebody could give an example from their INF? - Keith [TraceTech] ------------ Category 2, Topic 12 Message 147 Mon Aug 02, 1993 K.VANDELLEN [Ken Van] at 21:43 EDT Thanks, Keith. You've raised another question. Is the Reserve Memory the same thing in DD as in MultiDesk Deluxe? I mean, is it redundant to have memory reserved in both? Ken ------------ Category 2, Topic 12 Message 148 Tue Aug 03, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 01:00 EDT The reserve memory in MultiDesk Deluxe is 'a reserve size which is sets aside enough memory to ensure that nonresident DAs will be able to run even in programs that try to grab all available memory'. And yes that is from their manual. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Tuesday, August 3, 1993 - 12:49:38 am ------------ Category 2, Topic 12 Message 149 Tue Aug 03, 1993 K.VANDELLEN [Ken Van] at 07:06 EDT Thanks, Jeff. I know that about MDD. What I'm trying to find out is if I have memory reserved in MDD, might I need to reserve some in DD, or is it redundant? Might it be necessary to reserve memory in both applications? Ken Van ------------ Category 2, Topic 12 Message 150 Tue Aug 03, 1993 G.FUHRMAN [gnox] at 07:24 EDT Ken, Yes, it's redundant to reserve memory in both DD and MDD. I've had my "Reserve Size" in MDD set to 0 for about a year now. gnox ------------ Category 2, Topic 12 Message 151 Tue Aug 03, 1993 K.GERDES [TraceTech] at 19:05 EDT Ken, DDv2's Reserve Memory: Yes, it is redundant to use both. See the bottom of page 3... - Keith [TraceTech] ------------ Category 2, Topic 12 Message 152 Tue Aug 03, 1993 K.VANDELLEN [Ken Van] at 20:36 EDT Thanks, gnox. I'll follow your lead. Ken ------------ Category 2, Topic 12 Message 153 Wed Aug 04, 1993 K.VANDELLEN [Ken Van] at 06:18 EDT Keith, Hmm. I guess I looked every place but there. In both manuals! Ken Van ------------ Category 2, Topic 12 Message 154 Wed Aug 04, 1993 J.WILES1 at 07:38 EDT Keith, I was thinking the same thing about DDv2 #C INF & Geneva as I run DBII as single tasking. Actually, I did a backup last week and didn't run into any problems so all looks good to me. Jeff ------------ Category 2, Topic 12 Message 155 Wed Aug 04, 1993 D.HELMICK [Dan] at 22:36 EDT Is there any way to manually select OFFSET in Squish II? ------------ Category 2, Topic 12 Message 156 Wed Aug 04, 1993 DMJ [dmj] at 23:15 EDT I just got DD2 and Squish II in the mail today. Everything looks good, especially the Squish II manual. At first I was disappointed that I was going to have to add _another_ program to my AUTO folder (I was not aware of this when I bought the program), but the explanations in the manual definitely make sense, and I'm happy with how Squish II works. It will certainly take a while for the programs to get packed the way I want them. Something happened while I was packing files and my GFABASIC.PRG got toasted; I'm certain it was something I did, probably with Mega Depack. In any case, I look forward to getting this set up so transparently I won't have to think about it. Thanks for a great package. -dmj ------------ Category 2, Topic 12 Message 157 Thu Aug 05, 1993 G.FUHRMAN [gnox] at 06:42 EDT Dan, > Is there any way to manually select OFFSET in Squish II? No - Squish II detects whether a program supports the offset protocol or not. If not, there's no way to use it in the Squished version of the program; and if the program supports it, there's no reason not to use it. So no user interaction required. gnox ------------ Category 2, Topic 12 Message 158 Thu Aug 05, 1993 K.GERDES [TraceTech] at 19:50 EDT Dan, Squish II/OFFSET: "manually select OFFSET?" The 'Squish OFFSET Save Protocol' must be built into a program that you want to squish. Squish II will auto-detect the OFFSET code and squish the file accordingly. It's then up to the OFFSET-aware squished file to be able to save to either a non-squished or squished version of itself. Details with sample source code are included on the disk... The actual implementation of this is pretty trivial for any assembly programmer. Other languages might be a different story- to be honest, I've never investigated them. However, it seems to be the fact that a person is directly/indirectly - endorsing the Squish product, allowing your file to be squished, etc- which has kept programmers from taking this extra step of user convenience. DMJ, Your quite welcome. Squish II: Sorry, I didn't mean to make you think there was a "scheme" to hide how Squish II works before you bought it. ;) During development, the change from v2.0 to v2.1 reflected the addition of the new AUTO module, UNSQUISH.PRG. As the beta testers are well aware, I labored hard over this decision- pondering their wise, experienced input. Weeks were spent doing R&D to see if this was the best alternative. The main impetus was the fact that the old, tacked-on uncompress loader code from v1, "bandaged" for v2.0, just was to confining and wasn't up to the task at hand....now or in the future. It was reworked and rejuvinated in what became UNSQUISH.PRG. The end result being compatibility and performance improvements, expandability, etc. And to try to headoff people's reactions (mainly v1 upgraders) I expanded my coverage of this simple module in the manual. I see that it worked in your case, sort of... :) Unpack: For those unfamiliar with Mega Depack, it's a file unpacker available in the ST-RT file library. It unpacks most known "pack" types. Setup: For most users, compressing their original files and the conversion of Squish v1 files & other "packed" files will be a breeze using Squish II. The available options are designed to help the user get setup and then maintain the system with ease as files are added. Yep, Squish II is definitely a transparent, easy-to-use addition for any system. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 159 Fri Aug 06, 1993 DMJ [dmj] at 19:11 EDT Keith: It's not a problem, it just kinda surprised me. I guess the beta testers had plenty of time to get used to the idea, and when I finally picked up the thread here it'd already been discussed and hacked over a million times and put to rest. I looked briefly at the DC Offset protocol when I bought Data Diet 1 way back when, but not being a proficient assembly language programmer at the time, I didn't pay too much attention to it. (Not to say that I'm proficient now, just much better than I was.) In any case, it's so harmless to add that I'll toss it into View 2.1. I doubt there would be any space savings from squishing the viewer programs, because they're so small, but I was already planning on using something similar to allow for the new options. I have no trouble "endorsing" Squish II. It's a great package. Now if I only had the time to finish squishing all the programs on my hard drive... -dmj ------------ Category 2, Topic 12 Message 160 Fri Aug 06, 1993 K.GERDES [TraceTech] at 19:49 EDT ==================== | Squish II | | Press Release | ==================== Trace Technologies is proud to introduce the followup to the executable-file compression program, Squish. It's come a long way since 1989! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A little background: Squish v1 was previously distributed by the guys at Double Click Software as DC Squish in their DC Utilities and the Data Diet v1 package. Like all my programs released through DC, that was the extent of my business relationship with DC, there were never any formal ties. At one time there were plans to upgrade and split off three of the DCU programs as separate packages- Squish was one of them. Luckily, this new Squish version is now available from TraceTech. By the way, I never left the market... And no, I did not buyout DC. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TraceTech's latest package is Squish II- an Executable-File Compression System for the entire line of Atari computers. Squish II allows you to safely save storage space quick-and-easy by compressing your programs and accessories. 'Squished' files run exactly the same as the original, uncompressed version. The only side effect you will notice is all the extra space you gain after using Squish II. Squish II is a complete rewrite of v1, taking well over 6 months to complete. I look forward to your questions and comments. Hopefully you will decide to purchase Squish II.... Feel free to contact us through the various methods listed below. Keith Gerdes (TraceTech) -*- Squish II - Trim the fat from any file you can run! -*- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some Squish II highlights: [] Compatible with all Atari ST/TT/Falcon computers and all TOS versions [] 68030 compliant [] Multitasking operation- background and foreground 'Multitasking friendly' when run as an accessory under TOS, or as an application or accessory under MultiTOS. Automatically minimizes system load when in the background. [] Graphic resolution independent [] Advanced windowed graphical user interface, with keyboard equivalent user input [] Faster and better compression than v1 [] Compression Factor (CF) A value from 0 to 9 can be inputted. This adjustment varies the compression routine's data analysis step. Using a value of 0- fastest compression, least file reduction NOTE: CF0 produces files smaller than Squish v1.4 with an ~3x faster compression routine. Using a value of 3- approximately equivalent to PFX size reduction, though Squish II is faster of course. Using a value of 9- slowest compression, best file reduction [] Turbo mode Another compression adjustment like CF. Turbo/CF0 is the fastest. NOTE: Uncompression speed is constant, not affected by either Turbo or CF settings. [] Converts several "pack" types: + Squish 1.0/1.1/1.2/1.4 + Pack(2) + PFX & LZS2PFX + Pack ICE + Fire-Pack + Pompey Packer + BAPack + Atomik [] Recursive batch mode with Intellisearch Batch operations now work recursively. In addition to files in the current directory, files in sub-directories are searched for, allowing you to compress the contents of an entire drive or folder. [] Include extenders + Extenders are filtered by 'include' logic. Default list- PRG, PRX, ACC, ACX, APP, TOS, TTP, GTP + Easy user entry and editing of 16 extenders total. Only files with an extender matching an 'included extender' can be squished automatically. This feature helps to alleviate the accidental compression of "non-Squishable" executable files- ie some I/O drivers. [] Excluded filenames + Filenames can be specified as excluded from Squishing. + Easy user entry and editing of 48 filenames total. This list is comprised of files that should not be squished or files that you do not want squished. For example, self-configuring programs. [] Memory efficient design [] Realtime status graph [] Revised uncompress loader + Smaller + Faster + Specialized code to safely handle load errors for both programs and accessories. + Squished accessories are compliant with Memory Protection. NOTE: Most executable compressors, if they even support compressing ACCs that is, will fail in this regard. + No more message printout- ie 'Squish-FILENAME'. [] Commandline support GEM Takes Parameters and Drag & Drop [] Flexible user options You control the system! [] FAST bit During a Squish operation, you can choose: a) Set FAST bit b) Clear FAST bit c) Keep the FAST bit as-is [] Other filters during Squish + Skip Squished + Squished only + No Compression Factor Update [] Keep TIME/DATE Stamp option [] Expandable features [] Very easy to use [] 40+ page manual ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Squish II Info -------------- Availability date: Shipping NOW! Suggested retail price: $40 NOTE: An upgrade is available for owners of Data Diet v1, Data Diet v2 or DC Utilities. Contact us for details. Address: Trace Technologies PO Box 711403 Houston, TX 77271-1403 Customer service line: (713)771-8332 [weekdays 1PM-5PM Central Time] Online: GEnie- K.GERDES Internet- k.gerdes@genie.geis.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TraceTech is always seeking distributors worldwide. Current product line: Squish II, Data Diet v2 and Data Rescue ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Reprint notice: Reprint permission is granted as long as it is done in entirety. ------------ Category 2, Topic 12 Message 161 Fri Aug 06, 1993 BRIAN.H [ST~SysOp] at 19:56 EDT Keith, I got mine the other day and I am really impress. Makes my 48 meg HD a lot "bigger"! Thanks. ~~~~Brian ... Written on Friday 06 August 1993 at 08:51 p.m. ADT ------------ Category 2, Topic 12 Message 162 Fri Aug 06, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 21:40 EDT Yep, it is so much better than the original version. Alot of improvements. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Friday, August 6, 1993 - 9:16:36 pm ------------ Category 2, Topic 12 Message 163 Wed Aug 11, 1993 J.BATTEY1 [J. L. Battey] at 20:43 EDT The main reason I bought DC Utilities was for DC DeskKey which breaks on TOS >2.06. Any chance of a fix? John L. ------------ Category 2, Topic 12 Message 164 Thu Aug 12, 1993 K.GERDES [TraceTech] at 20:23 EDT John Battey, Wish I could help you with Deskey. That was Mike V.'s program, so I'm not sure what the last version was, or if it was "newer" TOS (ie 2 or 3) compatible. It could have been since he had both a MegaSTe and a TT to work on. As of 3/92, the DCU2 package version was 2.0G. I couldn't find a sub-version in Deskey 3.0. Squish v1 (aka DC Squish) has been upgraded to Squish II. Leave me your address in email and I'll send you the upgrade notice. There is also a demo, file #29500, with full details. - keith ------------ Category 2, Topic 12 Message 165 Thu Aug 12, 1993 K.GERDES [TraceTech] at 21:14 EDT Squish II v2.10 owners: File #29655, SQ2UPD11.ZIP, has been uploaded to the Lib. This patch updates package release v2.10 to v2.11. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 166 Thu Aug 19, 1993 B.AEIN [B Man] at 00:13 EDT Keith great job on SqII!!! Anyone who wants more HD space should look no further! Data Diet 2 and Squish II are both fast, easily configured, and Rock Solid! Best of all, is Keiths service to helping his users in a quick and timely manner and it's a great feeling to KNOW that I am supporting one of the few remaining U.S. developers left. Keep up the good work! Bman ------------ Category 2, Topic 12 Message 168 Fri Aug 20, 1993 B.STOREY [Billy B.] at 07:15 EDT I have a few programs that were squished when I got them, and I have been using them for years with no problems whatever. If Squish II is better, I don't know how it could be! Billy B. :-) ------------ Category 2, Topic 12 Message 169 Fri Aug 20, 1993 M.MOTOGAWA [MEL] at 11:09 EDT Billy, Yes, it's hard to imagine how it could be improved. You could either d/l the press release (file #29601) or the demo (file #29500) to see how much faster and better Squish II is. It's amazing. - Mel ------------ Category 2, Topic 12 Message 170 Fri Aug 20, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 18:52 EDT Billy, >I have a few programs that were squished when I got them, and I have >been using them for years with no problems whatever. If Squish II is >better, I don't know how it could be! It is much faster, has alot more options, better compression, got rid of a few bugs... ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Friday, August 20, 1993 - 6:40:38 pm ------------ Category 2, Topic 12 Message 171 Fri Aug 20, 1993 K.GERDES [TraceTech] at 19:03 EDT Billy B.: Like you said, squished programs can be used for years with no problems whatsoever. You can say the same for archived files (.ZIP, .LZH, .ARC, etc), which a squished file can be likened to. Though a better "near" comparison for a squished file might be a self- extracting archive. The self-extracting part can always be improved in operation and compatibility, which Squish II has done for squished files. The program which creates squished files, Squish v1 & Squish II, can be compared to an archiver, the archive creator. Compression evolves over time and the 'creator' needs periodic maintenance to keep pace. Not to mention all the new features that are added! ;) Squish II is a vast improvement over Squish v1. Also, files squished with Squish II are even more compatible than v1 and allow for easy expandability in the future. Yep, Squish II is better. The press release is a good summary to see how it could be. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 172 Sat Aug 21, 1993 K.VANDELLEN [Ken Van] at 16:41 EDT Keith, I'm reading the docs before installing Squish II, and I have a question about Patch.TXT. My DATADIET.ACC is v2.1. Does this mean I don't need to patch it? Ken Van ------------ Category 2, Topic 12 Message 173 Sun Aug 22, 1993 K.GERDES [TraceTech] at 19:28 EDT Ken, Squish II/DATADIET.ACC Patch: Most likely you have an old BR version. Look in email for further details about your situation... - Keith [TraceTech] ------------ Category 2, Topic 12 Message 174 Mon Aug 23, 1993 K.VANDELLEN [Ken Van] at 07:06 EDT Keith, All the files on my DD v2 disk are dated 12/23/92, if that tells you anything. I'll look for GEmail. Thanks. Ken Van ------------ Category 2, Topic 12 Message 175 Tue Aug 24, 1993 M.SILVERSTE3 [SYNCHRON] at 10:53 EDT In DD v2, where does the configuration get saved?? I use Superboot and some of the Function Keys I use involves Ram disks (i.e. CodeRam). When using a Ram disk, I would like to have the DATADIET.WRK folder be specified in the RAM Disk and use Coderam to use a ccp file which makes the ram disk with the Datadiet folder. Since Datadiet is configured to run before Superboot (so my Random Dietized Pix/Sound files work), I have to manually rename the file as Datadiet.Prx and then the Datadiet.ACC will allow me to change the Datadiet.Wrk drive. Is there an easier way to do this??? ------------ Category 2, Topic 12 Message 176 Tue Aug 24, 1993 M.MOTOGAWA [MEL] at 19:21 EDT Synchron, For your Superboot configurations that use your ramdisk as a work dir., you don't have to use a .ccp file to create a work dir. there. DD will create one automatically if it doesn't find one there when booting. Be sure the ramdisk runs before DD in this case. CodeRam sure is a great ramdisk. If there are times when you want to use a hard disk work dir. (perhaps to work on files larger than your ramdisk) then just create two copies of DD in the auto folder, changing the name of one. This is because the config. saving, from the DD acc. for the work dir. path, gets saved to the DD auto folder prg. Have one copy of DD configured for your ramdisk work dir. and another for your hd work dir.. My hd work dir. copy of the DD auto folder prg is called DD_WORKD.PRG for a drive D work dir.. I switch between the two via Deskmanager. - Mel ------------ Category 2, Topic 12 Message 177 Tue Aug 24, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 20:49 EDT Synchron, >In DD v2, where does the configuration get saved?? Keith can answer this one better than anyone. But I believe in DATADIET.PRG. >using a Ram disk, I would like to have the DATADIET.WRK folder be >specified in the RAM Disk and use Coderam to use a ccp file which >makes the ram disk with the Datadiet folder. DataDiet will create the WORK directory if it does not exist. The only problem I see in you coping it via CodeRam is that - before you turn the machine off you must make a new CCP file, and this is each and every time!. >Since Datadiet is configured to run before Superboot (so my Random >Dietized Pix/Sound files work), I have to manually rename the file as >Datadiet.Prx and then the Datadiet.ACC will allow me to change the >Datadiet.Wrk drive. Is there an easier way to do this??? Yep there is, run DATADIET.ACC as DATADIET.APP, then you can change the WORK directory drive. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Tuesday, August 24, 1993 - 7:34:28 pm ------------ Category 2, Topic 12 Message 178 Wed Aug 25, 1993 K.GERDES [TraceTech] at 20:06 EDT Synchron, Data Diet: When you use DATADIET.APP/ACC to configure the handler (DATADIET.PRG) and choose 'Save', the info goes to the file boot:\AUTO\DATADIET.PR?. You didn't state the AUTO sequence which you run your RAMdisk WORK drive in. If the sequence is: 1) RAMdisk then DATADIET.PRG DATADIET.PRG will automatically create the WORK dir for you on the RAMdisk- page 22 DDv1 manual. 2) DATADIET.PRG then RAMdisk DATADIET.ACC (<-note extender) can be used to automatically create the WORK dir- same page. Of course, you won't be able to access dietized files until the WORK dir is in place. The next update of DDv2 will address the various issues when using a _ROOT_ WORK dir- ie K:\ instead of K:\DATADIET.WRK\. There are some advantages to using a ROOT WORK dir. To have multiple WORK dirs, like on a hard disk for one session and a RAMdisk for another, Mel has already tackled that... NOTE: And as Mel found out, file synchronization is very important. You will need to make sure the WORK dir is cleaned up before "switching" to the other one, if you run in _Terminate_ compression mode. To change the WORK dir assignment, you simply run DATADIET.APP (<-note extender)- page 21 DDv1 manual. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 179 Thu Aug 26, 1993 OUTRIDER [Terry] at 22:27 EDT Keith, I sent in my upgrade check for Squish II on the 22nd, and to my amazement, I received Squish II today on the 26th! That's from Vegas to Houston and back. Excellent service! And to think they call it U.S. Snail. ;^) I've only had a chance to play with it for an hour or so, but I'm even more impressed than I expected. Aside from the new features and the improved interface, the savings in compression over Squish 1.4b files is more than I could've hoped for. I expected a little extra savings, but not like what I've seen. I'm looking forward to having the time to use Squish on the rest of my executables (or most of them, anyway). I should save a significant amount of space on just the ones being converted from Squish 1.4b, let alone those that I haven't Squished at all. Again, thanks for the FAST service and an _excellent_ product! __ /erry .\\ay ------------ Category 2, Topic 12 Message 180 Fri Aug 27, 1993 T.MAGEE1 [Todd] at 00:15 EDT Keith, I just noticed with DD2 how compressing works. Using the memory as DD2 does on compressing makes things a lot faster, but worried me on BIG files (800K) when it just sat there. With DD1 it owuld do alot of read/write during that time, and I thought it had crashed at one time. Now that I get what is going on I think it is great. :) Todd ------------ Category 2, Topic 12 Message 181 Sun Aug 29, 1993 K.GERDES [TraceTech] at 18:51 EDT Terry, "FAST service and an _excellent_ product" Thanks for the kudos. I make it a policy to process orders ASAP. I know how impatient I get when I order something, so I try to treat customers as I feel I should be treated as a customer. Hope that made sense... :) And I always strive for quality products and service. Squish II: "Even more impressed" That seems to be the consensus so far. Sometimes it's too bad what you see in a demo or read about in a magazine or text file just doesn't give the big picture. True representation is gained when you actually use a product over a period of time. Sort of like a car. Another satisfied customer. Todd, DDv2: It's a little tough to explain some features at times. The memory model of DDv2 is no exception. This falls into the "use" category. Once you have become accustomed to DDv2, you can tell the difference in performance over DDv1. I'm glad you like it... :) - Keith [TraceTech] ------------ Category 2, Topic 12 Message 182 Sun Aug 29, 1993 C.CASSADAY [Chris C.] at 22:54 EDT All, In last Wednesday's DATALITE RTC with ORA, I incorrectly stated that DATA DIET II did not work with MultiTOS on a friends Falcon. I regret this mistake since I did not have first hand experience in working with the DATA DIET II/MultiTOS/Falcon configuration. DATA DIET II does indeed work with MultiTOS on the Falcon. I extend my sincere apologies to Keith Gerdes of Trace Technologies for my gross misunderstanding. Chris Cassaday To anyone including transcripts of the RTC in printed publications, please note my error. ------------ Category 2, Topic 12 Message 183 Mon Aug 30, 1993 OUTRIDER [Terry] at 01:44 EDT Keith, One thing I'd like to see in Squish II is to not only show total space saved from the original file sizes, but the total saved from the previous Squished file sizes (where applicable), perhaps followed by the total actual disk space saved. Something like: Total Savings from Original Files : 500,000 bytes Total Savings from Previous Squished: 50,000 bytes Total Savings on your disk : 100,000 bytes Since the vast majority of my executables are already Squished with 1.4b, it would give me a better indication of how much actual space I'm saving, without checking my drive space before and after. An ASCII log keeping track of Squished files and their savings would be nice, too, and would help to show the benefits of Squish II. Ideally, it would be self-maintaining, i.e., kept to a certain size. Thanks... __ /erry .\\ay ------------ Category 2, Topic 12 Message 184 Mon Aug 30, 1993 M.MOTOGAWA [MEL] at 20:32 EDT Terry, Just fire up DD_TOOLS.APP in the TraceTech folder of the master disk and you'll be pleasantly surprised. Tools will allow you to grab squish stats (using the Calories section) on a folder, partition or all of your drives at one time, and recursively at that. You can save the stats to disk too. Nice. - Mel ------------ Category 2, Topic 12 Message 185 Mon Aug 30, 1993 OUTRIDER [Terry] at 21:37 EDT Mel, Thanks for the tip! I just fired up DD_TOOLS.APP and I'm very impressed! I had overlooked it before, because the name indicates it's something for Data Diet (which I don't have), and I didn't see any docs for it. Still...I'd like to see total savings from previous Squished files at the end of a batch. Obviously, once you exit the program that information is history, so DD_TOOLS.APP won't do me any good. It's no biggy. It's just something useful for the curious. :^) __ /erry .\\ay ------------ Category 2, Topic 12 Message 186 Tue Aug 31, 1993 M.MOTOGAWA [MEL] at 02:12 EDT Terry, I'm not sure if I'm following your thought, but did you try the Save Stats button in Tools' Calories section? It will save to disk the stats for the path or drives you specified, which takes into account every file you've ever squished. Then you can compare this with a future Calories session. Squish II will, at the end of a batch squish, show you how much you've saved in that batch operation. - Mel ------------ Category 2, Topic 12 Message 187 Tue Aug 31, 1993 G.FUHRMAN [gnox] at 06:19 EDT Mel, I think what Terry wants to know is how much space he's saved relative to the previously Squished files, not relative to unSquished files. And I think the only way to do that is to manually make a note of the file sizes before and after updating them. It's a fairly esoteric statistic. :) gnox ------------ Category 2, Topic 12 Message 188 Tue Aug 31, 1993 M.MOTOGAWA [MEL] at 10:51 EDT Gnox, Oh, o.k.. Yes, that would require saving the stats before a batch conversion to Squish II format and then comparing the results. - Mel ------------ Category 2, Topic 12 Message 189 Tue Aug 31, 1993 K.GERDES [TraceTech] at 19:57 EDT Terry, Squish II stats: Thanks for the input. I'll note them on my 'eval' list. An ASCII log: I think I hear some beta testers mumbling to themselves in the background... :) DD Tools: The brief Tools documentation, related to Squish, is in the file TRACE.DOC in the TRACE_TE.CH folder on your Squish II disk. I guess I should have named it TOOLS.APP so that people who don't browse all text files would have at least run it... - Keith [TraceTech] ------------ Category 2, Topic 12 Message 190 Tue Aug 31, 1993 OUTRIDER [Terry] at 23:55 EDT Mel, What gnox said. It already shows you the original Squished size vs. the new Squished size at the end of each conversion. The only thing that I'm asking is that it be totaled at the end of a batch. -----8<----- Keith, Thanks. BTW, do you have any idea why Diamond Edge bombs when Diamond Mirror is Squished? Luckily, I had seen this reported before in the Diamond Edge topic, so I knew right away what the probable cause was. I unSquished Diamond Mirror and no more bombs. __ /erry .\\ay ------------ Category 2, Topic 12 Message 191 Wed Sep 01, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 00:54 EDT Terry, Diamond Mirror saves the configuration to itself, so you can squish it after you have it configured. Diamond Edge works great squished all the time since it saves the configuration to a separate file. ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Wednesday, September 1, 1993 - 12:43:44 am ------------ Category 2, Topic 12 Message 192 Thu Sep 02, 1993 K.GERDES [TraceTech] at 19:58 EDT Terry, Squishing DMIRROR.PRG: As JSW stated, data is saved in the Diamond Mirror program so you can not have it squished during configuration. Please see the EXCLINCL.TXT file on the Squish II disk for further details. - Keith [TraceTech] ------------ Category 2, Topic 12 Message 193 Thu Sep 02, 1993 J.WISNIEWSK2 [Jeff - ST'er] at 20:40 EDT I just remembered about Diamond Mirror, I believe that it saves the date to itself when it runs so it can't be squished at any time, can someone confirm this... ^^^^^^^^^^^^^^^^^^^ ^^^^ JSW ^^^^ ^^^^ ST'er ^^^^ ^^^^^^^^^^^^^^^^^^^ Thursday, September 2, 1993 - 8:25:36 pm ------------ Category 2, Topic 12 Message 194 Thu Sep 02, 1993 OUTRIDER [Terry] at 22:57 EDT Jeff, That makes sense about Diamond Mirror looking for the date inside the program; I hadn't thought of that. The problem I was having was _not_ trying to configure a Squished Diamond Mirror; it was already configured when I Squished it. The problem was simply running Diamond Edge after booting with a squished Diamond Mirror. Diamond Edge bombs while loading. Thanks... __ /erry .\\ay ------------ Category 2, Topic 12 Message 195 Sat Sep 04, 1993 K.VANDELLEN [Ken Van] at 07:38 EDT Keith, I finally got around to trying to load Squish II after attempting to digest all of the README files and the manual. Whew! You did a good job on it, but all the stuff about the Heap and Fastbits and other stuff was pretty strange to me. You had to go into it all so people would know why and how to set things, but it's just about a short course in computer operation. I tried to read the READ-ME.1st first, and got pretty bewildered until I switched to the manual. Thanks for being so thorough there. Ken ------------ Category 2, Topic 12 Message 196 Sun Sep 05, 1993 G.FUHRMAN [gnox] at 06:40 EDT Ken, Yes, it is very thorough, isn't it? :) Actually a lot of the information in the manual will be quickly forgotten because you don't need to remember it to use Squish. But it's good to know that it's there if you ever need it. The Heap option is a good example - I've never actually used it. And the Exclude/Include feature eliminates having to remember anything about specific programs - you just set it and forget it. That's what manuals are for, right? - all the stuff you don't _want_ to remember! gnox ------------ Category 2, Topic 12 Message 197 Sun Sep 05, 1993 K.VANDELLEN [Ken Van] at 16:21 EDT gnox, Right. I don't believe in carrying a lot of stuff around in my head that I can look up when I need it. I must have tweaked something having to do with Hot Wire, because it's back to where it was a year or so ago. Again it may not load and when it does it doesn't load a HOT file. Worse, I can't remember how I fixed it last time. Deja vu, but I wish I could deja vu all of it. Ken ------------ Category 2, Topic 12 Message 198 Sun Sep 05, 1993 OUTRIDER [Terry] at 18:24 EDT Keith, Any idea why when I try to Squish UNARJ.TTP (32925 bytes), although the Squish graph shows about a 38% compression upon completion, I'm given the alert that there was not enough compression to Squish? __ /erry .\\ay ------------ Category 2, Topic 12 Message 199 Mon Sep 06, 1993 G.FUHRMAN [gnox] at 05:39 EDT Terry, Are you sure that 38% figure isn't left over from the previous Squish operation? (If you were only Squishing the one file, ignore this message!) gnox ------------ Category 2, Topic 12 Message 201 Mon Sep 06, 1993 BRIAN.H [ST~SysOp] at 12:17 EDT Can one of you experts help Ken Van? I have deleted message number 200 in this topic. It is a duplicate of one in the Hotwire topic. Let's keep this thread in one place and since it is in the Hotwire topic, we will keep it there. Long-winded explanation ==> For everyone information (no flame intended), when a problem is concerning two or more topics, a pointer directing everyone to one topic is best. This way it would result in not everyone suggesting the same solution in different area. Therefore, a solution should, in theory, occur quicker. Why? Everyone would be aware of all the aspects of the problem. (A pointer is a brief message informing pertinent users where the main thread is occurring. The pointer would be in each of the topics except one. This one topic is where the pointer would of course point.) If someone wants this explained more or have a complaint, please EMail me. Thanks everyone for helping! Here is the topic for the main thread: 32 CodeHead Software Topic 2 HotWire! ------------ Message 84 Mon Sep 06, 1993 K.VANDELLEN [Ken Van] at 10:50 EDT I restored partition C, and everything ... ~~~Brian... Written on Monday 06 September 1993 at 12:37 p.m. ADT ------------ Category 2, Topic 12 Message 202 Mon Sep 06, 1993 OUTRIDER [Terry] at 13:47 EDT >Message 199 Mon Sep 06, 1993 >G.FUHRMAN [gnox] at 05:39 EDT > >Are you sure that 38% figure isn't left over from the previous Squish >operation? Positive. Keep in mind I'm using CF 9 to compress all my files, and it takes a few minutes to compress a 33k file. It doesn't just jump to 38%; it's a gradual process. And yes, it gives the same reading when Squishing in single file mode. __ /erry .\\ay ------------ Category 2, Topic 12 Message 203 Mon Sep 06, 1993 K.VANDELLEN [Ken Van] at 21:15 EDT Brian, Your suggestion of pointers is an excellent idea. I didn't like the idea of posting in two places, but wasn't sure what to do, since I was initially unsure where I should post. Experts, You folks can relax. Everything's cool. Thanks, anyway. Ken Van ------------ Category 2, Topic 12 Message 204 Mon Sep 06, 1993 BRIAN.H [ST~SysOp] at 21:45 EDT Thanks Ken Van for understanding. ~~~Brian... Written on Monday 06 September 1993 at 10:42 p.m. ADT ------------ Category 2, Topic 12 Message 205 Tue Sep 07, 1993 G.FUHRMAN [gnox] at 06:31 EDT Terry - well, you've got me! Maybe Keith has an answer. ------------