Difference between revisions of "Sxgo"
From Just in Time
| Line 7: | Line 7: | ||
| + | ==Features== | ||
| + | ===supported=== | ||
| + | * 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 | ||
| + | * Output panel | ||
| + | * and much, much more... | ||
== Support == | == Support == | ||
| − | 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. | + | 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 [http://www.python.org/ 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. | ||
| + | |||
| + | <pre> | ||
| + | # simple test script that runs the thermostat firmware, simulates some input and | ||
| + | # writes the program output to screen. | ||
| + | |||
| + | import sys | ||
| + | import pysix | ||
| + | |||
| + | # load a listing file | ||
| + | listing = pysix.ParseListingFile("../../test/thermostat.lst") | ||
| + | |||
| + | # create an emulator | ||
| + | sx = pysix.Simulator() | ||
| + | |||
| + | # load the listings program bytes into the sx rom | ||
| + | sx.load_rom( listing) | ||
| + | |||
| + | # some code labels | ||
| + | send_byte = 0x0405 | ||
| + | after_spi_read = 0x0141 | ||
| + | |||
| + | #some data labels | ||
| + | spi_value = 0x08 | ||
| + | |||
| + | # the entry point to the send_byte function. At this | ||
| + | # point w will contain a character to be sent to output (LCD/rs-232) | ||
| + | sx.set_breakpoint( send_byte) | ||
| + | |||
| + | # right after a temperature has been read from the spi device | ||
| + | # ram location spi_value will contain the temperature reading. | ||
| + | sx.set_breakpoint( after_spi_read) | ||
| + | |||
| + | while True: | ||
| + | sx.run(10000) # do 10 000 instructions, or stop if we hit a breakpoint | ||
| + | |||
| + | if send_byte == sx.state.pc: | ||
| + | sys.stdout.write( chr(sx.state.w)) | ||
| + | |||
| + | elif after_spi_read == sx.state.pc: | ||
| + | # Todo: simplify this. state can only be copied as a whole, not changed | ||
| + | state = sx.state | ||
| + | state.ram.set_absolute( spi_value, 100) | ||
| + | state.ram.set_absolute( spi_value + 1, 0) | ||
| + | sx.state = state | ||
| + | |||
| + | |||
| + | </pre> | ||
== The sources == | == The sources == | ||
Revision as of 23:33, 28 June 2009
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 limited in it's functions 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.
Features
supported
- 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
- Output panel
- and much, much more...
Support
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.
# simple test script that runs the thermostat firmware, simulates some input and
# writes the program output to screen.
import sys
import pysix
# load a listing file
listing = pysix.ParseListingFile("../../test/thermostat.lst")
# create an emulator
sx = pysix.Simulator()
# load the listings program bytes into the sx rom
sx.load_rom( listing)
# some code labels
send_byte = 0x0405
after_spi_read = 0x0141
#some data labels
spi_value = 0x08
# the entry point to the send_byte function. At this
# point w will contain a character to be sent to output (LCD/rs-232)
sx.set_breakpoint( send_byte)
# right after a temperature has been read from the spi device
# ram location spi_value will contain the temperature reading.
sx.set_breakpoint( after_spi_read)
while True:
sx.run(10000) # do 10 000 instructions, or stop if we hit a breakpoint
if send_byte == sx.state.pc:
sys.stdout.write( chr(sx.state.w))
elif after_spi_read == sx.state.pc:
# Todo: simplify this. state can only be copied as a whole, not changed
state = sx.state
state.ram.set_absolute( spi_value, 100)
state.ram.set_absolute( spi_value + 1, 0)
sx.state = state
The sources
I will release the sources to this program, I promise. It's just that I need things cleaned up a little (mainly adding license information and big fat disclaimers to all the source-files). I intend to release the whole source 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 dispatcher is convoluted and requires unhealthy amounts of caffeine to comprehend, and 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.