[Coco] Kinda disappointed with 6809 assemblers
Luis Antoniosi (CoCoDemus)
retrocanada76 at gmail.com
Thu Jan 31 12:37:49 EST 2013
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
>
>
> On 1/30/2013 8:03 PM, Luis Antoniosi (CoCoDemus) wrote:
>
>> Hi,
>>
>> Been using different assemblers and for me they all seem to lack very
>> basic
>> features.
>>
>> for example, I want to create a simple array of 256 zeroes ? Then I need
>> to
>> do this ?
>>
>> array fcb 0,0,0,0,0,0,0...,0 ???
>>
>> what if my array was sized set by the size of the code ? impossible.
>>
>> Maybe I'm spoiled by Z-80 assemblers. For example in z-80 it would be:
>>
>> array: db 0,256
>>
>> simple as that. Another good example of what is impossible with 6809 asms:
>>
>> I have a game using some 8k memory banks mapping, and I need to include a
>> binary file into a determined bank since it's a ROM file, that would be:
>>
>> org 16384
>> WORLD11BIN: incbin "data\WORLD11.MGL",0x108,**0x1000
>> ds BANK_SIZE - ($$ % 8192),0ffh
>>
>> not only the code above would include my binary file WORLD11.MGL into the
>> 3
>> bank as it would fill the rest of the remaining bytes (in the bank) with
>> 0xFF. And look the include bin, it has an offset and a size, so I don't
>> need to include the entire file.
>>
>> Other nightmare: math operations in constants. Look that:
>>
>> I want to make:
>>
>> KEY_LEFT equ $0503
>>
>> then in my code I would like this:
>>
>> lda (KEY_RIGHT >> 8),x
>> bita #($01 << (KEY_RIGHT & $00ff))
>>
>> but I can only use very basic math operations on it and shifts and ands
>> are
>> out.
>>
>> BTW the code above core dumps with lwasm, also a single cmpx with no
>> parameters crashes too.
>>
>> unhappy programmer :(
>>
>>
>
> --
> 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
More information about the Coco
mailing list