We traditionally divide consoles into “generations”—the earliest devices like the Magnavox Odyssey are the first generation, the Atari 2600 is second, the NES third, the SNES and Genesis fourth, the PlayStation fifth, and so on. These divisions turn out to be pretty slippery when you look at them more closely—generations don’t really match product lineage, raw power, or year of release all that closely at all. The closest we come to a real division is that consoles in the same generation competed against one another as peers.

Sega’s third generation may be the most blatant gap there. The SG-1000 came out on the very same day as the Famicom, and it is reckoned as a third-generation console. However, its actual hardware closely matches the ColecoVision, released less than a year before but which is firmly in the second generation. It doesn’t spread terribly far, either. Sega doesn’t make a major play for the international market until 1986, three years after the original SG-1000 release and one year after Nintendo started selling the Famicom internationally as the NES. The NES was a slightly modified Famicom—firmly 1983 tech, albeit very good 1983 tech that had been dominant in Japan for some time by this point. Sega’s offering—the “Master System”—was based on their “Mark III” console from 1985. Those extra two years were pretty busy ones in home computing—1985 in particular sees the release of the Amiga 1000 and the MSX2, both of which offered far more sophisticated graphics than their predecessors. (Indeed, the MSX 1 released the same year as the SG-1000 and had the same graphics chip!) The Master System manages a similar jump as the MSX 1-to-2 advance, or as the Atari 5200 did from the 2600 earlier in the decade.

Also, much like the 5200, the Master System is reckoned as being in the same generation as its own predecessor, though unlike the 5200 the Master System is far more famous and successful than the system it succeeded.

(If you’re looking at the Japanese name of “Mark III” and assuming that the SG-1000 is the Mark I, you may be wondering where the Mark II went. The only real candidate for this is an SG-1000 in different packaging that came out along the way. We’re not missing anything important.)

Head to Head

The Master System was clearly designed to compete directly with the Famicom, but it is also clearly designed to be a broadly-compatible upgrade to the SG-1000. Looking at what the system offers really requires us to compare it both to its predecessor and to its primary competitor. These sorts of comparisons are often a fool’s errand—in this era of home computing particularly, the core capabilities of different machines is so different even in operating principles that the only thing you can do is gesture at how they approached it—but these three systems all have enough in common in their core design that we are on firmer ground. It helps that the Master System’s VDP is explicitly a mostly-compatible upgrade to the SG-1000’s, and that the NES’s PPU is also very clearly inspired by the original principles of that 1979-era chip.

