Downloadable Vectorblade versions

[Malban]

@vtk

Good to hear from you – long time no see!

[Peer]

Just a sidenote, but well worth mentioning: Jerome was one of the main beta testers of Vec-Man and greatly helped shaping the final version into what it is now 🙂 Thanks again!

As for the VB crashes:

Have these crashes been experienced by several different testers on several different machines?

Is there strict evidence that the reason is on the software side? Can we definitly rule out that the reason is probably on the hardware side? Some aged or worn out physical part, capacitor, pin connection, …, etc. in the console? Or in the eprom?

If it is on the software side, then the fact that all of us have not experienced it in debug/demo mode, might indeed be an indicator for a Heisenbug, i.e. a bug that is gone once some debug code is added. So in which way does the debug code alter the timing or behavior of the original code?

I think Helmut’s suggestion is a good one: Let us see if we can reproduce the crash in non-debug demo mode. Or maybe with a debug version that gives less debug information? Meaning one where the diff to the original code is less and which thus is probably less Heisen-buggy?

Sorry, I am tired, and I hope this makes sense, but I couldn’t get these thoughts out of me head.

Cheers,
Peer

EDIT: Hehe, while I was writing the above, all your last posts came in…

[Jerome Vince]

@Chris. Thank you for your analysis and your explanations about the calibration. Now i understand the technical difficulties we can find if we want to modify the screen position.
About the bankswitching and your hypothesis to solve the problem : I would be happy to test your next version 🙂

@Peer : Thank you ! I am delighted to have participated in the latest developments of Vec-Man! 😉 : it is an extraordinary game on the Vectrex!

[Malban]

…

‘been experimenting.
‘been running the testcode for probably more than 70 hours.
No crash. Removed testcode – crash 2 times after 1/2 an hour – than for 20 hours no crash.

Started a “fixed” version with extra wait cycles for bankswitch – crash after 1/2 hour – than never again.

Started a couple of intermediate version – played a couple of hours by hand – one crash.

Started a debug version and played by hand – 5 hours no crash.

Started just this morning again a debug version – crash, in the middle of boss fight 1.
This means there have been literally over a hundred ours of play without crash with the debug version… but now… there is!

No debug output – this most probably means it is not bankswitching related (or the debugging code is buggy).

---

Back to square one.

I have absolutely no clue what this is.
A crash can happen on different vectrex. After playing minutes… or after playing tens of hours.
Within the normal game, while picking up bonuses, during the minestorm intro and during a boss fight…

Basically ANYWHERE.

I’ll keep looking – and thinking… but I have been doing that for quite a while now.

If I do not find this bug – there will be no Vectorblade release.

 

Cheers

Malban

 

 

[Jerome Vince]

I do not know if it is possible, but we have to identify what is the oldest beta version where this crash randomly appeared for the first time and compare the differences with the previous version. Also we have to intensely test this last known version without a crash (to be sure) and so on if a crash occurs.

[vtk]

hey Malban sorry to hear of the troubles  🙁

i wish i had some useful suggestions,  i can only think of maybe you could try some different builds of the game where certain areas of the code are disabled, to see if that can help pinpoint the troublesome area of the game…

[Malban]

Hi,

thx for the suggestions… but they are not really feasable.

Since it takes between 1/2 hour and in access to 100 hours for the crash to occur, I cannot think of any plausable way to test out which version started to be faulty.

Also, since in between I did more than once a major code overhaul – it would be very hard to do a simple “compare”.

Malban

[Peer]

Ok, as far as I understand, the crash occurred on different consoles. Did it also occur with other testers, using other eproms? Or was it always you using the same eprom? Just to rule out some hardware glitch of your eprom?

[Jerome Vince]

<span style=”-webkit-tap-highlight-color: rgba(0, 0, 0, 0);”>@Peer</span>

Hi Peer! I do not know if it can help, but I got the crash with the Malban’s eprom and with the VecFever MK II too…

 

[Peer]

Blind guess:

You said a crash can happen basically anywhere, and before that you listed several situations. Is there anything all those situations have in common? One thing crossed my mind: sound. I do not know anything about your sound engine. Maybe some bug occuring in some corner case situation if some new sound is starting while another sound is still playing?

This is just a wild guess, but I was thinking about what those situations could possibly have in common…

[Malban]

Well – although its in different parts… I still reuse the “engine”.

same:

• sound
• sprite drawing
• bankswitching
• input
• stars

---

At the moment I am thinking about two further approaches to debugging:

• either a new BIOS ROM, which allows me to press reset and jump than to a user reset routine which gives out current registers/stack
• adding a NMI – push button to the cartridge so I can also “jump” at a button push to a subroutine…
  this is more tricky in software since I have possibly to consider rebounces of the push button, and the NMI uses itself the stack to push values…. also in game the stack sometimes uses a ROM area – so I wouldn’t get any information at all…

Both have its merrits

a) reset doesn’t use the stack, so nothing is destroyed – but I cannot get the address (PC Program Counter) where the “crashed” program currently is running

b) if the stack is in RAM I might with a debounce handler access the NMI stack, and as such can also access the PC – which might give further clues

 

I ordered some 8kB eproms… so I can make my own BIOS…
I just have to socket the original eprom 🙁

Which means opening the vectrex desoldering the ROM etc etc etc…

 

I also ordered a push switch to build a NMI switch. Now this probably also means I have to implement a capacitor debounce “circuit” and also do software debouncing…

All in all – I will do it, but I am not sure what kind of information I will get in the end out of it…

But I don’t see many options here 🙁

I’ll keep you updated

Malban

[Peer]

Some more wild guesses. I am sure you most likely already thought about this, but I can’t think of any other way to help you right now.

I know that VB code is not “normal”, meaning it uses all sorts of sophisticated assembly language tricks. Under “normal” circumstances, with a bug situation like this (indeterministic, not reproducable), I would think of memory corruption and/or stack corruption. If I recall correctly, then you are also (ab)using the stack register in other ways, but anyway. I am just brainstorming. So what about:

– stack overrunning heap, and thus corrupting ram data

– stack corruption, some instructions like jsr or rts which also implicitly use the stack interfering with your using of the stack register for other purposes

– corrupted/abused stack followed by an rts will corrupt the program counter

– if you are storing/handling the game objects in some sort of linked list, what about list corruption? Maybe in combination or as a consequence of one of the above?

Another crazy idea: if we assume the bug to be purely programming-logic related (no hardware issue, no timing issue), then maybe Vide could be able to re-simulate it? Meaning: let Vide run the binary for hours, maybe in some special, yet to be implemented autonomous playing mode, and see if the bug occurs? Ok, you can see how highly I think of Vide 😉

Let me know if I can help with any of this, or in other ways…

Cheers,
Peer

[Peer]

Three more questions:

– Does VB use any of the “original” BIOS/RUM routines? If so, which?
– Does VB use any of the ROM data (located in the BIOS or located in the MineStorm code)? If so, which?
– The bug occured on various real consoles. Do all of these console have the same BIOS version, or do we know that the bug occured with different BIOS versions?

Cheers,
Peer

[Malban]

In game I do not use any BIOS routines.

I let the game run about 40 hours in Vide (demo mode).

I played (in one game e.g.) 517 levels Vectorblade (easy, normal, hard, impossible, super impossible… and 17 levels)  no “crash” in Vide.
In Vide I have not been able to reproduce it – so I sort of doubt, that it is a normal code/memory/stack bug.

But that is still no certainty – I’ll keep trying reproducing it in Vide.

[Peer]

… do you ever sleep? 😉

Next question regarding demo mode: Computers run their programs deterministically. Unless there is some users input or some true randomization, the output will always be exactly the same. How do you ensure that each demo-mode-run behaves differently? Are the RNGs seeded differently each time, depending on some user input or hardware timer? Just to prevent that each of us is just experiencing exactly the same game behavior when testing in demo mode (i.e. a behaviour that just does not activate the bug).

EDIT:

– What about more “demo modes” to incite more corner case behavior? E.g. a mode with constant maximum auto fire (lots of bullets permanently active)? Or a mode with always-dropping-bonus item? Or only-money-dropping? …

– This might not be feasible: massive parallelization, 8+ Vides running in parallel and doing different demos runs for a week. I have a server in my lab that has 8 CPUs, each of them having 4 cores. There is no easy way to give you access to that server, and it would surely require some additional setup of the Linux system, but if you are interested, let me know, and I will try to make this possible.

[Author]

Posts