26th of December 2020 – Intensity and Vectorblade V1.06, optimization WARNING!

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

Tagged on:

2 thoughts on “26th of December 2020 – Intensity and Vectorblade V1.06, optimization WARNING!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.