To check out the latest development tree, type:
svn co https://gxemul.svn.sourceforge.net/svnroot/gxemul/gxemul/trunk gxemul [August 2014: This seems to be down these days...]
(The parts of the documentation that is built by make documentation, which includes both the Doxygen source code comments and documentation about the new machine modes and components, is not stored in SVN.)
Some recent news
 Release 0.6.0.1. It has been a while since the last release, and the SVN repository mirror at Sourceforge seems to be broken, so it felt reasonable to package the current code into a patch release. Not much has happened feature-wise since 0.6.0.
 On FreeBSD/amd64 with GCC 4.2.1 as the default compiler, you may need to install GCC 4.8.4 and run the configure script like this to avoid triggering a bug in the default compiler:
CXX=c++48 CXXFLAGS=-Wl,-rpath,/usr/local/lib/gcc48 ./configure
 Not much coding lately. The only thing worth mentioning is that the Dreamcast emulation mode now gets further when running Marcus Comstedt's test programs, and also shows "something" when booting the PROM from my real Dreamcast. (This was in the legacy Dreamcast mode, for fun. I haven't had time to work on the new framework at all.)
 Uploaded a clip to YouTube, showing the NetBSD/pmax install procedure in GXemul.
 Release 0.6.0. Even though almost nothing is reimplemented in the new framework, it's probably best to get an early release out the door.
 An important milestone for the framework rewrite has been reached: the testm88k rectangle drawing demo runs :-) The output can be seen by breaking into the debugger, and dumping the emulated framebuffer memory.
 Continuing on the new translation system (page allocation etc). The things to do next are slow/fallback implementations of M88K loads/stores, and more branch instructions. Hopefully this will lead to a working "rectangle drawing demo" for the new testm88k machine, although with no graphical output.
 No coding lately, but I've added a check for valgrind in the configure script, so that it is used during 'make test' if available. Any output from valgrind -q is interpreted as a test failure.
 Over the last few days, I've finally begun to merge the old abandoned C++ rewrite (which was supposed to become 0.5.x) into the legacy C code. The code in SVN trunk right now is thus a mix of both branches. If everything goes as planned, GXemul 0.6.0 will be released when something in the new C++ framework works. I will try to concentrate on MVME187 emulation. Most emulation modes, however, will use the old C framework.
 Finally took the time to learn how the new SVN repository migration stuff works at SourceForge.
 Release 0.4.7.2. Mostly documentation updates (new NetBSD, OpenBSD, and HelenOS releases). GXemul's official homepage is now moved to SourceForge: http://gxemul.sourceforge.net/
 Copying back the 0.4 tree into the trunk. Because of issues regarding the amount of available spare time, 0.5.x (the C++ rewrite) could never be realized. (The SourceForge SVN repository is not up to date; I haven't figured out yet how to upload the repository after the last changes SF have made to their system, so release tarballs will have to do for now.)
 Release 0.4.7.1. Some more M88K instructions have been implemented, and NetBSD/hpcmips can now be run using serial console (in addition to graphical framebuffer, which was the only choice before).
 Not much actual coding lately, but I've now finally decided (again :-) that 0.5.x will not contain any legacy code. It would simply be too much to support, and there would be too many ugly hacks. Removing lots of old stuff. The 0.4.x releases will of course still be available for users who need those modes/features. Hopefully this time will be final, and I'll not change my mind again. :-)
 Updating the TODO file to include stuff from the TODO file in the old C++ branch.
 To work on the new framework, I need to choose a suitable machine to try to implement. I think I'll concentrate on mvme187 first, since it is the only M88K machine in the emulator so far. In other words, most of the other (legacy) modes will not be affected too much.
 Merging in the rest of the old C++ branch into the main trunk, except the graphical UI. (I'll not include it in 0.5.0, but perhaps later.) In other words: it is currently not possible to emulate anything with the code in the main trunk.
 Starting to slowly merge in some infrastructural stuff (build related) from the C++ branch. I have not merged over any actual C++ code, though, so the Doxygen documentation is pretty boring.
 Release 0.4.7. Apparently the gcc warning is a bug in gcc, not in the emulator.
 Some more bugs found and fixed. A default OpenBSD/mvme88k install is now down to 10-13 minutes, approximately. One of the remaining bugs now is triggered by self-compilation inside OpenBSD in the emulator:
cc -Wall -fstrict-aliasing -fomit-frame-pointer -fpeephole -O3 -DNDEBUG -I../include/ -c cpu.c cpu.c: In function `cpu_show_cycles': cpu.c:405: warning: `mseconds' might be used uninitialized in this functionwhich is impossible. However, the resulting binary from self-compilation seems to work.
 FINALLY made enough progress on the osiop for OpenBSD/mvme88k to accept it. After the osiop fixes, and a couple of other things (implementing some more floating point instruction variants), OpenBSD can now be installed onto a disk image on an emulated MVME187. An expect script running a default install takes about 31-34 minutes on my main machine, which is horribly slow. It will need to be optimized later on. Self-compilation (compiling GXemul 0.4.6.6 inside OpenBSD inside the emulator) works, it takes about 30 minutes. There are some bugs left, but overall, I am quite pleased with the progress.
 Current plan for the next release is to try to implement enough of the osiop SCSI controller (NCR 53C710) to make OpenBSD/mvme88k able to install onto a disk image. If this succeeds, and if self-compilation inside the emulated environment works, it will be released as 0.4.7.
 Cut-and-pasted together some old news entries, from the beginning of GXemul's history.
 Significant milestone reached regarding 88K emulation: an OpenBSD/mvme88k ramdisk kernel boots all the way to an interactive shell :-)
 FINALLY found (and fixed) the M88K bug I've been looking for lately. Conditional branch instructions with delay slots incorrectly emulated the delayed branch target, in the case the branch was not taken and there was an exception in the delay slot, e.g. due to a page fault. With r2 = 0:
u00001074: eda20005 bcnd.n ne0,r2,0x00001088 u00001078: 244da000 (d) st r2,r13,0xa000 ; [0x0013a000] = 0x00000000 [ EXCEPTION 0x003: DATA_ACCESS ] [ DMT0: Big-Endian, User, store, bytebits=0xf ] [ DMD0: 0x00000000; DMA0: 0x0013a000 ] [ DMT1: not valid ] GXemul> r,0 cpu0: PID=0x00000007 PSR=0x800003fb EPSR=0x000003f0 SSBR=0x00000000 cpu0: SXIP=0x0000107a SNIP=0x0000108a SFIP=0x0000108e VBR=0x00000000The exception is as expected (a page fault), but SNIP and SFIP which define the next two instructions should be 0x107e and 0x1082 (for the addresses 0x107c and 0x1080, respectively), because r2 was zero. :-) After fixing this, OpenBSD/mvme88k runs a lot further. There is no serial console output yet from userland, but I am assuming this is because of lack of TX interrupts. I'll look into this next.
 Some progress on M88K emulation (some bug fixes, implementation of the pcc2, the M88K cpu interrupt mechanism seems to work now, and some more 88100 instructions have been implemented). OpenBSD/mvme88k receives timer interrupts from the pcc2. "Something" executes in userland, but seems to restart over and over again.
 Release 0.4.6.6.
 Moving away the experimental "0.5.x" C++ code into a branch, and moving back gxemul-legacy/trunk to become just gxemul/trunk. In other words, I'm picking up 0.4.x again. So, from now on,
 Updating the gxemul-legacy documentation regarding OpenBSD/landisk. (From 4.2 to 4.4.)
 After thinking a bit about GXemul development, I think I have come to the following realisation: since I do not have that much spare time anymore, and I have other projects to work on too, it seems that the complete rewrite of GXemul (0.5.x) will never happen. It would take a lot of time to reimplement 0.4.x's features if I worked on this full-time, and when I barely have time to work on it at all, well, it will take forever. So, I might ditch the current 0.5.x tree, and instead slowly continue working on 0.4.x. This will not mean that I get more time to work on the emulator, but maybe there can be some more meaningful 0.4.x releases.
 According to http://bsdimp.blogspot.com/2008/10/gxemul-update.html: "Oleksandr Tymoshenko posted a patch to gxemul that allows FreeBSD/mips to boot on it".
 Applying a patch from Kiyotaka Inaba (to the gxemul-legacy tree) which causes an ARM UND exception (undefined opcode) to be generated whenever the emulator runs into the instruction word 0xe6000011. GDB apparently uses this as a break-point opcode.
 Importing the old CVS repository, approximately 5000 commits, into SVN (using cvs2svn). You can browse the gxemul-legacy tree here:
 The ARM emulation in the 0.4.6.5 release seems to be quite stable. I've been able to build quite a lot of packages inside emulated NetBSD/cats, which can then be run on a physical NetBSD/hpcarm.
 Release 0.4.6.5, since 0.4.6.4 contained an incorrect fix.
 Oops. The bug fix in 0.4.x for ARM pc-relative loads was incorrect. After fixing it, and playing around with some other stuff, NetBSD/hpcarm (Jornada 720) kernels now print some boot messages again.
 Release 0.4.6.4, containing two ARM fixes: one fix for a corner case for PC-relative loads, which wasn't implemented correctly before, and a patch to implement the bkpt instruction (by Jiri Svoboda).
 There's now a "dirty flag", which the UI can use to detect whether or not to ask for confirmation before quitting etc. Screenshot showing the Swedish translation:
 Here is a screenshot of what the GUI looks like at this point in time. The lower part of the main window contains a "debug console", which should be equivalent to running GXemul in non-GUI mode. The upper part consists of a design area (which so far shows dummy blue circles instead of actual components), and a palette to the right, from which the user will be able to drag-and-drop components into the design area.
 Lately, I've been working a bit on the GUI, on file loading (ELFs can be loaded now, but no symbols or anything fancy yet), and today I added support for "methods" on components. I also removed the "tree" command; simply executing a component with no method name will show a tree now. Method names are automagically completed as well, so "cpu.u" is equivalent to typing "root.machine0.mainbus0.cpu0.unassemble" etc.:
 Experimenting with xgettext and msgfmt to implement I18N/L10N support. Swedish is the only implemented translation so far. It seems to work (although it requires a make install, it is not (currently) possible to run with translation when not installing GXemul).
 Obviously 0xffffffffbfc00000 is wrong; the physical address is 0x1fc00000.
 Continuing on bus-related things; the MIPS CPU (or in fact, any CPU) will now read instructions via an AddressDataBus. In practice, this will either be an L1 cache, which would be an immediate child component to the CPU, or it will be a bus, which will be a parent component of the CPU. In the basic testmips machine case, it is a MainbusComponent. A RAMComponent is then connected to the mainbus:
[testmips] \-- mainbus0 |-- ram0 (32 MB at offset 0) |-- rom0 (32 MB at offset 0xffffffffbfc00000) \-- mips_cpu0 (100 MHz)
 Working on the RAMComponent and related stuff.
 The source code is now also available via anonymous SVN checkout (svn co https://gxemul.svn.sourceforge.net/svnroot/gxemul/gxemul/trunk gxemul), and browsable online via SourceForge (https://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/). Traditional .tar.gz snapshots are still built, though.
 There's now a channel on FreeNode for GXemul, called #GXemul. So far, I'm the only one around :-) but feel free to join. The mailing-lists gxemul-devel (for anything related to the development of GXemul) and gxemul-users (user questions) at https://sourceforge.net/mail/?group_id=191414 should also theoretically work now, but I am not receiving my own mails, so something is a bit fishy. But it almost seems to work.
 Thinking about how the IR (intermediate representation) stuff should work in the new version: I'll probably use simple and traditional interpretation by default (read an instruction from emulated memory, decode it, and execute it), and only let native code generation via some form of IR kick in when necessary. Two advantages: it will be easier to quickly add new cpu types (because an interpretation switch/case block is very easy to comprehend, compared to e.g. the dyntrans system in GXemul 0.4.x), and there will be no waste of memory (for IR data) for code which is not commonly used. I will try it, and see how it feels, implementation-wise and performance-wise.
 Release 0.4.6.3; the experimental disk device used in the test machines can now access disk images larger than 4 GBs when emulating 32-bit architectures (as suggested by Julian Elischer).
 The latest FreeBSD quarterly report mentions GXemul. It's nice that the emulator can be used like this.
 0.5.0 development: Lists of available template machines and components are now automagically built as HTML documentation. For the stable release, when it is ready, only machines and components marked as stable will be included in the documentation.
 Release 0.4.6.2, containing a fix for the WDC device from Oleksandr Tymoshenko.
 The rewrite (what will become GXemul 0.5.0) is slowly moving forward. Nothing is emulated yet, though. It is possible to start a dummy emulation using a "template" machine, e.g. -E testmips, so from a user's perspective it works like in GXemul 0.4.x. Loading and saving the emulation setup (the component tree) works too, including full state. Full state at the moment means pretty much nothing :) since all components are dummy. Interactively adding and removing components in the emulation setup, and undo/redo using the ActionStack also work. By the way, the ActionStack source code is a reasonable example of how I am implementing unit tests.
 Updating the home page so that the current development version is easily accessible, next to the stable/legacy (0.4.x) version. On the 13th of December, I decided to not slowly convert the code to C++, but to really restart from scratch. That's what I did. So far, I have written some simple infrastructural classes to get started (the Component is probably the most central of them), and spent some time writing unit tests and Doxygen comments.
 Release 0.4.6.1. Mostly minor documentation updates, compared to 0.4.6.
 Branching the development tree; a 0.4.6.1 branch will be used for the upcoming release. In the main trunk, I'm going to play around with more experimental stuff -- rewriting the code from C to C++. Many parts of the code are more or less object orientedly written already, but going to C++ will be an interesting thing to do. I hope it will be worth it. Note that snapshots are built from the main trunk.
 OpenBSD/landisk 4.2 seems to work fine in GXemul. Once NetBSD 4.0 has been finally released, I will make a 0.4.6.1 release with updated guest OS installation instructions.
