These days, if you want to code a game for the original Nintendo Entertainment System, it’s about as easy as downloading an assembler, firing up Notepad, and running the ROMs you cook up in any one of a variety of emulators. In the 1980s none of those things existed, and the process was a little more complicated – as demonstrated by [Tyler Barnes] in the video embedded below.
[Tyler] has put together a 40-minute guide on what it takes to get to “Hello World” – or more accurately, a simple pink screen – on the NES, using period-correct hardware. He starts the process by formatting some floppy disks and whipping up some basic assembly code on an Apple IIe, which gets run through the Merlin assembler for the 6502. It’s particularly convenient as the Apple II line and the NES both run the same CPU. From there it’s a case of using a standalone EPROM programmer to verify some appropriately-datecoded chips are empty, before programming them in a special add-on card for the Apple II. From there, the EPROMs are loaded into a cart custom modified with chip sockets, where it can be inserted into a NES for testing.
It’s a tedious process, with just the programming side of things taking on the order of ten to twenty minutes with a few fiddly steps along the way. While there are likely some efficiency gains to be had that were used by studios back in the day, it remains clear that development in this era was a much slower process.
Of course, if you prefer your Nintendo homebrew a couple generations hence, consider getting stuck in on the Nintendo 64. Video after the break.
[Thanks to Alex McAlpine for the tip!]
What is this extended keyboard? I don’t know Apple II had these.
The computer used is a Platinum Apple IIe. They came equipped with the numeric keypad.
The Platinum //e was a really nice platform with an excellent sculpted keyboard. A really interesting look at human factors comes from looking at the effect of using a 4MHz accelerator. At that speed the system actually keeps up with a developer’s pace as far as an edit/compile/test cycle and with a large RAM disk, the Profile HDD, or similar setup it was very satisfying and boots in about 1 second. Using an Apple //e to target a C64 was way faster than using the C64 itself.
Anyway, a user interface that is not a GUI takes very little processing power. Eventually there were 8 and 10MHz accelerators. (There was also a project to use an ARM since Apple was one of the owners of ARM and prototypes were built. The rumor was always that it outperformed the new Mac and Jobs did not like open hardware expansion in the box. The ARM //e would have been outstanding, but that is a whole ‘nother story.
Where can I find out more about an ARM Apple 2 type project?
Agree with you. The Platinum with fast CPU is nice. I run a FastChip in mine and it is remarkable above a few Mhz.
I have three sources each with not a lot of info. First is Bana Witt, deceased in March and Apple employee 49 and assistant to Jef Raskin. She knew the Huston brothers who (I think) built the prototypes. I’m the executor and working through papers and photos. Second isn’t really a source yet. Contacting some of the members of the original Mac team whom she knew well.
Third is Art Sobel (retired now) from VLSI which was the 2nd licensee/shareholder/partner in ARM. I saw something by him in the last few weeks where he mentions it. Any Apple ARM project at he time would use VLSI silicon. https://retrocomputingforum.com/t/art-sobel-on-the-history-of-arm-and-further-notes/1422
By the way, one thing Bana did was cut up Apple I’s on a bandsaw. Jobs saw the drain on time and personnel from supporting the Apple I so he offered a very attractive trade-in deal for an Apple II and they destroyed them to make sure they would not find their way back into the wild and be a PITA. Another thing she did was marry “Tog”, Bruce Tognazini and win Beat Poetry slams in SF. I think you can email me through the ancient regnirps.com if you want to keep in touch on this.
Incredible – thanks for sharing!
Also the Laser 128 EX had an extended keyboard in a beefed-up IIe-IIc compatible clone.
So EPROM emulators weren’t a thing back then? I’ve seen amateur building these in the 90s so I’d expect commercial solutions to be available much earlier.
That’s exactly what I though: doing a cartridge board with some RAM and a connection to the Apple ][ would had speed up the process a lot, and it’s extremely simple and maybe even cheaper.
I think the same. There were ROM simulators using RAM in the 80s, maybe even 70s.
However, it also seems like early development was done “the hardway” via EEPROM.
Well, at least in Japan.
https://www.retroreversing.com/famicom-nes-development-kit/
They are basing that information on pictures of a children’s book. The existence of eeprom prototypes doesn’t mean that’s what the developers used for development. They might develop with a eprom emulator attached to their computer, then when they wanted to distribute it around the office to testers / executives they could burn it to eeproms.
Yes, I have certainly seen dev cards such that you have described. I’ve not really had the time to dig into the prototyping board documentation to build one up. It would just take a 6522, some ram, some rom, and maybe some glue. But writing the firmware takes some knowhow and specific calls.
The documentation for making an Apple II expansion card is here: https://www.apple.asimov.net/documentation/hardware/io/Apple%20II%20Hobby%20and%20Prototyping%20Board%20Manual.pdf
The SUPERPROTO v1.0 would be a easy jumping off point for such a card as well.
There is also a great article on such dev cards for the Apple II here: https://arstechnica.com/gaming/2019/09/how-a-basement-hacker-transformed-donkey-kong-for-the-atari-2600/
Lewin, the Apple II and the NES do not use the same CPU. The Apple II series used the MOS 6502, whereas the NES used the Ricoh N2A03.
Perhaps I’m being overly pedantic, but I wouldn’t think that anyone interested in being accurate would describe an ARMv5-class CPU, and an SoC using an ARMv5-class CPU with a few instructions disabled, to be using “the same CPU”.
The Ricoh N2A03 does make use of most of the 6502 instruction set, but notably, BCD mode is disabled due to Ricoh being uninterested in licensing the relevant patent from MOS at the time. Additionally, the Ricoh N2A03 contains the NES’s audio generation circuitry, controller-polling circuitry, and other functionality within the same overall package.
Oh good to know… I always thought I got hired to work back in ’89 on NES and TurboGfx16 (65C816) because I coded in 6502 on II+ (and 65c816 on IIgs)
Interesting. Would you, by any chance, happened to have lived in Monterey County (Calif) around that time?
The Apple //e in the photo came with a 65C02 which has some added instructions and fixed a paging problem for one of the indirect addressing modes. There was an update kit with ROMs and a 65C02 supplied by Apple for use in previous Apple II versions.
And that doesn’t matter in the slightest. Anyone who can write for the 6502 can write for the N2A03 immediately, the differences are trivial as far as development is concerned. Nobody is out in the world complaining about how the Ryzen and the Core i7 chips are COMPLETELY DIFFERENT AND HOW CAN YOU EVEN CONSIDER PUTTING THEM IN THE SAME CATEGORY
Programming for a subset is easy, you just don’t use the missing features. Lots of people used only a subset of the 6502 instructions.
The development tools were there for the Apple II, and the hardware was more available than some specific development system. You’d always face limits because some hardware from the game was missing, or at a different location. But itwas way easier than writing emulators and cross assemblers.
I believe these were “popularly” called “ROM-ulators”
A well tuned system setup allowed one to generate a hex file automatically reset the system and download the file to the device.
The ones I used were 128K max and had different pin out boards to plug in for the ROM, a micro clip lead was available for hooking into the reset on the system.
Anyhow one would download the image to the system then release the reset and see what happened (boom rarely happened… really). This was usable on most any processor type that supported external program memory.
Did Nintendo do any NES development using a IIGS?
Nope. But a few third party developers used the IIGS to write SNES software. (Most notably Becky Heineman for the SNES version of Out of This World. She also wrote the IIGS version of that game.) This was incredibly uncommon, however, as Nintendo sold official dev kits to the big companies.
Something doesn’t add up here. The NES was launched in 1985 in US. Which is a year after the release of IBM PC AT and 80286 is already roaming the earth. Using Apple //e for development because it shares the same 6502 CPU seems like rather a rather weak reason.
The PC monopoly was neither close to being existant nor even obviously the correct choice in 1985. We know of people using host computers of basically every single available architecture (ranging from x86, 6502, 68k, 6800, VAXen, various Japan-exclusive things) to develop games for the NES.
The piece you’re missing is that the NES wasn’t a clean-sheet design. There were existing product lines, and as is usual in industry, it was faster to adapt the existing environment and workflow than to create one from scratch based on the newest, sexiest hardware available (although nobody would have described the AT and 286 platforms in those terms at the time).
Additionally, pretty much anyone doing _anything_ in game development already had lots of experience with 6502-based technology, while the 8086 and 80286 were not really that similar to a Z80… and the Z80 was not well-represented in graphical gaming circles anyway.
Running the test environment on a 6502-class cpu had the added advantage of making it easy to exercise some parts of the (non-hardware-specific) code without having to do the full round trip to the game box.
This was a different time. It’s hard to believe, even for myself, but 80s hardware was common to find at homes up to the early 90s. No kidding, seeing an old XT class PC doing its job, say, in the corner of a hardware store, garden center or behind the counter in a PC store wasn’t unheard of in ~1991-1994. Likewise, C64, Amigas etc were still around before approximately Windows 95. In the amateur radio hobby, the C64 must have been a common terminal up to ~1990 according to magazines, also. That being said, it also depends on where you live. In Europe, people used computers like, say, the Atari ST for a longer time than they did in the US or Canada. So I could imagine very well, that a person in 1988/1989 would buy an out-dated Apple II series PC as his/her primary PC, even.
A 4MHz Apple //e (or 8MHz by 1985) outpaced the IBM PC pretty easily because assemblers are text processors and the binary output is in bytes. A fast 8 bit processor was perfect for this. And in the case of 65C02 (20mW at 1MHz by the way) the number of possible 8 bit opcodes is 212 which means 1 byte offsets into lookup tables can handle fast opcode generation in the assembler. Plus there are a couple addressing modes that make this very easy.
There were many good 6502 assemblers available on the Apple II (most notably Merlin, shown in the video, and the competing ORCA/M, but there were also lots of others) whereas there weren’t likely to be many 6502 assemblers on the PC in 1985. Also, the programmers who were most familiar with that CPU (and frequently hired by game companies who wanted to produce NES software quickly) were most likely already accustomed to using 6502-based computers, whether from Apple, Commodore, or Atari. Also, the PC was expensive compared to those 8-bit systems and it was not yet ubiquitous the way it was later, so there’s no reason to assume programmers would have had access to one.
**Notepad++
:)
Man good thing nesmaker is out. So much easier and better now.