Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!uunet!world!jon_sree From: jon_sree@world.std.com (Jon Sreekanth) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: [Was Perstor...] EXPANZ triples HD capacity; vendor? Technology? Message-ID: Date: 30 Dec 90 17:15:14 GMT References: <9012281359.aa02212@PARIS.ICS.UCI.EDU> Sender: jon_sree@world.std.com (Jon Sreekanth) Organization: The World Lines: 64 In-Reply-To: baxter@zola.ICS.UCI.EDU's message of 28 Dec 90 21:59:30 GMT In article <9012281359.aa02212@PARIS.ICS.UCI.EDU> baxter@zola.ICS.UCI.EDU (Ira Baxter) writes: Can you tell us a) who makes the EXPANZ card, and b) roughly how they do this? I didn't think there was time for enough flux transitions on a track to triple the number of bits. Does the driver compress files as it writes them? How can work when storing, say, a .ARC file? PC Magazine, Nov 13, page 43, covered this card in their First Looks section. The "fact file" summary box says : InfoChip Systems, 2840 San Thomas Expressway, Santa Clara, CA 95051 800-447-0200, 408-727-0514. List $199 Requires any non-MCA expansion slot, 512K free RAM,. 1 MB free on hard disk, DOS 3.0 thro 3.3. In short : An expansion board that transparently compresses files written to virtually any DOS disk. The savings in disk space might not be worth the restricted use of disk utilities. My summary of the article : It's a half size 8 bit bus expansion card, has one ASIC sorrounded by glue chips. The hardware is fast enough that there is no visible inefficiency due to compression/decompression. A disk must be initialized with the software, then a 30K driver must be left installed in RAM. Presumably, the software traps disk access calls and forces disk data to go through the card. Does not work with DOS 3.31, 4.0, OS/2, or network operating systems. Compression ratios are impressive, upto 1.6:1 for executables, 2:1 for ascii files, 10:1 for graphics (PC Mag's test numbers). The safety margin provided by disk utilities is lost. The product tricks DOS into thinking the files are their original size, while actually storing them in a compressed form in a smaller number of sectors. The question of compressing an already compressed (ARC'ed) file is interesting, but was not answered in the article. Hopefully it's smart enough not to have a larger compressed file than the original. The right place to put compression is in the hard drive itself; this eliminates the software hackery. Computer Technology Review, Dec 90, had a good article on page 26. Briefly, the reason it's not already available is : disk architectures and chips are highly integrated, and there's no place to sneak in the compression, error correction is more problematic, and the "transparency issue". Transparency means issues like, for example, DOS knows the uncompressed file size, but until compression is completed, the drive does not know the compressed file size. (The article was written by a Maxtor Corp engineer, so presumably drive makers are looking into the issue). Regards, / Jon Sreekanth Assabet Valley Microsystems Fax and PC products 346 Lincoln St #722, Marlboro, MA 01752 508-562-0722 jon_sree@world.std.com