[Coco] Connect CoCo Floppy drive to Windows PC

[Gene Heskett]

On Sunday 18 January 2009, Steven Hirsch wrote:
>On Sun, 18 Jan 2009, Gene Heskett wrote:
>> On Sunday 18 January 2009, Bill Barnes wrote:
>>> IIRC, the PC Floppy controller is "sleeping" because when they designed
>>> it, they designed the supporting structure to reset the FDC chip every
>>> time the sector 0 sync hole came along. The CoCo didn't do that. Because
>>> of this there is an unused gap between the sync and chip "reset" recovery
>>> before it can write or read to the disk. It's in that gap, where the CoCo
>>> writes because it isn't clobbered over the head every sync to reset, that
>>> the PCs have a difficult time reading or writing to a CoCo disk that was
>>> formatted on a CoCo. Formatting a CoCo disk on the PC eliminates the
>>> unreadable time frame, as far as the PC is concerned, and the CoCo could
>>> care less that that gap exists.
>>
>> I had heard there was a gap timing problem occasionally, and it has
>> bothered the coco.  But this is the first time I've read a cogent
>> explanation of it. Thank you.
>
>I'll add to that.  It's something I've noticed when moving disks back and
>forth.  Once it's been formatted on a CoCo, my Linux box chokes on it.
>Other way around works fine.

And as you'll note, my experience has been the opposite.  What I think is 
wrong is that the linux formatter doesn't like sector 0's, on any track.  But 
that's just what I call a SWAG too.  I have not put a scope on it and 
compared them in that manner.

>> FWIW Bill, I find that when I am doing nitros9 disk images here in this
>> linux box, Fedora 8, generic kernel local build, that I must first format
>> the disk on the coco in order for it to work correctly, otherwise dd gets
>> a tummy ache a few sectors into the write and dumps out.  If anyone knows
>> the secret of properly formatting a coco disk on linux, I would appreciate
>> a hand. Software to use, command line to use, etc, please.
>
>Exactly the opposite from my experience.  I _can_ tell you that the disk
>parms are incorrect on many systems.  Here's what I had to do on a Xubuntu
>7.04 box:
>
>Install 'fdutils'

And what version does that install?   5.4 works mostly here, 5.5 has something 
wrong in its mediaprm parser from what I can get it to spit out.  It also 
ships with a broken mediaprm file, and an error in that file causes it to 
skip all entries below it.

>Check the media descriptor in /etc/mediaprm.  On my box, COCO360 and
>COCO720 used an extraneous 'zero-based' flag.  This is certainly incorrect
>for 5.25" diskettes (haven't tried the 3.5 yet).

That is another problem, that is not incorrect, but the parser thinks it is,, 
the coco (1793 family fdc's) are in fact a base zero sector numbering system,  
one of the very few, and only by beating a 765 based fdc about the brow 
forcefully, can you get it to accept 'track zero sector zero' numbering for 
write functions.
>
>Run the 'floppymeter' utility with a scratch diskette and let it calibrate
>for any variance in drive speed (creates a control file called
>/etc/driveprm.

IIRC I tried that a couple of years ago, and it couldn't find the drive or 
some such sillyness.  It is not installed, and:
[root at coyote etc]# yum install fdutils
livna                                                                                                                     | 
2.1 kB     00:00
fedora                                                                                                                    | 
2.1 kB     00:00
rpmfusion-free-updates                                                                                                    | 
2.7 kB     00:00
rpmfusion-nonfree-updates                                                                                                 | 
2.7 kB     00:00
rpmfusion-free                                                                                                            |  
951 B     00:00
updates-newkey                                                                                                            | 
2.3 kB     00:00
fedora-source                                                                                                             | 
2.1 kB     00:00
rpmfusion-nonfree                                                                                                         |  
951 B     00:00
updates-newkey-source                                                                                                     | 
2.1 kB     00:00
Setting up Install Process
Parsing package install arguments
No package fdutils available.
Nothing to do

The repos have been cleaned out, this is an F8 system.  EOL for F8 support was 
a week ago. :(

It may be on a dvd, I haven't looked.  Busy putting out other fires, like 
verizon's dns servers became inaccessible to anything but a ping about 7Pm & 
I've been battling with the typical morons in tech support on a Sunday since.  
They are incapable of groking that my OS of choice has absolutely zip to do 
with their failed dns setup. Finally a friend called and he got me setup to 
use the opendns servers.  And they are 10x faster than vz's have ever been.
I won't convert back.

>Format diskettes by:
>
>- Insert diskette in drive
>
>$ setfdprm /dev/fd0 COCO360
>
>$ superformat /dev/fd0 COCO360
>
>Copy image:
>
>$ dd if=<image_file> of=/dev/fd0 bs=256
>
>Adjust names to suit your system.  The important issue to always execute
>setfdprm with the target disk in the drive.

Yes, cuz all those config changes are nulled when the drive says the disk is 
gone.

>Steve

-- 
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)
There are running jobs.  Why don't you go chase them?