[Coco] HDBDOS - RETRIEVE FIXED!!

[David Ladd]

Tormod,

Yes it would be nice if we didn't need to worry about stuff being hard
coded.  Sadly so many programmers back then figured the ROM's would never
change and figured it would be safe to use portions of routines in the
ROM's.  Sadly one of the reasons modifying HDBDOS becomes a pain lol.

I even applied this patch to normal disk basic as well and stuck it in my
CoCoSDC for testing on both the CoCoSDC and real FDC.  That I only tested
for about a hour.  :O


On Tue, Jan 20, 2015 at 3:28 PM, Tormod Volden <lists.tormod at gmail.com>
wrote:

> On Tue, Jan 20, 2015 at 6:52 PM, Tormod Volden wrote:
> > 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.
>
> Or... unless the HDB-DOS code is changed to not require hardcoded code
> locations in the middle. A jump table at $9930? What is this about?
> Can somebody please tell me what is using this jump table? Are there
> third party applications expecting to jump in here? Is this table
> common among various DOS implementations?
>
> Tormod
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>