Time to abandon DASM

[Dr. Kylstein]

I have put together a basic example for building a DPC+ rom with the cc65 tools. It's a mash-up of GroovyBee's demo above and Spiceware's DPC+ demo. It includes conversions of all the headers. The resulting rom draws color bars on the screen (as in GroovyBee's demo) by doing round-robin accross the code banks. I'm quite new to Atari programming, but hopefully this will be useful to someone.

 

Edit: The Makefile is for GNU Make, it uses the Unix command 'cat' to combine the arm and 6502 pieces.

 

Edit2: I think I should mention that this is not a superset of any of the existing examples, it lacks some features.

dpcplus_ca65.zip

Edited January 7, 2012 by Dr. Kylstein

[GroovyBee]

If you need to include binary files just use the .incbin directive. Saves having any windows/linux issues with the makefile.

[Dr. Kylstein]

Ok, here's one that builds in one step and includes a batch file. I knew about incbin but hadn't thought of using it this way.

dpcplus_ca65.zip

Edited January 7, 2012 by Dr. Kylstein

[Dr. Kylstein]

There were some mistakes in the converted macro.inc file. Here's one more update.

dpcplus_ca65.zip

[+SvOlli]

There were some mistakes in the converted macro.inc file. Here's one more update.

I guess, we need one more update here, as the archives include bankswitch_program.o instead of bankswitch_program.s, as needed by the Makefile.

 

Anyway it looks like a very nice start learning to understand DPC+, thanks.

[Dr. Kylstein]

Ok, here it is with the right bankswitch program file. I should warn you that I haven't managed to get any non-trivial programs working with this. I think there may be a problem accessing the data fetch registers.

dpcplus_ca65.zip

[+SvOlli]

I just figured out another cause to abandon DASM: when compiled for the x86_64 architecture, it breaks during runtime stating errors like:

main.asm (64): error: Unknown Mnemonic '<some binary data>'.

Edit: this happened when invoking a macro (which was included from macro.h).

Edited May 20, 2012 by SvOlli

[+Propane13]

I just installed this, and want to try it. I've done some simple examples, but before I commit, I want to verify that I can re-assemble something that was dis-assembled byte-for-byte. So, with that note, does anyone have a 2K or 4K game that's disassembled into a format where I can try to assemble it back again?

 

Is it easy enough to convert from a dasm disassembly? Such a thing might help get the ball rolling a little further.

 

-John

[+Propane13]

Ok, I've converted "How to Draw a Playfield" -- yes, that old thing, over.

 

I like this assembler, although I have a few gripes.

 

1) We need a retooled vcs.h. I can use .byte declarations, but I can't seem to find the equivalent to .ds.

 

2) The atari2600.cfg file that I found online has some problems. It raises 3 warnings:

ld65: Warning: Duplicate external identifier: `__TIA_SIZE__'

ld65: Warning: Duplicate external identifier: `__RIOT_SIZE__'

(the third warning was that during the linking stage, the -o should be before any other flags, so I moved it)

I think we need a better one.

 

3) I grabbed some code from an old thread:

http://www.atariage....variable-0-150/

Unfortunately, this compiler has no idea how to handle "sta.wx HMP0".

Does anyone know the equivalent?

 

-John

[+SpiceWare]

.wx is a forced addressing mode. From dasm's text file:

 

[label] XXX[.force] operand

       XXX is some mnemonic, not necessarily three characters long.
       The .FORCE optional extension is used to force specific
       addressing modes (see below).

...

EXTENSIONS:

   FORCE extensions are used to force an addressing mode.  In some cases,
   you can optimize the assembly to take fewer passes by telling it the
   addressing mode.  Force extensions are also used with DS,DC, and DV
   to determine the element size.  NOT ALL EXTENSIONS APPLY TO ALL
   PROCESSORS!

   example:    lda.z   charlie

   i   -implied
   ind -indirect word
   0   -implied
   0x  -implied indexing (0,x)
   0y  -implied indexing (0,y)
   b   -byte address
   bx  -byte address indexed x
   by  -byte address indexed y
   w   -word address
   wx  -word address indexed x
   wy  -word address indexed y
   l   -longword (4 bytes) (DS/DC/DV)
   r   -relative
   u   -uninitialized (SEG)

   First character equivalent substitutions:

   b z d        (byte, zeropage, direct)
   w e a        (word, extended, absolute)

 

It's often used to force a zero page update to use word addressing instead. It'll take 1 additional cycle to process, which can be quite handy during the Kernel to force a TIA update to occur on a specific cycle.

 

Googling turns up that sta.wx HMP0 would be done using sta a:HMP0,x

 

A post here at AtariAge mentions using z: to force zero page addressing.

 

I'm not set up to try these, so I hope it helps!

Edited November 21, 2012 by SpiceWare

[+Propane13]

