> The NES is in some sense a composite-only system. While there is an RGB mod, it's quite invasive[...]
This is something that a lot of even very plugged into retrogaming people don't really get about the NES and RGB mods. I think it's very counterintuitive for people now that there is no part of the system that operates in actual 'color' information. The NES' video output is composite from start to finish[1], with palette entries corresponding to approximate output frequencies for the color subcarrier.
So there is no canonical palette for the NES - the colors produced by games varied by region, a little bit by unit, and especially because NTSC had trouble with stable color even by TV.
So people imagine that RGB or HDMI mods of the NES are somehow tapping into a missing layer of raw color information, but what it's actually doing is intercepting communications with the PPU and modelling (on an fpga) an extra PPU that does operate in RGB, and then constructing a new video signal from that.
And then you have to pick a palette, because there isn't just one.
I have an RGB modded NES (a US toploader) but I doubt I will ever buy or make another one. At this point I think it's better to just use an upscaler, which will produce no less authentic a picture. The main benefit imo of the rgb mod is that there's less interference so the picture is clearer, even if you just output reconstructed composite from it.
[1] There is actually a model of NES PPU that outputs RGB, it was used in the PlayChoice arcade machines (which generally used RGB monitors, not composite) and it has a palette that most people agree is ugly as sin.
> and especially because NTSC had trouble with stable color
This is why we joked NTSC meant Never The Same Color.
The last thing you wanted to see in NTSC was bright red because you'd continue to see it smear for at least 1/4 of the screen to the right. NTSC "Safe" red wasn't really red. Run a broadcast safe filter on 255,0,0 and see how far off it goes. Should be somewhere around 180,0,0 IIRC. The days of looking at vectorscope to see the red point shoot off while everything else was much closer. When it became easier to get digital images to tape, we'd have to adjust the chroma down on the TBC to bring it back into legal limits which would mean the rest of the other colors would get squashed when the client didn't work in NTSC safe color palletes.
I want a time machine to go back and prevent the US decision makers to not fret about keeping a color system backwards compatible with B&W. I don't care to use the time machine to prevent war, making stock picks or sports bets. I just want to make my future career a little less insane by stopping this idiotic (in hindsight) decision. If there's enough time, I'd try to convince them to keep working on progressive scan and avoid more complications to my future career by not needing to deal with interlacing issues.
It was possible of course, but there are good reasons they were intrinsically linked:
The AC power line frequency was used for the vertical refresh rate for two reasons. The first reason was that the television's vacuum tube was susceptible to interference from the unit's power supply, including residual ripple. This could cause drifting horizontal bars (hum bars). Using the same frequency reduced this, and made interference static on the screen and therefore less obtrusive. The second reason was that television studios would use AC lamps, filming at a different frequency would cause strobing.
You could also play PAL on 60Hz in the US with the right equipment. However, playing the video system on the opposite mains always had a weird flicker in the playback as the native power and playback just didn't line up.
It is similar to the effect that could be seen when using native lighting in a 50Hz mains country while recording video in NTSC. Not everyone would notice, but when you sit in an edit bay working with that footage all day, you notice everything.
Then again, some people don't notice the stuttering that is the result from 24->29.97 either. The modern 4th frame repeat drives me up the wall. </rant>
There was a computer you could switch between 50 and 60 Hz with a button press. This controlled the CPU clock too so you got a faster computer with 60 Hz. But I can't remember what computer it was? Can't have been the Amiga or Atari even though they also could do it, has to have been an older one?
No, not the turbo button, it was the 50/60 Hz software switch that made the computer faster. Hm, might just have been that the gfx chip was working less in 50 Hz come to think of it...
I do remember seeing several computers in the 80s having this switch, but they were all modded. They also required you to have a more expensive monitor that could handle the format change (PAL/NTSC and 50/60hz)
And pal snes conversion of street fighter 2 was really slow! As were lots of games. All my retro hardware is NTSC now (I live UK which was pal territory).
Though UK developers new what they were doing an optimised properly for pal. Goldeneye looks better on pal for example.
No game was ever fully optimized for PAL because it is literally impossible. The only way to fix the squashed down graphics would be to completely re-scale all the art. This re-scaled art would no longer fit in the existing 8x8 tiles so you would then have to completely redo all the background and sprite mappings, you may have problems with overlapping parallax layers no longer lining up to whole tiles, and might have problems with video ram since the re-scale art now requires more memory. Basically a fully PAL optimized game would be pretty much a completely separate port built from the ground up.
But lots of games are successfully pal optimised. You are probably right, maybe it's easier to change resolution of 3d rendered games as it seems towards end of N64 is when optimisation started happening.
Related to this, I never knew just how bad the Sega Genesis composite signal looked until I switched to RGB. It may have the worst composite signal of any system ever.
Europe had RGB so I wonder if that was part of the reason the Mega Drive (Genesis) was so popular. The SNES doesn't look (much?) better than the Genesis when both in RGB, but SNES composite is much much better than Genesis.
I think it might just be the NTSC composite that looks bad. I have never felt any desire to use RGB on my PAL Mega Drive since the composite output looks excellent. On PAL it gives just the right amount of blending to smooth out the dithering, but at the same time is sharp enough to resolve individual pixels, and lacks any sort of rainbow effect which apparently plagues NTSC.
Video and audio quality varies pretty wildly between models of the genesis, so some are better than others. But basically every model has some kind of notorious issue with output fidelity.
I think they pretty often need to be recapped in modern times. More so than contemporary nintendo systems tend to need to, I think.
In the end most of this wasn't really super obvious on an 80s/early 90s consumer CRT though, and I don't think people were really comparison shopping on it.
In France we had a different color system (SÉCAM), while the other european countries were in PAL, but French TV were required to have a Péritel/SCART entry by law, offering RGB input. So the french NES was basically the european PAL version with an extra PAL to RGB converter.
Don't forget MESECAM and PAL-M and the other crazy things we had to deal with in the bad old days. There was one standard (PAL-M I think) that was not NTSC but the difference from NTSC was so slight that you could slap an PAL-M sticker* on an NTSC recording, and the PAL-M tape machine would play it back just fine.
An NTSC tape would play in black and white on a pure PAL-M system. PAL-M was the Brazilian system, created to conform to the 60Hz mains but having the improved colour encoding of PAL.
Before colour TVs, Brazil used the American 60Hz System M (B&W predecessor of NTSC), so when it came time to adopt colour they couldn't choose the European PAL because it would not be compatible with current B&W TV sets, and they didn't want to adopt NTSC* because by then it was clear it was an inferior colour encoding, so they slapped a PAL colour encoding on top of a SystemM B&W signal, resulting in a 525 lines 60Hz without NTSC colour distortions (kinda best of both worlds).
* Also they didn't want to adopt NTSC because they wanted to prop the national electronics industry, so a home made standard meant local TV makers didn't have to compete with imported TV sets.
Brazil used PAL-M. NTSC on a PAL+M would give you B&W video and it was possible to convert the equipment (the VCR) by changing the frequency offset of the color carrier.
Wait a minute: we had SCART in the Netherlands too, but it supported both composite (CVBS) and RGB.
In fact, if you had a composite device (with the yellow, red and black plugs), you could just get one of those cheap passive adapters to hook it up to SCART: https://media.s-bol.com/mwVL1yR45z6E/1144x1200.jpg
IIRC our childhood (Philips) TV had two SCART inputs: one supported both RGB and CVBS, the other only CVBS.
AFAIK the French NES is just a PAL console with an added composite-to-RGB converter. Although it outputs RGB signals, the quality is no better than composite.
When I was young and would play NES, it was usually on an older CRT TV and the NES was connected via the RF connector. So you had the RF interference, and the fine tuning certainly added things because often it had to be adjusted, and then anything with tint, brightness, etc. was adjusted until it looked good in the room. Some problematic TVs had bleeding colors, etc. or brightness issues, or the antenna connector was broken, causing fuzziness, etc.
Take the analog path from NES to TV in that common situation, then the second analog path inside the TV generating the color, then NTSC color/lum separation limitations, and "crisp" or "accurate" is something that couldn't describe the results.
On nesdev.com there's at least one thread where quite a few people are discussing about the best way to capture the color palette from video sources, and argument that there really isn't a "golden palette" because each TV was different and NTSC quirks: a pixel sent to a CRT TV could have different colors depending on its position and the colors/luminance before and after.
So CRT/NTSC fuzziness is part of the memory and nostalgia. I like the NTSC emulation options in FCEUX which do a really good job of the color fringing and smearing that was on CRT TVs and really make it "look" like how it was when I was young.
Wouldn't the palette chosen by Nintendo for use in first-party emulators going for a "nostalgic" feel (e.g. the NES Classic's https://emulation.gametechwiki.com/index.php/Kachikachi) be in some sense the "canonical" palette? At least in the same way that an author's statements about their own previously-published works are "canonical" to those works.
My thinking is that there was certainly an RGB palette that the designers — probably working on something like an Amiga — chose when creating the pixel art for the games; and that Nintendo likely has institutional memory, if not hard records, of what that design-time palette was; and so later palettes in RGB-based emulators were likely chosen to closely resemble those design-time palettes.
* As evidenced by the fact that the (RGB-based) Nintendo VS. System has a different palette than later emulation releases, even at the time Nintendo wasn't sure of the "correct" RGB palette (or has since come around and changed their mind about what that should be).
* There wasn't really any sort of standard devkit. Different developers, different games, different artists used different hardware and software tools to draw their graphics. Nintendo was notoriously crappy to third-party developers during the Famicom years, and Western developers in particular had little institutional support from them. Even if you had the correct palette that Nintendo was using between 1988 and 1991, that's not necessarily what Rare was using in 1990, or what Square was using in 1987, or...
* The Famicom was released in 1983, and development on it began in 1982. There was no Amiga, no Atari ST, no X68000, no VGA, no mainstream computers really capable of general purpose graphics editing. Developers often had to come up with bespoke systems for editing graphics at the time, including bespoke hardware - and it's entirely possible these bespoke systems used a similar non-RGB design as the Famicom, or even the same PPU, or were even just editing programs on a Famicom with some kind of serial-out hacked in.
* Philosophically speaking, the artists were aware that they were producing graphics for the Famicom/NES. That is, they weren't looking at whatever RGB output they had as the definitive version, but just as a rough guideline for how the image would appear on TVs. Given that, whatever RGB the devkit might've been spitting out isn't "definitive" in the sense of how the artist intended anyone to see it.
* I don't really trust Nintendo to make any extra effort to provide an "authentic" experience in their re-releases: witness, for instance, the low quality of the N64 emulation in the Switch Online Expansion Pack they just put out. The actual people who did the art may be gone or uninvolved in the re-releases; just because they own the copyright I don't think whatever Nintendo slaps together really represents the intent of the artists themselves, in the same way that I don't think, say, the release of Go Set a Watchman says anything about the intent of Harper Lee.
> Given that, whatever RGB the devkit might've been spitting out isn't "definitive" in the sense of how the artist intended anyone to see it.
Sure, but that's not what I meant.
Back when images were being bit-banged into computers, you didn't really care what the results looked like on the screen of your workstation, if your workstation wasn't the target system. You designed on paper — usually grid paper — and then iterated from there by flashing an EEPROM and checking the results on the machine.
When I say "the design colors", I mean the marker-pen colors used to color the grid paper. You might also call these the "pre-color-grading" palette.
Certainly, the artist would get a different idea about what they wanted a thing to look like, once the image had been passed through the "color grading" of the NES palette; and so would then iterate toward a design that most-closely lined up the vision in their head with what the NES could actually produce.
But the artist's original intent wasn't to achieve that iteratatively-color-graded final result image; it was to achieve the original colors they had put down on the grid paper. That original intent was just stymied by the system; and so they had to settle for the colors the system could do.
(I realize that modern designers working with retro art styles often design from scratch under palette constraints; but video games were much newer then, and so most of the professional art-and-design people working in the industry had never done digital art before, and had been trained / previously worked only in traditional art. The closest their designers would have got to the kind of constraints imposed by the NES would be in designing neon signs.)
>output they had as the definitive version, but just as a rough guideline for how the image would appear on TVs.
We have seen photos featuring people using nice, pro or broadcast grade CRT displays. Given the lack of an RGB authority, and the limited number of colors, it is likely each group just used whatever references that made sense to them.
And regions. PAL, SECAM, other variants all added noise.
I'll bet a standard consumer grade TV with RF was a small part of many dev processes too. Just a check on effects and or particularly troublesome color combinations. The pro or broadcast grade displays would often render those better than one might expect, but your average TV would likely display a hopefully interesting blur...
RGB images suggest this check on a basic RF TV because some of the pixel art choices may have been different, given better display signals were an option.
For me personally, viewing an NES on a better quality composite display works best for me. Personal preference, and that is due to having composite capable displays early on. I used composite more than anything else. But all that said, the NES RF modulator was respectable. Worked better than many did.
Often, the design choice was a long cable to the TV.
I had a few systems that parked the modulator right next to the signal input on the TV. TI Home computer had a huge one, but it really was great. I used it for many different systems. There was a modulator for PS1 that you could use with a very short connection. And the NES.
> That is, they weren't looking at whatever RGB output they had as the definitive version, but just as a rough guideline for how the image would appear on TVs. Given that, whatever RGB the devkit might've been spitting out isn't "definitive" in the sense of how the artist intended anyone to see it.
I don't think it's necessarily even very likely that they were looking at rgb from a devkit. These days people associate PVMs and other pro monitors with RGB but they aren't synonymous. Take a look through ebay listing for PVMs and you'll find plenty of composite or s-video-ish pro monitors from the 80s kicking around.
And even some microcomputer monitors were composite. If the dev tooling they used was based on a C64 or Apple IIe (which also used 6502 cpus), that'd be composite out for eg., even with a designed-for-c64/appleIIe monitor. And I'm pretty sure I've seen photos of people using Apple IIe or similar for NES dev.
> I don't really trust Nintendo to make any extra effort to provide an "authentic" experience in their re-releases
To add to that, the emulation of old games is handled by the NERD group at Nintendo, based in France (https://en.wikipedia.org/wiki/Nintendo_European_Research_%26...). Nintendo is not a monolithic block, and internal groups will have vastly different opinions on how things should look.
To the last point I just wanted to point out that they've recently patched a lot of the graphical issues on the N64 emulator (including texture coordinate issues and fog in OoT).
While I still feel the original quality was shameful, I recently upgraded my subscription and I have been enjoying it with no issues.
The problem is that Nintendo is not consistent about NES palettes either. Their different emulators all have different palettes, https://emulation.gametechwiki.com/index.php/Famicom_color_p... goes as far as to suggest their latest emulator (the one that is part of Nintendo Switch Online service) has as many as 12 different palettes where the palette picked depends on a game. Nintendo did have NES-based arcade systems that used RGB, however the problem is that their color choices were really ugly.
What made the NES so interesting? It was the games, pure and simple! I've got probably 20 versions of classic arcade Q*Bert. But the iteration with the "purest" design? My goto to actually play when I want to go for a personal high score? Hands down, it's the NES.
I've got a RGB modded NTSC nes too. I bought it so o could use with an ossc (open source scan converter, bit of hardware that does lagless line doubling to output to hdmi 720 or 1080 etc, though I'm sure you know this others might not). The results are way past what I expected and I'm really happy with it.
However the RGB mod I got for my N64 to use with ossc has been really disappointing. I'm sure it would look good on a CRT but on an ossc it's a blurry mess, I've gone back to emulation for the N64 instead.
Yep it's rim Worthingtons mod I've got an the deblur makes no real noticeable difference to me. I'm convinced I'm doing something wrong but don't have the time to mess with ossc settings properly. Emulation has just worked out better for me
sibling comment mentioned that you either need to do deblur as a post-process step or mod the n64 to remove blur to get rid of it. Tbh I don't have an issue with this, because the n64 really truly is a blurry mess it's just not obvious on a crt. But of all my consoles the n64 is one I pretty rarely go back to.
And yeah, I also got a modded nes to use with an ossc but now there are good retro-console upscalers that'll take composite (notably the retrotink5x, which incidentally does have a deblur filter for the n64 iirc) and it just doesn't seem worth it anymore. I'll still mod my consoles (or get them modded by someone better at it than me) if they actually have a better video signal to steal, but I just don't see the point in faking one in the console instead of outside it.
I've been poking at trying to mod famicoms/NESs just for the purposes of getting a cleaner composite signal out of them, but it's tricky and I'm not that good at this stuff.
For instance the color palette was designed with aesthetics in mind: it had 56 colors that you'd want to use, compared to the 216 colors of the web safe palette that must have been chosen by a physicist because 60% of them make me want to puke.
The Atari 400 and 800 had an elaborate system for game-friendly video that couldn't touch what the NES did with tiles. They did amazing things with the TI-99/4A (like simulate framebuffer graphics with tiles so long as you didn't need to cover the whole screen... a trick you couldn't do with the character ROM talked about in this article) but it didn't have the brilliant end-to-end engineering of the NES...
... And of course the ability to extend the hardware with the cartridge took advantage of the falling cost of electronics AND fit with the business model that the cheap console is subsidized by expensive games.
> compared to the 216 colors of the web safe palette that must have been chosen by a physicist because 60% of them make me want to puke.
Most likely a computer programmer. It's just all the combinations of six shades of Red, Green and Blue that are equally spaced out. 00, 33, 66, 99, cc and ff.
The NES colors are actually equally simplistic internally:
12 equally spaced color hues with 4 levels of luma (plus 4 grays, 2 whites and 10 blacks wasting space in the pallet). But it works so much better because it's done in the YUV color space, rather than the RGB color space. Then the analog hardware doesn't manage to replicate it's target YUV colors accurately (or consistently across models, regions and even individual machines/tvs), which adds character.
The NES colors are nice but not sure how "designed" it was - to get colors from an NTSC or PAL signal is phase shifting, so if the colors are in rainbow order (which they are) then each color is simply a phase shift of some amount and the "design" is which amount of phase shift. I was always curious why they left 8 colors black and why black and white was duplicated in the palette, though.
Something like the C64 which used a "resistor bank" to pick the colors actually had thought into the individual choices of each color.
What NES got very right IMHO was:
- More than 16 colors
- Adequate horizontal resolution but not caring about the maximum since the point wasn't to display text (256 pixels, not 160 or 320)
- 2 bits per pixel with just enough palettes to be useful - no 1bpp graphics.
- 64 sprites - so many sprites even if they were 8x8
- Hardware scrolling and multiple nametable support
A lot of the magic in the NES was all the sprites - 64 is a lot for the hardware at the time, the fact they had the same resolution as the nametable, and easy support for scrolling. Also the CPU was kinda fast - 1.79MHz is speedy for a 6502 CPU.
If you're aligned to the axes of the NTSC system you're going to form a grid on intensity, hue and saturation. There's almost no way to make somebody a better colorist than to take away their RGB sliders and give them something more like HSV. You get ideas like complementary and analogous colors "for free". As atrocious as NTSC was it's representation of color was parsimonious of bandwidth as well as compatible with black and white.
I think it's got something to do with the eye being much more sensitive to green but RGB cubes wind up terribly unbalanced and "meaningless" in my way of thinking whereas the Nintendo colors are "meaningful" in that they are aligned with human perception. (Never seen anybody else do it but I run my Hue, Sengled and LIFX lights green on hot summer days to add less heat to the house... I figure the strange color rendition is not so bad because I'm either supplementing outside light from the windows or if is really hot the windows are covered with space blankets and I don't care how strange of a scene it is.)
Subject: "Re: VIC-II colors"
From: Robert 'Bob' Yannes
To: Philip 'Pepto' Timmermann
Date: 27.09.1999
I was involved with the development of the VIC-II, however the actual implementation of the design, including the Color Palette, was done by someone else. I have forwarded your message to him, but it is up to him if he wants to respond.
I can tell you that the design was based on the principle that adding a sine wave of a particular frequency and amplitude to an inverted version of the same sine wave at a different amplitude produces a phase-shifted sine wave of the same frequency. The amount of phase shift is directly proportional to the amplitudes of the two sine waves.
The VIC-II used the 14.31818 MHz master clock input (4 times the NTSC color burst frequency of 3.579545 MHz) to produce quadrature square-wave clocks. These clock signals were then integrated into triangle waves using analog integrators. The triangle waves were then integrated again into sine waves (actually rounded triangle waves, but good enough for this application). This produced a 3.579545 MHz sine wave, inverse sine wave, cosine wave and inverse cosine wave.
An analog summer was used to create the phase-shifts in the Chroma signal by adding together the appropiate two waveforms at the appropiate amplitudes. The Color Palette data went to a look-up table that specified the amplitude of the waves by selecting different resistors in the gain path of the summer. The end result was that we could create any hue we wanted by looking at the NTSC color wheel to determine the phase-shift and then picking the appropiate resistor values to produce that phase-shift.
Color Saturation was controlled by scaling the gain of the summer. When we picked the resistor values to determine the output phase-shift, we also scaled them to produce the desired output amplitude. Luminance was controlled using a simple voltage divider which switched different pull-down resistors into the open-drain output. We could create any Luminance we wanted by choosing the desired resistor value.
I'm afraid that not nearly as much effort went into the color selection as you think. Since we had total control over hue, saturation and luminance, we picked colors that we liked. In order to save space on the chip, though, many of the colors were simply the opposite side of the color wheel from ones that we picked. This allowed us to reuse the existing resistor values, rather than having a completely unique set for each color.
I believe that Commodore actually got a patent on this technique. It was certainly superior to the Apple or Atari approach at the time, as they ended up with whatever colors that came out — ours allowed the designer to freely select Hue, Saturation and Luminance.
Since all of this was based on selecting different resistor values and resistance varied from chip lot to chip lot, there was variation from one Commodore 64 to another. It wasn't as bad as it could have been though, since all of the Chrominance selection was based on resistor ratios, which could be kept constant even if the actual resistor values varied. Luminance was more of a problem. A trimmer resistor should really have been used to pull up the output. This would have allowed the Luminance to be adjusted for consistency from unit to unit, however Commodore didn't care enough about consistency to bother with adjusting each unit.
—
Robert 'Bob' Yannes
I wrote an NES game for my senior project in university. Later, when I researched writing a game for the Atari 2600, I was surprised to learn that you basically had to write your own display subroutine, whereas the NES did that work for you.
The system used in the Atari 400 and Atari 800 is definitely based on the thinking of the Atari 2600 in that you are really thinking about drawing one line at a time but you are getting help to do it
is controlled by a "display list" that sets the strategy used to draw lines on a line-by-line basis. If you have 20 blank lines you can just skip past them and not waste any RAM representing them. If you want to put a line of text at the bottom of a video game it is completely easy.
It's interesting, though, to see the co-evolution of the Atari design strategy in the 7800, Amiga, and Lynx (the former explicitly being a souped-up 2600 and the latter two sharing design team in part). By the time of the Lynx there's a clear bias in the featureset towards "lots of powerful sprites in a fixed memory layout", so the alien nature of the earlier systems is mostly gone and it's become roughly as straightforward as a Neo Geo, plus a few little surprises like the retention of the old Atari "LFSR distortion" sound effects in the form of programmable timers as something you could opt to plug into the audio(which like the Amiga, is 4 channel digital, but the sound driver used in most games biases towards chiptune sounds).
Principally the thing it did right, having lived through the era, is bring a real video game home with Super Mario Bros.
At the time I had a C64 and an Atari 2600, but would spend every quarter I could dig up at the arcade at the bowling alley next door playing pretty much anything, but especially Super Mario Bros.
The Nintendo was the first console to bring the arcade home and it was absolutely revolutionary.
Interesting, it never felt like an arcade game to me. When I'd go to the arcade I avoided Super Mario Bros. It didn't feel like an arcade game like Rampage.
I played it on the NES first (and it was released there before arcades, though I don't think I played until 1989 personally). But I didn't own an NES at the time, so it wasn't that I could play it for free at home.
SMB is a much better game than Rampage. I would also play Excitebike at the arcade, also not nearly as good as SMB.
I guess in an arcade I was looking for simple high score games, I wanted to dream of putting my initials on, but I also wanted to be able to walk away when I died (where in SMB if I got to 8-2 then died I'd wanna go again/continue).
I found Rampage more fun as a concept than SMB, but it doesn’t have the replay value or progression that you really want in a home video game, where SMB does.
I could never get into Excitebike. Controls always felt so awkward.
Rampage is a great game but it’s slow no matter how good you are. With most 2D mario games they nailed the level design such that you can play faster with practice and it’s fun in the same way skiing a familier run faster than last time is fun. The warp zones help replayability too.
There’s a lot in SMB that we take for granted, but I didn’t understand as a kid. The physics system made the action feel real. The the subtle animation of the coins rotating in the air (actually part of the background, interestingly) gave the levels fullness. It was a really impressive achievement compared to the competition at the time (which of course had been destroyed by the video game crash of 1983)
NES wasn’t the first home console to bring the arcade home. It wasn’t even the first console in its generation.
What it was, was the most successful console in America in that era but that was largely due to the crash in the console market over there (something that didn’t affect the rest of the world).
Yep, this is what did it for me. I was playing vs. super mario at the arcade and was amazed it was available at home. yes, it was a bowling alley arcade
Folks who found this article interesting will also appreciate Nathan Altice's book "I AM ERROR" which looks at how the NES's various technical decisions and limitations influenced the NES's lasting cultural legacy. The book contains a surprising amount of technical depth combined with history, business, and sociology. It's really excellent.
“I am Error” is a book from the Platform Studies series, to which the extremely famous and well-regarded “Racing the Beam” also belongs - an awesome analysis of the technical features and restrictions of the Atari 2600/VCS and how they influenced the games that defined the console.
I'm glad I'm not the only one. I was very excited for it after Racing the Beam and I AM ERROR, but the negative tone made me put it down almost immediately.
What made the NES great was what others have already mentioned: by 1985 chip technology was at a point where you could do hardware tiling and RAM was cheap enough that you could do nice color lookup tables. Also the NES came out during a video game crash, so competitors were holding back on making new consoles (their latest consoles were a few years earlier).
Also the ability to do simple stored audio wave patterns and not just sine waves and white noise probably mattered a lot.
Another little detail is the controller layout. Nintendo was the first to figure out that "shitty rubber joystick" wasn't a selling point, and a simple d-pad was infinitely preferable for real games.
...which sold eye-poppingly to a mass audience, while the DS and 3DS sold a ton to a more core gaming audience, and the two have merged in really neat ways with the Switch. (I am very much a "core gamer", I'm playing Triangle Strategy right now, but Ring Fit Adventure also owns.)
Agreed. I always wondered how games got so much better through the NES’s lifetime and didn’t realize the extent of the hardware augmentation in those cartridges.
If you have any interest in NES or video game history, and you haven't read "Super Mario" by Jeff Ryan, get it. I first read it about 10 years ago, but it was one of the most interesting books I'd read and should be evergreen. I also bought the audiobook, which is phenomenal. Read by the great Ray Porter, and DRM free on Downpour: https://www.downpour.com/super-mario
You'd be amazed at how many times Nintendo almost died in the cradle!
I don’t have a book recommendation because they all seem to be flawed in some way, but the history of Sega is fascinating. The following is really rough: Originally an American company, it imported slot machines to American bases around the world. Those were eventually banned on bases and success was found importing automatic photobooths and coin-op games to Japan, and eventually Sega became a Japanese company. I glossed over hundreds of pages of details.
It’s also interesting seeing what influence the American offices of Sega and Nintendo had in the 90s.
To me the NES is the precursor of Apple and Google with closed systems that preys on the discovery of the home computer and creates waste (cartridges) when software can be written to re-writeable media (cassettes, floppies and network).
C64 and Amiga are the precursors of the Raspberry, that while not 100% good; they atleast leave you in charge of your machine to a larger extent:
Another interesting tidbit is that Nintendo wanted Commodore to design the Famicom but Tramiel bailed in the last second when the Commodore guy was allready in Japan on his way to that first meeting.
Last but not least, the C64 had S-video before it even had that name, separating the chroma and luma. Not even the Amigas had that 10 years later.
The Amiga had analog RGB output that was used by everyone because high resolution text (640x200) was unreadable with the composite output. Composite was okay for playing video games (inevitably 320x200), but few actually did that. One RGB monitor that worked (and much better than composite) was good enough.
That was in August 1985, about three years after the C-64. The Atari ST came out a few months earlier, and had excellent monitors, the problem was you really wanted two of them, one for high resolution (640x400), non-interlaced black and white, and the other for RGB low resolution (320x200) color. They were not compatible with each other.
In the PC world you started to see digital RGB EGA with 64 colors about this time, but until VGA monitors came out there wasn't really anything to compare to the Amiga / Atari ST in the color department. VGA was released in 1987, and of course took a few years to become common. An amazing number of PC video games were still CGA (four color low res digital RGB) at the time, but that of course all changed a few years later when VGA became standard.
The analog RGB signals from an Amiga are so standard that you can easily break them out and plug into almost any analog RGB monitor, including any decent VGA monitor with an off the shelf adapter. Composite support is an aberration and no one in their right mind would run an Amiga using composite only for any significant period of time, and it has always been that way. It was a waste of hardware, they should have left it out, almost no one ever used it.
Of course these days HDMI conversion is better, but that is also the case for nearly any video signal you want to display from more than a couple of decades ago.
I use composite on my A1200 because RGB -> anything means trouble with signals and latency. My GV-USB2 capture dongle has zero latency and I only play games.
Floppies and cassettes had slow access times and lacked the ability to use mappers to extend functionality. Pluggable ROM cartridges had a lot of advantages and were used by computer systems of the era too.
Besides, Nintendo did have the Famicom Disk System in Japan, which used rewritable floppies.
Everything can do anything, you need to look at what the majority did.
And not even 0.0000001% of NES/Famicom owners had a keyboard and a disk drive and out of those probably 0% did any coding since Nintendo to this day does not allow you to run what you want on your hardware unless you hack it.
It seems tangential, but interesting, that a system that provided my childhood years with probably thousands of hours of entertainment did so with individual games requiring less memory than the average corporate spreadsheet.
Has anyone attempted to calculate utility per byte? Certainly, the relative evolution of society would play a role (a cave-dweller might have found a few hieroglyphs entirely fascinating), but even with a certain adjustment factor in terms of the general complexity of dominant sources of information, Nintendo games would assuredly excel.
As evidence, folks are still speed-running the original Super Mario Bros from 1985. Lindy effect or efficiency of "utility" per byte?
Possibly, but I doubt that 35-years later, folks would continue to read and re-read that .txt file for its entertainment value. Those few hundred thousand bytes of Mario Bros. code have been reviewed by so many for so long!
I loved how you could tell the complexity of the game by the weight of the cartridge. Some like Super Mario Bros 3 were at the top end, while those 1000 in 1 compilation games seemed to weight very little more than the plastic casing.
If you like this kind of article, Retro Game Mechanics Explained is a channel with a lot of really similar retro game console hardware and software breakdowns. It's a really good channel that goes into a lot of detail and has fantastic visuals: https://www.youtube.com/c/RetroGameMechanicsExplained
Be warned that the Gell-Mann effect applies; you can't tell when a presentation is accurate when you're not an expert.
I'm an expert on the Atari 2600 (wrote a homebrew game.) This channel's video on it isn't quite accurate. He overstates the case of how primitive the machine is, claiming that it takes only 39 bits to display the 2600's screen. That's not really true. The playfield (20), sprite (8x2), missiles (2x1), and ball (1) do total to 39 bits of pixel data... but a lot more than that is involved, many registers modify those pixel bits. There are two X-position latches for all five objects, four color registers, two sprite width/repeat registers, two sprite reflection registers, one register to repeat/mirror/priority the playfield, plus a few more bits in the "vertical-delay" (really each another latch) and timing (horizontal and vertical blank and sync) registers.
Thanks for the information. I actually don't know that much about the Atari, so I extrapolated from his NES, SNES, and GameBoy knowledge, which is very accurate (the Pokemon sprite videos are incredibly in depth, including a stream of him manually deciding a Pokemon sprite by hand over the course of three or so hours). Having done NES programming, I was surprised at the level of detail and accuracy in some of those. I suppose he might just be more experienced in the Nintendo home consoles.
I think he knows the Atari too, but misrepresented it in the video, choosing to push the message of how primitive the Atari is rather than presenting technical accuracy. And, knowing that he did that with the Atari, now I have to ascribe less credibility to anything else he presents that I'm not an expert on.
I always found mappers and additional hardware in cartridges fascinating. NES does not support saves? Just put a battery and additional memory in cartridge to store your data. No animations? Add more pattern tables and cycle through them during the game. An interesting way to keep your console's price low and add some extensibility at the cost of making cartridges more expensive.
If you wanted to publish a game for the NES, you had to go through Hiroshi Yamauchi, the president of Nintendo. He had the final veto power at the moment of publishing a game.
If he didn't like the game, the game would not get published no matter what.
This process ensured that the NES had only quality games.
Yamauchi was 7th dan in Go, and at one point was the richest man in Japan.
Some companies did manage to produce NES compatible cartridges without NES permission, but it wasn't easy. They had to work around or defeat the lock out chip designed to prevent that.
Ironically, "Super 3D Noah's Ark", a bible inspired game, was one of such games, but for the SNES.
The required you to put a licensed catridge on top of the game catridge, and the unlicensed catridge would piggyback on the licensed catridge for loading.
I don't think the NES is that interesting. Who said it is? It was just another machine that came out, had some games, got outdated, and then was replaced by something else just like all the rest.
The SNES was the most "special" of the Nintendo machines in that it hit the sweet spot where the games were sophisticated enough to be really interesting yet still simple enough to be made by small teams and thus not end up as run by committee corporate turds.
I am not sure why this webpage is so hard to screenshot, but my main screenshot service can't do it (i get a 404 after it returns the URL), and in firefox directly telling it to screenshot loses a significant amount of text.
I cannot complain enough, this is a simple web page. there is absolutely no reason i cannot capture a static image of it.
beyond that, i sort of enjoyed a deeper dive, but the subject matter was relatively uninteresting to me. Technology used to have to be bent to the will of the group programming for it, and i'm sure with enough time and the lack of a release schedule from the three big CPU manufacturers, we'd have amazing results with x86 and Arm now, too. But it was a different time, and i do appreciate history.
Sure do wish i could save the site as a .png, though.
I'd love to support this use case, but I don't know how? I mean, this is about as plain-text as a site can get without just being text, if there's some tweak I need to make to the site generator to make it work though I'd be willing to do it.
Sorry for the delay. My "screenshot" bot just runs a headless firefox with --screenshot (or whatever the command is) - so it loads the website as firefox and tries to take a full page screenshot. This is limited by timeouts, so if a site is getting slashdotted/whatever, it may fail. However, i am able to take a partial screenshot after the page is loaded on a regular firefox[0], which shows the exact same missing text as i mentioned a week ago, even this morning.
I'm nearly positive it doesn't have anything to do with your site, even though the page weighs in at at least 19000KB as a .png. I'm weird, i think .png (or even .gif/.jpg) full page renders are functionally equivalent to a "print to pdf" except more useful.
Sorry i sort of derided your efforts. My parents bought me a Sega master system rather than a nintendo, and the past year has me worn out on the "6502-era" systems.
[0]http://projectftm.com/#-b3CluYULJcy0JiPUjjUCg this is my personal pastebin, the screenshot linked here is 10% of my total storage on the pastebin, so this may not be available by the time you see this reply. you can @genewitch me on twitter or gmail if you want to see what i mean, and this link is "dead". Many spring tidings!
doesn't actually work the way it claims to work, see http://projectftm.com/#-b3CluYULJcy0JiPUjjUCg for the 19000KB screenshot firefox took, with missing text after the first 30% or so.
With the European GDPR(?) stuff and general cookie alerts and floating ad boxes, i find that a good 20-30% of all web pages cannot be correctly "captured" as an image. Realistically, since i can literally scroll the actual webpage and see everything, there is no reason that a screenshot wouldn't capture the exact same thing, but it's 2022 and here we are.
Sorry, my pastebin (projectftm.com) is one of the few that allows both arbitrary resolution screenshots as well as pinch/ctrl-scrollwheel zoom to arbitrary sizes. My screenshot bot uploads to a regular nginx webserver, however the screenshot id it generates is a 404. I haven't figured out how to adjust the timeout interval, as i think that's on the bot's home host side, and not the firefox side. the API has a timeout for receiving data from a remote host and if firefox takes longer than that to produce a screenshot it just gives up, even though the script has created a link.
This is something that a lot of even very plugged into retrogaming people don't really get about the NES and RGB mods. I think it's very counterintuitive for people now that there is no part of the system that operates in actual 'color' information. The NES' video output is composite from start to finish[1], with palette entries corresponding to approximate output frequencies for the color subcarrier.
So there is no canonical palette for the NES - the colors produced by games varied by region, a little bit by unit, and especially because NTSC had trouble with stable color even by TV.
So people imagine that RGB or HDMI mods of the NES are somehow tapping into a missing layer of raw color information, but what it's actually doing is intercepting communications with the PPU and modelling (on an fpga) an extra PPU that does operate in RGB, and then constructing a new video signal from that.
And then you have to pick a palette, because there isn't just one.
I have an RGB modded NES (a US toploader) but I doubt I will ever buy or make another one. At this point I think it's better to just use an upscaler, which will produce no less authentic a picture. The main benefit imo of the rgb mod is that there's less interference so the picture is clearer, even if you just output reconstructed composite from it.
[1] There is actually a model of NES PPU that outputs RGB, it was used in the PlayChoice arcade machines (which generally used RGB monitors, not composite) and it has a palette that most people agree is ugly as sin.