Downloadable Vectorblade versions

[Malban]

I am not sure about the demo mode – whether it is “truely” random.

If all is setup – and you let the demo run straight from the startup… it might not be random.

---

Manually… in each round of the title screen I call “random” once. So if you start a game as a player the random is pretty much random – if you do not press the “START” at exactly the same “round” after starting the vectrex – which is highly improbable.

Each 1/50 second the random values change.

Thx for the offer…
But I let Vide run here in the background. Without speed limit it does about 250% of an original Vectrex… so I have a little “time crunch machine” here.

… and if indeed Vide can find the bug – than I will be able to enter the debug session and explore.
All you could verify with your setup would be whether its a “simple” code problem or not.
(Which would be great to know – but than again I would have to let Vide run myself 🙂 )

Cheers

Malban

[Malban]

On another note…

Ian sent first images of the overlay from the printer.

50 pieces are done – and approved. So the next batch will be printed soonish – and will arrive sometime this year at my place :-).

Although – for the release I want to figure out the problem first …

 

 

 

[Peer]

… darn, finding a way to help you is hard 😉

This will not stop me from posting more wild guesses and other crazy things! Is there really nothing I/we can do to help you?

And the offer still stands. Also if you have other ideas of how to put the server to good use.

Cheers,
Peer

EDIT: Cool, the overlays look great!

[Peer]

Ok, here is my next attempt:

We know that there are different models of VIA chips out there. And I still remember the infamous faulty VIA I sent you. If I recall corectly, the VIA is used for bank switching and the differences between the VIA models are timing related and you found a way to deal with all variations in your code. I also recall that you wrote some test programm which identifies the type of VIA present in a console. So, might it be worth to check if all the consoles on which the current bug was observed have the same type of VIA? And all of us who did not observe the bug could check if we have different types?

And here are more questions:

– Do all known Vectrex consoles have exactly the same type of 6809 CPU? I know that there are also variations of 6809 processors, but I did not find out if different ones were used in the production runs of Vectrex consoles.

– Does your assembly code use some of the non-official 6809 instructions (sometimes also called undocumented or illegal instructions, you know what I mean)?

– RAM chips have setup/hold timing restrictions. Normally the hardware design of the whole system ensures that these are respected. Is there possibly any low-level timing-critical stuff that might violate them? (e.g. new value not yet stable in RAM cell when next instruction relies on it?) Are there possibly different types of RAM chips out there in Vectrex consoles which have timing differences which under normal circumstances do not matter, but come into play here?

Cheers,
Peer

[Malban]

Hi,

I can not identify VIA’s – I wrote a test program to test one via “feature” to find out how it behaves. There are no internal VIA ID’s that I know of that one can access – or similar.

Thank you for all your thoughts… the questions:

1. CPU
   I would guess – seeing the multitude of different parts GCS used, that also the 6809 might be different in consoles
2. Nope
3. RAM
   There is now way, that I use RAM differently than any other Vectrex game.

If the bug would be on one console only – I guess it might easily be a hardware fault of some kind though.

I have experiences the crash on 3 different consoles of mine. Jerome on his – and I think I remember one of you beta testers also had a crash that in retrospective might have beed the same.

As said, the darn thing is very seldom – so testing it means most of the times – hours of running the game.

What makes it much harder is that as of now it appears that it only occurs in a non emulated environment. That would mean the current emulators are not good enough…

All hints did and still do point to a faulty bankswitch – thing is  I tried to cover that in code… meaning, when a faulty bankswitch occurred – it should run debug code and display a message. The ONE TIME I have been able to produce the crash with the debug code in place it did not “catch”…

I think I’ll debug the debug code – while waiting for the hardware to arrive.

---

Still I can not be sure it might be as you suggested. But damn I hope not – because than I will never find it – or know how to prevent it.

Appart from the bankswitching Vectorblade is still a NORMAL Vectrex game. Nothing really out of the ordinary…

Cheers

Chris

 

 

 

[Peer]

Hypothesis: Bankswitching

Would it make sense, if you created several binaries which do not contain the (full) VB code, but which just do some heavy load bankswitching? No real game stuff, just bankswitching related things.

Things which you consider as “this is not the normal or average bankswitching use case, but it should work”. The more different scenarios, the better.

We then run those binaries on our consoles and see what happens. If one of them produces a crash, this might give a hint to the corner case situation in VB.

Cheers,
Peer

[Malban]

Hi,

thats a good idea – if the next things I plan “fail” I’ll probably do something like that.

At the moment I am trying to get the NMI to work…

I added a capacitor for rebounce softening – and also did a rebounce handling in software.
In Vide the code works great (added NMI handling to the emulation)… in real life the vectrex just crashes…

Further invenstigation pending…

[Malban]

Short update…

The non working NMI was a layer 8 problem – I flashed the wrong vectorblade image – since I now work in a test directory.

NMI works great and I can show all registers and PC on a button press. Now I only have to reproduce the bug and I MIGHT get more information… or not.

Getting the bug to show will again take a couple of (dozen of) hours. Yesterday I played to level 542 on the Vectrex.
Yep – again all the way thru all difficulties… so at least now I know it is possible to do it on a real Vectrex – not just theoretically.
(but no crash)

Cheers
Chris

 

[Malban]

Update.

All overlays are on its way to Germany.
I cleaned up the Vectorblade code (partially). Did many, many tests.
Corrected a couple of things. Found one potential Stack overflow.

Did play yesterday with my newest version – and had the first crash in a week. Soooo still the same.

For heavy duty bankswitching test, as suggested by Peer – I wrote a test program, which uses the vectorblade routines.
All it does is bankswitching at random from a random bank to another – endlessly.
If it faults, it prints an error message.

Mad Bankswitching

It looks stupid – but so far runs without flaw.

The NMI mechanism works fine – but I can not compile it in as “default”, since it uses to much space (the code must be resident in all banks at the same location… and some banks are really FULL). I tested the shorted version of Vectorblade – but as bad luck has it… The crash did not occur while the NMI code was in place :-(.

So…. really… no progress at all :-().

 

[Peer]

Sorry to hear that the bug still hides in the shadows. I will run the mad bankswitching over the next days and report back. And on the risk of repeating myself, let us know if there is anything else we can do.

Cheers,
Peer

Edit: Hehe, thought the link was pointing to a test binary. Have watched the video now. If you deem it useful, send me the binary, and I will gladly test it on my consoles.

[Malban]

New theory.

Since my standard test – vectrex is at Thomas place, my second standard test vectrex runs the bankswitch ordeal…I fired my third vectrex up and tried some more testing there.

After some experimenting it seems that my “third” Vectrex has become “weird” as in:

http://vide.malban.de/1st-of-june-faulty-via-vs-inc

Gee – sometimes it doesn’t just rain, it pours.
Anyway – it occured to me, that the faulty behaviour seems to be quite similar to the “crashes”.

I know it sounds strange – but what if…

… what if some VIAs are faulty, some are not faulty… but some are faulty only once every 1000 accesses or so?
Since I don’t have any other straw to cling to – I will take this one.

I will (as mentioned in the above link) rewrite the routines to be “faulty” insensitive. This will take a bit of time, so probably no update for some more days. But once I finish the “insensitive” version – you guys (Jerome?) can go crash hunting again.

Cheers

Chris

 

[Malban]

PS

The Bankswitch test program is insensitive anyway…

But also didn’t  crash yet…

[Peer]

… very interesting thought. I was digging in a similar direction in my post on March 26. So, question:

The WeirdTest binary you wrote for checking the type of VIA, as far as I understand, does some sort of “test”. Does it do this “test” only once, and then come up with an answer, or is the “test” done repeatedly?

What if you created a “while(1) {test}” ForeverWeirdTest binary that just keeps on checking the VIA (no VB stuff)? If your theory is correct, that some VIAs behave weird only every once in a while, then shouldn’t this be a way to chase such behavior?

Cheers,
Peer

[Jerome Vince]

Hi!

@Chris:

If I can help, I am here 😉

Of course, I would be happy to test the “insensitive” version (intensely)!

[Malban]

The WeirdTest binary you wrote for checking the type of VIA, as far as I understand, does some sort of “test”. Does it do this “test” only once, and then come up with an answer, or is the “test” done repeatedly?

What if you created a “while(1) {test}” ForeverWeirdTest binary that just keeps on checking the VIA (no VB stuff)? If your theory is correct, that some VIAs behave weird only every once in a while, then shouldn’t this be a way to chase such behavior?

As of now – the “tester” only tests once.
I can certainly do such a repeated “tester” – thing is… it <might> just be, that there are very weird prerequisite, so that VIA might behave differently. Some IRQ at a specific falling edge of a cycle… Timer T1/T2 overflow… or whatever.

So while very interesting to do such testing – it might still be that such a tester does not show a useful result. Since I can not guarantee, that all “cases” are really tried out…

 

 

 

 

[Author]

Posts