[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