Emulation and sync behaviour of a CRT monitor

The Uzebox now have a fully functional emulator! Download and discuss it here.
Post Reply
User avatar
Jubatian
Posts: 1381
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Emulation and sync behaviour of a CRT monitor

Post by Jubatian » Sat Nov 23, 2019 6:39 pm

Thoughts over how emulation may be improved regarding how it catches sync, what it may display when the signal is incorrect. CUzeBox currently mostly either draws a solid image or nothing at all. In some regards to try to remedy what Stephane (rv6502) mentioned, giving some difficulty designing video modes (that is if the emulator doesn't pick it up, you get a blank screen with no reasonable sync indicators either, making it difficult to figure out what is even wrong).

For this, some insight is necessary on how a CRT operates. I never checked that myself down to the electronic, just making some assumptions by common sense. Please correct if wrong.

What I believe is that the CRT mostly runs at its own pace (60Hz NTSC), when it receives signal, synchronizing its operation to the signal.
  • HSync pulses: Triggers a horizontal retrace (deflects beam to the left), probably simply as long as the sync is active.
  • VSync pulse: When it matches, probably triggers a mechanism to do the vertical retrace (deflects beam to the top).
  • Otherwise beams runs at a steady pace towards the right (~55 usec across the monitor), and at a steady pace towards the bottom (~14ms from top to bottom).
The behaviour without signals is what probably can be tuned by pots, how wide the horizontal / vertical sweep is and where it begins (image size & position respectively).

The emulator I think already behaves by these principles, the hsync condition causing it a horizontal retrace (advances to next line), and the vsync one a vertical retrace.

However two things are definitely not wholly correct:
  • The emulator establishes 60Hz by the vertical rate provided by the game. This obviously isn't anything anywhere near the truth, it is fine when the game behaves right producing sync, otherwise not. But as the emulator's architecture is now, due to the audio / video syncing constraint (notably video to the host where the emulator is running, if host is set up to use a 60Hz display), I don't think this is possible to change. Or maybe it could cause the emulator abandoning this precise sync with the host if the timing of the game is off.
  • Capturing the VSync pulse is quite crude, and so it often misses for signals which actual TVs may still be able to pick up. This might be possible to be improved (I just didn't find too high need for this as even figuring out cycle counts for a video mode with trial-and-error would rarely cause this to be a problem, at least I didn't find it so with my designs).
Any thoughts?

rv6502
Posts: 53
Joined: Mon Feb 11, 2019 4:27 am

Re: Emulation and sync behaviour of a CRT monitor

Post by rv6502 » 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 video is displayed using a small queue, regulated by computer's vsync or a timer, and doing a frame discard when the emulation is faster than the display (eg: a 50Hz display)

If the computer display is >60Hz frames are output whenever one is completed
if the computer display is <60Hz buffer 1 or 2 in the queue, past that: discard


Regarding CRTs, they start going to the right at a fixed rate as soon as the blanking signal is stopped and they keep going right (clamped to the off-screen right edge)

Right until the Phase Lock Loop (PLL) says screw that! I need my switching power supply to work!

CRTs/TVs have a built-in time-out as the 15Khz signal also drives the flyback transformer / switching PSU.
the PSU's PLL syncs to the hsync when it's there, otherwise it generates something around 14Khz (anything a bit slower than normal hsync)

At any time any blanking will move the beam back to the left (discharges the horizontal drive capacitor).
It's not instantaneous but for all practical purposes for the emulator (it doesn't have to cope with real-life RF noise) we can consider it instantaneous.

Useless detail: The H-position knob controls how fast that hblank-capacitor discharges and releases the beam (it's a bit of a hack)
The H-hold knob adjusts the threshold (for hardware RF noise, which we don't care for an emulator)


The vertical scan works the same way but at 60Hz:

The blanking signal charges a capacitor, once it goes past a threshold the TV/CRT takes that as a vertical blank and moves the beam back to the top and hold it there until it discharges back down past a lower threshold (it's got a bit of an hysteresis, we don't really care about this detail for an emulator).

Digital tuners just do: when the blank is longer than the non-blank it's considered a vertical blank.

Multi-sync monitors have more built-in smarts to figure out when the sync polarity was inverted. ( signal over multiple frames got more lines "more-off-than-on" than "more-on-than-off", that's why they take "forever" to figure out there's a signal )

CRTs are picky about the horizontal sync you can vary it but not "too much".
However CRTs are generally not too picky about the vertical rate. (TVs are more often picky)

As long as the color signal is of the right standard and the horizontal frequency is within the PLL's tolerance CRTs often accept both 50Hz/60Hz by adding/removing lines. Just gotta adjust the vertical size knob.

On a CRT monitor you could output a 15Khz horizontal (normal horizontal frequency), 120Hz vertical signal of 121 lines and a lot of them would be okay-ish* with it.

(* When doing this you should drop the max brightness because the CRT beam zaps half the screen twice as often. You don't want to burn the phosphor. )

Back in the days (mid-90s) the demoscener Tran made a few demos that did just his and it's super difficult to capture because no VGA capture cards could deal with it but it looked amazing on CRTs




Digital capture cards and digital TVs will usually accept extra lines so you can drop the refresh speed a tiny bit and get extra cycles, but not as much as CRTs.


And some current digital TVs, especially the cheap ones (I have a cheap Haier for example) which aren't locked-down seem to detect the color standard and the refresh/resolution standard separately and will accept a PAL timing with NTSC color burst and vice-versa.
( I haven't tested it in details )

So there's a LOT of fun to be had even if it doesn't work on all displays.

PS: I think I know how my quick patch broke the debug display for timing... Will look into it again later.

rv6502
Posts: 53
Joined: Mon Feb 11, 2019 4:27 am

Re: Emulation and sync behaviour of a CRT monitor

Post by rv6502 » Sun Nov 24, 2019 2:01 am

Adding from the AD725.pdf data sheet:
If no equalization or serration pulses
are included in the HSYNC input there won’t be any in the
outputs. Although sync signals without equalization and serration pulses do not technically meet the video standards’ specifications, many monitors do not require these pulses in order to
display good pictures. The decision whether to include these
signals is a system trade-off between cost and complexity and
adhering strictly to the video standards.
They're covering their butt by saying "many monitors": I have yet to see one display, be it CRT, LCD, or capture card that requires the serration & equalising pulses.

And from personal experience hsync pulses are not even necessary during vsync. It can just be held low for the entire vblank period. (I still output the syncs on Uzebox because I thought that was what the emulator didn't like and didn't remove them tho)

Old video titlers are one piece of hardware that I can see having an issue with the cheats as they need to line up their signal very precisely.

But all in all, it's about TV trying their best to show a good picture despite terrible radio signals and using cheap designs that ignore unnecessary parts of the standard.

Considering how damaged old VCR tape signals are :lol:

User avatar
Jubatian
Posts: 1381
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Emulation and sync behaviour of a CRT monitor

Post by Jubatian » Sun Nov 24, 2019 10:30 am

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 :P . 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).

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests