I wrote an Atari 2600 emulator once, and decided that since the frame timing was unpredictable, I would render the picture similar to how a TV would. I counted the scanlines between each vsync, and used that to center the picture vertically. If the frame ran for more than say 265 lines without a sync, it would retrace on its own. Since the PC video frame rate was a consistent 60 Hz, I had my emulator generate exactly enough pixels as meant for 1/60 second, regardless of sync, and then blit that to the screen. That means, of course, you could end up with portions of two different source frames displayed at the same time, but in practice it seemed fine. The important thing for me was to preserve the overall timing accurately, as well as any visual artifacts from out of spec sync timing. I even had a V-HOLD control on my emulator, that pretty convincingly reproduced the V-HOLD effect from an actual CRT. I think an interesting game to try with the scalers would be Maze Craze. I believe that one did not generate any vsync for a few seconds while it generated the maze, but it did flash different colors during that time so you knew it was working.
I'd defer the auto-refresh until one receives more than 280 lines without sync, since some games ran a bit on the long side. I don't know that any NTSC games got up to 280, but I'm pretty sure some got up to at least 270.
God I love the 2600, and this is EXACTLY why! Making ANY game (much less an attractive or fun one!) took so much care, creativity, and ingenuity. It's a miracle that the system hosted so many incredible games when the hardware is so primitive and finicky. I hope you do more videos on the quirks of the realllllly old/weird tech like this in the future! I know they're very hard to explain, but they're so interesting!
The Atari 2600 will forever remain history's best example of hardware being pushed beyond what its designers intended. It was literally only designed to do two games well: "Tank game" (Combat) and a kind of "Pong to end all Pong clones" (Video Olympics). Everything the hardware was _designed_ to do was aimed squarely at those two games. Two player sprites, two bullet sprites, one ball sprite, the ability to double up, triple up or double the size of some of those things, and some very primitive background graphics so walls and such could be drawn. Atari's engineers knew that was enough flexibility to render the best video games the home had ever seen (the competition was basically just the Fairchild Channel F, after all), and even made the console superior to most of what you could find in arcades at the time, but it really was a short-term bag of tricks. It's only because of the "beam racing" nature of the system that we ever got anything more advanced than those two games. You want to be blown away by the potential of a system with five sprites, you look for videos of Draconian or Mappy.
Leaving so much up to the programmer (for practicality purposes) ended up being one of the best decision Atari made back then. It allowed the system to remain relevant for far longer than it otherwise would have. With no video RAM and only 128 *BYTES* of RAM, it's amazing they could make any kind of games at all with it, but restrictions brought out the best in those early programmers who love an extreme challenge.
@ghost mall What I said was that they made the 2600 superior to most of what you could find in arcades at the time. This statement allowed for the unique case of Space War, which used hardware that is really not remotely comparable. Let's rubber stamp this. The 2600 was released in 1977. In arcades in 1977, you could find the likes of Super Bug, Canyon Bomber, Boot Hill... For one thing, almost every existing game was black and white. And the ones that actually used CPUs (since this was still pretty novel) basically never ran at 60fps. There's no getting around this: The 2600 was vastly superior to what arcades had to offer in 1977. I would argue that Space Invaders (1978) was the first game to convincingly outpace the 2600's *capabilities* in any meaningful respect, though even then, you could in theory produce a much more advanced game for the VCS hardware than Space Invaders.
@@Asterra2 "I would argue that Space Invaders (1978) was the first game to convincingly outpace the 2600's capabilities in any meaningful respect, though even then, you could in theory produce a much more advanced game for the VCS hardware than Space Invaders." You could also create a much more advanced game than Space Invaders to run on Space Invaders hardware. But in an apples-to-apples comparison, you can't duplicate arcade Space Invaders on the 2600. Arcade SI uses a thin-lined, narrow font for text and numbers, which you can't even come close to duplicating on the 2600. It also has higher resolution, so the sprites are smaller and therefore look less blocky than when they are recreated on a 2600, and you can also fit more of them on the screen. Arcade SI has 55 aliens and could fit a lot more on the screen than that, while the 2600 can only fit 36 and couldn't fit any more than that without the aliens being already on top of the shields at the start of the game. Furthermore, arcade SI's sound is far superior to what is possible on the 2600. I think 2600 SI is actually more fun to play than arcade SI though, especially if you do the trick to enable double-shot capability. Nukey Shay's Space Invaders Deluxe (which is a rom hack of 2600 Space Invaders) is even better than the official version.
@@MaximRecoil > But in an apples-to-apples comparison, you can't duplicate arcade Space Invaders on the 2600. And you can't duplicate the 2600 Space Invaders on Space Invaders hardware. Only two colors; sprite control manifestly not capable of moving the entire alien formation in a single frame; the sound hardware, while more flexible, is incapable of reproducing the TIA's output, even somewhat. Anyway, all my points still stand. The Atari VCS will forever remain the only console that was, on paper, more capable than the typical arcade game at the time of its launch.
You should watch Retro Game Mechanics Explained latest video about Atari 2600 if you're interested in the nitty gritty. The hardware of that console barely did anything for you. You were supposed to time everything manually, and the available video memory was enough for half a scanline.
The original Atari is about the most primitive device you can make that can still play a video game. Most of the niceties that we take for granted on pretty much all platforms are "FILE_NOT_FOUND" on the VCS. Most hardware has a frame buffer, for instance. Atari ain't got time for that crap, you get half a line buffer(sort of). Programmers of the day described coding for it as "forgetting every good programming practice you ever learned", because it was so esoteric. It was ruthlessly trimmed down in the name of cost, and the result was a system with just 128 bytes of RAM and a TV controller that had to be micromanaged through the entire frame. (Resulting in an inversion of the game loop from basically everything else. Most game hardware, the game logic takes place while the frame is being drawn and is suspended during VBlank to set up for the next frame. On the VCS, VBlank is where most game logic lives because it is the only time that the poor overworked 6502 isn't spending most of it's clock cycles drawing a picture.)
1977 - Writing a game involves an individual learning all the technical details of the target console, figuring out how the features can be used to make some sort of playable game, and then tediously writing cycle exact assembly code which must be painstakingly tested on real hardware on a continual basis. 2021 - A massive team with millions to spend can write just about anything they can dream up on state of the art tools and with minor modifications can compile the code across a wide range of devices.
Yeah, not really. There is a point where you have to go the old school mode and really optimize the crap out of your code, as seen on Doom 2016 and Witcher 3 on the Switch. And a new API such as Vulkan even supports lower level control of the hardware.
@@fungo6631 You are one of many people who incorrectly believe that DOOM 2016 achieves relatively high framerates because it is "well-optimized". It's not. It's simply _non-demanding_ compared to other (mostly open-world) AAA games. There's not near as much going on, and no near as much to process.
@@fungo6631 I didn't know you were referring to the Switch version of DOOM 2016. I don't know anything about it, but that version may indeed be well-coded and -optimized in order to perform well on the Switch. I was referring to DOOM 2016 on PC. The reason it achieves framerates significantly higher than other contemporary AAA games is that there is very little to process: No open world/high draw distance, no advanced lighting, no NPC AI, no physics, etc. If anything, it proves that you don't _need_ to push technological boundaries if you have great gameplay.
I do take exception to the "there's no such thing as 240p". It wasn't there by design, but it's obviously there, obviously progressive, and obviously can't contain more visual information than about 240 lines. Therefore it exists. You just have to trick the display to achieve it. Thank goodness that feat is possible.
It's interesting because it's a "feature" of the standard that came to light mainly when electronics began using TVs as cheap monitors. Interlacing isn't enforced by the display device at all and in fact, 3 or 4 field interlacing could be done if you tweak the vsync some more (giving more vertical resolution at the expense of flicker).
@@xeostube I'd imagine starting 3 V-syncs at the start of, 1/3 along and 2/3 along horizontally. Basically, the V-sync start horizontal offset determines the vertical offset of the following field.
@@CarbonRollerCaco you're saying that the field is not determined with a binary threshold but just as an analog distance to move the start of the refresh down the screen?
Having a frame buffer results in one frame (about 17 milliseconds on an NTSC console) of input lag. The Atari 2600 has no input lag, and when connected to a CRT like it's supposed to be, you don't get any display lag either, making it as responsive as a video game can possibly be. In addition to being inherently more responsive than the NES, the Atari 2600 also has perfect hit detection, while the NES uses far-from-perfect "hitboxes" for hit detection. Here's an explanation of it from the book Racing the Beam: "In today’s games, collision detection is handled in software. A computationally cheap way to accomplish this is with bounding boxes. In this method, boxes around each object are determined and each pair is checked for intersections. This simple and quick method is nevertheless inaccurate, because an object that does not fill its bounding box may register as colliding with something when it actually does not. The VCS hardware collision is performed by the TIA, which checks for overlapping logic states on its multiple graphics registers. For this reason, only those bits that are turned on in the graphics registers of a sprite can register collision. In other words, the parts of a sprite that are actually seen are the only ones subject to colliding. Thanks to a relatively simple circuit on the TIA, the Atari VCS offers more precise collision detection than is done using the standard technique in modern software toolkits such as Adobe Flash."
Every console BEFORE too. The VCS is unique in managing to shave the hardware down so minimally that it could get away with a quarter-kilobyte of RAM while still outputting real-time color graphics(at a fairly high color depth, no less!). The only thing to come close was RCA's Studio II, which has a half-K of RAM... and a 1-bit black-and-white display.
@@CptJistuce "The VCS is unique in managing to shave the hardware down so minimally that it could get away with a quarter-kilobyte of RAM" The Atari 2600 only has 128 bytes of RAM, which is one-eighth of a kilobyte.
Great video as always! I've been recommending your content when it comes to explaining topics like this, you do a very good job of making things clear.
Before the term "progressive" was thrown around, we just called it "non-interlaced" and it was denoted as ni with interlaced as i. Progressive scan terminology seems to have come about as a product of the HDTV generation.
I think it was a marketing term designed to sell high end DVD players with component 480p output. At least, when I find those old DVD players in thrift stores they prominently brag about their "Progressive Scan"
I am VERY certain that the term "progressive scan" was known to me by 1997. I would have likely picked it up from a Russian language encyclopaedia of technology or some other source like that, as "прогрессивная развертка" if you're curious, and those would have been from the 80s. I have just found Russian lecture notes from around 1998, or date unknown, but i remember this site being around by the late 90s, and none of the sources mentioned therein are newer than 1998, that also use this term. I should probably check the articles that i wrote myself, whether i used the term, because i was a magazine editor at the time, but i don't think i would have. It was probably not commonly used outside of engineering and educational contexts. I checked the manual to 19/23" Mitsubishi DiamondPro CRT monitors, and they call it "non-interlaced". EnTech PowerStrip just doesn't seem to have an explicit word for progressive scan at all, at least as far as i can see from the screenshots that are easy to get hold of.
Personally if the game program worked as intended for target hardware and display standards of the time than it wasn't bug. The Saturn does this alot too.
the devs did have a full documentation of how to properly integrate V-sync in a way it would be compatible with different displays, but for some reason some devs decided to deviate from this! they probably tested it on a couple of displays they had laying around and called it a day, i would call it a bug, even though it is more aking to just an oversight of the devs
When I was a kid in the 80s our TV started to have a vertical hold issue while watching regular television programming. However, most Atari games displayed correctly so my parents bought a new TV and let me have the "broken" TV for games. A hand full of games didn't work they displayed the same vertical hold issue. The Empire Strikes back was definitely one.
@11:48 Some monitors will do that every time they detect any change in the video signal. It might have resynced properly if the frame rate had stayed at 60.5Hz.
Thank you so much for making this video! I have an RGB modded 2600 and have been contemplating hooking it up to a modern Oled display with a Tink5x pro instead of using my Sony HD CRT. It looks like I’ll stick with my CRT for a bit longer as it accepts component natively.
And here I was thinking you'd dive into getting a scaled signal out of a coax cable! Great video though, I grew up with a 2600 myself until I took it apart to figure out how it worked.
I remember in some documentary on Atari, I heard that there were only a few handfuls of programmers in the world smart enough to program for the Atari, I always wondered if they meant the Atari specifically or video games in general because I couldn't understand how such a simple looking machine with such simple games was harder to program for than an arcade machine or microcomputer, but then I watched a video on Racing the Beam and I was like "oh yeah that explains it."
Well that's part of it, definitely, but the VCS was designed to run Pong and Tank games only and it only supports just enough simultaneous sprites and features for those types of games. Racing the beam actually was a blessing in disguise, as you could display more sprites by redefining the existing sprites mid-frame! But yeah, programming the VCS always seemed to me like being MacGyver - turning the components of a Pong machine into something that can play Donkey Kong. Must have been incredibly difficult.
A couple of minor notes: the 8-bit computers by Atari and Apple used scan lines that were 228 chroma clocks in duration rather than 227.5, so even a 262-line frame would be 59.922Hz. For systems that used 227.5 chroma clocks, the choice of 262 or 263 would visually affect the image, since 262 would yield a stable chroma 'checkerboard' pattern, while 263 would yield a checkerboard that swapped phases every frame. The NES for some reason uses a unique horizontal rate which shifts chroma phase by 1/3 every scan line. Also, the question of how to capture video may be affected by how one will edit it. A frame-perfect capture at 59.47Hz may be better synchronized with audio, if played back accurately, than a triple-buffered version, but if an editor tries to convert it to 60Hz that may yield distorted audio if the editor has to insert empty frames to make the timing line up with reality, or only includes 1/60 second of audio with each frame.
Nice and detailed summary of some of the issues with old games! You asked: Is that what happened a bug, considering it worked on 4 decade old hardware - yes, it is. As a dev, I can say for sure. As a dev the answer is simple, you showed part one of it: There's documentation, and the game didn't follow it. Part two, there's the actual way of WHEN vsync should happend by NTSC standard, and that didn't happen. Even if it worked in real life at that time, this is a bug, and it just happened to be exposed later when things followed standards more closely.
The output of the VCS, and in fact just about all game consoles up until and including the 16-bit era, actually never, under no circumstance, follows the NTSC standard with regard to actual timings. It just hits it kinda close enough for CRTs to not be too bothered. The early 3D consoles like Playstation got it to where they can optionally be NTSC compliant, but the most common modes are not. NTSC simply has no provision for non-interlaced video that these output. Also your rigid view of things would prevent any creative and unusual use of hardware. Watch "Poems for bugs" i think by lftkryo, learn about viznut's VIC20 sound kernel, and many other WONDERFUL things. A lot of console games resulted in the official system spec being tweaked or rewritten. For example the streaming system in the original Crash Bandicoot runs afoul of original maximum disc hits per minute spec. Would have been sad had it been just forbidden. Your point of view is understandable from modern perspective, where any deviation from spec will not bring you bliss but only delayed punishment, it's a technical debt at best. Where there is an insane network of interdependencies, which can all get independently be replaced and updated - the underlying hardware, the operating system, hundreds of libs, etc. Where most projects work in large teams with dozens or hundreds of other engineers, and the spec forms the foundation of communication, and even if not, you depend on so many other engineers and each of their individual decisions, and you must be able to trust a common said of foundational assumptions, i.e. the spec. But these are pieces of software written by small teams to run on bare metal, which is guaranteed to not change. It's a whole different approach. The documentation tends to be somewhat sparse too, leaving out many actually useful and important to know details.
@@SianaGearz While I understand what you're saying, and I know that creativity made solutions - it still does (I did under MSDOS and I still do with modern standards) - there's one simple thing. The observation I made may have followed modern standards indeed, it's a simple thing here: There was a spec given by Atari. The spec hasn't been followed. The problem could be solved by following the spec - that's a bug, no discussion there. I get that consoles are a bit trickier, and they especially have been in the past, and I understand that they merely did enough to PAL or NTSC that it "just worked" (look at e.g. the PC and CGA NTSC color artifacting), and that they merily followed the minimum spec to get a picture, I was mainly talking about the part where the specific Atari doc has been shown - which the game didn't follow. One might not have understood this as a potential bug at that time, given that it worked on CRT's, but it is. Thanks for the video recommendations - but I'm getting a bit of a feeling you're thinking I am someone I am not, which feels a bit weird, given the few sentences I have written.
Awesome. I'd like to see more talk about how other systems handled 240p, and from the late 80s on, 480i. It's kind of strange how it's possible to do interlaced video on the 2600, yet its contemporaries and even the NES and SMS can't do 480i.
This may sound kinda random, but thanks for making these videos. They are really informative and entertaining at the same time, and at least for me, helps getting through the day. =)
I had no idea the refresh rate and resolution of the 2600 was controlled by software - I guess I should have, since I already knew the TIA output things to the TV line-by-line in software. The idea of taking away a scanline or two because you feel like programming it that way is insane! Are you planning on doing an explanation video on the black "comb" lines that appear on the left side of some later 2600 games?
Interesting that the Atari 2600 had a "dynamic resolution" in a sense, almost 40 years before it became standard on the Switch (and I believe some PS4/Xbox One games do as well).
I remember battlefield in PS4 and Xbox One had dynamic resolution (specially due to the bug that made 16 by 9 pixels a thing), also titanfall and many, many others. However those implementations were actually made correctly, and mostly changed in-game rendering and not gui/hud
Dynamic Resolution also existed in the ATARI 8-Bit family too. Many games ran in 240P like the 2600 but they would use either 320 or 160 pixel wide display modes for graphics. Moon Patrol on the ATARI 800 used 320 mode for the hud and 160 mode for the actual playfield.
The first time I had to learn the hard way what 240p was, was playing my PlayStation 2 with component cables (after getting my first HD/LCD TV in the mid 2000s) and popping in a PS1 game. Get the game running on the top half of the screen with BIOS garbage on the bottom, if not more problems. Checked the Sony forums, and the only answer I got is that hopefully you still have that composite cable that came in the box, and to swap it in.
The TIA sprite horizontal counters are advanced with every displayed pixel, and can be advanced a programmable amount from 0 to 15 pixels during horizontal sync. Every 160 counts triggers a sprite to display. To move sprites, the end of horizontal blank is delayed by 8 pixels, so the sprite only receives 152 counts. If zero pulses are added, the sprite will move 8 pixels left. If eight are added, the sprite will stay put. If 15 are added, it will move 7 pixels left. It's possible to trigger the insertion of 0-15 motion pulses without the 8 pixels of blanking, but I don't know if anyone was aware of that during the 20th century.
It's an anomaly of how the TIA operates. It's can be hidden by the developer by putting a colored block over it (something that matches the background), or cause that part of the image to go out into the overscan areas of the TV, or they just didn't bother with each because it probably took system resources away from them from being able to make their game.
I'd love a Colecovision video! Seeing how much like the Atari, its a classic system with a thriving homebrew scene. Including ports of MSX games being made in the last few years.
"If you programmed the game in 1980, and it worked as expected on mid-20th century technology, but then later struggled when it came to 21st century technology, is the problem really a bug?" I'd say yes. Not because it stopped working, but because it didn't follow the specs.
Yet at the time it fell within real world specs. No CRT back then would fail with such timing anomalies that is why when video tape tracking are bad, CRTs will still do their best to display that mess no matter how garbage the tracking is, CRTs are too stupid to know any different as they don't have frame buffers and the gun just does what it told like oscilloscopes.
@@Psy500 I wouldn't say it fell within any sort of specs, which are in the end, written requirements. Anything outside that is outside specs, even if it works.
@@felineboy While it didn't fall within the specs of NTSC or PAL, it fell within specs of the TVs themselves. If in 1980 you went to the likes of Sony, RCA or Zenith their engineers would say with confidence that it falls within tolerances provided by the overscan (that exists for just this kind of inaccuracy in the timing). Analog electronic geeks already knew this as far back as the 1973 with the TV Typewriter that was far from accurate in providing a signal.
@@Psy500 Don't confuse specs with tolerance from the devices. It probably would have been harder for the engineers back then to enforce the standard than just letting the device do whatever the signal told them to do, even if not within specs. Let me give an analogy: My English grammar might be bad (which probably is, given it's not my first language). You might understand what I say, but that doesn't mean it's proper grammar.
@@felineboy It is more back then there was no point to enforcing NTSC/PAL that strictly on the TV side. For example you were not going to have the TV blue out just because the user changed channels so all of sudden the TVs sees a new V-blank while it was drawing the previous frame thus got an extra frame. It only a problem now because of displays interpreting the entire frames instead of real time control of the line sweep thus if anything it is a compatibility bug of modern displays not of how devices were designed to work with CRT displays. It would be impossible to convince anyone in the 80s this was a fault since the TV displayed the image fine and it not harming the TV.
Shouldn't we be able to "fix" this by a custom capture card that only needs two lines of vsync and fill any missing scanlines with black to some defined maximum, or even dynamic detect maximum (that is, once too big, stay that big)?
A really excellent video. I was not aware of the way the 2600 handled image signal and graphics. I hope there are more 2600 videos on the way since it is a really fascinating topic. You raise some very interesting points near the end of the video. We tend to look at this quirks as bugs, but at the time it was proper functioning hardware and software. Man, CRTs are great. Yeah, they were bulky and heavy, but the way everything looks in a CRT is way too hard to emulate. Even watching a good quality VCR tape on a CRT looks great. Anyway, your content keeps being really interesting and didactic. Great work.
I guess I'm lucky in that my Sony x900h seems to do well with an Atari VCS/2600 with unmodified games, I mean it's not flawless, Battle Zone plays without any screen issues, Buck Rodgers has a little jumpiness on the title and level screens but otherwise plays fine, the empire strikes back displays without any screen issues. And this is still using RF (using an RCA to F type adapter on the coax input of the TV) before I mod it for composite output and refresh the components. But even when I was a kid back in the 80s not all CRT TVs was tolerant (some TVs was) to these anomalies and would cause the TV to lose v hold for a split second (regardless of how you have everything adjusted), and some TVs took it in stride.
Thanks for the vid! I'm now worried about the performance of my OSSC with my Atari that I plan on RGB modding. I have a PVM, but I use the OSSC and a HDMI to VGA converter to play on my 20" CRT PC monitor.
What if a special converter was made for the 2600. One that basically has a video buffer that collects the video data and doesn't update the screen till vsync?
I have no background in any of this, so what I am about to say may not make any sense, but... What if the converter box would interpret the signal the same way as a crt would, sloppy tolerances and all, into a virtual frame. Then a virtual hd camera would kinescope from that image? Kinda like a power conditioner, but for the video signal.
There are certainly a lot of ways to interpret a video signal, however image processing and conversion is done at the expense of lag. Of course if you are capturing (and potentially streaming) to a device that is independent of what you use to play the game, you could split the analog signal to a CRT for gameplay and do image processing/capture independent of that gameplay to create a trouble-free presentation. Streamers do this already, but you could continue to implement some fancy forms of "CRT-esque" visual processing on the capture side of your chain. ... OR! You could point the camera at your CRT. Heh. The trouble with this is that video cameras pointed at a CRT can be tricky to get just right.
Not so easy. A CRT can change its resolution even for individual frames, but a digital TV signal cannot. You need to fill in the gaps for the missing lines and then you lose sync with the original signal and need to average that out somehow. That's what the converters do.
@@joshuahudson2170 That's fixed by the TV standard. NTSC says it's 525 lines per frame, PAL says it's 625 lines, if I remember correctly. Hmm... industrial monitors have knobs at the back to adjust this - turning them makes the picture taller or wider - so you can use pretty much any amount of lines that you like. When your signal has a vertical retrace pulse, the beam goes back to the top. But modern TVs are typically not happy to show anything else than a proper PAL or NTSC picture.
IMO these issues are bugs. They might've been invisible, but are still violating the spec. The spec is there for a reason, and if you violate it, you have no guarantees that your program will run on all spec-compliant hardware. It would've been impossible to test the game on all available TVs. If you use hacks, coincidental behaviour or private apis, you program might run fine, but you must remember that it will break sooner or later.
Yup, that would explain why some games when it changes screens or does something on screen and the TV would quickly roll/flip/bounce the screen because it lost v hold (and it wouldn't matter how you adjusted the TV it would still happen), I noticed this when I was a kid in the 80s, even back then you had TVs that was intolerant to what signal gets put into them.
This video, folks, is why you should KEEP your old-school analog TV sets. They're beasts for handling this technological wizard-level madness. Key word, ANALOG. Not to say a digital display is bad, (they're far from it) but to have an authentic retro gaming experience without issues, get a CRT TV.
Great video! Maybe its just me, but the background music was competing with your voice and content, which don't need the music to keep audience interest?
I really like the opening background music, and I went to the link, but which song is it exactly, as I can't seem to find it? EDIT - I FOUND IT! It's "Galaxy Joyride" on the album "Ace of Space".
6:15 “But processor execution times for instructions is… unpredictable” Not at all. The number of cycles each instruction takes is well known and documented. Most took two cycles, some took 1 or 3, and everyone who coded for a 6502/6507 would know those timings. Knowing the instruction timings exactly is how writing code that raced the beam was even possible.
It is still unpredictable. Don't forget about looping and branching. A natural variance in cycles required for execution is why Atari implemented the WSync register I explained in the video. Reference the Stella Programmer's Guide, Section 3.2 for details.
@@DisplacedGamers The Stella Programmer’s Guide is saying something different from what you said. You said that instruction times are unpredictable. That’s not true. The Guide says that the program’s loops and branches take unpredictable lengths of time, which is somewhat defensible, though imo a sloppy way of saying it.
It's not technically unpredictable (it's worse in modern cpus where timing depends on caches and whatnot), but it sure is a lot easier to get predictable behavior out of your code if you don't have to count cycles all the time, but can rely on wsync to resynchronize!
@@possible-realities Agreed. WSYNC is a massive convenience for programmers. My sole objection was that instruction timing was called “unpredictable”. I grew up in the Apple II world, in 6502 land, and everyone had an assembly instruction chart that listed cycles taken.
Why does everyone need a scaler? I have my Atari 2600 on a 4k uhd 50" TV through COAX on RF on Channel 2 and have not had any problems at all. Ive had more difficulty with the DSP and my NES on A/V than with a 2600 on analog channel 2.
I immediately subscribed to the channel after I saw that this gentleman knows to distinguish between the “system” that dictates the number of lines in a CVBS signal and the colour encoding standard that dictates … the colour encoding, which are two separate concerns and are way too frequently mixed together into statements like “an NTSC signal” and “a PAL signal”. Well done!
And that’s why i hate my sony bravia tv because not only does it take long to start up by it also sometimes fails to get in synch with composite video signals wich forces me to unplug and replug the composite video jack in order to get a proper image from my nes,and theres also that slight input delay and you can see those combing artifacts in fast scenes such as flashes wich can be very annoying,luckely the frame meister wich i do own solves these issues😁
Really late to this video but.. it deeply annoys me to suggest that interlacing inherently has to use two fields to produce one frame. All video and TV cameras of the time were 1 field = 1 frame, ie every field was a moment in time. Lots of video games that used interlaced modes were like this too, like so many PS2 games for instance.
If these old systems look best on an old television, why isn't there literally anything at all that does what an old television does? These old systems used a moving spot of light, which had momentum, to draw a picture line by line, which you then viewed. The momentum would smooth out things. Instead, literally every capture device/converter/upscaler/everything converts the analog signal into rows of pixels in a very rigid video file. If the video format gets out of line with what the video file suggests, it breaks.
So one idea is to literally make a CRT emulator. Not something like the atari emulator, but a literal program that takes raw video samples and simulates how a CRT draws a picture. You'd have a spot of light that paints to a canvas, with a 2D position and momentum. It would sweep the canvas in a raster, painting pixels as it goes. And just like a CRT it would handle things like this just as well as a real CRT would. But, like a CRT, it wouldn't be a 1:1 display by default. I'm sure some methods could be made to make it 1:1, but its not straightforward.
The only practical solution we have is to do our best to preserve the CRTs we do have. Unfortunately the only economical way to produce good CRTs like the ones we had in the 1990s-2000s would be to produce them on the massive scale that we did… which would not work for obvious reasons. But anything using simple, small, black and white tubes (projectors? wink wink) could be feasible.
Any television set designed to receive broadcasts would need to include circuitry to prevent damage from wonky sync, since otherwise use in conditions of poor reception could cause damage. Monitors designs that weren't based on TV receivers weren't so forgiving, but the Atari wouldn't be connected to those.
Now I can't stop wondering how the electron beam "knows" whether the machine producing the output wants it to stop in the middle or at the end of a scan line. Surely the technology wasn't made with 8-bit computers in mind...
@@DisplacedGamers Thanks. I paid better attention and got it the second time. Incidentally, were you perchance raised in or around Texas? Just curious, having been so myself and finding your speech especially familiar.
It doesn't get any less crazy to me when I'm reminded that the 2600 just... didn't have video memory at all Like I get it, cost-cutting, I understand but... wow
So you're running modified code through a genuine console, send the signal to an external upscaler and then capture that footage while sending it to a modern monitor. This is giving me serious Ship of Theseus vibes xD
If you're going to play a retro game on a modern monitor, would it be preferable to select a modern monitor with the lowest resolution possible so there's less upscaling required? Say a 1366x768 monitor as opposed to a 1440p monitor? I'm under the impression that the more you have to upscale - the worse the image quality. For example if you take a thumbnail sized image and blow it up in photoshop, the bigger you make it - the uglier it gets. Or is this wrong? An upscaler can't add more pixels to the original for more detail right? It just essentially takes the original and stretches it by doubling, etc right?
@@fungo6631 I'm not so sure. Based on my testing at home with emulation using a 1366x768 monitor, a 1920x1080 monitor, and a 2560x1440 monitor it seems the highest res monitors reveal more of the flaws and jaggy edges from blowing up a very low resolution image further and further beyond the original intent. However my tests were done using emulators with internal resolution (software based) upscaling, as opposed to original consoles connected via upscaling hardware, (which I don't have to test and am not familiar with).
The physical screen size makes the biggest difference. The screen can be CRT, plasma, LCD, or OLED - the bigger the screen, the more that low-res content needs to be stretched.
@@KopperNeoman And the more something is stretched - the worse the result right? So a higher resolution monitor demands the small pixel count native image to be further stretched (distorted) than a lower resolution monitor. A larger physical screen size will result in lower pixel density, which would add an additional blurriness but overall, the higher the resolution, the more distorted and flawed the translation.
Higher resolutions can compensate for larger screens by making the individual pixels/dots smaller. That, however, requires the source image to be higher resolution. You'll never magically turn a 480p image into a 4K one.
Racing The Beam is a reasonably interesting book (I bought it), but actually rather lax on specifics. It was calculated to serve pretty much only the kind of information that 99.9% of readers are guaranteed to understand without much hand-holding. You get far more detail from the above video. The result of this is that Racing The Beam's learning crutch-a history lesson of a handful of well-known Atari VCS games-ends up serving more information than what the title of the book implies as its ostensible focus.
That line that divides what is entertaining with what is technical is a really tough one. Stray to far to the technical, and the entertainment is lost, and people lose interest. Err on the side of entertainment, and you maintain the attention of a larger audience without sharing much information on the subject. I thought the authors did great job of balancing both - providing some technical background while making sure they still reached a large audience.
I was really disappointed by racing the beam. It works so hard to dumb things down that it's not actually possible to even guess what he's trying to say in several of the examples. far better info can be found on RUclips. The other book in the series, "the future was here", is great. I highly recommend it, and wish there were more books like that one.
They are faster than the scaler built into your LCD TV, so compared to plugging it in directly it's less laggy. CRT TV: no lag Dedicated upscaler: minimal lag LCD TV: moderate lag
another source on how crazy draing graphics on the Atari 2600 was, i recommend RGME's Video "Racing the Beam", it's very high quality and came out a few days before your video so it makes sense that you likely didn't see it at the time you released yours (even when you likely already had the video finished) ruclips.net/video/sJFnWZH5FXc/видео.html
per LINE graphic update? That must be one of the bigger reasons the NES was so much better looking than the Atari because that, to someone who isnt super knowledgable about such old hardware, sounds extremely CPU taxing to me.
man...perfect timing to see this...just picked up a 5x - should arrive by EOM. running a OSSC this homebrew game (ruclips.net/video/VrWeQcUHwjM/видео.html) dropped sync for too long and lost a great run/score - when I spelled "NINJA" - hope triple buffer can help
Imagine todays point-and-click game-"developers" would attempt to "develop" a game for a limited console such as the Atari 2600/2600jr which has no frame buffer and (correct me if I'm wrong 128 bytes of RAM)
Imagine if those Atari 2600 developers had to develop for a system that demanded that graphics look realistic instead of like one pixel blobs that the users had to use the manual to figure out, or that have long complex stories with (many) NPCs and (much) text, systems where AAA games are hundreds of developers years instead of one developer six weeks. Better yet, imagine a world where we could consider the Atari 2600 without bagging on later developers working on entirely different systems.
Couldn't we just replace the vsync in our brains and skip all this scrambled image nonsense!? The clock speed in our occipital lobe destroys any processor so why not just reprogram it?
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
I wrote an Atari 2600 emulator once, and decided that since the frame timing was unpredictable, I would render the picture similar to how a TV would. I counted the scanlines between each vsync, and used that to center the picture vertically. If the frame ran for more than say 265 lines without a sync, it would retrace on its own. Since the PC video frame rate was a consistent 60 Hz, I had my emulator generate exactly enough pixels as meant for 1/60 second, regardless of sync, and then blit that to the screen. That means, of course, you could end up with portions of two different source frames displayed at the same time, but in practice it seemed fine. The important thing for me was to preserve the overall timing accurately, as well as any visual artifacts from out of spec sync timing. I even had a V-HOLD control on my emulator, that pretty convincingly reproduced the V-HOLD effect from an actual CRT.
I think an interesting game to try with the scalers would be Maze Craze. I believe that one did not generate any vsync for a few seconds while it generated the maze, but it did flash different colors during that time so you knew it was working.
Had no idea emulation involved that much of thought ! Thanks for sharing !
That actually seems like a good easy workaround: Do you have the code on github/gitlab?
@@maxlife459 Unfortunately, I never published the thing, as I never felt I got it quite polished enough.
@@sa3270 Publish the emulator plz
I'd defer the auto-refresh until one receives more than 280 lines without sync, since some games ran a bit on the long side. I don't know that any NTSC games got up to 280, but I'm pretty sure some got up to at least 270.
Right after Retro Games Mechanics Explained's video! Neat!
this is exactly what I thought about when he pulled out the book racing the beam
It was a wonderful coincidence! So happy to see more tech talk for the Atari on YT.
@@DisplacedGamers It's as if the two videos were planned to complement each other
I almost got confused and thought they rebranded tbh
@@DisplacedGamers I quite frankly thought you guys were doing a collab. That timing was good enough to run a 2600 video signal!
God I love the 2600, and this is EXACTLY why! Making ANY game (much less an attractive or fun one!) took so much care, creativity, and ingenuity. It's a miracle that the system hosted so many incredible games when the hardware is so primitive and finicky.
I hope you do more videos on the quirks of the realllllly old/weird tech like this in the future! I know they're very hard to explain, but they're so interesting!
The Atari 2600 will forever remain history's best example of hardware being pushed beyond what its designers intended. It was literally only designed to do two games well: "Tank game" (Combat) and a kind of "Pong to end all Pong clones" (Video Olympics). Everything the hardware was _designed_ to do was aimed squarely at those two games. Two player sprites, two bullet sprites, one ball sprite, the ability to double up, triple up or double the size of some of those things, and some very primitive background graphics so walls and such could be drawn. Atari's engineers knew that was enough flexibility to render the best video games the home had ever seen (the competition was basically just the Fairchild Channel F, after all), and even made the console superior to most of what you could find in arcades at the time, but it really was a short-term bag of tricks. It's only because of the "beam racing" nature of the system that we ever got anything more advanced than those two games. You want to be blown away by the potential of a system with five sprites, you look for videos of Draconian or Mappy.
Leaving so much up to the programmer (for practicality purposes) ended up being one of the best decision Atari made back then. It allowed the system to remain relevant for far longer than it otherwise would have. With no video RAM and only 128 *BYTES* of RAM, it's amazing they could make any kind of games at all with it, but restrictions brought out the best in those early programmers who love an extreme challenge.
@ghost mall What I said was that they made the 2600 superior to most of what you could find in arcades at the time. This statement allowed for the unique case of Space War, which used hardware that is really not remotely comparable. Let's rubber stamp this. The 2600 was released in 1977. In arcades in 1977, you could find the likes of Super Bug, Canyon Bomber, Boot Hill... For one thing, almost every existing game was black and white. And the ones that actually used CPUs (since this was still pretty novel) basically never ran at 60fps. There's no getting around this: The 2600 was vastly superior to what arcades had to offer in 1977. I would argue that Space Invaders (1978) was the first game to convincingly outpace the 2600's *capabilities* in any meaningful respect, though even then, you could in theory produce a much more advanced game for the VCS hardware than Space Invaders.
@@Asterra2 "I would argue that Space Invaders (1978) was the first game to convincingly outpace the 2600's capabilities in any meaningful respect, though even then, you could in theory produce a much more advanced game for the VCS hardware than Space Invaders."
You could also create a much more advanced game than Space Invaders to run on Space Invaders hardware.
But in an apples-to-apples comparison, you can't duplicate arcade Space Invaders on the 2600. Arcade SI uses a thin-lined, narrow font for text and numbers, which you can't even come close to duplicating on the 2600. It also has higher resolution, so the sprites are smaller and therefore look less blocky than when they are recreated on a 2600, and you can also fit more of them on the screen. Arcade SI has 55 aliens and could fit a lot more on the screen than that, while the 2600 can only fit 36 and couldn't fit any more than that without the aliens being already on top of the shields at the start of the game.
Furthermore, arcade SI's sound is far superior to what is possible on the 2600.
I think 2600 SI is actually more fun to play than arcade SI though, especially if you do the trick to enable double-shot capability. Nukey Shay's Space Invaders Deluxe (which is a rom hack of 2600 Space Invaders) is even better than the official version.
@@MaximRecoil > But in an apples-to-apples comparison, you can't duplicate arcade Space Invaders on the 2600.
And you can't duplicate the 2600 Space Invaders on Space Invaders hardware. Only two colors; sprite control manifestly not capable of moving the entire alien formation in a single frame; the sound hardware, while more flexible, is incapable of reproducing the TIA's output, even somewhat.
Anyway, all my points still stand. The Atari VCS will forever remain the only console that was, on paper, more capable than the typical arcade game at the time of its launch.
An "NTSC" signal at 65+Hz? Go home, Buck Rogers, you're drunk
From "Never The Same Color" land, now we get "Never The Same Rate" LOL
I had no idea it was this complicated.. I always thought the hardware controlled the vsync not the game.
You should watch Retro Game Mechanics Explained latest video about Atari 2600 if you're interested in the nitty gritty. The hardware of that console barely did anything for you. You were supposed to time everything manually, and the available video memory was enough for half a scanline.
It does in just about every system but the 2600. Atari figured out how to offload a lot of the hardware functions to the programmer.
@@bryede To save cost, mainly.
The original Atari is about the most primitive device you can make that can still play a video game. Most of the niceties that we take for granted on pretty much all platforms are "FILE_NOT_FOUND" on the VCS. Most hardware has a frame buffer, for instance. Atari ain't got time for that crap, you get half a line buffer(sort of).
Programmers of the day described coding for it as "forgetting every good programming practice you ever learned", because it was so esoteric.
It was ruthlessly trimmed down in the name of cost, and the result was a system with just 128 bytes of RAM and a TV controller that had to be micromanaged through the entire frame. (Resulting in an inversion of the game loop from basically everything else. Most game hardware, the game logic takes place while the frame is being drawn and is suspended during VBlank to set up for the next frame. On the VCS, VBlank is where most game logic lives because it is the only time that the poor overworked 6502 isn't spending most of it's clock cycles drawing a picture.)
1977 - Writing a game involves an individual learning all the technical details of the target console, figuring out how the features can be used to make some sort of playable game, and then tediously writing cycle exact assembly code which must be painstakingly tested on real hardware on a continual basis.
2021 - A massive team with millions to spend can write just about anything they can dream up on state of the art tools and with minor modifications can compile the code across a wide range of devices.
With abstract layers, runtime engines, and common code codebases 😁
Yeah, not really. There is a point where you have to go the old school mode and really optimize the crap out of your code, as seen on Doom 2016 and Witcher 3 on the Switch.
And a new API such as Vulkan even supports lower level control of the hardware.
@@fungo6631 You are one of many people who incorrectly believe that DOOM 2016 achieves relatively high framerates because it is "well-optimized". It's not. It's simply _non-demanding_ compared to other (mostly open-world) AAA games. There's not near as much going on, and no near as much to process.
@@bricaaron3978 You do realize that less open world games can also use higher detail graphics?
And IIRC even MVG praised the Switch version of Doom.
@@fungo6631 I didn't know you were referring to the Switch version of DOOM 2016. I don't know anything about it, but that version may indeed be well-coded and -optimized in order to perform well on the Switch.
I was referring to DOOM 2016 on PC. The reason it achieves framerates significantly higher than other contemporary AAA games is that there is very little to process: No open world/high draw distance, no advanced lighting, no NPC AI, no physics, etc. If anything, it proves that you don't _need_ to push technological boundaries if you have great gameplay.
I do take exception to the "there's no such thing as 240p". It wasn't there by design, but it's obviously there, obviously progressive, and obviously can't contain more visual information than about 240 lines. Therefore it exists. You just have to trick the display to achieve it. Thank goodness that feat is possible.
It's interesting because it's a "feature" of the standard that came to light mainly when electronics began using TVs as cheap monitors. Interlacing isn't enforced by the display device at all and in fact, 3 or 4 field interlacing could be done if you tweak the vsync some more (giving more vertical resolution at the expense of flicker).
"there is no such thing as 240p." - author of video titled History of 240p
PS. Keep up the awesome work, Sack! Longtime sub here.
@@bryede how would you do 3 field interlacing?
@@xeostube I'd imagine starting 3 V-syncs at the start of, 1/3 along and 2/3 along horizontally. Basically, the V-sync start horizontal offset determines the vertical offset of the following field.
@@CarbonRollerCaco you're saying that the field is not determined with a binary threshold but just as an analog distance to move the start of the refresh down the screen?
Framebuffers are a wonderful thing. I'm thankful the NES has one (basically) and every console beyond. Great video!
NES was hardly the first system to use a frame buffer.
Having a frame buffer results in one frame (about 17 milliseconds on an NTSC console) of input lag. The Atari 2600 has no input lag, and when connected to a CRT like it's supposed to be, you don't get any display lag either, making it as responsive as a video game can possibly be.
In addition to being inherently more responsive than the NES, the Atari 2600 also has perfect hit detection, while the NES uses far-from-perfect "hitboxes" for hit detection. Here's an explanation of it from the book Racing the Beam:
"In today’s games, collision detection is handled in software. A computationally cheap way to accomplish this is with bounding boxes. In this method, boxes around each object are determined and each pair is checked for intersections. This simple and quick method is nevertheless inaccurate, because an object that does not fill its bounding box may register as colliding with something when it actually does not.
The VCS hardware collision is performed by the TIA, which checks for overlapping logic states on its multiple graphics registers. For this reason, only those bits that are turned on in the graphics registers of a sprite can register collision. In other words, the parts of a sprite that are actually seen are the only ones subject to colliding. Thanks to a relatively simple circuit on the TIA, the Atari VCS offers more precise collision detection than is done using the standard technique in modern software toolkits such as Adobe Flash."
Every console BEFORE too. The VCS is unique in managing to shave the hardware down so minimally that it could get away with a quarter-kilobyte of RAM while still outputting real-time color graphics(at a fairly high color depth, no less!). The only thing to come close was RCA's Studio II, which has a half-K of RAM... and a 1-bit black-and-white display.
@@CptJistuce "The VCS is unique in managing to shave the hardware down so minimally that it could get away with a quarter-kilobyte of RAM"
The Atari 2600 only has 128 bytes of RAM, which is one-eighth of a kilobyte.
@@MaximRecoil Well, poop. There's goes my basic arithmetic credentials.
Great video as always! I've been recommending your content when it comes to explaining topics like this, you do a very good job of making things clear.
I appreciate that!
Man this all blows my mind. Discovering the ins and outs of games and the tech they run is just as fun as the games themselves.
Before the term "progressive" was thrown around, we just called it "non-interlaced" and it was denoted as ni with interlaced as i. Progressive scan terminology seems to have come about as a product of the HDTV generation.
Just like how "tech" used to mean "technology" or "technician". It's all a bit puerile. :(
I think it was a marketing term designed to sell high end DVD players with component 480p output. At least, when I find those old DVD players in thrift stores they prominently brag about their "Progressive Scan"
I am VERY certain that the term "progressive scan" was known to me by 1997. I would have likely picked it up from a Russian language encyclopaedia of technology or some other source like that, as "прогрессивная развертка" if you're curious, and those would have been from the 80s. I have just found Russian lecture notes from around 1998, or date unknown, but i remember this site being around by the late 90s, and none of the sources mentioned therein are newer than 1998, that also use this term. I should probably check the articles that i wrote myself, whether i used the term, because i was a magazine editor at the time, but i don't think i would have.
It was probably not commonly used outside of engineering and educational contexts. I checked the manual to 19/23" Mitsubishi DiamondPro CRT monitors, and they call it "non-interlaced". EnTech PowerStrip just doesn't seem to have an explicit word for progressive scan at all, at least as far as i can see from the screenshots that are easy to get hold of.
@@Impossiblah It's probably called progressive because the scan smoothly _progresses_ to the "correct" next line instead of skipping one.
@@ShamrockParticle We call the latter a "techie" now. :
I guess we owe those old TVs some respect for being so tolerant of crappy input signals!
Really cool video, i find the way that analoge video works vs how digital video works really interesting
Personally if the game program worked as intended for target hardware and display standards of the time than it wasn't bug. The Saturn does this alot too.
the devs did have a full documentation of how to properly integrate V-sync in a way it would be compatible with different displays, but for some reason some devs decided to deviate from this! they probably tested it on a couple of displays they had laying around and called it a day, i would call it a bug, even though it is more aking to just an oversight of the devs
hmmmm, disregard my post, since i now realize that if a bug was intentional, by definition it is not a bug or oversight lol
When I was a kid in the 80s our TV started to have a vertical hold issue while watching regular television programming. However, most Atari games displayed correctly so my parents bought a new TV and let me have the "broken" TV for games. A hand full of games didn't work they displayed the same vertical hold issue. The Empire Strikes back was definitely one.
@11:48 Some monitors will do that every time they detect any change in the video signal. It might have resynced properly if the frame rate had stayed at 60.5Hz.
12:33 - Key point not mentioned here, the "line dropped" was likely to steal that line for CPU compute instead of pushing pixels during that interval.
Thank you so much for making this video! I have an RGB modded 2600 and have been contemplating hooking it up to a modern Oled display with a Tink5x pro instead of using my Sony HD CRT. It looks like I’ll stick with my CRT for a bit longer as it accepts component natively.
And here I was thinking you'd dive into getting a scaled signal out of a coax cable! Great video though, I grew up with a 2600 myself until I took it apart to figure out how it worked.
I remember in some documentary on Atari, I heard that there were only a few handfuls of programmers in the world smart enough to program for the Atari, I always wondered if they meant the Atari specifically or video games in general because I couldn't understand how such a simple looking machine with such simple games was harder to program for than an arcade machine or microcomputer, but then I watched a video on Racing the Beam and I was like "oh yeah that explains it."
Well that's part of it, definitely, but the VCS was designed to run Pong and Tank games only and it only supports just enough simultaneous sprites and features for those types of games. Racing the beam actually was a blessing in disguise, as you could display more sprites by redefining the existing sprites mid-frame! But yeah, programming the VCS always seemed to me like being MacGyver - turning the components of a Pong machine into something that can play Donkey Kong. Must have been incredibly difficult.
A couple of minor notes: the 8-bit computers by Atari and Apple used scan lines that were 228 chroma clocks in duration rather than 227.5, so even a 262-line frame would be 59.922Hz. For systems that used 227.5 chroma clocks, the choice of 262 or 263 would visually affect the image, since 262 would yield a stable chroma 'checkerboard' pattern, while 263 would yield a checkerboard that swapped phases every frame. The NES for some reason uses a unique horizontal rate which shifts chroma phase by 1/3 every scan line.
Also, the question of how to capture video may be affected by how one will edit it. A frame-perfect capture at 59.47Hz may be better synchronized with audio, if played back accurately, than a triple-buffered version, but if an editor tries to convert it to 60Hz that may yield distorted audio if the editor has to insert empty frames to make the timing line up with reality, or only includes 1/60 second of audio with each frame.
Oooo my retro tink is arriving today I'm so excited!
Nice and detailed summary of some of the issues with old games!
You asked: Is that what happened a bug, considering it worked on 4 decade old hardware - yes, it is. As a dev, I can say for sure.
As a dev the answer is simple, you showed part one of it: There's documentation, and the game didn't follow it. Part two, there's the actual way of WHEN vsync should happend by NTSC standard, and that didn't happen.
Even if it worked in real life at that time, this is a bug, and it just happened to be exposed later when things followed standards more closely.
The output of the VCS, and in fact just about all game consoles up until and including the 16-bit era, actually never, under no circumstance, follows the NTSC standard with regard to actual timings. It just hits it kinda close enough for CRTs to not be too bothered. The early 3D consoles like Playstation got it to where they can optionally be NTSC compliant, but the most common modes are not. NTSC simply has no provision for non-interlaced video that these output.
Also your rigid view of things would prevent any creative and unusual use of hardware. Watch "Poems for bugs" i think by lftkryo, learn about viznut's VIC20 sound kernel, and many other WONDERFUL things. A lot of console games resulted in the official system spec being tweaked or rewritten. For example the streaming system in the original Crash Bandicoot runs afoul of original maximum disc hits per minute spec. Would have been sad had it been just forbidden.
Your point of view is understandable from modern perspective, where any deviation from spec will not bring you bliss but only delayed punishment, it's a technical debt at best. Where there is an insane network of interdependencies, which can all get independently be replaced and updated - the underlying hardware, the operating system, hundreds of libs, etc. Where most projects work in large teams with dozens or hundreds of other engineers, and the spec forms the foundation of communication, and even if not, you depend on so many other engineers and each of their individual decisions, and you must be able to trust a common said of foundational assumptions, i.e. the spec.
But these are pieces of software written by small teams to run on bare metal, which is guaranteed to not change. It's a whole different approach. The documentation tends to be somewhat sparse too, leaving out many actually useful and important to know details.
@@SianaGearz While I understand what you're saying, and I know that creativity made solutions - it still does (I did under MSDOS and I still do with modern standards) - there's one simple thing. The observation I made may have followed modern standards indeed, it's a simple thing here: There was a spec given by Atari. The spec hasn't been followed. The problem could be solved by following the spec - that's a bug, no discussion there.
I get that consoles are a bit trickier, and they especially have been in the past, and I understand that they merely did enough to PAL or NTSC that it "just worked" (look at e.g. the PC and CGA NTSC color artifacting), and that they merily followed the minimum spec to get a picture, I was mainly talking about the part where the specific Atari doc has been shown - which the game didn't follow.
One might not have understood this as a potential bug at that time, given that it worked on CRT's, but it is.
Thanks for the video recommendations - but I'm getting a bit of a feeling you're thinking I am someone I am not, which feels a bit weird, given the few sentences I have written.
Awesome. I'd like to see more talk about how other systems handled 240p, and from the late 80s on, 480i.
It's kind of strange how it's possible to do interlaced video on the 2600, yet its contemporaries and even the NES and SMS can't do 480i.
This may sound kinda random, but thanks for making these videos. They are really informative and entertaining at the same time, and at least for me, helps getting through the day. =)
Thanks!
Great video, great explanations! Thanks a lot! :-]
I had no idea the refresh rate and resolution of the 2600 was controlled by software - I guess I should have, since I already knew the TIA output things to the TV line-by-line in software. The idea of taking away a scanline or two because you feel like programming it that way is insane! Are you planning on doing an explanation video on the black "comb" lines that appear on the left side of some later 2600 games?
It seems black lines are the sign of hardware playfield registers being updated by CPU while also being drawn
Yay you brought back my favorite kind of video!
Interesting that the Atari 2600 had a "dynamic resolution" in a sense, almost 40 years before it became standard on the Switch (and I believe some PS4/Xbox One games do as well).
I remember battlefield in PS4 and Xbox One had dynamic resolution (specially due to the bug that made 16 by 9 pixels a thing), also titanfall and many, many others.
However those implementations were actually made correctly, and mostly changed in-game rendering and not gui/hud
Dynamic Resolution also existed in the ATARI 8-Bit family too. Many games ran in 240P like the 2600 but they would use either 320 or 160 pixel wide display modes for graphics. Moon Patrol on the ATARI 800 used 320 mode for the hud and 160 mode for the actual playfield.
The first time I had to learn the hard way what 240p was, was playing my PlayStation 2 with component cables (after getting my first HD/LCD TV in the mid 2000s) and popping in a PS1 game. Get the game running on the top half of the screen with BIOS garbage on the bottom, if not more problems. Checked the Sony forums, and the only answer I got is that hopefully you still have that composite cable that came in the box, and to swap it in.
I wonder if these issues will ever be able to be fixed on the scaler’s end. That way you could play those games without modifying them.
The data saver option on my YT mobile set the quality of this video to 240p.
CRT forgives, i like that. But on another hand now we have very peaky modern tech. Sucks.
That was very interesting. I have the book Racing the Beam but so far I haven't opened it up.
What are the horizontal lines near the left edge of the screen in Empire, e.g. at 10:41? Is the game doing anything "interesting" with HBLANK?
Almost all atari games have them its up to the programmer to bother with trying to hide them or not as its in the overscan area of a CRT
The TIA sprite horizontal counters are advanced with every displayed pixel, and can be advanced a programmable amount from 0 to 15 pixels during horizontal sync. Every 160 counts triggers a sprite to display. To move sprites, the end of horizontal blank is delayed by 8 pixels, so the sprite only receives 152 counts. If zero pulses are added, the sprite will move 8 pixels left. If eight are added, the sprite will stay put. If 15 are added, it will move 7 pixels left. It's possible to trigger the insertion of 0-15 motion pulses without the 8 pixels of blanking, but I don't know if anyone was aware of that during the 20th century.
It's an anomaly of how the TIA operates. It's can be hidden by the developer by putting a colored block over it (something that matches the background), or cause that part of the image to go out into the overscan areas of the TV, or they just didn't bother with each because it probably took system resources away from them from being able to make their game.
I'd love a Colecovision video! Seeing how much like the Atari, its a classic system with a thriving homebrew scene. Including ports of MSX games being made in the last few years.
"If you programmed the game in 1980, and it worked as expected on mid-20th century technology, but then later struggled when it came to 21st century technology, is the problem really a bug?"
I'd say yes. Not because it stopped working, but because it didn't follow the specs.
Yet at the time it fell within real world specs. No CRT back then would fail with such timing anomalies that is why when video tape tracking are bad, CRTs will still do their best to display that mess no matter how garbage the tracking is, CRTs are too stupid to know any different as they don't have frame buffers and the gun just does what it told like oscilloscopes.
@@Psy500 I wouldn't say it fell within any sort of specs, which are in the end, written requirements. Anything outside that is outside specs, even if it works.
@@felineboy While it didn't fall within the specs of NTSC or PAL, it fell within specs of the TVs themselves. If in 1980 you went to the likes of Sony, RCA or Zenith their engineers would say with confidence that it falls within tolerances provided by the overscan (that exists for just this kind of inaccuracy in the timing). Analog electronic geeks already knew this as far back as the 1973 with the TV Typewriter that was far from accurate in providing a signal.
@@Psy500 Don't confuse specs with tolerance from the devices. It probably would have been harder for the engineers back then to enforce the standard than just letting the device do whatever the signal told them to do, even if not within specs. Let me give an analogy: My English grammar might be bad (which probably is, given it's not my first language). You might understand what I say, but that doesn't mean it's
proper grammar.
@@felineboy It is more back then there was no point to enforcing NTSC/PAL that strictly on the TV side. For example you were not going to have the TV blue out just because the user changed channels so all of sudden the TVs sees a new V-blank while it was drawing the previous frame thus got an extra frame.
It only a problem now because of displays interpreting the entire frames instead of real time control of the line sweep thus if anything it is a compatibility bug of modern displays not of how devices were designed to work with CRT displays. It would be impossible to convince anyone in the 80s this was a fault since the TV displayed the image fine and it not harming the TV.
Shouldn't we be able to "fix" this by a custom capture card that only needs two lines of vsync and fill any missing scanlines with black to some defined maximum, or even dynamic detect maximum (that is, once too big, stay that big)?
A really excellent video. I was not aware of the way the 2600 handled image signal and graphics. I hope there are more 2600 videos on the way since it is a really fascinating topic. You raise some very interesting points near the end of the video. We tend to look at this quirks as bugs, but at the time it was proper functioning hardware and software. Man, CRTs are great. Yeah, they were bulky and heavy, but the way everything looks in a CRT is way too hard to emulate. Even watching a good quality VCR tape on a CRT looks great. Anyway, your content keeps being really interesting and didactic. Great work.
I guess I'm lucky in that my Sony x900h seems to do well with an Atari VCS/2600 with unmodified games, I mean it's not flawless, Battle Zone plays without any screen issues, Buck Rodgers has a little jumpiness on the title and level screens but otherwise plays fine, the empire strikes back displays without any screen issues. And this is still using RF (using an RCA to F type adapter on the coax input of the TV) before I mod it for composite output and refresh the components.
But even when I was a kid back in the 80s not all CRT TVs was tolerant (some TVs was) to these anomalies and would cause the TV to lose v hold for a split second (regardless of how you have everything adjusted), and some TVs took it in stride.
Thanks for the vid!
I'm now worried about the performance of my OSSC with my Atari that I plan on RGB modding. I have a PVM, but I use the OSSC and a HDMI to VGA converter to play on my 20" CRT PC monitor.
Damn, that's one hell of a technique.
What if a special converter was made for the 2600. One that basically has a video buffer that collects the video data and doesn't update the screen till vsync?
I have no background in any of this, so what I am about to say may not make any sense, but...
What if the converter box would interpret the signal the same way as a crt would, sloppy tolerances and all, into a virtual frame. Then a virtual hd camera would kinescope from that image? Kinda like a power conditioner, but for the video signal.
There are certainly a lot of ways to interpret a video signal, however image processing and conversion is done at the expense of lag. Of course if you are capturing (and potentially streaming) to a device that is independent of what you use to play the game, you could split the analog signal to a CRT for gameplay and do image processing/capture independent of that gameplay to create a trouble-free presentation. Streamers do this already, but you could continue to implement some fancy forms of "CRT-esque" visual processing on the capture side of your chain.
... OR! You could point the camera at your CRT. Heh. The trouble with this is that video cameras pointed at a CRT can be tricky to get just right.
That's effectively what the triple buffer mode is doing.
Not so easy. A CRT can change its resolution even for individual frames, but a digital TV signal cannot. You need to fill in the gaps for the missing lines and then you lose sync with the original signal and need to average that out somehow. That's what the converters do.
@@nmosfet5797 How does the CRT know how much space to advance down for one scanline?
@@joshuahudson2170 That's fixed by the TV standard. NTSC says it's 525 lines per frame, PAL says it's 625 lines, if I remember correctly. Hmm... industrial monitors have knobs at the back to adjust this - turning them makes the picture taller or wider - so you can use pretty much any amount of lines that you like. When your signal has a vertical retrace pulse, the beam goes back to the top. But modern TVs are typically not happy to show anything else than a proper PAL or NTSC picture.
Seems like the real solution is for the scaler to be as relaxed about things as real CRTs were
IMO these issues are bugs. They might've been invisible, but are still violating the spec. The spec is there for a reason, and if you violate it, you have no guarantees that your program will run on all spec-compliant hardware. It would've been impossible to test the game on all available TVs. If you use hacks, coincidental behaviour or private apis, you program might run fine, but you must remember that it will break sooner or later.
Just about a minute in, but I'm already going to subscribe. Your narration is excellent.
Thank you!
Great video!
Buck Rogers Planet of Zoom has problems even on CRTs. When I play it on a 7800, my good old CRT TV loses vertical hold at the title screen.
Yup, that would explain why some games when it changes screens or does something on screen and the TV would quickly roll/flip/bounce the screen because it lost v hold (and it wouldn't matter how you adjusted the TV it would still happen), I noticed this when I was a kid in the 80s, even back then you had TVs that was intolerant to what signal gets put into them.
AMAZING VIDEOOOO
I see it as an incompatibility issue rather than a bug, just like how the Zapper's (at least claimed) disliking of flat-screen TVs isn't a bug
Elgato: [switches self off in pure disgust]
[refuses to come back on]
I understand this machine's feelings. I have also had Mondays like that.
Elgato: Go home, Buck Rogers! Your code is drunk! 😂
As retro scalers get better and more powerful, could VRR theoretically be used to mitigate the essentially variable framerate of the 2600?
Great stuff!
This video, folks, is why you should KEEP your old-school analog TV sets. They're beasts for handling this technological wizard-level madness. Key word, ANALOG. Not to say a digital display is bad, (they're far from it) but to have an authentic retro gaming experience without issues, get a CRT TV.
Great video! Maybe its just me, but the background music was competing with your voice and content, which don't need the music to keep audience interest?
I really like the opening background music, and I went to the link, but which song is it exactly, as I can't seem to find it? EDIT - I FOUND IT! It's "Galaxy Joyride" on the album "Ace of Space".
does this have something to do with the visual flicker on my astrocade?
6:15 “But processor execution times for instructions is… unpredictable”
Not at all. The number of cycles each instruction takes is well known and documented. Most took two cycles, some took 1 or 3, and everyone who coded for a 6502/6507 would know those timings. Knowing the instruction timings exactly is how writing code that raced the beam was even possible.
It is still unpredictable. Don't forget about looping and branching. A natural variance in cycles required for execution is why Atari implemented the WSync register I explained in the video.
Reference the Stella Programmer's Guide, Section 3.2 for details.
@@DisplacedGamers The Stella Programmer’s Guide is saying something different from what you said. You said that instruction times are unpredictable. That’s not true. The Guide says that the program’s loops and branches take unpredictable lengths of time, which is somewhat defensible, though imo a sloppy way of saying it.
It's not technically unpredictable (it's worse in modern cpus where timing depends on caches and whatnot), but it sure is a lot easier to get predictable behavior out of your code if you don't have to count cycles all the time, but can rely on wsync to resynchronize!
@@possible-realities Agreed. WSYNC is a massive convenience for programmers. My sole objection was that instruction timing was called “unpredictable”. I grew up in the Apple II world, in 6502 land, and everyone had an assembly instruction chart that listed cycles taken.
Why does everyone need a scaler? I have my Atari 2600 on a 4k uhd 50" TV through COAX on RF on Channel 2 and have not had any problems at all. Ive had more difficulty with the DSP and my NES on A/V than with a 2600 on analog channel 2.
Does the ossc's pass thru modes work well with displays in regards of this?
I remember having the other Atari 2600...the black one with the tapered front
I immediately subscribed to the channel after I saw that this gentleman knows to distinguish between the “system” that dictates the number of lines in a CVBS signal and the colour encoding standard that dictates … the colour encoding, which are two separate concerns and are way too frequently mixed together into statements like “an NTSC signal” and “a PAL signal”. Well done!
And that’s why i hate my sony bravia tv because not only does it take long to start up by it also sometimes fails to get in synch with composite video signals wich forces me to unplug and replug the composite video jack in order to get a proper image from my nes,and theres also that slight input delay and you can see those combing artifacts in fast scenes such as flashes wich can be very annoying,luckely the frame meister wich i do own solves these issues😁
What is the game at 1:03....the space shooter?
Draconian! An Atari 2600 homebrew port of Bosconian.
@@DisplacedGamers Ah yes.... cool. Thanks my friend!
Crts have technically no horizontal resolution…
Heh. Funny how ALL old CRT TV modes were actually progressive, just with different vertical offsets depending on exact V-sync timing.
Really late to this video but.. it deeply annoys me to suggest that interlacing inherently has to use two fields to produce one frame. All video and TV cameras of the time were 1 field = 1 frame, ie every field was a moment in time. Lots of video games that used interlaced modes were like this too, like so many PS2 games for instance.
If these old systems look best on an old television, why isn't there literally anything at all that does what an old television does?
These old systems used a moving spot of light, which had momentum, to draw a picture line by line, which you then viewed. The momentum would smooth out things.
Instead, literally every capture device/converter/upscaler/everything converts the analog signal into rows of pixels in a very rigid video file. If the video format gets out of line with what the video file suggests, it breaks.
So one idea is to literally make a CRT emulator. Not something like the atari emulator, but a literal program that takes raw video samples and simulates how a CRT draws a picture.
You'd have a spot of light that paints to a canvas, with a 2D position and momentum. It would sweep the canvas in a raster, painting pixels as it goes.
And just like a CRT it would handle things like this just as well as a real CRT would. But, like a CRT, it wouldn't be a 1:1 display by default.
I'm sure some methods could be made to make it 1:1, but its not straightforward.
The only practical solution we have is to do our best to preserve the CRTs we do have. Unfortunately the only economical way to produce good CRTs like the ones we had in the 1990s-2000s would be to produce them on the massive scale that we did… which would not work for obvious reasons. But anything using simple, small, black and white tubes (projectors? wink wink) could be feasible.
Even a standard analog signal from a VHS tape is labeled as "240p".
now that you mention it i remember a myth from the 90s that atari could damage you tv, is it possible to be true?
Any television set designed to receive broadcasts would need to include circuitry to prevent damage from wonky sync, since otherwise use in conditions of poor reception could cause damage. Monitors designs that weren't based on TV receivers weren't so forgiving, but the Atari wouldn't be connected to those.
For the algorithm. ✊
Cool thing about this method is that NTSC to PAL conversions were handled by the game, and not the console. lol
Now I can't stop wondering how the electron beam "knows" whether the machine producing the output wants it to stop in the middle or at the end of a scan line. Surely the technology wasn't made with 8-bit computers in mind...
You may wish to view the video on 525-Line Analog Video on this channel for more details.
@@DisplacedGamers Thanks. I paid better attention and got it the second time.
Incidentally, were you perchance raised in or around Texas? Just curious, having been so myself and finding your speech especially familiar.
It doesn't get any less crazy to me when I'm reminded that the 2600 just... didn't have video memory at all
Like I get it, cost-cutting, I understand
but... wow
Man i haven't seen that tank game in 30 years
So you're running modified code through a genuine console, send the signal to an external upscaler and then capture that footage while sending it to a modern monitor. This is giving me serious Ship of Theseus vibes xD
If you're going to play a retro game on a modern monitor, would it be preferable to select a modern monitor with the lowest resolution possible so there's less upscaling required? Say a 1366x768 monitor as opposed to a 1440p monitor? I'm under the impression that the more you have to upscale - the worse the image quality. For example if you take a thumbnail sized image and blow it up in photoshop, the bigger you make it - the uglier it gets. Or is this wrong? An upscaler can't add more pixels to the original for more detail right? It just essentially takes the original and stretches it by doubling, etc right?
It wouldn't make much of a difference.
@@fungo6631 I'm not so sure. Based on my testing at home with emulation using a 1366x768 monitor, a 1920x1080 monitor, and a 2560x1440 monitor it seems the highest res monitors reveal more of the flaws and jaggy edges from blowing up a very low resolution image further and further beyond the original intent. However my tests were done using emulators with internal resolution (software based) upscaling, as opposed to original consoles connected via upscaling hardware, (which I don't have to test and am not familiar with).
The physical screen size makes the biggest difference. The screen can be CRT, plasma, LCD, or OLED - the bigger the screen, the more that low-res content needs to be stretched.
@@KopperNeoman And the more something is stretched - the worse the result right? So a higher resolution monitor demands the small pixel count native image to be further stretched (distorted) than a lower resolution monitor. A larger physical screen size will result in lower pixel density, which would add an additional blurriness but overall, the higher the resolution, the more distorted and flawed the translation.
Higher resolutions can compensate for larger screens by making the individual pixels/dots smaller.
That, however, requires the source image to be higher resolution. You'll never magically turn a 480p image into a 4K one.
The chad CRT vs the virgin LCD
7800 modded for component or svideo and its beautiful
You should think about doing a dive into the GBA versions of Tony Hawk
Elgato: "Screw you guys, I'm going home".
Racing The Beam is a reasonably interesting book (I bought it), but actually rather lax on specifics. It was calculated to serve pretty much only the kind of information that 99.9% of readers are guaranteed to understand without much hand-holding. You get far more detail from the above video. The result of this is that Racing The Beam's learning crutch-a history lesson of a handful of well-known Atari VCS games-ends up serving more information than what the title of the book implies as its ostensible focus.
That line that divides what is entertaining with what is technical is a really tough one. Stray to far to the technical, and the entertainment is lost, and people lose interest. Err on the side of entertainment, and you maintain the attention of a larger audience without sharing much information on the subject.
I thought the authors did great job of balancing both - providing some technical background while making sure they still reached a large audience.
I was really disappointed by racing the beam. It works so hard to dumb things down that it's not actually possible to even guess what he's trying to say in several of the examples. far better info can be found on RUclips. The other book in the series, "the future was here", is great. I highly recommend it, and wish there were more books like that one.
Racing the beam? 😑
Catching the bus 😄
Yes menu left side Ontario
Adapters reduce lag?!?!? I thought they caused it!
They are faster than the scaler built into your LCD TV, so compared to plugging it in directly it's less laggy.
CRT TV: no lag
Dedicated upscaler: minimal lag
LCD TV: moderate lag
another source on how crazy draing graphics on the Atari 2600 was, i recommend RGME's Video "Racing the Beam", it's very high quality and came out a few days before your video so it makes sense that you likely didn't see it at the time you released yours (even when you likely already had the video finished)
ruclips.net/video/sJFnWZH5FXc/видео.html
Finding an HDMI cable for the Atari 2600 is not happening. After watching the video I can probably see why one was not made.
Frame buffers are for suckers. Long live the 2600
This is why I still have an old TV
Yeah the picture may not be great but I dont have to deal with this kind of issue
And even then some old TVs was intolerant to what signal gets put into it.
per LINE graphic update? That must be one of the bigger reasons the NES was so much better looking than the Atari because that, to someone who isnt super knowledgable about such old hardware, sounds extremely CPU taxing to me.
man...perfect timing to see this...just picked up a 5x - should arrive by EOM. running a OSSC this homebrew game (ruclips.net/video/VrWeQcUHwjM/видео.html) dropped sync for too long and lost a great run/score - when I spelled "NINJA" - hope triple buffer can help
Just use Sony DSC-1024g or HD I think this will fix issues
TIA? souns like "Aunt" in Spanish.
Imagine todays point-and-click game-"developers" would attempt to "develop" a game for a limited console such as the Atari 2600/2600jr which has no frame buffer and (correct me if I'm wrong 128 bytes of RAM)
Imagine if those Atari 2600 developers had to develop for a system that demanded that graphics look realistic instead of like one pixel blobs that the users had to use the manual to figure out, or that have long complex stories with (many) NPCs and (much) text, systems where AAA games are hundreds of developers years instead of one developer six weeks. Better yet, imagine a world where we could consider the Atari 2600 without bagging on later developers working on entirely different systems.
@@prosfilaes *facepalm*
you didn't really get it, but OK.
virgin LCD versus Chad CRT
Couldn't we just replace the vsync in our brains and skip all this scrambled image nonsense!? The clock speed in our occipital lobe destroys any processor so why not just reprogram it?
Just window capture Stella. Have a nice day. But it is amazing more games didn't break up constantly with that silly video of theirs.
Why would you ever even WANT to play an Atari 2600 on anything other than a wood-panelled TV dug out from where it was put in a garage 40 years ago?
LOL! You said A-soos.