[Coco] FW: Color Computer DSKINI / RETRIEVE

Chad H chadbh74 at hotmail.com
Sat Jan 17 18:47:04 EST 2015


The source of the Side 1 problem with RETRIEVE has been confirmed!!!!

I managed to patch the HDBDOS DSKINI routine to write all 1's for the head ID byte instead of all 0's.   This FLIPPED the problem from Side 1 to Side 0 !!

Now, RETRIEVE will read Side 1 just fine, but errors out on Side 0!

All I have to do now is figure out how to get it to write 0 or 1 as appropriate depending on the drive number being formatted and RETRIEVE will always be able to read any side of any CoCo DSKINI'd diskette.

In tinkering with the HDBDOS code I noted that it 'pads' the .ROM image but they are already near the 8K max boundary set by the $2000.  Remarking that out allowed me to successfully build the .BIN.  The other thing that threw me for a loop was the MAGICDG offset.  I had to adjust it a couple of bytes or the .BIN hanged upon EXEC.

Any easy way to remove unused code via the makefile or something to trim this down?  I don’t use HDBDOS hard drives for example.  If I have access to my physical floppies and drivewire I'm good.

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
Sent: Saturday, January 17, 2015 12:21 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] FW: Color Computer DSKINI / RETRIEVE

Oops...typo in the copy paste..Was supposed to be...

- Physical Drive 0 -
DRIVE 0 = Physical Side 0  (RETRIEVE reads this OK!) DRIVE 2 = Physical Side 1  (RETRIEVE FAILS!!!)

- Physical Drive 1 -
DRIVE 1 = Physical Side 0  (RETRIEVE reads this OK!) DRIVE 3 = Physical Side 1  (RETRIEVE FAILS!!!)


-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
Sent: Saturday, January 17, 2015 12:19 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] FW: Color Computer DSKINI / RETRIEVE

For clarification of the problem for those haven't been following this...

ROM: Standard HDBDOS

SITUATION:  Double sided floppy DSKINI'd on the CoCo SUCCESSFULLY!
RETRIEVE CAN read one side of the disk but gives ERRORS when attempting the second side.

- Physical Drive 0 -
DRIVE 0 = Physical Side 0  (RETRIEVE reads this OK!) DRIVE 2 = Physical Side 1  (RETRIEVE FAILS!!!)

- Physical Drive 1 -
DRIVE 1 = Physical Side 0  (RETRIEVE reads this OK!) DRIVE 2 = Physical Side 1  (RETRIEVE FAILS!!!)

WORKAROUND SO FAR:  Use the PC DSKINI utility to format the disk instead of the CoCo DSKINI.  Then it will still work in the CoCo but also be successfully read by the PC RETRIEVE for BOTH SIDES!!

CURRENT SUSPECT:  It appears that from the beginning the CoCo DSKINI routine was designed for single sided drives.  Later, when people started changing the drive tables, and even after the advent of HDBDOS, no one ever bothered to update the 'FORMAT TRACK IN RAM' coding that identifies every single sector to which side of the disk it belongs!!!   It just blindly marks all sectors as being side "0" regardless of what physical side it really is.

I'm currently attempting to test a 'Possible' solution by patching the format track building code in the HDBDOS DSKINI command to write a 0 or 1 appropriate to the Drive # selected in DSKINI parameter as opposed to blindly writing a "0" identifier on all sectors.



-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
Sent: Saturday, January 17, 2015 10:01 AM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: [Coco] FW: Color Computer DSKINI / RETRIEVE

Well Jeff was kind enough to respond to my side 1 issue with RETRIEVE.  Unfortunatley his suggestion didn't work.  I'm still trying to find out if I can 'patch' the HDBDOS DSKINI routine to check the drive number and write the appropriate head byte of 0 or 1 instead of always 0.

-----Original Message-----
From: Chad H [mailto:chadbh74 at gmail.com]
Sent: Saturday, January 17, 2015 9:59 AM
To: 'Jeff Vavasour'
Subject: RE: Color Computer DSKINI / RETRIEVE

Sorry, I tried covering the index holes and the PC wouldn’t read the floppy at all.  Even the DOS "DIR" command, which usually results in some drive noise from head movement for a moment then ends in error, it remains 'silent' with no head movement and errors out with the index holes covered.

