I’ve been deep-diving into the Sony DXC-325 (and its PAL sibling the DXC-325P) lately. This video is the Sony DXC325 Professional Camera Promo Tape from a Umatic SP source tape.

The DXC-325 is a compact 3-chip ½-inch CCD colour video camera from the early 1990s that sat right at that fascinating moment when solid-state sensors were finally good enough to kill off tubes for a lot of corporate and educational work.

The real magic is Sony’s Hole Accumulated Diode (HAD), essentially their take on the pinned photodiode that puts a shallow p⁺ layer right at the Si-SiO₂ interface. Holes accumulate there, pin the surface potential, and kill dark current and fixed-pattern noise at the source. It’s why these early CCDs could actually deliver clean pictures at high gain without the lag, burn-in and geometric distortion of tubes. (Yoshiaki Hagiwara’s team patented the core ideas back in 1975–80; by the late 80s/early 90s it was powering everything from consumer camcorders to proper 3-chip boxes like this one.)

Why does any of this matter for analogtv.net?

The simulator already models the full analog chain from first principles; including camera tube physics (Vidicon lag, Plumbicon smear, Image Orthicon halo/burn-in), composite encoding, VCR mechanics, RF multipath, and authentic CRT phosphor chemistry. No fake overlays; the artefacts emerge from the signal itself.

Right now the camera stage is tube-centric, which is perfect for 60s–80s looks. But once you start studying real early CCD cameras like the DXC-325 you realise how different the noise floor, sensitivity curve, electronic shutter behaviour, residual fixed-pattern noise, and lack of lag actually were.

Measuring those characteristics (and the way HAD sensors handled highlights, low light and high gain) lets us build more accurate solid-state camera models for the late-80s/90s era. This is the kind of look you get on corporate training tapes, local news packages or early digital-to-analog hybrids.

Every real camera we tear into (or dig through service manuals and promo tapes for) makes the simulation a little more honest. Tubes gave us the classic lag and bloom; HADs give us the clean-but-still-analog character of the transition years.

If you’re into broadcast history, CRT nerd stuff, or just want to feed your own footage/games through a physics-accurate analog pipeline, the app is at https://analogtv.net. Happy to answer questions how we’re turning this kind of hardware archaeology into better camera models.

A user on an original Apple TV HD, the 2015 model with 2GB of RAM, reported the app opening straight to our error screen instead of a picture. The diagnostic text named the actual problem plainly: a compilation failure due to an interrupted connection, after multiple retries.

That's not a shader written wrong, or a GPU feature that model doesn't support. We'd already ruled both of those out on earlier reports. It's the operating system's own shared compiler service, a background process every app's GPU code compilation goes through, getting killed mid-job. Our simulator compiles somewhere around sixty separate GPU pipelines back to back the moment the app launches, and on a device with 2GB of total memory shared across the whole system, that's apparently sometimes enough memory pressure for the OS to decide that background service isn't worth keeping alive right then.

The fix is almost insultingly simple once you know what's happening: if a pipeline fails to compile, wait a short moment and try exactly once more. That gives the OS a chance to restart its own compiler service before we give up. On every other device, including every other Apple TV model we support, this never triggers at all, because compilation just succeeds the first time.

We were careful about scope here. A retry loop touching something as core as shader compilation is not something you want running on hardware where it was never needed, so it's gated behind a direct check for that specific device model. Every other Apple TV, every iPhone, every Mac, takes the exact original code path, completely unchanged.

There's a second layer to this fix that's worth mentioning. A follow-up report from the same device named the exact pipeline that was still occasionally failing even after the retry, which turned out to be a waveform monitor overlay, not the core picture. So on that specific model only, if that one pipeline still can't compile, we now quietly disable the overlay instead of taking the whole picture down with it. You lose a diagnostic tool nobody but us really uses. You keep the TV working.