The Atari 2600 is a historical enigma in many ways. On one hand, it was the most popular gaming console of its era, but it was also at the center of the video game crash of 1983 due to the poor quality of its games at the time. It is a fascinating system in many ways that are still relevant today, especially when it comes to pushing hardware much farther than it was designed to go. [nicole] brings us a project that overcomes some of the limitations in its hardware to provide a more modern video output.
At the heart of the Atari is a custom chip called teh Television Interface Adapter (TIA) that generates the console’s video signal as well as handling controller information and a few other tasks. It was designed at a time where memory was expensive, and essentially trades programmer effort to reduce memory requirements. Interestingly, it separates luminance and chrominance information much like S-video does, so that’s where [nicole] focused their efforts. Thanks to some help from an adapter board, the video signals can be intercepted and reprocessed for the S-video standard instead of using RF modulation to send video data out, although this does involve some soldering and modifying of the original Atari hardware. In [nicole]’s case this was a little more involved due to the differences of the 2600jr compared to more standard versions of the console.
While S-video isn’t modern in the strictest sense, as a standard from 1987 it is a huge step forward compared to the available video output methods available in the 1970s when the 2600 was first produced. Plenty of older consoles and other hardware like VCRs and the like used S-video, so if you have a retro gaming setup complete with a CRT you might want to take a look at this 12-input A/V switch to keep everything managed.
“custom chip called teh Television Interface Adapter (TIA)” 2 letters flipped there
Programming for 2600 has been a challenge because of having no video RAM. You had to code to update the video in real time while doing other things, and a missing NOP or extra WSYNC somewhere in the code will cause the picture to roll. So you have to know how many cycle each command does and then count up all the cycles to ensure you have the correct number per line and per frame.
Early games were mostly blocky with overly large number displayed because 2600 was still new and challenging to program back in the day, but as some programmers got better plus some of 2600’s quirks are discovered and exploited*, many later games had greatly improved graphics like many of Activision games and even some of the newer games people are churning out today. Google for 2600 homebrewn games to find available ROMs or source of physical cartridges.
Also with better programming understanding, it was possible to expand the game beyond the original 4k limit by mean of bankswitching chip that checks for write attempt at specific address and flip ROM pages, added SRAM chip (usually as 2k with paged 2k ROM chunks) to get around the tiny 128 bytes RAM on 2600 console, and even sound enhancement like Pitfall 2.
*example of exploited quirk, 2600 could only display 2 players sprite on a single line but if you abuse HMOVE, you could double or even triple the sprite, which made 6 aliens per line possible in Space Invaders.
IIRC that is why Pacman has “ghosts” – the single ghost sprite is in one position one frame and another position the next, so they flicker and appear “ghost like” with a bit of imagination.
“Interestingly, it separates luminance and chrominance information much like S-video does, so that’s where [nicole] focused their efforts.”
The French model utilized this, I vaguely remember.
Since SECAM used a memory system and was too complicated for the VCS, the designer used a trick.
They fed the grayscale levels to a Pong era video chip with SECAM support.
That’s why the SECAM version has ~8 colors only, with the colors of games usually being all over the place.
Some Fench versions of games like ‘Space Shuttle: A Journey into Space’ were being modified to look correctly on the French SECAM VCS.
Also, the switches on the VCS are all software-controlled (except RF channel). It’s up to the games to respond to switch positions accordingly. That’s why the Shuttle game works, at all.
That also goes for the mono/color switch. It’s the game which controls if there’s a color output or not.
J’ai oublié la systeme SECAM!
A l’epoch 80s, mes amis francais ont seulement des ordinateurs “speciale” et spécifiquement fait pour le marché interne la; a cause du systeme SECAM.
masculine and missing an accent, le système IIRC
Btw, to those who wonder, video is usually being generated in this line:
Monochrome+Sync (Luma) and Color (Chroma) -> Composite/CVBS -> RF
Or in words, underlying video signal consists of the monochrome video signal, along with sync/blanking information.
This is known as VBS.
If an color information is mixed with VBS, we get Color VBS (CVBS).
Usually known as Composite video (some voices also describe the plain VBS as Composite.)
If it’s kept separate, on a pin of its own, we get S-Video (aka Chroma/Luma).
If we take VBS/CVBS and and fed it into an RF modulator , the video signal is being modulated on a carrier wave, often along with an audio signal on nearby carrier).
That’s why S-Video often is the source of both Composite and RF.
RGB is a different thing that originated from color TVs. It’s just a raw connection between a color CRT’s indivial tubes and the Red/Green/Blue planes of a RAMDAC. Very primtive, but also very lossless. Unfortunately, it wasn’t being well suited for RF connections.
Composite by comparison evolved from earlier black/white TV technology when CRTs had just a single tube displaying intensity. The monochrome VBS signal is like a single color channel version of RGB, plus the sync/blank informations. Fidelity could be even improved if S-Video had two extra lines for separate blanking and sync.
That’s all just very simplified, of course. But maybe good enough to provide a basic understanding.
Good explanation, I’ve always puzzled over this stuff.
There never was a crash. Atari crashed. They alone were 80% of that 3.2 billion figure.
As Medium put it so eloquently…
“AN ENTIRE VIDEO GAME MARKET CRASH.
BUT ONLY IN CARTRIDGE GAMES.
BUT ONLY IN CARTRIDGES FOR CONSOLES.
BUT ONLY REALLY ONE CONSOLE.
LOCALIZED ENTIRELY IN NORTH AMERICA.”
ColecoVision and ColecoVision Adam and IntelliVision also crashed, though.
Coleco went bankrupt and vanished a few years later. Mattel Electronics closed up and sold off Intellivision asset to Intv who continued to sell for a few more years.
8 bit computers weren’t affected. Apple II, Atari 800, C64, Trash-80, and PC kept selling very well.
Sweet, now you can connect it to your Commodore 1701/1702!