Since I'm on a HDBDOS EPROM, I've tracked down the spot in the HDBDOS assembly source where the 'head' byte is encoded in.  It only seems to be referenced in the actual DISKINI routine itself.  If I can somehow figure out how to compare the drive number (DCDRV ?) and if it's greater than CoCo drive # 1 then it's the other side of a disk so write a "1" instead of the usual "0" then maybe...just maybe it might work?

>From the HDBDOS assembly source in the DSKINI section (note it just clears the byte to 0 always)...

* BUILD A FORMATTED TRACK OF DATA IN RAM STARTING AT DFLBUF.
LD691          ldx       >$1F
*LD691	LDX	#DFLBUF	START TRACK BUFFER AT DFLBUF
               ldd       #$204E              GET SET TO WRITE 32 BYTES OF $4E
               bsr       LD6C2               GO WRITE GAP IV
               clrb                          RESET	SECTOR COUNTER
LD69A          pshs      B                   SAVE SECTOR COUNTER
               ldu       #DBUF1              POINT U TO THE TABLE OF LOGICAL SECTORS
               ldb       B,U                 * GET LOGICAL SECTOR NUMBER FROM TABLE AND
               stb       DSEC                * SAVE IT IN THE DSKCON VARIABLE
               ldu       #LD6D4              POINT U TO TABLE OF SECTOR FORMATTING DATA
               ldb       #$03                * GET FIRST 3 DATA BLOCKS AND
               bsr       LD6C8               * WRITE THEM TO BUFFER
               lda       DCTRK               = GET TRACK NUMBER AND STORE lT
               sta       ,X+                 = IN THE RAM BUFFER
               clr       ,X+                 CLEAR A BYTE (SIDE NUMBER) IN BUFFER
               lda       DSEC                * GET SECTOR NUMBER AND
               sta       ,X+                 * STORE IT IN THE BUFFER
               ldb       #$09                = GET THE LAST NINE DATA BLOCKS AND
               bsr       LD6C8               = WRITE THEM TO THE BUFFER
               puls      B                   GET SECTOR COUNTER
               incb                          NEXT SECTOR
               cmpb      #SECMAX             18 SECTORS PER TRACK
               blo       LD69A               BRANCH IF ALL SECTORS NOT DONE
               ldd       #$C84E              WRITE 200 BYTES OF $4E AT END OF TRACK
* WRITE ACCA BYTES OF ACCB INTO BUFFER

-----Original Message-----
From: Jeff Vavasour [mailto:jeff.vavasour at shaw.ca]
Sent: Friday, January 16, 2015 11:15 PM
To: Chad H
Subject: Re: Color Computer DSKINI / RETRIEVE

Hi,

The problem is in your PC's floppy drive. It goes "blind" to data a moment after the index hole is sensed, but the CoCo does not. When the disk is formatted on the PC the track starts further away from the index hole than when it is formatted on the CoCo. The only workaround to read CoCo formatted disks on some drives on the PC is to put a sticker (such as a write protect tab) over the index hole, as it is not always needed. 

- Jeff

----- Original Message -----
From: Chad H <chadbh74 at gmail.com>
To: jeff vavasour <jeff.vavasour at shaw.ca>
Sent: Wed, 14 Jan 2015 20:04:30 -0700 (MST)
Subject: Color Computer DSKINI / RETRIEVE

Hi, I've been using these tools on my floppy/CoCo 2 setup for a few years now with good results.  Thank you for sharing these tools! J  However, recently I've become reacquainted with a 'glitch' I've been wanting to iron out.  You may or may not already be aware of the problem.

 

**

Floppy formatted by the CoCo will RETRIEVE side 0 OK.but not side 1.

Work around so far.   DSKINI the floppy using your tool first, then it
works.

 

**

Since the issue only seems to effect one side of the floppy I thought I could conjur enough mental fortitude to spot some place in your assembly code for these to see why this might be happening.  Unfortunately  assembly was never my strong suit L

 

I was wondering if you might be able to give me a pointer or clue on something to try or anything you could do to help.  I realize this project may be umm.retired? If that's the best way to put it?  Thanks for any help you can give anyways! 



--
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



More information about the Coco mailing list