Computer Motivator

If you don't know what a computer motivator is by now, then you have been reading too many textbooks and not watching enough TV.

Public Chat
Similar projects worth following
There are many issues addressed in this project, which will focus on providing improved software tools for developing better robots, of all kinds.

Lately, code bloat is one of many systemic problems as the PC world continues headlong into the realms of mangled code, which they want you to think is actually managed code, but if the management (read: the shirts) can't understand it, or explain it, or fix it, well? This has led to poor quality software, with serious consequences, like the crash of at least two airliners; and not just "unmaintainable" code, annoying reboots, wasted energy, more bad patch Tuesdays, security breaches. etc.

So what is a computer motivator? Sci-fi writers love to invent things like "astrogators",
"positronic" or mnemonic memory circuits, and of course "motivators." Thus, there might be 6502 reasons why every robot needs one, even if it doesn't exist. Or maybe it does. Now.

Stay Tuned!

O.K., just getting started here.  There is a project that I started on GitHub which you can find under the project name (there), where it is presently titled "rubidium", and as far as rubidium and my C++ port of the propeller debug terminal, that project is what it is; but as far as the motivator is, well that is where is THIS saga begins, or will begin shortly, after a brief message from the Propeller Debug Terminal C++ version release notes.

Notes for Propeller Debug Terminal.

This is a C++ port of the Delphi code originally posted by Chip Gracey to the Parallax forums. Many issues are addressed in this code base that I hope others will find useful in developing their own Parallax Propeller P1/P2, Arduino or other microcontroller-based projects. Serial port interfacing using the FTDI USB hardware conversion is well developed, so that part of the code base can be used as a part of a framework for other developers who trying to develop their own bespoke applications. Thus, if you have been getting that dreaded "port in use error by another application" with some other program written in Java for the Arduino (for example), and requiring you to reboot or die, then you will find reasonably correct COM port interfacing code example here which should help banish that issue -- for once and for all. Just in case you are trying to build a real application ... and not just run test cases in the manufacturer's sandbox.

Likewise, many people are going to want to go beyond the typical ANSI terminal mode, which is usually all that is available when remotely debugging or otherwise interfacing with experimental external hardware. Now you should be able to incorporate UNICODE based symbols for things like chess fonts, Astrological symbols, Emojis etc. Additionally, providing for improved accessibility for users who need special input device (not provided) for reasons of disabilities will also be possible. Of course, if you are already using, or have used an IME (Input method editor) with another application, then you should have no problem adapting the Code base for use with Arabic, Chinese, Greek, Japanese, Mayan, or any other context that requires UNICODE awareness.


Intrinsic functions discussed in the project logs, needed to compile the Pascal style WRITELN function in C++. Copyright 1995-2021 Gerold Lee Gorman. GNU/MIT/LGPL.

plain - 10.27 kB - 10/05/2021 at 05:52


ucsd pascal license.txt

This file contains the official terms of the license for UCSD Pascal. Excerpts of UCSD Pascal may be referred to in this project for educational and/or research purposes. Note that the projects "Frame Lisp" and "Rubidium" do NOT use ANY UCSD code, nor are they derivative works thereof.

plain - 1.83 kB - 10/05/2021 at 05:48



This is the source file for the C++ code needed to implement the Pascal-style SET type, As discussed in the log entry "Once upon a Midnight Dreary" NOT provided by third parties.

plain - 2.12 kB - 09/27/2021 at 09:51



This is the header file for the C++ code needed to implement the Pascal-style SET type, As discussed in the log entry "Once upon a Midnight Dreary" NOT provided by third parties.

plain - 912.00 bytes - 09/27/2021 at 09:47



This is the header file for the C++ code discussed in the log entry "Pay no attention to the man behind the curtain", and is needed to support Pascal style IO as well as other intrinsic operations. NOT provided by third parties.

text/plain - 4.74 kB - 09/27/2021 at 09:43


