24th of April 2021 Porting GS BASIC – to PiTrex (4)

Today I coded nearly “nothing”. First I had to do much around the house. Second – I researched the Vecterx32 BASIC a little closer:

Since I never programmed a PIC and I do not have much experience (none) with RTOS – and I only glimps at code pieces I need “now”… I can sometimes only guess, what is keeping things together.

I was wondering how the different “pieces” of software go together… and I think I found it deep in one of the directories I never needed to look at… there is a directory called:


and within that directory is what I guess the “system setup”. The PIC seems to be running an OS called RTOS, the operating systems has a task scheduler and is started with 4 tasks:

  • system task
  • console task
  • vectrex task
  • app task

Without going into any code, my guess is:

System task is for the OS “housekeeping” (USB accesses, File systems…), console task for basic i/o / terminal and user input output, app task runs the actual user program (in this case the BASIC) and here a special “vectrex task”, which handles talking to vectrex, putting commandlists into the Dual RAM and synchronize things.

The “splitup” into different tasks running more or less independendly got me a little bit mixed up. I have been programming pure vectrex and piTrex baremetal for too long – I had nearly forgotten about message passing, callbacks and different tasks (processes)…. and I wondered, why I could never find a section within the BASIC, that does the actual i/o :-).

I also realized, that I have to implement something into my own VectrexInterface which I have been “talking” about – but not yet realized: “persistent vectors”

Implementing those will greately ease any further Vectrex32 BASIC porting. Take a look at this little BASIC sample:

call IntensitySprite(72)

textSize = {40, 5}
call TextSizeSprite(textSize)
instructions = {{-50, 90, "INSTRUCTIONS"}, _
                {-80, 70, "JOYSTK IS THRUST"}, _
                {-80, 50, "BTNS 1&2 ROTATE"}, _
                {-80, 30, "BTN 4 EXITS"}, _
                {-80, 1, "PRESS BTN 1 TO START"}}

call TextListSprite(instructions)

' Wait for button 1 or button 4
controls = WaitForFrame(JoystickNone, Controller1, JoystickNone)
while controls[1, 3] = 0 and controls[1, 6] = 0
     controls = WaitForFrame(JoystickNone, Controller1, JoystickNone)

What the orange code actually is – it is a vectrex frame loop. In the common vectrex sense it displays nothing, but just waits for a joystick input.

In the Vectrex32 sense – all text output is initialized beforehand as persistent “output” elements, which get redisplayed, till the screen is cleared or single elements are removed.

As of now, the vectrexInterface does not per default support such constructs. But I have been talking about supporting this for quite some time now… So… this is what I’ll do next.

Add “persistent vectors” to the vectrexInterface and THAN return to the Vectrex32 BASIC.
No worries, that (if I find the time at all) will not take long. Since even now the complete output is done using a “pipeline” which contains (in Vectrex32 BASIC speaking:) compiled elements – I just have to flag them as persistent and than to not delete “flagged” elements.

If I do not have to much houskeeping activities on my plate tomorrow, we might see that “instruction” loop displayed on a vectrex :-).


Tagged on: ,

3 thoughts on “24th of April 2021 Porting GS BASIC – to PiTrex (4)

  1. Bob

    Wow, you’re coming up to speed really well! I’ll have to obfuscate my code more next time. 😉

    Everything you’ve surmised is correct.

    Microchip, the company that makes the PIC32, has a framework library called Harmony. Their IDE has a “wizard” that generates Harmony code. That’s what you see in the system_config subdirectory. It includes helper functions for accessing the hardware, an interface layer to the RTOS, and the boilerplate code for creating the four threads.

    The RTOS I use is a third-party product called FreeRTOS. That’s because it’s an RTOS. And it’s free. Clever name, huh?

  2. Phillip Eaton

    It’s very interesting to see this analysis, thanks for posting it. Is RTOS time-sliced like UNIX or cooperative “Round Robin” like Forth usually does it? (It’s a shame the the original Pi CPU was superseded so quickly, I thus can’t suggest a multitasking bare metal Forth OS to try, there’s only pijFORTHos, and that appears to be single tasking only 😉 )

    I’ve often wondered if a simple persistent vectors system would be useful for regular Vectrex programs, probably based on a 50Hz interrupt like you and Graham demonstrated, when you have a long running process. In my head, it seems quite doable and might make it easier to program for raster/frame buffer converts.

    Actually, I’m more than wondering, my current project has processing that takes much longer than 20ms, so, unless I want to blank the screen (probably acceptable), I would need to decouple the screen updates from the core game processing and I/O handling.

    Really, I guess I need everything I/O related running on interrupt reliably in under 20ms i.e. the vector draw to display from a persistent source, controllers and sound, then all the processing would be done in the main loop with what ever time was left.

    I have a few other game elements to work through before I get this – I don’t have anything running on screen yet, everything is via the interactive Forth terminal – but when I do, I’ll be delving into the code that you and Graham did for his “lines game”, that will hopefully guide the way for me.

    I’m only a novice with real assembly programming and I’m guessing that if I’m going to use interrupts, I’ll need to change the way the wait_recal works – could be a challenge!

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.