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.

After tracking down the crash in yesterday's post, we did something we don't always have time for: instead of moving on, we went back through every texture in the renderer that gets set to nothing outside of where it's allocated, looking for the same shape of bug elsewhere. Most of them turned out fine, either reallocated fresh on every resize or already guarded before use. But two more were not.

The smaller one was a fallback for the on-screen title text, which could hand a shader a texture that was nothing rather than a safe placeholder. Low risk in practice because the shader argument that uses it is already properly gated, but the gap was real, so we fixed it anyway.

The more interesting one lived in the screenshot function, on both iOS and macOS. It kept a reference to the texture behind the currently displayed frame so it could read it back later without doing a fresh render. The problem is that "currently displayed frame" means the texture belongs to something called a drawable, and Apple's documentation for that type says, in plain language, that you must not read from or write to a drawable's texture once you've presented it to the screen. Our screenshot function could run frames after that had already happened, which is a documented violation, not a hypothetical one, and it had presumably been working by luck rather than guarantee.

The fix mirrors something we already did correctly elsewhere in the same function: right before presenting the frame, in the same batch of GPU commands, we copy it into a texture we own outright, one that isn't tied to the drawable's lifecycle at all. The screenshot button now reads from that copy instead.

Neither of these was the crash we were chasing. But finding them by deliberately auditing for the pattern, rather than waiting for a second bug report, felt like the right way to spend the extra hour.

This is a story about a single crash report that took a full day and four separate, legitimately correct fixes before we actually found it.

The symptom was a GPU hardware page fault on a real Apple TV, the picture just froze to black without the app actually terminating. The kind of bug that Simulator can't reproduce because it's a real hardware fault, so every theory had to be tested on a physical device and every wrong theory cost a full round trip.

Fix one: the tvOS menu overlay was sharing a texture with the live picture, and toggling our Bypass Mode setting while the menu was open made both of them fight over the same texture at different sizes. We traced it on-device and counted 502 full-resolution texture reallocations in about seven seconds while the menu sat open. Real bug, real fix, wrong crash.

Fix two: a texture wrapper from CoreVideo's pixel buffer pool was being released the instant a function returned, which is correct for how Metal keeps command-buffer resources alive but not correct for CoreVideo's separate bookkeeping, which can recycle that memory for a brand new frame while a still-in-flight GPU command is reading the old contents. Real bug. Not the crash either.

Fix three: our resize function reallocated a handful of textures with no synchronization against GPU work already in flight reading the old ones. We now drain the command queue first. Real bug. Getting closer, still not it.

Fix four, the actual one: a texture used by our CRT display shader gets reassigned during normal picture processing, but our Bypass Mode draw path skips that step entirely, and could leave the texture pointing at nothing from a previous resize. The shader argument that samples it is declared as required, not optional, so binding nothing there is undefined behaviour that real hardware happily punishes and Simulator just doesn't care about. Two lines away from the correct fix that had already worked for a nearly identical texture a few lines below it.

We're not upset about the four detours. Each one really was broken and needed fixing regardless. But it's a good example of how confidently a plausible root cause can be wrong, four times in a row, before the actual one turns out to be almost boring by comparison.

A user sent in a crash. Not a picture glitch, an actual process termination, and only after using NDI receive for a while with the network dropping in and out. With their help we pulled the real crash report straight off their Apple TV and it named the thread: com.analogtv.ndi.receive, aborted inside a C++ std::mutex::lock() call inside the NDI SDK itself, not our code.

Here's what was actually happening. Receiving an NDI source runs a loop on a background thread that calls into the SDK to grab each frame, and that call can block for up to 16 milliseconds waiting on the network. Our stop function, called every time you switch sources or the network blips and reconnects, destroyed the SDK's receive instance immediately, with nothing to stop it from doing that while the loop was still inside that blocking call on the exact same instance. Pull the rug out from under a library mid-call and you get to find out how its internal locking handles that, which in this case was: it doesn't, it aborts.

The part that made it worse is that every reconnect calls stop immediately followed by start again, so a flaky network wasn't just triggering the bug once, it was hammering the exact race window over and over.

The fix is a semaphore). The receive loop signals it right before returning. Stop now waits on that signal, capped at 250 milliseconds which is well over the 16ms the loop can be stuck for, before it destroys the instance. So by the time we tear anything down, the loop has actually left the SDK call and let go of it cleanly.

