PDA

View Full Version : More GEAR - Improved Emulation of the Propeller



mirror
01-13-2008, 12:08 PM
What is GEAR? GEAR is a C# program that simulates the inner workings of the Propeller chip.
Who wrote GEAR? The original version of GEAR was written by asterick, and his version and notes can be found here: (especially the first posting!)

http://forums.parallax.com/showthread.php?p=624986

So why this version? asterick has not been seen on this forum for quite some time. In the meantime, I've made several enhancements to GEAR which are presented here.

On 26 October 2009 - V09_10_26
* Many thanks to Bob Anderson for identifying bugs in and subsequently testing improvements to the emulation of SUBS, SUBSX, CMPSX and REV.

On 5 June 2009 - V09_06_05 (140)
* Many thanks to Ben Levitt for improving the behaviour of GEAR. (Reload Binary, Open to PlugIn, Close PlugIn)
* Improvements in SerialIO plugin (Ben Levitt).

On 11 May 2009 - V09_05_12 (50)
* Fixed memory references of the form LONG[ &MyVar ][ 2 ], this case was being emulated as LONG[ 2 ][ &MyVar ].
* Included SerialIO plugin (with thanks to Ben Levitt) in the distribution.

On 16 October 2008 - V08_10_16 (151)
* An extra function has been added which allows hot keys to be disabled for a plugin. Simply add the following function to your plugin:
public override Boolean AllowHotKeys { get { return false; } }

On 29 April 2008 - V08 04 29 (159)
* The lastest stimulus.zip is now included in V08_04_29.zip.
* 'R' and 'S' keys can now be used to run, stop and step the currently active cog.
* Floating the cursor over an assembly cog page shows the values stored at the source and destination registers for the instruction line that's under the mouse. The values are shown as both hex and decimal.

On 23 January 2008
* Updated stimulus.zip. Still works with V08_01_18 of GEAR.
* The stimulus plug-in page has a context menu which allows a new stimulus file to be loaded and the current one to be saved.
* Editing of the stimulus file is allowed - previously it was read-only.
* As part of the stimulus file, it is now possible to include the words reset and stop.
reset - simulates a reset of the processor.
stop - causes a breakpoint - click Run to go to the next stop / breakpoint
How's this for something you haven't been able to do til now!!



! Stimulus File breakpoint example
! (diagnosing the first microseconds of life)
10u stop
+10u stop
+10u stop
+10u stop
+10u stop
+10u reset



On 21 January 2008
* Added stimulus.zip which updates stimulus.xml and the example stimulus file. It is now possible to do clock and pwm generation. You need the V08_01_18 version of GEAR, but if you already have that then all you need is the stimulus.zip file.

V08_01_18 (140)
* Pin toggling by means of a stimulus file. The other proposed functions (clock and simulated serial) may be written as part of stimulus.xml, but several changes were required in GEAR to make it all work.

V08_01_13 (86)
* Better disassembly of PASM
* Some fixes in assembly language emulation
* An alternative / short instruction set for the spin bytecodes (the original is still available)
* The ability to display numbers as hex or decimal
* The ability to add a single breakpoint (just click on a line of code).
* Improved simulation of the timing from the output pins

Post Edited (mirror) : 10/26/2009 3:50:59 AM GMT

stevenmess2004
01-13-2008, 04:59 PM
Sounds great mirror.

Thanks for the effort.

Steven

potatohead
01-13-2008, 10:48 PM
Thanks for this!

The breakpoint significantly improves the usefulness of Gear.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)

Sapieha
01-13-2008, 11:22 PM
Hi All.

Gear is very fine program.
But if it have TGB input emulation it have more power.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.

Sapieha

mirror
01-14-2008, 05:15 AM
But if it have TGB input emulation it have more power.
I've never heard of TGB input emulation.

But, do you realise that add in's can be written for GEAR. A number of example plugins were written by asterick. Personally, I've never used the plugins.

I generally·use·GEAR to simulate small subsets of code, not the entire application. It's great for nutting out concepts - eg. watching a block of memory (like a circular buffer) as you step through code.

simonl
01-14-2008, 06:42 PM
This is great mirror - many thanks.

Are you planning on taking-over development?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

mirror
01-15-2008, 04:41 AM
simonl said...
Are you planning on taking-over development?
I've probably been the only person who's done any development on GEAR since october last year. If you look at the original message thread you'll see several versions that I released.

I don't mind taking over development, but don't have as much free time as some of the other more prolific programmers on this forum. Part of the challange is that I do most of my PC development using Delphi, so I find working with the C# GUI components to be a bit handicapped in comparison.

Having said all that, what's the current wishlist?
·

simonl
01-15-2008, 05:04 PM
Well, I've only used it occasionally because it doesn't appear to have 'outside world' interaction - unless I've missed something?!

I'd really like:

a) 'serial' connection to PC (i.e. being able to have GEAR run simple_serial et al, and have the output appear in (say) Hyperterminal)

b) ability to toggle 'switches' on pins

c) ability for GEAR to read a text (CSV?) file that describes pin values over time

d) I2C emulation - again reading from a text file

Not much to ask really LOL!

Seriously though, just knowing that it's not a frozen product is good news - many thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

mirror
01-16-2008, 12:25 PM
How about the following as an example stimulus file for GEAR?

Comments welcome.


! Example stimulus file for GEAR
! Time indications are in seconds, use
! n - for nano
! u - for micro
! m - for milli
! K - for Kilo
! M - for Mega
! Time may be given in a relative format by starting the line with a +
! but once you've done that, mixing absolute times could result in events
! that never occur.
!
! Pin states are:
! 0 - Low = zero
! 1 - High = one
! x - No longer driven

! At 1 microsecond set pins 2 low, 3 low and 4 high
1u 2=001

! 10 microseconds later send a message on pin 4
+10u tx=4 baud=115.2K bytes=("Hello",13,$A,0)

! At 1 millisecond start clocks on pins 2 and 3.
! Clock 2 will start high then go low, clock 3 will start low then go high
1m clk=2 high=2u low=1.5u clk=3 low=1u high=2u

! At 2 milliseconds, stop the clock on pin 2
2m 2=0

! 100 microseconds later, stop driving pins 2, 3 and 4
+100u 2=xxx

simonl
01-16-2008, 05:53 PM
Hi mirror,

Wow - you're on the ball!

Re: your scheme:

1. If you supply (say) '1m clk=2...' after you've already supplied '+10u...', does that mean 1m from start, or 1m after the 10u start (I think the former)?

2. Would it be more efficient to just supply pin data as a 32bit binary string?

Looks like a good start though - thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

mirror
01-18-2008, 03:41 PM
See top posting for first draft of pin stimulus.

To demonstrate:
1) Load a binary file into GEAR, something generated from the following will work fine:


CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

PUB Main
repeat

2) Open the stimulus.xml plug-in from the tool bar, and open the test.stm file.
3) Open the Logic Probe.
3) Click Run.
4) Wait for the action to be displayed on the Logic Probe.
5) Press Reset and watch it all again - there's no need to stop or step.
·

simonl
01-18-2008, 03:56 PM
That's awsome! Many thanks http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

mirror
01-21-2008, 02:33 PM
Clock and PWM generation have been added to the Stimulus plugin. See top posting.

The clock generation setting are a bit different to what was originally proposed. Briefly, the syntax is:

clock=[pin] sets the pin number.
low=[time] sets how long the pin is low for.
high=[time] sets how long the pin is high for.
period=[time] sets the period, but leaves the ratio of high to low time unchanged (or sets to 50%)
pwm=[0.001 to 0.999] sets the ratio of high to low time without changing the period.

Once a clock is running it can be updated by modifying a single parameter at a time. The example stimulus file shows varying pwm and period examples.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

mirror
01-23-2008, 05:59 PM
See top posting for a handy modification to the stimulus plug-in.

Stop the code at the exact point in time that you're interested in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

matb
03-06-2008, 07:35 PM
Mirror can you put the source somewhere please.
I am keen to try it out under mono again on linux.

Ideally shoving the code back into sourceforge, or in a similar repository. (I won't argue if its bzr a based system)
We should be able to get added to the source forge project pretty easily if that works for you.

m@

mirror
03-11-2008, 12:42 PM
Here's a zip of my variant of the current source code for GEAR.

mirror
04-29-2008, 12:12 PM
I was doing some PASM work, and got frustrated at the user interface, so made some simple changes - included as part of the first post.

The changes are:
1) Use 'R' (or 'r') to run the current cog. 'S' will stop the current cog. If the cog is already stopped, then 'S' will step to the next instruction.
2) For a PASM cog, the values stored at the source and destination registers will be shown for the line under the mouse. They're shown as both hex and decimal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

mirror
10-16-2008, 06:22 AM
GEAR has been updated to allow 'R' and 'S' keys to be blocked when writing a plugin. See top post for details.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
05-01-2009, 05:18 PM
Updated to v0.2 to fix a bug in receiving a 0-value byte.
===================================

I put together a Serial IO plugin that lets you communicate interactively with the simulated Propeller. It talks to a FullDuplexSerial object running on the simulated chip (or anything pin-compatible). Just rename this file from SerialIO.xml.txt to SerialIO.xml, and put it in your gear directory with your other plugins.

Load it up and you can set the RxPin, TxPin and Baud, and then Press the Reset Serial button to apply your settings.

