NES devs discuss the process of creating classic retro games that defined a generation

The Nintendo Entertainment System, and its Japanese counterpart the Famicom, need no introduction – if you're reading this magazine, you'll know that the 8-bit hardware catapulted Nintendo to a position of global leadership in the videogame business, and hosted the first iterations of countless classic series. 

Though marketing played an important role in this commercial and cultural success, it wouldn't have been possible without the hardware. After all, the ColecoVision and the Atari 5200 were less than a year old when the Famicom launched in Japan in 1983, and the 3DO and Atari Jaguar were on the market by the time developers finally abandoned the NES in 1994. A machine simply can’t stay relevant for that long without hardware that's flexible enough and capable enough to keep up with the changing tastes of gamers.

New ground

But the NES wasn't just a titan of its time – plenty of developers are creating new games for the hardware, pushing it harder than ever with modern development tools. Two CPUs and their derivatives dominated the home hardware scene of the Eighties – the Zilog Z80, as seen in the ZX Spectrum, ColecoVision and Master System, and the MOS Technology 6502, which featured in the Atari 5200, Apple II and Commodore 64. Nintendo's engineer Masayuki Uemura opted for the 6502 for the NES, primarily because it was small enough that a chip could also include sound capabilities.

In 2016, the late engineer told Retro Gamer that this choice caused "a huge problem within the company" as Nintendo’s hit arcade game Donkey Kong had used a Z80 and the source code couldn't be reused. Consideration for any programmers outside of Nintendo wasn't a priority, as the company didn't initially intend for third-party publishers to be part of its business model. Of course, the success of the hardware in Japan and North America eventually necessitated third-party development just to keep up with demand for new games. 

The system didn’t have the same impact in the UK, which is why programmer Paul Machacek didn't encounter one until 1988, when he joined Rare – one of the few UK developers to concentrate on Nintendo's system. His previously published games had been written for Z80-based computers, and he was initially tasked with writing for the Z80-based RAZZ arcade board, but he was soon asked to work on a NES project. Fortunately, Paul was familiar with 6502 assembly code from his time as an Oric-1 owner. "I picked it up pretty quickly again," he says, “but forgot about all the number juggling you did on it compared to the Z80 as 6502 has so few registers, but alternatively had the fast zero-page storage." 

The development environment that Paul worked with was rather basic. "Originally at Rare everyone used PDS (Programmers Development System) which was a text editor and code assembler. We had home-built interface cards that plugged into the cartridge slot on the NES, and they were attached by a ribbon cable to our PCs that ran PDS," he explains. "We had no network. The PCs were Amstrads with 20MB (not a typo) hard disks. Every time you assembled your code – it was all done in one go, we didn't have linkers yet – the full binary would copy over the ribbon cable to the interface card and you'd run your code on the target machine. As for documentation we just had the standard NES manual, which had a few typos in that needed to be corrected otherwise things wouldn't work, and also your handy 6502 instruction set guide for occasional reference, especially if you wanted to write self-modifying code."

If you’re a programmer wincing at that, it gets worse. "There were no debug tools as you’d know them today," Paul continues. "There were tricks for finding out where your code got to before things went wrong, like writing values into a memory location and seeing which one was written last before it crashed, then using a bisector search to narrow down to the offending code. For performance testing you normally had some visual change on the screen (offset a screen horizontal scroll register, or alter a colour palette) at the start of a function, and then reset it at the end so that you could 'measure' how long it took on-screen by drawing marks with marker pens around this visible indicator, and seeing if the marks got closer together as you continued to optimise your code. Yes folks, these were the days you measured code performance in inches!" 

That sounds like a fairly awkward way to work, but Paul just sees it as a product of the circumstances at the time. "We did what we had to do back in the day. Folks, go back 35 years, develop what we did with the tools that we had on the systems that we used and tell me you wouldn’t end up doing something similar!" Fortunately, this situation would eventually improve for Paul and his colleagues. "After a few years Rare contracted Jon Ritman, a close associate, to write a new system called GLAM [Global Language Assembler Monitor] to replace PDS. GLAM could target a wider variety of processors and had a linker as well as assembler so you didn’t have to assemble your entire codebase every single time you changed anything, which speeded up development. GLAM worked really well."