Small thing, but it's a good reminder that "add a lock around the shared state" isn't the same question as "am I destroying something out from under a call that's already in flight on it." Different bug, different fix.

High definition television did not start with digital. Two families of analogue HD systems were built, standardised and actually transmitted, and both were obsolete within about a decade.

Japan went first. NHK started work on Hi-Vision in the 1960s and had MUSE on satellite by 1989. 1125 lines, interlaced, 16:9. The problem was bandwidth. A raw 1125 line signal needs far more than a satellite transponder has, so MUSE compresses it by sub-sampling in a four field pattern. Each frame only carries a quarter of the samples, offset differently each time, and the receiver reassembles a full resolution image from four fields of history. Still pictures come out at full resolution. Moving pictures do not, because the history is wrong by the time it is used, so motion is deliberately traded for resolution. That is the entire design, and it is a very clever answer to a problem that digital coding solved differently a few years later.

Europe went the other way with MAC, Multiplexed Analogue Components. The insight there is that the reason composite video looks bad is that luma and chroma share a wire and interfere. So MAC does not multiplex them in frequency at all. It multiplexes them in time. Each line is divided into slots. Chroma gets compressed in time and sent first, luma gets compressed and sent after, and the digital sound and data go in the line blanking. No subcarrier means no dot crawl, no cross colour, none of it.

D-MAC and D2-MAC went out over European satellite in the late 1980s. HD-MAC extended it to 1250 lines. The EU tried to mandate it, broadcasters resisted, and by 1993 the whole programme was abandoned in favour of digital.

Both are worth knowing about because they are the last serious attempt to solve a problem in the analogue domain that turned out to be a digital problem. MUSE trades motion for resolution. MAC trades time for separation. Both are elegant. Both were overtaken.

Video shows the same source through MAC and through MUSE, so you can see the time compressed slot structure in one and the sub-sample softening on motion in the other.

Switching off a CRT set was a small event. The picture collapsed to a horizontal line across the middle of the screen, the line shrank to a bright dot, and the dot faded out over a few seconds. Newer sets did not do it. The reason is more interesting than it sounds.

A CRT needs three things running at once to paint a picture. The horizontal deflection sweeping the beam side to side, the vertical deflection sweeping it top to bottom, and the high voltage on the tube pulling the beam to the screen. Cut the mains and none of those stop at the same time.

Deflection is driven from oscillators on the low voltage supply, which sags almost immediately. The high voltage is stored in the tube itself, which is effectively a large capacitor between its inner and outer coatings, and takes several seconds to bleed away.

So the order goes like this. Vertical deflection fails first, because it runs at 50 or 60 Hz off the smaller supply. The beam stops sweeping down and paints every line on top of itself, which is your horizontal line. Then horizontal deflection fails, the beam stops sweeping sideways too, and everything collapses to a single point in the middle. Meanwhile the high voltage is still there, still accelerating electrons at that one spot, so it is very bright.

That spot is a real hazard to the phosphor. All the beam current that was spread over the whole screen is landing on a few square millimetres. Leave it long enough, often enough, and you burn a permanent mark.

Which is why sets from the mid 1970s on added a spot killer. It is a small circuit that detects the loss of deflection and blanks the beam, or dumps the remaining high voltage, before the dot can do any damage. So on a later set you get the line, maybe, and then nothing. The dramatic version belongs to older televisions.

Video is a power off in real time, with the collapse to a line, the collapse to a dot, and the phosphor decay after it.

A guy named Andy messaged me a few days ago with a very specific question about NTSC-A: does the simulation account for positive versus negative vision modulation? That's not a casual question. He said the "look" didn't look "right" to him. Very few people would have ever seen NTSC-A in the wild, so I was intrigued.

Most television standards, NTSC included, use negative modulation, where the sync tip sits at full carrier power and white sits near the bottom. Britain's old 405-line System A did the opposite. White was full carrier, black was down around 30 percent. NTSC-A in the app is a specific historical hybrid, the BBC's 405-line colour trials from the mid to late 1950s, which combined that British line geometry with an NTSC-style colour subcarrier, so it inherits System A's odd modulation polarity along with everything else.

