sxgo - simple but fast sx28 emulator
spiff
Posts: 15
Hello all,
In the past few years I felt the need to support my SX hobby-projects with a customizable sx28-emulator. Being a professional programmer--and therefore always prepared to reinvent the wheel
--I decided to start on my own emulator. By and by, this project has grown into something that may be more generally usable than just by me, so I hereby announce my pre-release version of "sxgo" (attached below).
Beware, this emulator is nowhere near as versatile as SXSim, it lacks many of the features that SXSim has and will probably never acquire those features. Still, it could be useful because of 2 interesting characteristics:
Attached is an installer for the windows version. Feel free to use this program. Suggestions for improvement are welcome, although my time to spend on this project is extremely limited, so don't expect any major new features appearing soon.
Kind Regards,
Danny.
In the past few years I felt the need to support my SX hobby-projects with a customizable sx28-emulator. Being a professional programmer--and therefore always prepared to reinvent the wheel
--I decided to start on my own emulator. By and by, this project has grown into something that may be more generally usable than just by me, so I hereby announce my pre-release version of "sxgo" (attached below).Beware, this emulator is nowhere near as versatile as SXSim, it lacks many of the features that SXSim has and will probably never acquire those features. Still, it could be useful because of 2 interesting characteristics:
- It's portable (I've built it, and am running it on Windows and on Ubuntu linux)
- It's fast. On my 2.6 Ghz PC it runs near-real time for my 50Mhz projects.
- single step and continuous run
- breakpoints (doubleclick on the dark grey bar on the left side of the listing window)
- a ram-window that allows viewing and editing ram content
- a "watch"-window that shows all variables. their address and their value
- an overview pane that shows all code jump labels and allows you to quickly scroll to them by double-clicking.
- there is also a module for the python scripting language allowing one to create advanced test-scripts.
Attached is an installer for the windows version. Feel free to use this program. Suggestions for improvement are welcome, although my time to spend on this project is extremely limited, so don't expect any major new features appearing soon.
Kind Regards,
Danny.
- I will continuously update the files in this post (the topmost message), so the files in this message are the newest
- Update: I noticed that this version still had an old bug (not skipping page instructions, most notable when running SX/B listings with a pause statement). So I'm attaching version 0.1.1 which fixes this.
- update: v0.1.3 has a few fixes, some UI improvements and in python: RAM breakpoints
- update: v0.1.4 fixes some SX instructions (DC flag behaviour). The source package shows (but doesn't use) the "precompiler optimization" which runs a lot faster on linux but a lot slower on windows
- update: v0.1.5 fix of serious bug in retw implementation introduced in v0.1.3
- update: v0.1.6
- UI improvements (fixed size font, keyboard shortcuts)
- Some changes to make the listing parser a bit more stable
- The installation now contains a few example lst-files in 'program files\sxgo\examples'
- speed improvement (about +50%) because the use of 'precompiled instructions' now also works on Windows, though I reserve the right to sacrifice some of that speed for new features like 'step back',
- In python: a 'cluster' object that can run several SX emulators on one clock (I needed this for testing communicating SXes), see included example 'cluster.py'
640 x 579 - 73K
zip
168K
Comments
very cool Danny - I'll try it out.
test scripting is a real need - and in Python no less !
cheers,
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Because I wasn't sure about the type of needs of the average dweller on this forum, I concentrated on getting an installer working for the GUI. I'm not sure if the python module works out of the box.
I'll try to post a dedicated python install for Windows this evening (CET) . I'll see if I can crank out some documentation of the classes as well.
Let me know how you fare...
Cheers,
Danny
Danny,
no problem - and·it's always interesting to be on the bleeding leading edge [noparse]:)[/noparse]
which version of Python will it be?
(and it looks like an "SX-python" has already been claimed!)
http://www.alibaba.com/product/areasx-11823218-11107392/Board_Sx_Python.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A python module called "pysix" (I know, I know, but any other name sounded either like some British football club or like indecent acts on pastry). The module should work with python 2.6 (and probably no other versions) on Windows. If needed, I could build modules that work with other python versions and a linux version is certainly also possible.
The attached zipfiles contains a bunch of dlls, a .pyd file (which is in fact also a dll), one demo .py script and one demo .lst file.
Easiest way to install this is to copy the dll (and pyd) files to the 'DLLs' directory of the python installation (often this would be "C:\python26\DLLs"). But you can also test the plugin by running a script that is in the same directory as all the dlls, as the demo script is when unzipped with the rest of the files.
The included demo script, 'retw_table.py' will try to load a simple listing called 'retw_table.lst', run it and print the contents of the w register after every the call to the 'Table' function. On my sxgo web page I have an example with a slightly more interesting lst file.
I'm going to create some documentation on this page after this post.
@Howard: Shame about the sx-python name. Good thing that I'm of the 'the name doesn't matter'-school
@Vinnie:Thanks for the feedback! Testing with non-trivial IO is exactly why I created the python module.
All comments, suggestions and bug reports are welcome.
Actually, the next thing I wanted to implement, for both the UI and the python module was going to be "data-breakpoints", in other words, breaking when some ram location or register changes value. I think I can probably do this without too much performance cost.
- Update for page skip bugfix
- I removed the python support files, the most recent one can now be found at the topmost message.
Post Edited (spiff) : 8/9/2009 2:36:26 PM GMT▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
very nice work --- what is it with you Netherlanders anyway? You seem to be among the world's best programmers and engineers [noparse]:)[/noparse])
Initial results/comments/observations:
1. I'd just put the python stuff together with the win-installer (or linux package), if you can. And then let the user find the Python file. [noparse][[/noparse]I'm still not sure which set of DLL's are correct as the pysix ones (all of them, including the VC dlls) seem newer than the installer version] - got it to work following your lead immediately above, just maybe a little differently:
= installed SXGO first,
= unzipped pysix, putting only the boost_python-vc90-mt-1_39.dll into the Python26\DLLs dir,
= ran 2.6's IDLE from the start menu,
= openned your sample retw_table.py in IDLE, then 'run'
*SUCCESS*
Here's what I got (from IDLE window):
>>> ================================ RESTART ================================
>>>
just read: 65 : A
just read: 66 : B
[noparse][[/noparse]...etc...]
just read: 100 : d
just read: 255 : ÿ
just read: 0 :
Done
2. Using Python Version 3.1's IDLE, there are syntax errors as the print instruction has changed (or was broken from version changes, depending on how you think of it [noparse];)[/noparse] Print is now a 'function' e.g Print ("Hello Nederlanders") --- yes, you'd have to recompile the 2.6 pyd to 3.1 ... I think it would be a good idea to go to 3.1 (unless your linux distro's are still on 2.6 which is pretty likely.
3a. Just a nit: For SXGO's control buttons, you might want to put tooltips (mouse-over help) - wasn't sure which was run versus fast-forward.
3b. Add a status bar at the bottom to reflect the current running/stepping action - gives a bit of help what it's actually doing.
4. Which development platforms did you use on Win and Linux - the full visual studio or the express version, and GCC on Ubu?
5. I don't know how many other Python'ers we have here, but it would be wonderful to embed the script engine in some of the other toolsets. (PY/SX/B or PY/SPIN would be killer [noparse]:)[/noparse])
I'll noodle more and report back soon... ik heb ervan genoten!
again, nice work!
cheers
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (CounterRotatingProps) : 7/4/2009 9:09:31 PM GMT
You got me all blushing! Thanks for the feedback.
In the end, I think it would be best to embed python into sxgo somehow. That way it could come with it's own python installation and then I could just pick 3.1 as the version to use. There are other programs that do stuff like that (K3D is an example), so it should be possible.
3a: Good tip (pun entirely intended). I'll figure out how to do this and add it.
3b: I'm not sure what you mean. should it show the current assembly instruction? Does that mean it doesn't show you the green bar that highlights the current statement in the listing? When you open a file, SXgo is supposed to show you the listing and when you start running it should show you a semi-continuous update of what the currently executing line is by highlighting it with a green bar (actually it only updates that bar every 10 milion instructions, about five times per second).
It's Visual Studio 2008 (9.0) express edition on Windows vs. GCC 4.3 & eclipse on Linux.
Interesting point. Maybe we are boring our fellow SX enthousiasts to death with all of this Python talk
On the other hand: for any project that is slightly more complex than the blinking led, it is really nice to have some test scripts ready that quickly show me if everything is working the way it's supposed to. Most of my SX projects involve some textual LCD or rs-232 output and it's been very convenient to have a python script that just runs the latest listing and outputs the simulated rs-232 text to screen.
Still, for most SX users a full-featured emulator like SX-sim is probably good enough. SXgo is intended for those who really need the speed and pysix is maybe best suited for those complex projects where writing a test script is worth the effort.
Now, a Python Stamp would be interesting... Another small step towards my Secret Plan for World Domination by Putting Python in Everything...
Cheers, and be careful with those fireworks today...
Danny.
Now... if I could learn how to develop cross-platform apps with nice UIs in Python, that would be even cooler.
Blender is one of the best programs I've ever seen. Even its initially counter-intuitive GUI becomes efficient once you learn it. And integrating Python was one of smartest things they did.
Python's easy to learn - and, more important, the syntax and data handling are easy to remember. The difficulties are in learning the libraries/modules available that extend not the language but its functionality. For example, there are FFT packages for scientific, raw data and for Blender specifically. The difficulty with learning libraries/functions for Blender would be true regardless of language - as you know, the working guts of a program can be exposed through an interface, then some language is used to access and manipulate (script) those functions so you can make the program do more than it does out of the box. Blender has a gazillion functions, so Python makes them easier to wrap your head around than would say VBScript - the former can encapsulate them into modules, the latter would have to do that in more rudimentary objects. (OK purists would argue that, but let's not go there please - it's messy in VB(x))
One of the things you might want to study closely is iPython, it really helped me learn the language.
> if I could learn how to develop cross-platform apps with nice UIs in Python, that would be even cooler.
You can! There are several cross-platform GUI modules that work pretty well and are mature, but there's a learning curve on each. Probably the most well-known are "wxWidgets" and "Tk"
for a good overview, look here:
http://wiki.python.org/moin/GuiProgramming
Keep in mind that Python is a script language, so you won't get the speed if your GUI needs to update data fast (but you can hook into C/C++ and even ASM, if you need [noparse]:)[/noparse]
Jon, while we have your attention (and Bean too, if you happen to read this) - one of the most astounding advances you guys could make in the already amazing SX/B would be to expose part of its internals... I can well imagine that you'd be more inclined to use VBscript via the windows scripting host tools because of the similarity of their basic-like syntaxes. But I would encourage you all to take the embedded Python-script approach instead. Here's why: exposing it's interface via Inspect/automation and then optionally embedding a scripting language is about the same amount of work regardless of the script language you choose. Any language can usually talk to the automation interface - so why layer Python on top of that ? Because of the massive amount of Python libraries and their continued growth.
Several examples of all kinds of interesting possibilities: dynamically downloading different virtual devices; seemless interface to PC-based instrumentation (Viewport for SX anyone?); translation of Python libraries into SX-asm modules (probably too cool for our own good [noparse];)[/noparse]; etc. etc.
cheers
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
> In the end, I think it would be best to embed python into sxgo
Yes.
> 3b: I'm not sure what you mean. should it show the current assembly instruction?
> Does that mean it doesn't show you the green bar that highlights the current statement in the listing?
That's working fine - no worries there.· It's just at the start, pause, and end states where it's not clear what it's doing... but the "unclarity"·might be gone once you get used to how it works.
> currently executing line is by highlighting it with a green bar
> (actually it only updates that bar every 10 milion instructions, about five times per second).
You'll probably want to fine tune it·by adding a "step" "walk" "run" speed control. (And then comes "step into," "step over," etc...) And by the time you have that, Guenther may get wind of this and put Python into SXSim --- then you'll really have some (friendly) competition·- and not just who's got the better engineers, Netherlands or Germany? ;-)
> It's Visual Studio 2008 (9.0) express edition on Windows vs. GCC 4.3 & eclipse on Linux.
Oh very cool ! I've got both going here·(WOW is eclipse a fatty or what??)
> Another small step towards my Secret Plan for World Domination by Putting Python in Everything...
Sshhh! Don't tell anyone !
> Cheers, and be careful with those fireworks today...
Thanks, it was a· * BLAST *
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Danny.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There's nothing like a new idea and a warm soldering iron.
Is all of the correct downloadable code at the top of the Thread? I would like to try your System and see how it works.
RS_JIM
· WHOA... You've got to be kidding me right ??? 50MHz Real-time performace ???
· If that is true I'll have to check it out.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...
·
@Bean: I kid you not
- The 50Mhz (actually I'm measuring more like 75Mhz lately) in the UI version (sxgo) is measured without measuring the time a UI update takes. Currently sxgo runs 1_000_000 clock ticks (at a speed of approx 75Mhz) and then spends some unknown amount of time updating the UI before running the next 1_000_000.
- The python implementation does run at full speed until either a breakpoint or a ram watchpoint is hit. So the python version of the emulator runs normally at full speed until it has to go back to python for some reason.
I've also created an improved version of the emulator that runs at 105 Mhz on a 2.4Ghz linux machine. Alas, this "improvement" slows down the windows version considerably (to about 40Mhz). The improvement is reached by pre-compiling all instructions into a format that the emulator can run more quickly.however: I'm working on an version that allows the UI to be updated in parallel with the executing emulator on multi-core/processor machines.
(text update: I accidently wrote 10_000, where I meant 1_000_000)
Post Edited (spiff) : 7/16/2009 10:24:49 PM GMT
I went to look for the files in the top of this topic but find no files, Are they misssing or am I missing something?
RS_JIm
Must have been as I see the files now and will download them.
RS_JIM
Tried to run SXGO today and got the following error:
AppName: sxgoui.exe AppVer: 0.0.0.0 ModName: sxgoui.exe
ModVer: 0.0.0.0 Offset: 000edd11
I am running XP Home on a Celeron processor with 1 GB ram.· Any Ideas on why the failure?
RS_JIM
From the offset it would appear that this crash happens when you open a file. Is that correct? If not: when does the crash happen?
If it does crash during file open, would it be possible for you send me your .lst-file? I believe you can send it through a private message if you click on my name and then on 'Send a Private Message to spiff'. Alternatively, could you also try to open the lst-file that I've attached and see if that one opens normally?
Oh, and additionally: what language is your windows version configured to use? (sounds weird maybe, but the problem appears to be in an otherwise very unimportant string localization function that is used by the listing parser).
I'd be very interested to see what kind of performance you would get on your celeron. 1GB ram should be more than enough. Need to get the thing running correctly first though
Post Edited (spiff) : 8/6/2009 7:35:41 PM GMT