16th of October 2022, Wobble, Jitter or Stable?

Wobble / Flicker on the Vectrex!

Newest scientific experiements show:

The Vectrex creators were no shielding experts!

Actually that is no news, and everybody that listened to a Vectrex already knew that.

THE BUZZ!
… of the vectrex proved that already.
The built in sound amplifier was placed on the power board and not shielded, which
resulted in electrical interferences – that could be well heard.
But actually it cannot be only the transformer that is interfering – since the buzz changes with
the amount of vectors that are displayed.

Anyway… Sound is not what I was going to talk about.

As I have made clear many, MANY times I like my vectrex games running at 50Hz.
Which I thought would be needed to make the vectrex display stable.

That is not true, per se.

Actually come to think if it…
I doubt that many eyes can make out the difference if a game is running in 50Hz or in 48Hz.

BUT!

As it turns out – concerning the Vectrex you CAN clearly see a difference whether it runs in 50Hz or 49Hz. But the reason is not that the display FLICKERS more due to to slow refresh rates. It wobbles due to power grid interferences!

For easier demonstration purpose I will not show images of a real vectrex, but images from Vide – which by now can emulate this feature. On the bottom I’ll provide links with “real” vectrex showcases.

Note: Most of the theory and input on this came from Peer Johannsen.
This is a summary of the findings. You can find more on this subject in the Proboard forum (link provided further down in the article)

The mentioned scientific experiements (running programs on a Vectrex) seem to support the theory, that the Vectrex image is influenced by the frequency of the power grid.

German AC power grid values (50Hz)

(Germany: ) If we plug in our electrical devices in the power outlet on the wall we get ~230Volt AC at 50Hz. AC means alternating current, which means the voltage changes in form of a sinus wave – fifty times a second a complete sinus curve.

The vector position on a vectrex is changed very slightly with the sinus wave of the power grid frequency.
The effect is with “well programmed” vectrex program in Europe not visible!

(Well programmed -> refresh in 50Hz)

Because the BIOS refresh frequency that the original developers chose was also exactly 50Hz.
This means although, all vectors are influenced by the power grid – the (European) user does not notice it, because every vectrex round the influence of the power grid is exactly the same and the image is thus STABLE again.

Vectrex program, refreshing in 50 Hz, with a 50Hz sinus interference -> Stable

The effect of the interference is “funnily” most visible, when the 50Hz is barely missed.
If you miss the 50Hz by 1Hz, meaning the vectors are displayed only slightly longer or slightly faster – the effect is MOST visible. Because “virtually” you can see the vectors following (both in x and y coordinate) the sinus wave function. Missing/or being faster by 1Hz is about 600 cycles (612 cycles) in Vectrex terminology. This means, the vectors on the screen “move along the sinus” curve – with one full sinus wave taking exactly 1 second.

Vectrex program, refreshing in 51 Hz, with a 50Hz sinus interference -> Wobble!

The image shows the result (slightly exaggerate in emulation, but a real vectrex also shows this!).

Running the same program at 60Hz (still in Germany) does the same movement but 10 times per second – barely visible to the eye as a sinus movement, this is more like a “jitter”.

Vectrex program, refreshing in 60 Hz, with a 50Hz sinus interference -> Jitter!

(again exaggerated by emulation)
Theoretically a 60Hz image should be much more stable – but the interfering power grid destabilizes the image!

60Hz power grid!

I always wondered, why other people were not disturbed by those “wobbles” when the refresh rate of the Vectrex was slightly above 50Hz. The reason is easy, people with a 60Hz power grid can not see a difference! They NEVER! have a jitter free display. And for you guys it does not really make a difference if the jitter is 1/10th of a second or 1/9th of a second – it is just some other kind of jitter.

For Americans (and all other 60Hz power grid users) to really get a CLEAN display – the Vectrex programs must display in 60Hz – meaning each display round should be done in 25000 Vectrex cycles!

Try it! Write a program and set the WaitRecal() refresh rate to 60Hz:
1500000 / 60 = 25000 cycles
25000 in hex -> $61A8
respecting VIA little endian -> $A861

 LDD #$A861        ; load D with little endian 25000
 STD Vec_Rfrsh     ; store to vectrex refresh rate time

… and not only will you display in 60Hz (as long as your program does not add up to more than 25000 cycles), but your display will be JITTER-FREE!

(BTW. PiTrex owners should set their display to 60Hz – since the program speed and display speed are disjunct – you can do that, and the display will be much better!)

Following examples are again exaggerated by emulation, but the real world is very similar!

50Hz Vectrex program running in a 60Hz power grid environment:

Vectrex program, refreshing in 50 Hz, with a 60Hz sinus interference -> Jitter!

60Hz Vectrex program running in a 60Hz power grid environment:

Vectrex program, refreshing in 60 Hz, with a 60Hz sinus interference -> Stable!

61Hz Vectrex program running in a 60Hz power grid environment:

Vectrex program, refreshing in 61 Hz, with a 60Hz sinus interference -> Wobble!

Experiments to reinforce this theory

There are two tests for the above theory, that come to mind:

a) the ones I provided above
Run a stable image at exactly the same “cycle offset” (from the WaitRecal) per round at different refresh rates. This results in a stable image as long as the Vectrex- refresh frequency matches the power grid frequency.
Otherwise there is a wobble (small differences) or a jitter (larger differences)

b) the opposite experiement can also be made
Meaning: display a stable image at different cycle offsets (from the WaitRecal) per round, and keeping the same Vectrex refresh frequency as the power grid frequency.
(Peer did these also – and these experiments also show the expected wobble/jitter)

The “complete” discussion about this can be found at the proboard forum: https://vectorgaming.proboards.com

What Next?

If there is time – Peer and I would like to do further experiments on this subject. One thing we intend to look deeper into is – whether it is possible to add some shielding to existing vectrex units to suppress the wobble. If that can be done – than maybe in the future there will not only be offerings to DeBuzz kits, but also “DeWobble” or “DeJitter” kits.
If anyone else is intrigued by the subject, does his/her own experiments or just want to small talk about this – pls contact us – or inform us about your findings!


Links to “real” vectrex displays

Frequency test Europe 50Hz power grid: WobbleTest_50Hz

Frequency test US 60Hz power grid: WobbleTest_60Hz (Thanks Brandon!)

(Note: a simple “Sinus” wave as shown in emulation is probably not 100% correct, probably there are other trigonometric functions interfering, possibly some function like:
sin(x * pi/15000) * cos(c * x * pi/15000)
0 <= x <= 30000 cycle of refresh frequency, c some constant like c = 0.02

Thus the display of the real Vectrex are not 100% identical to emulation)

Files

My own test program (source and binary) can be found at: Directory: test program

@Peer: the latest Vide.jar (with the above “extended wobble function”) can be found at: Vide_wobble3.jar

Tagged on: , , ,

10 thoughts on “16th of October 2022, Wobble, Jitter or Stable?

  1. Michal

    Hi Malban, I have just tested you program on my Vectrex (in Europe on 50hz power grid). I have few questions 🙂 Does it mean all original Vertex games are running at 50hz regardless if Vectrex is American or European one? It is a very interesting topic …can you give some examples of games not running at 50hz please (I would like to check it out)? 🙂

    1. Malban Post author

      Interesting question – I never looked before.
      One thing you must understand:
      The Vectrex BIOS has a function WaitRecal (Wait and Recalibrate) – this function is called once per round.
      It waits till timer T2 finishes the set timing. Most games set the timer so that the game runs in 50Hz (regardless of country). The thing is – if the game round (the drawing mainly) takes longer than 20ms (1/50 of a second) – than this “wait” function naturally does not wait at all.

      MOST games, that supposedly run at 50Hz do most of the time NOT run at 50Hz but are slower (you can see that quite well in Vide).

      However – after your question I examined a few games and there are some exceptions:
      For following games the timer is set to 33Hz:
      – RipOff
      – Cosmic Chasm
      – Tour de France
      – Hyper Chase

      Bedlam is set to run at 30Hz.

      StarTrek alternates between 33Hz and 50Hz (strange).

      And some games do not use the WaitRecal function – here I did not examine further (e.g. Polar Rescue).
      There is no official game running with a higher refresh rate than 50Hz.

      I programmed a Night Driver Demo, that displays in 100Hz (Dark road, see downloads).

      Also on the PiTrex you can chose for the Arcade emulations and the “games” the refresh frequency in the settings.

  2. Michal

    Thank you for the investigation and the answer. I am going to have a look as well. I still don’t have PiTrex (just ordered today), but will use original carts and vecmulti. Does it mean in PiTrex you can enforce 50hz and therefore stabilise the image? How will it work for, e.g. Bedlam, which as you mentioned run at 30hz?

    1. Malban Post author

      You can not change the Refresh frequency for Vectrex programs on the PiTrex – only non – Vectrex programs, like emulations and ports of PC games.

  3. Peer

    So interesting to know that some of the original games set the timer to a frequency different than 50Hz. I had asked myself that question during the investigations of the past weeks, but I never checked. But clarification: those games cannot use Wait_Recal(), as that one resets the cycle count to 30000. Correct?

    1. Malban Post author

      They nearly all use WaitRecal, that function reset Timer T2 to the value that is stored in RAM, at a location called VecRefresh (Bruce Tomlin style naming convention).

      So the programers can chose the refresh rate programatically by changing that value!

  4. Malban Post author

    To have all comments in “one place”, I quote a facebook question and reply:
    (following a video running the test program on a Vectrex that does not use the internal transformer as power supply, but has external DC Power supply attached -> and shows absolutely no wobble/jitter
    Facebook post: https://www.facebook.com/groups/vectrex/posts/1944965112380523/)

    My Question:
    In your above video:
    a) was the original transformer still in the Vectrex?
    b) if so – was it connected to power?
    I am asking because we (Peer and I) tried shielding the transformer – as yet to no avail.
    If the transformer itself is the reason of the distrubances, than connecting the DC 13V should not really make such a big difference should it? (with the transformer being still connected that is)
    On the other hand, if the 13V DC that is gotten from the transformer thru a rectifier has in itself some “jitter” left, than no shielding on earth will prevent that jitter.
    Thoughts?

    Pete answers:
    The transformer IS the cause, the video I shot kinda proves it. Trying to magnetically shield is pointless, the nature of a transformers AC magnetic field is to induce current flows in anything capable of carrying electric current, ie a metal shield will just emanate a field of its own… back to square one, the original transformer is contained in a steel shell it obviously doesn’t help, you could remove the transformer and locate it several feet away, that would work. This is not a problem of 100Hz ripple from the power supply, fully recapping your unit wont make a difference, if the Vectrex were to be made today it would have a switching power supply and no one would have this problem. In short there are but two solutions, A) remove the transformer pop it in a box and extend the output leads to a plug to connect to the Vectrex (use it with the box as far away as possible), B) ditch the transformer (leave it in place) and develop a switching power supply solution to place in a box, again having a leas plug/socket to connect to the Vectrex.

    (In the Video the internal transformer was in place, but completely disconnected)

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.