• CPU Memory. The SG-1000 matched the ColecoVision, with a single kilobyte of memory visible to the CPU. The Famicom doubled that to 2KB, and the Master System jumped it up to 8. In 1987, an expansion system for the Famicom was releaesd in Japan called the Famicom Disk System or FDS which loaded games off of floppy disks instead of cartridges, and it offered 32KB of additional RAM to actually load games into. This replaced the memory normally mapped to the cartridge ROM but could be used as working RAM by the games themselves.
• Video Memory. The SG-1000 also matched the ColecoVision here, with a full 16KB of VRAM that enabled full use of all of its graphics modes. The SMS does not meaningfully expand it further; 16KB is enough for its enhanced graphics as well. The only addition on this side is that its palette information is stored in an independent “Color RAM” that only holds 32 bytes. The Famicom only offers 2KB of ordinary video RAM, with 32 bytes of palette RAM elsewhere in the VRAM space, and 256 bytes of “Object Attribute Memory” for sprite data also split out into its own 256-byte bank. 2KB of VRAM is impossibly small; the Famicom’s innovation here is that 8KB of the cartridge ROM is actually mapped directly into the VRAM’s address space as “character ROM” or “CHR-ROM.” Those 8KB are backed by fast RAM in some later cartridges, and the FDS also does this for its disk-based software, ultimately raising the total space available to a hair over 10KB.
• ROM Capacity. The SG-1000 had a hard 32KB limit on the “Sega Cards” that held its games. The Master System expands the ROM space to 48KB and relies on a standardized bankswitching mechanism to allow cartridges to expand up to 512KB. The Famicom relied on more manufacturer-specific bespoke on-cartridge hardware for this capability, with Nintendo requiring standardization to a set of models of their design in the international markets. Famicom bankswitching was generally a bit more sophisticated because its 32KB of CPU ROM space and its 8KB of VROM space needed to be independently controlled. The FDS allowed disks to be swapped so the limit here was more the patience of the end user. By the end of the system’s lifecycle, the largest games for both the NES and Master System were about a megabyte in size.
• Resolution. The SG-1000 and Master System both offer 256×192 displays, while the Famicom expands this to 256×240. In practice, the visible display for all three systems generally ends up more like 248×192 just because analog TVs didn’t render the whole signal visible.
• Color Depth. SG-1000 graphics modes are 1 bit per pixel, though sometimes specified at a high granularity allowing use of all the system’s colors. Famicom graphics are 2 bits per pixel, generally offering three colors plus a transparency. The Master System uses 4, allowing 15 non-transparent colors for any given graphic element.
• Palette. The SG-1000 offers 15 unique colors that may be selected by various graphical elements but which may not be meaningfully remapped or arranged in palettes. The Master System offers 64 colors that are essentially a 6-bit RGB system, much like EGA graphics on the PC. From this a developer may create two 16-color palettes, one usable only by backgrounds and the other usable by backgrounds or sprites. The Famicom also offers 64 colors, but only 62 that are unique and usable, and arranged in a more miscellaneous way. From this gamut the developer again selects 32 colors, arranged into four palettes each for the background and sprites.
• Sprites. The SG-1000’s TMS9918A offers 32 8×8 or 16×16 monochrome sprites, 4 of which may be active on any given scanline. The NES and Master System both offer 64 sprites, up to 8 active per scanline, that may either all be 8×8 or 8×16. Both Sega systems have a status bit that reports if any two sprites have collided, though it does not tell you which ones; the Famicom has a very strange sprite collision detector that works only for the first sprite and only checks for collisions against the background. More on this later.
• Backgrounds and Scrolling. The SG-1000’s TMS9918A graphics chip offers a great many graphics modes, which I have documented in detail before. None of these meaningfully permit scrolling without rewriting the entire name table. The Master System defines a 32×28 graphics display, and any point within it may be designated the upper-left corner. The VDP lets one turn off the leftmost column of graphics, which gives the room necessary to smoothly scroll the screen in any direction. The Famicom offers enough VRAM for two side-by-side background screens, and these are arranged by the cartridge logic to be either aligned horizontally or vertically. Due to the way backgrounds are encoded, it is significantly more difficult to completely hide scroll seams when scrolling diagonally on the NES. Even highly regarded late-era games like Super Mario Bros. 3 and Mega Man 3 have obvious glitches sometimes. All systems that support scrolling effectively support it by having the developer write X and Y scroll values to a pair of control registers.
• VDP Register and VRAM Access. All of these systems access VRAM in similar ways. There is a “control port” to which the developer writes a two-byte address, and then a “data port” to which bytes are then written or read in sequence. The SG-1000 and Master System treat registers almost like a special kind of VRAM; registers are set by writing two command bytes to the VDP control port. Most of the Famicom’s registers, on the other hand, are directly mapped into the CPU’s address space starting at $2000. The big exception is the 16-bit internal VRAM pointer, which is adjusted by writes to $2005 (when editing scrolling values) and $2006 (when doing more ordinary byte-oriented VRAM access).
• Timing Restrictions. Both Sega systems maintain a fairly strict buffer between the developer and the VDP’s internal state. As a result, it is possible on both systems for command or data bytes to be “missed” by the VDP if they are overwritten before it can spare time to actually check its inputs. The Famicom exposes its internals much more directly to the developer, and all writes to any control register take effect, for all practical purposes, immediately. The timing restrictions on the Famicom instead are more macro-scale; the 16-bit internal VRAM pointer is used by the PPU for fetching the data required to draw the backgrounds, so attempting to access VRAM outside of VBLANK is likely to end up reading or writing the wrong locations.
• Split Screens and Raster Effects. The SG-1000 offers no particular support for mid-frame configuration updates to allow for split-screen or other raster-level effects. The Famicom’s bizarre single-sprite collision detection is intended to trap exactly these cases; developers were expected to engineer a sprite-to-background collision at the appropriate split point and then edit control registers as needed at that point. As noted above, mid-screen PPU state is fragile enough that it was challenging to do much besides split-screen scrolling, but that was usually enough. Later cartridges included circuitry that could count scanlines and set interrupts to occur at specific points on the screen. The Master System backed similar hardware directly into its VDP, allowing for multiple regularly-spaced interrupts over the course of a screen. However, as part of its buffering of state away from the developer, vertical scrolling values could not actually be changed mid-frame. To account for this, it includes a special extra hardware mode that simply excludes the top two rows or right eight columns of the display from scrolling, prefiguring the “window layer” we’d later see in the Genesis and the Game Boy.

