Introducing the DMPP Amiga debugger

I had this actually running for some time now: It is a graphical debugger which helps me understand how the 68000 instructions in the Kickstart ROM affect my Amiga emulator’s state. Here is a screen shot:

It is currently mainly a view to the Mahatma68k CPU, the two CIA-8520’s and the custom chip registers. It can execute a defined number of steps and any changes to the chip registers or CPU state will show there. I am currently implementing a function which displays a tooltip for each custom chip register to show a little more information than just its numerical value. The CIA’s and the CPU have only a few registers, so it is still feasible to display the role of each flag in the main view. The sheer amount of custom chip registers however, made it even hard to get them all in one frame.
By the way, compliments to the developers of Scala Swing – these are very nice wrappers ! I started with conventional Java Swing components and then realized that Scala Swing makes programming user interfaces much easier. As a long time user,  Swing does really seem to be all that difficult to me, still I like it when the code looks as tidy as it does when using Scala Swing.

What else is new today ? I have made my second file release to Mahatma68k today. As its main addition, it now comes with the Javadocs the distribution archive and made sure only to have the methods and classes in there that matter to the user of the library.

First file release for Mahatma68k

I decided to build a package of the current code in the Mahatma68k repository and upload it with the little example program that comes with it. It can now be found on its project website. I am aware that not everyone likes or knows maven and so I provided an ant build file for the binary distribution. I like Maven a lot, and have therefore standardized all my builds on it, but it has a steeper learning curve.

I could have provided projects for Netbeans, Eclipse and IDEA, but I guess that this task is simple enough. For Mahatma68k, I wrote everything in Emacs and Vim by the way.

Oh yes, and finally, I have the most important reference manuals together that I will need for my emulation project:

Amiga Reference Manuals

Of these, the “Amiga Hardware Reference Manual” is the most important, of course. I got the Exec Manual and “Libraries and Devices” as well (DOS and Intuition are coming, too), because I might be able to clarify some details in case I get stuck.

Birth of a New Amiga Emulator

Do not take the title serious. As long as there is no release, this is strictly Vaporware(TM). Or something like that…. However, with the release of Mahatma68k, the likeliness of such a release has become somewhat more probable.

When I started the project, which has the current working title “I Heart Amiga”, it actually started as an attempt to make WinUAE’s features available in Unix versions. I have to admit it, I do not like C when it comes to writing a virtual machine. The abstraction level is simply too low and I like to look at a virtual machine as a system of components (a job for an object-oriented language). There is no sense for me to write a lot of extra code that has nothing to do with the problem. You can get it done in pure C, but then you could also use Notepad to create whole web sites.

I then had this crazy idea that the JVM might actually be fast enough nowadays to at least reach the performance of an Amiga 500 (something that has yet to be proven) and so I just kind of started hacking together some code in Scala. The nice thing about doing side projects is that you can just choose what you think suits the problem and I wanted a static JVM language (for performance), which allows me to avoid writing tons of boilerplate and “syntactical noise”. Scala seemed to be much more difficult than Java at first, but when I saw that the “difficult parts” were actually in the library and not part of the language, I realized that it is actually simpler. I like functional languages, but after having done the Z-machine in Erlang, using a object-oriented language to implement a VM feels more natural to me.

The emulator is still in its early stages and I do not know how fast I will progress. However, I wanted to share some details of my current design, that might be useful to anyone who is trying to implement an Amiga.

The Amiga is the most fascinating computer system ever created. That’s why I am trying to implement it in software. You might think differently, but ask yourself: can you think of any other system that was years (released in 1985) ahead of its competition and yet those competitors slowly incorporated all of its features and eventually surpassed it in the nineties. I have a feeling that if the Amiga would have been an Apple brand, it would have probably been much more successful, but then, the competition would also have tried harder to catch up quicker. The way the Amiga was marketed, it did not really pose a threat to the established competition. That’s sad, but there are lessons to learn from that. We see everyday that technological excellence is not everything, and great marketing and business development can make up for not having the best product.

I digressed. I actually wanted to show the current system design of my emulator. Here is an UML diagram of it:

