|
Post by D-Type on Sept 30, 2022 3:21:56 GMT -5
TLDR:- The mains power supply frequency from the Vectrex internal transformer interferes with the vector monitor display, making the picture wobble.
- The default Vectrex screen update frequency is 50Hz, so, as luck would have it, for countries with a 50Hz mains supply i.e. most of the world, the wobble is imperceptible as it happens really slowly.
- Unfortunately, all countries with a 60Hz supply e.g. North America, will have a "beat frequency" display wobble of 10Hz (difference between 50Hz display update and 60Hz mains supply) that you simply can't get rid of (unless you relocate the Vectrex mains transformer away from the CRT).
Consequence:- You could write your game targeted at 60Hz countries by changing the default display update to 60Hz and the 10Hz beat frequency wobble will then only appear for non-60Hz countries.
- 60Hz display update has pros and cons: 60Hz will reduce display flicker (though may not be noticeable), but it also reduces your number of display frame CPU cycles from 30,000 to 25,000, so basically you can't draw as much.
- The 60Hz game will also run faster than it would at 50Hz.
Original discussion starts below"...because dropped frames are sin against God"said Jeff Minter on the Retro Hour Podcast, Episode 146, 2018-11-02 at 58:11. I agree with him, though he was talking about rasterized vectors and 60Hz. Vectrex runs at 50Hz, which I presume is arbitrary and not tied to the mains frequency as that isn't 50Hz worldwide. We know that if your Vectrex vector drawing takes too long, you get a wavy picture or flicker, but is it possible to develop a game with a deliberate non-50Hz refresh rate and still get a good display performance? I don't have a Vectrex handy right now to try, but if you set the frame timer (or interrupt) to say 60Hz, would it work OK, or is there something odd intrinsic to the Vectrex that makes it only work properly at 50Hz? I'm reminded of someone that said, at 50Hz, the Vectrex display was flickery as hell to him, he could hardly watch it. I guess some people are more sensitive than others, perhaps like some people can't watch a DLP projector because they see lots of rainbows.
|
|
|
Post by Peer on Sept 30, 2022 6:19:25 GMT -5
I might be mistaken, but I vaguely remember that Malban at some point did such experiments and wrote about it, probably in his Vide blog, though I could not find anything by a quick search. Maybe just ask him?
|
|
|
Post by kokovec on Oct 1, 2022 17:08:28 GMT -5
I could be completely off, but I imagine the math behind the integrator circuits places a physical limit on the speed at which the beam can sweep across the screen. In any case, I always wanted to try my hand at developing something that acted as a video buffer and would handle rasterization.
|
|
|
Post by Peer on Oct 2, 2022 9:24:08 GMT -5
This is just theory, as I have not (yet) done any experiments of such kind. I do not think that the integrator speed is of primary concern. Those operate at much higher frequencies anyway, drawing lots of vectors within one frame. I think we have to distinguish between a stable and a non-stable framerate.
A stable framerate of 60Hz should be as good as a stable framerate of 50Hz. By stable I mean that you get everything done within the respective fraction of a second and use a timer to sync to that framerate. And the framerate stays the very same over a long period of time. A stable framerate of 40Hz should be just as Fine, but I guess there is a lower limit under which you will start to see flicker caused by the after-glow time of the phosphoric layer of the CRT (the vectors starts visibly fading until they are drawn again in the next frame).
A non-stable framerate of 60Hz should be as bad (or nearly as bad?) as a non-stable 50Hz framerate. Non-stable means that the time needed for your computations related to one frame fluctuates and wavers around the desired fraction of a second, sometimes being within the limit, and sometimes exceeding the limit. This should cause a noticeable vector wobbling or flicker.
In theory, I do not see any technical reason why a game should not run fine at a stable 49Hz or a stable 51Hz. I am curious if this is the case, but I do not have the time right now to try this out.
|
|
|
Post by Peer on Oct 2, 2022 11:37:20 GMT -5
Ok, couldn't resist. I tried this on a real vectrex, and it seems that my above theory is wrong. I wrote a programm that displays some small number of vectors. It set the refresh timer so that the program ran at a stable 60Hz, 51Hz, 50Hz, 49Hz, 40Hz and 25Hz framerate. Stable, so in each case the vector drawing finishes well before the allocated number of cycles for the respective fraction of a second. Still the vectors are slightly shaking or wobbling if the refresh rate is different than 50Hz. So there seems to be indeed some connection between the 50Hz and some other parts of the Vectrex hardware. I am not that firm in Electrical Engineering, maybe someone who is more knowledgeable can chime in. My current guess is that some other part of the analog(?) hardware is operating at a certain frequency, and that this frequency and the refresh rate must match or be at a certain ratio for the vectors not to wobble (given that the refresh rate is stable). But that is just a guess...
|
|
|
Post by D-Type on Oct 2, 2022 12:55:45 GMT -5
Right, so Peer has just confirmed what I had in the back of my mind from some years ago (probably from talking with Malban), it has to be 50Hz...but I don't know why. If there's something tuned to 50Hz somewhere in the device, is it tuned to the crystal or some other approximate 50Hz? If it's not the crystal, it sounds like there would always be problems. (And doesn't the 3D-Imager run at 62.5Hz or something similar?)
|
|
|
Post by Peer on Oct 2, 2022 13:12:43 GMT -5
I rather suspect that it is related to the CRT somehow. Will try to do some research…
|
|
|
Post by D-Type on Oct 2, 2022 13:23:31 GMT -5
...In any case, I always wanted to try my hand at developing something that acted as a video buffer and would handle rasterization. I've sort of done this for a game that updates the display on interrupt, like one version of Graham Toal's Wangle. Wangle does this so it can keep the screen displayed whilst some long running code is in progress. My game has an optimised table of things to draw that are displayed on screen on 50Hz interrupt. Some other parts of my program are written in Forth that update the table of things. I found here that if you don't handle the interrupt really quickly initially, e.g. looking at what created the interrupt, Vectors start to wobble, it's a tiny amount per extra cycle, but it's there (on real hardware). I believe Graham also posed the idea of making some standard routines that implement a video buffer kind of thing. I guess the problem is that it's not optimised to the game, but i still think it's a good idea. I think a problem with Vectrex development is that we have the BIOS and lots of source code for games, but no-one has pulled together a documented bunch of "Advanced-BIOS" routines you can easily use. I've pulled a bunch of things out of the VIDE and Vectorblade source, but it's not on a plate for you, you have to do some digging! Maybe that's why it's fun :-)
|
|
|
Post by Peer on Oct 5, 2022 10:14:42 GMT -5
I have thought about the 50Hz thing, and I came up with a theory. Not an actual explanation, but rather a potential model of illustration why the positioning works properly at 50Hz only. It might be a bit weird, but it seems to fit, and I’ll describe it as best as I can: Hypothesis: Somewhere inside the Vectrex system there is a signal S which very slightly interferes with the positioning of the electron beam which is generated by the ray gun and shot at the CRT screen. This interfering signal might be caused by the high voltage converter, or might be intrinsic to the CRT, I have no idea. Also, I do not know whether it interferes with the y-x deflectors, or with the focusing system of the CRT, or with the DAC, or with whatever. The effect is, that die positioning of the electron beam is displaced by a tiny delta. This delta is a vector, having a length and an orientation, and delta directly depends on S. My theory is that S is a sine-wave with a full period of 1/50 of a second. So delta oscillates at a frequency of 50Hz, and we have continuous tiny varying displacements of the electron beam. If a program runs at a stable 50Hz framerate, then the 30.000 cycles of each frame are synchronized with S, in the sense that each frame meets with the very same sine-wave pattern, and in each cycle c (with 0 <= c < 30.000) the very same delta S(c) appears. So, if the program draws a non-moving object always (roughly) at the very same cycle c, then this object will appear stable on the screen. If, in contrast to that, the program does not achieve a 50Hz framerate (either accidently by having too long lasting computations, or deliberately by setting the refresh timer to a value different than 30.000), then there is no synchronization anymore between the interfering signals S and the windows of cycles used for one frame. In each frame, a distinct cycle c now gets a different delta S(c) compared to the frame before or after. In other words, for a fixed cycle c we now have an oscillating delta S(c), which results in the well-known “wobbling” of vectors and dots which is so typical on the Vectrex if the 50Hz framerate is not met. If this theory is correct (or fitting), then, at a stable 50Hz framerate, a slight “jitter” should be noticeable, if a stationary object is draw at a different cycle c (0 <= c < 30.000) in each frame. Consider the following pseudo code which runs at a stable 50Hz and draws an object with a varying pause after the recalibration: int x = 0; while(1) { Wait_Recal(); wait_cycles(x); draw_object(); increment(x); } So, with each frame, the object is draw at a later cycle c, relative to the total of 30.000 cycles. According to the above, the occuring delta S(c) follows a slice of the sine-wave of the interfering signal S, and a slight “wobble” or “shaking” should occur in the position of the object on the screen, followed by some sort of “jittering back” when x overflows. So, in summary, the object should not appear 100% clean and stable, and it should also not be wobbling like things wobble at a 51Hz framerate, but there should be some visible inaccuracy in its position. I tried this, and voila, that is exactly what can be seen on the screen. At least on my console. This is not noticeable when the objects moves, but for non-moving objects this seems to be important. What can we deduce from this? Well, if we want a clean image with non-moving vectors being truly stable, then stationary objects should be drawn always at the same cycle c in each frame. Or at almost the same cycle. The more apart, the larger the delta S(c) will be (it’s a continuous sine-wave). Also, stationary objects should be draw before game-logic computation of varying durations. In that sense, a bad Pac-Man like code example is this:
while(1) {Wait_Recal(); check_joysticks(); compute_movements(); check_collisions(); draw_ghosts(); draw_pacman(); draw_labyrinth(); The check_ and the compute_ routines are usually taking a different amount of cycles in each frame. Much better: Wait_Recal(); draw_labyrinth(); draw_ghosts(); draw_pacman(); check_joysticks(); compute_movements(); check_collisions(); This is in accordance with what has been discussed in various topics in the past. And it fits the interfering-signal-theory. But right now, that is what it is. Just a theory. Hope all this makes a little sense 😉 Many Cheers, Peer
|
|
|
Post by Malban on Oct 6, 2022 5:33:29 GMT -5
Have you tried running a program at 25Hz? Apart from getting soar eyes because of flicker - the displayed vectors should be stable according to your theory.
---
And - as asked in our private conversation...
That 50Hz stable thing - is that also true in countries that have a different power frequency than us Europeans. In America the power frequency is 60Hz - does that in any way make a difference?
|
|
|
Post by Peer on Oct 6, 2022 10:56:11 GMT -5
Have you tried running a program at 25Hz? Apart from getting soar eyes because of flicker - the displayed vectors should be stable according to your theory.
---
And - as asked in our private conversation...
That 50Hz stable thing - is that also true in countries that have a different power frequency than us Europeans. In America the power frequency is 60Hz - does that in any way make a difference?
I did try the 25Hz, and I did get really bad eye-flicker. I could not tell for sure. I will dig out the binary and try that again. And I will also rerun the whole thing on a different console, and I can send you the program, then you can try on your consoles, if you want. As for the 60Hz power frequency, that would be cool to know. Maybe someone from the US could chime in?
|
|
|
Post by Malban on Oct 6, 2022 10:56:47 GMT -5
Random thoughts....
... Pure theory - I haven't tested any of this
1)
First - movement after "X" cycles. This could be drift related - the longer you pause the more drift accumulates.
If your theory about a system wide disturbance signal holds true - should it not also be visible if you do a a Reset0Ref() after the pause?
2a) sin
If it is indeed a sin wave it should go back and forth. Thus the next experiment would be: place a marker on the screen and draw a single dot Once with no pause, than with 7500 cycles apart, 15000 cycles apart, 22500 etc.
7500 cycles would correspond to 90 degrees sin wave. If your theory holds I would guess the dot should go something up, than middle, than down. It would probably be not more than a millimeter.
2b)
If a sin wave holds true with you example, than a pause of X = 15000 cycles should generate a stable image. (sin reaches zero after 180 degrees) The question is, is 50Hz a full sin or is 50Hz itself only "half sin" (180 degrees) and the full wavelength would be 25Hz. Than the experiment should be altered accordingly
3) I never really had a testrun on this... (but this again may be a sign that you are correct)
but my feeling is:
If you draw an image on screen and it takes only "slightly" to many cycles, the wobble is most visible. ->
It may be, that being only - say: 600 cycles off - it would than take 1 second for the image to be in the same position again. With 600 cycles off you could see in 1 second a full sin cycle of "wobble" one back, one forth.
...
|
|
|
Post by Peer on Oct 6, 2022 12:49:32 GMT -5
1) First - movement after "X" cycles. This could be drift related - the longer you pause the more drift accumulates. If your theory about a system wide disturbance signal holds true - should it not also be visible if you do a a Reset0Ref() after the pause? All my experiments included a Reset0Ref(). By "draw_object()", I always meant a complete "Reset0Ref(); Moveto(..); Draw_VL()" Not necessarily. It is not guaranteed that the sine wave starts at cycle 0 with sine(0) and has sine(180) at cycle 15.000. Only that within 30.000 cycles all values from sine(0) to sine(359) are seen. This becomes a bit clearer if you think of the following: Assume the program runs at a stable 50Hz, then for just one frame this is exceeded by x cycles and the framerate drops to 49Hz, and in the very next frame is goes back to 50Hz. The sine wave patterns of the first frame and the third frame are not the same, they are displaced by a ratio of x/30.000. And this displacement grows with each further frame. Now assume a stable 49Hz framerate. The dots will not jitter in a nice and regular sine pattern, but with something like a dynamically condensed sine pattern, as the amount of cycles by which the 30.000 are exceeded likely varies from frame to frame. And I think that this is exactly what can be seen as "wobbling". Have a look at the stars (dots) in Mine Storm at the beginning of a mine field, once the sweeper has just disappeared. They are wobbling for a short time, and this wobbling is not a regular wobbling, but shows variations in itself.
See above. A pause of 15.000 cycles only gives you two displacements sine(x) and sine(x+180) = -sine(x). So you will almost always get a jitter instead of a stable image. Again see above. That is what I tried to describe by the 49Hz and the Mine Storm example.
|
|
|
Post by Malban on Oct 6, 2022 13:40:54 GMT -5
The last example could be done with a fixed displacement of e.g. 600 regardless of the start and endpoint of the wave in relation to cycle 0 of 30000 - it would display a wobble of exactly 1 sin curve in 1 second.
|
|
|
Post by Peer on Oct 6, 2022 13:54:40 GMT -5
The last example could be done with a fixed displacement of e.g. 600 regardless of the start and endpoint of the wave in relation to cycle 0 of 30000 - it would display a wobble of exactly 1 sin curve in 1 second. Agreed. I don't have time for that today, but I will try it out tomorrow and then let you know.
|
|