From Just in Time

Sxgo screenshot.png

sxgo is my C++-based, soon-to-be open source SX28 emulator.

I'm developing this emulator for my private purposes (mainly testing complex SX assembly projects before doing a burn-and-watch-the-leds-blink-cycle). The emulator is quite spartan and certainly not as versatile as the already existing and excellent sxsim for windows. In its simplicity, it's got two advantages though:

  • It is portable (I develop on Windows and Ubuntu Linux and have it running on both)
  • It is fast. On my 2.66 Ghz machine it runs at about 70 MIPS. Close to real time for most SX projects.



  • breakpoints
  • single step
  • run freely mode (which is interruptable from the UI)
  • ram window
  • watch window
  • Outline window, showing clickable code labels

not supported

  • anything but the SX28
  • the option to map the W register onto address 0
  • input/output panel
  • wakeup/brownout
  • any of the "undocumented instructions"
  • and much, much more...


The GUI is quite rough around the edges and it's probably going to be quite easy to break this program. Test coverage has been limited to the listings that I write myself. This means that:

  • the simulator could crash
  • there may be a bug in some of the sx instruction implementations. Getting the correct Carry-flag behaviour has proven to be interesting, to say the least.


Ah. There's one catch: No guarantees. I could drop this project tomorrow. My dabbling in SXes is pure hobby-work and although I'm a professional programmer, this particular program is just an exercise on the side.

Python module

Sxgo comes with a python module, that allows a programmer to create extensive test-scripts. This feature is one that I'm currently putting much effort into, since complex SX firmwares tend to need some automated testing and python scripts are a very convenient way to do such a thing.

I have made no provisions to install this module into a python environment, since python is one of those areas that I have actually very little experience with. I believe though, that simply copying the module (.pyd file for windows, .so file for linux) to the right location (python scripts directory) should probably do the trick. I myself always use the module in the same directory as the test-scripts and that seems to work too...

Currently, the python module and the emulator GUI are completely separate programs: you can either write a python script to run your SX listings in or watch them in the GUI, not both.

As a teaser, here's a python script that runs a specific SX assembly program (one that reads a SPI temperature sensor and outputs the temperature to a serial port as ascii text). The script breaks the program execution to insert 'simulated' inputs and to retreive the outputs and write them to the PC console output.

I've created another page with some documentation of the python module

The sources

The sources are available through this link. It is released under the boost license, which is a 'BSD-like' non-viral open source license. See also this explanation.

But I have to warn anybody that is interested in the sources beforehand: If you think that C++ templates are evil, you won't like reading the sources. Even I think that the current implementation of the instruction decoder is convoluted and requires unhealthy amounts of caffeine to comprehend.

Since I originally intended this program for my personal use only, the source code documentation (comments) are only there to get me started on the project again after a month of real work.


Getting this to build on your system may be quite complex. At the least you will need:

  • Cmake as a cross platform make (I'm using 2.6) [1]
  • WxWidgets for the UI (I'm using version 2.8.10) [2]
  • The Boost C++ Libraries for boost.python, boost.mpl and much more (1.39, but any fairly recent version should do) [3]

For compilers I use:

  • Visual C++ 9.0 Express edition on Windows [4]. It's important to note that there is a problem with the 'redistributables' for this version of the compiler: the provided manifest shows a different version number than what the generated executables or dlls require. See this bug report (and I won't comment on MS's handling of this particular one)
  • G++ (4.3? need to check) on Linux. This is the one that is installed by default on Ubuntu Linux 9.04