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:

“/dev/Vectrex/SmartCart/SmartCart/firmware/src”

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” {
endif

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.

Cheers

Malban