Difference between revisions of "Sxgo"

From Just in Time

m (fixing some stale links)
Line 73: Line 73:
* [ anouncement of another open source SX28 emulator] written in C, as early as 2005.
* [ anouncement of another open source SX28 emulator] written in C, as early as 2005.
* [ sxsim for windows].
* [ sxsim for windows].
* [ my announcement of sxgo in the parallax SX forum]
* [ my announcement of sxgo in the parallax SX forum]

Latest revision as of 23:20, 24 January 2015

the newly added color profiling feature

sxgo is my C++-based, 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, its 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 Mhz. Close to real time for most SX projects.
    • Actually, after a number of revisions, the performance of the python version (without all the GUI stuff) is 100+Mhz on a (my) modern PC.

The design is documented on another page.



  • breakpoints
  • single step
  • run freely mode (which is interruptable from the UI)
  • ram window
  • watch window
  • Outline window, showing clickable code labels
  • color profiling of running program. In the UI, during your code run, you can see which code is executed often. In the image at the top of this page you see darker green lines which are executed often, light green lines that are executed less often and white lines that haven't been executed for a while.
  • integration with python with the following exclusive features (additional to the features that the UI provides)
    • ram breakpoints (actually: have your python function called whenever the SX writes to a RAM address)
    • SX 'clusters' or having multiple SXes run on the same clock. Ideal for simulating communicating SX controllers.


  • ram breakpoints in UI.
  • 'undo'/step-back
  • saving and loading a full SX state in both python and the UI.

not supported yet

  • 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. In fact, I now (2013) haven't touched it in years. Since the SX is no longer in production I assume you don't mind...

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 retrieve 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 at GitHub. 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. 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.

I've started to document the design.


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) on Linux. This is the one that is installed by default on Ubuntu Linux 9.04