problem with DASM in OSX and DOS

[deto]

Hi,

 

i am new here and new to Atari coding.

I have some basic skills in x86 asm an z80, c, pascal and i would like to do a River Raid hack.

Downloaded the source and the latest version of DASM then tried to compile in OSX (Snow Loprard) as described in the tutorual

 

open dasm filename switches

 

it doesnt do anything

downloaded DOSBOX, the tried to do it there, with the dos version.

when i type dasm.exe

the error message: This program cannot run in dos mode.

Ths is quite WTF,isn't it?

Am i missed something?

Please help

cheers,

peter

[GroovyBee]

DASM is a command line tool. Can you elaborate on your "doesn't do anything" statement above? What steps did you follow?

[deto]

DASM is a command line tool. Can you elaborate on your "doesn't do anything" statement above? What steps did you follow?

 

more detailed:

 

- open terminal in osx

then type:

cd /Volumes/OSX2/dl/DASM/bin/Mac/OSX (where is my osx dasm located as you can see)

 

http://www.atariage.com/forums/topic/27221-session-9-6502-and-dasm-assembling-the-basics here are the basic steps i follow, so type:

 

open dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin

 

then i get this message:

 

Mac:OSX deto$ open dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin

open: invalid option -- l

Usage: open [-e] [-t] [-f] [-W] [-R] [-n] [-g] [-h] [-b <bundle identifier>] [-a <application>] [filenames] [--args arguments]

Help: Open opens files from a shell.

By default, opens each file using the default application for that file.

If the file is in the form of a URL, the file will be opened as a URL.

Options:

-a Opens with the specified application.

-b Opens with the specified application bundle identifier.

-e Opens with TextEdit.

-t Opens with default text editor.

-f Reads input from standard input and opens with TextEdit.

-R, --reveal Selects in the Finder instead of opening.

-W, --wait-apps Blocks until the used applications are closed (even if they were already running).

--args All remaining arguments are passed in argv to the application's main() function instead of opened.

-n, --new Open a new instance of the application even if one is already running.

-g, --background Does not bring the application to the foreground.

-h, --header Searches header file locations for headers matching the given filenames, and opens them.

 

 

thats all.

 

thanks in advande

[RevEng]

Instead of "open dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin" try:

 

./dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin

[deto]

Instead of "open dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin" try:

 

./dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin

 

Thanks, worked!

 

but there is a problem with it

the plane initially crashes when i start the game.

is this source code currupted maybe?

Could you please point me to a correct one?

Or is it depends on some compiler parameters?

strange...

[GroovyBee]

Could you please point me to a correct one?

Or is it depends on some compiler parameters?

strange...

 

Have you done a binary file compare of the ROM image produced by DASM against the one on AA?

 

Maybe you are seeing this :-

http://www.atariage.com/forums/topic/27221-session-9-6502-and-dasm-assembling-the-basics/page__view__findpost__p__1452335

[deto]

Could you please point me to a correct one?

Or is it depends on some compiler parameters?

strange...

 

Have you done a binary file compare of the ROM image produced by DASM against the one on AA?

 

Maybe you are seeing this :-

http://www.atariage.com/forums/topic/27221-session-9-6502-and-dasm-assembling-the-basics/page__view__findpost__p__1452335

 

yeah, just now!

 

TIA_BASE_READ_ADDRESS = $30

 

solved the problem, but gives some error message at the beginning of compiling.

And i don't understand what kind of error messages are these... would be cool if one could explain.

I want to understand the stuff i am doing. i dont like trial and error.

 

thank you for being this helpful and fast!

great community

[GroovyBee]

And i don't understand what kind of error messages are these... would be cool if one could explain.

 

We aren't mind readers . You'll have to specify the errors you are seeing.

[+Allan]

And i don't understand what kind of error messages are these... would be cool if one could explain.

 

We aren't mind readers . You'll have to specify the errors you are seeing.

No but your 7800 programming abilities are on par with mind reading.

 

Allan

[Nukey Shay]

It sounds like you are using TZ's disassembly of the game. Keep in mind that beside resetting the base read address (because some lines reference them like this -> CXPPMM-$30), you may also need to edit lines that use negative value arguments (such as -1). Some versions of Dasm has a problem with those.

 

For example, if the program is doing this:

LDA #-1

 

...change it to this:

LDA #<-1

 

 

The problem arises because -1 can be misinterpreted as a two-byte value instead of only one. The immediate addressing mode (#) expects that the argument is only a single byte. Sticking in the "least-significant byte" directive (<) solves the problem.

 

#(Negative one) misinterpreted to be #$FFFF becomes #$FF...the MSB ("most-significant byte") portion is thrown away in assembly.

Edited October 30, 2010 by Nukey Shay

[deto]

And i don't understand what kind of error messages are these... would be cool if one could explain.

 

We aren't mind readers . You'll have to specify the errors you are seeing.

 

The error messages are already copypasted into that thread you linked.

[deto]

It sounds like you are using TZ's disassembly of the game. Keep in mind that beside resetting the base read address (because some lines reference them like this -> CXPPMM-$30), you may also need to edit lines that use negative value arguments (such as -1). Some versions of Dasm has a problem with those.

 

For example, if the program is doing this:

LDA #-1

 

...change it to this:

LDA #<-1

 

 

The problem arises because -1 can be misinterpreted as a two-byte value instead of only one. The immediate addressing mode (#) expects that the argument is only a single byte. Sticking in the "least-significant byte" directive (<) solves the problem.

 

#(Negative one) misinterpreted to be #$FFFF becomes #$FF...the MSB ("most-significant byte") portion is thrown away in assembly.

 

Can't thank your enough guys!

very much appreciate this behavior. not like other forums post like RTFM or "google it".

[GroovyBee]

No but your 7800 programming abilities are on par with mind reading.

 

Thanks for the compliment. I don't think that the 7800 was pushed very hard back in the day. Its good to see the old girl fly .