[Coco] Rusty ole FD-501

[Stephen H. Fischer]

What is on a track (Cylinder)? In the "1773 disk controller", while you need to read a lot of words there is a picture on page 1-17 that may help quickly.

http://maben.homeip.net/static/s100/western%20digital/datasheet/WD%201773%20Floppy%20Disk%20Controller.pdf

I have an earlier version of this document from ~ 197x.

We are using Double Density format on the CoCo. FLEX uses a strange method of having Track 0 always in Single Density and the rest of the tracks in Double Density if trace 0 says so.

> It's the information written to every block of data on the disk in addition to the 256 bytes of sector data.

Do you have a bulk tape eraser? I have one and would be bulk erasing the floppy disks before each test. I always use it if the floppy does not say what formatted it. I have ~ 5-8 different color labels.

Whenever I wanted to write a 40T 2S OS-9 5-1/4" disk for a friend I always had to bulk erase the floppy first. (Why, my 80T head is one half the width of 40T head.)

SHF

----- Original Message ----- 
From: "Chad H" <chadbh74 at hotmail.com>
To: "'CoCoList for Color Computer Enthusiasts'" <coco at maltedmedia.com>
Sent: Thursday, January 15, 2015 8:22 PM
Subject: Re: [Coco] Rusty ole FD-501


>I managed to 'Hack' Jeff's older RETRIEVE source to cycle between heads 0 & 1 and get a good solid verifyable .DSK image off of a 2-sided disk.   However, it exhibited the exact same behavior as Johns version and errored on head 1 unless the diskette had been formatted with the DSKINI utilility.
> 
> The old v1.3 source of Jeff's RETRIEVE and DSKINI had no accompanying DISK.ASM referenced.  Everything was self contained.  I did some research on the DOS Int13h and Int21H and was able to decipher the head select registers and create a variable in the code to cycle it....not much good it did though except to confirm the strangeness of the problem once again.
> 
> I'm beginning to wonder if it has something to do with the "media descriptor" information I've been seeing in the assembly codes.  It's the information written to every block of data on the disk in addition to the 256 bytes of sector data.  The reason I say this is because most of us use a modified DECB drive table in our HDBDOS, etc and I have no idea what kind of 'extra' information the CoCo DSKINI puts on the disks when formatting them.  Perhaps it's not writing the correct descriptors or something when writing to that drive number?  This would explain why the PC side formatting is restoring the expected descriptors.
> 
> 
> ** I tell people often:  I make mistakes every single day! ... I just fix them before anyone finds out about it. **
> 
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Stephen H. Fischer
> Sent: Thursday, January 15, 2015 9:43 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Rusty ole FD-501
> 
> You have in validated my statement that I used Jeff's original RETRIEVE to read the second side of my DECB floppies.
> 
> I may well have been using John's at that point in time.
> 
> The (c) years may be the way to tell them apart.
> 
> SHF
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>