Jump to content
IGNORED

DASM - NEW RELEASE 2.20.11


Recommended Posts

From DASM maintainers:

 

"We just released the first update to DASM in 4 years, DASM 2.20.11! A lot of things are new about this release, including a slightly more Unix-oriented distribution (that can still be built in Windows). Several bugs have been fixed, several features have been added, see the extensive NEWS and ChangeLog files for details. We hope this release will convince everybody that DASM is alive and kicking. "

 

Visit http://sourceforge.net/projects/dasm-dillon/

Link to comment
Share on other sites

From DASM maintainers:

 

"We just released the first update to DASM in 4 years, DASM 2.20.11! A lot of things are new about this release, including a slightly more Unix-oriented distribution (that can still be built in Windows). Several bugs have been fixed, several features have been added, see the extensive NEWS and ChangeLog files for details. We hope this release will convince everybody that DASM is alive and kicking. "

 

What new features exist for 2600 programmers? Will it still (try to) produce a 4+gig binary on something like:

  org $7FF8
 byte 1,2,3,4,5
 ds $7FFC-*
 byte 1,2,3,4

Using org rather than ds might have been more convenient, except that it would put org and rorg out of sync.

 

I've been toying with the idea of making some changes to DASM, but didn't particularly want to encourage the development of code that wouldn't work on older versions. Still, if the thing is being maintained and people do want new features, it might be neat to add some:

 

-1- An option to allocate two memory buffers of a requested size; the first would hold an image of the program being built, while the second would indicate which areas of memory have been used (the free-space map would not necessarily require a second memory buffer, but that would be the easiest way to implement it). Allow .org's to go out of sequence, provided that no area of memory is written more than once (a "ds" should skip over memory without writing it, to allow for back-patching).

 

-2- A syntax to allow label names to be derived from labels values and/or numerical expressions. For example, something like:

  mac stackless_call
 mov x,#sc_count
 jmp {1}
ret_{{sc_count}} = *
sc_count .set sec_count+1
 endm

 mac sc_rets:
SC_RET_LSB:
temp .set 0
 repeat sc_count
 db <ret_{{temp}}
temp .set temp+1
 repend

SC_RET_MSB:
temp .set 0
 repeat sc_count
 db >ret_{{temp}}
temp .set temp+1
 repend

 

I've managed to kludge something similar using Roman-ish numerals in labels (forty-nine is xxxxviiii) but the listing file for even a small program is outrageously huge. Do you know any nice way to do anything like the above?

Link to comment
Share on other sites

I had no idea you were planning another release, as I would have submitted a bunch of bug reports, some that I already fixed myself in a private build.

 

There are at least three that I can think of from the top of my head.

1. LDA #-1 works in 2.20.07 but not 2.20.10

 

