Family BASIC in 2019

In preparation for an article I’m writing on hobbyist Japanese Famicom programmers in the 80s, I’ve spent the past few days diving into a quirky bit of software from Nintendo called Family BASIC. If you’ve never heard of it before, FB was a Japan-only release for the Nintendo Family Computer that built an interpreted programming language into a cartridge, allowing users to program rudimentary games, utilities, and music compositions on their console using a custom keyboard peripheral. In partnership with Sharp, Nintendo released a custom modification of a Hudson-developed BASIC they called NS-HUBASIC—i.e., Nintendo Sharp Hudson BASIC).

Family BASIC’s commercial lifespan was relatively short-lived. Technically its first release was for a Sharp-manufactured television called the My Computer TV C1, which had an integrated Famicom and an early version of NS-HuBASIC called Playbox BASIC. Besides some slight UI differences and variations in its “pre-installed” software, Playbox BASIC was nearly identical to Family BASIC. The first FB cartridges shipped in July 1984 with software v.1.0. This was quickly supplanted by v.2.0, which itself received some bug fixes and an update to v.2.1A. In February 1985, Nintendo released a hardware upgrade (with much-needed RAM) along with a new software version—v.3.0—which added many new BASIC keywords and capabilities.

It’s fascinating to ponder an alternate history where Nintendo pushed the Famicom’s PC-like features and kept improving Family BASIC with more memory, better features, and improved hardware, but that future was not destined to be. Instead, seven months after FB v.3.0, Nintendo released Super Mario Bros., and the Famicom’s future as a console would be set in stone forever. The platform would no longer be programmed, but played.

What’s equally interesting is what FB became despite Nintendo’s lack of official involvement. Much like the U.S. and Europe, Japan had a thriving hobbyist PC culture throughout the 1970s and 80s, though served by different manufacturers and publishing outfits. U.S. mainstays like Apple and Commodore were available in Japan, but they were far surpassed by domestic PC companies like NEC and Sharp. And hobbyist programmers were largely served by the magazine マイコンＢＡＳＩＣ (or MyCom BASIC), a monthly publication that included PC computing news, reviews, cartoons, tutorials, and type-in programs.

I had purchased a few issues of MyCom from Yahoo! Auctions while searching for board game advertisements, and I was amazed to see listings for Family BASIC programs as late as 1988. When I poked around the Internet, I found a Japanese site that meticulously catalogued all the FB listings that appeared inMyCom during the magazine’s run. I was floored when I found out that one or more FB programs appeared in every monthly issue of MyCom from September 1984 to April 1996 (yes, 19-ninety-6), totaling more than 300 homemade Famicom programs. I was curious about finding out more but quickly realized that spending close to $20 per imported issue would be financially untenable. Serendipitously, in February 2019, a kind soul known as pc-986 uploaded an astounding cache of beautifully-scanned MyCom issues to Archive. And thus an obsession began.

So what can you do with Family BASIC? Long story short, it’s a programming language built atop an already highly-constrained platform. Family BASIC predates the hardware mapper technology that extended the Famicom’s capabilities, so you’re stuck with the limitations of the stock architecture, minus the backend necessary to host and run BASIC. Perhaps most jarring to a modern programmer is the pre-set palette of built-in sprites and background tiles. Since there is no RAM allotted for tiles, you’re stuck with those burnt to ROM. To their credit, Nintendo provided an incredibly flexible set of pre-made tiles. For sprites, you get Mario and Lady from Donkey Kong, several spaceships, enemies from Mario Bros., a race car, a few custom characters, and a few other miscellaneous tiles. For background tiles, there are mountains, Donkey Kong Jr. platforms, ladders, and various other abstract bric-a-brac that hobbyists managed to wrangle into convincing approximations of many different genres, from shooters to RPGs. With some time and creativity, you can concoct myriad creatures and architectures using Family BASIC’s smattering of tiles.

The BASIC implementation is robust and well-designed. Like all BASICs, it runs much slower than a native assembly application, so it takes a lot of work to get responsive controls and smooth animation. But Nintendo built in lots of thoughtful hooks to make game creation simpler. There are custom commands for sprite definitions, palette manipulation, animation, sound, and collision detection. And on the computing side, you get simple conditionals, loops, math operations, arrays, a very useful DATA/READ/RESTORE command trio, jumps and branches, the crowd favorite PEEK and POKE commands for hardware manipulation, and, surprisingly, a CALL statement, which allows you to inject machine language routines in your code. (In fact, MyCom ran a 9-month series in 1987 on how to use these features, culminating in an impressive scrolling tutorial.) And if you don’t read Japanese, you’re not out of luck. English translations of most of the v.2/v.3 manuals are available online, though it takes some time to assemble the various sources and piece them together. For me, it was most useful to skim the official resources, then work through a few MyCom programs to get a handle on the language and its capabilities.

