26th of April 2021 Porting GS BASIC – to PiTrex (6)

Today was a much better day than yesterday.

I threw all stuff away that I did yesterday, started fresh and implemented the command list and a bunch of BASIC functions. My goal was to actually get “Lunar” running today.

After the usual “bugs” (correcting include files, adding function, that I missed, added all those to the Makefile etc etc). This nearly worked out of the box – WOAH!

Nonetheless – I was “bug hunting” for about 3 hours. I actually had a bug in my vectrexInterface, strings were not printed correctly “all the time” when displaying Lunar. As you can see – I have gotten it under control – but I was nearly ready again to give up. It is hard to explain what the bug was about, but I’ll try.

When I create the pipeline – I do that one item after another, and I know the order with which the elements will be displayed later with the pipeline. This alowes me to optimize the output. At each and every “second” while constructing the pipeline, I know what value is in the T1 timer, what value is in ViaA, ViaB etc. This alowes me to take shortcuts when I do the actual output.

I remember those values in variables like “currentScale”, “currentA”, “currentYZH” etc.

Everytime I change those registers, I also remember what the values of those registers is, so I can save “double setting” them (one setting is 2 vectrex cycles = 2*666 piZero cycles).

Anyway what I didn’t really realize before today, I am under no circumstances alowed to change those values while I am in hyperspace (IRQ routine). If I change those values while in IRQ, I actually “destroy” the values I use while I am not in IRQ – so false values will be used to generate the pipeline!

There were a couple “quick and dirty” (copy and paste) routines in the IRQ pipeline (mainly raster display routines) – which out of “habit” changed those variables.

Sounds logical now, that I write it down – but finding a bug like that, which just produces random disturbances is hell.

I also found a “feature” in Vectrex 32 BASIC – no bug, but again the compiler (library) doing different things. In Bobs code the “toString()” for float variables was implemented with sprintf(s, “%g”, f); – my library doesn’t recognize “%g” as a valid format. The horizontal/vertical speed in “Lunar” was always “gg”.

I changed the routine to manually truncate:

String String::ftoa(float f)
     char s[30];
     sprintf(s, "%f", (double) f);
     // truncate
     int i = 0;
     for (i=strlen(s); i>=0; i--)
       if (s[i] == 0) continue;
       if (s[i] == '0') {s[i] = 0;continue;}
       if (s[i] == '.') {s[i] = 0;break;}
     if (i==0) s[0] = '0';
     return s;

Not very nice – but working as intended – I believe.



Tagged on: ,

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.