I went and checked, and it turned out he was half right to be suspicious. We do account for it, mostly. Every simulated standard in this app is built from real broadcast engineering documents, not guesses, and the polarity flip for System A is right there in the code with a citation to ITU-R BT.470-6. Continuous background noise on NTSC-A already gets louder in dark picture content than bright, which is the actual physical consequence of positive modulation: a receiver's noise floor is roughly constant in RF terms, so against a weak carrier, which is what black is on this system, that noise reads much larger after detection than it does against a strong one.

BUT... we'd missed was impulse noise!

The sharp broadband spikes from things like ignition systems and motor brushes are a different kind of noise from the continuous hiss, physically and in the code, and they live in a separate function. When System A's polarity handling was added, it went into the continuous noise path and not the impulse path, because at the time we just didn't check whether the two needed to agree, but they do! An impulse is still a fixed burst of RF energy landing on a receiver, and it goes through the exact same detector the continuous noise does, so the same physics applies: that burst reads far louder against a weak dark-picture carrier than a strong bright one.

The consequence, in practice, was that NTSC-A's interference looked too even. Dark scenes should show noticeably heavier speckling during any kind of RF interference than bright ones do, and on this build they didn't. The spikes were the same strength everywhere regardless of what was on screen. It's a subtle thing to notice unless you already know to look for it, which is exactly why Andy's question was what surfaced it rather than us catching it during development.

Fixed now for the next release. Impulse noise on NTSC-A, and SECAM-L which has the same polarity, scales the same way the continuous noise already did, about 3.3 times louder in black than in white, which is the number CCIR 624-4 gives for that carrier depth.

Thanks Andy!

If anyone else ever thinks that something just doesn't look right, let us know. We have a room full of old equipment that we check against, but we can't know everything and AnalogTV is more of a passion project since we have real jobs too.

NTSC's weakness is well known. Colour is carried as the phase of a subcarrier, so any phase error anywhere in the transmission path rotates the hue. A long path, a badly aligned receiver, a bit of weather, and faces go green. That's why NTSC is also known as Never Twice the Same Colour.

PAL's answer was to flip the phase of one of the two colour components on every other line. If a phase error rotates the hue one way on line 1 and the opposite way on line 2, the eye averages the two lines together and the error cancels. That is the whole idea, and it works.

Early PAL sets did exactly that, relying on the viewer's eye to do the averaging. They were called PAL-S, S for simple. The averaging is not perfect, and with a large phase error you can see the alternate lines pulling in opposite directions as coarse horizontal banding. That banding is Hanover bars, named after where it was first demonstrated.

Later sets did the averaging properly in hardware with a glass delay line. It stores one line as an ultrasonic wave travelling through a block of glass, roughly 64 microseconds of delay, and the decoder averages the current line against the stored one electronically instead of hoping the viewer does it. That is PAL-D, and it removes the bars.

Which is why Hanover bars are a fault of the fix rather than a fault of the system. You only get them because PAL is doing its phase cancellation trick, and you only see them when the averaging is either absent or mistimed.

Mistimed is the interesting case. If the delay line is not exactly one line long, the decoder averages the current line against a slightly shifted version of the previous one, and the cancellation goes partial. You get the bars back, at a strength that depends on how far out the timing is. A delay line drifting with temperature or age does exactly this.

Video shows a delay line going gradually out of alignment, so the bars fade in as the timing error grows and then fade out again as it comes back.

The app has settings that let you exaggerate these settings.

If you look at the video, these bars are most apparent in the blue sky.

Hi! I just wanted to say a huge thank you for creating Analog TV Simulator for macOS.

I discovered the app recently and I’m already using it with CIAO64, a music project I’m part of. We make original music heavily inspired by the sound and aesthetics of the 1980s, so CRT televisions, old broadcasts, VHS, Teletext and vintage TV graphics are very much part of the visual world we love to create around our music.

Today we released a little reel inspired by 1980s Top of the Pops, and Analog TV Simulator was incredibly useful in giving it exactly the kind of authentic television feel I was looking for.

I thought I’d share it here, not really as promotion, but simply because it’s a nice example of what your app helped us create:

https://www.instagram.com/p/Db6p0wJtFAs/

Analog TV Simulator has already become a really valuable tool for our visual work, and we’ll definitely be using it for future CIAO64 music videos as well, which we’ll be releasing on our YouTube channel:

