Learning ASM
Moderator: BigEvilCorporation
Learning ASM
I've been looking after programming for consoles since long ago. I've decided to start on the Mega Drive then, but not knowing either C or ASM (only thing I know is BASIC, heh) this is obviously going to be a hard task. Even if I don't really like to, I can understand and learn new programming languages easily (just never had patience for C), and so I came here to ask if you guys could give me any tips on ASM, like a simple list of commands and their syntaxes, or if anyone knew where to find a tutorial for MD-specific ASM programming.
I don't intend to make anything big, only some demos and maybe simple games. A Tetris clone maybe, who knows.
So, could anyone help me please?
I don't intend to make anything big, only some demos and maybe simple games. A Tetris clone maybe, who knows.
So, could anyone help me please?
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
You know basic? And like it? If you do, you should try this:
http://devster.monkeeh.com/sega/basiegaxorz
:Basic Compiler for the MegaDrive
But you need to know how to create Tiles and Maps for displaying anything (text included).
I think C is worth learning, though. ASM is a pain because doing a simple thing (like one IF) requires a lot of asm instructions...
http://devster.monkeeh.com/sega/basiegaxorz
:Basic Compiler for the MegaDrive
But you need to know how to create Tiles and Maps for displaying anything (text included).
I think C is worth learning, though. ASM is a pain because doing a simple thing (like one IF) requires a lot of asm instructions...
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Some things to read...
http://en.wikipedia.org/wiki/Motorola_68000
http://www.tigernt.com/onlineDoc/68000.pdf
http://srf50194.ld.infoseek.co.jp/asm/mc68000.shtml
http://www.math.unipd.it/~mezzetti/ROME ... 0/toc.html
Once you understand how the 68000 works, then you want to read about the Genesis hardware.
http://emu-docs.org/?page=Genesis
Lot's of good stuff there, but the main one to read is
http://emu-docs.org/Genesis/sega2f.htm
http://en.wikipedia.org/wiki/Motorola_68000
http://www.tigernt.com/onlineDoc/68000.pdf
http://srf50194.ld.infoseek.co.jp/asm/mc68000.shtml
http://www.math.unipd.it/~mezzetti/ROME ... 0/toc.html
Once you understand how the 68000 works, then you want to read about the Genesis hardware.
http://emu-docs.org/?page=Genesis
Lot's of good stuff there, but the main one to read is
http://emu-docs.org/Genesis/sega2f.htm
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
That Sega2F doc... it has a bunch of things mis-aligned (like values in tables), and has a lot of missing pages, the PDF version is better (but heavier in file size) and it's here on the forum somewhere...
EDIT: there it is...:
http://www.spritesmind.net/_GenDev//for ... .php?t=227
This is the doc I open most of the time when I'm walking in circles in my MD coding:
http://www.monroeccc.edu/ckelly/Files/E ... ickRef.pdf
Chilly Willy had already posted a txt similar to this one but the latter it's easier to read. (for me it is...)
EDIT: there it is...:
http://www.spritesmind.net/_GenDev//for ... .php?t=227
This is the doc I open most of the time when I'm walking in circles in my MD coding:
http://www.monroeccc.edu/ckelly/Files/E ... ickRef.pdf
Chilly Willy had already posted a txt similar to this one but the latter it's easier to read. (for me it is...)
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Yeah, those are better. With those and a decent manual on the 68000 (until you understand the instruction set better), you're all set.Jorge Nuno wrote:That Sega2F doc... it has a bunch of things mis-aligned (like values in tables), and has a lot of missing pages, the PDF version is better (but heavier in file size) and it's here on the forum somewhere...
EDIT: there it is...:
http://www.spritesmind.net/_GenDev//for ... .php?t=227
This is the doc I open most of the time when I'm walking in circles in my MD coding:
http://www.monroeccc.edu/ckelly/Files/E ... ickRef.pdf
Chilly Willy had already posted a txt similar to this one but the latter it's easier to read. (for me it is...)
Well, I can easily understand Genesis structure, but how (other than giving me the hardware references) would it help me about the ASM language itself?
EDIT: Nevermind, hadn't checked that 68k quick reference. That helps a lot. So now only 2 questions remain: What kind of compiler should I use? One with a GUI/IDE would be preferable, but I can take command-line ones as well. And where can I find some 68k ASM examples so I can understand it a bit more?
EDIT: Nevermind, hadn't checked that 68k quick reference. That helps a lot. So now only 2 questions remain: What kind of compiler should I use? One with a GUI/IDE would be preferable, but I can take command-line ones as well. And where can I find some 68k ASM examples so I can understand it a bit more?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
You use an assembler for assembly language. There's the old SNASM assembler that many folks use. I think more folks here are using asmx.
http://xi6.com/projects/asmx/
You can use any editor you're comfortable with to write the assembly files.
As for example code, you'll have to look around. The demos forum here has some mixed asm/C code. You also might check http://devster.monkeeh.com/ as he has some example code as well.
http://xi6.com/projects/asmx/
You can use any editor you're comfortable with to write the assembly files.
As for example code, you'll have to look around. The demos forum here has some mixed asm/C code. You also might check http://devster.monkeeh.com/ as he has some example code as well.
if you want really small samples, there's some on my page:
http://www.pascalorama.info/article.php?news=9&cat=20
really basic, and they are my really first attempt at asm
http://www.pascalorama.info/article.php?news=9&cat=20
really basic, and they are my really first attempt at asm
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
ASM is not hard, just tricky sometimes. I found some nice guides at www.programmersheaven.com, and have some tools and sources on my site www.hot.ee/tmeeco
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
[quote="Pascal"]if you want really small samples, there's some on my page:
[url]http://www.pascalorama.info/article.php?news=9&cat=20[/url]
really basic, and they are my really first attempt at asm[/quote]
Hey Pascal, your pong demo was the first program I studied !!! Thank you !
[url]http://www.pascalorama.info/article.php?news=9&cat=20[/url]
really basic, and they are my really first attempt at asm[/quote]
Hey Pascal, your pong demo was the first program I studied !!! Thank you !
I recommend good ole' paperbooks about atari st/amiga assembler, they all cover the 68000 cpu and are usually far more comprehensive than those bits'n'piecies spreading across the internet. A good (german) source for books are those published by "Markt&Technik", I personally stick to those till today.
You really should give 68000 assembler programming a try, it's the best start one could imagine to dig into any assembler programming at all and it's a piece of cake compared to other (ugly) cpus.
As assembler i recommend using the gnu assembler (gas) that's shipped as part of the gnu binutils package though it's syntax is bit special compared to the "traditional" 68k asm syntax as known from devpak/seka/..., but nevertheless, it's somewhat maintained and it works
You really should give 68000 assembler programming a try, it's the best start one could imagine to dig into any assembler programming at all and it's a piece of cake compared to other (ugly) cpus.
As assembler i recommend using the gnu assembler (gas) that's shipped as part of the gnu binutils package though it's syntax is bit special compared to the "traditional" 68k asm syntax as known from devpak/seka/..., but nevertheless, it's somewhat maintained and it works
Pascal's code can be improved by using segments to declare variables. It's easier to read and it won't give you a chance to make a mistake and screw up your variables by declaring them wrong.
(This code is for asmx. It's probably very similar or even identical in other assemblers, but not having used them, I don't really know.)
Instead of this:
Write this:
Isn't that a whole lot prettier?
If you want a byte, use "ds 1", a word, use "ds 2", and a longword, "ds 4". Easy. Just be careful to keep your words and longwords aligned to 16-bit boundaries (use "even" before 16/32-bit variables if you're not sure whether they'll be aligned or not).
The "seg" at the end tells the assembler that the globals segment has ended, at least for now, and you're back to writing ROM code.
You can also have multiple "globals" blocks. Let's get some terminology clear, to distinguish between blocks and segments. I'm using the word "block" to mean a "seg globals ... seg" block of code. A "segment" is a place in memory where code or variables go. So you may have multiple blocks, but as long as you name each one the same thing (in this case "globals"), they are all the same segment. The assembler just combines the blocks of a segment together in order as if they were written as one big block in the first place.
When using multiple blocks, in the first and ONLY the first block, you must use "org $ff0000". This tells the assembler that these variables go in RAM (which begins at FF0000) rather than ROM, which is the point of using the segment.
Being able to use multiple blocks is good because you could, say, have a globals block in your main file, and then have another one in, say, video.inc that contains globals specific to video routines, and the assembler will correctly merge the blocks together in a single segment, as long as you do that "org $ff0000" the first and only the first time. You don't even have to include any variables the first time if you don't want to define any before including your other files; you can just do this:
One thing to be careful about is that words and longwords need to be on 16-bit boundaries. If your globals block doesn't end on such a boundary, the next block won't begin on one. For that reason I prefer to end my segments with "even" just before "seg", which forces the next block to begin on a 16-bit boundary. Alternatively, you can always begin them with "even" instead. It doesn't matter which as long as you either always choose the beginning or always choose the end.
Whew, this was a long and exhausting post to write. Hope it helps.
- Kef
(This code is for asmx. It's probably very similar or even identical in other assemblers, but not having used them, I don't really know.)
Instead of this:
Code: Select all
vtimer equ $ff0000 ; long
ballx equ vtimer+4 ; word
bally equ ballx+2 ; word
ballpx equ bally+2 ; word
ballpy equ ballpx+2 ; word
x1 equ ballpy+2 ; word
y1 equ x1+2 ; word
x2 equ y1+2 ; word
y2 equ x2+2 ; word
Code: Select all
seg globals
org $ff0000
vtimer ds 4
ballx ds 2
bally ds 2
ballpx ds 2
ballpy ds 2
x1 ds 2
y1 ds 2
x2 ds 2
y2 ds 2
seg
If you want a byte, use "ds 1", a word, use "ds 2", and a longword, "ds 4". Easy. Just be careful to keep your words and longwords aligned to 16-bit boundaries (use "even" before 16/32-bit variables if you're not sure whether they'll be aligned or not).
The "seg" at the end tells the assembler that the globals segment has ended, at least for now, and you're back to writing ROM code.
You can also have multiple "globals" blocks. Let's get some terminology clear, to distinguish between blocks and segments. I'm using the word "block" to mean a "seg globals ... seg" block of code. A "segment" is a place in memory where code or variables go. So you may have multiple blocks, but as long as you name each one the same thing (in this case "globals"), they are all the same segment. The assembler just combines the blocks of a segment together in order as if they were written as one big block in the first place.
When using multiple blocks, in the first and ONLY the first block, you must use "org $ff0000". This tells the assembler that these variables go in RAM (which begins at FF0000) rather than ROM, which is the point of using the segment.
Being able to use multiple blocks is good because you could, say, have a globals block in your main file, and then have another one in, say, video.inc that contains globals specific to video routines, and the assembler will correctly merge the blocks together in a single segment, as long as you do that "org $ff0000" the first and only the first time. You don't even have to include any variables the first time if you don't want to define any before including your other files; you can just do this:
Code: Select all
; Set up the globals segment for your include files
seg globals
org $ff0000
seg
; blah1.inc and blah2.inc have their own globals blocks,
; and now they don't have to worry about using org $ff0000
include blah1.inc
include blah2.inc
; Now the globals for your main file
seg globals
var1 ds 2
var2 ds 2
seg
Whew, this was a long and exhausting post to write. Hope it helps.
- Kef