2011 was a slow Emumiga year, but I have the feeling 2012 is going to be better. The C++ version is catching up to the former C version and that makes it a lot more exciting to work with, breaking new ground again.

It is also inspiring to see a similar project gain momentum: Vamos by Chris “Lallafa” Vogelgsang. Keep it up Chris! That is cool stuff! I am impressed of how far it has already got in running real applications.

And thank you all for comments in forums and sending mails to me. Your cheers and positive words are truly helpful.

I’ve done some small work on the code base since last post. I’m adding symbol handling to be able to debug virtual memory references.

Finally some visible lifesigns with the new C++ codebase!

And, as promised: the source code. Fetch it from the download page.

Perhaps not very useful yet. But it is at least an example of how you can implement a library in C++ for AROS.

Things are starting to fall into place. I have prepared for dynamically loadable modules. The abstraction is in place but does not yet do any dynamic loading, but it will be straightforward when time comes for this.

First module out is the internal module that controls the bootstrapping procedure when starting an emulated process. The second module is exec.library. I’ve started with reimplementing the call hooks. OpenLibrary will just use the module system to find the correct library module. Certain things just become lovely with OOP.

This can be done by creating the file /usr/share/X11/xorg.conf.d/05-backingstore.conf and putting this into it:

Section "Device"
        Identifier "Default device"
        Option "Backingstore"
EndSection

This works for my Ubuntu running inside a VirtualBox machine. If you are running Linux natively, you will probably want to edit the Device configuration for your detected graphics card. The important thing is to add the option line for backingstore.

Here is a list of the extra packets I had to install to build AROS: automake, bison, flex, netpbm, libx11-dev and gcc-multilib. I also installed GIT as I’m using this for Emumiga development.

The reason for gcc-multilib is a bit tricky. I stumbled upon an Ubuntu bug (#778047). I got this error when building AROS: “include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory”. Installing gcc-multilib fixes this.

Not much done lately. I’ve been occupied with other things, mainly my work.

I’m upgrading my build environment. I used a somewhat old Debian Lenny system as base for the development, but I want to set up a newer one. Running Debian Squeeze now, but I have some problems with it so I will probably install Ubuntu eventually. Upgraded to a more recent AROS codebase too, and I was positively surprised that it builds real cross compilers in the standard source package now. It used to be a contrib thing to get these. Thumbs up!

Emumiga starts up again and runs the special exit instruction to quit.

I’m considering some kind of plugin system so support of libraries and devices can be added without requiring a recompile of all code. The question is, should I put them in their own libraries (load a library to emulate a library), or is it enough to LoadSeg() the plugins and just call the first address for it to set itself up? These things will not be shared so I guess a library is overkill.

The cpu emulation is converted to C++, and I’m working on the memory system. It is not too far left to the first checkpoint, that the emulator fires up, runs a couple of instructions, and then quit with a RTS instruction.