[Coco] Kinda disappointed with 6809 assemblers

[Luis Antoniosi (CoCoDemus)]

ah ok, that's a start. Thanks.

On Thu, Jan 31, 2013 at 1:45 PM, Steve Bjork <6809er at srbsoftware.com> wrote:

> Try this to define the Index into the object (DataBlock.)
>
>             org       0         ;Game object
> octrl    rmb      1         ;Control Byte
> xpos    rmb      2         ;16-bit x position
> ypos    rmb      2        ;16-bit Y position
> olen     equ       *        ;PC counter is the length of the object
> ....
>
>             org        0        ;Sound Object
> sctrl    rmb      1        ;Control Byte
> spnt    rmb       2       ;Pointer to next digital byte to output
> scnt    rmb       2       ;# of bytes left to play
> slen     equ       *       ; PC counter is the length of the object.
>
> Just do the above before the start of the program.
>
> Steve
>
> On 1/31/2013 9:37 AM, Luis Antoniosi (CoCoDemus) wrote:
>
>> mega ROM files. When using mega-rom paks, with multiple pages like a MMU
>> switched by a bank register, you need to distribute your data between the
>> bank pages, and therefore you need to fill the gaps with some value. Just
>> ORG won't work there.
>>
>> I do agree for binaries loaded from disk this would be wasteful as you
>> just
>> need rmb at the end of your code segment instead of fcb.
>>
>> But this is just one of the things that 6809 asm lacks. Other is being
>> able
>> to resolve labels and offsets in the second phase. But I kinda understand
>> why this wasn't needed in first place: 6809 can generate native
>> relocatable
>> code while z-80 must rely on code offset arithmetic to be able to emulate
>> such thing.
>>
>> But my major complain the what operators you can use to calculate
>> immediate
>> values.
>>
>> Felipe.
>>
>>
>> On Thu, Jan 31, 2013 at 12:21 PM, Steve Bjork <6809er at srbsoftware.com
>> >wrote:
>>
>>  The reason why better assemblers don't include a fill a block of memory
>>> option is its wasteful.
>>>
>>> While it make it easier to write the source code with a memory "init" at
>>> run time by loading in all that data, it waste space in the run-time file
>>> that's loaded.
>>>
>>> In the days when file space could not be wasted for 256 zeros, it was
>>> better to reserve the space in memory for the data and at run-time to
>>> clean
>>> it out with a few lines code. (It goes without saying that code running
>>> in
>>> ROM would have clear it at run-time.)
>>>
>>> Too many times I've seen code create by young programmers with megs and
>>> megs of array data fill with none thing but zeros.  Once I got a
>>> programmer
>>> to see the errors of his ways, the Game Install CD-ROM dropped from three
>>> to just one.  (The savings in production cost more than paid for the
>>> consulting fees for that project.)
>>>
>>> Yes, you can pack (zip) the file to remove most the wasted space. But why
>>> have the wasted space in the first pace?
>>>
>>> Steve
>>>
>>>
>>>
>>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>



-- 
Long live the CoCo