OSDev.org

After teaching myself a tiny bit of German I was able to output the Assembly code of an Atari ST game called Brataccas.

Or at least I think that is what I did ::)

There are two main files that run the program:

BRATACCA.PRG
MAIN

If my understanding of how most software works BRATACCA.PRG is the interpreter of sorts, MAIN is the resources.

My goal here is only to extract images from these files. I have no idea how to go about this.

I requested Brian's help long ago, but, he is still busy with SCI Studio (although he did offer to help when SCI VGA is released).

Basically, I am going to do as much as possible myself. I consider it a small miracle that I made it this far, and with a disassembler written in German at that (actually it was pretty easy to figure out).

Any help from anyone would be GREATLY appreciated.

You may download both the original files and the decompiled txt files here:

http://www.juncmodule.com/juncAGS/BRATACCAS.zip

Thank you,
-junc

Now you should look through this code and look how the game loads its resources. The code's in Motorola 68000 assembly, you should be able to find some tutorials about it.

Oh yes, I might be wrong here, but I think that "bratacca.prg" is a crack, which loads the whole game from the file "main".

A PRG file is a typical executable on the Atari ST. This one is cracked yes. But, that file is on the original disk. So, you are right, it is a crack that loads the main file...sort of ;D


yep, that sounds like a good next step. So, I assume that means I probably did do the right thing here? It appears to be correctly Disassembled I mean?

Can anyone recommend any good 68K tuts? I will start googling for some later today.

Oh yeah, just how hard is this going to be? On a scale of 1 to 10? Considering that I am a complete n00b with nearly -0- understanding of Assembly?

later,
-junc

It seems to be correctly disassembled, and I would give it about 7 or 8. About tutorials, I can't suggest you any, as I know little about 68K assembly, and never bothered to study it.

Motorola 6800 is pretty easy to learn once you've understood the basics of assembly language. If you've ever learned another computer language, you would know that it has certain basic functions that you need to learn.

For example: It doesnt matter what math you take as each type of math requires the same basic functions: add, subtract, multiply, and divide. Everything else is just added on.

I dont know of any good tutorials as I learned it in College. I would check out www.programmersheaven.com for tutorials and a download of the compiler.

Woo Hoo!
Even though I have no clue what a lot of that means...

the "//" parts are my comments

I reserved some books at the library and found this tutorial:

http://emulazione.multiplayer.it/stgraveyard/Assembler/TutSection.htm

beyondsociety:
I have a little programming exp. I've become rather good with AGS's scripting language. But, scripting and programming are somewhat far apart. I've read about 3/4 of "Assembly Language: Step by step".

Not nearly enough to understand what I'm doing, but, my hope is to decode, or understand each line and possibly comment it. That way once I finish maybe getting someone elses help will be easier. I understand that no one wants to poor of a million lines of code and get nothing out of it. I figure if I can at least put a dent in the work... ;D

Thanks for your replies guys, keep the advice coming. No matter how small, I need the encouragement right now. I will post a few things now and again updating my progress.

I need to get a better grasp on what the heck a stack is. I assume it is like clearing the memory before a program starts..??

later,
-junc

Not quite.

The stack is an area of RAM used for temporary storage of data and/or return addresses when the CPU is executing a subroutine call or an interrupt service routine.

Subroutine = a subroutine (function, procedure, or subprogram) is a sequence of code which performs a specific task, as part of a larger program, and is grouped as one, or more, statement blocks; such code is sometimes collected into software libraries. Subroutines can be "called", this allows programs to access the subroutine repeatedly, without the subroutine's code having been written more than once.

Interrupt Service Routine (ISR) = An interrupt is a piece of code that is executed asynchronously with the running program. That means that the processor can decide to jump to that code at any time it is executing the running program. Asynchronous code is dangerous, in the sense that the synchronization between that code and the running program should be guaranteed by the designer.

A typical use of an ISR is as a callback function: the running program needs some input from another program (or hardware device), but doesn't want to wait for that input itself. Therefore, it programs the ISR which will be executed when the other program or hardware has delivered its data.

An ISR typically runs with other interrupts disabled, and it pre-empts all running programs. So, an ISR should never execute a blocking operation, and be as short as possible. Typically, this means just reading or writing a couple of bytes from a peripheral device. The processing of these data is done in a Deferred Service Routine, that runs with interrupts enabled.

ISR
A hardware interrupt to the CPU makes this CPU save the context of the currently active process, and jump to the address stored in the interrupt vector entry corresponding to the interrupt number (``IRQ'') of the hardware interrupt. This address must be filled in by the application programmer; this is called the registration of the Interrupt Service Routine (ISR). It's the application programmer's responsibility that the registered value points to a valid function.

Typically, the ISR does nothing more than reading or writing a couple of registers from a peripheral card, and/or signaling an event to wake up its DSR (see below). For most processors, no new interrupts arrive during the execution of the ISR.

The processing of the data is done elsewhere. More specifically, in the so-called the Deferred Service Routine (DSR), which runs with interrupts enabled. The DSR is scheduled by the RTOS, after all interrupts have been serviced.

