@database 078f4f00-0 @master More:DiskSqueeze/Docs/DiskSqueeze.guide @$VER: 1.20 @author "Dirk 'Dirkie' Vael" @(c) "19.01.1996 (03:19AM)" @remark Created with Heddley v1.1 (c) Edd Dumbill 1994 @node "Main" "Welcome to DiskSqueeze!" @toc "ImpressieMaken" @{b} ,_ , gmi @{ub} Click @{"HERE" link "ImpressieMaken" 0} @{b} W@@W @ di d@@@i @@@@[ @ @` d@`dA] Y@ ]@ i@ @[ @! ]@ ]@ ,Wi ][ i @` ,i ,. , gm gm _mm ,mi @[ ]@ W. i@M[ W[ W @i g@[ ]A @ d@M[ d@M[ @@@[ ,@A@ @[ WA @` W! ` @`d@ M@. d@A@i @! @ i@!][ i@!][ ~T@! WA @ i@!,@[ iA @. i@i@! '@[ ,@P,@` ]A ]P dP W[ dP W[ WP ,@`i@ d@ ]@` d[ Y@. ]@@! ]@ ]A ]P ][ W[ @bg@` @bg@` d@` ]@_WP @P @A @ M[ @MP ]@ @[ @! @[ @ ]@M@! ]@M@! ,@[ @A@A i@!d@! ,@ W! @ @ , ][ i@`,@ @ i@ ]@ ]@ @A @[ d@W@P ]P ibd@ ]A @ dbg@! ]@ WP ]@sWP ]@ ,. ]@ ,. ]@Wmi @[ _ @@@A W[ !@@! d[ @[ Y@@P '@@@[ @@@[ @@@! @@@! @@@@[ ]@@A !V*` V` !! !! ]W *~ V!@` V!][ V*f V*f !~ '**` '` i@ ]A @{ub} v1.22 @{b} ][ @{ub}@{fg fill}(1/10/96)@{ub}@{fg text} @{fg shine}@{bg shadow}DISKSQUEEZE@{fg text}@{bg back} a powerful and yet so easy-2-use diskpacker for the Amiga Computer © 1996 Dirk VAEL @endnode @node "ImpressieMaken" "Overview" @{b}@{u}DiskSqueeze - Overview Menu@{ub}@{uu} @{"Introduction" link "dikkeKAK" 0} @{"What's New ?" link "NEW" 0} @{"Features" link "sHoWYAsTupH" 0} @{"Requirements" link "WaEddeNuudig" 0} @{"Installation" link "Arrangeren" 0} @{"Usage" link "Prutsen" 0} @{"Hints" link "HoeBeterDoen" 0} @{"Troubleshooting" link "StrontADKnikker" 0} @{"Known Bugs" link "Verdjuu" 0} @{"History" link "Vroegere" 0} @{"Future" link "NaUnNiefWijf" 0} @{"Free Registering" link "Slijmen" 0} @{"Author" link "Stoefen" 0} @{"Big shouts" link "JoowDeMannen" 0} @{"Technical Info" link "PoepjeRuiken" 0} @endnode @node "dikkeKAK" "Introduction" @toc "ImpressieMaken" @next "sHoWYAsTupH" @{b}@{u}Introduction@{ub}@{uu} DiskSqueeze is the answer to people who are in need for a disk archiver which has better compression ratio's than existing programs, and has moreover some extra's which cannot be found in existing archivers. Since it is a 'must-have' for a new disk-archiver to be compatible with the DMS tool (Disk Masher System), this option is also implemented. But before we go to all the features of DiskSqueeze, let's talk a bit more about the currently available disk-archivers. Almost every Amiga owner who has worked with compressed files, has seen and/or worked with the DMS tool. This tool, the follow-up of a disk cruncher called 'Warp', was released in 1991 by the American firm SDS software. The Warp tool, also from SDS and which was very similar to DMS, was one of the first disk-archivers for Amiga computers those days, together with 'Zoom'. But as you might have guessed, DMS was fast, compressed better than 'Zoom', 'LHWarp' or 'Warp', was relatively easy and (almost) totally free. The docs were missing with the DMS distribution on Fish Amiga Lib disks, but the program was pretty self-explanatory. Then came the new Amiga's, SDS passed away (RIP) and DMS (v1.11) had still some bugs, which were sometimes very frustrating. The program itself crashed sometimes for inexplicable reasons (it even crashed on my machine just a few minutes ago !), archives were sometimes unstable (cf. ERR3!ERR3!...), and the compression routines were becoming outdated (although still MUCH faster as 'DImp' (Disk Imploder)). These kind of archivers, especially DMS, were mostly used by pirates (come on guys, admit once!). This wasn't funny for SDS, but the Amiga-user benefited somehow from this situation, cause pirates recoded partially these disk-archivers. Guys like 'Paradox' and 'Quartex' made their own enhanced versions of DMS or Warp (DMS v1.51-53 / WarpXtra3+), and some dudes tried even to make money with it (ParCon), releasing DMS as DMSWB 2.xx. However, these pirates often forget something good programmers and Commodore (almost) never did... compatibility ... Ever tried to run DMS v1.53 or DMS 2.06 on an Amiga 4000/040, with all caches on ? CRASHHHHHHH !!! Caches maybe off ? Oh yeah, and pack with the speed of an A500... this was pretty frustrating, moreover by the fact that archives became incompatible with older versions of DMS/Warp... Ok, Paradox claimed that they fixed most bugs in the original version, Quartex made a Warp version which could pack upto 83 tracks (under MFM though), and ParCon made a DMS which could pack high density disks or MS-DOS disks, but what if the archiver itself isn't working properly on your fast Amiga ? DMSWB crashes also when started from WB ! (and not from CLI..?? stupid...:-) There was also a new compression-standard coming to Amiga, called eXtended PacKer (XPK). Very flexible, up-to-date compression algorithms for all kind of data, all hosted by one library, and endless update-able. Backup programs, doublespacers, etc. were starting to use these compression algorithms... However, DMS was keeping up pretty well in Amiga-land, certainly because of pirate-support ... Once I switched to XPK, I was happy for some time. Transparent packer for files and/or devices (including harddisks) ... hmmmmm ;-) But last year, another cruncher saw the light in Amigaworld... LZX. PC suckers always say that nothing beats their ZIP or RAR archivers, and they have MS-DoubleSpace, Stacker etc. Amiganoids were forced to work with LhA, fast but not as good as RAR. Amiga versions of ZIP were always a bit inferior in compression than their PC-counterpart. Moreover, PC's are very fast these days, which benefited PC-ZIP/RAR aswell. Recently, an UnRAR tool was released on Aminet, but a RAR program will probably never see the daylight on the Amiga, because it's inferior to LZX and certainly to LZX-2 (finally also available for PC) This time, we can kick some PeeCee ass, showing them LZX (on a fast Amiga of course ;-). Compression ratio's unrivalled, especially for big files. Lotsa whining on internet-newsgroups, but you couldn't deny the superior compression ratio's in daily 'work'. Sadly, there are a few things missing in LZX. If you compare LZX 1.21r with LhA 1.50r, you'll see that there are alot of extra options with LhA, like disk-spanning, move option, etc... Moreover, LZX doesn't support XPK (still under development, said J. Forbes, author of Amiga LZX). The current xpkELZX from Adam Przybyla and Piotr Kasprzyk is not really an xpk sublibrary, but merely a linked library towards the lzx.exe program. I guess we will have to wait for a standalone LZX xpk library for quite sometime. Although Amiga-owners have the very talented gift of being VERY patient ;-), some Brit Amiganoid called 'Adam Chapman' couldn't stand it no longer in this DMS world, and decided to make an disk-archiver based on LZX. His result was called xDM (eXtended Disk Masher). I was pretty surprised that making a disk archiver is really easy (...). However, xDM had really alot of bugs and wasn't flexible at all. Therefore, decided to put my Amiga-knowledge of the past 8 years into a better version of xDM. For more about xDM, see History. After I uploaded xDM v1.2 and a much improved xDM 1.3, Adam finally reacted to my calls to agree/disagree with the release of this. He reacted on it by removing my xDM v1.3 from the Aminet! Grrr, me pissed off. He was working on a v2.0 xDM, and I was 'degraded' to a beta-tester... When I saw what xDM v2.0 was, I was very bitter that such a thing was the reason for the destruction of all my hard work on xDM 1.3. Even when I saw further improved versions of xDM, I was still thinking that it could be done MUCH better. Well, the result is my own thang, DiskSqueeze. An versatile, ass-kicking disk-compressor. I made this because I wanted to solve all experienced troubles with DMS and xDM, and not seeing somebody else running away with all my ideas ... Hopefully 'dark forces' won't try to remove the DiskSqueeze release this time from the Aminet... Hope you enjoy it (and even more with this third release!), Dirk @endnode @node "sHoWYAsTupH" "Features" @toc "ImpressieMaken" @next "WaEddeNuudig" @prev "dikkeKAK" @{b}@{u}'DiskSqueeze', the ultimate 'kick-ass' storage solution, featuring:@{ub}@{uu} * @{bg shine}ALWAYS@{bg back} better compression ratio than DMS (using the LZX algorithm) @{i}-> not that much gain for already packed disks (few percent), but upto @{b}@{u}@{ui}33 %@{i}@{ub}@{uu} for unpacked disks And wipes the floor with XPK too, regarding ratios@{ui} * just as fast as DMS (even faster on slow CPUs) * faster compression for registered LZX users (LZXr autodetected) @{i}-> yep, but only with the '-Qf' and 'af' options The -9 option is crap, cause it's 20 times slower than -3, and gain is only 3% or so * DSQ-archives include verbose filelist for valid ADOS/MAC/PC disks ! -> yep, and that's totally new for a disk-archiver@{ui} * DSQ-archives can use the File_ID.DIZ 'de facto' filenote standard -> just to keep up with upcoming standards in internet/BBS land * supports ADOS/MAC/PC/AFS (high-density) disks (+ other device-drivers) @{i} -> yes! again new, and future filesystems will work too with it !@{ui} * DiskSqueeze also unpacks DMS archives without a problems, except single track archives (fault in dms.device?) * inbuilt DMS to DSQ archive-convertor * supports up to 2 ramdrives (for quick packing/unpacking/converting) @{i} -> more than enough, I guess + very handy for big-mem systems (>5 MB)@{ui} * supports a custom device for those who do not use MFS/or who have exotic devices * fully multitasking + OS compliant (no extra libraries required) * easy, mouse-driven ASL user-interface * smart memory-usage monitoring + full error-handling @{i}-> For those nasty bug-hunters, or the silly wussies@{ui} * extensive AmigaGuide documentation @{i}-> Hmmmm, I hope it's useful, and if it isn't, just read it anyway@{ui} * very flexible @{"installing" link "Arrangeren" 0} (anywhere you want!) * including nice MagicWB icon @{i}-> Yep, took me all night just for that one little sucker to draw@{ui} * *free* (!) @{"registering" link "Slijmen" 0} for future updates/tools etc. @{i}-> The only (but patient ;-) road to success (???)@{ui} @endnode @node "WaEddeNuudig" "Requirements" @toc "ImpressieMaken" @prev "sHoWYAsTupH" @{b}@{u}Requirements for DiskSqueeze (DSQ)@{ub}@{uu} · an Amiga ;-) : sorry, since PackDev isn't supporting PC/Unix, forget it porting DSQ-archives to Aminet etc... but DMS is now also forbidden for uploads onto Aminet, and Aminet is planning to use a 24hr/day Amiga for checking viruses, making it possible to use any Amiga compressing software for uploads. · a M68000 upto M68060 (M68EC020 or better recommended) Remember to select the correct version of LZX for your CPU. · OS 2.04 (@{u}v37.175@{uu}) or higher : people who are still working with 1.2/1.3 ever heard of FAST Amiga's ? · a 'working' WorkBench or Shell with: most system @{u}libraries@{uu} (DiskSqueeze doesn't use alien libs) the following @{u}directories@{uu}: - ENV: - C: - T: in your @{u}C:@{uu} directory - assign; eval; mount; resident; type; RequestFile; RequestChoice (Hey OS 2.x users!: these last 2 files are included in this archive, and will NOT be found on your WB 2.x disk!) - any textviewer (Like More, PPMore, MuchMore, Less, MCPP, ...) the default textviewer is '@{u}More@{uu}', supplied with your WorkBench disks (use alias if possible for easy integration) (may be located anywhere on your system) - standard DiskCopy command (for DMS handling) - dms.device (for dms.compatibility) · 1 MB RAM : This is theory, expect dogslow compression with this kinda memsize. Even 512 K users can give it a try. However, you need a harddisk or a second floppy drive to work with only 512K RAM. Since 512K users are an endangered species, I would suggest 2 MB of RAM as a good minimum. Fast RAM makes everything MUCH faster (upto 4 (=FOUR) times !! > You'd be surprised!) 4 MB is more than enough for DiskSqueeze when not using the two RamDrives and the T: temporary storage dir at the same time (checked by DiskSqueeze) A harddisk is still very recommended for crunching, but from 3 MB onwards, not really recommended anymore. !BUT! if you wanna squeeze HD disks (1440/1760K), add 1MB of reserved harddisk-space (or RAM) · LZX 1.20/21 evaluation or registered copy (check Aminet: util/arc) See LZX docs for more info on this · all other files (PackDev, DiskType, GetChars, PathName, ChDir, DirII & OS 2.0 requesters) will be installed by the installer script, using the Commodore 'installer' program (found everywhere, except in this archive) · all the necessary files (except the commands) are checked by DiskSqueeze when starting it up. They might be placed anywhere on your system. (well, as long as it is in a C: dir (or other configurated path)) Optional requirements: · @{i}MFS 2.x@{ui} = MultiFileSystem (check Aminet: disk/misc) Also not necessary, but if you wanna squeeze MS-DOS or MAC disks, again a must-have. MS-DOS disks require additionally 'CrossDOS' (see Workbench (OS 3.x), Aminet or Fred Fish), MAC (HD) disks require 'MaxDos' or 'CrossMAC'. CrossDOS is installed in 3.x ROM's, CrossMAC has to be purchased seperately from Consultron, the guys behind CrossDOS. For MaxDos, check Aminet biz/demo for more details. Be sure to use MFS v2.2 if you're using the FAST CrossDOS 6 Pro. If you want to have a look at the docs of PackDev, RequestFile (for 2.0) or DirII, check Aminet, it's all there for free! I haven't included them here to save some bandwidth for all you modem-freaks... @endnode @node "Arrangeren" "Installation" @toc "ImpressieMaken" @{b}@{u}Installing information@{ub}@{uu} @{fg shine} @{b}Check@{fg text} @{ub}is a small tool to auto-install all necessary environmental files, except the DSQ temporary path variable, which can be altered in the main program itself... For those who want to install the rest manually, read the following: Since DiskSqueeze! is designed to 'float' on your system, you can place almost all its files wherever you want! Those 'floating' files are: @{fg shine}DiskSqueeze@{fg text} \__together please! @{fg shine}DiskSqueeze.info@{fg text} / @{fg shine} PackDev DirII DiskType GetChars PathName DirII ChDir LZX @{fg text}(not included here)@{fg shine} more @{fg text}(Commodore textviewer, see Workbench disks) Make sure you have all @{fg shine}necessary AmigaDOS command files@{fg text} (see @{"Requirements" link "WaEddeNuudig" 0}) in your C: directory. If you want to make DiskSqueeze a bit faster, make sure you copy the following 9 very small files from your @{b}ENV:@{ub} dir to your @{b}ENVARC:@{ub} dir (if they already exist -> you need to run DiskSqueeze first): @{fg shine} DSQ, LZX, More, DiskType, ChDir, GetChars, PathName, DirII, PackDev@{fg text} Next time you boot your system, DiskSqueeze won't have to look for these tools anymore, but will know straight ahead where they are located (using these ENV files) @{u}Note@{uu}: If you place one of the 9 executable files somewhere else, make sure to re-run the @{b} 'Check' @{ub} tool; it will refresh all needed ENV files (except the DSQ temporary path variable. @endnode @node "Prutsen" "Usage" @toc "ImpressieMaken" @{b}@{u}How To Use DiskSqueeze@{ub}@{uu} Well, the program is pretty self-explanatory, so I won't start whining as "first you click the icon, the you move your mouse to the menu..." Just try it out for yourself, there's nothing you can do wrong, as long as you know what unpacking and packing means... unpacking needs always a device, so make sure that the destination disk (RAD:, DF0:, etc...) isn't containing vital stuph or so... it will be completely erased after an unpacking session ! Therefore: @{i}@{fg shine}This software is provided as-is, without warranty of any kind, either expressed or implied. In no event will the author be liable for direct, indirect, incidental or consequential damages or data loss resulting from the use or application of this software. The entire risk as to the results and performance of this software is assumed by the user.@{ui}@{fg text} ;) For those who want some info, I'll give you some (but it's pretty dull) When starting up with a small system (no HD or low-memory) , DiskSqueeze will check what it can do to avoid lot of problems (disk-swapping, etc.) Make sure you choose a disk-based temporary path, and not something like RAM:, T:, ENV: or so... Mounting RamDrives (automatically) will also be pre-checked by DiskSqueeze, to avoid problems... Disk-swapping can be avoided using the 'resident' command. All this is taken care of by DiskSqueeze, If necessary of course... (at the expense of ± 100 K) If some necessary files aren't present (not DMS. 'more' or 'dd'), and this after a fierce search ;) DiskSqueeze! will complain and exit. See more on this in the @{"requirements" link "WaEddeNuudig" 0} section. Main-menu Options: @{fg shine}Pack@{fg text} This option will squeeze the device you select... (If you wanna know something more about 'mixed filesystems', press @{"HERE" link "DJotMix" 0}) @{fg shine}UnPack@{fg text} This option will decompress an disk-archive. Current supported formats are DiskSqueeze (DSQ) and Disk Masher System (DMS). DiskSqueeze will apply the decompression routines based on the format & eventually extension of the archive. @{fg shine}View@{fg text} With this option you can view what is actually stored inside the archive (not some useless crap like DMS gives you, but (and this is pretty cool) filenames, disklabel, filesizes, directory structures, etc...) All this is made even easier to read by using ANSI colour-codes. See the docs of 'DirII' for more... This option is NOT available by ANY other diskarchiver ! Have fun with it... Oh yeah, when unpacking an archive, you'll get the option to see what you're about to unpack aswell. New is the inclusion if File_ID.DIZ capabilities (>view & pack) There is one important note about this goodie: when your disk isn't using any filesystem (trackdisk loader programs, like most megademos do, and also some games, DiskSqueeze cannot create such a filelist, since there do not exist any 'files' at all ! Note: when packing an empty disk, you'll see that DiskSqueeze will inform you that the disk is using a '@{"mixed filesystem" link "DJotMix" 0}'. This means that there aren't any files found on the disk, but that the directory checksums are valid. Easier explained, this means that the PackDev program would be misled when using the BAM (Block Allocation Map) of the disk to read its contents. It would normally result in an archive of 250 to 328 bytes, which looks a bit too small to be a valid archive (if that would be TRUE...). Therefore, select MixedFs option when this occurs... For those who are DMS-experts: this option is the same 'NOZERO' in DMS. @{fg shine}Convert@{fg text} To convert DMS- to DSQ-archives... nothing special to say about this, I guess... One note : if you cancel the convert function after unpacking, you'll be directly back in the main menu. If you pressed the wrong button, then just continue by selecting 'Pack' and take the same device you were using to convert... @{fg shine}Test@{fg text} Simple checks integrity of DSQ (= LZX archive aswell as PackDev structure) archive. @{u}A special note on how to use the @{bg shine}CUSTOM device@{uu}@{bg back}: just make sure the driver (??.device and mountfile) is installed in DEVS:, then make a environmental file called 'DSQusr', which contains the name of the device. @{b}Example:@{ub} you want to use@{i} FMS device@{ui} with DiskSqueeze: install fms.device (1.0, 1.1, old 2.0 or new 2.0) in DEVS: install FM0: mountfile in DEVS:Dosdrivers (for OS 3.X users) add FM0: mountdata in DEVS:mountfile (for OS 2.X users) then type in a shell-window: @{fg shine}echo FM0: >ENV:DSQusr@{fg text} to make this device work after reboot, additionally type once: @{fg shine}echo FM0: >ENVARC:DSQusr@{fg text} @endnode @node "HoeBeterDoen" "Hints" @toc "ImpressieMaken" @{b}@{u}Hints using DiskSqueeze@{ub}@{uu} - if your disk is a normal DOS disk (Amiga or PC), make sure it's @{u}not@{uu} fragmented. (use 'ReOrg' (Amiga > Aminet) or 'DEFRAG.EXE' (MS-DOS)) This will improve your crunch-speed AND will save some extra bytes (± 5%) from your archive size - use a ramdisk for FAST converting - How 'mixed filesystems' can be detected, click @{"HERE" link "DJotMix" 0} - Making an @{u}DSQ-archive-viewer@{uu} in @{b}DOPUS@{ub} is very easy: just assign a button with following details: name it whatever you want (DSQview or something) @{fg shine} no flags AmigaDOS LZX -m x {f} T: Files.dsq Command FinishSection AmigaDOS Delete T:Files.dsq Command AnsiRead T:Files.dsq Command Notify "Archive listed... (if nothing appeared, it's a NDOS disk)@{fg text} [I know it's weird, but delete it before you ansiread it...] - Making a quick @{u}bootblock viewer@{uu} in @{b}DOPUS@{ub} is also very easy, but requires the 'dd' utility (see Aminet: disk/misc or so): assign again a button with a preferred name @{fg shine} no flags AmigaDOS dd -q -c2 -r{s} T:bootblock Command FinishSection Command HexRead T:bootblock AmigaDOS Delete T:bootblock@{fg text} - Since I anticipated all problems during packing, I cannot give any more hints... ;-) @endnode @node "StrontADKnikker" "Troubleshooting" @toc "ImpressieMaken" @{b}@{u}TroubleShooting@{ub}@{uu} What can I say ... ? Since most of the errors are explained in the program itself, I can hardly add much to it... Just here are a few reminders: To make sure that all @{u}required commands@{uu} are present, check the installation page (@{"HERE" link "Arrangeren" 0}) If files are @{u}corrupted@{uu}, LZX cannot unpack the archives, so DiskSqueeze can't do much about it... pity for you... Don't try to @{u}unpack a high-density disk@{uu} or 'fremdformat' (other FS, like MSDOS or MAC) to ramdisk... (see bugs) Make sure your @{u}path for temporary storage@{uu} (see 'ENV:DSQ') ends with a ':' (for devices) or '/' (for directories). if it isn't, DiskSqueeze will force you to choose a valid one The opposite is applicable for @{u}filenames@{uu} (as always) : please don't try to use ':' or '/' in a filename (read your AmigaDOS manual for more on this!) @{u}Save memory@{uu} doing the following easy steps: - close all your non-DiskSqueeze windows - don't choose for the non-disk-swapping option if DiskSqueeze asks for it - quit all applications (screenblankers, jingle-tools, etc...) - replace the line in your S:Startup-sequence saying "LoadWB" with "LoadWB -debug" Now choose in the 'Debug' menu (next to the 'Tools' menu in WorkBench) the 'flushlibs' option... this frees more than avail flush (which is already done by DiskSqueeze! anyway) If you accidentally clicked 'ROMWack' (a terminal debugger), just wait 25 seconds and your machine will unfreeze again (on a 040 it is 25 secs, maybe more on a slower Amiga?...) - choose a disk-based temporary storage path - remove ramdrives and REBOOT your computer - don't use ramdrives (but DiskSqueeze will check if this is possible) Unexpected failures do occur with @{u}pirated versions of LZXr@{uu}... Ask the author of LZX for more about this... he'll probably smile... (a failure of the archive itself is also possible... I warned ya! ... 8-O If you can't @{u}temporary store@{uu} your image onto a 880K floppy, try diskspare device (found on the Aminet), which gives you over a whopping 1,000,000 free bytes on a standard Amiga 880K disk... No more troubles to shoot... (I hope) If you have any difficulties with your Amiga, don't hesitate to @{"contact me" link "Stoefen" 0} (I am very friendly, you know ;-) @endnode @node "Verdjuu" "Known Bugs" @toc "ImpressieMaken" @{b}@{u}BUGS in DiskSqueeze@{ub}@{uu} :-/ Although I have put every effort in this program to avoid bugs (I even made some 'fake' archives to see how DiskSqueeze reacted on them, and afterwards I enhanced the script to avoid bug-traps)... However, there are some bugs I cannot workaround (yet?) 1.@{b} PackDev + DirII@{ub} bug : if your AmigaDOS disk is using a valid filesystem, but some asshole added an endless directory-loop or made the disk unreadable using @{i}root/dir-header editing@{ui}, DiskSqueeze will hang. I have encountered only a few (old) disks who had these fucking directories ('CCS Musicdisk', almost all 'Bitstoppers' cracks, almost all Bamiga Sector One cracks (hello Peter!) and 'Ports Of Call' (cracked by 'Warriors o/t Wasteland'). The games were hacked ones, so you legal guys can be assured that you normally will never encounter these nasty disks. The only solution to this is copying the files of the disk to another empty DOS disk or do some sector-editing (removing the 'looped' directory headers, but be careful, always try this on a copy first!) 2. @{b}AmigaDOS@{ub} bug : If a ramdrive is unmounted with 'remrad', the system will still recognize that ramdrive... PackDev will certainly complain... Restart your machine after a remrad if you wanna re-use your ramdrive(s) (also assign dismount cmd won't help) 3. @{b}DSQ@{ub} bug : if you're processing high density disks, remember to add ONE megabyte of memory to the minimum requirements for memory (cause DiskSqueeze won't ;-) Normally, people with highdensity drives are serious users, with plenty of RAM...=) 4. @{b} DSQ@{ub} bug : Unpacking HD-disks and/or MS-DOS disks (or whatever filesystem, like MAC) to the ramdrives will result in a failure EXCEPT when using a custom device 5. @{b}DiskCopy@{ub} bug : when unpacking a DMS file, and you want to unpack it to a disk which was originally unformatted or formatted with a different number of cylinders, DiskCopy will complain that source and destination do not have the same format. Just quickformat unformatted or alien disks before unpacking disks. @endnode @node "Vroegere" "History" @toc "ImpressieMaken" @{b} @{u}DiskSqueeze History@{ub}@{uu} I'll save you from all the beta-versions with their ommitments and bugfixes, but I can assure you that it was sometimes very hard to find where those nasty bugs came from, not forgetting all those times that my backups f**ked up. The only thing I can tell you about early beta versions is that 83 tracks were supported upto version 0.75b, but then kicked out because it was just too unstable. I'll save you most of the crap history stuph regarding xDM 1.1 - 1.3, the 'father' of DiskSqueeze, since this tool has been erased from Aminet anyway. Some short crap follows: xDM 1.0 : written by Adam Chapman xDM 1.1 : small bugfixes, 4 floppydrives support, 'looped' [done by ME - unreleased] xDM 1.2 : bugfixes, 1 ramdisk avail, dd implemented, better ASL config [Aminet June '95] [Adam didn't react on my snail-mail message] Biggest mistake was here to release it as xDM. I better had renamed it already then to DiskSqueeze. It would have saved me alot of troubles. xDM 1.3 : bugfixes, PackDev implemented, multifilesys, xDM backwards compatible, AmigaGuide docs [appeared on Aminet July '95 & Amiga Shopper October '95] [Adam finally phones me, and erases xDM from Aminet, without telling me this > I got the message from Urban Müller himself] xDM 1.4b: bugfixes, 2 ramdrives supported, DMS convertor implemented [unreleased] Since then, Adam asked me to 'hand over' my ideas to him, but I didn't like this, because it didn't go fast enough + too many bugs in his BETA's (more than in my (previous) xDM 1.3 !). Finally, I could persuade Adam to implement PackDev... (he sticks also with 'dd' for some unclear reason). I also think he will include DMS compatibility in xDM, since I suggested that to him too (not included in xDM 2.0beta5, though) Since I was told by Adam that he wanted to do all, and I would just be a silly beta-tester (I found that out soon after), I was pissed off even more than when I read Urban's mail... So I went my own way, developing DiskSqueeze, based on MY xDM 1.4c version, NOT Adam's 2.0 beta's (OK?). Further improvements were: - OS 2.04 compatibility (thanks to Rainer Koppler for suggesting me this) (> without seperate versions, as originally planned) - high-density/MSDOS/MAC etc. support - DMS support - xDM support ;-) - File-format-recognition for DSQ/xDM/DMS - File-list included in archives of valid DOS disks - File-list extractor for valid DOS archives - all bugs removed (?) - memory dependent operations - better device-handling - 2 ramdrives supported - read short-readme for more I hereby officially announce that I'm NOT affiliated with xDM anymore. The only thing I was really pissed about was the fact that when xDM 2.0 was released on the net, Adam 'forgot' to mention me, and moreover, his code contained quite some of mine. Ok then, if he played it that way, I could could play it the same way. Luckily for me, some other people mailed me about problems with Mr. Chapman. Chapman removed my DiskSqueeze from Aminet, saying it was stolen from him!!! Now I went really mad, so I mailed Urban Mueller with the request to remove xDM 2.0 because of its illegalty, I included mail from the other folks to prove my credibility. It must have been weird days for Mr. Mueller, because he had to replace DiskSqueeze (but too late to be re-placed on the CD version of CD 8 - DSQ is still in the list of the CD, but the program is not on the CD itself) and removed xDM (finally, but too late to remove it from the CD). Although Urban promised me to include DSQ on CD 9, it never appeared again. So for the guys who still wanted DSQ, well, they had to download it from Aminet itself. I hope all this shit is now resolved with this new release. @{bg shine}Bugfixes from 1.00 to 1.01@{bg back} Oops, even registered users were insulted as @{i}'wussie pirates'@{ui}... sorry if some registered LZX user felt offended by this... It's 100% my fault, and I apologise for the inconveniences... Ok, what went wrong ? Well, the algorithm to detect a pirated keyfile was OK, but it was again the 'VAL EQ' instruction which caused the trouble (I do really think this is some flaky bug in the OS, since it gives sometimes the good result, and the next moment it's wrong ... ??? That's what happened here ... All was cool and working (even with my valid keyfile), but then the f**ker refused to accept my keyfile... I have encountered these problems more than once while developing DiskSqueeze!, and I dunno what the reason for this flaky behaviour of VAL EQ 0 ... Anyway, I made another trick to check, and this time, no more problems can occur... I also replaced PackDev with the latest release 1.5 (thanx Chris), so bug number 2 was resolved too (the noconfirm stuff -> see dox of DSQ 1.00) This version appeared on the coverdisk of Amiga Computing issue June (or July). Thank you guys! @{bg shine}V1.01 to 1.10@{bg back} Euh, I cannot recall what was changed, so I just list some of the improvements from v1.01 to 1.20 - fixed bug for viewing filelist - added file_id.diz - switched to dms.device (finally got rid of buggy dms.exe) - removed xDM compatibility (xDM 2.0 format was a mess, so no support) - added new programs into DSQ for remembering paths - now checks archive using bytechecks, not just extension - made verify on/off switch when writing to disk - added double-layered test option - autodisplay file_id.diz when unpacking or viewing - added custom device - minimized use of mountfiles (they're incorporated now) - minimized use on global variables - added script flag - localized DSQ (well, not really, just made diff language versions) - removed LZXr authenticity test (would give probs anyway) - made zillions of small bugfixes and improvements, not worth mentioning here - ommitted ! from title (was too annoying because I forgot it all the time) @{bg shine}improvements from v1.20 - V1.21@{bg back} too many/trivial to list here, but lots of thanks should go to Max Headroom and Jorma Oksanen for all the help - too bad the amiga community isn't overcrowded with such guys. @{bg shine}improvements from v1.21 - V1.22@{bg back} - made a workaround for a possible bug in PackDev 1.8, which made it for DiskSqueeze 1.21 unable to read mixed-mode disks correctly. Thanks to Tony for pointing this out to me. I hope this time he ditches DMS forever! But make sure you use PackDev 1.8 from now on! - corrected the version number (not a beta number anymore) @endnode @node "NaUnNiefWijf" "Future" @toc "ImpressieMaken" @{b}@{u}Future plans with DiskSqueeze@{ub}@{uu} - a GUI/AREXX version - check out the 2 iff pics in the archive to see how it looks... It will support all possible drivers with upto 100 devices per driver. (for those who have 50 ramdrives running on their system :) Hopefully I will be able to compile it to assembler using a REXX compiler. - a Windoze95 version ...??? Over my dead body! - ??? ... let me know PS: since raw tracks and 83 tracks aren't really used anymore these days, I dropped my intention to develop such DSQ version in the far future. @endnode @node "Slijmen" "Free Registering" @toc "ImpressieMaken" @{b}@{u}Registration info@{ub}@{uu} @{u}How do you register ?@{uu} DiskSqueeze is @{i}'pictureware'@{ui}, which means that you'll have to send a picture to me (in digital format - ANY format is OK (PCX/GIF/IFF/JPG/PCD)) of something weird or nice... (a nice chick is a (very) good suggestion ;-) Include a list of your current computer setup aswell Snail mail is OK, although I prefer e-mail for fast replies... See @{"Author" link "Stoefen" 0} for all the address stuph... @{u}What do you get for this picture in return ?@{uu} - FAST & longlife updates/bugfixes/hints/help/etc (e-mail only) - some interesting mail now and then about new Amiga developments (e-mail only) - a 'binary' surprise... 8-) - you become a beta-tester for DSQ, but only if you want to Other reasons to contact me: you have a lot of @{b}garage underground-house music@{ub}, and like to swap some cool tracks on MC, CD or MD (I have over 1500 CDs and 300 12") I'm still looking for tracks like "Fibre Foundation - free your mind" or "DJ Device - positive influences EP 1" or "Disco Elements - EP 3" or "CLX - life will make you dance", Grant Nelson or Danny Tenaglia cuts. you are a @{b}Level 42@{ub} fan : I'm still missing some live performances and remixes. I can supply you with alot of rare material (even CD video material) on MC, CD or MD. Just send me a list of what you got, and I'll be grateful to reply in a generous way, if you have something I don't @endnode @node "Stoefen" "Author" @toc "ImpressieMaken" @{b}@{u}Info about the author@{ub}@{uu} name: @{b}Dirk Vael@{ub} born: 1972 @{u}address:@{uu} @{fg shine} Merellaan, 33 B-9060 Zelzate (silly) BELGIUM (Europe)@{fg text} @{fg shine}tel & fax: +32-93447196@{fg text} if you want to have fast snail-mail replies, use this address instead of my home address @{u}email:@{uu} (one of my brother's, used by me all da time ;-) @{bg shine}marc.vael@ping.be@{bg back} Have a university degree in Applied Economics (graduated with thesis on Amiga) and a university degree in Master of Business Administration (MBA), both obtained at UFSIA university (see http://www.ufsia.ac.be) Also gave courses on LAN networks, Internet, operating systems and productivity software during last two years. @{u}current activities:@{uu} Just amusing myself re-mastering & re-recording my garage vinyls on MD and CD using my Toccata w/ MS-Samplitude-software, an SL1210, two Sony MD-recorders and sOOn a CD-R thang (read further on). In the meantime: looking for a j.o.b. ;-) @{u}hobbies:@{uu} -Amiga, esp. the high-end stuph (since 1988) -Garage music (like @{i}Grant Nelson, Strictly Rhythm stuph, M@W, Roger S, CJ Mackintosh, Carl Craig, David Morales, Todd Terry, Italo grooves, iT, Nervous records, Ministry of Sound, Azuli, Tribal US/UK, etc etc)@{ui}...) For Amiga-users living in London, just check out Kiss 100 FM on Tuesday 7-9PM (Steve Jackson) or Saturday eve (9-11PM) with Paul 'Trouble' Anderson to know what kinda music I love more than I would love any women ;-) -DJ'ing at local (house-)parties -IndyCar and Formula 1 racing (euh, watching it of course) -Beavis'n Butthead (they're like.. euh...cool.. huh huh huh) -women, especially the nice ones ;-) (hi Kirstien!) @{u}DiRkiE's fuNNy coNfiGzz:@{uu} A500/000 7 Mhz 1 MB slow RAM A1010 880K external diskdrive (3,5") StereoMaster 8-bit stereo sound sampler Philips CM8833 stereo monitor A4000/040 25Mhz 2 MB chip RAM 16 MB fast RAM (70ns) Seagate Medialist 2.1 GB EIDE harddisk (over 2 MB/s!) Mitsumi IDE double speed CD-ROM (using Tandem interface) Toccata 16-bit soundcard (linked with Denon DCD-1015 (CD), Sony MDS-302 & Sony MZ-R3 (MiniDiscs)) 2 × 1.76 MB internal diskdrives 5.25" 880K external diskdrive MicroVitec A1438 multisync monitor HP LaserJet 4L printer OS 3.1 (OS 1.2/1.3/2.04/3.0 softkicked w/ Set040) (both machines are linked through a serial cable - for Skidmarks & Lotus!) In September'96 I'll gonna buy me a Oktagon-4008 SCSI interface together with an external Philips CDD2000 SCSI CD-Recorder (so I can use it on Amiga aswell as on the PeeCee thing), mainly for putting my vinyl on CD. 486SX40 desktop 16MB ram, 420+170MB HD running Lose95 486DX66 portable 8MB ram, 350MB HD, colour display (a cute machine!) Pentium 133 full tower, 16MB ram, 2GB SCSI-2 HD, 28.8 V34 modem, Soundblaster AWE32, 17" multisync, ultra-fast Matrox 64-bit PCI-SVGA 4MB w/ MPEG, Plextor 6xspeed SCSI2 CDROM, HP LaserJet 5L; all running under Lose95 (aka MS-DOG 7) Psion 3 256K with 1MB flash & worksheet card (funny thing, but 3a is definitely cooler, Marc) @endnode @node "JoowDeMannen" "Salutes" @toc "ImpressieMaken" @{b}@{u}Thanx must go to the following friendly Amiganoids:@{ub}@{uu} @{b} Frank Verheyen@{ub} : Keep programming, dude! @{b}Tim Groenwals@{ub} (tgroenwa@zorro.ruca.ua.ac.be) and the guys of HCC Antwerp (Amiga division) for helping me with my thesis... @{b} Jonathan Forbes@{ub} for the awesome LZX program. (too bad it's dead :( (jonathan.forbes@canrem.com) the Amiga store '@{b}Hirsch & Wolf@{ub}' (in Germany) for excellent service I am also grateful towards the German Amiga-shop '@{b}Off Limits@{ub}' for great service & prices. @{b}Oliver Hitz@{ub} (oliver.hitz@unifr.ch) for his LJ4-Boost proggy @{b}Christian Wasner@{ub} for PackDev (crisi@blackbox.shnet.org) @{b} Simon Dick@{ub} for his handy RequestFile for 2.0 owners @{b} Stephen Davies@{ub} for his excellent DirII tool (I love it!) 2:2500/73.18@fidonet @{b} Paul Reeves@{ub} at @{i}AsimWare Innovations Inc.@{ui} Canada (reeves@guy.asimware.com) @{b} Geert Peeraer@{ub} at UFSIA for all the help (check our http://www.ufsia.ac.be) @{b}Tony W.@{ub} for keeping me informed about all kinda Amiga 'thingies' @{b} Tim Stalmans@{ub} for bug-reporting (tim_stalmans@metnet.demon.co.uk) @{b}Rainer Koppler @{ub}(Köppler?) for the e-mail and registered (and patient) DSQ users (thank you all for the mails and many firepower map-editors): @{b} Val Hite Mikael Grahn Oksanen Jorma Franck Aniere Julien Wilk Gary Smith Michael 'Max Headroom' Taylor Georg Hazianastasiou Dennis Eijs Yves Bouchy Alexander Lovell Steve Thomas John Wells@{ub}, author of@{i} CCB@{b}@{ui} Mark Knibbs@{ub} (I believe I forgot a few still stuck in my university mailbox...?) The rest of the Amiga-community (including the magazines, esp. @{b}Dave @{ub}@@{i}Amiga Shopper@{ui}), or @{b}Neil Mohr@{ub} @ @{i}Amiga computing@{ui}, but not the lamers, like "@{i}Click!@{ui}" My brother @{b} Luc Vael@{ub}, lawyer, for allowing me to drive his MGF car (wOw!) Thank you @{b}Paul@{i} 'Trouble' @{ui}Anderson, Steve Jackson@{ub}, and all DJ's spinning the groovy 'tech-funk' tunes from Chicago. London and NY every day. @{b} Tommy Vandaele@{ub}, my partner in crime, along with@{b}@{i} 'Rikske'@{ui} Verlinde@{ub} and @{b}@{i}'Koentje'@{ui} Verschueren @{ub}. Also big shout to @{b}Kristien, Elke, Sofie, Liesbeth, Katleen, Myriam, Viki & Gitta@{ub} for their charming company in Antwerp! ;-) @{b} Ruby & Viete@{ub} (for their SL-1210's and professional Technics/Denon/Luxman audio hardware)... keep the vibe alive guys... @{i}And remember guys:@{ui} @{b}@{u}Wintendows95 from Mickeysoft needs an MMU (Marketing Management Unit) to run@{ub}@{uu} (next to the Pentium w/ 16MB ram + 500 MB hd... and this with MS-DOS as OS) You DO know that Win95 is NOT an operating system, but just a *16* bit (and not 32, just some kernel stuff is 32bit, but most of it is 16bit!!) resource-hungry front-end for 11yr old MS-DOS, with 640K base mem, FAT filesys, .... ? Hahahahaha .... Win95 ... 1995 ??@{b} Win85@{ub} sounds better! @endnode @node "PoepjeRuiken" "Technical Info" @toc "ImpressieMaken" @next "DJotMix" @prev "JoowDeMannen" @{b}@{u}What is DiskSqueeze in fact doing ?@{ub}@{uu} To put it very simple: DiskSqueeze uses a ± DMS-like way of reading disks, and compresses the whole image (and not track per track, like DMS does) as a file with LZX. See also note on xpkLZX.library & PackDev. To put it not so simple: DiskSqueeze uses a combination of various tools (9 for the moment) connected in some way to each other using a very complex AmigaDOS script. The tools are: @{b}DirII@{ub} this tool is just a dir+list replacement, and is used in DiskSqueeze to store the filelist of the AmigaDOS/MS-DOS/MAC etc. in the archive. It is better than dir or list because it has much more parameters and gives a nicer (ANSI) output too >version 3.3a supported @{b}PackDev@{ub} a very good disk-reader, with optional XPK support (not used in DiskSqueeze). Will support more filesystems in the future. >version 1.7 supported @{b}DiskType@{ub} a small tool, just to check whether a disk is inserted or not, and if so, whether it's a DOS disk or a NDOS disk >new enhanced assembler version supported (nowhere else available) @{b}LZX@{ub} excellent file compressor. Very hard to get registered, since I've waited over 9 weeks for my keyfile, (my disk was probably lost in mail, but J. Forbes was so friendly to send my keyfile through e-mail. Thanks Jonathan) But beware, the pirated versions of the lzx.keyfile and standalone LZXr that I have, are very unstable and buggy, due to the two-level protection incorporated in LZX. I cannot say more about this, because Mr. Forbes asked me to ! @{i}(BTW, I am really registered!)@{ui} And believe me, I'm not joking (hacked LZXr versions sometimes 'forget' files to add, just to give an example of dangerous situations when being lame...) >version 1.20 or v1.21 registered supported GetChars excellent bytegrabber, designed by me, afterwards written in C by Frank Verheyen, and then rewritten in assembler by Jorma Oksanen. Frank has made a pro version, with powerful extras, and expect it to see Aminet some day. Registered users of DiskSqueeze can get this version already. >version 1.1 supported PathName tool to extract pathname so DSQ can 'remember' previous directories (very useful when you (un)squeeze alot. Thanx to Max Headroom for the hint. >version ?.?? supported ChDir a DMS tool, needed to handle dms archives as devices (VERY easy, but not bugfree, like all other DMS tools - sigh...) >version 1.1 supported Programs no longer needed (since DSQ 1.01): @{b}DMS@{ub} whew! @{b}dd@{ub} I simply ditched xDM compatibility... The script is about 500 lines big, written in pure spaghetti-style ;-) and it uses no more (!) temporary variables (in ENV: dir). But, some strings always reside in ENV: , namely the locations of the necessary tools & 'DSQ'. See @{"installation" link "Arrangeren" 0} for more on this. Advantage of this modular view is that the tools, especially PackDev and LZX, can be replaced with updates as soon as they become available. Expect PackDev 2.0 and LZX 2.0 soon (?), just to give an example of this. These updates are more likely bugfixes + further refinements of the current versions. Expect updates of DiskSqueeze in the future, if new options are implemented in LZX or PackDev. Also, when bugs are removed, I could make the script a bit shorter, in removing all sorts of workarounds to deal with those nasty bugs (see @{"Bugs" link "Verdjuu" 0}) Unformatted disks can be inserted aswell to unpack to, using the enhanced trackdisk format routine in PackDev (set by DiskSqueeze) (NOT for DMS!!!) @{i} Multitasking Info@{ui} When @{u}LZX@{uu} is packing, all other tasks will NOT be frozen (previous version of DSQ didn't allow multitasking). If have * NOT * changed the task-priority for @{u}PackDev@{uu}, because I wanted to give resident virus-checkers the chance of checking a disk when it's inserted (before PackDev can lock the device). @{i} Memory Information@{ui} Memory is checked when selecting ramdrives -> no problem For guys with systems with only 1 MB of RAM, the buffer of LZX is the default 64K When having 2 MB of RAM, LZX works with a 256K buffer When having 3 MB of RAM or more, LZX works with a 930K buffer (fastest) LZX isn't using a disk-based workdir, since this is only used when really 'adding' files to existing archives. This is not the case for DiskSqueeze, where only a (small) filelist (or FILE_ID.DIZ) is added, if it exists. And environmental files aren't supported in LZX anyway... 'More' is not made resident by DiskSqueeze, because it isn't necessary for basic operation... the others are (AmigaDOS command 'type' isn't made resident too...) @{i}Other things you shouldn't know ;-)@{ui} DiskSqueeze was developed with a 800x600 resolution and a XEN-9 font. I have tested it also with a 640x256 and the default Topaz-8 font, just to avoid any 'invisible' text... So no problems should occur... Something big about @{"'Mixed Filesystems'" link "DJotMix" 0} @{i} DiskSqueeze was made with...@{ui} A4000/040 (see @{"Author" link "Stoefen" 0} for config) GoldEd Heddley (Hello Ed, great job, except for da Buggz!) Directory Opus DiskMonTools ilbm2ascii Set040 @endnode @node "DJotMix" "HERE" @toc "ImpressieMaken" @next "Cijfers" @prev "PoepjeRuiken" @{b}@{u}A word on 'Mixed FileSystems'@{ub}@{uu} 1. @{u}Normal AmigaDOS disks (also for MAC and PC)@{uu} The normal Amigadisks are using the AmigaDOS filesystem as the standard system to store files. This filesystem uses file-headers, directory blocks, a root block, checksums, cache blocks, links, data blocks and more... The connection between a directory/files and the actual disk-sectors goes via checksums and headers... The 'trackdisk.device' will handle the actual sector/track reading. This system has the disadvantage that it's slower than direct track access + it's eating disk-capacity before even 1 byte is written to disk. (ex: a 4.3 Gig HD loses about 300 K when being formatted) The big advantage of a filesystem is of course the easy and clear way of managing various data on a disk (adding, deleting, replacing, etc.) Some flavours of FS were added during the C= Amiga years, like FFS/DC/INTL, next to the OFS (read the AmigaDOS manuals (or my thesis ;) for more) >> All these formats are supported by DiskSqueeze 2. @{u}Trackdisk disks (Amiga only)@{uu} Some dudes then discovered that it's easier to write their data straight to the tracks, ignoring the filesystem... Only the bootblock stays valid, but the rest of the disk is unreadable when accesses via AmigaDOS. The bootblock contains specific info about how to start reading sector x to y, and if more has to be loaded afterwards, programmers can still code this reading session in the intro or so... Moreover, you can't access the files with a directory utility or a filezapper, making it harder to modify datafiles (or hack it). Lot of games-firms use this system because they can cram more on one disk and the access is much faster than the ordinary way... Also almost all megademos on Aminet are coded this way. >> This format is supported by DiskSqueeze 3. @{u}'Nibbled' disks (Amiga/PC ... MAC???)@{uu} Some dudes went even further, and used another system than the normal trackdisk.device (SYNC's, MFM, etc...), making the disk unreadable, even for sector editors (like @{i} DiskMonTools, SmartDisk, DiskX@{ui}, etc...) Very handy for disk-protection systems, but as always, hackers are just always a bit smarter ;-) [some hackers are now making money legally, making copy-protections or so...] :-| Also some PC programs use (track 81) MFM protection routines... Only lowlevel access to disks makes them readable, but then you gotta know alot more about disk access in general. @{i}DiskMonTools3@{ui} features an MFM lowlevel sector editor (see Aminet) example of this: Carrier Command >> This format is NOT supported by DiskSqueeze (it was once! cf. history) Now back to the trackdisk.device story: 4. @{u}'Mixed FileSystem' disks (Amiga only)@{uu} THIS IS *VERY* RARE, AND EVEN NOEXISTANT FOR SERIOUS SOFTWARE. MOSTLY GAMES AND FEW MEGADEMOS CAN HAVE THIS SYSTEM (about 1%) Then came a nasty spin-off of this trackdisk-approach... what if you use a valid AmigaDOS filesystem (with dirs etc.), ** AND ** some 'invisible' data, written directly to tracks, and not using a fileheader or whatever... Well, a diskcopy won't make your copy of such a disk faulty, but with a mere copy of just all files, you're far from success... If those guys, who made the disk, have ticked the used sectors in the bitmap or BAM (Block Allocation/Available Map -> cf. FAT (file allocation table) with MS-DOS)), no problem will arise with DiskSqueeze. (but still with copying just the files). I know five (OLD!) examples of such disks, namely "FirePower"¹, "Faerytale Adventure", all disks using "BootGirl" (display a picture before the actual disk is booted), all cracked disks from HQC with an intro on it, and all faulty disks processes with BFormat (allocates bad sectors as used, just like all harddisk-filesystems do). ¹: some versions of FirePower are not using mixed FS, some others do @{u}Note@{uu}: NEVER defrag such disks (using ReOrg etc. will destroy them!) @{i}4.A Using bootblocks@{ui} However, with (cracked) games who have an intro or trainer-menu using the bootblock to start the up, it's a different story. If a virus or so erases your bootblock, you'll notice that the disk won't work anymore (or in the best case, just the trainer menu/intro is gone) >> DiskSqueeze cannot recognize this type of disks (yet?), and if no utility is released to check whether a bootblock contains trackdisk-read code, it will stay this way. Come on, someone do the job ??? If you are a happy owner of '@{i}RattleCopy v4.0 Pro@{ui}' (written by Peter Van Campen, a dutchie, back in 1991), there's a bootblock analyzer included in this copier, which makes it possible to show all sorts of instructions in a bootblock (reads mouse or keyboard, changes screen-colour, reads/writes data from/to disk, filter switch etc etc etc). Sadly, this utility doesn't work on my A4000/040. Strangely enough, v1.0-v2.2 works fine on that same machine, so I think the display-routines are not AGA-happy... Anyone knows anything to help me ??? I have also noticed that games from the @{i}Bitmap Brothers@{ui} (Xenon I/II, SpeedBall I/II, etc.) have just an empty directory. As sort of protection for these type of disks, DiskSqueeze @{u}will@{uu} check if the directory is empty. Just try to archive an empty disk, and see what the program will do... IMPORTANT NOTE!: Since the ramdrive does not support a custom bootblock, it's impossible to start a NDOS trackdisk.device disk from ramdisk. However, the custom bootblock is present (but just ignored when booting). Therefore, @{b}you can use the ramdrives to convert/unpack/pack NDOS disks without any problem@{ub}. @{i} 4.B Using file-based sector-readers@{ui} Also, and this is even more bothering me, there are disks which use a normal DOS bootblock, but have an executable somewhere on the disk which loads tracks straight into memory, bypassing the filesystem... These disks can only be detected by testing and listening to your drive whether it makes a vibrating noise (= heads which are skipping tracks real fast) Another trick is checking if the disk contains few little sized files on it, while the program seems to load alot more while running... (example: "BattleChess") Yet another trick is optimizing your suspicious disk with a reorganizer or optimizer, like ReOrg or XCopy, and see if the copy still works... if not, it's a mixedFS disk. Last advice, for the real manic freaks, is just copying the files to another fresh formatted disk, and test whether the program still works on the copy. >> DiskSqueeze cannot check for these disks-loaders, but you can archive this kinda disk without any problem, as long as you select YES at the Mixed FS question (when you're packing) @{i}4.C Using MFM techniques@{ui} Even bigger crap. Combines AmigaDOS with MFM tracks... Where did they get such idea ? Example: Fright Night (it's indeed a nightmare!) @{fg fill}I hope this clears up a bit the latin for novice Amiga users...@{fg text} @endnode @node "new" "whatsnew" @{b}@{u} What's new?@{ub}@{uu} to briefly sum up: - writing to disk goes 100% faster - DMS-archives (any version) transparantly handled - DMS-archives can be automatically converted to DiskSqueeze-archives - no memory (or disk) required to handle DMS-archives - buggy DMS executable no longer needed to handle DMS-archives - DiskSqueeze-archive TEST option added - File_ID.DIZ option added - now using assembler-tools for extra speed (thanks Jorma!) - several bugfixes, enhancements and new extras - ditched xDM compatibility These docs are still incomplete (no benchmarks or indepth info), but I was short of time. Forgive the errors left in it. They will be updated with the next release. @endnode