Possible assembler bug

[Franco Catrin]

Hi!

 

I'm using DASM and I don't know if I am doing something wrong or this is just a bug on the compiler.

 

I have this code in one .asm file:

 

genAutoMaskTable

ldx #0

 

On other .asm file, I just include the first file and use the names as if they were local

 

jsr genAutoMaskTable

 

When I run DASM, genAutoMaskTable points to

 

GENAUTOMASKTABLE: 0bd1

 

And the JSR from the main file is right, as you can see:

 

1C:06 20 D1 0B jsr genAutoMaskTable

 

But.... the code is not there, it is one byte after the calculated address

 

D2:0B A2 00 ldx #0

Any ideas?

Edited April 29, 2015 by Franco Catrin

[JamesD]

I'm not familiar with DASM so I don't know how much help I can be but I'll give it a shot.

So you are getting the symbol table from the first file but not the code.
How did you include or link to the first file?

Edited April 29, 2015 by JamesD

[Rybags]

I'd give Dasm, AtAsm, most others a big miss. I wasn't aware of such problems in Dasm but do know there were some nasty bugs in older releases of AtAsm that'd give similar results to what you have.

 

Probably best off using MADS - the syntax can take some getting used to but it's the premier assembler package for doing projects for the 8-bit computer.

[danwinslow]

Or ca65....

[+JAC!]

The SF version of DASM had the wrong binary for quite a long time.

Just some days ago the correct build with a lot of fixes was released.

You should make sure you have that version. See

http://www.wudsn.com/index.php/126-compilers-download-update

 

And many more improvements are coming

https://sourceforge.net/p/dasm-dillon/activity?page=0&limit=100#553bd2ea2718464513c7dd08

Edited April 29, 2015 by JAC!

[Franco Catrin]

I was wrong...

 

I was using ATASM!!

 

Today I got to dig into it and finally found the bug. I wrote a sample code and reported to the ATASM guys:

 

https://sourceforge.net/p/atasm/bugs/7/

[Rybags]

I had similar problems with earlier builds of AtAsm... destinations would sometimes be one off.

 

Updating to the latest version fixed it. Can't say I've had problems since, though I started doing new stuff with MADS a couple of years ago.

 

My advice - if you have older versions of AtAsm, get rid of them. Use a modern build otherwise it's asking for problems.

 

Also noticed in your bug report re addressing. I don't think there's a way of forcing one or the other type as with some assemblers, e.g. on the 2600 it's often desirable to force absolute to give an extra cycle delay, e.g. lda.w $40

[flashjazzcat]

I also recall encountering the same issue but understood it to be fixed in a later version. I switched to MADS partly because of Atasm's funky reordering of code segments (although it's possible to force the order you want using directives).

[+JAC!]

Just verfied the bug is also there in the lasted build (V1.08-trunk100), which will released once I got it to compile as 32-bit WIN.

Yet the problem can be solved be re-ordering the code to help the parser a little:

 

* = $600

lda levelMap+1,x

lda levelData

rts

levelData .byte 0

levelMap = levelData + $1000

yields the correct output.

Edited May 1, 2015 by JAC!