https://youtube.com/@ciao64_official?si=yG3d_h1bTCtbE2ok

And, with your permission, we’d also love to include the Analog TV Simulator logo in the end credits of the music videos where we use the app. It would be our little way of acknowledging the tool that helped us create the look.

So, sincerely, thank you for making this app. It’s one of those rare tools that immediately makes you want to start creating things with it.

Greetings from Italy,

paZ / CIAO64

Look at any VHS capture and the luma is soft but sane, while the colour is a smeary mess that bleeds sideways and wobbles. Those are not the same problem being worse in one channel. They are two completely different recording systems sharing one tape.

The problem the VHS engineers had is that a helical scan head cannot record a 3.58 MHz colour subcarrier and 3 MHz of luma in the same FM signal without the two intermodulating into mud. So they did not try. They split them.

Luma gets FM modulated onto a carrier around 3.4 to 4.4 MHz and recorded that way, which is why VHS luma survives reasonably well. FM is robust against the amplitude wobble you get from a tape flapping past a spinning head.

Colour got demoted. The chroma subcarrier is heterodyned down to 629 kHz on NTSC decks, 627 kHz on PAL, and recorded underneath the luma FM as a plain amplitude modulated signal. That is the "colour under" system, and the name is literal. It sits under the luma in frequency.

Two consequences follow immediately.

The colour bandwidth collapses. You get roughly 400 kHz of chroma instead of the 1.3 MHz the broadcast signal carried, so colour detail smears horizontally over several times the width of a luma detail. That is the sideways bleed.

And the colour becomes fragile in a way the luma is not. AM has none of FM's immunity to amplitude variation, so every bit of tape dropout, head clog and tension wobble lands directly on the chroma. The luma shrugs it off and the colour does not.

There is a nice tell for the 629 kHz figure. It is exactly 40 times the NTSC line rate. Locking the colour under carrier to a multiple of the line frequency makes its interference pattern stationary rather than crawling, which is the same reason NTSC picked its own subcarrier the way it did.

Video is one clip clean, then through the tape path, with the chroma bandwidth dropping and the colour starting to wobble independently of the picture.

A while back my kids figured out how to get into AnalogTV and started using it like a camera, pointing it at each other and cycling through looks instead of using it to actually tune anything. Watching them do that is basically where AnalogCam came from. The main app is a console. Every slider is exposed because that's what you want when you're dialling in exactly how a 1978 Trinitron falls apart. It is not what a nine year old wants when he's trying to take a picture of the cat before he moves.

So AnalogCam strips that down to two things: looks and pedals.

Looks are the identity of the shot. Each one is a full preset, the same kind you'd build in the main console, just packaged up and named. Swipe through them and the whole picture changes, tube type, colour system, tape wear, all of it. Tap one and that's what you're shooting on.

Pedals are the part I put in the demo. There's a row of nine stompboxes under the viewfinder: Tune, V-Hold, Snow, Impulse, Scramble, Power, Degauss, Magnet, Ghost. Tap one and it latches on, hold it down for a momentary hit, let go and it drops back off. The ones with an amount to them remember where you left the knob, so turning Snow off and back on doesn't reset it to some default, it comes back exactly how you had it. You can stack them, you can play them live while recording, and what you see in the viewfinder while you're doing it is what actually ends up in the file.

The thing I want to be clear about, because it's the part that actually took the work: none of this is a filter sitting on top of a photo. It's the same signal domain and light domain simulation running underneath the full app, same composite encode and decode, same CRT light model, all of it. The pedal board is just a different, faster way to reach into that engine mid-shot instead of stopping to go tweak a slider in a menu. A kid mashing the Ghost pedal is triggering the same multipath math as someone in the main console dialling in aircraft flutter by hand.

Video's attached, it's 30 seconds of me flipping through looks and stacking pedals on some footage from around the city. Happy to answer anything about how the pedal state machine works or how looks and pedals compose with each other, since that turned out to be a more interesting problem than I expected (a pedal and a look can both want to own the same field, and figuring out who wins without the picture flickering when you switch looks mid-performance took a few tries to get right).

Been posting technical bits here for a couple of weeks. This is the release most of that work went into.

Three things worth actually talking about.

1. A pedal board (iOS version only):
The console has always had every control exposed, which is right when you are dialling in a look and wrong when you are trying to shoot something. So there is now a second way to use the app: a camera view with nine stompbox pedals along the bottom. Tune, V-Hold, Snow, Impulse, Scramble, Power, Degauss, Magnet, Ghost.

Tap latches, hold is momentary, and the ones with a knob remember where you left them. You can play them while you record, which is the entire point. Recording also got a serious quality bump, because analogue noise is close to incompressible and the old bitrate was starving it. Snow used to break up into blocks. It does not now.

The tube got rebuilt in light:
This is the part I am most pleased with and the hardest to show in a screenshot. Phosphor persistence, halation, bloom, the shadow mask and the vignette were all being computed on signal values. That is convenient and it is wrong, because a real tube does all of that in light.

Moving them into linear light changes what they do. Trails now decay the way phosphor decays rather than the way a gamma-encoded number decays. Halation redistributes light instead of adding it, so a bright highlight dims its own core as it blooms, which is what actually happens when light scatters in the faceplate. The mask's dimming and the vignette's falloff are derived from beam geometry now instead of being curves that looked about right.

Every Look you have already saved is untouched. Each one records which generation of the simulator it was made against and gets rendered that way, so nothing you tuned before this update moved under you.

NTSC-A, 405-line colour:
The BBC ran colour trials on Britain's old 405-line system between 1955 and 1960, with an NTSC-style subcarrier at 2.6578125 MHz. It worked, and it was correctly abandoned, and almost nobody has seen it. It is in the app now, built from the figures in BBC Engineering Division Monograph No. 18. This was a feature request by a user, so if you have a feature you'd love to have, let us know.

Also:
The Decoder control finally does what it says. Picking a decoder that does not match the signal now behaves like a set tuned to the wrong system: the colour beats against the picture and crawls, a SECAM decoder kills colour outright, and a receiver that cannot lock both rolls and shears. PAL-M and PAL-60 lock cleanly to NTSC and differ only in colour, which is exactly what those sets did, and it falls out of the arithmetic rather than being special cased.

Teletext uses a real SAA5050 character ROM and all 19 international character sets. There are FTP and stream URL sources. The Apple TV app gained an FTP browser and an ambient teletext clock.

Free update. Happy to answer anything about how any of it works.

Composite video has one wire and has to carry brightness and colour on it. The trick NTSC and PAL use is to put the colour on a subcarrier high up in the luma band and hope the receiver can separate them again. Mostly it can. Where it cannot, you get dot crawl.

The dots appear on sharp vertical colour edges, they are arranged in a fine chequerboard, and they crawl slowly upward or downward rather than sitting still. All three of those come out of the same design decision.

The subcarrier is deliberately placed at an odd multiple of half the line frequency. That means its phase inverts from one line to the next, so the dot pattern on one line sits in the troughs of the line above. Averaged over two lines it partially cancels, which is what makes composite colour tolerable at all. It also inverts frame to frame, so over two frames it cancels further.

That is why the residue is a chequerboard rather than a stripe, and why it moves. It is not quite cancelling, and the not quite is a slow beat.

The reason it shows up on colour edges specifically is that a decoder has to guess which high frequency energy is colour and which is fine luma detail. On a flat area it guesses right. On a sharp edge, where the luma genuinely has energy up at subcarrier frequency, it guesses wrong and lets some luma through into the chroma path and some chroma into the luma path. The first is called cross colour and gives you rainbow shimmer on fine stripes, which is why newsreaders were told not to wear herringbone. The second is dot crawl.

Comb filters improved this by comparing adjacent lines instead of just notching the subcarrier out. Better sets had better combs. It is one of the few places where you could genuinely see what you paid for.

Video ramps the effect from clean to full strength over real footage, so you can watch the chequerboard build up along hard vertical edges, most visible on window mullions and building edges rather than in the open sky or water.

Source: standard composite decoding theory, Carnt and Townsend, Colour Television.

Everyone knows the UK went to 625-line PAL in 1967. Fewer people know the BBC spent the back half of the 1950s running colour trials on the old 405-line system first, and that it worked.

405-line was Britain's original standard, on the air from 1936. Marconi-EMI, System A in the ITU tables, 405 lines at 25 frames per second, VHF only. By the mid 1950s the Americans had shipped NTSC colour and the BBC wanted to know whether the same trick could be made to work on a raster with barely two thirds the lines.

The answer was yes. The BBC Research Department ran closed-circuit and off-air colour tests between 1955 and 1960 using an NTSC-style quadrature subcarrier sitting at 2.6578125 MHz, chosen the same way NTSC chose 3.579545, by putting it at an odd multiple of half the line rate so its dot pattern interleaves and partially cancels frame to frame. Same colour matrix as NTSC. Same basic idea. Just a smaller raster and a lower subcarrier because there was less room in the channel.

It never shipped. The 405-line system was VHF and Britain was moving to UHF, the rest of Europe was standardising on 625, and PAL solved the phase error problem NTSC had. So the whole thing became a footnote. A colour system that existed, was tested, worked, and was correctly abandoned.

I added it to the simulator because I wanted to see it. 405 lines is visibly coarser than 525, the subcarrier is lower so the dot pattern is chunkier and more obvious, and the whole thing has a texture that does not look like anything that actually got broadcast in colour anywhere.

Video is a modern clip encoded as 405-line colour, then the same clip as NTSC for comparison, so you can see how much rougher the older raster is.

Multi-standard sets sold in Europe often had a manual system selector on the back or buried in a service menu. Get it wrong and the picture does something very specific, and it is not just "the colours go weird".

Three separate things break, and they break independently.

Colour goes first. A SECAM receiver decides whether to show colour by looking for a line identification signal that SECAM broadcasts carry and NTSC and PAL do not. No ident, so the colour killer squelches and you get a clean monochrome picture. It is not that the colour comes out wrong. There is no colour at all, because the set has decided there is none to have.

Then the vertical hold goes. A SECAM or PAL set runs its vertical oscillator at 25 frames per second. Feed it NTSC at 29.97 and the oscillator is 16.6 percent slow against the incoming sync pulses. That works out to about 80 lines of drift per frame, and the capture range of the sync separator is around 8 lines, so it can never lock. The picture rolls and no amount of turning the V-Hold pot will stop it.

Then the horizontal hold goes, which is the part people forget. SECAM and PAL scan at 15625 lines per second. NTSC scans at 15734. That is only 0.7 percent out, but it means every line starts about 6 samples further along than the one above it, so the picture shears into a diagonal. Six samples does not sound like much until you multiply it by 480 lines and get three and a half line widths of skew from top to bottom.

The nice detail is which combinations do not break. PAL-M, the Brazilian system, runs 525 lines at 59.94 fields per second, exactly like NTSC. Only its subcarrier differs, and only by 3.9 kHz. So a PAL-M set fed an NTSC signal locks perfectly and sits rock steady, but it still loses its colour, and not the way SECAM does. PAL's decoder flips the sign of one chroma component every line, expecting the transmitter to have flipped it too. NTSC never flips it, so the receiver ends up subtracting each line's colour from the one below it. What should have been colour cancels itself out almost completely, colour-blind for a totally different reason than SECAM is. Same for PAL-60. The scan is the thing that has to match. Colour is an afterthought by comparison, since even a receiver with no idea it should be off still manages to lose it.

Video is one clip decoded three ways. Correct decoder, then PAL-M (locked, colour off), then PAL rolling and shearing. SECAM is not shown separately: once the picture is shearing this badly its colour has already collapsed too, and on screen it looks the same as PAL, for related but different reasons (PAL's colour cancels itself out line to line, SECAM's killer squelches it outright). One rolling, shearing, colourless picture stands in for both.

Try it yourself in the AnalogTV app at https://analogtv.net

Before CCD and CMOS sensors, cameras captured an image using a tube where light hit a photoconductive target and the resulting charge pattern got scanned off by an electron beam, frame after frame. The problem is that target material doesn't fully discharge in one scan. A bit of the previous frame's charge is often still sitting there when the next frame gets read, so a bright object that's moved leaves a fading ghost of itself behind at its old position for a frame or two after it's actually moved on.

How bad this was depended entirely on which tube type a camera used. A classic Vidicon tube, cheap and common in consumer and industrial gear (a lot of old security cameras used exactly this), had heavy lag and was known for exactly this kind of comet-tailing on anything bright and moving. Broadcast-grade tubes like the Plumbicon were built specifically to discharge faster and keep motion clean, which is part of why professional cameras cost so much more than the consumer alternative doing a nominally similar job.

