[Coco] 3.5" Drive Variable in the NitrOS-9 Module Header

[Wayne Campbell]

I recall that, although I never saw one, 720K floppies did exist, both in 5.25 and 3.5 varieties. I'm not sure it will be worth it for those, except for completeness as they were rare back then (89-94). I think the greatest issue will be the high-density drives. The 5.25 variety is 1.2 meg instead of 1.44 meg. Will that make a difference to the driver?

When I had my Coco3 I had 3 80-track floppies, 2 5.25 and 1 3.5. I found a 1.44 meg 3.5, but it was only usable as a 80-track 360K because the descriptors and driver wouldn't work with anything larger under OS-9 Level 2.


Kip Koon <computerdoc at sc.rr.com> wrote:

>NitrOS-9 Developers,
>
>I have been giving some serious thought to the recent discussions about when
>to use a track density of 48 tpi or 96 tpi.  Here's my thoughts on the
>matter.  Create a new bit in the Drive Descriptor which is called '3.5"
>Drive Track Density' and this is how it would work.  When this bit is set to
>0 (zero) the other track density bit would be active.  When set to 1 (one),
>the other track density bit's effects are deactivated and the new track
>density becomes 135 tpi.  We could also implement a bit called "Quad Data
>Density"  to take advantage of the 3.5" drive's highest data density
>capability and finally reach the full capacity of a 1.44 floppy disk drive
>and it could work in a similar fashion.  When the bit for Quad Data Density
>is 0 (zero), the other data density bit is active, and when the Quad Data
>Density bit is 1 (one) the other data density bit is deactivated and the
>data is encoded onto the floppy disk's surface using the 3.5" drive's Quad
>Data Density capabilities.  Of course all disk drive drivers would have to
>be updated to implement the change in the Drive descriptor giving the
>correct commands to the 3.5" drive when appropriate.  If there is space for
>these two new bits in the current Drive Descriptor Definition, there may be
>the possibility that only floppy drive drivers would need to be updated due
>to the definition that if both new bits were 0 (zero) their older
>counterpart bits would remain active and all should be well.  So guys, what
>do you think of my brain storming session?  Do you all think that this may
>be possible?  So far in my thoughts, it sounds very doable.  Thanks for
>considering my suggestion.
>
>Kip
>
> 
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco