+Andrew Davie Posted May 25, 2003 Share Posted May 25, 2003 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. 1 Quote Link to comment Share on other sites More sharing options...
Happy_Dude Posted May 26, 2003 Share Posted May 26, 2003 What does the sample kernel include the Macro.H file? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 26, 2003 Author Share Posted May 26, 2003 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 Quote Link to comment Share on other sites More sharing options...
JBones Posted June 1, 2003 Share Posted June 1, 2003 I can find distributions of DASM that include VCS.H, but not MACRO.H. Can you please post MACRO.H? Thanks. -JB Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 1, 2003 Author Share Posted June 1, 2003 I can find distributions of DASM that include VCS.H, but not MACRO.H. Can you please post MACRO.H? Thanks. -JB http://sourceforge.net/projects/dasm-dillon/ Quote Link to comment Share on other sites More sharing options...
chadtower Posted September 3, 2003 Share Posted September 3, 2003 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! Quote Link to comment Share on other sites More sharing options...
kisrael Posted September 5, 2003 Share Posted September 5, 2003 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? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2003 Author Share Posted September 6, 2003 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 Quote Link to comment Share on other sites More sharing options...
kisrael Posted September 6, 2003 Share Posted September 6, 2003 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. Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 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. Quote Link to comment Share on other sites More sharing options...
Tom Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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 January 25, 2008 by Tom Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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.free.fr/atari2600/rivertjnb.bin I'm still trying older versions... Which version do you use ? Edited January 25, 2008 by NicoLarve Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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": (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 January 25, 2008 by NicoLarve Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 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 ?! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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 January 25, 2008 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
Tom Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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 January 25, 2008 by Tom Quote Link to comment Share on other sites More sharing options...
Tom Posted January 25, 2008 Share Posted January 25, 2008 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) Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 25, 2008 Share Posted January 25, 2008 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. Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 (edited) 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 ! DASM reported some error, but the game is working: DASM V2.20.07, Macro Assembler ©1988-2003RiverRaid_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 January 25, 2008 by NicoLarve Quote Link to comment Share on other sites More sharing options...
Tom Posted January 25, 2008 Share Posted January 25, 2008 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". Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted January 25, 2008 Share Posted January 25, 2008 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). Quote Link to comment Share on other sites More sharing options...
kamakazi Posted March 26, 2008 Share Posted March 26, 2008 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 Look forward to the other lessons. Quote Link to comment Share on other sites More sharing options...
NicoLarve Posted March 28, 2008 Share Posted March 28, 2008 (edited) 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 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 March 28, 2008 by NicoLarve Quote Link to comment Share on other sites More sharing options...
atarigrammer Posted May 31, 2008 Share Posted May 31, 2008 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 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 2, 2008 Share Posted June 2, 2008 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 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.