Ultimately, 6502 programming wasn't a big problem for Paul in transitioning to a new platform. "For me the larger adjustment was going from home computers with bit-mapped screens, to the character-mapped system of the NES, with separate colour palette designations, character banks (and swapping) and memory bank-swapping on the carts," he remembers. Nintendo’s Picture Processing Unit – PPU for short – was a custom design by Ricoh, and according to Nicolas Bétoux of Morphcat Games, "Compared to other hardware of that time, the graphics and scrolling capabilities were great." 

Indeed, when the Famicom launched in 1983, its closest competitor in Japan was Sega’s SG-1000. The Famicom’s graphical capabilities were clearly superior – it had a palette of over 50 colours compared to just 16 on Sega's system, sprites could have three colours each as opposed to just one, and screens could be scrolled on a per-pixel rather than per-character basis, resulting in a considerably smoother look. Nintendo’s hardware could also display more sprites overall, and more sprites per scanline. Sega introduced the graphically superior Mark III hardware in 1985, meaning that competition took place on a more even footing by the time the NES and Master System made it to international audiences. 

Tools of the trade

While Nintendo’s 8-bit hardware had advanced graphical capabilities, the methods used to create those graphics were anything but advanced. Like Paul, artist Kevin Bayliss had never encountered a NES before creating games for the system. "On my first day at Rare, Tim [Stamper] showed me the basic 'pixelation process' and taught me how to create work that could actually be put into a game," he tells us. 

"I had to basically draw my artwork and place it beneath a grid sheet on a large drawing board filled with fluorescent strips. I'd then trace over my drawing by using the grid to define pixels with a pencil, and then I'd use felt pens to fill out the pixels. Then the work had to be organised and split into boxes (8x8 sprites) and the sprite data and position data all had to be worked out in hexadecimal, in my head. This was pretty easy but a bit laborious at times, and you often didn’t want to do this job because it wasn’t at all creative. You just wanted to see your work in the game.” 

If you're baffled by the lack of a computer in that process, you're not misunderstanding anything. "There were no tools other than the pen, pencil, paper and a surgical scalpel for scribbling out your mistakes on the tracing paper when you put a pixel in the wrong place, or wanted to chop pixels off a character to allow it to squeeze into less data," Kevin clarifies. "There was a simple sprite editor that Mark Betteridge wrote but this wasn't really used because it was very limited and didn’t allow you to view your animation (as they do in all of the old Disney 'behind-the-scenes' footage – by flipping your paper back and forth to create the illusion of animation)." 

Since NES development tools weren’t standardised, a variety of different art tools were used by different companies. Nintendo did use hand-drawn sprites at one point, but eventually created a mouse-driven pixel-art tool, while Namco had a sprite-editing tool that did have the animation preview facility that Kevin describes. However, he enjoyed the low-tech approach employed at Rare. 

"It was actually quite nice to have a limited palette. I mean, there's no way you could have drawn all of your graphics on paper for any 16-bit console because you'd never have enough pens, and it would have taken all day to decode – and you would have made so many mistakes – it would have been impossible," he says. "But due to the simplicity of the colour palette and the low resolution and small number of sprites that we mostly dealt with, making graphics on paper was actually quite fun and felt a lot more 'organic' than creating them digitally on the SNES, so I guess there's something to be said for that." 

No matter how a developer created art for the NES, technical limitations played their part in the final results. "Sprites per line (more than 64 filled pixels in a horizontal scanline) were a problem so you'd try not to make characters very wide," Kevin explains. "For instance, in particular I remember all of the characters for the WWF games I did had to either 'fall back' or 'lie on the ground' and of course that meant that they'd be quite wide in that pose. So you'd often try to angle them or be clever with the pose, but you'd never really avoid it. You can see how the characters often flash on and off particularly in beat-'em-up games like that, and it was a problem all companies had to deal with as best they could." 

That characteristic flickering is actually a clever programming workaround – the NES would simply skip pixels if too many sprites were displayed, so rapidly cycling sprites on and off at least ensured they’d all be displayed in some form.

In fact, NES developers often had to get creative to realise their visions – such as the huge boss characters Kevin drew for Cobra Triangle. "With Cobra Triangle we were lucky because the game took place in an isometric environment, so all the graphics were viewed from an angle which reduced the amount of width that you’d normally see in a horizontally scrolling game," he says. 

