[Coco] HDBDOS - RETRIEVE FIXED!!
Chad H
chadbh74 at hotmail.com
Sun Jan 18 19:43:42 EST 2015
P.S. I forgot to mention, my fill statement was erroring out as well. I guess that what happens when it grows to >8K. I just remarked out the fill statement to allow a bigger build, used my hex editor to find the right offset for the MAGICDG in the HARD DISK DRIVER section, then recompiled and was ok. The .BIN was funny about loading. It would load, but would give a "?IE ERROR" after loading. Still the EXEC brought it up just fine. Once I burned it to a 16K EPROM, I just had to modify my FD-502 pack since Tandy shorted the A13, A14 and A15 lines to +VDC which means it will only do 8K normally. Since the 3 pins were in a line with a common trace on the EPROM, I just cut the trace at the A13 pin and soldered a short jumper back to the card edge connector, 2nd pad from the left on top for the A13 line back to the CPU and voilia! The EPROM booted! It wouldn’t do that without the mod.
I went ahead and did another short patch to my HDBDOS that sets it to try the AUTOEXEC from physical Floppy . The "*****" marks the 2 lines I added ...
* Test for SHIFT key, skip autoboot if pressed
BOOTUP lda #$7F Shift bit mask
ldb #$04 Group first 4 drives *****
jsr DCLOSE Clear Hard Drive Flag (Drive OFF) *****
* Optimizations below save 1 byte
* ldx #$FF00 Point to keyboard PIA
* sta 2,x Set columns
sta $FF02 Set columns
* lda ,x Read rows
lda $FF00 Read rows
coma Invert
anda #$40 Keep SHIFT
bne BASICBYE Was pressed, go to BASIC
This too worked OK but I had to adjust the MAGICDG offset again. I then tried adding on something to the bootup copyright. It did work, and I thought everything was ok. The DSKINI was working and everthing. But I then tried to BACKUP a floppy to another and it acted funny...the head was making noises like the disk was going bad.. But it didn’t behave that way with the same disk under the old ROM. From glancing over the "BACKUP" section it appears there is a reserved buffer after the fcb's at the very end of the code. For some strange reason it's commented as anything above "FFFF" is illegal.. What!!? According to the memory map I'm looking at $FF00-$FFFF is reserved for "I/O, machine configuration, reset vectors" It should stop at $FEFF instead of $FFFF I would think. It shouldn’t be allowed to step all into those vectors. I suspect the increased size of the code had caused just that and was confusing the BACKUP operation I was doing. It’s a wonder it didn't freeze or give me errors. I went back and removed my startup message and everything is working smooth with my floppy boot patch and the DSKINI patch so I'm good for now.
I would LOVE to know how to adjust things further without crashing it! If you guys figure that one out that would be awesome. I believe Juan Castro would be a good person to ask about this since he made a 16K CoCo2 HDBDOS a little while back with WIDTH 64 screens, some CoCo 3 commands added, etc. I know that took up more space than what we are trying to do!!
- Chad
-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
Sent: Sunday, January 18, 2015 6:01 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] HDBDOS - RETRIEVE FIXED!!
Yes I know right!! I played around with that section of code ALL DAY yesterday!! You have to adjust this section every time you change the length of the code before it...
* HARD DISK DRIVER
org MAGICDG+$193D It all starts here!
* Indirect Jump Table ( jsr [$MMMM] )
fdb DISKIO universal hard disk input / output
fdb SETUP Setup command packet
fdb BEEP Make a beep sound
fdb DSKCON2 DSKCON Re-entry
HDBHI fcb $00 HDB-DOS Offset hi-byte
HDBLO fdb $0000 HDB-DOS Offset lo-word
PORT fdb DATAADDR Interface base address
CCODE fcb TDELAY IDE: startup delay / SCSI: wakeup delay
That "MAGICDG" Offset, if not right, made it freeze instantly. If you use a hex editor on the original HDBDOS.ROM file for your computer you will see at the offset they have there this long string of ff's with a data marker at that address. (ff ff ff 99 da ad da b3 ...." It's that first 'da' that you have to find the offset of and change it beside the MAGICDG.
-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Robert Gault
Sent: Sunday, January 18, 2015 3:55 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] HDBDOS - RETRIEVE FIXED!!
Chad,
I been trying something similar but for some reason my version of hdbdos.asm does not correctly use the fill statement at the end and I either get overflow past $2000 or inadequate filling with $39. Also the default positions for things like jump tables and the drive value table change location in memory.
Anyway I used
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
lda <DCDRV should be $EB ie. drive #
lsra 0&1 become 0 while 2&3 become 1
sta ,x+
lda DSEC * GET SECTOR NUMBER AND
sta ,X+ * STORE IT IN THE BUFFER
ldb #$09 = GET THE LAST NINE DATA BLOCKS AND
etc.
This did not work for me on my system but it could have been a problem compiling the code.
Robert
--
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