Then just type to send, and stare at the screen to receive. :)

Copy and Paste work too.

Let me know what you think, and if there are crucial features that I'm blatantly missing. :)

Ben

Post Edited (benjie) : 5/10/2009 4:41:41 AM GMT

benjie
05-10-2009, 11:27 AM
I just noticed a case that gets simulated incorrectly.

In spin code on a real Propeller chip, the expression long[ a ][ b ] evaluates to long[a + b*4].
Similarly, short[ a ][ b ] == short[a + b*2] and byte[ a ][ b ] == byte[a + b].

But in gear, long[ a ][ b ] seems to always evaluate to 0.

Any suggestions where in the gear code to look for a way to fix this?

(For now, this is easily worked around in spin code by using the long[a + b*4] format.)

Ben

Post Edited (benjie) : 5/10/2009 12:21:32 PM GMT

heater
05-10-2009, 02:56 PM
Silly question but how do I run gear ? I have a naked XP SP3 installation. Clicking on gear just gets me a application error "The application failed to initialize properly...."

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Sapieha
05-10-2009, 03:14 PM
Hi heater.

I run XP SP3 and not have problems to start Gear relase V08_10_16

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

heater
05-10-2009, 03:42 PM
OK it starts up after installing .NET 2.0. I had 3.0.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
05-10-2009, 04:14 PM
Just for kicks I wanted to run: CP/M under the ZiCog z80 emulator running under the Gear Propeller emulator in the .NET virtual machine under XP which is running in a Sun VirtualBox virtual machine under Debian Linux.

Just to see how many VMs we can stack up :)

Anyway Gear running ZiCog won't respond after hitting "run". Just keeps running eventually taking down XP.

What are the known limitations on what Gear can do at present?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mirror
05-11-2009, 04:28 AM
benjie said...
I just noticed a case that gets simulated incorrectly.

In spin code on a real Propeller chip, the expression long[ a ][ b ] evaluates to long[a + b*4].
Similarly, short[ a ][ b ] == short[a + b*2] and byte[ a ][ b ] == byte[a + b].

But in gear, long[ a ][ b ] seems to always evaluate to 0.

Any suggestions where in the gear code to look for a way to fix this?

(For now, this is easily worked around in spin code by using the long[a + b*4] format.)

Ben


Ben,

Do you have a minimal example to demonstrate the error and I'll look into it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

mirror
05-11-2009, 04:35 AM
heater said...
Just for kicks I wanted to run: CP/M under the ZiCog z80 emulator running under the Gear Propeller emulator in the .NET virtual machine under XP which is running in a Sun VirtualBox virtual machine under Debian Linux.

Just to see how many VMs we can stack up :)

Anyway Gear running ZiCog won't respond after hitting "run". Just keeps running eventually taking down XP.

What are the known limitations on what Gear can do at present?


Three major limitations that I know of:
1) It's slow - like really, really slooowww. It's best for debugging snippets of code.
2) The spin bytecodes are functionally simulated, but not time simulated. Spin takes quite a few more clocks to run on the real Propeller than under GEAR. The PASM simulation is "time-accurate".
3) Very little simulation of external hardware.

You could try stepping through the code - rather than running. To see if there is a reason for the "lockup" - like maybe waiting for some sort of hardware event.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
05-11-2009, 08:38 AM
Here's a small sample that shows the problem. It uses a serial connection, so fire up the SerialIO Plugin. :)




CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000

CR = 13


OBJ
debug : "FullDuplexSerial"


VAR
long list[ 4 ]
long r


PUB Start
debug.Start(31, 30, 0, 57600)

repeat
debug.tx(">")

r := debug.rx
LONG[ @list ][ 2 ] := r ' this line combined with
LONG[ @list + 3*4 ] := r

r := LONG[ @list + 2*4 ] ' this line seems to fail.
debug.tx(" ")
debug.tx(r)

r := LONG[ @list ][ 2 ] ' the rest seem to work.
debug.tx(" ")
debug.tx(r)

r := LONG[ @list + 3*4 ]
debug.tx(" ")
debug.tx(r)

r := LONG[ @list ][ 3 ] ' not sure why this one would work.
debug.tx(" ")
debug.tx(r)

debug.tx(CR)





The minimal code to see the problem would be something like:




VAR
long list[ 3 ]
long a

PUB Start
LONG[ @list ][ 2 ] := 3
a := LONG[ @list + 2*4 ] ' a is not set to 3





Ben

mirror
05-11-2009, 10:03 AM
benjie said...

The minimal code to see the problem would be something like:




VAR
long list[ 3 ]
long a

PUB Start
LONG[ @list ][ 2 ] := 3
a := LONG[ @list + 2*4 ] ' a is not set to 3