"The boss characters were all a collection of large sprites and we could use the surface of the water to make things appear submerged by adding a few 'ripple' sprites around them at the base. So for instance the sea monster (Nessie) character I created was quite tall, and the humps behind her moved around independently, and because of the angle, there wasn't very much in the way of sprite flickering."

The limitations became more difficult to deal with when developing licensed games, as Rare often did. "For WWF wrestling games we had to make sure there was a good likeness with the characters. So it was hard to 'digitise' the photographs by hand and reproduce the characteristics of everyone accurately when you had only got about 16x16 pixels for a character headshot on the select page," says Kevin. "I remember getting these awful quality faxes with pictures of the wrestlers on and I was supposed to try and recreate them using such low resolution and three colours."

This did lead to some funny experiences, though. "A lot of the time I'd get faxes back from America saying that, 'The graphics were in need of some attention,' because the likeness wasn't quite close enough," Kevin continues. "Then I'd change, like, one pixel and then I'd get a fax back the next day saying that the image was much better. It really made me laugh when that happened. Also, when I worked on the Beetlejuice game, I had the opposite problem, and my title page artwork looked too much like Michael Keaton apparently, and so I had to do it again to make it look more like Beetlejuice – kind of difficult when they’re the same person."

Shades between

Sometimes, it was possible to push the system beyond its theoretical limits. "If you look at Super Off Road, you'll notice there are more colours on-screen at times than the hardware can handle as standard," says Paul. "There were four palettes of four colours each, but the first colour in each palette was the same background colour for all. So the total number of colours you could display for background characters was 13. There are more displayed on Super Off Road because I changed the palettes with carefully timed access to VRAM during horizontal blanking. This worked fine," Paul explains, before correcting himself. "Well, it did on the US version of the NES.

When the game was finished, I was informed it would be released in Japan on the Famicom, which was slightly different in terms of hardware and unfortunately my colour switching wouldn't work on that, so I believe it was not released there." Audio was handled by the same Ricoh 2A03 chip that contained the CPU. "On the NES, you've got four audio channels to work with. We don't count the DPCM (sample) channel, we don't use it as it has some drawbacks," says Nicolas, a developer of modern NES games.

"Either way, that’s two square wave generators, one triangle wave which is often used for bass lines and one noise channel used for percussive sounds. So you see, there are limited options for polyphony and timbre, which makes it difficult to create a more atmospheric soundtrack the likes of which you’d hear in modern games. Likely, that is one reason why a lot of game soundtracks back in the day made up for it with dynamic compositions and catchy melodies."

NES audio has some particularly distinctive characteristics, not least the triangle waves which are stair-stepped rather than being smooth, due to the system's 4-bit sound processing. "Due to the limited amount of channels, you also have to be aware that sound effects can interrupt the music," adds Nicolas. "Ideally, you'll have sound effects play only on the channels you use for accompaniment, so they won’t silence the melody."

Sound is also one of the differentiating points between the Famicom and the NES, as the Famicom supports expanded audio through the cartridge port – something that the Famicom Disk System and certain special cartridge chips take advantage of. Since the NES doesn't have this capability, Japanese versions of games such as The Legend Of Zelda and Castlevania III: Dracula's Curse have noticeably better music than their international counterparts. Indeed, it was the special chips that were one of the key factors in the longevity of the NES. As well as supporting both ROM and RAM on cartridge PCBs, the NES was able to utilise chips that Nintendo called Memory Management Controllers. 

As well as allowing for bank-switching that broke past the storage limitations of the original cartridge specification, these chips could provide extra features to assist in game development, and for the Famicom even expansion audio. That's ultimately how the system was able to go from hosting games like Donkey Kong to much more complex titles like Kirby's Adventure over the course of a decade. Of course, even with ROM capacity greatly exceeding the original 40KB total, developers often fought for every byte. "A common issue in those days was trying to cram your games onto the tiny cartridges we were given," says Paul. "This was complicated on NES/Game Boy (both 8-bit systems with 64KB memory maps) by having to have bankswitching where the region might be divided up into four 16KB blocks, and you could switch different ROM banks in and out of them. 

So you had to carefully arrange what code and data was where and how you would jump from one ROM bank to another in the same address space, using standard overlay jump tables at the start of the space. We also had to develop data compression routines, often different ones for different types of data – character data, map data, text data, music data. Huffman compression was used quite a bit, but I did spend time staring at printouts of other types of data, looking for patterns that I could use to develop compress software for."