Multiple emulators support Family BASIC, its keyboard, and (tape-based) saving features. I’d highly recommend Nintaco, a fairly new, Java-based emulator that works cross-platform and includes all manner of useful FB utilities. Most impressive of these is the Family BASIC Background Editor, which lets you circumvent FB’s built-in background editor in lieu of a more modern interface. I have no idea why Nintaco’s developer would put so much care into an interface that only a small number of people would use, but I’m exceptionally grateful that they did. It’s an incredible time-saver.

When I started thinking about my own FB project, I decided to design a Japanese sugoroku, partly because that’s a component of my other research interests, and partly because I wanted to make a game well-suited for the platform. FB action games don’t always feel great, and they can only be so complex, so I thought a turn-based movement/logic system would work well. I also thought I could make a pretty good approximation of sugoroku’s cell-based board layout using tiles and fill each section with tiny vignettes assembled from FB’s preset graphics. I also knew the game logic would be relatively simple to implement. Sugoroku, in a nutshell, is a race-to-the-finish style game that relies solely on the luck of the die roll. In the sugoroku variation I adapted (called “jumping” or “leaping” sugoroku), player progress is non-linear. Each board space has a list of numbers (corresponding to one or more die faces) and their destination spaces. So space 1, for example, might have you leap to space 6 if you roll a 2, leap to space 8, if you roll a 4, and so on. I didn’t have room to include destination numbers on each board space, but I thought that was a reasonable visual concession, since the computer is handling the numbers. Additionally, not all rolls allow you to move, and I made 4 an unlucky roll in all spaces (as a nod to the Japanese superstitions surrounding that number). In sum, there is no strategy or player choice—you roll and move, and that’s it.

Initially I thought the sugoroku’s theme would be Japanese ghosts, so I input ghost names in the custom data structure I created to store each spaces’ coordinates and destinations. After I got the game logic working, I realized I wouldn’t be able to make representative ghost illustrations in the limited tiles I had for each board space, so I spent some time “sketching” in the background editor and settled on a new theme—visiting an art museum. I loved the look of the borders in each board space, and I could fill the remaining interior tiles with tiny abstract assemblages that looked like modern art pieces. Once I’d drawn the entire background, I swapped the ghost names for artwork titles and built a little routine to print them on the right side of the screen, since I had an extra column of graphical space to fill.

Part of the challenge of working in Family BASIC is the Famicom’s limited resolution for displaying code. You can only view a small number of lines at a time, and with limited error messages, debugging is a tedious process of hitting an error, LISTing the pertinent lines, carefully making edits (it’s easy to overwrite other lines), running the program to check your edits, and on and on. Nintaco allows you to copy/paste code in and out of the emulator, so I started copying my source to Notepad to use as a reference while I was debugging. It’s not ideal, but it does save some editing time.

One limitation I did enjoy was the need to plan my programming in advance—on paper. BASIC uses line numbers to organize code, so even with the best intentions and ample line allotments, you can run into situations where you’ve exhausted all of your line numbers. FB v.3.0 added a helpful renumbering keyword, but I was working in 2.1A (because I wanted the authentic experience), so I had to renumber a few times by hand. Fortunately, I had planned most of the program in my notebook beforehand, so I knew roughly how much space I would need. Most of my line numbering problems were a result of adding feature I hadn’t originally planned.

Despite FB’s limitations, I’m pleased with the results. I think the “Art Walk” theme maps well to sugoroku’s random structure. It’s possible to “leave the museum” in two turns, or you can get stuck wandering for a long time. Instead of losing a turn, you must “contemplate for 1 turn” and spend more time in front of your current painting. And perhaps my favorite small touch is when I discovered that Mario and Lady’s ladder climbing frame resembles patrons standing in front of a painting and pointing at some detail they see.

For future projects, I’ll definitely jump to FB v.3. Just as I was finishing the project, I ran into an Out of Memory error, so I was scrambling to delete REM statements (i.e., comments) and concatenate lines to save precious bytes. As a result, I had no room for a few extra features I wanted—walking animations, a bit more music, and randomized “art critiques” that would appear on the screen as the players moved.

So why make a Family BASIC game in 2019? If you’re a newcomer to the Famicom/NES, it’s a user-friendly way to better understand the platform’s architecture. Tricky concepts like attribute tables are more legible when you have to manipulate background tiles around conflicting color borders (e.g., you can see a bit of color clash in my game—note the green numbers on a few board spaces). I also find it creatively rewarding to program under severe constraints. It’s a useful exercise to program before you touch a computer, and you can often think up clever game design tricks that you might never run into if you were working in JavaScript or Unity.

For those interested, you can download the save state for “Art Walk Sugoroku” to run it in Nintaco (don’t forget you’ll need a Family BASIC 2.1 ROM) and/or check out the source code on GitHub. And if you end up making your own Family BASIC project, be sure to send it my way on Twitter.