Learning 68K Assembler: how do I do it?

Post Reply New Topic

When I took my first faltering steps toward programming, it was on the Amiga. I always wanted to be good at it, and I picked what I thought was the best tool for understanding how the computer actually worked. Unfortunately, I took the recommendation of my computer mag of choice and chose AMOS.

In other words, it was much later that I learned to code C and Java and suchlike, and it always rankled that I never learned "proper" coding on the Amiga. So now I've decided that enough is enough. I'm going to make an effort toward learning 68000 Assembler (I hear DevPac is a good IDE for the purpose), most likely using the WinUAE virtual machine. There's just one problem: this is so low-level I don't even know where to begin, and the one tutorial I've read utterly mystified me. I understand how binary and hex works, but registers confound me.

Anyone here know where I should go or how I should proceed?

Not sure what to suggest. One thing would be to learn a more modern architecture, where there are more educational resources and it's easier to write programs. WROX has a good book Professional Assembly Language that talks about Linux, and there are a million tutorials online. Once you know assembler in general, it's much easier to learn a new architecture, so picking up an 8-bit instruction set wouldn't be as big of a challenge if you knew modern x86 assembler.

Also, don't overlook old, cheap books. I have a great book called IBM PC Assembler Language and Programming which talks about the original 8086 architecture. Probably cost $1 or something. (I can't remember.) I imagine similar books for Amiga are out there.

Also, emulators are great. You could get an Amiga emulator. I set up a Windows 2000 virtual machine for MS-DOS programs. (I have Turbo Assembler and the old a86/d86 shareware programs on it.) Windows 2000 is the best MS-DOS emulator I know of. After W2K, DOS support started getting dropped. W2K supports MS-DOS as fully as possible, and also has networking so you can easily get files into and out of the emulator instance. Much easier to deal with than trying to emulate MS-DOS itself.

As I remember, there's not much to the 8-bit processors. You have like four registers, and a tiny 64k address space (most of which is mapped to things like video memory). So they're good to learn because there's not much to them. My memory isn't good, but I don't think there is even a stack provided by the hardware.

What is it that assemblers do. They get down to the basic operations that a computer actually does: operate on a register and a location to produce a value to put in a register. Compare a register with a location and take a branch to a location depending on the comparison. And do unconditional branching as well as branching with a return address to invoke a subroutine.

Once you understand just how boring and primitive the computer is at its very heart you are ready to do assembly programming.

I have just taught you how to do bare a** basic programming while standing on one foot.

ruveyn

From what I've been told, low-level IBM x86 architecture is less ordered and more of a hassle than the Amiga. Even accounting for fanboy bias, the word's generally been the same - the modern PC has (vastly) greater computing power, but is a lot less intuitive to work with. Supposedly, anyway.


I'm considering trying to pick up the Amiga Hardware Reference Manual, which I think contains such things. Still, it's not something that would help me make the transition from "hello, there are X registers in this machine" to "look, ma, something's happening on the screen," I suspect.


I have WinUAE up and running already.


Um, the Amiga isn't an 8-bit machine. It's 16/32 bit, with 512K internal and several custom chips.

Okay, that part I get. What I don't get is A) how to employ the DevPac IDE (which isn't something I think you guys here can help me with) and B) how to go about accessing peripherals such as the screen, the keyboard, the mouse etc.

One sets up a "channel" which is a pseudo register corresponding to a peripheral device. Then one tells a byte stream to go from a memory location to the channel or from the channel to the memory location. Every machine has somewhat different details on how to set that up. Also for interrupt conditions created by external devices (such as clocks, peripherals or external data lines) one must set up a transfer location to process the interrupt. This is asynchronous and out of sequence with whatever program is going on.

ruveyn

Awesome. That's enough of a starting point for me to begin, I think. Time to read a few old manuals and see what I can deduce.

Thank you.

What I'd do is write your programs in a higher-level language like C, and either compile them to assembly code (which some compilers will do) or examine the object code with a disassembler. That way you get a feel for how compilers represent high-level structures like if-else, switch, function calls, etc. and you will know how to write them directly in assembly.

Registers can be thought of simply as special memory addresses that actually reside inside of the CPU itself. Generally the CPU can do three types of operations - read the contents of a memory address into a register, write the contents of a register back out to an address in main memory, and perform some sort of calculation (addition / subtraction, etc.) or logic operation (and/or) on values contained within one or more registers. What the CPU cannot normally do is perform math or logic operations on values that are in main memory but have not been loaded into the CPU's registers. So say you want to add two numbers together - chances are you'd instruct the computer do four operations to accomplish this - a) load the first number into one registry b) load the 2nd number into a 2nd registry, c) instruct the CPU to perform an addition operation on the contents of those two registers, placing the result in a 3rd register, and d) writing the contents of that third register back out to an address in main memory.

