DMPP Cymus – CIA emulation library

Now that I have a somewhat working M68000 emulation, I can finally focus on the rest of the Amiga system. Currently most of the system is stubbed out with a couple of dummy functions so I can see when something interesting happens.

I have reached now reached a point, where I can’t fake out the CIA functionality anymore, because the Amiga OS tries to use the timers and the TOD (Time-of-Day clock). Apropos TOD – in german the word “TOD” means “death”, so using that abbreviation in the source code gives me the shivers. In UAE’s CIA source code, I even found the words “TOD Hack” – which sounds to me like “chop to death” – (brrr ! horrible !).

However, I’ll stick with that word since “tz” (for “Tageszeit”) does not seem to be any better. I grabbed the MOS CIA 6526 datasheet linked from the Wikipedia article and the information from the Amiga HRM. As an additional reference, I am also looking into the CIA implementation of the MAME project (as I have done for the M68000 implementation). MAME  is a pretty large project, but from what I have seen so far, I really like the overall code quality and the CIA implementation is no exception.

From the combined information, I created a first class design:

 

I find creating UML diagrams during software development very useful. I can verify and review the software design on different levels. When designing, I first create a rough draft and then try to verify it with a prototype (usually written in Ruby or Python) to get quick feedback, so I can feel how well it works. I then iterate a couple of times until the design seems to meet the requirements.

A while ago, I had created the project “Dream Machine Preservation Project”, which I currently use as an incubator to experiment with a couple of ideas, which will hopefully one day lead to a full Amiga emulation.

The CIA library is the first thing I checked into the public git repository on Sourceforge. The implementation is still incomplete, because features are added as they are needed in the Amiga emulator. It was originally written in Scala, but when I decided to make a separate library out of it, I changed the implementation language to Java. This was mainly because I did not want to force users of the CIA library (assuming that there could be someone else besides me) to have to add the Scala library or having to know Scala in order to compile it.

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.