It works! I didn't know what to google for, so I came up with some empty nets.

 

Thanks man.

 

-John

[Omegamatrix]

1) We need a retooled vcs.h. I can use .byte declarations, but I can't seem to find the equivalent to .ds.

 

There should be something that works. Maybe just try "DS". Looking at the source of Crystal Castles, they did this to declare there ram variables:

 

 

 

;*****************************************************************
;
; RAM PAGE ZERO DEFINITIONS
;
;*****************************************************************
;
;
.=80
SCREEN: ;# OF CURRENT KERNEL IN USE
GAME: .=.+1 ;ATTRACT MODE OR GAME NUMBER
;D7 = GAME/ATTRACT	 0/1
;D6 = GAME OVER/SELECT 0/1
;D5 = /DELAY STATE	 /1
;D4-D3 = SCREEN NUMBER
;D2-D0 = GAME NUMBER
BLSTAT: .=.+1 ;STATUS FOR BUTTON, STICK, BALL AND MICKEY (SCREEN 0)
;D7=BUTTON,D6=BUTTON LAST FRAME
;D5=RESET SWITCH LAST FRAME
;D4=SELECT SWITCH LAST FRAME
;D3-D0=TIME TO NEXT ROLL SELECT
;
SEEDL: .=.+1 ;RANDOM SEED
SEEDH: .=.+1 ;RANDOM SEED
;
;
FRMCTR: .=.+2
SCORE: .=.+3 ;6 DIGIT SCORE IN BCD
;
DOTCNT: .=.+2 ;NUMBER OF DOTS ON SCREEN
ELVATR: .=.+1 ;ELEVATOR STATUS
;D7-D4=ELEVATOR NUMBER ON SCREEN
;D2-D0=STATUS OF THIS ELEVATOR
; 0=RESET TO NEW ELV
; 1=WAIT AT BOTTOM
; 2=MOVE UP
ELVOCC: .=.+1 ;P1 INDEX OF OCCUPANT
ELVCNT: .=.+1 ;COUNTER FOR ELEVATOR MOVEMENT
;
MAZE: .=.+1 ;MAZE NUMBER
WAVE: .=.+1 ;WAVE NUMBER
WAVST: .=.+1 ;STATUS OF WAVE
WAVTMR: .=.+1 ;TIMER FOR WAVE
BEECNT: .=.+1 ;NUMBER OF TIMES BEES HAVE DESCENDED
HATNDX: .=.+1 ;INDEX INTO HAT BOUNCE TABLE
GSPEED: .=.+1 ;OVERALL GAME SPEED
BNTLIV: .=.+1 ;LIVES OF BENTLEY
;DUMBOS TIMERS
JMPNDX: .=.+1 ;INDEX INTO JUMP TABLE (AIR)
P0XTMR: .=.+1 ;TIMER FOR HORIZONTAL DUMBO UPDATE
P0YTMR: .=.+1 ;TIMER FOR VERTICAL DUMBO UPDATE
FSTTMR: .=.+1 ;TIMER FOR MOTION UPDATE (FAST)
SLWTMR: .=.+1 ;TIMER FOR MOTION UPDATE (SLOW)
CNT3: .=.+1 ;3 COUNTER
CNT5: .=.+1 ;5 COUNTER
CNT7: .=.+1 ;7 COUNTER

... and so on

 

 

I'm pretty sure the forum software will chew the above code entry! It should be nicely spaced like this:

[+batari]

I think the best solution is not to port over the code. The DASM code base is big.

 

A better solution, IMO, is to write a syntax converter. I think the basic syntax should be easy to convert. The macros and other things may be harder but possible.

[+SvOlli]

I just installed this, and want to try it. I've done some simple examples, but before I commit, I want to verify that I can re-assemble something that was dis-assembled byte-for-byte. So, with that note, does anyone have a 2K or 4K game that's disassembled into a format where I can try to assemble it back again?

 

Is it easy enough to convert from a dasm disassembly? Such a thing might help get the ball rolling a little further.

With this approach you throw away the biggest advantage of as65 against dasm: the option to split your sourcecode into several files, and get them compiled and linked together as it fits the project. You sacrifice a bit of direct control, via the source code. This control can be reclaimed, at least in part, during the linking process. The sacrifice of control makes it easier to reuse some of your code.

 

1) We need a retooled vcs.h. I can use .byte declarations, but I can't seem to find the equivalent to .ds.

Try ".res"

 

Right now, I'm hacking on a setup that is intended for a multibank cartridge where each separate bank can be assembled either using dasm or as65.

 

I attached the templates I use for creating new projects right now. It includes the vcs.inc file I use for VCS development. It lacks all the macros and is just a description of the registers, but got my code working. The templates also shows a simple split of the source code. To get it run you'll need "make" as used on Unix/Linux systems.

 

Hope this helps.

 

Greetings,

SvOlli

[supercat]

Does the linker have any means of issuing warnings if specified branches cross page boundaries? When coding in DASM, I rely upon "safe-branch" macros which will squawk if the target isn't in the proper page. If I get a squawk when I assemble my code, a little rearrangement will usually fix it. Unless link sections are aligned on 256-byte boundaries, I'm not sure how readily one would be able to detect such cross-page faults.

[GroovyBee]

Does the linker have any means of issuing warnings if specified branches cross page boundaries?

 

Not that I know of between linked object files. You can still take the DASM "huge file" approach with CC65 because the assembler supports the .include directive.

[supercat]

Not that I know of between linked object files. You can still take the DASM "huge file" approach with CC65 because the assembler supports the .include directive.

 

For any reasonable-sized Atari project, the time required to assemble the whole thing is going to be pretty negligible. Using macros to arrange memory in DASM can be a bit tricky, but it can do some pretty neat tricks. There are some things that could be improved with DASM, but if the main objection is the lack of separate-link support, I'm not sure I see that as a problem.

[supercat]

DASM could simply just need an overhaul/update.

 

I would think so. There are a relatively small number of features I've found myself wanting that could probably be added fairly easily. Given that 6502 code for the 2600 often has "unusual" address restrictions (e.g. a requirement that some branches and data structures must not cross page boundaries often implies that certain addresses may only be relocated to certain addresses within a page) I don't think a separate link is as helpful with 2600 code as with some other platforms.

 

The things I would add would probably be the following:

 

• A mode in which DASM allocates buffers for specific addressing ranges, sends output to those buffers, and then outputs them at the end. This would facilitate use of constructs which allocate data non-sequentially.
  
• Better control over the number of passes, and the requirement that labels be resolved by a certain pass.
  
• Built-in opcodes for sbne, sbeq, sbcs, sbcs, etc. (which perform like bne, beq, etc. except that they will generate a diagnostic if, on the last pass of assembly, they cross a page boundary. This can be done with macros (I often define macros for that purpose), but using macros clutters the listing file.
  
• New .org-style directives which would set the logical or physical output address while keeping the same displacement between those two addresses
  
• Bounds checking on the ds directive.
  

When I first started looking at Atari programming in 1994, I would have found DASM to be a massive improvement over any of the alternatives I could find at the time; I started Strat-O-Gems with an assembler that was a big quirky, and nowhere near as nice as DASM. I'm not sure what improvements are needed which couldn't be accomplished with a few tweaks to DASM. I'd been load to change DASM and make any code that used new features be incompatible with what everyone else was using, but if people are going to migrate to something else I think it might be better that it be a tweaked DASM than something completely different.

[shazz]

Hi guys, this topic looks dead.... did the community switch to ca65 or not at the end ?

 

Whatever, I saw in this topic some examples for bankswitching, do we also have a simple template for classic 4K roms ?

Dasm is so easy to start with that now it is hard to change

[Thomas Jentzsch]

I suppose most people (like me) are still working with DASM.

[Omegamatrix]

I suppose most people (like me) are still working with DASM.

 

Yep, and it's never given me enough problems to switch over.

[johnnystarr]

I have used ca65, but I prefer asm6. Of course, I was doing NES development with it. I have been doing '2600 stuff with DASM but only because the tuts out there use it.

[shazz]

ok. Btw with SvOlli's help I made some templates (thanks !) and I won't say it is better than DASM but it offers some cool features... to split code segments per file is nice and the source code is easier to read (or seems to) when it starts to be long.

[+SpiceWare]

it offers some cool features... to split code segments per file is nice and the source code is easier to read (or seems to) when it starts to be long.

 

Is that different than using DASM's include pseudop? This extract is from the manual.

 

PSEUDOPS:

   INCLUDE     "name"

       Include another assembly file.

 

Besides that, I also use INCBIN to include binary files. I'm using that in my current project to include level data that's been compressed with a C program.

[shazz]

SvOlli would explain it far better that what I will do and I hope he will

But basically, as far as I understand, that's more like a C compiler, every segment file is "assembled" alone (so there is a global file if it references variables from another segment/file that is 'included' in each file) and then the linker links all the .o (assembled objects) into one binary image according to the linker definition (segments, alignments, optional/mandatory...).

 

So from a reader poitn of view, you're right, DASM includes help to split ther source code. From an assembling point of view, that's different.

That's a little "non sense" for VCS programs as it is lightning fast to assemble on a 2013 PC and ther eis not megabytes of code/data to assemble, so the time saved to assemble is probably not a good argument (as you only recompiled changed segments).

 

So before telling too many mistakes, I'll let SvOlli explain why this is nice, and probably bankswitching is a nother argument But let's say it is more "modern" somewhat (It's like comparing in the Atari ST world Devpac vs Assemble maybe)

 

After all, both are quite ok.... use the one your prefer, I like both