25th of April 2021 Porting GS BASIC – to PiTrex (5)

I will not say today was “wasted” – since again I learned quite a lot. But on the other hand despite the image saying otherwise – I am nearly at same stage as yesterday.

Yes, what you see in the image is the “autobas.bas” loader, yes it starts and also yes you “can” start BASIC programs with it.

Inspite of that – it is not working as it is supposed to.

Ok, first things first. After I went hiking with my girlfriend… ok, not soooo first… later when I started programming…

I implemented within my vectrexInterface “library” the said “persistent” vectors and I thought I would do that in preparation of BASIC to come. But I still had not completely understood how the BASIC works. I’ll try to explain:

• the BASIC interpreter is a “standalone” app on the PIC
• it can be enhanced with user defined constants and functions
• all vectrex stuff is “user defined”
• each user defined function can “access” the vectrex
• the access to the vectrex is realized with “VectrexCommands”
• Vectrex commands are really an abstraction layer between the BASIC and the actual communication with the vectrex ( – and as it turns out – the current pool of instructions that must be repeatedly issued to the vectrex)
• the vectrex task, mentioned yesterday takes these commands and
  compiles these commands to actual 6809 code, that is put into the dual port memory

And here is where I went wrong in my thoughts before. The empty wait block, I showed yesterday:

while controls[1, 3] = 0 and controls[1, 6] = 0
     controls = WaitForFrame(JoystickNone, Controller1, JoystickNone)
endwhile

… I thought that this ment, that the current active display elements would not change anymore and were static. So that I just had to redisplay them.

If that had been true, I could have taken a shortcut, and NOT implement the “VectrexCommands”, and needed only to implement the user defined BASIC functions. (That is what you see in the image above).

The definition:

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)

… of the instructions, and the calling of the TextListSprite() prepare the instructions for output and put them on the screen (persistently). Yes – but not “unchangeable”.
You can change the “data” of the TextListSprite without having to reissue a call, or a notification of any kind.
Within the WaitRecal loop, you could do:

    if controls[1, 2] != 0 then
         instructions = {{-50, 90, "INSTRUCTIONS"}, _
                {-80, 70, "... ARE SO BORING!"}}
    endif

On a button press CHANGE the contents of the instruction without “redisplaying” them.

This is NOT possible with persistent vectors. For this I have to implement the VectrexCommands and within each round also “compile” them (in this case really interprete them) and actively build a new pipeline. It is not possible to use persistent vectors with Vectrex32 BASIC.

And you know what – Bob does exactly that within the ServiceVectrex – each “round” the current command list is “recompiled” and put into the Dual RAM, the Vectrex commands do not contain the data to display but pointers to BASIC data so if the BASIC data changes – their output changes too. Somehow I missed that before.

… so I am a bid more knowledgable now – but programming wise at the same position as yesterday.

Tomorrow I will than start the VectrexCommand implementation :-).

Cheers

Malban