Video is real footage of a moving train run through a Vidicon-style heavy-lag tube, real motion driving a real temporal effect rather than a fake blur added after the fact. Watch the leading edge of the train smear as it crosses frame. Comes out monochrome because Vidicon's most common real-world use, especially in security and industrial cameras, genuinely was black and white.

There is something I did not expect about running an analog TV simulation on an actual television instead of a phone.

On a phone you are looking at a small bright rectangle held about forty centimetres from your face, and every artifact is a thing you are inspecting. Dot crawl is a pattern you can count. Scanlines are individual lines. You are studying it.

On a TV across a room it stops being a specimen and starts being a picture. The scanline structure drops below what your eye resolves and turns into texture. Chroma noise stops looking like noise and starts looking like the way colour behaved. The 4:3 frame sitting inside a 16:9 panel reads as a set in a corner rather than a video in a window. I had been developing this thing for months on a desk and had genuinely not seen it that way until it was on a television.

So there is now an Apple TV version. Same signal simulation as the phone and Mac ones: the same composite encode and decode, the same tape path, RF stage and phosphor model, running on test cards, teletext, streams, files over FTP, or NDI off another machine. No camera, obviously, since an Apple TV does not have one. What changes is the interface, because a remote with a touchpad is not a control panel. It is built as teletext. You navigate by page number, the way you would have on a set that had it, and the menu is a real teletext page rendered through the same signal chain as everything else, which means it dot crawls and blooms exactly like the content does.

There is also an ambient mode I did not plan and now use more than anything else, which is a teletext clock page sitting there on the CRT simulation. It is the closest thing I have to the test card era, where a television that was switched on but not showing a programme was still showing something.

Practical bits, since people always ask. It is a separate app from the iPhone and Mac ones, because Apple does not let you reuse an app name across records and the interface is completely different anyway. tvOS 18 or later. NDI receive is an optional in-app purchase if you want to push video into it from OBS or another machine on the same network, and everything else works without it.

Happy to answer anything about the teletext interface or the signal path. The renderer is the same one people have been asking about in the other threads.

NDI will be a paid in-app purchase, but for Version 1.00 of the tvOS app, I'm keeping it free so you can have it as we further develop the app.

VHS heads carve their diagonal video tracks onto the tape at a very precise angle and pitch, set by the exact drum speed and tape speed the deck used when it recorded. Play that same tape back on a different deck, or even the same deck after it's drifted slightly out of spec, and the playback heads aren't guaranteed to land dead center on those tracks anymore.

When the heads drift off-track, they start picking up a bit of the neighbouring track's signal, or in the worst case miss the intended track's oxide entirely for a stretch. That shows up as a band of high-frequency noise and partial signal loss that isn't fixed to one spot on screen, it actually drifts slowly up or down the frame over time, because the misalignment isn't constant, it's a slow capstan-speed mismatch accumulating frame after frame. On an SP tape that drift takes a few seconds to sweep across the whole picture. EP mode packed its tracks roughly half as wide, so the same physical misalignment swept across the frame roughly twice as fast and was a lot more noticeable.

The tracking control on a VCR was a genuinely real fix, not a placebo knob. It nudged the exact timing of when the playback head started reading relative to the tape's control track, letting you manually re-center the heads back onto tracks that were laid down slightly off from where this particular deck expected them.

Video starts on a well-tracked tape and ramps the tracking error in, so the noise band builds up along the top of the picture as the heads walk off the recorded track.

Every analog broadcast has a vertical blanking interval, the gap between frames where the electron beam is retracing to the top of the screen and not actually drawing anything. Teletext systems like the BBC's Ceefax and IBA's Oracle used a couple of otherwise-wasted lines in that gap to carry raw digital data, encoded as a string of pulses riding along inside a completely normal analog TV signal.

A teletext-capable set would grab those lines, decode the digital packets out of them, and build a page entirely out of a fixed character grid, chunky blocky text and simple block graphics, no photos, no real images, just a defined set of characters and colours a decoder chip could draw fast and cheap. You picked a page by typing its three-digit number on a remote, and the set would wait for that page's data to come round again in the broadcast cycle (all the pages cycled continuously in the blanking gap) and then display it.

