jazzed said...
@Ale, I didn't really think about it. I figured Mac users only want GUI programs. The program works under wine with linux, but I've never tried it on Mac.
I can say the same about windoof users... I got a Mac because the GUI does not get in the way and I can have a fairly decent unix box in one. GUIs have to be well done if not they are just a PITA while the command line is always power.
After realizing the cause of the Unicode issue with SPUD, I also changed to ANSI and reloaded with ViewPort...it says my object has exceeded by 5374 longs...
I assume you removed the spud objects and calls before recompiling for ViewPort.
CassLan said...
Are you yourself using ViewPort?
No, I could never figure it out ... especially the part about why I need to write more code to use "conduit" .... I bought a ViewPort license, but I lost it in my PC failure last year. Maybe I should ask for another one.
Ale said...
I can say the same about windoof users... I got a Mac because the GUI does not get in the way and I can have a fairly decent unix box in one. GUIs have to be well done if not they are just a PITA while the command line is always power.
I prefer Linux for serious development I like command line for scripting and CVS among other things.
There are some things that GUI really helps though: my PASM debugger is difficult to use without full source visibility. Brad was nice enough to provide some list enhancements to make lines easier to find and I'm testing a GUI for that. It is much easier to use. I would release it because I think the multi-cog ability is useful, but features are missing and it's .net only.
I'll send you my sources if you PM me your email and promise not to complain too much about my coding style and why I chose to use a hashtable for some things [noparse]:)[/noparse] The Spin source does not use Brad's list source line enhancements ....
Jazzed, I'm sending you a shiny new ViewPort license now... I'm a big fan of scripting things from command line, but when it comes to debugging things the more information I have the more productive I am. That's why I wrote ViewPort...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hanno said...
Jazzed, I'm sending you a shiny new ViewPort license now... I'm a big fan of scripting things from command line, but when it comes to debugging things the more information I have the more productive I am. That's why I wrote ViewPort...
Hanno
Thanks Hanno. Maybe you can use some multi-cog PASM debugger code? It's command line driven and I have a simple GUI for it. Let me know off line.
I've decided to publicly release the Spud C source. See attached.
Here is the readme that summarizes the project files.
Package Contents:
Spud Debugger Source [noparse][[/noparse].ch] and Makefiles
BSTC compiler binaries
hashtable hashtable source files used for fast key/line lookup
spin spud debugger support spin files and SpudDemo.spin
Build:
Currently setup to build for cygwin if $(OSTYPE) not linux.
$ make clean
$ make
$ spud -c com8 spin/SpudDemo.spin
Makefiles:
Makefile choose Makefile.linux or Makefile.cygwin
Makefile.linux builds linux spud
Makefile.cygwin builds cygwin spud
Makefile.pload choose Makefile.load.linux or Makefile.load.cygwin
Makefile.load.linux builds standalone linux loader
Makefile.load.cygwin builds standalone cygwin loader
Sources:
Most headers provide doxygen tagged public API comments.
BSTC.h bstc parse-scraper function declarations
ComPort.h provides generic com port API for linux or cygwin comport
DebugLib.h debug library generic/common function declarations
History.h command history function declarations
inttypes.h contains integer typedefs used in most sources
Spin.h contains spin debug management and variable declarations
Spud.h main spud function declarations
UserCLI.h user interface function declarations
hashtable directory contains dynamic hashtable code and a public API layer.
Hashtable.h public API function declarations
BSTC.c This is the most complicated module and can be simplified
with the new file::linenum extentions added to BSTC list files.
The parser code can be very convoluted, but is 99% bug free.
This contains BSTC list file access methods. The entire file
is kept in a hashtable and lines are selectable by number --
funny way to do it :) I was too lazy to add a linked list
lookup which would probably speed up everything since there
would be less hash table keys.
ComPort.c This is the cygwin comport app driver selected by Makefile.cygwin
Uses only Windows API for COM. This limits COMx to 1 digit.
ComPort_linux.c This is the linux comport app driver selected by Makefile.linux
Uses only linux driver API for COM.
DebugLib.c Debug library ... Some customization is done with #ifdef for
msleep definition. buildSpin and loadSpin startup the debugger.
This has some file functions that were used early in development,
but are now are superceeded by BSTC file methods.
History.c Keeps user command history queue to allow repeat last command,
repeat command by line number, or last line ^search^replace repeat.
Spin.c Contains spin debug management and stack/variable interpetation
functions. This is the buggyist module. Interpreting the spin
stack dump is difficult. Sometimes the "n" command fails to skip
over a method call correctly by getting the wrong return address
or prematurely stopping. The "c" command can prematurely stop.
Spud.c Main spud startup and args interpretation.
UserCLI.c This is the main user interface parser/dispatcher. The interpreter
is merely a big switch statement.
At some point it would be nice to release this code publicly.
Enjoy.
Steve Denson (jazzed) Feb 2, 2010
thanks for the source. I'll make some minor modifications to improve 64-bit and MacOSX compatibility (pointers casted to int, intxx_t already defined in types.h and so on) and bring a patch. It looks good so far. I hope I can test it soon soon.
Thanks Steve for releasing the code- I'm working on big improvements to ViewPort's debugger- this could be perfect for PASM support!
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Comments
I can say the same about windoof users... I got a Mac because the GUI does not get in the way and I can have a fairly decent unix box in one. GUIs have to be well done if not they are just a PITA while the command line is always power.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
No, I could never figure it out ... especially the part about why I need to write more code to use "conduit" .... I bought a ViewPort license, but I lost it in my PC failure last year. Maybe I should ask for another one.
I prefer Linux for serious development I like command line for scripting and CVS among other things.
There are some things that GUI really helps though: my PASM debugger is difficult to use without full source visibility. Brad was nice enough to provide some list enhancements to make lines easier to find and I'm testing a GUI for that. It is much easier to use. I would release it because I think the multi-cog ability is useful, but features are missing and it's .net only.
I'll send you my sources if you PM me your email and promise not to complain too much about my coding style and why I chose to use a hashtable for some things [noparse]:)[/noparse] The Spin source does not use Brad's list source line enhancements ....
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Here is the readme that summarizes the project files.
thanks for the source. I'll make some minor modifications to improve 64-bit and MacOSX compatibility (pointers casted to int, intxx_t already defined in types.h and so on) and bring a patch. It looks good so far. I hope I can test it soon soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
I am sure Ale and others will extend it. No time for me to look - I would get distracted from other tasks at hand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer