14th of May 2020 – debugging in new ways

Still we are looking for the Vectorblade bug. If you watch the forum you might have seen different theories and different approaches popping up.

We are by now (or at least I am) quite certain, that it is no “stack corruption” of the “usual” kind. Meaning stack grows out of bounds and destroys some game data.

The reasons behind me being quite certain are two fold:

• I measured the stack quite extensively and it fits “perfectly”. Stacks can be watched and “breakpointed” in Vide – and Vide never showed any stack corruption.
• Secondly – the stack can not grow “out of bounds”, at least not accross “game rounds”. Due to the programming methods used I need to reset the stack every game round. The round literally starts with the instruction:
  lds #MY_STACK
  So… it IS reset and can not grow.

Despite me being “quite” certain we did additional experiments, one of them extending the stack by a considerable amount (more than doubling it) by 16 bytes. … the crash happened again (level 170 – thx Jerome!).

If you read the forum and encounter phrases like “Voldemort” or “that which is not to be spoken of” – it relates to the stack. Since I gave out the parole “I never want to hear of it again!” :-).

---

Now.

I think I did something cool. I don’t know if we can find the crash reason with it – but if not, I doubt we will ever find it.

I let the few hairs I still got left turn a little bit more gray and put on my thinking cap (ok, ok, … it was a restless night where I couldn’t sleep. Gee, could you please just let it slip by? Once?).

Since we offically decided to let Major Havoc leave the game and make room for stuff which we do not know anything about yet… we … well .. had “room”. About 15kB of room!

While I was wearing the thinking cap – I mused. Couldn’t I do something with the 15kB? … maybe… Flash!
Yep – I can program a “save game” feature. Just saving 1024 bytes of RAM – and load them again. Sure it would take away the quadrupel size (4kB). But what the heck, we have plenty of it (for now).
4kB is the minimum block size of flash memory that can be erased – so at least 4kB it must be. After actually only a couple of programming units.
I could save a game – and load it. Cool!
(I don’t know if I’ll implement it in the final Vectorblade version…

POLL: “should I?” please leave a comment!

But even if I do, I will probably disable highscores for “loaded” games.)

Putting on the thinking cap again… and than it occured to me – I can actually (when my eprom programmer works correctly) LOAD the data from the flash chip – and load a saved game in Vide!

1/4 hour later. Yep … works. COOL again!

Continuous thinking cap wearing.
… What if… I save a game “continuously” each start of a level? If a crash occurs, I can read out the game data from the flash chip and see if Vide can emulate the crash after all?

2 programming units later – that also worked.
And while I was on it… implemented another “custom save game” and a save game while in NMI modus (yep, my Vectorblade debug version – has still all NMI features enabled and can now also save all data to the flash chip).

The 3 save game slots are not independed of another though – they all lie in the same 4kB region. But that is getting erased every round – so NMI and continuous are save. – The “manual” save doesn’t even have a “trigger” yet :-).

Works great!.

Thinking cap.

Actually this just came to me – because in one level “all is random” and random is more or less cycle dependend. Even if I save all data from the start of a level – there is NO guarantee, that I can reproduce all steps to get the correct constellation for a crash.

BUT

Now I also thought … to record ALL input data!
Button / joystick and also save that (per played level) to the flash.
For that data I have 8kB space.
Button/joystick is “polled” each round, but alternately – so I have to save 1 byte every “round” (and no, I won’t start packing them).

8192 / 50 = 162

162 seconds I can record. Since I do only record ONE level (I only need one, since the last savegame started at this level!) – this is way enough.

If you have played Vectorblade – you will know that this is WAY enough. The usual level will not need a third of that.

There are only three levels which MIGHT take longer (where the aliens use shielding devices) – but I either take that risk, or if not use a smartbomb to blast them away FAST.

---

This is happening!

All of the above has been implemented and is working. There might still be one of two bugs inside the system – which I have to iron out… but now I can:

• play on a real vectrex
• record each level I am playing
• record all of my actions EXACTLY
• reload and play them back on my vectrex (start the game with a button pressed, plays back the last recorded session)
• load all that data from the flash and into Vide
• still have all NMI possibilities – when the crash happens
• recording “automatically” stops when the crash occurs

So…

Tell me – if I can’t find the bug with THAT setup – what else will I ever be able todo that can help me further?