8-bitten

James is similarly full of praise for the software, saying, "The community is great and the resources for using the tracker applications are accessible to anyone, whether you're an experienced composer or just a fan of chiptunes." With these modern tools at their disposal, NES developers today tend to try very ambitious projects. Four-player action games are a rarity on the NES, but Morphcat Games created an excellent one in Micro Mages. This required some very economical use of the hardware. 

"The NES allows for a maximum of 64 hardware sprites to be on the screen at any time," Nicolas begins. "These sprites are 8x8 pixels in size (there’s an 8x16 mode, but it has its drawbacks) and can be pieced together to form bigger sprites. "So, to get a 16x16 sprite in the first mode, you'll have to use four hardware sprites. If you have all four players use 16x16 sprites, that's one quarter of all the available hardware sprites used on players! Also, there's a hardware limitation where if more than eight sprites are on the same horizontal line, they start to disappear," he continues. "To remedy this and still allow for many other objects and graphical effects on the screen, the player characters in Micro Mages use a single 8x8 sprite each." 

The 8-bit CPU also proves to be a limiting factor, according to Nicolas. "If a game has an enemy which only moves sideways and turns around when it encounters a wall, that's a limited number of checks that need to be performed. Human players, on the other hand, are wild cards, they will interact with everything around them in ways a developer cannot fully predict. 

Also, if players have the ability to shoot, the number of objects on the screen adds up fast," he tells us. "This isn't that much of an issue in a single-player game and you usually get away with things in a two-player game. A four-player game, however? Ouch. In Micro Mages, we spent a lot of time on optimisation to avoid lag. However, in four-player mode, there are occasions where the game still slows down when there is too much going on." 

One advantage that modern developers do have is the ability to pick and choose from a wide range of memory management solutions – more commonly known as mappers these days. "They are just so interesting to unpack, and develop for," says James. Despite having the most powerful ones available, they are not always the default choice. "When a game is planned for development at Mega Cat, we start working backwards from what's required for the core gameplay to be fun," James explains. "In some cases, we end up defaulting to something powerful like the MMC3 mapper. In others, we can keep it simple and use a discrete mapper, like an NROM." Indeed, the recent NES game Blazing Rangers from Japanese developer Karu_gamo specifically used the simplest mapper, the NROM, to evoke nostalgia for the early days of the Famicom. That's really the core of the ongoing fascination with the NES from developers – not only is it a technically interesting system, but one that offers a strong nostalgic pull. 

Even those who first encountered it in a work context, like Kevin, feel that nostalgia. "I enjoyed working on the NES as an artist, because you really knew the system eventually. Whether you were creating backgrounds, animated sprites, title pages or front-end (scoreboard) graphics – you had a system in place that you'd used on a previous game and occasionally you'd come up with something new to push it a little further and squeeze a little more out of it visually. Simple times, but fun!"

Although Paul laments the number juggling inherent in programming for the 6502, he also remembers the system fondly. "I loved coding the NES, it was a completely different architecture from the home computers I'd worked on before, there were interesting tricks you could play with the character-mapped screen which you could exploit to give depth – go check out our Battletoads games on NES/Game Boy – and I regarded it all as an interesting technical challenge to 'solve' new issues around this alternative hardware architecture." 

The future of the past

But for all of the fun of programming the system, Paul rightly points to the results of that work as the reason for the success of the NES. "It can’t be forgotten that Nintendo had an incredible catalogue of games on the systems, notably Super Mario and Zelda. Super Mario Bros 3 was a huge step forward, and an absolute pinnacle at that time," he says. 

If you're an aspiring retro-game creator, the NES might just be the ideal platform for you. "NES code, graphics and sound are easy to manage by one person each in the team," says Nicolas. "Compared to now, the programming language feels more obscure and complex than modern languages. All the limitations push you to spend more time for everything," he admits. "But it also forces you to think twice about each idea. In the end, you can focus on the most important ones for gameplay. 

These limitations can keep the scope of your game in check – there's only so much you can do." If you find yourself drawn to the idea of tackling that technical challenge, show us the results one day – we’ll always be interested in seeing them. 

This feature originally appeared in Retro Gamer magazine. For more fantastic features and interviews, you can subscribe to Retro Gamer in print or digital here.