Jump to content

Recommended Posts

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 by Franco Catrin

Share this post


Link to post
Share on other sites

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 by JamesD

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by JAC!
  • Like 3

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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 by JAC!
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...