dillon@CORY.BERKELEY.EDU.UUCP (02/05/87)
Unfortunetly, I'm no expert on disk media and hardware. This is my understanding: The raw bit data which goes into drive represents the existance or lack of a flux reversal on the media. 0=no flux reversal, 1=flux reversal. You need to encode the data such that: (A) You don't go too long without a flux reversal or the phased locked loop will loose it's lock. This means no more than 3 '0' bits in a row. (B) You can't have the peaks too close to each other or you get intersymbol interference due to data shifting. Thus: bit 0101011000110 flux _--__-____-__ This seems to indicate that you cannot have more than 2 '1' bits in a row, but I'm not sure. Does one also have to enforce a 'No more than N peaks in T time' rule also?? MFM encoding works as follows. Each bit is encoded like this: databit bits-to-disk 0 -> *0 (where * is the complement of the previous bit in the stream) 1 -> 01 MFM thus guarentees no more than 3 zero's in a row, and no more than one one in a row. It takes exactly two clocked bits to disk for every bit in the data. 1 0 1 01 00 01 My question is, is it allowed to have two one's in a row, and does one also have to take into account a 'N peaks over T time' limit? Because if two one's in a row IS allowed, you can use the following method to encode the data: 8 data bits -> 11 'disk' bits. the encoding ensures no more than 3 0's in a row, and no more than 2 1's in a row. If you *can* do this, then you have just given yourself about a 30% increase in storage. Current MFM: 11 sectors * (512+32 bytes/sector) = 5984 bytes/track. New method which may or may not work: 16 sectors * (512+32 bytes/sector) = 8704 bytes/track. Making for a 1.25Meg floppy. So is it possible? If so, I'll write a trackdisk driver for the baby. ------------------------ Note on RLL: Can't be done on the Amiga.. it requires you to boost the bit clock for the drive. -Matt
grr@cbmvax.UUCP (02/05/87)
In article <8702050359.AA01021@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Unfortunetly, I'm no expert on disk media and hardware. This is my >understanding: Suggest you do a little more research on MFM, GCR and RLL implementation. The Amiga floppy controller function lets you spit out whatever flux transitions you want at a fixed clock rate. There is also provision for write-precompensation (bit shifting) for either MFM or GCR standards. The Amiga at one point was to have GCR formatted floppies, but somewhere along the line it was decided to switch back MFM. Feel free to experiment. Note that GCR and RLL codes may require different time-domain filter parameters in the analog drive electronics. Typically, wider bandwidth is needed to prevent droop on missing transitions... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
charles@hpcvcd.UUCP (02/09/87)
It has been several years since I worked with floppys, but I'll give this a try. My experience is with 8 inch drives. >The raw bit data which goes into drive represents the existance or lack of >a flux reversal on the media. 0=no flux reversal, 1=flux reversal. Yes. > (B) You can't have the peaks too close to each other or you get > intersymbol interference due to data shifting. Thus: Bit shifting is a significant problem. But consider that the head is this mechanical thing. It has a physical size that is significant in relation the the track and bit cell size. I don't know how close floppys run to this limit, but there certainly is a limit to how small a flux region can be made. > This seems to indicate that you cannot have more than 2 '1' bits in > a row, but I'm not sure. That is one way to look at it. I usually think of it in terms of time. On an 8 inch floppy, the encoded bits can be 2us, 3us, or 4us apart. With FM and single density, the timing was 2us or 4us. Thus in the shift from single to double density, the minimum and maximum bit timing to the drive did not change. All that changed was the resolution required of the system. Notice that this implys the early single density drives could run double density if they were adjusted well and if you used floppys that didn't shift the bits much. > Does one also have to enforce a 'No more > than N peaks in T time' rule also?? Never heard of such a thing. > 8 data bits -> 11 'disk' bits. the encoding ensures no more than > 3 0's in a row, and no more than 2 1's in a row. Won't work. With MFM on 8 inch floppys a continuous stream of data ones produces encoded bits with ones 2us apart. That is the closest together you can put the flux reversals. It turns out a continuous stream of zeros also produces encoded bits with ones 2us apart. The only way to tell the difference is to remember from the start of the data which encoded ones represent data ones and which represent zeros. Altho I explained this in terms of 8 inch floppys, I am pretty sure the only thing different with smaller floppys is the actual timing. I understand GCR is more dense than MFM. Personally, I would rather give up a couple hundred KB to have a commonly readable disk format. While reading the Hardware Reference Manual, I got the impression that the decoding of the floppy bits to real bits is done in software. I hope that is not true. Perhaps that is part of the explanation for why the A1000 is so infernally slow. With several floppy controller chips on the market, this seems counterproductive. Charles Brown hplabs!hp-pcd!charles
claudio@ethz.UUCP (02/10/87)
In article <8702050359.AA01021@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU.UUCP writes: > > Unfortunetly, I'm no expert on disk media and hardware. This is my >understanding: > > [ some discussion about MFM encoding ] > > Current MFM: > 11 sectors * (512+32 bytes/sector) = 5984 bytes/track. > > New method which may or may not work: > 16 sectors * (512+32 bytes/sector) = 8704 bytes/track. > > Making for a 1.25Meg floppy. > >So is it possible? If so, I'll write a trackdisk driver for the baby. > >------------------------ >Note on RLL: Can't be done on the Amiga.. it requires you to boost the >bit clock for the drive. > > -Matt Sorry Matt, but that is not possible. Although I don't know very much about MFM and other disk encodings, I can tell you for sure that you will not be able to put 8704 bytes/track on the disk. The floppy controller writes to the disk with a speed of 250000 bits/sec and the disk turns at 300 rpm which means that a track is 0.2 sec long thus (0.2*250000)=50000 bits/track and no more. So the maximum you can expect to put on a flopy is 6250 bytes/track if you use no encoding but simply put every bit as it is on the disk (which, as you explained, is impossible). 6250 bytes/sec vs. 5984 bytes/sec that's only 4.5% more, so it's probably not worth the work. -- claudio (* --------------------------------------------------------------------- Disclaimer: I'm not working for ETH-Zurich! I'm just a CS student. E-Mail: UUCP: claudio@ethz.uucp BITNET: K538912@CZHRZU1A Mail: Claudio Nieder, Kanalweg 1, CH-8610 Uster, Switzerland. --------------------------------------------------------------------- *)
daveh@cbmvax.UUCP (02/10/87)
> >>So is it possible? If so, I'll write a trackdisk driver for the baby. >> >>------------------------ >>Note on RLL: Can't be done on the Amiga.. it requires you to boost the >>bit clock for the drive. >> >> -Matt > > Sorry Matt, but that is not possible. Although I don't know very much > about MFM and other disk encodings, I can tell you for sure that you > will not be able to put 8704 bytes/track on the disk. > > The floppy controller writes to the disk with a speed of 250000 bits/sec > and the disk turns at 300 rpm which means that a track is 0.2 sec long > thus (0.2*250000)=50000 bits/track and no more. So the maximum you can > expect to put on a flopy is 6250 bytes/track if you use no encoding but > simply put every bit as it is on the disk (which, as you explained, is > impossible). > > 6250 bytes/sec vs. 5984 bytes/sec that's only 4.5% more, so it's > probably not worth the work. > claudio There's apparently a bug somewhere in the above calculation. If you just look at some simple mathematics. First of all, because of the MFM encoding, we're storing 2 bits for every important data bit; that's to prevent the problems associated with improper flux changes (since each bit stored is stored as a flux change or no change). So for a full track of 11 sectors of 512 bytes each (5632 bytes total), you have to store in the MFM format twice that, or 11264 byte of data per track. This particular method of MFM storage was designed since the blitter can very easily decode it; it takes 3 blitter passes to encode, 1 to decode as I recall (the decoding's easy; every other bit is significant). What you may be loosing on, which I think is Matt's point up above, is that you're not getting every significant bit combination out of this formula. I'm encoding 8 bits into 16 bits via this MFM scheme. But, possibly, a more intelligent scheme could encode 9 or 10 bits into those same 16 bits. That's basically what all the old Commodore GCR drives do. The MFM scheme requires that 256 out of the possible 65536 values cause no flux change problems. If I can find 512 out of this same 65536 possible values that cause no flux change problems, I've just upped my capacity, at the expense of probably having to decode by processor via a lookup table, instead of zapping it with the blitter. If I can find 1024 values, I'm even better off, storage wise. I'm not sure how well this can be done on the Amiga, but it certainly sounds worth investigation. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "You can keep my things, they've come to take me home" -Peter Gabriel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
grr@cbmvax.UUCP (02/10/87)
In article <4410003@hpcvcd.HP> charles@hpcvcd.HP (Charles Brown) writes: >While reading the Hardware Reference Manual, I got the impression >that the decoding of the floppy bits to real bits is done in >software. I hope that is not true. Perhaps that is part of the >explanation for why the A1000 is so infernally slow. With several >floppy controller chips on the market, this seems counterproductive. > > Charles Brown hplabs!hp-pcd!charles The MFM encoding/decoding is not done by the floppy controller function of Paula, however it is done using the Blitter hardware, rather than software "bit-bashing". While this has to be slower, in an absolute sense, than using a standard controller chip, it does not neccessarily follow that this is a limiting factor on system performance... The advantage (if any) of this scheme is that you can read (or write) any floppy format using standard constant bit cell timing. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
daveh@cbmvax.UUCP (02/11/87)
> While reading the Hardware Reference Manual, I got the impression > that the decoding of the floppy bits to real bits is done in > software. I hope that is not true. Perhaps that is part of the > explanation for why the A1000 is so infernally slow. With several > floppy controller chips on the market, this seems counterproductive. > Charles Brown (A) That is quasi-true. The decoding is done by one pass of the blitter, the encoding done by 3 passes. All set up by software. (B) This has nothing to do with any precieved floppy slowness. If by slowness, you mean that directories take a long time to list out, that's based on the DOS file structure (a few levels of software above what we're talking about here) and probably the fact that you use the DIR command, which holds and sorts all the files it finds. If you're referring to the 256K of Kickstart code that the machine loads in less than 30 seconds (a decent test of raw floppy speed), I'm not sure what you're driving at. No commercial floppy chip would be as flexiable as the currently implemented system. First of all, the raw data is read from the floppy via an interleaved DMA a track at a time. So once a read/write request is set up, the data gets transferred to memory directly, as fast as it can come from the floppy, without any processor intervention and without slowing the processor down at all. Once the raw data is in, the conversion is done by the blitter. This is a tremendously powerful mechanism, and the basis for most of the discussion that's going on around here. We are talking about the possiblity of a simple software change that would allow 12 or 13 logical sectors per track, instead of 11. You also probably know that the Amiga can easily read IBM or Atari ST formatted disks; just try to go the other way (hint: The Amiga disk format doesn't really use sectors, only tracks). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "You can keep my things, they've come to take me home" -Peter Gabriel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
claudio@ethz.UUCP (02/17/87)
In article <445@ethz.UUCP> claudio@ethz.UUCP (Claudio Nieder) writes: > ... Although I don't know very much about MFM ... I spent this weekend learning more about MFM encoding. >The floppy controller writes to the disk with a speed of 250000 bits/sec >and the disk turns at 300 rpm which means that a track is 0.2 sec long >thus (0.2*250000)=50000 bits/track and no more. So the maximum you can >expect to put on a flopy is 6250 bytes/track if you use no encoding but >simply put every bit as it is on the disk (which, as you explained, is >impossible). Argh, I was wrong. I was so used to the Apple ][ method of encoding, where the time between two flux transitions is a multiple of the minimum time required between two flux transitions (4, 8, 12 us), that I didn't consider other possibilities. In MFM the time between two flux transitions is 4, 6 or 8 us, so while the minimum time is 4 us, the time between two flux transitions may be a multiple of 2 us. Therefor the Amiga floppy controller must be able to write out the data at 500 kbit/s and not only at 250 kbit/s as I assumed in my first posting. I apologize for my misinformation. -- claudio (* --------------------------------------------------------------------- ==========> ANYTHING IN THIS POSTING MAY BE WRONG. <================== Disclaimer: I'm not working for ETH-Zurich! I'm just a CS student. E-Mail: UUCP: claudio@ethz.uucp BITNET: K538912@CZHRZU1A Mail: Claudio Nieder, Kanalweg 1, CH-8610 Uster, Switzerland. --------------------------------------------------------------------- *)