For a motorola 6800HC11 microprocessor, the stack pointer is a 16-bit register within the CPU that points to the next free location on the stack. Each time a byte is put onto the stack, the stack pointer is automatically decremented (decreased by one), and each time a byte of data is retrieved from the stack, the stack pointer is automatically incremented (increased by one). Normally, the stack pointer is initialized by one of the first instructions in an application program.

In order to use the stack, you need to learn how to push and pop stuff off of it. Hope this helps.

Wow. Thank you. Very helpful. I'm trying to get my head around ISR's and the concept of asynchronous code. I'm going to ask on the AGS forums if someone will give me a frame of reference related to AGS. It might help.

I am familiar with functions, therefore I understand subroutines. I should have mentioned that I know a little C++(very little).

Just out of curiosity do you know what DC.B is? Isn't it a display call of some sort. There is a ton of code like this:



I assume this may be images, colors for pixels maybe? Could it be THAT easy!? I imagine not.

As a four color game I suppose it could...

Thank you very much for your help and time.

later,
-junc

EDIT: Nevermind...Define Constant Byte...

Yes, but the Atari ST used the M68000 (the same CPU as the riginal Macintosh and Amiga) not the M6800 (an 8-bit CPU used in a lot of early SBCs and some current embedded systems; the Mostek 6502, which was used in the Apple II, the =C64, and the Atari 800 and 2600, was based loosely on it)

The 68k has 16 32-bit general-purpose registers, but a 24-bit address space (this was a cost saving measure that didn't pan out; the 68020 and other later models used the whole 32 bits of addressing width, and the 68030, which was contemporary to the 80386, added hardware memory management). These registers are divided into two groups, Addressing (A0-A7) and Data (D0-D7); while they all can be used for any purpose, traditiona dictated that A registers be used for addresses (pointers, etc.) and the D registers for temporary data manipulation. By convention, any of the A registers could be used as the stack pointer, but A7 was the default and it was rare for any others to be used instead.

M68000 assembly language is very different from x86 assembly, and frankly is a lot better in just about every regard (in this crazy business, it only figures that the worst of all the microprocessor architectures ended up becoming the standard). I found this tutorial about it on Programmer's Heaven, but I don't know if it's any good. This site seems to have some material on the ST, as does this one. HTH.

RE: tips on disassembling

One of my main tips is to see if you can some how load it into IDAPRO (Interactive Disassembler). It should have a module that will work with the ST processor. It is currently bar none the best, and will aid greatly in your disassembly.

Assembly language isn't too difficult once you get the hang of everything. You simply have to take it slow at first. if you follow it completely, you can turn something like:

mov ax, 10
mov bx, ax
mov cx, bx
mov ax, cx
inc ax
mov somevar, ax

into somevar = 11

Here is how I generally will go about disassembling a game:

1-Load it in IDA
2-Find the file I/O routines
3-Find out which files are accessed, then label the routines accordingly
4-Label anything you can along the way (such as w002FD to wFileHandle) using the interrupts or i/o addresses as reference
5-Go to the entry point and slowly trace it all from the top labelling and commenting what is going on. Eventually, you will reach the file i/o routine you want. With all the labels you've made so far, much of the executable may have already been understood enough to figure out what's going on with the file loading.
6-A debugger is helpful too, if you can get one that works for your platform/executable.

Once you get experienced, it could sometimes be as simple as steps 1,2,3 (skipping 4,5,6 )

Brian

Keep in mind, Brian, that this is a different CPU from the x86, and has a different instruction set and architecture. An x86 assembler won't help here.

Foo.

That IDA program looks great. It does support 68k but, only in the $300 version. It's just not worth it. I did manage to find the freeware version, but it does me little good.

Someone pointed out that I don't need to go through the trouble of disassembling it. So, I have been trying out a Atari ST graphics ripper and even been able to find some distorted images, but can't quite get them to clear up. Very frustrating to have it right there in front of me.

It has also been pointed out to me that the DC.B opcodes are in fact the sprites.

I just have no idea what to do with that knowledge. Is it possible for me to find a shortcut? Or was my original instinct to just learn 68k the best one?

very frustrating.

later,
-junc

Erm... Where does that come from? We're talking about disassemblers, not assemblers, and it IDA supports 68K code as well as x86. I was just giving a generic example with x86. On systems such as the NES' 6502 for example, which doesn't use file I/O, you'd look at the I/O addresses that are written to and such, and possibly look at the CHR ROM to get the idea of what's happening. The concepts are all very similar.

Schol-R-LEA is right, at least as far as I'm concerned. There is no way I'm going to drop $300 on a program just to disassemble one program and then never use it again.

I didn't see anything about adding modules to the free version. They also claim on the web site that they won't give out the demo version to private individuals. I also understand it's crippleware.

I think he was talking more about the recommended disassembler rather than the example you provided.

eh,
-junc

you used to be able to find IDA in all the shareware stuff (check simtelnet or that).

i'm sure there is a free IDA version around that does 68k....