[Coco] Formatting HD floppies w/ modified controller.

[Gene Heskett]

On Friday 07 October 2005 17:02, Robert Gault wrote:
>Before you do more testing, at least get the latest 3.02.05 version so
>we lock in the specific modules being use. I'm quite willing to accept
>that rb1773 is causing a problem, but without a known platform for
>testing, no fix is likely. It looks like v3.02.04 does not use the
>rb1773 which slows during format.
>
>By the way, the actual hardware I just used to test the code is the
>Disto SCII which is a 1773 controller (but not Tandy's) and a Tandy 1793
>controller. The controllers were connected to the Coco3 via an MPI and
>the 3.5" drive is a modern high density drive. Disks were MF2DD type.
>
>The disks were formatted for double sided, 40 tracks per side at TPI 96.
>
>Just as a point of information, rb1773 slows down only during the track
>write command, not during any data read/writes.
>
>RESULTS
>The success of the format procedure was dependent on the disks rather
>than the controllers. Any errors that showed up during the verification
>step, changed track number when disks were changed. Errors were all 243,
>CRC error.
>
>Repeated formats on the disks that gave errors, eventually resulted in a
>full format of $B40 sectors without any errors.
>
>COMMENTS
>The above is not a high density format in a modern sense as these disks
>should be capable of 135 TPI, 80 tracks. Still the normal Coco density
>is 48 TPI.
>
Thats mixing apples and oranges.  48 tpi is only valid on 5.25" disks. 
All 3.5" disks are 135 tpi, and its not adjustable.

But if you are using MF2DD disks, those are only rated for double denisty
recording, which at the 3.5" disks default track number of 80 tracks,
gives 720k.

>On my system, NitrOS-9 v3.02.05 will format 3.5" disks at 96 TPI but the

The drives do not recognize nor respond to the tpi setting, so the device
descriptors tpi is meaningless on a 3.5" disk.  All that counts is the
total number of tracks, 80 is std, and the data rate, 250kbaud being DD. 
It takes a modified controller to write at 500kbaud and get the full 1.44
meg capacity from an HD disk.

Modern 3.5" drives apparently switch the internal decoder speed according
to the HD hole, or lack thereof.  To find one that will do 250kbaud when
an HD disk is inserted may take sorting through the junk box for one that
doesn't do this data rate speed switch.

>disks must be in good magnetic condition. I have not bought new disks
>for many years and did encounter errors. These appear to be caused by
>degraded magnetic material on the disks rather than hardware or
> software.
>
>Paul T. Barton wrote:
>> Mark,
>>
>> OK, boot reads v030204.
>>
>> How can I access this
>> "version info" internally,
>> without rebooting?
>> ---
>>
>> I can format/read 80tks normal density,
>> no problem. Cannot format/read
>> hi-density (double-datarate) using
>> the 1793 controller, with rb1773.
>>
>> Paul - idezilla
>>
>> --- Mark Marlette <mark at cloud9tech.com> wrote:
>>>Paul,
>>>
>>>At the top of the boot screen will indicate the
>>>os version.
>>>
>>>I'm using all version 030205 components. Most
>>>times I get a CRASH after
>>>less that three track steps.
>>>
>>>I did put my 1793 controller into slow mode and
>>>did do a good format
>>>last night. Same procedure done on a 1773
>>>(FD501) controller, different
>>>machine and it crashed every time I tried it.
>>>
>>>So with Roberts fix of slow mode doesn't fix
>>>the problem on my end.
>>>There is something else causing this. Puzzled.
>>>
>>>Mark
>>
>> --snipped--
>>
>>
>>
>>
>> __________________________________
>> Yahoo! Mail - PC Magazine Editors' Choice 2005
>> http://mail.yahoo.com

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.