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;}
break;
}
if (i==0) s[0] = '0';
return s;
}
Not very nice – but working as intended – I believe.
Cheers
Malban