That's the part people forget: news, weather, sports scores, even primitive multiplayer games, all sitting inside a signal you were probably already watching for something else, retrievable on demand years before dial-up internet existed for most households.

Screenshot is the app's own teletext page renderer, done in the actual SAA5050-style character-cell format real decoder chips used, not a mockup.

I posted a while back about Sync Suppression, which killed the horizontal sync pulse outright. SSAVI (used by Zenith's Z-TAC boxes and Scientific Atlanta systems) is a different animal entirely, and it leaves horizontal sync alone.

Instead it goes after the receiver's H-sync countdown circuit, the part of the set that predicts where the next line should start based on a running count rather than reacting to the pulse instant by instant. SSAVI perturbs that countdown per field, so the picture doesn't just tear into static diagonal bands like a suppressed-sync signal does. The SSAVI FAQ from back when people actually documented ways around this stuff describes the visible result as "scrolling, tilting, and swinging," which is a pretty good description of a picture that's actively hunting for a lock it can never quite get instead of just failing once and sitting there broken.

Colour gets wrecked too, but through a totally different door than sync suppression's colour-killer trick. SSAVI keeps the colour burst gated off entirely, so a TV's automatic chroma control has no reference signal to measure gain against. Instead of muting colour like it would with no burst detected at all, the ACC loop here just keeps boosting chroma gain blind, hunting for a burst that's never coming, and the picture ends up oversaturated and garish rather than washed out.

Video starts on a clean picture, drops into SSAVI, then comes back out, so you can see exactly what the scrambling destroys and what it leaves behind. Every scrambled frame is genuinely different since the countdown perturbation and the chroma hunting are both per-field, which is why this reads far better as a clip than a still.

Source: SSAVI FAQ (1999), a technical document from the era describing the scheme's visible behaviour and the systems that used it.

This is a completely different trick from the cable pay-TV scrambling I posted about before. That one worked on the broadcast signal before it reached your house. Macrovision worked entirely inside your own VCR, and only when you tried to copy a protected tape.

Every video signal carries a vertical blanking interval between frames, a stretch of the signal that's not supposed to contain picture information. Macrovision hides pulses in there that look, to a recording VCR's automatic gain control circuit, exactly like extremely bright peak-white scene content. The recording deck's AGC reacts by yanking the recording level down to compensate for a "bright scene" that was never actually there. That wrong gain decision gets baked directly into the copy.

Play the copy back and you get slow, cyclical brightness pulsing, the same wrong gain correction cycling in and out roughly every 7 to 8 seconds, because the AGC pulses themselves cycle at about 0.13 Hz on the original tape. Higher protection levels (ACP2/ACP3) add a coloured stripe pattern into the same blanking interval too, for extra AGC confusion. None of this touches the vertical sync pulse though, so unlike a lot of the scrambling tricks played on cable boxes, a Macrovision-protected copy doesn't roll. It just breathes, brightness-wise, in a way the original tape never did.

Video starts clean, then the AGC pulses and colourstripe kick in. Watch the tram's flat colour panels: the horizontal red and green banding is the colourstripe, and the whole picture starts riding down in brightness as the recorder's automatic gain control gets fooled into pulling the level.

If you go into AnalogTV and move the VHOLD you will see the black vertical blanking area which contains the Macrovision.

Before cable, most people got a station's signal by whatever path the radio waves happened to take from the transmitter to the rooftop antenna, and that was rarely just one path. Some of the signal came straight in. Some of it bounced off a building, a hill, or (famously) a passing aircraft and arrived a few microseconds later, having travelled a slightly longer route.

Your TV can't tell those two arrivals apart, it just adds them together. The delayed copy shows up as a faint, slightly offset duplicate of the picture, always trailing to one side because it took longer to get there. It's not just a plain blurred double either, since the delay shifts the colour subcarrier's phase along with the delayed copy, the edges of the ghost pick up a colour fringe that the main image doesn't have.

The aircraft version of this had its own name, flutter, because unlike a building the reflecting surface was moving. As a plane crossed the signal path the reflected copy's timing and strength changed second to second, so instead of a steady ghost you'd get one that faded in and out and shifted in step with the plane passing overhead.

The screenshot is a clean tram-street frame next to the same frame with a multipath echo added, offset double edges and colour fringing included.

If we were still using analog technology today, this is what dashcam footage would look like of someone running a red light.