gab@notecnirp.Princeton.EDU (Gavin Bell) (05/08/87)
I've read several people who stated that, since the Mac drives spin at variable rates and the Amiga drives at fixed rates, that it was not possible to read Mac Disks with the Amiga drive. Well... one way to get around this is to read in data faster or slower, depending on what track you are on. This is how the Commodore 1541 drives manage to squeeze 170k on a single density 5 1/4" disk, putting more sectors on the outer tracks of a disk and reading the bits at a faster rate (the drive spins at a constant 300 rpm). So, a program to read Mac disks on an Amiga seems not-impossible-- I would try to write such a beast, but don't yet even have a C-compiler for my 'miga. Am I missing something?
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/08/87)
<I've read several people who stated that, since the Mac drives spin <at variable rates and the Amiga drives at fixed rates, that it was not <possible to read Mac Disks with the Amiga drive. < Well... one way to get around this is to read in data faster or <slower, depending on what track you are on. This is how the Commodore <1541 drives manage to squeeze 170k on a single density 5 1/4" disk, putting <more sectors on the outer tracks of a disk and reading the bits at a faster <rate (the drive spins at a constant 300 rpm). < So, a program to read Mac disks on an Amiga seems not-impossible-- I <would try to write such a beast, but don't yet even have a C-compiler <for my 'miga. < Am I missing something? Yes. The 1541's firmware has access to a hardware IO register which allows it to select the speed. No such register exists on the Amiga. Still... has anyone *tried* raw-reading mac disks??? I assume the Mac drive doesn't spin any faster than then 300rpm, which means you *might* be able to decipher the data the Amiga would spew at you. -Matt
barry@borealis.UUCP (Kenn Barry) (05/08/87)
<I've read several people who stated that, since the Mac drives spin
<at variable rates and the Amiga drives at fixed rates, that it was not
<possible to read Mac Disks with the Amiga drive.
Usual disclaimer ("I could be wrong"), but didn't Macs switch
from variable speed to constant speed with the Mac+? I remember the
funny "singing" noises the old Mac drives made, but not the new ones.
Kayembeebryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (05/09/87)
In article <2176@borealis.UUCP> barry@borealis.UUCP (Kenn Barry) writes: ><I've read several people who stated that, since the Mac drives spin ><at variable rates and the Amiga drives at fixed rates, that it was not ><possible to read Mac Disks with the Amiga drive. > > Usual disclaimer ("I could be wrong"), but didn't Macs switch >from variable speed to constant speed with the Mac+? I remember the >funny "singing" noises the old Mac drives made, but not the new ones. > Old mac drives are multi-speed devices. This allows more bits to be packed on the outer tracks, since there is more physical space. In the outer zones old mac drives spin SLOWER, thus writing more information per degree of arc. [Editorial: despite this 'innovation' mac drives store pathetically little information (400k). Far too little considering the needs of the machine] Mac+ drives run at a constant speed but the ELECTRONICS compensates and read/writes data at a variable bit rate. This is the same way that the Commodore 2040/4040/8050/8250/1541/1571 drives work. For the Amiga to *WRITE* mac disks if would need to have a set of bits in paula to select bit rates to match those of the mac drives. The Amiga may be flexible enough as is to *READ* mac disks with some fancy software that can compensate; interpolate and retry to extract good data from a incompatible rate bit stream. / ==== === == == // /--|--\ ** ||| == =__= = = = = // | ( | == ||| == = = = = = \\// \_____/ ** / | \ ==== === = = = Me? I like the // \\// but the MAC II also has a lot going for it.
scotty@l5comp.UUCP (Scott Turner) (05/10/87)
In article <8705080543.AA18112@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: ><I've read several people who stated that, since the Mac drives spin ><at variable rates and the Amiga drives at fixed rates, that it was not ><possible to read Mac Disks with the Amiga drive. >< Well... one way to get around this is to read in data faster or ><slower, depending on what track you are on. This is how the Commodore ><1541 drives manage to squeeze 170k on a single density 5 1/4" disk, putting ><more sectors on the outer tracks of a disk and reading the bits at a faster ><rate (the drive spins at a constant 300 rpm). >< So, a program to read Mac disks on an Amiga seems not-impossible-- I ><would try to write such a beast, but don't yet even have a C-compiler ><for my 'miga. > >< Am I missing something? > > Yes. The 1541's firmware has access to a hardware IO register which >allows it to select the speed. No such register exists on the Amiga. >Still... has anyone *tried* raw-reading mac disks??? I assume the Mac drive >doesn't spin any faster than then 300rpm, which means you *might* be able >to decipher the data the Amiga would spew at you. > -Matt I apologize for including the whole thing again folks but I'll be addressing most all the points above so I wanted yall to have 'em in front of ya. First lets correct that statement about selecting speed, the Amiga DOES have such a register! Go read yer hardware manual again Matt. Yes, the Mac has variable speed drives. But that doesn't imply they vary based on 300 rpm! We aren't the center of the universe folks! :-) Back when the 3.5" drive was first floated by Sony they wanted it to rip around at 600 rpm. The industry though decided that being able to plug them into existing systems meant they had to rotate at 300 rpm. So Sony lost, almost. The Mac people didn't give a rats behind about the rest of the industry, after all their disk format was already incompatible. Apple had just come off the embarrasment of the Twiggy drive. Analysis showed that the variable speed concept was fine, it was the drive and media that nailed them. So they kept the variable speed part and switched to "stock" drives and media. As a result Mac disks vary their speed from 400 to 600 rpm. Alot of people have stated that the Mac system is "brain damaged" because of it's use of variable speed and software decoded GCR. Well that extra rpm cancels out quite a bit. I have read the slowest moving pieces of Mac disks, back in Nov 1985. The Amiga can decode Apple's GCR. I would have pursued this to the end but the trackdisk. device and floppy treatment in general was rather err brain damaged back then. It still hasn't gotten much better... :-( Anyway, is there hope? YES! Now that all the facts are out I'm sure a few of you will get right to work, :-). Note, a C Compiler IS NOT REQUIRED to work on the Amiga. I've NEVER used any of the C "compilers" sent to me by C-A. When working on ground that no one else has trompled it helps to know EXACTLY what is going on. With a C compiler in between you and the hardware that gets tricky at best. After all, if something goes bump you don't know if it was Manx tripping or you. And all to often it seems people find it was Manx and not themselves. PD assemblers are available that will let you get right to work for the cost of a download. Are you missing anything? YES! The Amiga 3.5" disk drive spins from 0 to 300+ rpm... Scott Turner L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
farren@hoptoad.uucp (Mike Farren) (05/11/87)
In article <112@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > >First lets correct that statement about selecting speed, the Amiga DOES have >such a register! Go read yer hardware manual again Matt. > News to me - could you please specify what you're talking about? I just put down the Hardware Ref. Manual and couldn't find such a beast. There IS a bit for selecting 2 or 4 microseconds/bit cell, but that isn't going to buy you a lot of flexibility. >So [Apple] kept the variable speed part and switched to "stock" >drives and media. As a result Mac disks vary their speed from 400 to >600 rpm. Alot of people have stated that the Mac system is "brain >damaged" because of it's use of variable speed and software decoded >GCR. Well that extra rpm cancels out quite a bit. No, it just makes it more brain damaged. If the extra speed thing is true, then they should have been able to get a LOT more data onto the disk than the 400/800K that they did. Twice the rotation speed == twice the data rate, after all. (Is this how IBM is getting 1.4M 3-1/2" drives, by the way?) -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
tim@amdcad.AMD.COM (Tim Olson) (05/11/87)
In article <2112@hoptoad.uucp| farren@hoptoad.UUCP (Mike Farren) writes: +----- | No, it just makes it more brain damaged. If the extra speed thing is | true, then they should have been able to get a LOT more data onto the | disk than the 400/800K that they did. Twice the rotation speed == | twice the data rate, after all. (Is this how IBM is getting 1.4M | 3-1/2" drives, by the way?) +----- If you doubled rotation speed and kept the data transfer rate constant, you would get *half* the data storage capacity. Doubling the rotation rate allows you to double the data transfer rate for the same amount of storage. -- Tim Olson Advanced Micro Devices
cjp@vax135.UUCP (05/12/87)
In article <16641@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: >In article <2112@hoptoad.uucp| farren@hoptoad.UUCP (Mike Farren) writes: >| disk than the 400/800K that they did. Twice the rotation speed == >| twice the data rate, after all. (Is this how IBM is getting 1.4M >If you doubled rotation speed and kept the data transfer rate constant, >you would get *half* the data storage capacity. Doubling the rotation Depends on your point of view (reading an existing disk twice as fast, or writing half as much to a disk); but this misses the point. I believe the bottleneck is not so much data rate or rotation speed, as it is the magnetic behavior of the media and read/write head. Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "The road to Hell is paved with good opinions."
ewhac@well.UUCP (05/12/87)
In article <112@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > >First lets correct that statement about selecting speed, the Amiga DOES have >such a register! Go read yer hardware manual again Matt. > Without getting coarse, Scott, I (and many others) would greatly appreciate it if you would explicitly quote the manual and not simply ask us to take your word for it. I have inspected my hardware manual, and the only thing I can find that might possibly be related to varying bit densities on the disk is the ADKCON register, bit 8 (FAST). This bit switches from 2 to 4 microseconds per bit cell. Was this what you were talking about? >Are you missing anything? YES! The Amiga 3.5" disk drive spins from 0 to 300+ >rpm... > I presume you mean it turns on (300 rpm) and off (0 rpm). I see no other software controls to vary speed in the manual. Am I blind (I personally don't think so)? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
scotty@l5comp.UUCP (Scott Turner) (05/12/87)
In article <2112@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >News to me - could you please specify what you're talking about? I >just put down the Hardware Ref. Manual and couldn't find such a beast. >There IS a bit for selecting 2 or 4 microseconds/bit cell, but that >isn't going to buy you a lot of flexibility. Yeah but it DOES change the clock rate! Which is what we were talking about. >No, it just makes it more brain damaged. If the extra speed thing is >true, then they should have been able to get a LOT more data onto the >disk than the 400/800K that they did. Twice the rotation speed == >twice the data rate, after all. (Is this how IBM is getting 1.4M >3-1/2" drives, by the way?) Uh, twice the rotational speed at the same data rate := half the data at a 1X rotational rate. The laws of nature win out, grin. Take for example a phonograph record. Which record stores the most music: 33 1/3, 45, or 78 RPM? The faster rotational speed does one thing, decreases rotational latency. And actually considering that Apple is using SINGLE DENSITY data rates I think they do a rather nice job of packing the data on the disk. Data density is a function of three things: Media's ability to record X number of flux changes per inch. Drivehead's ability to produce X number of flux changes per inch. And the drives ability to position the head in tracks per inch. Rotational speed has very little to do with anything except rotational latency and the EFFECTIVE fci (FluxChangeInch) being laid down. If a constant speed is used for rotation and fci being sent to the drive, the actual fci will vary from the inner most track to the outer most track. This is because no matter which track you are you always go round in the same amount of time, but the length of track that goes round varies from the inside to the outside. Thus on the outer tracks the bits are "fatter" because more track goes under the head during a fluxchange in the head. So what Apple did was have the drive change speed so that the effective fci laid down is pretty much the same from the inside track to the outside track. The trouble with Apple is that they've never gone double density :-). Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /devA SOe >
wtm@neoucom.UUCP (05/13/87)
I don't know about the Panasonic drives, but the NEC drives definitely DO NOT have any means for having the processor alter the rotational speed. The NEC drives have a small, in fact *very* small pot on the bottom circuit board in front next to the flywheel that can be used to tweak the speed. Note that the pot is normally of no benefit to the end user. I've heard that the rpm of the Panasonic drives is crystal controlled, and thus not adjustable at all. Perhaps, an industrious programmer could rapidly select and de-select the drive motor to implement virtual speed control via pulse width modulation. The speed would vary depending on the floppy, however. I guess you'd have to stay awary from those sticky made in USA black disks (grin). --Bill (wtm@neoucom.UUCP)
cmcmanis@sun.uucp (Chuck McManis) (05/13/87)
Here are some comments to the ongoing Mac disk debate which has probably raged on far to long for the wrong reasons. But not being one who likes to leave a discussion in a muddy state ... :-) The Players ... '>>' Mike Farren '>' Scott Turner ' ' Moi >>News to me - could you please specify what you're talking about? I >>just put down the Hardware Ref. Manual and couldn't find such a beast. >>There IS a bit for selecting 2 or 4 microseconds/bit cell, but that >>isn't going to buy you a lot of flexibility. >Yeah but it DOES change the clock rate! Which is what we were talking about. No it wasn't what we were talking about. We were talking about changing the *motor* speed of a disk drive which is *not* possible on the Amiga. (If you try to pulse width modulate the MotorOn line it doesn't help because the drive isn't 'ready' until is comes up to speed) May grr correct me if I am wrong, but I don't think the 2/4 bit changes the clock rate at all, it changes how the bits are viewed so that you can decode FM formatted disks. >>No, it just makes it more brain damaged. If the extra speed thing is >>true, then they should have been able to get a LOT more data onto the >>disk than the 400/800K that they did. Twice the rotation speed == >>twice the data rate, after all. (Is this how IBM is getting 1.4M >>3-1/2" drives, by the way?) > Uh, twice the rotational speed at the same data rate := half the data at a > 1X rotational rate. The laws of nature win out, grin. Take for example a > phonograph record. Which record stores the most music: 33 1/3, 45, or 78 RPM? > The faster rotational speed does one thing, decreases rotational latency. First the change in disk speed is marginal and second they slow it down rather than speed it up. I'll get into that in a moment but first ... Actually a faster speed can increase your effective bandwidth because for a given signal you have more media to put it on, the quantity of signal that is present goes down. Scott failed to mention that on disks (unlike records) you can move the 'grooves' closer together which complicates the issue. As for the IBM disks, they got 1.4 Meg the exact same way they got 1.2 Meg on a 5-1/4" disk they went with a 500Khz clock rate rather than the 250Khz rate which is standard on other 5.25" interfaces (and 3.5" interfaces) Both Sony and 3M sell '2M' 3.5" diskettes that can be used by the IBM drive. > And actually considering that Apple is using SINGLE DENSITY data rates I think > they do a rather nice job of packing the data on the disk. Yup, but they are using Group Coded Recording which cannot extract the data clock the way Modified FM can so they are 'stuck' at single density. As it turns out the data density of GCR is fairly close to that of MFM so it isn't a loss on their part, the big win is that the Integrated Woz Machine can easily decode GCR data and it is inexpensive to build. > Data density is a function of three things: Media's ability to record X number > of flux changes per inch. Drivehead's ability to produce X number of flux > changes per inch. And the drives ability to position the head in tracks > per inch. This is in essence true, I would phrase it a bit differently. Given a drive whose head can resolve 'n' tracks on the disk and a data clock rate of 'c' clocks/second and whose speed of revolution is 'r' revolutions/second. Raw data capacity can be calculated with : [(clks/sec * bit/clk)/(revolutions/sec * bits/byte)] * tracks * heads Which for a 3.5" drive at a constant 300 RPM (5 rps) is [(250000 * 1) / (5 * 8) ] * 80 * 2 = 1000000 bytes. Note that MFM encodes 1 bit/clock, and FM encodes .5 bits/clk. This is the difference between single and double density on most drives. Now you lose some of those bytes to formatting information like sector headers, intersector gaps, and end of track gaps (to account for variations in disk speed) Another note : Most computers like the Atari and IBM use dedicated floppy disk controllers that work on a sector by sector basis. These computers leave gaps between the sectors to allow for variations in disk speed, and before the sector, usually write a 'sync' pattern that locks the controllers phase locked loop onto the data stream. Since the Amiga writes entire tracks it can eliminate those gaps and use the recoverd space for data. That results in the 'extra' 80K of space/disk or one 512 byte sector/track. Now back to our story ... > Rotational speed has very little to do with anything except rotational latency > and the EFFECTIVE fci (FluxChangeInch) being laid down. If a constant speed > is used for rotation and fci being sent to the drive, the actual fci will vary > from the inner most track to the outer most track. This is because no matter > which track you are you always go round in the same amount of time, but the > length of track that goes round varies from the inside to the outside. Thus > on the outer tracks the bits are "fatter" because more track goes under the > head during a fluxchange in the head. So what Apple did was have the drive > change speed so that the effective fci laid down is pretty much the same from > the inside track to the outside track. What Scott fails to do here is relate this to the real world. Real disks are rated at a given fci. And like he says flux changes becomes bits as the head goes over them. Since most disk drives are constant speed the worse case condition occurs on the inner track with whose circumference is the smallest, and consequently has the bits packed as closely as possible. Apple was and is constrained by a constant speed clock to their phase locked loop but they realized that the disks were underutilized on the outer tracks so they came up with the rather clever scheme of slowing down the drive as the heads stepped further out. In our capacity formula above, this means that the (revolutions/sec * bits/byte) term will vary according to the track number. Thus, assuming there is a function for rotational speed given the track number the formula for capacity becomes the following integral instead : _ tracks / heads * / [(clks/sec * bit/clk)/(revolutions/sec(tracks) * bits/byte)] dtracks 0 _/ What this also points out is that the exact same effect could be achieved if you vary the clks/sec as a function of the track as opposed to the speed of the drive. Electronically this is a bit more difficult but certainly possible. However since the Amiga is constrained by *both* clock speed and drive speed you cannot change it to read Mac disks. The infamous 2 msec/ 4 msec bit is there to 'switch' between MFM decoding and FM decoding as these are the respective bit-times for these recording methods. > The trouble with Apple is that they've never gone double density :-). Well it is impossible to represent some GCR codes in an MFM bit stream however as I said earlier GCR does yield about the same *data* density as the 'double density' MFM technique so the conversion would not achieve the desired effect of doubling the data capacity :-) -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.
scotty@l5comp.UUCP (05/14/87)
In article <3038@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > Without getting coarse, Scott, I (and many others) would greatly >appreciate it if you would explicitly quote the manual and not simply ask us >to take your word for it. While I have you on the horn here Leo, I (and many others) would greatly appreciate it if you would take that bike and smash it down a bit and not force everyone to pay $$$ for useless data. As for manual quotes I'll keep that in mind the next time I offer help. I don't imagine everyone here has the luxury of their own set of manuals. [one public tit for your public tat, 'nuff said?] > I have inspected my hardware manual, and the only thing I can find >that might possibly be related to varying bit densities on the disk is the >ADKCON register, bit 8 (FAST). This bit switches from 2 to 4 microseconds >per bit cell. Was this what you were talking about? If it quacks like a duck... Yes Leo, although I think a term stronger than 'possibly' could be used for something that SAYS it changes the bit timing. > I presume you mean it turns on (300 rpm) and off (0 rpm). I see no >other software controls to vary speed in the manual. Am I blind (I >personally don't think so)? What I meant is that the drive in the Amiga does not turn on or off in 0us. By applying a properly timed sequence of motor on/off commands to the drive we can control it's speed to a degree. I have no data on what kind of range can be achieved with the Amiga's 3.5" drive but this idea has been used on the PC to change the drive speed for less useful things like copy protection. To head off any more semi-hostile responses, I'm attempting to do more with my messages than just state facts, that most of us already have, over again. I'm attempting to elicit discussion by provoking thought and response. Sometimes things go in directions other than expected, like Leo's statement about manual quotes, but that's the whole point. Discussions more often than not lead to everyone learning something. Of course everyone is free to emasculate me for attempting this, or we can discuss it. But this form of dealing with questions has worked well on other forums (like GEnie). Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (05/14/87)
Recently, there have been a number of articles about this subject (see
the "References" line), but some information has been missing. Given
that the Mac disks rotate at 400-600 rpm (?) and are recorded at single-
density rates, how fast would the bits come by on an Amiga? How fast
would they come by on the innermost track? How fast would they come
by on the outermost track?
The reason for the question is that if the bits are recorded in a fashion
that would cause them to come by about 4 usec apart at 300 rpm, it might
be possible to read them as if they were 2 usec apart and then compensate
in software for the drift that would occur as they were read either faster
or slower than 4 usec.
Another consideration is the response of the phase-locked loop (PLL) in
the Amiga drive to off-speed bits. Can data be recovered (at least to
the nearest 2 usec) even when the PLL is not locked?
If it is possible to read the disk and get the raw bits to the nearest
2 usec (out of approximately 4 usec) then it should be possible to decode
the data in software, compensating for the timing uncertainties. It
might not be possible to write a disk for a Mac, but perhaps it would be
possible to read the entire disk.
Steve Rice
-----------------------------------------------------------------------------
Copyright 1987 by Steven E. Rice, P.E. All Rights Reserved. This material
may be redistributed only where such redistribution is without charge and
without restrictions on further redistribution. Incorporation of this
material in a compilation or other collective work constitutes permission
from the intermediary to all recipients to freely redistribute the entire
collection. All other uses are prohibited.
-----------------------------------------------------------------------------
new: stever@videovax.tv.Tek.com
old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!steverkeithd@cadovax.UUCP (05/16/87)
In article <18746@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >Another note : Most computers like the Atari and IBM use dedicated floppy >disk controllers that work on a sector by sector basis. These computers >leave gaps between the sectors to allow for variations in disk speed, and >before the sector, usually write a 'sync' pattern that locks the controllers >phase locked loop onto the data stream. Since the Amiga writes entire tracks >it can eliminate those gaps and use the recoverd space for data. That >results in the 'extra' 80K of space/disk or one 512 byte sector/track. Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch floppy? sounds like 720k a side. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa Contel Business Systems 213-323-8170
farren@hoptoad.UUCP (05/16/87)
In article <124@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >What I meant is that the drive in the Amiga does not turn on or off in 0us. >By applying a properly timed sequence of motor on/off commands to the drive we >can control it's speed to a degree. I have no data on what kind of range can be >achieved with the Amiga's 3.5" drive but this idea has been used on the PC to >change the drive speed for less useful things like copy protection. > Won't work on the Amiga without disabling the multi-tasking. To do this kind of control requires taking over the machine so you can always toggle the signal at the right time, something which the multi-tasker pretty much guarantees won't happen while it's running. A dumb idea anyhow, as the timing is extremely device specific - the timing that will work on an NEC drive probably won't on a Fujitsu, and vice versa. >To head off any more semi-hostile responses, I'm attempting to do more with my >messages than just state facts, that most of us already have, over again. I'm >attempting to elicit discussion by provoking thought and response. While I agree with the philosophy of "attempting to elicit discussion by provoking thought and response", I have to draw the line when the topics being discussed are, basically, a waste of time. It has long since been determined that the Amiga drives cannot read Mac disks. Period. Further discussion is less than useless, and will, in fact, just confuse those who aren't as familiar with the Amiga capabilities as some of us are. It is important to keep in mind that the purpose of this forum is to provide useful information and intelligent commentary on the Amiga, its capabilities and its possibilities. By engaging in "discussion" which is misleading or downright wrong, you are filling the bandwidth with fog. I, for one, don't appreciate it. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
dillon@CORY.BERKELEY.EDU.UUCP (05/16/87)
:by provoking thought and response", I have to draw the line when the
:topics being discussed are, basically, a waste of time. It has long
:since been determined that the Amiga drives cannot read Mac disks.
:Period. Further discussion is less than useless, and will, in fact,
Ha. That attitude is a fast way to get left behind the times! In
this business, *nothing* is impossible. Even if one were to accept that
fact, the discussion was still not a 'waste of time'. I for one gleemed a lot
of useful information about Apple's disk driver and format (although GCR is
old news to people like Bryce and I, who have picked through Commodore's 2030/
1541 series floppy drive roms with a fine toothed comb).
P.S. The Mac+ disk IO r/w times in BYTE are a crock.... I ran the tests myself
and came up with about the same throughput as an Amiga... less even!
-Matt
':' is a Pnews defeater.yuan@uhccux.UUCP (Yuan Chang) (05/17/87)
In article <1542@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch >floppy? sounds like 720k a side. It simply uses more tracks per side (160 tracks, versus 80 track/surface on the Amiga). Yes, it is 720K/side. -- UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!yuan ARPA: uhccux!yuan@nosc.MIL INTERNET: yuan@UHCC.HAWAII.EDU AT&T: (808) 395-1732 "I'm an Amigoid, she's an Amigoid, they're Amigoids, - Yuan Chang - Wouldn't _y_o_u like to be an Amigoid too?"
cmcmanis@sun.uucp (Chuck McManis) (05/18/87)
In article <494@uhccux.UUCP>, yuan@uhccux.UUCP (Yuan Chang) writes: $ In article <1542@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: $ >Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch $ >floppy? sounds like 720k a side. $ $ It simply uses more tracks per side (160 tracks, versus 80 track/surface $ on the Amiga). Yes, it is 720K/side. $ - Yuan Chang - Not likely, I bet they did it the exact same way they got 1.2Meg on an AT floppy which is to say a 500Khz data clock. That lets 'em cram 9 1K sectors per track and with 80 tracks/side they get 1440 K of storage. The Amiga stores 11 512 byte sectors per track and use 160 tracks and gets 880 K. The difference is in the data clock rate. The Amiga uses a 5.25" disk compatible 250Khz data clock. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.
scotty@l5comp.UUCP (05/19/87)
In article <2140@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >Won't work on the Amiga without disabling the multi-tasking. To do >this kind of control requires taking over the machine so you can >always toggle the signal at the right time, something which the >multi-tasker pretty much guarantees won't happen while it's running. >A dumb idea anyhow, as the timing is extremely device specific - the >timing that will work on an NEC drive probably won't on a Fujitsu, and >vice versa. I point you to Disk-2-Disk from Central Coast Software. They seem to have done the impossible feat you describe. They had to deal with multi-tasking, different drives, AND different media. >topics being discussed are, basically, a waste of time. It has long >since been determined that the Amiga drives cannot read Mac disks. Really? Well maybe YOU have given up but others are actively working on this subject at both the commercial and non-commercial level. And as Leo says, how about some references so we don't have to take yer word for it? If it's been proven WHO proved it, WHEN did they prove it, and HOW did they prove it? >Period. Further discussion is less than useless, and will, in fact, >just confuse those who aren't as familiar with the Amiga capabilities >as some of us are. It is important to keep in mind that the purpose >of this forum is to provide useful information and intelligent >commentary on the Amiga, its capabilities and its possibilities. By >engaging in "discussion" which is misleading or downright wrong, you >are filling the bandwidth with fog. I, for one, don't appreciate it. Again, I've yet to see anything from YOU (or yer others in that 'us') that proves that the Amiga can't cut it. The Amiga is a VERY flexible machine, I think it still has a few tricks left. As for filling the bandwidth with 'fog', I think "you can't do that because XXX so drop it" is VERY bad stuff. This is the kind of thinking that stretched out the dark ages. Far better to ask "but wouldn't that interfere with XXX" and have someone have an answer for your fears than try to slap people down and be proven wrong. I don't think there's anyone out there arrogant enough to claim they know EVERYTHING about the Amiga. One man's fog is another man's Manna. There's alot of 'waste' from my viewpoint on Usenet. But I don't attack it, I figure it's part of the cost of getting what I can get. All networks, not just Usenet are like this. And quite frankly a 'frivolous' discussion can yield pay dirt just as easily as one steered from the start for pay dirt. I, for one, don't appreciate such obviously wrong blanket personal condemnations as you just made. I think several people have learned something from the discussion so far. I don't think it has been misleading nor downright wrong. I also didn't start the #$@! thing so don't lay the whole thing at MY doorstep in ANY case. >8-< Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
bmarsh@cod.UUCP (William C. Marsh) (05/19/87)
In article <494@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) writes: >In article <1542@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch >>floppy? sounds like 720k a side. > > It simply uses more tracks per side (160 tracks, versus 80 track/surface >on the Amiga). Yes, it is 720K/side. > According to the DOS 3.3 Technical Reference Manual (which IBM sent to me for some unknown reason) the two 'formats' for 3.5" media are as follows: Sides Sectors/Track Media Descriptor 2 9 F9H 2 18 F0H It looks like they put twice the number of sectors on the little disk, instead of twice the number of tracks. That means there won't be any "I can't write 720K disks in my 1.4M drive" problems like with the 1.2M drives in the AT. What, IBM learning from their mistakes? Maybe someday they will come out with a keyboard where you don't want to swap at least two keys... ---------- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/19/87)
>According to the DOS 3.3 Technical Reference Manual (which IBM sent to me for >some unknown reason) the two 'formats' for 3.5" media are as follows: > > Sides Sectors/Track Media Descriptor > 2 9 F9H > 2 18 F0H This isn't necessarily physical. It could be a logical mapping so software doesn't break. -Matt
keithd@cadovax.UUCP (05/20/87)
In article <494@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) writes: >In article <1542@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch >>floppy? sounds like 720k a side. > > It simply uses more tracks per side (160 tracks, versus 80 track/surface >on the Amiga). Yes, it is 720K/side. Oh YEAH? How compatible are the drives (including mounts)? Anybody know what's the possibility of getting a couple of drives, and with some driver hacks upgrading an Amiga to use them? Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa Contel Business Systems 213-323-8170
cmcmanis@pepper.UUCP (05/20/87)
In article <8705191949.AA17002@cory.Berkeley.EDU> (Matt Dillon) writes:
$>According to the DOS 3.3 Technical Reference Manual (which IBM sent to me for
$>some unknown reason) the two 'formats' for 3.5" media are as follows:
$>
$> Sides Sectors/Track Media Descriptor
$> 2 9 F9H
$> 2 18 F0H
$
$ This isn't necessarily physical. It could be a logical mapping so
$software doesn't break.
$
$ -Matt
But it is physical. Double the clock, double the sectors (or double the
size of the sectors). With the above note I am *sure* that IBM left the
AT type floppy controller intact and switch the data clock between
250 and 500 kilohertz. (I know dead horse, I'll stop now.)
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.grr@cbmvax.UUCP (05/20/87)
In article <1548@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > In article <494@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) writes: > >In article <1542@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >>Anybody have any idea how the new IBM PS/2 line gets 1.4 meg on 3 1/2 inch > >>floppy? sounds like 720k a side. > > > > It simply uses more tracks per side (160 tracks, versus 80 track/surface > >on the Amiga). Yes, it is 720K/side. > > Oh YEAH? How compatible are the drives (including mounts)? Anybody know > what's the possibility of getting a couple of drives, and with some driver > hacks upgrading an Amiga to use them? They're double bit density, not double the number of tracks. The built-in floppy disk controller can't handle MFM formats at the 500 K bits/sec rate used by these drives, 8" DD floppys or the AT 1.2 MB format. Apple type GCR might work, but you'd have to write you own floppy driver to test it out. -- 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)
jmpiazza@sunybcs.UUCP (Joseph M. Piazza) (05/22/87)
In article <19304@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: ... [How the PC2 gets 1.xxx Meg per disk] > >... Double the clock, double the sectors (or double the >size of the sectors). With the above note I am *sure* that IBM left the >AT type floppy controller intact and switch the data clock between >250 and 500 kilohertz. (I know dead horse, I'll stop now.) It ain't dead yet. What happens if you do this with an Amiga drive? What would be needed to make a new Amiga floppy drive do this? Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 (716) 636-3191, 3180 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@buffalo-cs BI: jmpiazza@sunybcs GE: jmpiazza
scotty@l5comp.UUCP (Scott Turner) (05/22/87)
Since Apple just doubled the clock rate available to the disk section of the new Macs, with the stated purpose of being ready for the new 1.4 meg drives, it would seem most likely that the doubling in storage capacity is coming from a higher data rate rather then twice as many tracks. On the "it can't be done" front. I received a phone call last night from one of the groups working on reading mac disks on the Amiga. They claim they can read 4/5ths of the Mac disk with VERY LITTLE TROUBLE. Reading the last 1/5th does present some what more of a challenge but they claim they can handle it. The greatest obstacle still left is how to calculate the 24 bit CRC used on the Mac disks. No dox have been found at present describing the polynomial used. Can anyone out there help? Drop me an E-Mail and I'll pass the info along. [So much for "FOG" :)] Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
farren@hoptoad.uucp (Mike Farren) (05/23/87)
In article <138@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >On the "it can't be done" front. I received a phone call last night from one >of the groups working on reading mac disks on the Amiga. They claim they can >read 4/5ths of the Mac disk with VERY LITTLE TROUBLE. Reading the last 1/5th >does present some what more of a challenge but they claim they can handle it. All right, all right, I give. I still have grave doubts about this stuff, but if they can do it, it must be possible, mustn't it? Sheesh, the things my mouth (fingers?) can get me into sometimes. I hereby apologize for my adamant defense of the "impossible" stance, and for an extremely offensive flame directed to Scott. HOWEVER: >[So much for "FOG" :)] The other point in my original posting was extremely badly (and baldly) stated, and buried in a bunch of "they can't do that" verbiage which allowed the point to be ignored in the general flamage (mostly justified, I must admit) which followed. That point, which I believe led to the "FOG" comment above, was simply this: when anyone is discussing the capabilities of the Amiga, it is extremely important to distinguish between real capabilities and "tricks", and to state the difference clearly. The example is the original posting by Scott Turner, in which he strongly implied that the Amiga hardware included provisions to control disk drive speed, and baldly stated that the disk controller hardware had provisions to change data timing at will. Within the context of the discussion his statements appeared in, both of these statements were untrue. Controlling disk drive speed by pulsing the motor control line does, in fact, change the drive speed. This is not, however, a built-in capability of the machine, but a software kludge - imaginative, but a kludge nonetheless, highly dependent on the physical construction of the drive mechanism, and absolutely NOT gauranteed to be constant from drive to drive. Secondly, the matter of disk data timing. Although the ADKCON register has a bit, FAST, which will change bit-cell timing from 2 microseconds to 4, this is not "control of disk data timing" in the sense in which it was being discussed at the time, which was basically a discussion of smoothly varying data timing over a given range, not switching between two discrete values. My problem with this was, and still is, that someone not intimately familiar with the way the Amiga hardware REALLY works could easily get very confused, and waste a lot of time trying to figure out how to get these capabilities from a machine which doesn't possess them. We all have much better things to do than to track down non-existent "facts". Scott has proven, several times over, that he does, indeed, understand the Amiga extremely well. My complaint was that he unintentionally made some VERY misleading statements. My mistake was to respond in a very extreme manner to what was a small offense. My apologies, again, for badly overstating the case, but I don't believe that my real point, as stated in the last three paragraphs, was any less valid for that. (BTW, as someone with 15 years of experience in this field, including the design of many disk controllers and disk device drivers, I am quite impressed with the people at Central Point if they really do manage to pull off the Mac-to-Amiga trick. I would have sworn (hell, I DID swear) that it was impossible. Must be getting old (sigh).) -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"