[Coco] HDBDOS - RETRIEVE FIXED!!

[Kip Koon]

I was wondering why the assembler wasn't calculating the proper addresses for the labels, etc.  Thanks for catching this.  It might be good to put this change as well as all the other suggestions into the HDB-DOS repository.  It would definitely be nice to create 8K and 16K assembler switches to enable the creation of both 8K and 16K rom images with all the cool extras included in the 16K version.
There were some very interesting updates recently to HDB-DOS giving Coco 1 and Coco 2s some Coco 3 commands.  I tested the rom and it was quite nice.  
I am passed ready to see all these all these wonderful features gathered together into the repository.  Since it is building a bunch of different rom images already, let's get these new ideas into the mix as well.  I for one say GO FOR IT!

Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/Kip_Koon



-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of William Astle
Sent: Monday, January 19, 2015 7:28 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] HDBDOS - RETRIEVE FIXED!!

Something that needs to be done before messing with putting a "fill" 
statement there is to move *all* of the "definitions" (the equ and rmb
stuff) between the "DOSINI" symbol and that "org MAGICDG-$193D" line to the start of the file. Otherwise, all those definitions with their interposed "org" statements will cause "fill" to end up with a negative value anyway.

Moving them to the start of the file makes them more discoverable anyway.

On 15-01-19 05:14 PM, Brett Gordon wrote:
> Yup.  This should work:
>
>              fill   $39,MAGICDG+$1930-*
>
>
> The -* part make lwasm calculate the number of bytes from the current 
> address to the MAGICDG+$1930.  Basically "*" stands for "the current
> address.     If the bottom parts of the ROM gets too big, then the
> result of "MAGICDG+$1930-*" becomes negative and farts out.....
>
>
>
> On Mon, Jan 19, 2015 at 11:13 AM, Chad H <chadbh74 at hotmail.com> wrote:
>> I think I understand what you are saying here.  Whereas with the "MAGICDG+$1930" it was offsetting at a fixed point, which was shifting by my adding of bytes.   Your solution of 'fill $39,MAGICDG+$1930'  would instead pad the gap so to speak and keep the Hard drive routine from moving?  This makes me want to go try again with your change and see if I can add in the extra bootup copyright string and see if it works.  I'll report back...
>>
>> -----Original Message-----
>> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Robert 
>> Gault
>> Sent: Sunday, January 18, 2015 9:26 PM
>> To: CoCoList for Color Computer Enthusiasts
>> Subject: Re: [Coco] HDBDOS - RETRIEVE FIXED!!
>>
>> 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.
>> 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.
>>
>> 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
>
>
>


--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco