Yesterday I got a message via Facebook, that Vectorblade looks “crooked”. The person – for easy reference let us call him CSR – has a recapped very well working Vectrex on which all other games work ok.
Symptoms:
Trying to describe what you see:
- all ships/enemy ships are displayed correctly
- shots on the bottom half of the screen are not displayed
- shots on the top half are displayed in varying intensity
- bonus drops from destroyed ships are “nearly” not displayed – they “blink” sort of, when reaching the bottom of the screen.
Symptoms 2:
Trying again to describe what you see:
- Highscore – is displayed in “constant” intensity – instead of varying degrees of intensity in relation to the letters being further back or in front
- some letters of the highscore wheel do not show or show only very dark:
“I” is missing, “J” is dark
“T” is missing
the signs between “Z” and “A” are missing - The “HIGHSCORE” text, the player initials, the player ship and the score itself are missing
- in the very end of the video the desktop is displayed… the bottom most icon (highscore) is not displayed, the middle icons are displayed with very low intensity
Now – I think we can agree that this is quite strange. Lucky for me and CSR – he had gotten his Vectorblade from Mr Coleman. The flash chip was socketed AND CSR is in posession of a device with which he can flash Vectorblade to his device.
This enabled me to write several test versions of Vectorblade and for him to try them out.
I was able to fix the problem – although I am still a bid awestruck by its appearance.
Having written the “what you see” for the videos, it might make the reasons for the behaviour “obvious” – but starting out the search, this was not the case! Anyway I will not bore you with false starts – the culprit in this case was “optimization” (as usual). This time it was optimization of the intensity setting.
Following macro I use to set intensities (I also used it with Karl Quappe and Release – so these might need some fixing too???):
_INTENSITY_A macro
STA <VIA_port_a ;Store intensity in D/A
LDD #$0504 ;mux disabled channel 2
STA <VIA_port_b
STB <VIA_port_b ;mux enabled channel 2
STA <VIA_port_b ;turn off mux
endm
Following is the original RUM function (as found in John Halls RUM source):
INTENS STA DAC ;SET INTENS TO 'A' LEVEL- USE 0-7F <---- STA TENSTY LDD #$0504 STA PORT STB PORT STB PORT ;NOP LDB #$01 STB PORT ;LEAVE 4052 AT ADDRESS 0 RTS
Note the “NOP” operation!
Again I am shamed by the foresight of the original designers. This NOP operation (a second stb) is on some strange Vectrex neccessary!
(but my thought actually is, that the STB before the above commented one is the “real” nop)
Since probably about 200 Vectorblades are out there – and I never heard of this kind of problem before, the first rough estimate suggests:
1 of 200 Vectrex might have this problem!
Inserting above “NOP” in my macro fixes most of the problems.
It seems that for some strange reason – that when port B (MUX setting) is switched to fast, the switching does NOT “reach” the MUX. The different intensity levels displayed by the ingame shots is actually the “Y” coordinate of the shot.
Thus the next “DAC” value that was passed to VIA was actually also put into the intensity settings.
This explains the seen (or unseen) shots.
- negative Y coordinates (bottom half of the screen) result in “invisible” shots, since negative intensities are always “black”
- positive Y coordinates (top half of the screen) result in brighter shots, the higher the shots are displayed
My new intensity macro now looks like:
_INTENSITY_A macro
STA <VIA_port_a ;Store intensity in D/A
LDD #$0504 ;mux disabled channel 2
STA <VIA_port_b
STB <VIA_port_b ;mux enabled channel 2
STB <VIA_port_b ;do it again just because
LDB #$01
STB <VIA_port_b ;turn off mux
endm
Still…
As said above – this only fixed MOST of the faults.
The title screen still looked like this:
Same behaviour as befor!
With following code section:
_INTENSITY_A ; draw high score stairs ldd #$da00 MY_MOVE_TO_D_START_NO_SHIFT
As you can see – in this “special” cases – the MOVE come directly after the intensity setting.
It seems – that for this special vectrex – there also have to be more “waits” between the intensity setting and the next move (probably again “MUX” problems).
If I just insert “switch off MUX” again before doing the move:
_INTENSITY_A ; V1.06 ldb #1 STB <VIA_port_b ;turn off mux ; draw high score stairs ldd #$da00 MY_MOVE_TO_D_START_NO_SHIFT
The title screen also looks “normal”.
Vectrex are strange devices…
There is one additional code section where I change intensities. As of now these could not be tested by CSR – since it is the boss – intro screen.
The code is slightly different (within smartdraw routines) – so these might work as they are.
I am awaiting more feedback on this. But since CSR can only play VB since a couple of hours – he didn’t see a boss yet!
The fixes described in this blog are not on Github yet – I will insert them soon. I have not updated any downloadable binary version!
Cheers
Malban
Would be very interesting to put a modern VIA chip in this vectrex to see if it change it’s behavior.
And to see what version/production date of his VIA chip is.
Sometimes for these type of things at my work we make a special build or add a cheat to be able to get to the boss. Or finally, a save game is used. But in any case. Good sleuthing! Very interesting.