Page 1 of 1

Learning ASM

Posted: Sun Mar 23, 2008 6:25 am
by Syniphas
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?

Posted: Sun Mar 23, 2008 1:17 pm
by Jorge Nuno
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...

Posted: Sun Mar 23, 2008 3:12 pm
by Syniphas
Thanks for the link, Jorge. And yes, I know that ASM is really hard to learn, but I figured I might give it a shot. :P

Plus, I chose ASM over C because it's more powerful on the MD when it comes to a lot of instructions (for example, a complex game).

Posted: Sun Mar 23, 2008 11:21 pm
by Chilly Willy
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

Posted: Sun Mar 23, 2008 11:49 pm
by Jorge Nuno
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...)

Posted: Mon Mar 24, 2008 5:56 am
by Chilly Willy
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...)
Yeah, those are better. With those and a decent manual on the 68000 (until you understand the instruction set better), you're all set.

Posted: Mon Mar 24, 2008 3:43 pm
by Syniphas
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?

Posted: Mon Mar 24, 2008 6:20 pm
by Chilly Willy
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.

Posted: Tue Mar 25, 2008 8:18 am
by Pascal
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

Posted: Tue Mar 25, 2008 5:52 pm
by TmEE co.(TM)
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

Posted: Tue Apr 01, 2008 1:34 pm
by ob1
[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 !

Posted: Tue Apr 01, 2008 5:24 pm
by Pascal
ob1 wrote: Hey Pascal, your pong demo was the first program I studied !!! Thank you !
thanks :) really glad you learned from it , even it's poorly coded :)

now the student surpassed the "master" ;)

Posted: Thu Apr 17, 2008 10:51 pm
by pnm
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 :)

Posted: Tue Jul 22, 2008 9:14 pm
by furrykef
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:

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
Write this:

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
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:

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
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