[Coco] Rusty ole FD-501

[Chad H]

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