Jump to content

Photo

Session 9: 6502 and DASM - Assembling the Basics


30 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,583 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun May 25, 2003 4:00 AM

This session we're going to have a look at the assembler "DASM", what it does, how it does it, why it does it, and how to get it to do it :)

The job of an assembler is to convert our source code into a binary image which can be run by the 6502. This conversion process ultimately replaces the mnemonics (the words representing the 6502 instructions we use when writing in assembler) and the symbols (the various names we use for things, such as labels to which we can branch, and various other things like the names of TIA registers, etc) with numerical values.

So ultimately, all the assembler needs to do is figure out a numerical value for all the things which become part of the binary - and place that value in the appropriate place in the binary.

We've already had a brief introduction to a 6502 instruction - the one called "nop". This is the no-operation instruction which simply takes 2 cycles to execute. Whenever we enter "nop" into our source code, the assembler recognises this as a 6502 instruction and inserts into the binary the value $EA. This shows that there can be a simple 1:1 relationship between source-code and the binary.

"nop" is a single-byte instruction - all it requires is the opcode, and the 6502 will happily execute it. Some instructions require additonal "parameters" - the "operands". The 6502 microprocessor can use an additional 1 or 2 bytes of operand data for some instructions, so the total number of bytes for a 6502 "instruction" can be 1, 2 or 3.

DASM is the assembler used by most (if not all) modern-day '2600 programmers. It is a multi-platform assembler written in 1988 by Matt Dillon (you should all find his email address and send him a "thank-you" sometime). It's a great tool.

DASM isn't just capable of assembling 6502 (and variant) code - it also has inbuilt capability to assemble code for several other microprocessors. Consequently, one of the very first things that it is necessary to do in our source code is tell DASM what processor the source code is written for.


     processor 6502


This should be just about the first line in any '2600 program you write. If you don't include it, DASM will probably get confused and spit out errors. That's simply because it is trying to assemble your code as if it were written for another processor.

We've just seen how mnemonics (the standard names for instructions) are converted into numerical values by the assembler. Another job the assembler does is convert labels and symbols into values. We've already encountered both of these in our previous sessions, but you may not be familiar with their names.

Whenever DASM is doing its job assembling, it keeps a list of all the "words" it encounters in a file in an internal structure called a symbol table. Think of a symbol as a name for something. Remember the "sta WSYNC" instruction we used to halt the 6502 and wait for the scanline to be rendered? The "sta" is the instruction, and "WSYNC" is a symbol. When it first encounters this symbol, DASM doesn't know much about it, other than what it's called (ie: "WSYNC"). What DASM needs to do is work out what the *value* of that symbol is, so that it can insert that value into the binary file.

When it's assembling, DASM puts all the symbols it finds into its symbol table - and associated with each of these is a value. If it doesn't "know" the value, that's OK - DASM will keep assembling the rest of the file quite happily. At some point, something in the code might tell DASM what the value for a symbol actually IS - in which case DASM will put that value in its symbol table alongside the symbol. So whenever that symbol is used anywhere, DASM now knows its correct value to put into the binary file.

In fact, it is absolutely necessary for all symbols which go into the binary file to be given values at some point. DASM can't guess values - it's up to you, the programmer, to make sure this happens. A symbol doesn't have to be given a value at any PARTICULAR point in the code, but it does have to be given a value somewhere in the code. DASM will make multiple "passes" - basically going through the code from beginning to end again and again until it manages to resolve all the symbols to correct values.

We've already seen in some sample code how "sta WSYNC" appears in our binary file as the bytes $85 $02. The first byte $85 is the "sta" instruction (one variant of many - but let's keep it simple for now) and it is followed by a single byte giving the address of the location into which the byte in the "A" register is to be stored. We can see this address is location 2 in memory. Somehow, DASM has figured out from the code that the symbol WSYNC has a value of 2, and when it creates the binary file it replaces all occurences of the symbol with the numeric value 2.

How did it get the value 2? Remember, WSYNC is one of the TIA registers. It appears to the 6502 as a memory location, as the TIA registers are "mapped" into locations 0 - $7F. The file "vcs.h" defines (in a roundabout way) the values and names (symbols) for all of the TIA registers. By including the file "vcs.h" as a part of the assembly for any source file, we automatically tell DASM the correct numeric value for all of the TIA register "names".

That's why, at the top of most files, just after the processor statement, we see...


     include "vcs.h"


You don't really need to know much about vcs.h at this stage - but be aware that a "standardised" version of this file is distributed with the DASM assembler as the '2600 support files package. I would advise you to always use the latest and greatest version of this file. Standards help us all.

So now we know basically what DASM does with symbols - it keeps an internal list of symbols - and their values, if known. DASM will keep going through the code and "resolving" the symbols into numeric values, until it is complete (or it couldn't find ANYTHING to resolve, in which case it gives an error). Once all symbols have been resolved, your code has been completely processed by the assembler, and it creates the binary image/file for you - and assembly is complete.

To summarise: DASM converts source-code consisting of instructions (mnemonics) and symbols into a binary form which can be run by the 6502. The assembler converts mnemonics into opcodes (numbers), and symbols into numbers which it calculates the value of during the assembly process.

DASM is a command-line program - that is, it runs under DOS (or whatever platform you happen to choose, provided you have a runnable version for that platform). DASM is provided with full source-code (it's written in C) so as long as you have a C-compiler handy, you can port it to just about any platform under the sun.

It does come with a manual - and it's always a good idea to familiarise yourself with its capabilities. In the interests of getting you up and running quickly, so you can actually assemble the sample kernel posted a session or two ago, here's what you need to type on the command-line...


dasm kernel.asm -lkernel.txt -f3 -v5 -okernel.bin


This is assuming that the file to assemble is named "kernel.asm" (.asm is a standard prefix for assembler files, but some prefer to use .s - you can use whatever you want, really, but I always use .asm). Anything prefixed with a minus-sign ("-") is a "switch" - which tells DASM something about what it is required to do. The -l switch we discussed very briefly, and that tells DASM to create a listing file - in this case, it will write a listing to the file "kernel.txt". The -o switch tells DASM what file to use for the output binary - in this case, the binary will be written to "kernel.bin". That file can be loaded into an emulator, or burned on an EPROM - it is the ROM file, in other words.

The other switches "-f3" and "-v5" control some internals of DASM - and for now just assume you need these whenever you assemble with DASM. Remember, if you're curious you can always read the manual!

If all goes well, DASM will output something like this...


DASM V2.20.05, Macro Assembler (C)1988-2003

START OF PASS: 1

----------------------------------------------------------------------

SEGMENT NAME                 INIT PC  INIT RPC FINAL PC FINAL RPC

                             f000                            f000                           

RIOT                     [u] 0280                            0280                           

TIA_REGISTERS_READ       [u] 0000                            0000                           

TIA_REGISTERS_WRITE      [u] 0000                            0000                           

INITIAL CODE SEGMENT         0000 ????                       0000 ????                      

----------------------------------------------------------------------

1 references to unknown symbols.

0 events requiring another assembler pass.

--- Symbol List (sorted by symbol)

AUDC0                    0015                  

AUDC1                    0016                  

AUDF0                    0017                  

AUDF1                    0018                  

AUDV0                    0019                  

AUDV1                    001a                  

COLUBK                   0009              (R )

COLUP0                   0006                  

COLUP1                   0007                  

COLUPF                   0008                  

CTRLPF                   000a                  

CXBLPF                   0006                  

CXCLR                    002c                  

CXM0FB                   0004                  

CXM0P                    0000                  

CXM1FB                   0005                  

CXM1P                    0001                  

CXP0FB                   0002                  

CXP1FB                   0003                  

CXPPMM                   0007                  

ENABL                    001f                  

ENAM0                    001d                  

ENAM1                    001e                  

GRP0                     001b                  

GRP1                     001c                  

HMBL                     0024                  

HMCLR                    002b                  

HMM0                     0022                  

HMM1                     0023                  

HMOVE                    002a                  

HMP0                     0020                  

HMP1                     0021                  

INPT0                    0008                  

INPT1                    0009                  

INPT2                    000a                  

INPT3                    000b                  

INPT4                    000c                  

INPT5                    000d                  

INTIM                    0284                  

NUSIZ0                   0004                  

NUSIZ1                   0005                  

Overscan                 f02c              (R )

PF0                      000d                  

PF1                      000e                  

PF2                      000f                  

Picture                  f01d              (R )

REFP0                    000b                  

REFP1                    000c                  

RESBL                    0014                  

Reset                    f000              (R )

RESM0                    0012                  

RESM1                    0013                  

RESMP0                   0028                  

RESMP1                   0029                  

RESP0                    0010                  

RESP1                    0011                  

RSYNC                    0003                  

StartOfFrame             f000              (R )

SWACNT                   0281                  

SWBCNT                   0283                  

SWCHA                    0280                  

SWCHB                    0282                  

T1024T                   0297                  

TIA_BASE_ADDRESS         0000              (R )

TIM1T                    0294                  

TIM64T                   0296                  

TIM8T                    0295                  

TIMINT                   0285                  

VBLANK                   0001              (R )

VDELBL                   0027                  

VDELP0                   0025                  

VDELP1                   0026                  

VerticalBlank            f014              (R )

VSYNC                    0000              (R )

WSYNC                    0002              (R )

--- End of Symbol List.

Complete.



Here we can actually SEE the symbol table, and the numeric values that DASM has assigned to the symbols. If you look at the listing file, wherever any of these symbols is used, you will see the corresponding number in the symbol table has been inserted into the binary.

There are lots of symbols there, as the vcs.h file defines just about everything you'll ever need to do with the TIA. The symbols which are actually USED in your code are marked with a (R ) - indicating "referenced".

Now you should be able to go and assemble the sample kernel I provided earlier. Don't be afraid to have a play with things, and see what happens! Experimenting is a big part of learning.

Soon we'll start playing with some TIA registers and seeing what happens to our screen when we do that! For now, though, make sure you are able to assemble and run the first kernel. If you have any problems, ask for assistance and I'm sure somebody will leap to your aid.

#2 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Sun May 25, 2003 11:39 PM

What does the sample kernel include the Macro.H file?

#3 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,583 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun May 25, 2003 11:47 PM

What does the sample kernel include the Macro.H file?


By default I include "vcs.h" and "macro.h" files in all source code. These are standardised files for '2600 development, and distributed as official DASM '2600 support files.

MACROs are a sort of text-processing language supported by DASM. In the same way that the REPEAT keyword allowed us to repeat blocks of code automatically, MACROs allow us to package common functionality into a single keyword and have the assembler insert (and tailor) code automatically.

There's nothing in the macro.h file we use, yet... but it is good practise to include it - as it has some useful content already, and will have more added from time to time.

As a teaser, consider the SLEEP macro... remember how we wanted to delay 76 cycles for each scanline, and we used the "sta WSYNC" capability of the TIA to halt the 6502 till the start of the next scanline? Or how we used NOP to waste exactly 2 cycles. Use the sleep macro to delay for any number of cycles you want... eg:

SLEEP 25 ; waste 25 cycles.

The SLEEP macro is defined in macro.h, if you want to see how it does it.

Cheers
A

#4 JBones OFFLINE  

JBones

    Combat Commando

  • 1 posts
  • Location:NJ

Posted Sun Jun 1, 2003 3:08 PM

I can find distributions of DASM that include VCS.H, but not MACRO.H. Can you please post MACRO.H? Thanks.

-JB

#5 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,583 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun Jun 1, 2003 3:57 PM

I can find distributions of DASM that include VCS.H, but not MACRO.H. Can you please post MACRO.H? Thanks.

-JB


http://sourceforge.n...ts/dasm-dillon/

#6 chadtower OFFLINE  

chadtower

    Stargunner

  • 1,129 posts

Posted Wed Sep 3, 2003 12:33 PM

Dude this ROCKS! It's always been a lifelong dream of mine to make 2600 games... and I just compiled my first 2600 kernel! Granted, it's not my code, it's Andrew's... but it's PRETTY! YEAH!

:lust:

#7 kisrael OFFLINE  

kisrael

    HMBL 2600 coder

  • 3,970 posts
  • Location:Boston Burbs, MA

Posted Fri Sep 5, 2003 2:16 PM

Hey Andrew,
(Hope you don't mind all my late posts...this is a great refresher...my knowledge was getting a little sloppy)

I know way back when there were a few flavors of vcs.h floating around, which is why the current standardization from the homepage of DASM itself is a good thing. Is there ever going to be any move to add in more definitions to it? Like all those numberic constants listed in teh Stella Programmer's Guide...I guess there will always be less standardization for that,because SPG didn't provide convenient 'canonical mnemonics' for most of them. And maybe for backward compatability you don't want to mess with VCS.H itself...but maybe it would make sense to have a VCSCONST.H, distributed along with macro.h and vcs.h?

Also, macro.h asks people not to distribute a modified version which makes a ton of sense...but vcs.h asks not to be distributed at all! Why is that?

#8 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,583 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sat Sep 6, 2003 5:46 AM

I know way back when there were a few flavors of vcs.h floating around, which is why the current standardization from the homepage of DASM itself is a good thing.  Is there ever going to be any move to add in more definitions to it?  Like all those numberic constants listed in teh Stella Programmer's Guide...I guess there will always be less standardization for that,because SPG didn't provide convenient 'canonical mnemonics' for most of them.  And maybe for backward compatability you don't want to mess with VCS.H itself...but maybe it would make sense to have a VCSCONST.H, distributed along with macro.h and vcs.h?

Also, macro.h asks people not to distribute a modified version which makes a ton of sense...but vcs.h asks not to be distributed <i>at all</i>! Why is that?



No particular reason. Since it's an official file, it makes sense for everyone who wants a copy to get it from the official source. If we get people used to getting that file from the one spot, it will reduce the number of versions hanging about.

There may be more additions of constants - feel free to propose some. They'll either be included in one of the existing files, or a new file will be added, as you suggest. Depends how universally useful the constants are.

There's not particular reason for the differences in distribution between the files. Just happened that way. My preference would be for everyone to always collect the files from their official source, and not redistribute them at all.

Cheers
A

#9 kisrael OFFLINE  

kisrael

    HMBL 2600 coder

  • 3,970 posts
  • Location:Boston Burbs, MA

Posted Sat Sep 6, 2003 7:36 AM

There may be more additions of constants - feel free to propose some.  They'll either be included in one of the existing files, or a new file will be added, as you suggest.  Depends how universally useful the constants are.


I thought some of the old stuff in the Dig, back when everyone was effectively cutting and pasting a VCS.H at the top had some, but I thought Eckhard's movable 48 pixel sprite had some for joystick left and right, but instead he's doing some clever LSRing.

There's not particular reason for the differences in distribution between the files.  Just happened that way.  My preference would be for everyone to always collect the files from their official source, and not redistribute them at all.

Well, there would be two possible reasons for me to want to distribute the two files on my joustpong site, but neither seem to apply
1. if the DASM URL wasn't stable
2. if VCS.H was likely to be modified in a way that wasn't strictly backwards compatible

It doesn't seem like either are going to happen (though the idea of the second is why it would be good to put any changes into a new file...wouldn't it break if we defined a constant name that somebody else used for some other purpose?) and I'm not mirroring DASM itself, so I guess I might as well just have a link to the zip file or something.

#10 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 8:16 AM

Hi,

I started yesterday to hack Atari 2600 games: I'm planning to add a level counter (number of passed/exploded bridges) to River Raid.

Thomas Jentzsch sent me his River Raid ASM source code (great job isn't it ?).
I recompiled it with dasm. Then I tested it with Stella and it started correctly: I can start a party by pressing reset or choose the number of players, etc.
But at the beginning of the game, when I press a button to move or the fire one the plane explodes immediately !
I think something goes wrong during the compilation, but I don't know what...

But the most important issue could be this: the only one version of dasm that succeed in compiling your source code is dasm 2.12.04 for Windows Console (i.e. for win32, and not for msdos).
Because I don't own a Windows license, I used it with Wine (Windows API emulator) to launch dasm under Linux, that's how I compiled the code from Thomas.
I tested about 5 or 6 different versions of dasm, but this one is the only one who reached the end of the compilation process with a kind of "success".

It's so sad because I already started to test some simple hacks within the code, but I can really test it...!
It just want to get it working good !

Also, note that with Linux versions of dasm (from http://www.atari2600.org/DASM/), I got the following errors:

$ dasm.linux-i386-elf-static RiverRaid.asm -f3 -otest.bin
	DASM V2.20.09, Macro Assembler (C)1988-2003
	Warning: Unable to open 'vcs.h'
	RiverRaid.asm (1265): error: Value in 'and #~PATROL_FLAG' must be <$100.
	RiverRaid.asm (1316): error: Value in 'and #~PF_COLLIDE_FLAG' must be <$100.
	RiverRaid.asm (1512): error: Value in 'lda #-1' must be <$100.
	RiverRaid.asm (2020): error: Value in 'lda #-1' must be <$100.
	Unrecoverable error(s) in pass, aborting assembly!
	Complete.
Does any one have an idea about these issues ?
Does anyone use dasm under a Linux PC and compile games with success ?

Thanks !
Nicolas.

#11 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Fri Jan 25, 2008 8:50 AM

Also, note that with Linux versions of dasm (from http://www.atari2600.org/DASM/), I got the following errors:

$ dasm.linux-i386-elf-static RiverRaid.asm -f3 -otest.bin
	DASM V2.20.09, Macro Assembler (C)1988-2003
	Warning: Unable to open 'vcs.h'
	RiverRaid.asm (1265): error: Value in 'and #~PATROL_FLAG' must be <$100.
	RiverRaid.asm (1316): error: Value in 'and #~PF_COLLIDE_FLAG' must be <$100.
	RiverRaid.asm (1512): error: Value in 'lda #-1' must be <$100.
	RiverRaid.asm (2020): error: Value in 'lda #-1' must be <$100.
	Unrecoverable error(s) in pass, aborting assembly!
	Complete.
Does any one have an idea about these issues ?
Does anyone use dasm under a Linux PC and compile games with success ?


Unable to open'vcs.h': I don't think this is a bug. dasm just can't find vcs.h, which is needed by your source code. Search the zip archives on the DASM website, it must be there somewhere. Then the simplest way to solve this is to put vcs.h in the same directory where RiverRaid.asm resides.

About the errors:
This is a problem with a typedef that got accidentally changed from signed to unsigned but never fixed. Use a previous version of DASM.

Edited by Tom, Fri Jan 25, 2008 8:55 AM.


#12 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 10:03 AM

Unable to open'vcs.h': I don't think this is a bug. dasm just can't find vcs.h, which is needed by your source code. Search the zip archives on the DASM website, it must be there somewhere. Then the simplest way to solve this is to put vcs.h in the same directory where RiverRaid.asm resides.

About the errors:
This is a problem with a typedef that got accidentally changed from signed to unsigned but never fixed. Use a previous version of DASM.

Thank you for answering me !
I copied/paste the wrong shell output...
I have vcs.h and with it, it is still the same without the warning line !
Is there an easy way to correct DASM for this unsigned int issue ?

Version 2.20.09 (both dasm.linux-i386-elf-static & dasm.linux-i386-elf-glibc22 Linux executables):
$ dasm.linux-i386-elf-static RiverRaid.asm -f3 -otest.bin
DASM V2.20.09, Macro Assembler (C)1988-2003
RiverRaid.asm (1265): error: Value in 'and #~PATROL_FLAG' must be <$100.
RiverRaid.asm (1316): error: Value in 'and #~PF_COLLIDE_FLAG' must be <$100.
RiverRaid.asm (1512): error: Value in 'lda #-1' must be <$100.
RiverRaid.asm (2020): error: Value in 'lda #-1' must be <$100.
Unrecoverable error(s) in pass, aborting assembly!
Complete.

I just tried the DOS version 2.20.7, I got the same problem: the plane explodes immediately.
Here is a link to the ROM a compiled, if any one want to test it: http://gravytrain.fr...0/rivertjnb.bin
I'm still trying older versions...

Which version do you use ?

Edited by NicoLarve, Fri Jan 25, 2008 10:08 AM.


#13 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 10:26 AM

OK, I got a really interesting thing here:
I did an hexdump on both the original River Raid rom (on the left), and the one I compiled (on the right):
Look at this: some MSB half-bytes (but not all of them) "0x0n" becomes "0xdn":

Posted Image
(click here if you have problems to read the image)

So, I'm not an expert, but this could be due to the unsigned/signed mistake, isn't it ?

This one was compiled using "DASM Assembler - Version 2.20.02".

PS: the link to "DASM Assembler - Version 2.12.04" is broken on the DASM web page.

Edited by NicoLarve, Fri Jan 25, 2008 10:31 AM.


#14 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 11:35 AM

I've tried every DOS version I could, I always have the same problems.
I've tested to compile it under a Windows 2k, same problem (the bin files always have the same MD5SUM).

Don't know what to do, and I really wonder how do you do people ?! :(

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,894 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Fri Jan 25, 2008 12:47 PM

The disassembly was created for an older version of DASM. Try adding the following line at the top of the source code file:

TIA_BASE_READ_ADDRESS = $30

For the errors your have to replace e.g. #~PATROL_FLAG with #<(~PATROL_FLAG)

Edited by Thomas Jentzsch, Fri Jan 25, 2008 12:54 PM.


#16 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Fri Jan 25, 2008 12:48 PM

I have vcs.h and with it, it is still the same without the warning line !


Yes, but you need that vcs.h anyway, as I said, you're having at least two different problems.

I just tried the DOS version 2.20.7, I got the same problem: the plane explodes immediately.


Post the source of the original disassembly. I actually think 2.20.7 should still be ok...
Oh yes...also post the binary you're expecting to get.

Edited by Tom, Fri Jan 25, 2008 12:59 PM.


#17 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Fri Jan 25, 2008 1:02 PM

For the errors your have to replace e.g. #~PATROL_FLAG with #<(~PATROL_FLAG)


But exactly that wasn't needed in older versions, was it?

I think one could write

lda #-1

Without getting these kinds of errors. Some operators need you to discard high bits, though (depending on the values of its operands)

#18 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,894 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Fri Jan 25, 2008 1:05 PM

But exactly that wasn't needed in older versions, was it?

I think one could write

lda #-1

Without getting these kinds of errors. Some operators need you to discard high bits, though (depending on the values of its operands)

Yes. The bug was introduced in a newer version when the DASM codebase was refactored.

#19 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 1:09 PM

The disassembly was created for an older version of DASM. Try adding the following line at the top of the source code file:

TIA_BASE_READ_ADDRESS = $30

For the errors your have to replace e.g. #~PATROL_FLAG with #<(~PATROL_FLAG)

It's OK with the first tips about TIA_BASE_READ_ADDRESS, with a MSDOS DASM version !
Great ! :D
DASM reported some error, but the game is working:

DASM V2.20.07, Macro Assembler ©1988-2003
RiverRaid_patchDASM.asm (61): error: EQU: Value mismatch.
old value: $0000 new value: $0030
vcs.h (140): error: Label mismatch...
--> CXM0P 0000
vcs.h (141): error: Label mismatch...
--> CXM1P 0001
[...]
[vcs.h (152): error: Label mismatch...
--> INPT4 000c
vcs.h (153): error: Label mismatch...
--> INPT5 000d
Complete.


The second tip should help me to compile the game with a Linux dasm version, I'll try it.

Edited by NicoLarve, Fri Jan 25, 2008 1:09 PM.


#20 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Fri Jan 25, 2008 1:18 PM

Yes. The bug was introduced in a newer version when the DASM codebase was refactored.


That wasn't refactoring. Someone just blindly removed a typedef which interfered with another one in the Linux or glibc system headers - "Now it compiles, therefore it must be OK".

#21 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Jan 25, 2008 1:31 PM

OK, now I feel better for the upcoming things I want to do !
Thank you !

Do you think that displaying the number of exploded bridges would be a hard task ?
In fact, a few weeks ago, a friend of mine introduced me to River Raid, since we began a high score competition.
But the score is not everything in River Raid, since levels (bridges) can also demonstrate how long you can stay alive.
That' why I had this idea... I also like to do such crazy things !

I think I will first try to understand the scoring system (and the use of graphic pointers instead of a score variable).

#22 kamakazi OFFLINE  

kamakazi

    Dragonstomper

  • 530 posts
  • Location:Moberly, Missouri

Posted Wed Mar 26, 2008 1:40 AM

I know that I am a few years behind all of you...but this is awesome! I finally learned something about the 2600! I'd waste a EPROM just to see this work on an actual 2600. You're doing a great thing...i hope that others find this page.

And I'm actually starting to understand assembly a little bit...and I'm a BASIC programmer :P Look forward to the other lessons.

#23 NicoLarve OFFLINE  

NicoLarve

    Space Invader

  • 12 posts
  • Location:France

Posted Fri Mar 28, 2008 1:46 AM

I know that I am a few years behind all of you...but this is awesome! I finally learned something about the 2600! I'd waste a EPROM just to see this work on an actual 2600. You're doing a great thing...i hope that others find this page.

And I'm actually starting to understand assembly a little bit...and I'm a BASIC programmer :P Look forward to the other lessons.

You're welcome !
I began learning 2600 assembly a few month ago, but I already understand how to create an entire frame (creating a "kernel") and I displayed some things on screen (digits using the playfield, rainbows, etc.)... this is the simple beginning, but here we are !

Good luck to you, and I advise you to read all of these sessions (don't skip anything) and also the "Stella programmer guide" (google for it...).
I've first read some parts of this book: "Using 6502 Assembly Language" by Randy Hyde's. But this can only help you to understand ASM, not the Atari hardware which is the most important thing to understand.

Edited by NicoLarve, Fri Mar 28, 2008 1:48 AM.


#24 atarigrammer OFFLINE  

atarigrammer

    Combat Commando

  • 1 posts

Posted Sat May 31, 2008 2:17 PM

hi i downloaded the kernel1.bin and extracted it to c:\atari2600\dasm\dasm\bin\dos but when i type the command dasm kernel.asm -lkernel.txt -f3 -v5 -okernel.bin it says DASM V2.20.05, Macro Assembler ©1988-2003

START OF PASS: 1

----------------------------------------------------------------------

SEGMENT NAME INIT PC INIT RPC FINAL PC FINAL RPC
and nothing else i was wondering what im doing wrong or if i need code from somewhere else thank you

#25 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Mon Jun 2, 2008 5:32 PM

hi i downloaded the kernel1.bin and extracted it to c:\atari2600\dasm\dasm\bin\dos but when i type the command dasm kernel.asm -lkernel.txt -f3 -v5 -okernel.bin it says DASM V2.20.05, Macro Assembler ©1988-2003

START OF PASS: 1

----------------------------------------------------------------------

SEGMENT NAME INIT PC INIT RPC FINAL PC FINAL RPC
and nothing else i was wondering what im doing wrong or if i need code from somewhere else thank you

What is "kernel1.bin"? And why do you need to extract it? Usually a compressed file or archive has an extension such as ZIP, whereas (in the world of Atari 2600 programming or emulation) the BIN extension indicates a file that's a ROM image. You wouldn't need to extract anything out of a BIN file, nor would you be able to.

Anyway, the command line you mentioned doesn't have any reference to kernel1.bin, and you didn't mention anything about downloading the kernel.asm file, so is it even compiling anything?

Michael




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users