MAD Assembler and *=

[Atari_Ace]

In order to compile old MAC/65 listings using MADS, I've had to convert all *= to ORG. This is fine, but if I forget, it often assembles without warning and I end up with labels at the same value, e.g.

 

ORG $1000
ZP1 *= *+1
ZP2 *= *+1
LDA ZP1
LDA ZP2

 

results in no warning and ZP1=ZP2=$1000.

 

It would be great if MADs would either accept assigning to * to behave as ORG, or to generate an error or warning instead.

[Rybags]

Yep, it's an annoyance with some 6502 assemblers.

 

Allowable, things like ZP1 = * or ZP2 = *+1 to make assignments relative to current location counter.

But not allowed to make assignment to * itself.

 

Actually, IBM's mainframe System 390 assembler does the same, though you don't usually play around with ORG except in data sections or in some situations where you want to force a certain alignment.

Edited April 13, 2016 by Rybags

[mono]

org $80

var1 .ds 1

var2 .ds 2

var3 .ds 1

var4 .ds 16

...

[MaPa]

deleted

Edited April 13, 2016 by MaPa

[Atari_Ace]

org $80
var1 .ds 1
var2 .ds 2
var3 .ds 1
var4 .ds 16
...

 

Sure, but I'm starting with MAC/65 (or AMAC) input and trying to get MADS to accept it with scripted changes and still generate the same assembly output as part of a project verifying the source code for old ANALOG games (I have weird hobbies). *= => ORG is a simpler rule than *=\s+*+ => .DS and *= => ORG otherwise.

 

As another example of assembly quirks, one thing I noticed when trying to assemble Fill 'er Up II, MADS needs to be coaxed to generate linear output in some cases. In that code, you'll find

 

SHSTRT DB 0,2

SHYHLD DS 2

SHOIMG DB $88,$50,$20,$50,$88

 

If you convert the DS to .DS and the DB to .DB and assemble that you get an obx with two segments, one with the first two bytes and one with the second 5 bytes. The file in the magazine had a single segment, with two zeros for the DS 2 instead of the four bytes for a new segment prefix, saving two bytes. Maybe AMAC did that automatically, or maybe the author assembled the file and then saved the object from memory. Either way, for my purposes I wanted the linear output, so I converted DS 2 to DB 0,0 here in my source translation before invoking MADS.

 

So far I've examined about ten games and only found one significant anomaly. Bacterion has buffers LOTBL and HITBL that have been moved in the published source file. They were just after :COLR1 when the object code was assembled for publication but are at the end of the file in the source file.

[flashjazzcat]

.DS has to generate new segment to skip over uninitialised memory. That's not a peculiarity of MADS.