Thanks for the code! It was being emulated as:



VAR
long list[ 3 ]
long a

PUB Start
LONG[ 2 ][ @list ] := 3 ' 2 + @list * 4 !!!
a := LONG[ @list + 2*4 ] ' a is not set to 3




See the top post for a new version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
05-11-2009, 10:37 AM
Awesome turnaround! :) I can confirm that the bug is fixed.

But I think you may have built the fix from an older version of the code, because I can no longer override AllowHotKeys.

Also, if you want to include the SerialIO plugin with the main distribution, feel free. :)

mirror
05-11-2009, 12:22 PM
Arrrgh, source code on two computers . . . I'm sure oldbitcollector will understand!

I included SerialIO - it looks good!

See the top post for the new version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
06-02-2009, 05:30 PM
Updated SerialIO to v0.3 to add a scroll bar, and to automatically scroll down as text goes off the screen.

I've been using it to debug changes to my remote controlled airplane autopilot code while I'm out of the country and away from the hardware. I've been pasting in raw GPS data and watching it churn, calculate, and spit out debug info. :)

Ben

benjie
06-02-2009, 05:41 PM
Hi mirror,

I have ideas for a few small UI tweaks that I think would make gear a lot easier to use:

- it would be super useful if you could reload an open binary so that after building a new version of the binary, you didn't have to close the window in gear, open it again, open and configure your plugins, and arrange your windows in the workspace. :)
- it would be nice if, when opening a new plugin, that plugin's tab was automatically selected.
- it would be really cool if there were a preferences setting that let you choose one or more default plugins that would open with every opened binary.
- it would also be awesome if there were a way to close a plugin.

But mostly the first one. :)

I'd be up for helping with this stuff if you think these are good ideas, and if I can figure out the code base. I'd also be up for starting something like a google code project for gear so we'd have a subversion repository to work with, if you like that idea.

Ben

benjie
06-04-2009, 10:12 PM
Oh, also, is there a link anywhere to the code for the most recent version of gear? I found the oldish code earlier in this thread, but not the latest.

Thanks!

mirror
06-05-2009, 04:56 AM
Ben,
Great suggested improvements! (Especially the "reload" button).
I'm not really interested in a subversion repositry, but don't mind managing the merge of any changes you (or anyone else) may want to make independently.
Source for the latest version of GEAR is included in the top post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
06-05-2009, 02:29 PM
Hi mirror,

Awesome, thanks for the source! It looks like a really nice codebase. I haven't played with csharp/.net much before, so hopefully my changes are not too offensive. :)

Here's a patch that makes the following changes:

- Adds a reload button to reload the currently open binary file from disk, and reload the chip.
- When opening a new plugin, select that plugin's tab.
- Adds a Close Plugin button that only closes user-loaded plugins, not built-in ones. (This button should probably only be enabled when a user-loaded plugin is selected...)
- Updates SerialIO from 0.2 to 0.4.

Please let me know if you like these changes as is, or if you want me to change how I'm doing anything.
Also, let me know if you want these changes in some other format.

Thanks for maintaining!
Ben

mirror
06-05-2009, 06:49 PM
Thanks Ben,
All mods have been included in the top posting!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

benjie
06-17-2009, 01:35 AM
I also noticed yesterday that Gear seems to work well now under wine.

I'm running:
- wine 1.1.23 installed through MacPorts
- dotnet 2.0 installed into my wine installation using winetricks

It seems to display the entire UI correctly (not the case under wine 1.0.1), as well as simulating programs correctly. It is however still quite a bit slower than running natively, or on a real windows installation into VirtualBox, but if wine is convenient for you, it's a pretty cool solution.

Ben

Ron Sutcliffe
06-22-2009, 10:21 AM
Hi mirror

Is there anyway I can save the logic probe image to a a bmp file?

Ron

Mike Huselton
06-22-2009, 01:01 PM
Mirror,

I am a professional C# programmer with about 7 years experience. I have been wanting to congratulate you on the code and support you give.
It is a great tool. Good job!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

mirror
06-23-2009, 04:47 AM
Ron, Use Ctrl-Print Screen, which will copy the screen to the buffer. You can then paste the image into Paint, Word and probably many other applications as well.

James, thanks for the compliment. I must confess that I merely dabble in C# (my support for GEAR is the sum-total of my C# experience), although I've been programming for 25 years and in many different languages.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

mirror
10-26-2009, 10:47 AM
Many thanks to Bob Anderson for identifying issues with the emulation of SUBS, SUBSX, CMPSX and REV.

The discussion and related test cases where included in a discussion thread at:
http://forums.parallax.com/forums/default.aspx?f=25&m=394757

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