Normally the CPU has a special register called a program counter, which tells it what address in memory to go to to fetch the next instruction that it will execute. So a normal CPU operation will consist of loading the contents of the memory address pointed to by the program counter into a special command register, executing that command (which would be something like adding/subtracting, logic, or loading/writing register values), then incrementing the program counter.

Other operations can include branching (i.e. changing the address pointed to in the program counter to a different memory address entirely - think of this like a GOTO in BASIC), pushing or popping values from the system memory stack, or executing a sub-routine (which is basically a combination of the above - pushing the program counter to the stack, changing the program counter to another location, executing the series of instructions that begin at that new location, then finally restoring the original program counter value from the stack and resuming execution after the original sub-routine call).

A lot will have to do with the specific CPU and what its limitations are. For instance, a CPU might have 16 registers R0-R15 but it might only be able to perform additions using registers R0-R7. Or, in older computers like the Apple //, there might be more system memory available than what the CPU can directly address at once, in which case you may need to command the CPU to switch back and forth between different memory banks. Also, some operations may implicitly overwrite a register, for instance performing an addition on the contents of R0 and R1 may write the results to R2 - which would wipe out anything else you had previously loaded into R2 - so there can be some gotcha's.

There's probably some more complicated (i.e. compounded) operations that modern CPU's are performing. Most of my assembly knowledge comes from a freshman comp. sci assembly course that I took probably in 1992 and in which we were taught assembly language for the DEC VAX computers, which were old even then. So I'm sure there's a lot that's different on a Core i7 or ARM chip today but I imagine that the fundamentals are still basically the same.

As a fellow Amiga fan, I congratulate you on your choice of computer .

I learnt a bit of 68k Assembly language using DevPac. I have it installed on my Amiga 500+.

I have the manual which accompanies DevPac which was excellent to tell me how to use the software, and I also bought the Abacus book 'Amiga Machine Code', which talks about 68k assembly applied to the Amiga, and hence does things like keyboard input, screen output, sound etc.

So, I can highly recommend you find a decent book. Ebay is probably a good bet. The 68k Programmers Reference Manual is also handy to have. It can be downloaded as a PDF from Freescale's website.

I wouldn't worry about learning an older processor. A lot of the concepts you will learn remain the same for newer ones.

I worked a lot with 68K family, as both operating system and application developer. The firts thing you need to learn is the memory model and the register model of 68K family. If you don't plan to write an OS you only need to learn the User part. Since you are programming under an operating system you also need to know register used by the system for global variable (usualy A5), local (usualy A6), or any special purpose (ex. on 68K Mac A4 was used for ressource code). I don't had the chance to work on Amiga hardware.

68K instruction set is easy to learn, it's CISC and it's an orthogonal desing...

Assembly used to be my language of choice. I originally learned the assembly language on the IBM 360/370 and related computers such as the Amdahl 470.

After that, I learned it on a Data General SuperNOVA. That was quite interesting. It's the only computer I've seen with autoincrement and autodecrement registers. On the SuperNOVA, this was what it took:
1) Enter the program on the standard 80 column cards.
2) Load the cards on a Data General NOVA to compile the program and write it to a paper tape.
3) Mount the paper tape on the SuperNOVA
4) Enter the bootstrap program on the SuperNOVA using the switches on the front console.
5) Run the bootstrap program to read the paper tape.
6) Execute the program.

After that it was the DEC PDP-11 computers and then to DEC Vax computers.

The PDP-11 had an interesting instruction. You would actually place the instruction on the stack when calling a subroutine. When the subroutine was finished, it would then execute the instruction from the stack to clean up after itself.

I quickly found when trying to use it that the description in one popular PDP-11 Assembly Language book at the time was wrong. It took a bit of work to figure out how it was supposed to be used.

At one DECUS once, I was sitting in a room full of Assembly Language fanatics and someone asked if anyone used the instruction. Out of the entire room, it appears that I was the only one who had ever actually used it!

Finally, on the Intel x86 computers. This is my least favorite Assembly Language platform of any that I've used.

I was going to buy an Amiga once shortly after they came out and bought a book on the Assembly Language for the Motorola 68000. When I went to buy the Amiga, the salesman told me that there was no assemblers available yet so I left without buying one.

Many years ago on one of my computer science exams I was supposed to write a program in 68K assembler. Not having done much revision (like none at all) I was pretty unfamiliar with the 68K. In the end I wrote the program in 6809, which I knew well. I then used the supplied 68K crib sheet to translate it to 68K assembler. I got a pretty good grade as well