2. Sometimes the assembler produces several hundred bogus label mismatches in early passes but successfully assembles in later passes (I fixed it by suppressing errors until the final pass, but the code isn't very good.)

 

3. Sometimes when in the second pass, a negative branch target may differ from its location in the first such that seems to be <-128 bytes away. If DASM would just complete the pass, it would find that the branch location also moved such that it would resolve properly, but instead it triggers a fatal assembly error.

 

EDIT: Just checked, and #1 is apparently fixed, though it's unclear if #2 was (something about spurious messages in the NEWS file, so I will check to see if this bug is indeed still there.)

 

But there is no mention of #3.

Edited by batari
Link to comment
Share on other sites

Yay! But how come it is not posted here?

 

http://www.atari2600.org/DASM/

 

DASM has been moved to SourceForge and a new maintainer, Peter H. Fröhlich, has taken over the reins. Peter's put some rigour into the maintenance and methodology of DASM releases and bug fixes, and it's quite clear the tool is now in very good hands. So, the atari2600.org site is soon to disappear. With a SourceForge project, we can all have input to the fixes, there's announcement and discusion mailing lists, and bugs will be fixed much much quicker.

 

Cheers

A

Link to comment
Share on other sites

From DASM maintainers:

 

"We just released the first update to DASM in 4 years, DASM 2.20.11! A lot of things are new about this release, including a slightly more Unix-oriented distribution (that can still be built in Windows). Several bugs have been fixed, several features have been added, see the extensive NEWS and ChangeLog files for details. We hope this release will convince everybody that DASM is alive and kicking. "

 

What new features exist for 2600 programmers? Will it still (try to) produce a 4+gig binary on something like:

  org $7FF8
 byte 1,2,3,4,5
 ds $7FFC-*
 byte 1,2,3,4

Using org rather than ds might have been more convenient, except that it would put org and rorg out of sync.

 

I've been toying with the idea of making some changes to DASM, but didn't particularly want to encourage the development of code that wouldn't work on older versions. Still, if the thing is being maintained and people do want new features, it might be neat to add some:

 

-1- An option to allocate two memory buffers of a requested size; the first would hold an image of the program being built, while the second would indicate which areas of memory have been used (the free-space map would not necessarily require a second memory buffer, but that would be the easiest way to implement it). Allow .org's to go out of sequence, provided that no area of memory is written more than once (a "ds" should skip over memory without writing it, to allow for back-patching).

 

-2- A syntax to allow label names to be derived from labels values and/or numerical expressions. For example, something like:

  mac stackless_call
 mov x,#sc_count
 jmp {1}
ret_{{sc_count}} = *
sc_count .set sec_count+1
 endm

 mac sc_rets:
SC_RET_LSB:
temp .set 0
 repeat sc_count
 db <ret_{{temp}}
temp .set temp+1
 repend

SC_RET_MSB:
temp .set 0
 repeat sc_count
 db >ret_{{temp}}
temp .set temp+1
 repend

 

I've managed to kludge something similar using Roman-ish numerals in labels (forty-nine is xxxxviiii) but the listing file for even a small program is outrageously huge. Do you know any nice way to do anything like the above?

 

These sorts of comments are very welcome, and we have a mailing list attached to the SourceForge project just for this purpose. Not all DASM developers are Atari-based, and will not notice your comments here at AtariAge. I've posted a copy of your post to the list, and I would encourage everyone interested in DASM improvements to join and contribute to the [dasm-discuss] list, available through the SourceForge link mentioned earlier.

 

Cheers

A

Link to comment
Share on other sites

I wanted to confirm that the bugs #2 and #3 are NOT fixed.

 

As for #2, I fixed this in a private build, as mentioned. What I did was suppress output for all passes except the last pass. This will also fix other annoyances, such as producing output from an "echo" for every pass, instead of just the last pass, where it's actually useful.

 

As for #3, here is a simple asm that exploits this bug:

  processor 6502
test = temp
temp = $90

 org $f000
ret
 repeat $38
 sta test
 repend
 bne ret

This generates a branch out of range (-170 bytes.) If you reverse the order of the two equates, it assembles.

 

I know part of this is due to the assembler assuming "sta test" is absolute in the first pass when it's really zero page, but that's not the point, as this could feasibly happen in other ways, and this "should" assemble as is, IMO.

Edited by batari
Link to comment
Share on other sites

These sorts of comments are very welcome, and we have a mailing list attached to the SourceForge project just for this purpose. Not all DASM developers are Atari-based, and will not notice your comments here at AtariAge. I've posted a copy of your post to the list, and I would encourage everyone interested in DASM improvements to join and contribute to the [dasm-discuss] list, available through the SourceForge link mentioned earlier.

What will happen to the Atari 2600 related files like vcs.h and macro.h? Where will they be still maintained?

Link to comment
Share on other sites

This is great news,

DASM is my choice of assembler when doing Atari stuff. I recently added support for generating a NoIce Debugger support file which is very useful..... I'll make sure to have this integrated..

 

/P

Link to comment
Share on other sites

I wanted to confirm that the bugs #2 and #3 are NOT fixed.

 

Good stuff, thanks. I've copied this to the [dasm-discuss] mailing list. It would be really great if you guys could join that list, as cutting and pasting bug reports from this forum is hardly an ideal way to operate!

 

Cheers

A

Link to comment
Share on other sites

  • 5 years later...

Hi,

 

There are at least three [bugs] that I can think of from the top of my head.
[...]
2. Sometimes the assembler produces several hundred bogus label mismatches in early passes but successfully assembles in later passes (I fixed it by suppressing errors until the final pass, but the code isn't very good.)

3. Sometimes when in the second pass, a negative branch target may differ from its location in the first such that seems to be <-128 bytes away. If DASM would just complete the pass, it would find that the branch location also moved such that it would resolve properly, but instead it triggers a fatal assembly error.

 

Sorry to necro this old thread, but I've run into both bugs as well. Are there any fixes or workarounds for this? Right now, I'm unable to continue development which is very frustrating. :(

 

I've also discovered two more possible bugs, one probably related to the bugs above:

 

4. When I ran into the branch bug (3.), I wanted to see what was going on and increased verbosity (-v1 to -v4). The result was that dasm throws label mismatch errors after the first pass which were not there before with -v0! In fact I have code that assembles correctly with -v0 but will throw an error with -v1 or above. Just increasing verbosity should in no way affect assembly!

 

5. There is no lda (nn),x addressing mode on the 6502, only lda (nn),y. But instead of throwing an error, dasm silently assembles lda (nn),x into lda (nn,x)! That cost me an hour of my life until I spotted this in Stella's debugger.

 

 

I'd greatly appreciate any tip how to circumvent bug 2. and 3., or if someone could post their private build of dasm that fixes those. Otherwise I would be forced to port 3 banks of code to another assembler, which would be a lot of work. :(

 

EDIT: I'm using dasm 2.20.11 on Windows 7, by the way.

 

-Kylearan

Edited by Kylearan
Link to comment
Share on other sites

I took a shot at addressing #1 and #3. The version attached below should handle negative immediate values, and batari's test...

 

processor 6502
test = temp
temp = $90

  org $f000
ret
  repeat $38
  sta test
  repend
  bne ret
...as well as variations requiring more passes to fix the branch...

 

processor 6502
test = foo
foo  = temp
temp = $90

  org $f000
ret
  repeat $38
  sta test
  repend
  bne ret
...but compilation does (correctly) fail if the out-of-range branch doesn't eventually go away.

 

Regarding your #4 bug, are you sure when you used -v4 it didn't actually create a binary? When you use that option it prints the unused symbol table after assembly, which is also what it does after an error at lower -v settings. If not, could you share code that triggers the problem?

 

Windows, Linux, and OS X x86 32-bit binaries are in the .zip file attached below. They should work on 64-bit systems. Source is also attached, per GPL v2.

 

[REMOVED - see my later post for the updated version]

  • Like 1
Link to comment
Share on other sites

This build of dasm might be good to include with batari Basic. The build of dasm in bB actually has bug #2 fixed and #3 "kind of" fixed. I can share source so we can get a build with #2 fixed and #3 fixed right. (Note that #3 in my case "sometimes" will not find an error with the branch out of range. I should find a case where it fails so we can be sure this new build doesn't fail.)

  • Like 1
Link to comment
Share on other sites

This simple assembly should fail but it assembles on my build:

PROCESSOR 6502
 ORG $f000
        bne long
        .byte       1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
        .byte       1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
        .byte       1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
        .byte       1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
long
  lda #1
It seems only forward branches slip through the cracks, not reverse branches.
Link to comment
Share on other sites

Here is the code I changed in DASM (this is 2.20.07, not the new version), and it's all in main.c.

 

Search for "FXQ" to more easily find my changes (initials there except for the beginning where the variable declarations are.)

 

A good programmer instead of a hack like me should use dynamic memory instead of the large static arrays I used (though maybe it really doesn't matter, it's not like anyone these days will miss a megabyte of static allocation :) )

dasmmain.zip

Link to comment
Share on other sites

Regarding your #4 bug, are you sure when you used -v4 it didn't actually create a binary?

No, I'm not sure actually - after testing -v1 and -v2, I assumed higher levels will only output more stuff in addition to lower levels and would fail for the same reasons. I will test more thoroughly.

 

Windows, Linux, and OS X x86 32-bit binaries are in the .zip file attached below.

Thanks a lot! I will test them tomorrow and report back.

Link to comment
Share on other sites

I have not been involved with upkeep of DASM for years and years.

Having said that, this email recently arrived to the maintainers of dasm on sourceforge. I have no idea, due to usernames, if this is from one of the above.

I was thinking it prudent to pass this on, so that those making current modifications might like to review and adopt these changes...

 

Hi,

recently I got a report froms someone who might have started to use DASM
for his project, but he ran into a crashing bug. It had something to do
with specifying include directories on the command line.

Now I had a quick look at the current source, and I noticed the
following:

the -I option goes to v_incdir() which calls

/* TODO: I think size is calculated wrong here, too big... [phf] */
newdir = small_alloc(STRLISTSIZE + 1 + strlen(buf));

where STRLISTSIZE turns out to be

#define STRLISTSIZE 4

but the structure supposedly allocated is

typedef struct _STRLIST STRLIST;
struct _STRLIST
{
/* next string in list? [phf] */
STRLIST *next;
/* the actual string? [phf] */
char buf[4];
/*
TODO: actual code in main.c and ops.c where STRLIST gets
malloc()ed indicates that buf[4] is a hack that basically
emulates a "flexible array member" of C99 fame; should be
replaced with a properly allocated buffer! the main.c use
is probably wrong btw... [phf]
*/
};


Now that was right once upon a time when pointers were no more than 32
bits, but now it is no longer!

For this code to work, STRLISTSIZE needs to be something like
(sizeof(STRLIST) - 4).
Or, simpler, and I think it is currently promised to work, make it
char buf[] and just use sizeof(STRLIST). (n1336.pdf paragraph
6.7.2.1.16 through .22, page 103).

Easy fix. Hopefully there are no other cases where the code isn't 64 bit
clean, but I haven't checked.

HOWEVER.... I see other places where a STRLIST is allocated, and there
it is done with code like

base = checked_malloc(sizeof(STRLIST)-STRLISTSIZE+strlen(str)+1);

Here STRLISTSIZE is supposed to represent sizeof(buf) and this is at
least a sufficient size.

But it would still seem cleaner to me to use 'char buf[]' and ditch
STRLISTSIZE in this meaning. Just use sizeof(STRLIST) + the size of the
string (not forgetting the terminating \0).

The incorrect size calculation seems to occur twice, and the correct (at
least better) one also twice.

Regards,
-Olaf.

--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'
Link to comment
Share on other sites

This simple assembly should fail but it assembles on my build[...]

It correctly fails on mine. I'll look into the #2 fix merge. A meg or two is small potatoes these days, and its one less bit of memory to forget to deallocate.

 

@Andrew - Thanks for passing that on. It looks like the "#define STRLISTSIZE 4" is still in use in this version. I'll fix it up as suggested while I'm in the code.

 

@Kylearan - Not a problem. Looking forward to your report.

Link to comment
Share on other sites

Ok, the latest update is attached. Hopefully this is it for the fixes. This one has the following additions to 2.20.11...

  • #1 - a fix for negative numbers as immediate addressing values (reported by batari)
  • #2 - the suppression of errors and warnings until the last pass (reported by batari)
  • #3 - a delay for branch out-of-range errors, to allow them to come back into range in later passes. (reported by batari)
  • #4 - verbosity abort bug fixed. Previously, if verbosity was turned up and the rom shifted due to IF clauses activating, the assembly would incorrectly abort.(reported by Kylearan)
  • #5 - added error+abort for malformed indirect addressing. (reported by Kylearan)
  • #6 - fixed STRLISTSIZE as suggested. 64-bit compiles of dasm now appear to work correctly.(reported by Andrew)
As before... Windows, Linux, and OS X x86 32-bit binaries are in the .zip file attached below. They should work on 64-bit systems. Source is also attached, per GPL v2.

 

[REMOVED - see my later post for the updated version]

  • Like 3
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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