Hacker News new | comments | ask | show | jobs | submit login
NES Graphics – Part 3 (dustmop.io)
197 points by dustmop on Dec 21, 2015 | hide | past | web | favorite | 22 comments

Does the electron gun physically move, though? I thought it was fixed and the beam is just steered with magnets.

The gun fires straight ahead. The electrons it produces are deflected in the desired direction by electromagnets.

I don't think it's possible to create a mechanical way of moving the gun fast enough to achieve the needs of even a low-res TV screen. If it was a physical mechanism, you can imagine it'd break all the time.

Not to mention your TV would sound like it was possessed by a banshee from the servo (presumably) noise.

There was such a thing as a mechanical television:


Not one using an electron gun. The article is specifically about CRTs. (Of course I know about mechanical televisions; I just didn't talk about them because they weren't relevant to the topic.)

Right; the gun is fixed and the beam is "deflected" (that's the term).

No the gun does not move. The author appears to have misunderstood this. I don't find it likely that he would have used the words "physically moves to point" if he meant that the electron beam is deflected magnetically. Still, great article.

electron beam would fit better in the sentence

Something else the article gets wrong, and this is a nitpick, is that it implies every scanline is redrawn every single time. This is called progressive video, and CRTs didn't do this. CRTs did something called interlaced video, where every other scanline is redrawn in a given screen update: Evens, then odds, then evens, and so on. This was done to reduce bandwidth requirements and to prevent flicker.

(Progressive versus interlaced is the difference between the "p" and the "i" in 480p versus 480i, 1080p versus 1080i, and so on.)

Therefore, with interlaced video, each screen update, called a "field", only has half of the data of a complete frame, and the other half is not sent: The next field is one-half of the next frame. Therefore, interlacing cannot be undone cleanly. Deinterlacing, and it's called, is inevitably a process of reconstructing an image which has passed through a rather brutally lossy compression algorithm.

(Distributing interlaced video where the same frame is broken up into two fields, and therefore frames can be reconstructed cleanly, is called "progressive segmented frame". It was used in film-to-video transfer.)


You are mistaken on two counts.

CRT TVs were designed around interlaced broadcast signals, but CRT monitors most certainly supported high resolution progressive scan video. The much vaunted Sony GDM-FW900, for instance, one of the last great CRTs before LCD monitors took over, supported progressive scan resolutions of 1920x1200 at 85hz.

And the NES and most early game consoles really did output a progressive scan signal that CRT TVs could display, through a hack known as "240p". Basically, the device only ever outputs odd fields in an out-of-spec NTSC signal, giving the effect of a progressive scan image with half of the vertical resolution. CRT TVs, being "dumb" analog devices, would just keep redrawing over the odd lines every time, and never ever touch the even lines.

This is the source of the "scanlines" effect of darkened horizontal lines spanning the screen, as these lines were never directly hit by the beam while a 240p game was running. It's also part of why these old games look like crap on modern LCD TVs, as almost all of them have scaling hardware that is ignorant of the 240p hack and incorrectly treats the signal as if it were interlaced, producing tremendously ugly results.

It's interesting how often people make this mistake.

The NES, like virtually all home computing hardware of the 70s and 80s, operates at 60 hz progressive scan of 200 lines, give or take a few. That is, of course, the same bandwidth of the 525 interlaced lines of broadcast video.

In those days, the horizontal and vertical resolution was bound by RAM capacity rather than pure video signal bandwidth.

In either case, the screen is updated at 60 hz.

Watch a broadcast TV signal on an old CRT: The scanlines appear to roll up (or down, depending on how you are trying to perceive them).

Hook up an NES to an old CRT and look closely at the screen: The scanlines are absolutely still. (This is also the case with the full-screen menus of VCRs, with the white text on blue background.)

The NES most definitely outputs progressive-scan video at 240p, with all 240 lines drawn 60 times per second.

Oh boy, those were the tough times for chip designers. sprite0 and mapper triggering are clever hacks that could have been avoided with <100 transistors (8 bit counter) in the PPU to let you trigger an interrupt on arbitrary raster.

but how does the NES know what the CRT is doing? It's not like they are synced up.

The NES's GPU generates sync pulses on the video line - one at the end of each line to make the electron gun's aim to return to the left side, and a long one at the end of each frame for the electron beam path to return to the top left. Circuitry in the TV uses these pulses to keep the picture stable.


They very much are synced up, since the PPU needs to generate the video signal directly: https://en.wikipedia.org/wiki/Picture_Processing_Unit

I'm not familiar with the NES in particular, but typically the software is synced with the video signal via hardware interrupts.

To answer more specifically: the NES doesn't know what the CRT is doing. It's the CRT's responsibility to sync itself to the incoming signal. So there's not bidirectional communication, but they are still synced.

They are synced up; in the NES, the PPU generates the video signal and is also attached to the CPU and provides interrupts at various points in the frame.

It controls the CRT by issuing HBLANK and VBLANK signals.

It doesn't. The NTSC standard outputs scanline-by-scanline, and traditional CRT televisions are synced to the signal.

CRTs wouldn't work if the video device wasn't synced up, whether that's an NES or whatever, it has to know when to send what data. It's not like the TV has a buffer.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact