[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 :-().

 

[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]

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]

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

 

 

 

[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 …

 

 

 

[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]

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.

[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

[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

[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

 

 

[Malban]

@vtk

Good to hear from you – long time no see!

[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

[Malban]

Jerome,

feel free to post future findings here on the board.

 

Cheers

Chris

[Malban]

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

Perhaps the new debug code fixed it???

[Malban]

Added the VecFever version to the last upload!

[Author]

Posts