Improved GEAR Emulator
Gatuno
Posts: 23
For who didn't know, GEAR is an Propeller 1 Emulator, capable to load propeller images (binary/eeprom) compiled by Propeller Tool or simillar. Their last version was 1.11 in year 2007.
Forum thread by the original programmer asterisk: http://forums.parallax.com/showthread.php?p=624986
Code repository: http://sourceforge.net/projects/gear-emu/
Then user mirror makes new versions up to 2009, with more improvements and bug fixes.
Forum thread "More GEAR" (w/ program & sources) : http://forums.parallax.com/showthread.php/100380-More-GEAR-Improved-Emulation-of-the-Propeller
It has not been update in 4 years, until now. I found some bugs using the counters in logic modes (CTRMODE=%1xxxx) emulation, and decide to explore what was inside the hook of GEAR. Finally I made many changes and bug fixes:
Version V14.07.03:
GEAR emulator Attachment:: [FILE]GEAR_V14_07_03.zip[/FILE]
GEAR source code (MS Visual C# 2010 Express): [FILE]gear-source-14.07.03.zip[/FILE]
Future ideas:
Enjoy better debugging with your propeller!
Gatuno.
(Edit 2016-02-24): reattached files.
Forum thread by the original programmer asterisk: http://forums.parallax.com/showthread.php?p=624986
Code repository: http://sourceforge.net/projects/gear-emu/
Then user mirror makes new versions up to 2009, with more improvements and bug fixes.
Forum thread "More GEAR" (w/ program & sources) : http://forums.parallax.com/showthread.php/100380-More-GEAR-Improved-Emulation-of-the-Propeller
It has not been update in 4 years, until now. I found some bugs using the counters in logic modes (CTRMODE=%1xxxx) emulation, and decide to explore what was inside the hook of GEAR. Finally I made many changes and bug fixes:
Version V14.07.03:
- Faster emulation.
In my own testing, GEAR runs now about 30% or 35% faster than Gear V09_10_26, maybe because the executable now use MS .NET framework 4.0 instead of 2.0. The drawback is the need to download the framework, but in windows 7 or 8, probably it is installed already.
Also, updated the project files to MS Visual C# 2010 Express (the old proyect was in MS Visual C# 2005). I use that because it was the only I could find.
Also, updated the project files to MS Visual C# 2010 Express (the old proyect was in MS Visual C# 2005). I use that because it was the only I could find.
- Show Cog RAM Special Purpose Registers values.
Now the values of special registers in cog memory (between $1F0 - PAR and $1FF - VSCL) are displayed correctly in memory or PASM view.
- Logic modes in counters.
Logic modes (CTRMODE between %10000 and %11111) didn't work well in past versions of Gear.
- Correction to enable PAR register changes.
As there was some reports of prop forum users that GEAR was of not capable to change the PAR cog register (forum thread "PASM simulator / debugger?" http://forums.parallax.com/showthread.php/115909-PASM-simulator-debugger) then I enabled it. They claims that some parallax video drivers in PASM changes the PAR register, and GEAR didn't emulate that. The Propeller Manual V1.2 specify that is a read-only register, but if parallax did that drivers that really run on the real one...
- Fixes in Logic View.
When you reload a binary or reset it, and you had run it before using pins, the logic view show a mix between new and old samples.
If you are using windows in other languages than english, -with other number formats-, the preset values for time frame and tick mark (with "." decimal separator) will not work if you press the update button.
If you are using windows in other languages than english, -with other number formats-, the preset values for time frame and tick mark (with "." decimal separator) will not work if you press the update button.
- Flickering correction on cog view over PASM lines.
When you were on cog view (PASM code), the tool tip text sometimes flickers.
- Tooltips over pins and locks in hub view.
Added tooltips on hub view on pins and locks views (IN*, DIR*, Floating, Lock Free, Locks), to identify easily which pin or lock is.
- Plugin editor enhancements.
Experimental C# sintax highlighting of code. Now the name of the file is displayed on the title of the window. Added tooltips to be more self explaining.
GEAR emulator Attachment:: [FILE]GEAR_V14_07_03.zip[/FILE]
GEAR source code (MS Visual C# 2010 Express): [FILE]gear-source-14.07.03.zip[/FILE]
Future ideas:
- Improve C# sintax highlight on plugin editor (accurate & faster).
- Modify the file format for plugins (add version, description, usage, author, etc) and show it on screen, keeping compatibility with older plugins.
- Better documentation of plugins.
- Documentation of C# sources (doxygen?).
Enjoy better debugging with your propeller!
Gatuno.
(Edit 2016-02-24): reattached files.
Comments
(Use "Attached Files")
For some reason your original post got stuck in limbo.
I got it to post finally, but the attachments did not come through correctly.
I posted the attachments to the bottom of the post.
Thanks for the great re-do of GEAR!
Thanks a lot for the editing. I try to modify by myself, but it doesn't work!
Inexplicably, now both kind of links works...
Gatuno.
Luckily we worked on different parts so I just integrated all your changes and it didn't affect mine. But still weird that after 4 years of silence we're 2 who want to improve it
So what I did?
I cloned asterick's original repository and converted it to Git. Then applied mirror's improvements on top of it so we've nice commit history (but not full as I couldn't find all version sources).
Then I converted VS project to 2013, properly formatted (eg. indentation) source code of all files. Refactored and fixed Propeller Assembly's disassembler so that disassembler is 100% correct and will output almost exactly same instructions as source. (note, that this is only disassembler, but not emulator)
I also wrote ChangeLog and included there info about all previous versions that were released. And now I've incorporated Gatuno's changes and pushed all code to GitHub.
So I suggest that from now on we all work on GEAR's Git repository, which can be found https://github.com/davispuh/gear-emu (feel free to send Pull Requests and I'll merge those in)
You can view ChangeLog.md here at GitHub and my changes can be viewed here and integrated Gatuno changes here ( can you Gatuno take a look if I've merged correctly them all?)
Now, next I plan to look into Spin interpreter disassembler and then in Emulation itself as it doesn't seem to be working properly for my test files. Also I wasn't able to get SerialIO working.
Here's a screenshot, you can compare how good disassembler now is. (before my changes it would say it's AND even if it was TEST instruction)
Nothing easier than that. Just go to Walmart or target and get the cheapest Laptop they sell. $200+ will work. Them come with windows pre installed.
If you need to run on Linux, try MONO.
Enjoy!
Mike
What are you running? I build the code on Mac OS X using Xamarin Studio and it runs in the Mono framework on my Mac...
http://xamarin.com/platform
dgately
Also I can't image that someone was working on GEAR too. Good news!I think we could work on it together, too.
As I don't have experience using Github, I have to learn a bit about. First I'll see the changes integration, as you asked.
Can I post you questions about the repository by forum mail? I have doubts about downloading a compiled binary from the Github site.
I would like to improve the plugin system, and I was trying to document the GEAR code with doxygen (I have good experiences with it).
Gatuno
I hope you weren't offended by the tone of my post if so I apologize for it. It's been a rough week and I was having a real bad day but still no excuse. I have a hack'n'tosh but mostly I use linux. I've tried using mono with windows software on linux and never had any success with it. I have to admit it's turned me off and I've never tried it on my "hack".
With the popularity of linux among prop users I'd like to see native linux software. Of course the developers have the right to develop software to run on any platform they choose. I just wish it would run under linux! :-)
No offense taken!
I'm not sure if mono has improved on Linux as it has on Mac OS X. I had given up on mono on Mac a while back, but thought I would give it another try and have had success with several apps, recently. Unfortunately Xamarin does not run on Linux.
dgately
Git is a very popular source code management system designed and developed by Linus Torvalds. You can read more about it on http://git-scm.com/ (they also have great documentation and compiled binaries, you can also get source code) it's available for all platforms (Linux, Windows, OS X and others).
GitHub is a Git repository hosting website and they offer free hosting for all public projects (and also paid private repositories). They're similar to SourceForge and Bitbucket but with much much nicer web interface IMO. They've also good documentation at https://help.github.com/ and I would really suggest to take a look. They also offer a GitHub client application, which is just kinda more user-friendly GUI for Git, but I personally don't use that, because when I looked last time I found to too limited in functionality. Anyway for Git usage just google for it and if you have any questions just post them here or PM me.
I'm myself also Arch Linux user, but I chose to work on this mostly because it seemed to be emulator with most features and I see a potential in it. But I haven't tried to compiling it for Mono yet, but I'll probably do that some day. Also another alternative would be Wine, but I don't know if that would work, so will also have to try.
So anyway, I'm sure we will get this working on Linux too
At least on OSX, Wine tells you to use mono if you give it a .net program and then it quits. I haven't tried it on my linux, but I imagine it does the same.
Mono is not there to run Windows applications on Linux/Mac Systems, like wine does. Not at all. The Net Framework/ECMA-Script is a bunch of libraries, some compilers and a Byte-Code Interpreter. Somehow like Java.
If you take care of things like File and Path separators as described here: http://www.mono-project.com/Guidelines:Application_Portability your application will run on Linux/Mac/Windows/AS400/IBM370/Solaris/whatever other implementation of the Byte Code Interpreter. The current Version of GEAR does this quite nicely.
You do not need to recompile anything. Compiled Net-Framework Applications/ECMA-Script are usually OS and HW independent if written that way. Its just Byte-Code, not compiled to a specific Architecture. Somehow like Java.
So it is basically copy and paste of the needed files. No installation process needed for a Application. You just need to have a working runtime. Microsoft provides this runtime for Windows and MONO (and others) provide the runtime for other systems.
Sure. You CAN write Net-Framework Apps NOT working on other systems (like Microsoft does). But you don't have to (like GEAR and others do).
There is a tendency here on this Forum to bash Microsoft anyways. But I am a Engineer and use the right tool for the right job if possible. I am not religion-orientated there. If a propeller can do it I chose the propeller, but if it is cost prohibitive I use something else. Same with MS/Linux/Mac/whatever. Its just a OS not a GOD. Use whatever is there and the customer/boss/wife is used to. Why bother?
SimpleIDE shows how nice platform independent QT can work and GEAR shows you how nice platform independent Net-Framework/ECMA-Script can work.
I personally do not use GEAR as much anymore as I did some time ago. Like with ViewPort. Nice to have if you are tearing out your hair, because you do not find the reason for some strange behavior of your code.
But it is a very nice tool to have and I thank @gatuno and @davispuh for keeping it alive and improving it. Well done!
Enjoy!
Mike
I've been searching, haven't found one.
I'd like to run SidCog on Gear if possible.
I haven't see a audio plugin already.
In the thread "SIDcog - The sound of the Commodore 64 ! (Now in the OBEX)" (http://forums.parallax.com/showthread.php/118285-SIDcog-The-sound-of-the-Commodore-64-!-%28Now-in-the-OBEX%29?p=1327988&viewfull=1#post1327988), I posted some help on access more data inside the emulator.
As we have been developing more the plugin system, I had realized there is more possibilities of expanding it, and although it is still not well documented yet, I know it is possible to access many properties of the emulator.
Currently the plugin system is mainly oriented to read & write pins when the clock ticks (using OnClock() method), or when a pin changes (using OnPinChange() method), offering Chip.DrivePin() method to affect pins or Chip.PinStates[] array to read their states. But is possible to access all the public methods and properties of Propeller and Cog class.
If you need specific help on plugins, post here.
============================================
POSTEDIT: In sake of clarity added the explanation from post http://forums.parallax.com/showthread.php/118285-SIDcog-The-sound-of-the-Commodore-64-!-%28Now-in-the-OBEX%29?p=1327988&viewfull=1#post1327988 of how to access the Cog data:
In that version of GEAR plugin, if you have declared inside your new plugin, you can access a Cog method ReadLong(uint address), and read directly FRQA or FRQB. I recomend the following as example:
If you somehow integrated into the learning page.
However, running a little slow under wine.
But a good reason to reinstall windows ;-)
As explained in post [post=1328085]#213 of SIDcog - The sound of the Commodore 64 ! (Now in the OBEX)[/post], the improvement of plugin system in the current development on gitguh repository (V15.xx or above) has implied some changes in the methods of plugins.
As a help to understand it, here I copy the current template of new plugins v1.0, with the common options explained inside (note: don't be confused with the "PHP code:", the code is C#, but to post here in the forum, I use the php tag to show it color highlighted).
[php]//Plugin template for plugin system v1.0
//Author : put your name here
//Date : date of this version
//Version : put the version of this plugin
//Description: write what do your plugin
//Usage : how to use this plugin
//Assemblies needed for GEAR plugin system (do not delete them).
using System;
using Gear.EmulationCore;
using Gear.PluginSupport;
//Add here extra assemblies as needed in your plugin.
//Class name declared below must match class name on plugin editor text box
class YourClassName : PluginBase
{
//Constructor for the initialization of your plugin
public YourClassName(PropellerCPU chip) : base(chip)
{
//Include here your initialization code only for attributes you add to
//your class or interface objects (example create user controls for
//the tab window). If you don't use any, don't add code here, but you
//must not delete this method.
//If you wish to use DrivePin() for initial setup of pins, call it
//inside of OnReset() method, instead of here.
OnReset();
// Put your code here:
}
//Title to be shown in tab, change the string as you need.
public override string Title
{
get { return "PluginBase"; } //change to your plugin name
}
//Set the reference to the emulated chip. Occurs once the plugin is loaded.
//Also, if you need the plugin be notified on pin or clock changes, you
//need to add inside this method calls to NotifyOnPins or NotifyOnClock.
//To keep good performance, use only the essentials ones.
public override void PresentChip()
{
//To be notified on changed pins (ex. DIRx, OUTx, INx) use here:
// NotifyOnPins();
//to be notified on each clock tick, use here:
// NotifyOnClock();
//
//Put your code here:
}
//Called every time a pin changes, if called Chip.NotifyOnPins() in
// method PresentChip(.) above.
//Warning: to assure the correct correct operation of the plugin system,
//you can't change the parameters of any predefined method: neither the
//names or the types. Also you must not add other parameters.
public override void OnPinChange(double time, PinState[] pins)
{
//You could set or test pin states like "pins[0] == PinState.FLOATING;"
//or "if (pins[1] == PinState.FLOATING)..."
//Possible values for PinState enum are:
// FLOATING, OUTPUT_LO, OUTPUT_HI, INPUT_LO, INPUT_HI.
//
//Put your code here.
}
//Called every clock tick, if called Chip.NotifyOnClock() in method
// PresentChip() above.
//Warning: to assure the correct correct operation of the plugin system,
//you can't change the parameters of any predefined method: neither the
//names or the types. Also you must not add other parameters.
public override void OnClock(double time, uint sysCounter)
{
//Put your code here.
}
//Called when you press the Reset button, to reset the plugin to a
//initial state.
public override void OnReset()
{
//For initial setup of the plugin (but not the creation of interface
//objects), you can add your code here. The idea if you have to reset
//the pins state, you can use here the DrivePin() method. Example:
// DrivePin(int pin_number, bool Floating, bool Hi);
//
//Put your code here.
}
}
[/php]
Also here is the source code of PluginBase class (in the current Master branch):
[php]
using System;
using System.Windows.Forms;
using Gear.EmulationCore;
///@brief Name space for Plugin support.
/// Contains the classes that defines the plugin system: the plugin class structure itself,
/// the loading of plugins from XML files, the compiling and instantation of a plugin class.
namespace Gear.PluginSupport
{
/// @brief Base class for plugin support.
/// @details Define basic methods and attributes for plugins in GEAR.
/// Almost every window on GEAR is based on it.
/// @note See Asterisk's comments:
/// Source: <a href="http://forums.parallax.com/showthread.php/91084-GEAR-Propeller-Debugging-Environment?p=636953&viewfull=1#post636953">
/// Original thread on GEAR with explanation of plugin class</a>
public class PluginBase : UserControl
{
/// @brief Reference to PropellerCPU for the plugin.
/// @version V15.03.26 - Added reference to keep PropellerCPU internal to class.
protected PropellerCPU Chip;
/// @brief Default constructor.
/// @note Not to be used by plugin derived class, only by the Designer in MVSC.
protected PluginBase() { }
/// @brief Constructor to initialize with the PropellerCPU reference.
/// This avoid to declare in each plugin the following example code:
/// @code{.cs}
/// class PinNoise : PluginBase
/// {
/// private PropellerCPU Chip; //<== this line will not be necesary to declare in every plugin anymore.
/// ...
/// @endcode
/// @version V15.03.26 - Added.
public PluginBase(PropellerCPU chip)
{
Chip = chip;
}
/// @brief Title of the tab window.
/// @note Changed default name , based on a comment from Asterisk from propeller forum:
/// Source: <a href="http://forums.parallax.com/showthread.php/91084-GEAR-Propeller-Debugging-Environment?p=627190&viewfull=1#post627190">
/// Post #32 from original GEAR post</a>. It shows that the original name of the class
/// was "BusModule". Changed to the new name of the class.
/// @version V15.03.26 - change on the default name
public virtual string Title { get { return "Plugin Base"; } }
/// @brief Attribute to allow key press detecting on the plugin.
/// @note Mirror's: allows hot keys to be disabled for a plugin.
/// @note Source: <a href="http://forums.parallax.com/showthread.php/100380-More-GEAR-Improved-Emulation-of-the-Propeller">
/// Mirror Post for Version V08_10_16 in propeller forums</a>
public virtual Boolean AllowHotKeys { get { return true; } }
/// @brief Attribute to allow the window to be closed (default) or not (like cog windows).
public virtual Boolean IsClosable { get { return true; } }
/// @brief Identify a plugin as user (=true) or system (=false).
/// @version V15.03.26 Added member.
public virtual Boolean IsUserPlugin { get { return true; } }
/// @brief Points to propeller instance.
/// @note Asterisk's: Occurs once the plugin is loaded. It gives you a reference to the
/// propeller chip (so you can drive the pins).
/// @note Source: <a href="http://forums.parallax.com/showthread.php/91084-GEAR-Propeller-Debugging-Environment?p=625629&viewfull=1#post625629">
/// API GEAR described on GEAR original Post</a>
/// @version V15.03.26 - Changed to method without parameters.
public virtual void PresentChip() { }
/// @brief Event when the chip is reset.
/// Handy to reset plugin's components or data, to their initial states.
public virtual void OnReset() { }
/// @brief Event when the plugin is closing.
/// @details Useful to reset pins states or direction to initial state before loading the
/// plugin, or to release pins drive by the plugin.
/// @version V15.03.26 - Added.
public virtual void OnClose() { }
/// @brief Event when a clock tick is informed to the plugin, in clock units.
/// @param[in] time Time in seconds of the emulation.
/// @param[in] sysCounter Present system clock in ticks unit.
/// @warning If sysCounter is used only, the plugin designer have to take measures to
/// detect and manage system counter rollover.
/// @version V15.03.26 - Changed to method with two parameters.
public virtual void OnClock(double time, uint sysCounter) { }
/// @brief Event when some pin changed and is informed to the plugin.
/// @note Asterisk's: occurs every time a pin has changed states. PinState tells you if
/// either the propeller or another component has set the pin Hi or Lo, or if the pin is
/// floating.
/// @note Source: <a href="http://forums.parallax.com/showthread.php/91084-GEAR-Propeller-Debugging-Environment?p=625629&viewfull=1#post625629">
/// API GEAR described on GEAR original Post</a>
public virtual void OnPinChange(double time, PinState[] pins) { }
/// @brief Event to repaint the plugin screen (if used).
/// @note Asterisk's: occurs when the GUI has finished executing a emulation 'frame'
/// (variable number of clocks). Force is always true (this means that the call wants to
/// 'force' an update, this is provided so you can pass a false for non-forced repaints).
/// @note Source: <a href="http://forums.parallax.com/showthread.php/91084-GEAR-Propeller-Debugging-Environment?p=625629&viewfull=1#post625629">
/// API GEAR described on GEAR original Post</a>
public virtual void Repaint(bool force) { }
/// @brief Notifies that this plugin must be notified on pin changes.
/// This method is to isolate the access to the underline Chip.
/// @version V15.03.26 - Added.
public void NotifyOnPins()
{
Chip.NotifyOnPins(this);
}
/// @brief Notifies that this plugin must be notified on clock ticks.
/// This method is for isolate the access to the underline Chip.
/// @version V15.03.26 - Added.
public void NotifyOnClock()
{
Chip.NotifyOnClock(this);
}
/// @brief Drive a pin of PropellerCPU
/// This method is for isolate the access to the underline Chip.
/// @param[in] pin Pin number to drive
/// @param[in] Floating Boolean to left floating (=true) or to set on input/output (=false).
/// @param[in] Hi Boolean to set on Hi state (=true) or to set on Low (=false).
/// @version V15.03.26 - Added.
public void DrivePin(int pin, bool Floating, bool Hi)
{
Chip.DrivePin(pin, Floating, Hi);
}
/// @brief Set an immediate breakpoint.
/// This method is for isolate the access to the underline Chip.
/// @version V15.03.26 - Added.
public void BreakPoint()
{
Chip.BreakPoint();
}
}
}
[/php]
The "Logic Probe" window of Gear has been very helpful but : ...
After changing the Time Frame value, and pressing update, the probe window's output will sometimes slow to a "crawl".
If I change the Time Frame value and update, then close the binary file, and re-open the file the drawing speed is back to normal.
This doesn't always work though.
Any idea if this is a Gear / DirectX 9.0c / Windows Xp sp3 / VCS 2010 issue ?
As I remember, I didn't see the behavior in change on speed before, so it is important to have more data to reproduce it. Could you open a issue on https://github.com/davispuh/gear-emu/issues with a copy of your plugin code?
Without advance knowing more, I recognize the speed of emulation is sensible to the complexity of code inside OnPinChange(.) & OnClock() methods (specially the first one as it evaluate frecuently than the second).
I'm shocked that Microsoft would allow and apparently even support that...
World is getting crazy... I'm about to try Win10 on my Raspberry Pi 2...
But first, I'll have to download MONO and Gear on this Mac and see this for myself...
I have been experimenting with changing the _CLKFREQ setting in my spin files, that might have something to do with it ( ?)
I'll have to see if I can narrow down the exact sequence of operations / file used that causing it.
But, it's a little flaky. Had to launch using terminal and it took a long time to start.
The font is horrible and some menu items don't draw right. I'd guess that recompiling some way might fix that, but don't know.
My other trick for this Mac is VirtualBox. I've got Win10 running on it now and both it and VirtualBox are free downloads (for the time being anyway).
It does run better, more usable with VirtualBox... No surprise there.
Gear was a little confusing for me at first, because cog 0 was showing me what looked like byte code instead of assembly.
Maybe I should read something, but I think I figured out that it can tell if a cog is running Spin or Assembly.
If Spin, then shows byte code from HUB instead of COG RAM contents. I guess that's OK, maybe not what I would do though.
I wonder what PropGCC would look like. I'm guessing it won't try to show HUB code in that case, but will show the LMM or CMM kernel just as any other assembly code...
Joe
The two zip files at the bottom of the first posts are working. (They are under the graphic)
I'm glad that work is still being done on it. It's handy to have at times and it's the program I used for a few months and got hooked before I purchased any Propeller Hardware.