The Flipside of Gaming
A good old-fashioned website! It’s hope to information on the construction of a wide variety of console platforms! Docs on the NES, the Sega Master System, the PC Engine (a.k.a. Turbografx 16), the Mega Drive (a.k.a. Genesis), Gameboy, SNES, Saturn, Playstation, Virtual Boy (yes), Nintendo 64, Dreamcast, Playstation 2, GBA, Gamecube, Xbox, DS, PSP, Xbox 360, Playstation 3, Wii and Wii U.
The Copetti site: Architecture of Consoles
In my teens I got started coding on my old Commodore 64s. Learning to program was a much different process back then, there was no internet to answer basically any question you’d have almost on a whim, everything I picked up came from some written matter, mostly programmer’s guides (including the definitive guide to using the hardware, the Programmer’s Reference Guide) or periodicals like Compute’s Gazette, Ahoy! and Commodore Magazine.
The C64 had a lot of graphics features, made possible by the machine’s powerful VIC-II chip. All of the home computers of the time had tricks one could use to get extra mileage out of their bespoke graphics hardware. The Atari 8-bit computers had display lists, for instance. The VIC-II had a powerful raster interrupt facility, the ability to share memory with the processor (at the cost of delaying the whole machine while it did so), eight surprisingly large hardware sprites (in double-width mode they could fill a whole scanline, something the NES’ sprites could only dream of doing), and a collection of interesting and flexible graphics modes.
Most of the time the C64 was in character mode, which was the standard kind of tile-based mode that pretty much all home computers at the time used by default, suitable for displaying messages, coding and some graphics. The ’64 three such modes: the standard mode where each character had a single color along with the screen-wide background color; a multicolor mode that gave a character its own color, up to two colors shared throughout the screen and that background color, and (mumble mumble). Sorry, what’d I say? I’ll get to that later.
The system also had two bitmapped modes that worked similarly, just directly viewing a region of memory instead of using each byte as an index into a character set. One mode was like the standard character mode, where the 1s in the bitmap were colored and the 0s were the background color; the other was multicolor mode, which similarly worked like it did in multicolor character mode: one color per 8×8 region, two colors shared throughout the screen, and the background color.
The problem with multicolor mode was, you had to trade horizontal resolution to use it. The big limiting factor to many computers’ graphics then was memory use: finding a way to encode the graphics information so the chip could access it and convert it into a video signal quickly enough to meet the needs of the display. So, to fit an 8-pixel-wide section of screen into the single byte it needed to be squeezed into, it could either use a one-to-one dot to screen ratio, or sacrifice two bits for one extra-wide pixel of up to four possible colors.
UNLESS
The Commodore 64 had a fifth graphics mode. The one I mumbled over earlier. The much-ignored Extended Background Color mode.
It was another character based mode that, instead of forcing you to make use of one background color over the whole screen, gave you up to four such colors. Every cell on the screen could display a character using its full 8×8 resolution, but could also pick which of those background colors it could have. Useful!
Well… not as useful as you’d think. There’s always a tradeoff, and Extended Background Color’s tradeoff was a dire one. How does the VIC-II chip know which background color to use for each character cell? It uses the two high-order bits of each character byte. Meaning, while you could decide which of two colors would be used in each cell with a lot greater nuance, you only had 64 characters to work with! A full screen of 1,000 characters is a lot to fill with just 64 possible tiles. A lot of repetition would be unavoidable, which is probably why it was so little-used.
It essentially was either this:
or this
These images are a little misleading, because I used the Commodore 64’s default ROM character set to make them, and the second half of its characters are just mirror images of the first half. But if you define your own characters, which basically any game worth its salt will do, it greatly reduces the number of tiles at your disposal. There may be some sneaky ways around it, sure, but they all involve their own tradeoffs.
I explain all this because Extended Background Color Mode is my best guess as to how Trap Door and Popeye do their graphics.
Here’s video of a playthrough of Popeye. It’s about 21 minutes, but it shouldn’t take long to get what I mean. It’s not Nintendo’s Popeye, it’s a completely different game.
And here’s a playthrough of Trap Door, with graphics by the same person:
Look at those huge characters! How could this be possible, and with that color depth? The C64 can have huge sprites, but only at the cost of making all their dots twice as tall and/or wide. And the pixels aren’t even multicolor mode wide. I can’t quite make sense out of it! Unless, maybe the games are displaying their large characters using the character set, which explains why they jerk along the screen? And the colors are using Extended Background Mode? That might explain the simplicity of the backgrounds, with only 64 characters to work with that means a lot of reused tiles.
I guess the point of this post is: what gives?
Displaced Gamers‘ Behind the Code series doesn’t get new videos often, but they’re always great. This one is more technical than usual, but I don’t think it’s really all that technical. It’s about how the NES processes and renders its sprites, particularly explains why there’s a eight sprite per scanline limit, and even reveals a couple of games that use that limit to produce special effects!
The gist: while each scanline is being prepared for display, the NES’ PPU looks through the entries for the machine’s 64 hardware sprites in order, finds the first eight that will display on the current line, and copies their attribute data to a small area of internal RAM. There is only space there for eight sprites, so, the NES cannot display more than eight sprites in a single scan line. Any later sprites in the primary attribute data won’t have room to be copied, and so the PPU won’t be able to display them.
One thing it notably doesn’t cover, however, is how games implement priority shuffling to cause sprites to flicker instead of not display at all. The video suggests that that might be coming in a future video….
NES Sprites, OAM, and the Battle for Priority – Behind the Code (Youtube, 19 minutes)
The narrator has a moderate case of Youtuberitis (symptoms evident: over-gesturing with hands, annoying shtick; absent: ending sentences in an undertone like they were John Cleese playing a TV presenter), but it’s still an interesting and even informative video about making software, and hardware, doing things they really weren’t designed to do.
One piece of the puzzle for getting this insane project working was Linux on Wii; another piece was the fact that the Wii and late versions of Mac OS Classic both use PowerPC processors. It doesn’t work perfectly, but as they say, it’s amazing that the Nintendog talks at all.
The SuperGrafx is a failed system that had only five games, only three of which seem to be worth playing. The Sharp X68000 series of high-end personal computers, which were only released in Japan, on the other hand, is probably the popular gaming system Westerners have heard the least about.
As I said yesterday, the X68000 cost three grand, and that was just for the base system. If you thought the NeoGeo was expensive, hah. It’s price was justified in that it was a computer, indeed a workstation, and had a variety of software other than games. But it did still have a lot of games, including some of the best arcade conversions, including excellent ports of Rygar, After Burner, Strider, Final Fight, Street Fighter II and Detana! Twinbee, and a well-remembered recreation of the original Castlevania up to then-current aural and visual ideals. The X68000 even got conversions of Atari arcade games like Marble Madness, and even KLAX, that would I would have loved to have played back then.
The X68000 also worked a lot like a MS-DOS machine from the time. It ran mostly HUMAN68K as its OS, a DOS clone made by HudsonSoft, although it also had windowing OSes. Despite how it seemed in use though, it used Motorola 680X0-family processors, like original iteration of the Macintosh. But while it has a DOS-style OS, it’s a home computer with a dedicated sprite chip!
At times it feels like this blog is a recap of my gaming-related Youtube explorations, but I have no qualms about it when they’re as excellent as the two I have this time. One is a review of the “pro” version system from four years ago, from someone who went and obtained one:
Three years later, RMC returned with a more thorough exploration of a different machine of the line:
And this one is about emulating it, which is probably the closest most of us will ever come to trying out any of its software:
What is the SuperGrafx? Why don’t we remember it as well as its predecessor, the PC Engine/TurboGrafx 16, with which it was backwards compatible?
Sharopolis on Youtube digs into the system and its capabilities (17 minutes):
As you can tell by the video’s cover image: Amazing Power, No games. The SuperGrafx only had five games released for it throughout its lifetime, pretty harsh for a system that cost around $300 by today’s money. That cost, relative to that of the PC Engine CD, which was also expensive but could play CD games with vastly greater storage, was probably what doomed it. For those really seeking an arcade experience in Japan there was the Sharp x68000, famous at the time as the true enthusiast’s system with a good number of nearly exact arcade ports. It also cost around $6,000 in today’s money, and still $3,000 in then-money.
The system used the same chip as the PC Engine before it, a 6502 variant running at 7 mHz, meaning it was only a 8-bit system. But was that really so bad? The major 16-bit competition for it was the Motorola 68000, another venerable chip at the time that was used in the original Apple Mac, the Sega Mega Drive/Genesis, the Commodore Amiga and the Atari ST. Yet the 68000 also had some more overhead. Many instructions on the 6502 completed in from two to four cycles, whereas the minimum cycle count of a 68000 instruction was four, with some taking up to 20. This, of course, is offset by the 68000’s greater number of registers and ability to work with two bytes at once for many instructions.
Its graphics were essentially two of the PC Engine’s graphics chip, with some circuitry to interface their outputs together. This description brings uncomfortable reminders of people deriding the Wii’s graphics as “two Gamecubes taped together,” but it’s a much closer description of the SuperGrafx’s graphics. But in practice this meant twice the sprites, dual-plane backgrounds, and double the potential colors on-screen at once, while the MegaDrive/Genesis infamously was still stuck with 64.
The SuperGrafx’s failure in the market was one of those inflection points of the growth of video gaming. If it had succeeded then NEC might still be a player in gaming today, and maybe Hudson Soft would still be an independent entity, instead of just another property for Konami to mine for nostalgiabucks.
This one’s crazy. The Gameboy does not have external video output. In order to get its display to appear on a screen other than its built in LCD dox matrix, you absolutely have to at least crack open the case. Don’t you?
Well, actually, yes, if you always want a perfect image. Sebastian Staacks (an awesome name) figured out a way to do it that mostly works. It’s a cartridge that goes into the Gameboy, that itself has a slot into which you plug the cartridge that you wish to play. Simple, right?
No, no, wait. There’s a problem. The Gameboy doesn’t expose its video through the cartridge port. There is no pin leading out providing a video signal that can be converted for display. There’s no way this could work!
Well, there is a way, kind of. The device contains a Raspberry Pi that runs its own Gameboy emulator, that it tries to keep synced with the version running on physical hardware. It does this by watching bus activity exposed to it through the cartridge port!
But while there’s a lot that it can do with this information, there’s also a lot it can’t see. It can’t, for example, see directly what buttons are being pressed. However, by watching how the cartridge reads the cart ROM, it can deduce what inputs were pressed.
The process is not perfect. While it can spy some memory accesses, a few things escape its inspection. While it can recreate the layout of the starting blocks in Tetris Game B, it can’t catch their randomized appearances. Also, while a Raspberry Pi is much faster than a Gameboy, it’s not fast enough to carry out its display in the same frame as the main unit, so it lags behind a couple of frames. Still though, it’s a very clever idea, and it’s amazing that it works as well as it does!
Sebastian made a Youtube video explaining and showing off his work, here. (It’s the same one embedded above.)
There Oughta Be A Game Boy Capture Cartridge
Rodrigo Copetti has an interesting rundown of the architecture to the Super Nintendo Entertainment System! It’s an interesting system over all. In clock speed it’s really not that much faster than an NES, but it has vastly superior graphic and sound capabilities, plus so much more addressing space that the phenomenon of mappers that ruled nearly every NES game worth talking about (except maybe Super Mario Bros. and Tetris) was completely absent. The SNES did have frequently-used add-on chips, but they tended more to take the form of co-processors to take some of the load off of the machine’s relatively slow CPU.
Super Nintendo Architecture: A Practical Analysis by Rodrigo Copetti
It’s a video from YouTube Channel The Retro Future with the title “Nintendo didn’t want us to know this…” which I hate. Why not just mention it’s about the difference between the Kiosk Units and retail ones? I’ve seen a hundred clickbait titles like this that have completely disappointed me.
This time though, it actually was interesting content, even if I can’t see why Nintendo would care if we knew it.
The kiosk units that were displayed in stores to demonstrate software differed from the ones you could buy in one important respect: they have a resistor in a different place on the motherboard. Without this resistor, the kiosk units will only turn on if they’re connected to power. They still have a battery, but it doesn’t appear to be used! If the resistor is removed and soldered into the location it’s at on a production unit, it seems, it’ll function normally.
Here is the video:
tom7, aka suckerpinch on YouTube, is a freaking genius. I don’t believe in geniuses, but he is a strong counter-argument, I will admit.
His modus operandi is to take some absurd premise and carry it to its logical conclusion, usually using some form of technology along the way. He then makes a video about it. Sometimes the video is in connection with a paper he’s written for SIGBOVIK, which is an entire oil tanker full of worms that I really don’t want to get into here, suffice to say it’s hosted on the site of the Association for Computational Heresy.
The PDF of their 300-page record of proceedings calls itself, “The fifteenth annual intercalary robot dance party in celebration of workshop on symposium about 26th birthdays; in particular, that of harry q. bovik,” about which all I can say, honestly, is, woof. I encourage you to go to that side and read, or at least try to read, some of their papers. You will come to feel like a complete imbecile, but you’ll probably be entertained.
AnYwAy. This post isn’t about SIGBOVIK but about tom7. The post above is about his questionable quest to construct mass storage devices out of unlikely things, like masses of Nintendo Tetris emulators, or a mass of used COVID tests. In the past he’s done fascinatingly-insane videos on bad chess algorithms, generalizing the concepts of uppercase and lowercase, created a number of weird bikes, or (to stick with the blog’s theme) teaching a computer to play Super Mario Bros. in a fairly silly way, which at least will teach you what lexicographical ordering means.
Found via a Metafilter post from user zengargoyle.
I’ve been rather taken by NCommander’s YouTube channel lately, in which he regularly tries to build and run old versions of Unix and software for it. He’s run an old boxed version of Debian 2.1, Internet Explorer 5 for Unix, the first Linux live CD (Yggdrasil), and–get this–even a version of System V made for the Commodore Amiga that was officially published by Commodore! It comes out of the box with NetHack 3.0! (Warning: that one’s a seven hour live stream.)
A highlight of the channel that falls under our jurisdiction is him trying to get DOOM running on an old IBM machine running old IBM Unix. Over an hour long, the video is a long sequence of sadness, involving misconfiguring hostnames, getting X running, discovering that IBM’s C compiler costs about $2,500, running into basic C functions IBM didn’t implement, building OSS for AIX (and buying a $10 license for that), and then the issues with building and running the game itself. So yes, add it to the long list of devices that run DOOM, but at what cost?
Well, to NCommander, $10 plus several days of time. To you, about an hour of entertaining (somewhat) learning about obscure computing esoterica!
NCommander at YouTube: What Does It Take To Runu DOOM On A $10,000 IBM RS/6000 From 2001?
via @doc on Twitter. PikumaLondon tweeted out a thread (unrolled) explaining, in general, how the original PlayStation rendered graphics, and the source of its distinctive graphic artifacts, specifically texture warping, pixelated textures, and jittery polygons. The Nintendo 64 didn’t have these problems, but also couldn’t draw as many polygons each frame.
The thread also links to developer David Colson’s efforts to create a PS1-style 3D fantasy console. I’m sure this isn’t interesting to everyone, but worry not, this blog isn’t going to become entirely low-level hardware rendering geekery. At least, not yet.