Current System Design

I like to keep it simple and my approach for this project is to only add new components when it seems to be necessary. On ZMPP I admittedly got a little overboard and created more classes than I actually wanted to, which has to do with the TDD approach I took and especially my inexperience with TDD when I started ZMPP. This time, I did not use TDD (I did use a couple of unit tests to enhance my confidence on some tricky parts, though), but entirely focussed on understanding the problem and keeping it simple.

As you can see, this is currently a CPU and an address space which maps to the various system components.The Amiga uses memory-mapped I/O, and one of the most important concepts I had to learn as a non-Hardware person was “incomplete address decoding”. As I have documented in the diagram, some system components respond outside of the documented addresses (e.g. Chip Memory if you have less than 1 MB and the Custom Chips). You could learn this by looking at UAE’s memory map, but I actually found out by looking at a disassembled Amiga Exec. Finding the disassembled (and commented !) Exec source code was almost like having found the Rosetta Stone for me and I am grateful to Markus Wandel (I noticed that a lot of Amiga fans seem to be german !) for doing this hard work. So far, this has been one of my most important tools (besides the Hardware Reference Manual). I just kind of progressed by stepping through the ROM listing. I currently reached a point where I am outside of the commented part (probably dos.library and graphics.library). Getting this far gives me some confidence that my CPU emulation seems to work pretty well and that my memory mappings are working.

Some time ago, I purchased the Cloanto DVD set: “Amiga Forever”. Looking at the videos, I am fascinated by the passion, enthusiasm and the incredible skill that the original Amiga team had and I am inspired by that. Reading through the Amiga OS assembly code is an exciting experience as well. This is the beginning of a wonderful journey into computing history, and into the internals of a computer system that is unlike any other that has come before or after it.

Emulating the Motorola 68000 on the JVM

I am currently trying to write an emulator for the Amiga, which is powered by a Motorola 68000 CPU. I initially started in C++, but switched to the JVM, for various reasons:

• development on the JVM is much faster than in C++ and the performance penalty might be acceptable here compared to other non-native platforms
• the license of the CPU emulation library I used was not flexible enough for me

I actually expected that I would find a suitable M68K emulation library for Java, but there seemed to be nothing that really fit my requirements. Because there is at least one person with a strong need for such a library (me), I decided to create one myself with the main goals:

• very liberal license (BSD)
• fast and simple to use
• easy to maintain

I have created that project on Sourceforge, and did my first checkin today.

There are no released files and the source is available in a git repository. It is basically a generator written in Ruby with a database containing information about the instructions (decoding, timing, output, execution), which is mostly defined as Ruby hashes. This approach is inspired by the emulation libraries as they are found in UAE or Musashi. The advantage is that the step for decoding the instruction is replaced by a simple lookup in an array, so that the CPU only has to evaluate the parameters and execute the instruction.

Execution times (which are necessary for my emulation) are also mostly pre-calulated: Because addressing modes are available at generation time, the generator can simply calculate the number from the timing database and put it in the generated source code. There are only a couple of exceptions, which are related to conditional execution (e.g. Bcc, Dbcc, privileged instructions…)

Another nice feature is that the decoded instruction objects “know” how to print themselves, which can be used to disassemble sections of code. This feature is optional, because it makes the code much larger.

With a generator approach I also can reduce one of my main pain points with the Java language: boilerplate. Writing tons of structurally similar code would tire me out and I’d be exhausted (and bored to death) before I actually write my Amiga emulator.

Currently the emulation can emulate 58 of the 76 instructions and I am adding a couple each day. There is some exception handling and support for traps and supervisor mode, and interrupts will be added shortly (because I need them).

I love the 68000 CPU, I really do. I am not a hardware expert, but I think, when it was released (1979), this processor must have been quite revolutionary. I just love how easy it was to program it (assembly code that did not make you go “cuckoo”), with a flat 24 bit address space and working in 32 bit internally. It’s nice that this project gives me an opportunity to study its design and history.

It is my hope that other people find this emulator useful in some way, I have tried to provide some help to make it easy to integrate in projects (maven build, example program, simple public interface).