anthes@geocub.greco-prog.fr (Franklin Anthes) (10/13/90)
I'd really like to find an amiga device (comp:?) which would automatically
compress/decompress any files stored on it. I don't think such a device would
be able to handle direct access ( it could probably fake it though ). But
it still would be a really usefull tool.
You're a little tight on disk space? Just copy some files over to to the
comp: device, delete the originals and voila you have some free space on
your disk. Of course all the other operatations on files (execute,delete,
read,write,rename etc.) would be supported.
Does such a beast exist already for the Amiga? If not is this a feasible idea?
This would have to be a Dos device, wouldn't it?
--
Frank Anthes-Harper : Bien le bonjour de la France
anthes@geocub.greco-prog.fretxtomp@eos.ericsson.se (Tommy Petersson) (10/15/90)
In article <291@geocub.greco-prog.fr> anthes@geocub.greco-prog.fr (Franklin Anthes) writes:
-
-I'd really like to find an amiga device (comp:?) which would automatically
-compress/decompress any files stored on it. I don't think such a device would
-be able to handle direct access ( it could probably fake it though ). But
-it still would be a really usefull tool.
-
-You're a little tight on disk space? Just copy some files over to to the
-comp: device, delete the originals and voila you have some free space on
-your disk. Of course all the other operatations on files (execute,delete,
-read,write,rename etc.) would be supported.
-
-
-Does such a beast exist already for the Amiga? If not is this a feasible idea?
-This would have to be a Dos device, wouldn't it?
---
-
- Frank Anthes-Harper : Bien le bonjour de la France
- anthes@geocub.greco-prog.fr
It seems like this would be a good thing... One could start with a software
compression scheme and incorporate it in an OS release. By adding one of
the existing processors that can be used for compression and some driver
software, someone with more bucks could get the compression done faster.
The processor may be located on a multi-purpose board with extra serial
ports, or whatever (Video WaffleIron?).
Anything wrong with it?phil@adam.adelaide.edu.au (Phil Kernick) (10/16/90)
In article <291@geocub.greco-prog.fr> anthes@geocub.greco-prog.fr (Franklin Anthes) writes:
-
-I'd really like to find an amiga device (comp:?) which would automatically
-compress/decompress any files stored on it. I don't think such a device would
-be able to handle direct access ( it could probably fake it though ). But
-it still would be a really usefull tool.
Isn't this basically how an RLL hard-drive controller on an I*M works?
As I understand it, it run-length encodes the data to be put on the
hard drive before storing it, and decodes it when reading it off.
This would mean slightly slower access times, but an increase in disk
capacity of about 50%.
Phil.
--
Phil Kernick EMail: phil@adam.adelaide.edu.au
Departmental Engineer Phone: +618 228 5914
Dept. of Psychology Fax: +618 224 0464
University of Adelaide Mail: GPO Box 498 Adelaide SA 5001hamish@waikato.ac.nz (10/17/90)
In article <phil.656040612@adam.adelaide.edu.au>, phil@adam.adelaide.edu.au (Phil Kernick) writes: > In article <291@geocub.greco-prog.fr> anthes@geocub.greco-prog.fr (Franklin Anthes) writes: > - > -I'd really like to find an amiga device (comp:?) which would automatically > -compress/decompress any files stored on it. I don't think such a device would > -be able to handle direct access ( it could probably fake it though ). But > -it still would be a really usefull tool. > > Isn't this basically how an RLL hard-drive controller on an I*M works? > As I understand it, it run-length encodes the data to be put on the > hard drive before storing it, and decodes it when reading it off. > > This would mean slightly slower access times, but an increase in disk > capacity of about 50%. > Not quite. RLL and MFM are just two different ways of encoding separate bits in a stream of them. The RLL gives higher densities, simply because it has a diffent number of transitions for a given bit pattern than MFM, and so can be recorded at a higher density. MFM is also an example of RLL encodeing, however the method is slightly different, and so the number of transitions written to the substrate is different. For a complete explanation see BYTE magazine. They had a piece on encoding bits on disk substrates not too long ago, however I can't remember the issue off hand. (any body?). > Phil. > -- > Phil Kernick EMail: phil@adam.adelaide.edu.au > Departmental Engineer Phone: +618 228 5914 > Dept. of Psychology Fax: +618 224 0464 > University of Adelaide Mail: GPO Box 498 Adelaide SA 5001 -- ============================================================================== | Hamish Marson | Internet hamish@waikato.ac.nz | | Computer Support Person | Phone (071)562889 xt 8181 | | Computer Science Department | Amiga 3000 for ME! | | University of Waikato | | ============================================================================== |Disclaimer: Anything said in this message is the personal opinion of the | | finger hitting the keyboard & doesn't represent my employers | | opinion in any way. (ie we probably don't agree) | ==============================================================================
dillon@overload.Berkeley.CA.US (Matthew Dillon) (10/20/90)
In article <phil.656040612@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes: >In article <291@geocub.greco-prog.fr> anthes@geocub.greco-prog.fr (Franklin Anthes) writes: >- >-I'd really like to find an amiga device (comp:?) which would automatically >-compress/decompress any files stored on it. I don't think such a device would >-be able to handle direct access ( it could probably fake it though ). But >-it still would be a really usefull tool. > >Isn't this basically how an RLL hard-drive controller on an I*M works? >As I understand it, it run-length encodes the data to be put on the >hard drive before storing it, and decodes it when reading it off. > >This would mean slightly slower access times, but an increase in disk >capacity of about 50%. > >Phil. Uh, no. RLL is not a compression scheme. It is a GCR like encoding which takes advantage of the higher clock rate to use larger code groups without violating the media transition limits. There is no compression involved. RLL is to disk media as MODULATION is to a modem. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
LEEK@QUCDN.QueensU.CA (10/21/90)
A compression device ? That's an idea. What about a set of compression routines in a shared library ? Think of programs such as hard disk backup programs, a shell for archiving etc programs that being able to the most up to date archive algorithms by simply getting a new library... Not to mention that it is easier to write such programs. how to code that critical portion of K. C. Lee Elec. Eng. Grad. Student
joseph@valnet.UUCP (Joseph P. Hillenburg) (10/21/90)
NOTE! Nico Francois (sp?) has released, on the Fish 371-380, a shared library that uses the PowerPacker routines. Also, on the new fish were MuchMore 2.7 (dunno about changes) and MuchMorePoPa 2.7, which allows MuchMore to load in text crucnhed with PowerPacker. (Boy, did I ever hate PPMore's interface!) -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
pochron@cat37.cs.wisc.edu (David Pochron) (11/17/90)
In article <1990Oct15.120046.15007@ericsson.se> etxtomp@eos.ericsson.se writes: >In article <291@geocub.greco-prog.fr> anthes@geocub.greco-prog.fr (Franklin Anthes) writes: >- >-I'd really like to find an amiga device (comp:?) which would automatically >-compress/decompress any files stored on it. I don't think such a device would >- >-Does such a beast exist already for the Amiga? If not is this a feasible idea? >-This would have to be a Dos device, wouldn't it? >- >- Frank Anthes-Harper : Bien le bonjour de la France >- anthes@geocub.greco-prog.fr > >It seems like this would be a good thing... One could start with a software >compression scheme and incorporate it in an OS release. By adding one of > >Anything wrong with it? Why not just write a GCR-trackdisk.device that writes disks in GCR format instead of MFM format? You get twice as much disk space (880*2 = 1.66 megs I think - its been a while since I last read the disk drive section in the hardware reference manual!) and you only have to live with the fact that reads and writes will be twice as slow. Using a trackdisk.device with a compression routine would probably work much slower - especially on a 68000 machine, but would give different results from different files. I mentioned this before and am surprised it received no response. Perhaps what I am suggesting is way out in left field... :-) (MSH-authors - any comments?) -- ------------------------------------------------------------------------------- David M. Pochron | from Rescue Rangers, _A Fly in the Ointment_ pochron@garfield.cs.wisc.edu| Gadget to Dale: "Keep the hands off the body!" -------------------------------------------------------------------------------
jesup@cbmvax.commodore.com (Randell Jesup) (11/18/90)
In article <1990Nov16.215210.23026@daffy.cs.wisc.edu> pochron@cat37.cs.wisc.edu (David Pochron) writes: >Why not just write a GCR-trackdisk.device that writes disks in GCR format >instead of MFM format? Because Paula can only handle GCR at 4us/bit, not 2us/bit. GCR buys you some of that space back, but my no means all of it. Combine that with slower reads and writes, and I think you see the answer. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "If your application does not run correctly, do not blame the operating system." (From "The Zen of Programming") ;-)
rhialto@cs.kun.nl (Olaf Seibert) (11/19/90)
In article <1990Nov16.215210.23026@daffy.cs.wisc.edu> pochron@cat37.cs.wisc.edu (David Pochron) writes: >In article <1990Oct15.120046.15007@ericsson.se> etxtomp@eos.ericsson.se writes: >[about a comp: (compression device)] >Why not just write a GCR-trackdisk.device that writes disks in GCR format >instead of MFM format? You get twice as much disk space (880*2 = 1.66 megs I >think - its been a while since I last read the disk drive section in the >hardware reference manual!) and you only have to live with the fact that reads >and writes will be twice as slow. Using a trackdisk.device with a compression >routine would probably work much slower - especially on a 68000 machine, but >would give different results from different files. Your suggestion _seems_ very interesting. Unfortunately, you forget one little but important detail. While MFM indeed expands 1 data bit to 2 disk bits (or 4 bits to 8, as some people say) and GCR only expands 4 bits to 5, GCR has only half the bit rate as MFM. So actually, MFM is _more_ efficient. Now this has of course a reason. Current double density disks don't like magnetic field changes too close to each other, and since 1's are encoded as field changes, you can't have 2 1's directly next to each other. Therefore, MFM uses 'clock' bits to dilute the data such that 2 1 data bits are always separated by a 0. (On the other hand, there can't be too much 0's in a row either since the timing partly depends on the 1's for resynchronisation.) Therefore, MFM encoding is relatively simple. Since GCR puts the bits further apart, it does not have the problems with 1's. It still does have the problem with 0's though, and of course also needs some special code for SYNC to indicate the start of a data block and so. So some kind of encoding is still necessary. Since SYNC with GCR is 10 or more 1's in a row, it needs to ensure that no data that is encoded can ever look like a SYNC. And also it must limit the number of 0's in a row to at most 2. (I think). There are in fact a number of different encodings that satisty these conditions. In fact, the Apple-][ GCR encoding is different from the Commodore-2040, 3040, 4040, 2041, 1540, 1541, 8050, GCR encoding. (GCR encoding is also a lot more work than MFM encoding.) I do have a 1541 ROM disassemble somewhere, so I could look up the actual encoding. (Unfortunately I don't have a ROM disassembly for the 2040 et al. In those days I had not figured out yet how to access the address space of the other processor. Could somebody help me to get hold of one?) >I mentioned this before and am surprised it received no response. Perhaps >what I am suggesting is way out in left field... :-) Unfortunately, yes. Although I don't know the expression 'out in left field' ;-) >(MSH-authors - any comments?) You succeeded in getting a comment from the one that's on this net. >David M. Pochron | from Rescue Rangers, _A Fly in the Ointment_ -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
peterk@cbmger.UUCP (Peter Kittel GERMANY) (11/20/90)
In article <1990Nov16.215210.23026@daffy.cs.wisc.edu> pochron@cat37.cs.wisc.edu (David Pochron) writes: > >Why not just write a GCR-trackdisk.device that writes disks in GCR format >instead of MFM format? You get twice as much disk space (880*2 = 1.66 megs I >think - its been a while since I last read the disk drive section in the >hardware reference manual!) and you only have to live with the fact that reads >and writes will be twice as slow. When I remember the manual correct then it states that when using GCR you have to halve your data throughput, so your factor 2 advantage disappears. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk