|
Post by bob on Nov 7, 2019 23:24:53 GMT -5
Has anyone characterized the relationship between vector strength and scale? My impression is that if you cut the strength in half and double the scale, the resulting line is approximately the same length as before, but not quite. Is that true? Does it vary from Vectrex to Vectrex, e.g. based on calibration? Is there a formula for predicting the length of a line?
Thank you, Bob
|
|
|
Post by Peer on Nov 8, 2019 3:36:46 GMT -5
Has anyone characterized the relationship between vector strength and scale? My impression is that if you cut the strength in half and double the scale, the resulting line is approximately the same length as before, but not quite. Is that true? Does it vary from Vectrex to Vectrex, e.g. based on calibration? Is there a formula for predicting the length of a line? Thank you, Bob Hi Bob, I did indeed do some investigations regarding this a couple of months ago. Unfortunately, I had to stop at one point due to some other urgent matters, and I did not write up my findings properly. I still have some notes though, and going back to further investigating is one of the things at the top of my to-do list. Here is a "short" summary of what I recall: Everything is relative First of all, please note that all my investigations and all my present findings relate to using the BIOS routine Draw_VLp() for drawing vectors and vector lists. The findings listed below should also be valid for the other BIOS drawing routines, but might be different if the VIA is programmed directly, or if some of the other new and modern techniques for drawing vectors are used. From now on, let SF stand for scale factor, i.e. the value put into VIA_t1_cnt_lo. This value can also be interpreted as "the time it takes to draw one vector", but only in a certain sense. Also, let (Y, X) denote vectors as used in vector lists. In theory, double SF should result in a line of double length on the screen, and double vector strength should also result in a line of double length on the screen. Now relativity comes in. There are no absolute coordinates on the Vectrex, and thus there is no absolute notion of a unit length. So what do we mean by line of double length? Double length in cm when physically measuring the object on the screen with a ruler? Let us assume that this is our notion of theory. First observation: A real Vectrex does not behave according to theory. If (Y, X) drawn with SF results in A cm on the screen, then (Y, X) drawn with 2*SF does not necessarily result in 2*A cm on the screen. A possible conjecture is that there is a linear relation though, meaning (Y, X) drawn with (N*SF) results in C1*(N*SF)*A cm, where C1 is a constant. And this constant C1 seems to be slightly different on any real console. Second observation: Drawing vector (2*Y, 2*X) with SF does not necessarily produce the same line on the screen as drawing (Y, X) with 2*SF. Again, a possible conjecture here is that there is a linear relation, meaning (N*Y, N*X) drawn with SF results in the same as drawing (Y, X) with C2*(N*SF), where C2 is a constant. And this constant C2 also seems to be slightly different on any real console, and it also seems to be not exactly the same as constant C1. Note that in real mathematics (2*Y, 2*X) does have twice the length of (Y, X), but since on the Vectrex SF is used as a timer for drawing vectors, and this timer management also takes up a few cycles, plus various analog effects also coming into play, the situation is a bit different here anyway. Third observation: Since SF is often associated with time (and thus performance), it seems to make sense to use scale factors as small as possible. According to theory, drawing (Y,X) with SF should take the same time (performance) as drawing (Y,X),(Y,X) with 0.5*SF. The first two observations tell us that the result on the screen will not be exactly the same in terms of length (there is also the connecting dot in between the vectors, but let us forget about that), but also performance is slightly different, at least when using the BIOS drawing routines. Why? Because there is also a bit of performance overhead for managing the vector list and iterating through it. For that reason, it seems sensible to use the shorter vector list and the higher SF. But again relativity hits. What I found is that which of the two approaches is more performant, depends on the specific length of the vector list, on the strength of the vectors, and on the specific SF being used. Meaning, for certain vector lists and scale factors, it is faster to use a short list and a higher SF, while for other vectors lists and scale factors it is faster to double up the vectors and use a smaller SF. I had actually made the attempt to come up with a formula here, but that is still ongoing research. I have to revisit the scratch notes I took while investigating this. What I remember is that at the end my personal conjecture was that the two constants C1 and C2 mentioned above are in fact not constants, but rather functions depending on further parameters, maybe linear in themselves, maybe even of higher order. As a conclusion, this makes it rather difficult to use different scale factors for positioning objects that should have specific distances to each other. The results will usually be slightly different on each real console. On a single console, good values can usually be found just be experimenting long enough. Hope this makes sense, and hope this helps a bit. Would be interesting to know what others might have found out here. Cheers, Peer
|
|
|
Post by bob on Nov 8, 2019 12:03:18 GMT -5
Thank you!
The circuitry uses capacitors to hold the analog voltages. Charging capacitors is inherently non-linear. I wonder if that's the cause of the problem.
- Bob
|
|
|
Post by demirug on Nov 8, 2019 12:53:39 GMT -5
The circuitry uses capacitors and op-amps. There are sample and holds and integrators. This is done because when it was build this was much cheaper than having multiple digital analog converters. This way the vectrex needs just one.
Based on my understanding there is some drift but it is not large enough to cause the issues we are seeing. As long as you don't draw for a long time without zeroing it. If I remember correctly the BIOS adds at least some zeroing for you.
The problem is the tube or to be more accurate the deflection yoke. To safe money the vectrex uses a "cheap" black end white tv tube. It was build and optimized for the normal raster line images. Therefore the electromagnets are just not that good for the vectrex use case as an more expensive arcade vector tube. Therefore the beam movement is not linear to the (delta)voltage you use. I have not figured out the details yet but the bios code gives us some clues. The move functions add additional wait cycles after the timer has run down depending on the voltage. The reason is either that it needs time to stabilize the position or the beam could not move fast enough. I have some possible tests in might to figure this out. Unfortunately I haven't set up a working dev environment yet.
My thesis, that it is supported) is supported by experiments that someone has done with a vectrex on a real vector tube. It shows in the critical games(like clean sweep) the same issues as emulators.
|
|
|
Post by Malban on Nov 8, 2019 14:57:35 GMT -5
Hi, My personal "highlight" experience was, when I connected a different vector monitor to the logic board. A "better" monitor (arcade) monitor, more or less looks exactly as "crooked" as the "normal" emulation. So my personal theories (at least logic board related), concerning analog stuff, integrators and capacitors and the like (at least regarding the Clean Sweep looks) were wrong. I think the vector monitor/circuitry in the vectrex is not top nodge, and there are delays when moving/beam switching. The effect of that LOOKS like it was caused by the logic board, but in fact is not. Tweaking the analog emulation can LOOK like a better emulation, but the true culprit lies in the vector monitor.
The original programmers tweaked Clean Sweep till it looked ok on the combination Vectrex/VectrexMonitor - but what they actually did was to program a crooked Clean Sweep, that gets uncrooked by a crooked monitor:
bad+bad = good!
Just my thoughts...
Malban
PS The movement stuff you mention.
My theory here is a bit different.
In 90% of all vectrex it is ok to neglegt the extra "wait" added. But there are some Vectrex out there, that sometimes need more time to "settle" on a value.
I think the extra waits are for what I call "cranky" Vectrex. Some Vectrex start the Timer later and finish it the same amount later. Some need more time to settle on a DAC value (also dependend on the last values) ...
I even think some need more time to ZERO and more time for the beam to be switched off.
I think the extra waits are just a SAFETY measure - so the routines result looks on all Vectrex the same.
|
|
|
Post by Peer on Nov 11, 2019 10:01:59 GMT -5
Please note that my attempts to formalize the observations were and are not meant as an explanation of the hardware or of what happens in the analog circuitry. They are intended only to provide a model that sufficiently predicts or approximates the results observable on the screen and that can be used as a reference or as a guideline while programming or while designing vector lists. I found this analysis to be extremely useful, and also to work astonishingly well while developing Vec-Man. In that game, each layer of the maze is drawn with a different scale factor. Yet, all the isles are supposed to have the same widths. Vec-Man and all moving objects are positioned using yet another scale factor, but shall of course move along the middles of the isles. This is very easy to achieve in a purely digital model. Just choose proper multiples as scale factors. It looked nicely in the digital emulation of e.g. ParaJVE, but on a real console, the layers and the objects were not properly aligned (note that this has nothing to do with the infamous "vector drift", but with the effects described above). It took some time to find working formulas, but when I had them the results looked as predicted on three of my consoles, and just a very tiny bit off on my fourth console. What also might be worth mentioning here are the "mystery gaps" that appear between connected vectors if certain scale factors are used (at least when using the BIOS drawing routines). Those gaps do not appear for scale factors (n*7 – 1) with n being a natural number, for all others, they do. I found this discovery most surprising. Basically it means that only scale factors 6, 13, 20, 27, 34, … are safe to use. Malban wrote a nice blog entry on this.
Cheers, Peer
|
|