View all 6 files

  • 1 × Parallax Propeller P2 Evaluation board (recommended) or P2 Edge Dev. kit.
  • 1 × Standard "four inch" blue electrical box from Home Depot.
  • 1 × Microsoft Visual Studio 2005 or later to compile the source code.
  • 1 × Legacy servos, motors, sensors. Optional: Parallax Boe-Bot or equivalent.
  • 1 × (Optional) Other Robotics Hardware as desired, such as Raspberry Pi or Arduino based system or subsystems.

  • First star on the right, then straight on 'till Morning.

    glgorman10/07/2021 at 03:56 0 comments

    O.K., UCSD p-system Pascal is now compiling under Visual Studio to the point that I can load a Pascal file in a Microsoft MFC CEditView derived class, and then attempt to compile it, even though I only have about 2500 or so lines converted so far, i.e., mostly by using find and replace in a word processor and then manually fixing the VAR statements and the WITH statements.  Had to write my own versions of BLOCKREAD, IDSEARCH, and TREESEARCH, among other things; as these were nowhere to be found in the UCSD distribution.  TREESEARCH I already had, in my bTreeType class, but my earlier version uses recursion, so I redid that one.  IDSEARCH is the one that is going to be more interesting since the whole concept of checking to see whether a token is on a list of keywords and then calling an appropriate function is also something that I am doing with Rubidium.  Thus the Pascal version looks like this:

    #include "stdafx.h"
    #include "afxmt.h"
    #include <iostream>
    #include "../Frame Lisp/defines.h"
    #include "../Frame Lisp/symbol_table.h"
    #include "../Frame Lisp/btreetype.h"
    #include "../Frame Lisp/node_list.h"
    #include "../Frame Lisp/text_object.h"
    #include "../Frame Lisp/scripts.h"
    #include "../Frame Lisp/frames.h"
    #include "../Frame Lisp/frames1.h"
    #include "../Frame Lisp/extras.h"
    #include "compiler.h"
    namespace SEARCH
        char *keywords[] = 
        frame m_pFrame;
        symbol_table *m_keywords;
        void RESET_SYMBOLS();
        void IDSEARCH(int &pos, char *&str);
        frame &f = SEARCH::m_pFrame;
        symbol_table *t=NULL;
        t = f.cons(keywords)->sort();
         m_keywords = t;
    void SEARCH::IDSEARCH(int &pos, char *&str)
        char buf[32];
        symbol_table &T = *SEARCH::m_keywords;
        size_t i, len, sz;
        sz = T.size();
        token *t;
        pos = -1;
        for (i=0;i<sz;i++)
            t = &T[(int)i];
            len = strlen(t->ascii);
            if (strcmp(buf,t->ascii)==0)
    //            PASCALCOMPILER::SY;
    //            PASCALCOMPILER::OP;
    //            PASCALCOMPILER::ID;

    Now as it turns out, on the Apple II, we are told that this function was actually implemented in 6502 assembly; which is why it is not in the UCSD distribution.  What it does of course, is check to see whether the symbols that are extracted by INSYMBOL are in the list of Pascal keywords, and then modify a bunch of ordinal values, enumerated types, or whatever in the global variable space; which is exactly what I need to do, but don't want to do in Rubidium; with respect to not wanting to use global variables, that is.  That would be TOO simple.  Even if this should turn out to be a refactoring job from hell, the payoff, in the end, will be well worth it - once I have clean C code that can be compiled, or transmogrified, or whatever to also run on the Propeller, or the Pi, or an Arduino, etc., such as by trans-compiling C to Forth, or C to SPIN, or C to Propeller assembly (PASM) or perhaps a mixture of all three.  Oh, and let's not forget about LISP.

  • Pay no attention to the man behind the Curtain.

    glgorman09/26/2021 at 22:37 0 comments

    That is a whole subject unto itself.  The notion of the "curtain" that in effect separates the developers from the users, on the one hand, is generally there for a good reason, like if a full "debug version" of a program runs 50x slower than its release counterpart.  But there are also problems with software - where "Uh oh! something bad happened!" which you never want to have to happen with your flight control system, or your robotic surgery unit, or your previously self-driving car, or robotic whatever, whether "it", whatever "it is" tried to re-enact a scene out of the movie "Lawn-Mower Man", or "Eagle Eye", or not.

    So let's talk about debugging, code portability, and code bloat.  Here is a fun piece of code, but what does it do, what was it intended to do, and what can it really do?

    typedef    enum { CHAR1, CHARPTR1, DOUBLE1, FLOAT1, INT1, SIZE1 } PTYPE;
    class deug_param
        PTYPE    m_type;
            char    ch;
            char    *str;
            double    d;
            float    f;
            int        i;
            size_t    sz;
        deug_param (char arg);
        deug_param (char* arg);
        deug_param (double arg);
        deug_param (float arg);
        deug_param (int arg);
        deug_param (size_t arg);

     Before we answer some of those questions in further detail, let's examine some of the implementation details.

    deug_param::deug_param (int arg)
        m_type = INT1;
        i = arg;
    deug_param::deug_param (size_t arg)
        m_type = SIZE1;
        sz = arg;

    O.K., before you say "nothing to see here, these aren't the droids you are looking for", take a closer look.  What this little snippet of C++ does is capture the type of any variable that we want to pass to it, which allows for run-time type checking of floats, ints, strings, etc.  This means that we can do THIS in C++! 

    if (NOISY)
        else if (LIST&&(ERRORNUM<=400))
    if (LINESTART==0)
        + (size_t)(LINESTART.val)-1);
    WRITELN(OUTPUT," <<<<");
    WRITE(OUTPUT,"Line ",SCREENDOTS,", error ",ERRORNUM,":");
    if (NOISY)
        WRITE(OUTPUT," <sp>(continue), <esc>(terminate), E(dit");
        char param[] = ":";
    .... etc ....

     Now like I said earlier with the right set of macros and some clever "glue" the C/C++ pre-processor+compiler can be made to chow down on Pascal programs, quite possibly without modification.  There is some debate of course, as to whether the C/C++ pre-processor is actually Turing complete, since there is something like a 64 character limit on labels, and a 4096 character limit on line length, IIRC; so that "at best" the pre-processor is considered by some to be a kind of "push down automation".  Yet, as I said, with the right "persuasion" the grammar of any well-defined programming language should be able to be transmogrified into any other.

    Oh, and by the way - here is how you get, at least in part, the C++ pre-processor to chow down on Pascal WRITE and WRITELN statements, even if I haven't fully implemented Pascal-style text formatting, yet.  (it's not a high priority).

    First, we use our "debug parameters class" to capture variable types during compilation.

    void WRITE(int uid, deug_param w1)
    void WRITE(int uid, deug_param w1, deug_param w2)
    void WRITE(int uid, deug_param w1, deug_param w2, deug_param w3)
    .// etc ...
    // NOTE that this can also be done with templates or macros.

    Then we use another version of _WRITE or _WRITELN which...

    Read more »

  • Introducing "General Concept"

    glgorman09/23/2021 at 21:40 0 comments

    Early on in this project I said that there would be robots, and by that I meant robots, in the plural form, not singular.  Even though the focus of this project is primarily oriented toward AI development, data acquisition, hardware interfacing and control systems, every now and then as Han Solo would say, "Sometimes I might even surprise myself."

    So here now we finally meet General Concept.

    This could actually get very interesting.

    Since the 3 d printed gear might also work as an optical diffuser, useful for such things as omnidirectional infrared, or just lighting up really nice when the robot is speaking or preparing to move.

    That doesn't mean that I have abandoned the concept of the Boe-dozer, by any means.  There are plenty of pathways worthy of exploration.  Now getting back on track with the software side of things should be my main focus, in the time remaining.  Stay tuned!

  • Where have all the Flowers Gone?

    glgorman09/19/2021 at 18:22 0 comments

    I still haven't decided whether I should try to go the "Boe-dozer" route like I was thinking about earlier.  Or maybe I could mount a small NTSC-compatible video camera as if it was a part of some kind of turret, like a miniature "tank."  It would also be nice if I had a "bigger barn", so as to be better equipped for dealing with issues of scale when planning and/or doing live modeling, instead of just talking about running things in "simulation".  This is the post that I was going to entitle "Go Ask Alice (when she is ten feet tall), but I changed my mind - after reading some of the news about Afghanistan, and how a relief worker and seven children were recently killed, and now the Generals just admitted that "no explosives" where found, and no link to ISIS existed.  Maybe this isn't the place to be political, or else I could have said something about being "Wasted away again in Margaritaville" since "I read the news today oh boy" about empty Tequila bottles being found strewn about in the new Air Force One.  End of rant.  Back on topic:  If robots become a part of out daily lives, and AI is going to be relied upon to make life or death decisions, well - are we ready yet to meet our new robot overlords? 

    O.K.. off of the rant now, and back on topic - I hope!  Imagine a robot where we can give it commands - like "IDENTIFY THE ROOM WHICH CONTAINS THE CRYSTAL PYRAMID BUT DO NOT ATTEMPT TO ENTER ANY ROOM WHERE TROLLS MIGHT BE PRESENT."  This sort of thing is very doable with game engines of the type that were used to implement classics like "Adventure" "Zork" or "The Wizard and the Princess".  Provided that is that we have a way of building an accurate model of the world that we want our robots to exist or CO-EXIST in.  Elon Musks' recent video about how Dojo will work was very interesting in several ways, like how the model view for autonomous self-driving cars is supposed to work.  It's one thing to talk about OpenGL and graphics, yet there is so much fertile ground for exploration with programs that might try to generate an accurate point cloud by actual exploration, and then proceed to the problem of defining vertex information, line sets, bounding planes, then proceeding to the minimum convex hull, as well as collision domains, with object recognition thrown in along the way.  The Boe-Bot is, of course, a bit too big to be able to enter and leave the various rooms of the model house that I built on its own, which is just another Goldilocks problem, I suppose, just as it is a bit small to be able to competently navigate a real world labyrinth.  And I could still use a bigger barn.


    Somewhere. I have the source code for an old Eliza program that I converted to run under my Frame Lisp APIs, so I am fairly certain that I can get some SHRDLU like functionality up, but honestly, this thing is huge.  The implications for this technology are even larger.  Consider for example the economic consequences if an elderly person falls and breaks their hip, and then isn't strong enough even after hip replacement surgery to use a walker or a wheelchair on their own.  The cost of nursing home care in the United States can run anywhere from $5000 to over $25000 per month, and Medicaid does not kick in until after you sell your stocks and other assets, and even then they can (or at least will try to) put a lien on your house (or your parent's house), and now how much does that add up to for example - if that sort of thing goes on for three...

    Read more »

  • Once Upon a Midnight Dreary.

    glgorman09/18/2021 at 15:33 0 comments

     What is a programming language, and how is it specified?  The following set of macros will give the user a head-start on getting almost any C compiler (actually the pre-processor) to chow down on Pascal Programs.  As nearly always, or so it seems, there is still a lot more work that needs to be done, even if the only purpose of this exercise (for now) is to prove a point.  Indeed, before we can even think about what a programming language is; maybe we need to address the issue of "what is a computer program?"

    #define {            /*
    #define }            */
    #define PROCUEDURE    void
    #define BEGIN        {
    #define END            }
    #define :=            ASSIGN_EQ
    #define    =        COMPARE_EQ
    #define IF            if (
    #define ASSIGN_EQ        =
    #define COMPARE_EQ    ==
    #define THEN        )
    #define REPEAT        do {
    #define UNTIL        } UNTIL_CAPTURE
    #define UNTIL_CAPTURE    (!\
    #define ;            );\
    #undef            UNTIL_CAPTURE
    #define ;            );
    #define    = [        = SET(\
    #define    ]        )\
    #define    )        \
    #undef    =         [\
    #undef    ]
    // so far so good ....
    #define    WITH        ???????? 

     But first, lets us consider how some hypothetical Alice can now convert her Pascal programs from that class she took in high school to run on Bob's C compiler, which hopefully is lint compatible, on the one hand, and which might also have a C to Spaghetti BASIC runtime option on the other.  Or can she?  Probably not with Visual Studio Code, at least in its present incarnation; and this sort of thing sadly, will result in an even bigger nightmare with Microsoft's purported AI approach to managing or I hinted at earlier,, "mangling" up code libraries on Git.  It is as if we should be entering a new era of code renaissance, but to paraphrase Ted Nelson, who once said, "no matter how clever the hardware boys are, the software boys will piss it away" ... well, I will leave that as an exercise to the reader to figure out.

     Despite the fact that you can get about a million hits on any search engine if you search for information about "context-free-grammars", it appears that a simple macro language based on the C pre-processor might indeed be Turing complete, at least in principle, if we had some improvements to the overall concept defining what a context is, or whether contexts should, in general, be understood in a dynamic sense, that is to say if that can be done in a well-defined way.  The Pascal WITH statement might cause a simple macro-based translation scheme, fits since the preprocessor would have to have a way of maintaining a restricted symbol table so that it could match otherwise undeclared identifiers with the correct object forms.  This is deeper than the problem with sets, but it is related to another issue and that is what is whenever we encounter a group of statements like SET S = [2,3,5]; S = S + [7,11,13] we try to transform the latter statement into something like ((SET)S) = ((SET)S)+SET(7,11,13); in effect enforcing a C style cast on every variable everywhere in the translation.

     This has no effect on any subsequent C compilation, Footnote: consider int a,b,c; (int)a = (int)b + int(c); which should compile just fine in any dialect of C.  yet it does give a lispy feel to the output, or maybe I should suggest Python?  That is to say that if an intermediate representation of a program according to some translation scheme explicitly required that every occurrence of a parameter be tagged with type information; then that would give the meta language at least some of the properties of a reflective language, which in term implies that even though C/C++ does not explicitly support reflection, we can add reflection via a suitable set of library routines, which would be invoked as appropriate when converting algorithms which can be specified according to some meta-language. 

     Nothing is better than steak and eggs for breakfast; but stale cereal is better than nothing, right?  Does it, therefore, follow that if A is better than B and B is better than C that A is also better than C?  Maybe somewhere...

    Read more »

  • All Mimsy were the Borogoves

    glgorman09/17/2021 at 18:51 0 comments

     I am not sure if "mimsy" is quite the way to describe how I am feeling right now.  I was trying to 3D print a planetary drive, using a graphics package I wrote from scratch, even though I used a commercial 3-d printer to do the actual print, and I ended up with a solid block of gear-ness.  Maybe I should entitle this post ".. and did gyre and gimble in the wabe."  Hopefully, I will have better luck next time, especially if I can conjure up a design for some kind of multi-axis gyroscopic platform, which might be used not so much as a part of an IMU (inertial measurements unit) - since we have GPS and MEMS (!!) accelerometers for that!  Yet, what about giving the Boe-Bot a multi-axis stabilized camera platform, based on the traditional model of the type of stationary platform as was typically used in the IMU in the Apollo spacecraft era.?

     Right now, I am nowhere near doing that, as least as far as "implementation" is concerned, or perhaps it might be easier than I might think.  So where are we?  Perhaps the Boe-bot isn't very good at navigating rough terrains, such as brickwork, or shag carpet, and that makes me think of something otherwise out of the box and as if out of nowhere in this context, but which comes to mind, anyway.  How about a Boe-Dozer?  Not a bulldozer, because it's not a bulldozer at all, as it is more like a steam roller, that is to say, if I put that big gear on the front, it should be an easy mod.  Or I can try to finish the oscilloscope code and get a camera mounted so that I can actually control this thing over Bluetooth.

     Maybe this is finally a good time to open up this page for comments.  What does the Hackaday community really need right now?  A C++ compiler for the P2?  A LISP for P2/Arduino that is "just enough lisp" to be able to run ELIZA/SHRDLU?  Or a crystal skull that says "good evening" to passers-by on Halloween?  (and then engages them in conversation sort of Eliza-like) I don't think I can quite pull that one off, just yet.  The crystal skull part that is.

     A SHRDLU-like "planner" with speech recognition and an Eliza-like interface is very doable with 3-rd party open source tools.  I just need to finish Frame-Lisp and get the oscilloscope and spectrum analyzer interface running. 

  • Here is another clue for you all ...

    glgorman09/13/2021 at 16:45 0 comments

     I promised a clue for those who are searching for the labyrinth.  Here is your first clue.  I could have titled this post "up up and away", but I DIDN"T!  The Reno Balloon Races event was just this last weekend (read yesterday and the day before as of 9/13.2021).  It is so easy to imagine so many possible uses for a simple robotics package, besides the overabundance of hexapod and wheel bots.   Now, of course, I am kicking myself in the head for not thinking ahead, i.e., so as to perhaps get permission to fly a drone at the event, or some kind of remote-controlled blimp.  I don't know if they would allow that, with up to 100 manned balloons in the air all at once.

  • Imagine a Maze of Twisty Little Pathways.

    glgorman09/13/2021 at 16:04 0 comments

    In Reno Nevada, if you know exactly where to look (stay tuned for a hint), you can find this lovely labyrinth.  Which of course would be an ideal maze for a small robot to solve.  Even though the terrain might be a little bit rough for a small robot like a Boe-bot, but imagine the possibilities.

    This is a kind of an epiphany of sorts.  Since a very long time ago, I implemented my own open OpenGL Stack or a least a subset of OpenGL entirely from scratch, and one of the things that I thereupon decided to experiment with was doing things like calculating "Cauchy's Integral Formula", for those who are familiar with the theory of complex variables.  Getting at least some hooks into some OpenGL routines appears to be very doable on the Parallax P2 chip, with its built-in HDMI, VGA, and standard NTSC/PAL or whatever capabilities., and of course there is the Propeller Debug Protocol, so that if a robot could be built that builds a kind of "OpenGL" like world view, while it does the job of exploring its environment.  Ah, the possibilities!

    Shades of Westworld?  "How do I find the center of the maze?"  "What if the maize isn't for you?"  What if "they" are supposed to be the ones who "think differently"?  Oddly enough, imagine a game where there is a hidden treasure behind the front door on the right, but there also might be a bomb, or some hungry trolls that have an appetite for human flesh, eagerly awaiting to pick the flesh from the bones of any mere mortal who tries to take this game too seriously.   Ouch.  The only way to disarm the bomb, or be prepared for the trolls, is to find the center of the maze.  This is easy for a simple spiral, but probably nonetheless quite difficult for an AI, even in simulation.  

    Interestingly enough, if you understand "Cauchy's Integral Formula" from calculus then you know that it is possible to compute an integral, i.e., the integral of dz/(z-z0) along some path in the complex plane and that the result should be 2*pi*"square-root-of-minus-one" times the number of times that (z-z0) takes on the value zero INSIDE the path.  This means that one can calculate whether a given point is either INSIDE or OUTSIDE an arbitrary enclosed region!  And yes, it does work for a really big, weird spiral, that is to say - if you have the map.

    O.K.., I admit that this is a HARD problem.  Probably very hard even for a Tesla Robot. 

  • Follow the Yellow Brick Road

    glgorman08/28/2021 at 04:08 0 comments

     Somewhere in the build instructions for the hardware part of this project I was also discussing how I am working on fixing up a sub-dialect of the programming language LISP that i actually developed, something like 25 years or so ago, as a part of a chat bot engine.  Well, in any case - I did some updates today to the codebase which is now (at least in part) on GitHub, so this would seem like just as good of a time as any to discuss the role of LISP, in the C++ port of Propeller Debug Terminal. 

     Basically, the debug terminal responds to a set of commands that can be embedded in a text stream that ideally runs in a side channel alongside the regular printf/scanf I/O semantics that a "normal" ANSI C program might make use of when running in a terminal mode.  Hence the command set looks something like this, and that is why LISP is so nice, even if it is written in C++, because at the end of the day it would be so nice to be able to simply CONS a symbol table, and then MAPCAR the symbol table onto a list of GUI commands, so that command processing can be done by tokenizing the input stream and generating the appropriate callbacks or messages.

    char *command_proc::debug_tokens[] = 
    void command_proc::reset_debug_symbols()
        command_proc pdbg;
        frame &f = *(pFrame->get());
        symbol_table *t=NULL;
        t = f.cons(command_proc::debug_tokens)->sort();

    So this is a screenshot of the raw debugging stream coming from the P2 chip while running a four-channel oscilloscope program, and the hexadecimal data is oscilloscope data being streamed live.  It is just not being plotted .just yet.   Real soon now.

  • Having Problems with your Droid?

    glgorman08/27/2021 at 00:13 0 comments

    Uploaded some images to the gallery of a Boe Bot getting ready for a P2 conversion, or maybe an alternative Arduino enhancement. So many possibilities.  A good hack of course starts with whatever is on hand without having to go to Radio Shack (remember those?) and spend any additional $$$.

View all 11 project logs

  • 1
    Getting Started

    Yes, this is a hardware project, and there will be robots, and things to try to get robots to do, and this project page will be updated regularly, if not daily, during the contest period.  So stay tuned!

    Imagine a robot that uses a Propeller chip as its brain, and if the robot has a program where it tries to map out a maze that it is trying to solve; wouldn't it be nice to be able to "see" into the "mind" of the robot, at it builds its "world view model or database!?"

    On the software side, you will need Visual Studio 2005 or later to compile the source files. Simply create an MFC project that supports Document/View Architecture with the Multiple Document and Multiple View settings, and then incorporate components that you are interested in from this repository. Thus, the purpose of this application is, in part, to provide some supportive tech to those who might already have a working application in the pipeline, but who are also fighting some show-stoppers issue(s) that are preventing their bespoke application's proper integration into a GUI based environment.

    Note that the full Graphical Debug protocol provided by PNUT (which is a separate commercial product provided by Parallax) is not yet fully working but is a work in progress. The GUI portion is working, but there are still some issues with managing the message map architecture, i.e., the message crackers and translators that will route Parallax debugging protocol messages to the correct GDI or OpenGL components. This will eventually be done in a sub-dialect of Lisp, called "Frame Lisp".

    In the meantime, you can nonetheless access the native FORTH interpreter which is built into the Parallax P2 Propeller chip directly, or you can upload binary images built with other tool sets - so that you can use applications built with other compilers/tools with this framework, and then interact with those programs using a GDI aware terminal program that you have the source code to and which can be customized as you see fit.

    To get the oscilloscope features and other graphical debugging features you will need to include a library called Frame Lisp, which has not yet published, as it is being updated for Unicode support, and undergoing further debugging. This will be remedied in a future update, "real soon now." In the meantime, the boilerplate needed for MFC based Document-View architecture is functional to the point of being able to upload binaries to the propeller P2 hardware and interact in text mode via keyboard and mouse if desired, as well as create and manage multiple debugging windows.

    Port speeds of up to 3Mbits/sec. are known to be reliable with the available and tested hardware. If you are not wanting to wait for Frame Lisp, you can also find some assembly language code written by Chip Gracey at Parallax, which was published along with the original Delphi code mid-summer of 2020 and made available on the Parallax forums. The original assembly language routines could be reworked and recompiled under MASM, and then linked to their corresponding C++ counterparts, instead of the original Delphi.

    Eventually I will be adding additional features, such as Audio/MIDI streaming, more fully functional oscilloscope and spectrum analyzer modes, OpenGL support, as well as project management and library management functions, all within a GUI environment that will immediately seem familiar to anyone who has used an IDE in the past.

View all instructions

Enjoy this project?



glgorman wrote 09/17/2021 at 19:16 point

O.K. Opening up this part of the project for comments, discussions, etc.  Thoughts?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates