[Coco] HDBDOS - RETRIEVE FIXED!!
Tormod Volden
lists.tormod at gmail.com
Tue Jan 20 12:52:31 EST 2015
On Mon, Jan 19, 2015 at 4:26 AM, Robert Gault wrote:
> Chad H wrote:
>>
>> 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.
>
>
> I know what is happening but not why. The problem almost certainly is with
> lwtools.
I think the reason is how lwasm implements "org", which is documented
in the lwtools documentation. For non-raw output formats it will
change the loading address, but naturally not for raw formats, which
is used here for assembling HDB-DOS. And it will not pad the binary
either... So fill is required, unless the HDB-DOS assembly workflow is
changed to using non-raw formats.
Tormod
> All the intermediate org statements in the program are being ignored. If you
> replace
> org MAGICDG+$1930
> with
> fill $39,MAGICDG+$1930
> then the HDBDOS jump table and offset will always be at $D930.
>
> Given this problem, all the org sections probably should be changed to equ.
More information about the Coco
mailing list