GitHub

After re-designing and re-engineering the CPU core I've now separated the 680x0 emulation into it's own project and I'm now using GitHub for hosting:

https://github.com/tonyheadford/m68k

This has taken a while although mostly because I've been too busy with other things to work on this. At one point I went up a blind alley writing code generation scripts in Ruby for a different approach to try and maximise speed (minimizing conditional code in the fetch and execute loop) and to further my Ruby skills, but it turned out to generate just too much code and made it unwieldy for both maintenance and my poor IDE.

It's quite exciting to be at a point where I can get back into the Amiga emulation.

Building the core

I've completed the CPU code re-engineering and I'm currently putting together a disassembler so that I can debug the new CPU. Once I've got this together I'll build a simple monitor/debugger and start running some tests to ensure the CPU instructions all function as they should. It's all rather monotonous at the moment so I'll spare you the details, but I just wanted to let you know that work is continuing, there's just not a lot to show at the moment.

Breakout

I am really enjoying getting back into the code. I've decided to bring all of the individual operation classes into the CPU class and make them inner classes. Lots of reasons for this but to me it just seems to be more logical for the individual instruction methods to access the internals of the CPU directly rather than through some static reference and public methods. This also means I'm removing tons of classes that helped with the previous abstraction and have adopted some simpler ways of decoding opcodes etc.

What this will lead to I hope is a much smaller and cleaner code base with no unnecessary coupling and a nice clean interface. With a bit of luck the performance might be better too, but I'm not really worried about that at the moment.
I am now thinking of creating a new project for the 68k CPU and hosting it on google code or github with a monitor/debugger/disassembler (and perhaps an assembler too) but separate from the Miggy project.

Once this is done I'll then return to Miggy and build it using this CPU core.
Thoughts anyone ?

Back in the saddle

Woooah where did 2009 go ?

I've recently been having huge urges to get back on with this little project and I decided to go grab the code again and begin trying to find time to do some more.
Amazing how a little time makes you look at things differently. I've only just started nosing through the code again and plenty of "what was I thinking!" thoughts are appearing.
I've decided to switch to Eclipse to continue developing Miggy. I've switched full-time to my MacBook Pro now and my beloved IntelliJ isn't behaving itself properly on Snow Leopard. I can't afford or justify the upgrade to the latest version when there's free tools around that should be up to the job. I say "should be" because my previous attempts at using Eclipse have ended in plenty of swearing and its swift removal from my hard-drive. But that was a long time ago and I'm a forgiving soul/sucker for punishment.

My first thoughts are I should really get the core 68k emulation done and dusted as a separate module. I think it's there or there abouts already but I've found loads of dependencies and coupling that really shouldn't be in there, so I want to clean it up. This will certainly help me get back in the saddle with the code too.

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.