One of the themes that emerges from this is a difference in design philosophies—and one that I think extends at least out to the SNES and Genesis, too. Sega’s designs are more “down-to-earth”; programming it generally feels to me like “ask for this capability that was designed-in, and get it.” Nintendo’s systems, on the other hand, generally feel like they need to me to combine a number of independent mechanisms to get the result. (Compare the Master System’s hardwired split-screen to the Sprite 0-hit mechanism on the NES, for instance, or the wild profusion of effects on the SNES that boil down to “combine the HDMA subsystem with some other feature“.) As part of this, the Sega designs also retain a lot of the safeguards that Nintendo’s chips scrapped. Before this year I figured that the Genesis VDP let me write VRAM during active display thanks to the 16-bit era finally letting us get proper bus arbiters; that feature actually goes all the way back to 1979 and it was Nintendo’s PPUs that dropped the capability. In dropping it, and removing any barrier between the user-accessible VRAM pointer and the values used to drive the active display, Nintendo ended up accidentally permitting a wider array of raster-scrolling effects than they thought were possible originally. (We know they did not plan the effects used in Rockman 6 originally, because The Legend of Zelda does not exploit them and the display glitches a bit as a result. The Master System goes out of its way to make itself a more solid foundation—but a more solid foundation is also less flexible.

The Nintendo approach ends up looked on more kindly later on, I think—there’s room for the console’s power to grow with the expertise of its developer community—but I will freely admit that in the moment programming systems that use the Sega approach is more pleasant.

Cartridge Structure

Cartridges had standard sizes from 8KB through 1MB, and there were 16 bytes of identifying information at the end of the first 32KB. (Cartridges shorter than 32KB just had it as their last 16 bytes.) This included a simple checksum, though I’ve gotten the impression that some models didn’t enforce it so some commercial software didn’t respect it either. Nevertheless, for my own work I created a simple “SMSFIX” utility that would expand simple assembled binaries to an appropriate size and document that appropriately.

Simple cartridges smaller than 32KB just loaded their entire contents into the first 32KB of RAM, mirroring themselves if necessary. Larger ones made use of a standard memory mapper and this only locked in the lowest 1KB of RAM. Somewhere in that code the developer was obliged to configure the memory-mapping registers, and Sega’s recommended approach for this was to lock down the lowest 32KB and then swap out the $8000-$BFFF region with 16KB blocks.

Writing a BIOS

The RAM, I/O port, and VDP design of the Master System were designed to be largely backwards-compatible with the SG-1000. This means that I should be able to reuse the earlier work I did creating a BIOS-like support library for the SG-1000 and adapt it pretty readily to the Master System as well.

As it turned out, attempting this worked so well that it made more sense to just block out the changes under some conditional-assembly defines like ifdef SMS or ifdef SG1000 and only make the necessary alterations in those places:

• The SMS has four additional I/O ports that we should define.
• The stack pointer starts in a different place since we have more RAM.
• Likewise, we have more memory to clear when we clear RAM during startup.
• Color RAM must be cleared on its own on the Master System since it’s not just part of VRAM the way the SG-1000’s color tables were.
• While the SG-1000’s VDP was highly configurable, and the SMS’s VDP has just as many knobs attached, there was an acknowledged canonical memory layout for the SMS that made good use of the entire 16KB of VRAM. We should initialize the VDP to that known-good configuration on startup.
• There are two possible IRQ sources on the Master System; our built-in handler should be able to identify mid-frame interrupts, and both skip the frame-only operations on those and also forward them to an alternate handler.
• We also should initialize the mapper circuitry, if any.
• One thing I expected to need but didn’t turn out to need was a special call for writing values to color RAM. It turns out that the way I’d implemented the various VRAM-writing functions effectively mapped the 16KB of VRAM proper to $0000-$3FFF and then the 32 bytes of CRAM to $8000-$801F. I’ll take it.

The official documentation for the Master System suggested an additional complication: when it described the VDP timing requirements it suggested that the Master System’s VDP needed to be written more slowly than the SG-1000’s. It purported to require a 16-cycle gap between writes during VBLANK and a 29-cycle gap during active display. My own calculations agreed with the 29-cycle number but only expected an 8-cycle gap needed during VBLANK. Enthusiasts at the SMS Power Forum actually did the timing experiments and discovered that the VBLANK number is closer to 3 cycles (impossible to violate on a Z80) and that the active-display value was more like 26 cycles. I’m going to stick with my SG-1000-level timing here, but we may be pretty confident that this will work out fine.

Project Plans

The first thing I did was port over my sample Hello World program to make sure that my SMSFIX program and my adapted BIOS actually worked.

Moving forward, after learning about how much the Master System actually offered, I realized that I could actually recreate one of my first Sega Genesis projects over to the Master System with effectively no compromises. After that I think I’m going to want to create some more ambitious display, pushing right up to the level where we’d start really wanting the power of the Genesis to enhance it further.

After the rest of the systems I’ve poked at this year, the Master System really feels both very familiar, yet shockingly powerful given the expectations I brought in. This should be a fun time.