Running on Mac OS X

As I had a bit of time to kill this morning I thought I'd try running the speed test on my MacBook Pro.

At the moment I'm doing all of the development on my Windows XP box as that is my main machine at home and has a lovely 24" monitor attached to it. My Mac is my portable work machine and until I can afford a Mac Pro for home I have to use both XP and OS X.

Bear in mind that at the moment there are no "external" interrupts on the CPU as it's only executing the ROM code. There is no display, sound or DMA functionality at work here either, just the CPU reading and writing to memory and executing code.
Also bear in mind that this hasn't been optimised at all, other than removing the logging from the memory access code.

My Windows box is home built with an Intel Core 2 Quad @ 2.4Ghz and 3.5Gb RAM. It's running XP Pro SP3 and I'm using Java version 1.6.0_07 32-bit Client VM.

My Macbook is an Intel Core 2 Duo @ 2.5Ghz with 4Gb RAM. It's running OS X 10.5.5 with Java version 1.6.0_07 64-bit Server VM.

The Mac is running Miggy at a rather pleasing 85Mhz !

So, I think I'll carry on with the development for now and leave optimising until later as I think there's enough headroom there to emulate the other components. Time will tell.

Debugger Alpha

I thought I just make a quick post to show the GUI debugger I've been working on the last week or so. It's incomplete but working well enough to put a grin on my face while stepping through code.

A quick screenshot:



The disassembly syncs nicely with the Program Counter as you step through and registers are all editable in place too.
Still to do are breakpoints and the memory views alongside the registers.
Bananas all round to those who noticed that I've borrowed the layout from Devpac's MonAm debugger ;)

Swings and Roundabouts

I've spent the last week trying to get a GUI interactive debugger together for Miggy and have ended up bouncing all over the place.

The big pain is trying to fit the disassembly output into a list of some description so that a user can view the code, interactively step through it and set breakpoints etc. Out of the box the JTable and JList are not going to do it for me without some serious hacking about I think.

These list type controls are backed by a model class that supplies the actual data and information such as the number of available entries to the list. This in turn controls the scrollbar range and response once the list is embedded in a JScrollPane.

My issue is that without disassembling the whole of the available emulator memory I won't know how many entries will be available for the list. Each instruction can be comprised of as little as 2 bytes or upwards of 8.

What I want to do is only disassemble enough rows to fill the visible area of the list and control the scrolling so that I can effectively create a sliding window view over the emulator's memory. Perhaps the best route would be to either have a separate JScrollBar which I use to update the sliding window, or provide my own "up and down" buttons to control the view.

Actually that sounds like a plan, I can control the number of rows in the list so that they equal the number visible rows on display, and use input from a separate scrollbar or other control to change the sliding view of memory.

Blimey, writing this entry has actually helped clear this up a lot in my mind. A bit like when you explain a problem to a colleague only to realise the solution mid-explanation. If only I'd done this a couple of days ago ;)

Grinding out a result

A week since the last post, how time flies. I've been adding instruction emulation and some unit tests this week. Both rewarding and a bit tedious at times and I've not had quite as much time as I'd hoped this week so progress has been a bit slow, but it's moving in the right direction.

One of my goals in developing this project, was to give me the chance to play with some of the newer language features of Java. I learnt the Java ropes on versions 1.2 and 1.3 and did my certification back when Sun had just started calling it the "Java2 platform". Work hasn't afforded me any opportunity to explore the additions made in 1.5 and later.

Having a strong C and C++ background I thought I knew an enum when I saw one. How wrong could I be. A Java enum is so much more, and after realising their potential I've incorporated several into this project.

One of the key enums in Miggy is the DataSize enum. This has grown quite a bit since it's inception, as I'm finding it so useful. Here's a code snippet:

public enum DataSize

