[Coco] Rusty ole FD-501

Fri Jan 16 03:21:44 EST 2015

A few items of possible interest while you are reading the fdc data sheet.

The CoCo and PC both use "soft" sectored floppies, not "hard" sectored ones.

First, I am talking about a freshly bulk erased disk. That is important!

When as the disk rotates the index hole is detected and at that point the fdc is reset.

The process starts with a "Write Track Command" which shortly after the index hold is detected an entire track is written. (To all tracks / cylinders one by one).

An exercise at this point is to calculate how many characters are written to the track for 512 byte sectors and how many for 256 byte sectors. The resulting tracks are NOT of the same length. If you go from the format that is longer to the shorter one without bulk erasing, you are asking for trouble. TROUBLE!

After the write track command is done the position of all the sectors on the track have been defined with no data in the sectors. The overhead characters between the sectors are to allow the fdc to get back into sync.

Data is written to sectors by having the fdc watch for the sector number to write and when it is seen to turn on the write head to write the data to the sector and then a few trailing characters and then turn it off. But never so many as to clobber the fdc detecting the next sector.

Sectors are not in order, 0, 1, 2, 3, 4, 5, 6, ... is not used because time is needed after a sector is read to process the data in the sector.

So, the sector order may be 0, 2, 4, 6, ... 1, 3, 5, 7. The interleave is in the OS-9 manual.

When sectors are written the fdc must get into sync for each sector even after sectors have been written several times which causes jitters in the placement of the sectors.

SHF

----- Original Message ----- 
From: "Chad H" <chadbh74 at hotmail.com>
To: <coco at maltedmedia.com>
Sent: Thursday, January 15, 2015 9:05 PM
Subject: Re: [Coco] Rusty ole FD-501

> Thanks for that data sheet reference... I'll definitely check that out.  I've also just been exploring the DSKINI section of the HDBOS source.  It talks about 'gap' size and between sectors just like mentioned in Johns source. The HDBDOS said it uses the minimum allowable.  I'll check correlations wherever possible.
> 
> Sent from my Transformer Infinity
> 
> -------- Original Message --------
> From: "Stephen H. Fischer" <SFischer1 at Mindspring.com>
> Sent: Thursday, January 15, 2015 10:50 PM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Subject: Re: [Coco] Rusty ole FD-501
> 
> 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
>>
> 
> --
> 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
>