[Coco] Kinda disappointed with 6809 assemblers

[William Astle]

On 13-01-31 06:30 PM, Luis Antoniosi (CoCoDemus) wrote:
> lwasm seems to not accept * as current program counter. It gives me bad
> operand (*)

You'll have to show the precise code you used. * works just fine in my 
tests.

>
> :/
>
> 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>
>>
>
>
>