{

Nibble(0, 2, 0x000f,"", 0x0008, 4), Byte(1, 2, 0x00ff,".b", 0x0080, 8),

Word(2, 2, 0x0000ffff,".w",0x00008000, 16), Long(4, 4, 0xffffffff,".l",0x80000000, 32),

Unsized(0, 0,0,"",0, 0);

private final int readSize;

private final int byteSize;

private final int mask;

private final String ext;

private final int msb;

private final int bitSize;

DataSize(int byteSize, int readSize, int mask, String ext, int msb, int bitSize)

{

this.byteSize = byteSize;

this.readSize = readSize;

this.mask = mask;

this.ext = ext;

this.msb = msb;

this.bitSize = bitSize;

}

What this does is create an enum named DataSize that has the values Nibble, Byte, Word, Long and Unsized. However each of these values also has additional data associated with it, passed into the constructor. To keep it simple I haven't shown the accessor methods as they just return the private member variables.

You can probably tell what these extra data fields are by their names, but I'll run through them quickly:

• byteSize - number of bytes the value represents
• readSize - number of bytes read when used as addtional data for instruction decoding
• mask - bitmask used to extract data of this size
• ext - the extension used when disassembling instructions of this size
• msb - Most Significant Bit mask, used when determining if a signed value is positive or negative
• bitSize - the number of bits used in this data size. The same as byteSize multiplied by 8.

Using this enum has meant that I do not need loads of conditional code when emulating or disassembling instructions. Apart from making the code simpler and easier to read, it also means I'm able to write more generic code that can handle byte, word or long sized operations.

For example when disassembling an ADD instruction, each of the "sized" handlers can call a base class method passing a DataSize enum representing the size the instruction is working on.

From the ADD_b.java class which handles the byte sized ADD instruction:

public final DecodedInstruction disassemble(int address, int opcode)

{

return decode(address, opcode, DataSize.Byte);

}

This gives the ADD base class all the information it requires to decode and disasemble the instruction.

Disassembler v0.1

I've put the first code drop into the google project repository and thrown together a download containing the compiled jar and a couple of scripts to run the disassembler.

The code isn't pretty at the moment, there's very little in the way of comments and there are virtually no test cases.  I'm a bad man.  That will all change in due course but I was keen to actually get something out there.  I'm itching to start on the emulation code and the release of this milestone will enable me to make a start now.

The disassembler knows nothing of executable formats but seems quite happy to disassemble lumps of compiled 68000 code.  My test file of choice has been the Amiga Kickstart 1.3 ROM.

I'm sure there are bugs, if anyone decides to try it out, please let me know what you think and if you find any problems.

If you want to try it out, you can grab the binary release here

You'll need a recent Java runtime environment installed 1.5 or 6.

Extract the archive to a directory and run either the disasm.bat for Windows or disasm.sh for *nix:

disasm.sh [-b <address>][-o <file>] filename

-b address -> The base address to use for the disassembly output.

-o offset -> Byte offset into the file to start disassembling from.

Have fun.

Twist and Shout

I had a bit of a redesign after being rather unhappy in how messy things were becoming trying to handle the 10-bit masking and hashing, and the subsequent overlapping instruction handling that it required. I decided to add the responsibility of registering opcodes down to the individual instruction classes. This means they can correctly register for the range of opcodes they will handle in full 16-bit glory. It also means these are stored in a 16-bit look up table, directly indexed by the opcode itself. No hashing or maps required and no autoboxing of opcode values to store and retrieve the instruction classes.
The CPU instructions are all loaded dynamically via a configuration file too, so different 680x0 family processors or opcode implementations can be configured quickly.

Yay.

Apart from imminent RSI things have gone well. The disassembler is very nearly done, I'm debugging at the moment. I really want to add a lot more unit tests though, as in my coding frenzy I have been a bit lax in that department.
Once the debugging is complete and I'm happy it's disassembling correctly I'll post the code on the google code project and make a compiled version available too.

Double Yay.

Come back z80 ...

No, not really.  Many moons ago I wrote Gameboy emulator with a cut-down z80 CPU.  Although I never got as far as handling sound, everything else worked quite nicely.  I wrote it in C++ with the CPU core written in x86 assembler.  Thinking back now it seems an order of magnitude simpler than emulating a 68000 in Java.

The painful thing with the 68000 is that the instructions are complex.  Decoding the machine code isn't as simple or straight forward as something like a z80.  The 68000's instructions are all 16-bit words and decoding these is somewhat long winded.

The goal is to quickly identify each instruction so that it can be emulated as fast as possible without wasting precious time trying to determine which action to perform.  I also want to use the same determination algorithm for both the emulator and the disassembler.

I've settled on a scheme of using the 10 most significant bits of an instruction for identification.  This covers the majority of the instruction set and allows me to determine the size of the operation in most case (byte/word/long).  There are however a few special cases where more of the instruction needs to be used for qualification.

I want my core loop clean and envisage something like this simplified pseudo code:

while(running)

short opcode = readMemWord(reg_pc)

Instruction i = Instructions.get(opcode & 0xFFC0)

i.execute(opcode)

end while

I don't really want the mother of all switch statements in there, so I will use a hash collection of some sort, keyed against the 10 most significant bits of the opcode paired with an instance of the class that implements that particular instruction.  This allows me to write a class to handle each instruction and specialise it to handle different operation sizes too.

To facilitate this, I have an Instruction interface that these classes all implement that looks like this:

public interface Instruction

{

  public int execute(int opcode);

  public DecodedInstruction disassemble(int address, int opcode);

}

The disassembler will work in exactly the same way, except calling disassemble instead of execute.

The disassembler is about half done now.  Back to it.

In the beginning

Miggy has been conceived.

Last weekend, I finally sat down and attempted to start developing the Amiga emulator I've been itching to write for ages.  I already have a reasonable idea of how this is going to be architected - a pluggable API framework so the emulator can evolve - and I'm going to code it in Java.

I've set up a Google Code project to host it http://miggy.googlecode.com, although I doubt there will be anything there for a while.  This is my first open source project and I am planning on a "release often" stragedy to try and keep me going.

Work has started on a 68000 disassembler.