Downloadable Vectorblade versions

[Malban]

Vectorblade_Beta44.bin – 12th March 2020

VectorbladeBeta44.V4E – 12th March 2020 – VecFever version

Geee… It has been nearly half a year.
Still waiting for the overlays :-)…

Anyways… I had some disturbing news.
It seems Vectorblade can “crash” now and than. It seems to happen rather seldom, about once in 20-100 hours of play.

Still I would like if possible to fix it. I have so far NO clue what happens. Its seems the crash can occur anywhere.
I have reports:

• after a bonus collect
• before a minestorm
• without ANY discernable cause

My suspision actually is, that sometimes a “bankswitch” can miss (for whatever reason) and as a result the program counter is set to a non sensible location.

I can not reproduce the situation with an emulator (I have been running Vide for about 40 hours… straight).

I have written a “special” vectorblade version in the hope of collecting more information.
Since I suspect the bankswitching I added special debugging code for bankswitching (in order to fit – I had to shorten some animations).

Vectorblade <should> display some information if a bankswitch “missed”.

It will display something like:

BS A xxxx yyyy zzzz

– BS for bankswitch error
– A an identifier for me, at which code location
– xxxx contents of the X-Register
– yyyy contents of the Stack register
– zzzz current word on the stack (return address if a subroutine)

With this information I can perhaps get some clues.

Since playing for hours is quite tedious… (and most reports state that a crash occured  on 110+ levels)…

This special version is not ment for PLAY.
If you don’t mind… let the game go into “DEMO” mode…. there it will play forever (or till a crash).

So please start Vectorblade, do a one time calibration… and leave it alone – till perhaps the error message appears.

By “multitasking” this procedure by including the  beta testers I hope to get some more results….
Sending a screenshot of such an occurrence would hopefully help me a lot.

Thank you!

Malban

 

 

[hcmffm]

Thank you for this update after a long time, Christopher. I’ll download the beta version and will run it in demo mode on one of my Vectrex consoles.

EDIT 1/2: VB beta 44 running… …: After more than 2 hours still no crash on my no-buzz Vectrex. I don’t want to leave my Vectrex running unattended so I’ll stop the test, now. I’ll continue tomorrow…

EDIT 3/4: [13.03.2020 08:25 am.] VB beta running… [9:25 pm] …stopped after 13 hours. No crash, here. Tomorrow I’ll try on a buzz Vectrex.

[Malban]

Thx.

I let mine running for about 7 hours yesterday… No Crash :-).

I think it does not really matter if you restart or not. The lowest “known” crash was in about level 23 (easy).

So I don’t really think the level – or the difficulty – matters.

 

[Jerome Vince]

Hello Chris,

Before all, “Thank You” for your invitation on your forum dedicated to your excellent Vectorblade. I am happy to test the VF version when it is available.

I will let you know my results very soon.

[Malban]

Added the VecFever version to the last upload!

[Jerome Vince]

Thx; i am going to test it

[Malban]

Let two vectrex play for another 6 hours. No crash.

Perhaps the new debug code fixed it???

[Jerome Vince]

May be Yes. After 9 hours (demo mode; VF version ) the game works fine for me! 🙂

[Peer]

Sorry I couldn’t join in earlier. Converting all my lectures to online presentations has kept and still keeps me quite busy, and the first is supposed to start tomorrow…

So far I managed to let VB run for approx. 4 hours on a buzz, and 2 hours on a no-buzz Vectrex. No crashes. I will continue testing tomorrow.

Cheers,
Peer

@Jerome: Great to see you here!!!

[Jerome Vince]

Hi Peer!! 😊 Thank You !!

I confirm all the results above on my buzz Vectrex : 3 hours today and no crash!

[Malban]

Jerome,

feel free to post future findings here on the board.

 

Cheers

Chris

[vtk]

hey, gave it a run for 4 hours yesterday and didnt have any crash

[hcmffm]

When adding up above numbers, it’s about two full days of testing beta 33, now. My guess is that we could continue running VB beta 33 in demo mode for even more days without experiencing any crash.

Perhaps it’s a good idea to run a version without any debug code for a longer time in demo mode. This way we could verify whether the crash occurs in demo mode at all.

@Malban: Which VB version crashed for a tester when playing for a longer time?

PS: Welcome, @Jerome!

[Jerome Vince]

<p style=”text-align: right;”>Hi!</p>
just a few words of introduction for those who don’t know me: i am a Vectrex fan since 1983 when i got it for Christmas! and i want to say that thanks to all of you it is always Christmas today !
I live in the south of France.
be indulgent with me for my english. I try to improve it.

@Helmut: thank you for kind welcome message!

About Vectorblade, i played the Beta 40 (VF) and beta 41 version.

Thanks to Christopher I am happy to be with you to test this great game and share ideas to improve some points.

I also want to warmly thank Christopher for having corrected little bugs and integrated some suggestions into the game in its last development.

My last suggestion: a modification of the calibration settings; the idea would not (only) to modify the size but to move the screen in each direction (as it is the case on the excellent VecFever emulator). In my opinion this calibration can be useful, when the Vectrex screen is not perfectly centered (old/”capricious” Vectrex). We have to keep in mind that some of the Vectrex fans never opened their Vectrex to modify the display settings with a screwdriver. May be they do not want (or do not know how) to do it. The consequences of a poorly adjusted screen are can be visible on Vectorblade. My own situation (without a litlle calibration): when the bonus fall down on the extreme right side of the screen it is impossible to collect them. Frustrating 😉.

About the crashes:
Very rarely i experienced crashes: 2 with the beta 40 and 3 with the beta 41. Always the same symptoms: black screen and buzz. ( for 3 of them: i got a crash playing the level 39 (easy mode) the level 117 and the 121 (“normal mode” after the “easy mode”). I did not find a real common point between the crashes. The only thing and Chris explained this very well: the crash appears rarely and without any obvious reason.

About the beta 44: i will test it again and again this week.

[Malban]

Hi,

just my current thoughts. Again I have had Vectorblade 44 running for another 20 hours or so – without crash.

I am with Helmut on this one – I don’t think a crash will happen anytime soon.

While trying to find the crash I let VB beta 43 run in demo mode for a couple of hours and I had two crashes.

Beta 44 is exactly the same code as beta 43 except:

– code for additional debugging
– leaving out a couple of animation frames in order to get the space for the debugging code.

IMHO the debugging code prevents the crashes.
The only thing which remotely resembles an explanation would be:

That befor the actual bankswitch occurs now there are 4 additional cycles, namely an:

LDA #01 ; some value as an identifier for the bankswitch instance

In the near future I will assemble a new version, with all code and animations in place BUT with some additional “wait cycles” befor the bankswitching.

If this plays well for … say 40 hours … I would guess that might be it. It does not EXPLAIN what happens – but if I can “fix” it with this measure … I will do so.

@Jerome:
Calibration….
As mentioned – the “screen size” calibration code is not finished – since I want to align it with the overlay. So I will not change anything to that just now.
But what I am certain of is, that I will not “move” the centerpoint.
The only calibration I can do (with the time limits I set myself) is making the display larger or smaller.
If the center is moved… than I have to add additional code to every (EVERY!) move done within the game.
This would quite literally cost thousands of cycles – without compromising the game quality that is not possible.

If a vectrex is “hardware wise” badly calibrated things might be “off” yes. But that is also true for every other game.
(thinking about overlays… Pinball comes to mind as a negative example)

You also mentioned – that it is not possible to catch bonuses which fall “out of bounds” near the screen edges.
While I too would like these to be caught as well… The current situation is on purpose and will also stay.

While programming Vectorblade I had to make some compromises – this is one of them.
This particular compromise has to do with placing the fighter and the “scoopies” on screen.
The on screen coordinates range from -128 to +127. These coordinates are applicable to ALL sprites on screen.

The thing is in order to be able to place the scoopies BESIDE the fighter – the fighter is not allowed the full range of coordinates – the fighter actually is allowed to use coordinates from -110 – +110 (or something like that). So bonuses which fall beyond the fighter range – can not be collected – because the fighter is not allowed to go there.

To handle the coordinates in a way that the fighter would be allowed to use the full range AND still might be able to capture enemies (scoops) – a way more complicated way to handle position calculation would be needed (which would also again slow down the complete game).

So my decision was between

• allow scoopies to “help” fight the enemies
• catch also “distant” bonuses

I went for the scoopies – because I think they are a cool feature.

But please let this “no I won’t change it” not discourage you to report other things you think need improvements. I am all ears 🙂

 

Cheers

Chris

[Author]

Posts