For anyone attempting to run Sprite
in GXemul, the Sprite harddisk image has been moved to a new URL:
 It feels like it is time to get back to GXemul development. I have not had much time for it lately. NetBSD 4.0 RC1 was announced a few days ago, and doing installation regression tests of NetBSD 4 for all emulated platforms is probably a good way to start again.
 GXemul is 4 years old today. :-) [full HISTORY]
 Release 0.4.6. NetBSD/pmppc now boots without timeouts.
 NetBSD/pmppc almost works in the emulator, when using root-on-nfs. There are lots of annoying timeouts, perhaps a problem with the DEC21143 NIC, or, more likely, a problem with interrupts in the PM/PPC machine.
 After fixing the behavior of M88K memory fault exceptions in branch delay slots, OpenBSD/mvme88k seems to run more of /sbin/init, and then it starts idling in cpu_switch, waiting for interrupts (which are not implemented yet). Small steps in the right direction. :-)
 More M88K progress; OpenBSD/mvme88k reaches userland, /sbin/init starts executing and even makes a few syscalls :-), before it crashes.
 Some more M88K progress. OpenBSD/mvme88k prints its first boot messages:
CPU0 is associated to 2 MC88200 CMMUs Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1 (RAMDISK) #5: Mon Mar 12 13:27:07 GMT 2007 email@example.com:/usr/src/sys/arch/mvme88k/compile/RAMDISK real mem = 67108864 avail mem = 53121024 (12969 pages) using 844 buffers containing 3457024 bytes of memory mainbus0 (root): Motorola MVME187, 33MHz cpu0: M88100 rev 0x3, 2 CMMU cpu0: unknown CMMU id 0x0 rev 0x0, full Icache, unknown CMMU id 0x0 rev 0x0, full Dcache pcctwo0 at mainbus0 addr 0xfff00000: rev 0 nvram0 at pcctwo0 offset 0xc0000: MK48T08 cl0 at pcctwo0 offset 0x45000 ipl 3: console
 A big thank you to Miod Vallat, for sending me M88K manuals. I've now implemented enough instructions to let the rectangle drawing demo run for testm88k. :)
 I have recently become more and more interested in learning about the M88K architecture. If I get enough spare time, I will try to implement the M88K ISA and one or more corresponding machine modes.
(Even older news entries can be found here.)
Curiosities / historyAs far as I am aware, GXemul was the first emulator released as Free Software capable of running unmodified MIPS-targeted unix-like operating systems, such as a default NetBSD installation. (Compare this to e.g. Stanford University's SimOS, which was capable of running a specific modified version of IRIX.)
In the early days of the emulator, the name was mips64emul. I thought this made sense, because it was a 64-bit MIPS emulator. However, it didn't take long to realize that the MIPS naming scheme was more complex than that. (MIPS64 is a specific ISA, but also earlier ISAs such as MIPS III and IV were 64-bit.)
Here are some old screenshots that might be fun to see:
I had an x86 emulation mode for a while. It was a really quick hack, using
simple instruction interpretation only (this was before the dyntrans system was
in place) so it was awfully slow. However, it was fun to experiment with.
One of the screenshots above shows a "copper bars" demo running in an
experimental version of GXemul compared to
Bochs; the VGA device had to
be able to switch palette color for individual scanlines, something which
Bochs didn't take into account (causing the whole background to change
color, all over the screen).
Another fun thing was the ability to emulate the SGI O2's graphic
controller, well enough to let a raw PROM image boot and draw some
graphics. (Broke somewhere before 0.4.0.)