22nd of April 2021 Porting GS BASIC – to PiTrex (2)

Bobs code is split into different section, this is what I interprete from the layout (I haven’t programmed a PIC…)

  1. code for PIC environment (RTOS), a programming framework, supporting devices/periphals (USB etc)
  2. code for everything GS BASIC

The second point can again be split into:

  1. code that sets up and runs an application on the PIC
  2. code that is the basic BASIC interpreter
  3. code that “defines” the BASIC
  4. code that translates the “vectrex” part of the BASIC to something that Vectrex understands and feeds the
    DUAL RAM port

Code that I can port and use is probably mostly within bullet point 2. and 3. of the last list. How to run a “PiTrex” application is up to me. The translation to “Vectrexian” will be totally different, since we can’t even access the ROM/RAM of the vectrex from the PiTrex.

I have to watch out what kind of message passing is done between the different OO entities. But all that will come in time. My goal for today was the “directory” in Bobs zip file: /dev/GSBasic/GSBasic

As I understand it, here the BASIC core resides. From here the code is loaded/started and executed. This also includes the “immediateMode” where you can enter commands directly to the console…

Compiling this directory will enable many “standard” BASIC keywords (as defined in the file “BuiltInFunctions.cpp”), but non of the vectrex specific stuff. The vectrex specific stuff is defined in a seperate directory:


This contains all vectrex specials. The core BASIC can be enhanced with “external” commands – I have not looked at the functionality though, so I can as yet not explain the mechanisms behind it.

To me this seperation looks, as if Bob might consider releasing the GS BASIC also for other devices, and each will have their own BASIC flavour. Anyway in that directory all the “cool” vectrex stuff is defined, 3d stuff, camera support, Sprite/Vector support etc – but that will be approached at a future date. For now we go back to the snuggly “/dev/GSBasic/GSBasic” directory.

This directory contains about 60 files, about 30 *.cpp with their headers. My usual approach to “porting” is, to find files which do have the least dependencies to other files. In this case my first candidate was “GSBString.cpp” – yes an own “String” implementation, featuring some specialties. Here Bob introduces a concept of “shortStrings” which I guess has to do with perhaps limited ressources on a PIC? Dunno – luckily the ARM processor can run in little Endian mode – otherwise I had to reimplement some stuff, as the code relies on the internal endianness of the processor. But other than that there were no difficulties.

Actually most of the files went thru the “porting” quite well. I had to change some order within my own “osWrapper”, wrote 3 functions in an additional “cppWrapper”, which I think had to be implemented because of some “array” code handling inside some cpp library. But that actually was a matter of minutes, since I had “circle” open in another directory and did just a copy and paste of some circle code. This is nice, I can peek at circle at will, since that baremetal library is completely written in c++.

Actually – at first I had the MAD idea to go all the way, and I started to use cout << “bla”; instead of “printf(“bla”);
BAD, BAD idea! Streaming is nothing for the weak at heart porters. That simple “cout” uses about every function that c++ knows. Either implement a complete own version, put months in it – or let it be.
I just let it be – and I am glad I did. (BTW. circle also does do no cout πŸ™‚ ).

I had a little “fight” with the directory routines used in the BASIC, since it seems the PIC is also a little bit “baremetal” and our directory handling was not 100% compatible.
That was if I remember correctly the only time I actually changed some code of Bobs (removed the keyword “struct”, because I “typedef”ed the name dirent…) – nothing to worry about.

I ran again into some troubles with “malloc” and “free” and at the same time I forgot to wrap my headers in

ifdef __cplusplus
extern “C” {

Which gave me heaps and heaps of errors (since stupid c++ could not find my “C” function anymore). But after that – I could compile the complete directory without errors (or warnings). Yeah!

The last thing to do to actually TEST the thing was to build a “correct” main() function in GSBasic.cpp and try it on the PiTrex. Surprisingly that took my quite a few minutes – I guess excitement leads to small bugs. But after correcting those (and changing the “main()” call of the the vectrexInterface to actually support parameters) – following could be seen on my terminal:

I have not done any “input” – and output is done to the standard UART terminal. The blinking “Ready” – is thus repeatedly printed over and over again.

That was my “workload” today.



Tagged on: ,

2 thoughts on “22nd of April 2021 Porting GS BASIC – to PiTrex (2)

  1. Bob Alexander

    The “code that translates the β€œvectrex” part of the BASIC to something that Vectrex understands and feeds the DUAL RAM port” is actually in section 1, “code for PIC environment (RTOS), a programming framework, supporting devices/peripherals (USB etc)”.

    You’re right that the Vectrex32 code defines functions that are usable from BASIC. The idea is that BASIC is embedded into an application, like the Vectrex32, and the application can define application-specific BASIC functions.

    You’re also right that short strings were to save memory. You’ll come across some other hacks to save memory: implementing my own memory pools to save on malloc overhead, and overloading pointers to also store integers or floats (a real object pointer will have its lower two bits zero, since objects are allocated on 32 bit boundaries; so if one of those low bits is set, it tells the code to interpret the rest of the bits as an integer or float, instead of as a pointer).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.