fche@db.toronto.edu (Frank Eigler) (04/20/89)
In article <10751@mcdphx.phx.mcd.mot.com> dbk@teroach.UUCP (Dave Kinzer) writes: > > Since nobody responded to the deeper FIFO question for a 2090a >(although I admit I posted in the no.tech group), I have come up with >yet another hack project idea. > > If one were to half the RPM rate of a 1.2meg 5.25 inch floppy >(or a 1.44meg 3.5 inch floppy), the Amiga floppy disk circuitry could >still send at 250Kbits/sec and this would be deposited on the drive >at the appropriate bit density (normal bit rate is 500Kbits/sec). >This would allow more sectors to be placed per track on the drive. >The question is, can the trackdisk.device handle reading/buffering/writing >twice as many blocks per track as normal? Can this just be specified >in the MountList? Another question, something in the same area. Is it possible/has anyone ever written a trackdisk.device replacement that uses RLL format instead of MFM on a floppy? It would probably be *very* useful. 1.44 megs, easy. Or, is it possible with the hardware at all? --Frank -- ................................................................. Frank Ch. Eigler |The Hack BBS _ (416)-265-3984 // fche@db.toronto.edu | /\ /\/\ / / \ /\ // fche%db.toronto.edu@relay.cs.net| /__X X / _ /__\ \\ // {uunet,watmath}!utai!db!fche |/ / \ / \\__// \ \X/
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (04/20/89)
In <10751@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) writes: > Since nobody responded to the deeper FIFO question for a 2090a > (although I admit I posted in the no.tech group), I have come up with > yet another hack project idea. I was thinking about answering this one, but lack of definitive information on the feasibility kept me from doing so. The idea is intriguing, and the next time I have my 2090A out, I'll see if I can find the FIFO(s), and then see if I can find a replacement that is deeper, and give it a try. I really don't have a problem with mine unless I go out of my way to create it by having a fairly complex picture displayed. If I did have the problem often, I would probably opt for Khalid Aldoseri's 'Patch2090', that solves the problem quite nicely. The hardware solution would be preferable of course. > If one were to half the RPM rate of a 1.2meg 5.25 inch floppy > (or a 1.44meg 3.5 inch floppy), the Amiga floppy disk circuitry could > still send at 250Kbits/sec and this would be deposited on the drive > at the appropriate bit density (normal bit rate is 500Kbits/sec). > This would allow more sectors to be placed per track on the drive. > The question is, can the trackdisk.device handle reading/buffering/writing > twice as many blocks per track as normal? Can this just be specified > in the MountList? There are two possible sources of problems in the above scenario. The first is that of media, and the second, closely related, is that of the heads. In a 1.44 MByte floppy, the media is definitely different, having a higher coercivity. In order to compensate for this, the head must put out a higher write current, and may well have other characteristics that help them to be able to get high densities. You might be able to get away with slowing the rotation to a degree, but I doubt very much that you could halve the RPM and still get reliable operation. The only thing necessary to use a different number of sectors per track from a system point of view is to create a mountlist entry (with a different name, ie. DF4:), and specify the specify the different geometry with that. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
jesup@cbmvax.UUCP (Randell Jesup) (04/21/89)
In article <89Apr19.165456edt.9318@ois.db.toronto.edu> fche@db.toronto.edu (Frank Eigler) writes: >Another question, something in the same area. Is it possible/has anyone >ever written a trackdisk.device replacement that uses RLL format instead >of MFM on a floppy? No. >Or, is it possible with the hardware at all? Probably yes, though it may require better than normal media (just as some ST506 drives can't handle RLL). I suspect the hardware in paula and the drives could do it, though I'm not certain. The real killer is encode/decode. MFM decode is trivial (((word[i] & 0x55555555) << 1) | (word[i+(BUFFSIZE/2)] & 0x55555555)) - I may have which word is shifted wrong, check the RKM. The blitter can do that in one pass, and store it in the users buffer. Decode is trickier, takes 4 passes, but the blitter can still handle it. RLL would be real tough with the blitter. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
bader+@andrew.cmu.edu (Miles Bader) (04/22/89)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > In <10751@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) writes: > > Since nobody responded to the deeper FIFO question for a 2090a > > (although I admit I posted in the no.tech group), I have come up with > > yet another hack project idea. ... > complex picture displayed. If I did have the problem often, I would probably > opt for Khalid Aldoseri's 'Patch2090', that solves the problem quite nicely. > The hardware solution would be preferable of course. What does "Patch2090" do? -Miles
jesup@cbmvax.UUCP (Randell Jesup) (04/22/89)
In article <2376@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > I was thinking about answering this one, but lack of definitive information >on the feasibility kept me from doing so. The idea is intriguing, and the next >time I have my 2090A out, I'll see if I can find the FIFO(s), and then see if I >can find a replacement that is deeper, and give it a try. I really don't have a >problem with mine unless I go out of my way to create it by having a fairly >complex picture displayed. If I did have the problem often, I would probably >opt for Khalid Aldoseri's 'Patch2090', that solves the problem quite nicely. >The hardware solution would be preferable of course. That would be interesting, since I think the FIFO is part of a custom chip (I could be wrong, I'm just a programmer. :-) What is this "Patch2090" program, what does it do? -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/03/89)
In <IYHvj2y00UkaE1YJQr@andrew.cmu.edu>, bader+@andrew.cmu.edu (Miles Bader) writes: >What does "Patch2090" do? It intercepts calls to hddisk.device, and checks for the presence of a hi-res, interlaced screen of a certain depth, which is likely to cause the infamous retries on the SCSI bus. If it finds there is going to be contention, it fudges the MaxTransfer value to prevent long, uninterrrupted reads. Since the entire read need not be retried if contention occurs, things get considerably faster. It is a kludge, and the method used is not exactly kosher (the MaxTransfer value the driver actually uses is not stored in a place where nice programs go), but it works. I'll see if I can get it mailed off to Bob. Khalid is another member in good standing of DAS (Devil's Advocate Software). -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+