Huh, thank you! I actually played a lot with tweaking VGA this way and that when I had a CRT, it is quite nice that they are analogue in nature, you can mess around with the signal to do interesting stuff with the display. Too bad the VGA had only two oscillators (the ~25.1MHz one for square pixels; 640px width typical, and the ~28.6MHz one for NTSC like clocking; 720px width typical), combined with that the lowest horizontal rate monitors tend to accept is 31KHz, this puts quite some constraints on freedoms.
rv6502 wrote: ↑Sat Nov 23, 2019 11:50 pm
Writing emulators I find it easier to sync purely to the computer's audio using the cycle counters.
So the audio becomes the speed governor. (if audio is disabled then I use a equivalent timer)
The first versions of CUzeBox did exactly this, but people here weren't quite content with it
. Which is reasonable in some regards, if you set up your gear to produce 60Hz, you may well expect emulators of NTSC machines producing smooth, jitter-free output. While that 60Hz may not be exactly 60Hz, and of course on the host, a PC, audio is just not in sync with video generation. So the current CUzeBox uses a complex process control (a variant of PID controller) to maintain sync with video if it is between approx. 58 and 62 Hz, maintaining an audio frequency to match.
This is fast. Buffering frames wouldn't be fast, I paid particular attention to ensure locality where possible (keep stuff in cache), and minimizing RAM usage (so it is more likely to stay in L2 cache). Emulator performance is always a problem, it just always could be better. Such as it would be cool to make Uzebox runnable even on other (reasonably fast ARM or Risc-V) microcontrollers.
So there are reasons why it is built the way it is in its current form.
That you can mix PAL color with NTSC timing I think is intentional. Brazil uses this format (
PAL-M).
True, the serration pulses might relate to transmitting the signal over radio, to have a sufficiently robust vertical sync, so frame timing can stay in sync even if the signal is poor.
In this case however there is a standard (NTSC this case), which defines how equipment should "talk" with each other. When you are the transmitter, it is always the best to strive to adhere to the standard as far as feasible, while when you are the receiver, you may cheat, assuming that the transmitter talking to you uses the standard. TVs in this case are receivers, often cheating regarding how they detect VSync as it works fine with standard signal. However Uzebox is the transmitter.
I think it is important to maintain proper compatibility, so that was a goal in the emulator's design to assist verifying / ensuring that. This avoids "weird issues" when people build the Uzebox, and find it doesn't work with their TV set, or some specific games fail to work (happened quite a few times). Now with CUzeBox, it is quite easy to check whether the signal matches the "golden standard", which is how Megatris does it (one of the first games by Alec, and it of course produces correct sync, matching that of old microcomputers generating progressive scan output).
If you aren't building a kernel, then basically the sync is only correct if it checks out OK in CUzeBox, as the kernel provides part of the timing. If you are actually building a kernel, you could deviate from it as the exact timings of where the edges happen aren't quite set in stone, only the frequencies and the relationships. However there isn't much benefit in deviating, so generally I would say, stick to Megatris.
Of course "if you know what you are doing", you could choose to produce PAL timing (50Hz) for example to get more VBlank time without sacrificing vertical resolution, as you mentioned, likely would work on lots of TV sets.
If there is interest in deviating in these manners, I might consider further techniques in the emulator to adapt. I also would like to build my own AVR console (18MHz ATmega1284), likely I would try to build a new emulator at some point alongside on the CUzeBox codebase, making it more versatile to allow for some variation in hardware (and then providing proper support for PAL timing could also be a nice addition if someone desired to build such a system).
Anyway, what sort of VSync you saw functioning then? I didn't experiment with it myself, I just generally consider things that way that if I am the transmitter of a standardized format, always adhere the standard (and then there should be no problem, or if there is, it isn't on my end). Anyway, it could definitely be worthwhile to make the emulator displaying picture in such cases (obviously showing that the corresponding part of the sync is bad, but behave like most displays, keep running - more friendly for home tinkering, if you get picture on your stuff, you should be able to have picture from the emulator as well).