What it was like developing for NES back in 1990

https://twitter.com/KevEdwardsRetro/status/1423653418439254026

by _Microft • 5 years ago

230 60 5 years ago

_Microft• 5 years ago

From the title screen of the tool:

"The current version still has room for improvement and any suggestions will be listened too[sic!], and probably ignored."

Good to know that it was never any different ;)

yosser2• 5 years ago

One of the trickier things to manage on a NES (without additional hardware on the cartridge) was maintaining a static information panel on the bottom of the display - for the score and so forth - while the portion of the display devoted to gameplay scrolled freely around both vertically and horizontally.

The trick we used at Zippo (Wizard and Warriors II and 3, Solar Jetman etc.) a trick given to us by Rare, was to change the scroll registers and I think the character look up location at the moment the screen refresh cycle reached the appropriate point on the display. These registers would then need to be reset during the vertical blanking interval. So all in all either 100 or 120 times a second depending on the TV system.

Since we couldn't afford to keep the CPU hanging around doing nothing while we waited for the cathode ray tube gun to hit the right point on the screen the trick was a two parter.

First you would get the sound chip - such as it was - to play an inaudible sample of a determined length which would then trigger a CPU interrupt at more or less the right time, within say two or three scanlines of the position of our static panel. You would then position a spare sprite on top of a visible pixel at precisely the right point on the screen so that when it flipped its hardware collision detection bit this was precisely the right time to switch the scroll registers etc.

These were the kinds of shenanigans that made programming the NES intricate and time consuming, and also in later years I suspect made the job of emulator writers something of a misery.

crmrc114• 5 years ago

Your post is why I keep coming back to HN to read- thank you so much for sharing. I love the undocumented stories from the trenches.

phoboslab• 5 years ago

Very cool! Sounds a lot like all the tricks you had to employ for the Atari 2600. If someone is interested in this, I can highly recommend the book "Racing The Beam". It's hard to imagine these days how complicated even the simplest things were back then.

15 years back I did some hobbyist programming for the GameBoy. Drawing a status bar there was comparatively easy. The hardware allowed you to set some registers to define a "window region", overlaying the main background map.

ant6n• 5 years ago

No hblank interrupts? Game boy has them to make this sort of thing relatively easy. Hblank interrupts is also how "mode7" style pseudo 3d for a Mario kart style game can be made (on GBA or SNES).

jkarneges2• 5 years ago

We abused hblank to death in Infinity for Game Boy Color (unpublished in 2001, later dumped on GitHub), for things like parallax scrolling, tilted overworld map, screen transitions, and scrolling inner text.

aidenn0• 5 years ago

IIRC, SNES had those, NES did not.

city41• 5 years ago

You could get the equivalent of hblank interrupts with a mapper, such as the mmc3 used in Super Mario Bros 3. That is how SMB3 renders its hud.

https://en.wikipedia.org/wiki/Memory_management_controller#M...

toast02• 5 years ago

Atari had a patent on a cpu instruction to wait for hblank, I suspect Nintendo didn't put anything similar in the hardware as a result. But it was needed, so interrupt generation ended up in cartridges... And since they didn't get sued, put in the next gen hardware.

agumonkey2• 5 years ago

man it must have been such a weird era where the screen was part of the "system architecture"

today everything seems so decoupled

nine_k• 5 years ago

The hardware was so limited and expensive that rather trickery paid off.

For instance, on Sinclair Spectrum the memory refresh and the keyboard matrix scanning were intimately coupled; tape I/O and screen border color circuits were also somehow coupled, which was easy to see with every tape operation.

anyfoo4• 5 years ago

was to change the scroll registers and I think the character look up location at the moment the screen refresh cycle reached the appropriate point on the display. These registers would then need to be reset during the vertical blanking interval. So all in all either 100 or 120 times a second depending on the TV system.

That's a cool way to do it on the NES. While the NES did not have a raster interrupt, requiring such tricks (though you mentioned the later cartridges with the extra chip that added one), the Game Boy did have a raster interrupt, and the SNES essentially went all in on it. Switching the mode mid-frame became a very common method then.

By the way, PAL/NTSC is 50/60Hz, but a frame consists of two fields (odd/even lines), so 25 or 30 frames per second for PAL/NTSC respectively. So I guess this means you probably did the trick 50/60 times per second? (Unless you used more than two configs per frame maybe.)

janzer• 5 years ago

My guess is the trick is needed four times per frame. For every field you need it once to start the static portion drawing, then once more to stop.

thristian• 5 years ago

NTSC draws each frame as two fields; first the 240 odd rows, then the 240 even rows, for a total of 480 interlaced rows, or "480i".

However, older video game consoles (such as the NES and SNES) typically output a malformed NTSC signal, designed to trick the TV into drawing just the odd lines, over and over again, sometimes referred to as "240p". As a result, it's effectively 60 independent frames per second, not 30 frames of two fields.

yosser2• 5 years ago

Ah yes, in retrospect I think the NES was refreshing at 25/30 times a second, so double that for the number of scroll register updates we needed to make.

It's been a long time!

psyc• 5 years ago

What mechanism existed for telling what scan line the TV was on?

klodolph2• 5 years ago

That’s what the “hardware collision” bit is about. You place sprite 0 at a certain location on screen, and you can find out when that sprite gets drawn (with some certain other restrictions / assumptions). IIRC, the collision bit gets set when a pixel from the sprite is drawn overlapping a background pixel. This is how early games like Super Mario Bros. drew the status bar, but Super Mario Bros. could just spin the CPU waiting for this.

There are two other mechanism I know off the top of my head.

One is to put some circuitry on the cartridge, and then arrange the usage of tiles such that all the background tiles are in one bank and all the foreground tiles are in another. If you do this right, you get an address line which cycles high and low once each scanline–and you can put a circuit on the cartridge which counts the scanlines, triggering an interrupt. This was only available if you could put that circuitry (usually, a “mapper”) on the cartridge.

The last method is to count cycles.

I would note that among other differences, this is much, much easier on a Game Boy. The Game Boy has a register you can read which tells you which row you are on. Not the only thing that’s easier on a Game Boy—there’s also a hblank interrupt, and the tilemap is larger than the screen. Anyone interested in NES programming but unsure about how much they like dealing with obscure technical problems may want to try Game Boy programming first to get a taste for it.

burnte• 5 years ago

The TV syncs to the clock in the input signal that the console generates. The console knows what line the TV was on because it's the line that the console is currently outputting. Analog TVs were very simple devices where the signal coming in via the wire or antenna was basically pumped directly to the CRT to manipulate the beam. While at the user's end it looked like a raster, it's all analog tricks.

Imagine a text file pushed out theough a serial port, all the data is just dumped on to the wire and the other end worries about interpreting carriage returns and line feeds. You just imagined how old line printers worked!

When the TV wasn't able to figure out the sync signal you'd get rolling [1] or tearing [2] where the picture was being displayed the best the TV could make out.

1: https://youtu.be/bGXEqzCS4nE?t=28 2: https://www.youtube.com/watch?v=FVOVk3psy-w

0des• 5 years ago

When I hear stories like these, I always think that nobody is doing stuff like this these days; but in retrospect, I think it's just that I've never asked or seen it discussed.. so..

What are you guys doing these days that has this same hacker-ethos applied to it?

gambiting2• 5 years ago

It's semi-common on PS4 to abuse the audio coprocessor to do things other than audio, just to eek out that little bit of extra processing power. After all, it's programmable, so why not? In fact Sony specifically made the PS5's audio processor non programmable to make sure developers don't do this and actually focus on its strengths and things that it can do very well with 3D audio and such, rather than make it crunch physics or whatever.

Also I'm aware of at least one game that uses an internal executable restart routine to reboot and reload data on PS4 and X1 since it's just easier than dynamically unloading all engine data and loading it again following an in-game update. While not forbidden by either 1st party, it's certainly somewhat unorthodox.

In general, I think that even with next(current) gen there is still a lot of the good old school hacker mentality going on, it's just that you can't hear about it because it's all NDAd. Wait 10-20 years and those stories will start to come out.

matheusmoreira2• 5 years ago

also in later years I suspect made the job of emulator writers something of a misery

Most certainly. These tricks force developers to emulate systems down to individual cycles in order to get the timing right because getting them wrong will result in visual glitches or worse.

https://mgba.io/2017/04/30/emulation-accuracy/

https://mgba.io/2017/07/31/holy-grail-bugs-2/

Byuu, the author of bsnes, wrote some very detailed articles about this as well. I can't seem to find them anymore though. His domain has also been excluded from the internet archive for some reason.

Saoshyant• 5 years ago

His domain has also been excluded from the internet archive for some reason.

Because Byuu, who later went by "Near", tried to scrub as much personal information from the internet in the hopes of staying ahead of constant doxing attacks by an awful internet community called KiwiFarms. It didn't work. In the end, Near/Byuu committed suicide months ago to escape the constant harassment.

Akronymus• 5 years ago

Isn't it actually down to sub instructions?

chrismcb• 5 years ago

You meant 50 or 60 times a second. SNES wasnt that fast. And yeah what you were describing was common

toast02• 5 years ago

They mean that they need to fiddle with those specific video registers twice a frame, which is 100 or 120 times. Vblank timing isn't too hard, the base system has an interrupt for it; scanline timing is hard though, you either need to carefully time your loop (and redo it for 50hz systems), or poll on things, or use extra hardware built into the cartridge (mappers).

I don't think there was an IRQ for sound, but it might have made sense to poll the audio unit rather than the graphics unit for some reason.

Kye• 5 years ago

Was this any less harrowing than racing the beam on an Atari 2600?

TillE• 5 years ago

NES games were still pretty simple, so I can see how simple tools were more or less adequate.

I'm far more impressed that complex SNES games were also developed purely in assembly, like A Link to the Past (1991) or Super Metroid (1994). This is an era where PC game developers would mostly be using C.

anyfoo4• 5 years ago

On the other hand, there were pretty complex games on the vastly more simple NES. Less than on the SNES, they required elaborate tricks. (I guess that however mostly required more from the actual game code, and sometimes some extra hardware, than from the tools.)

emsy• 5 years ago

SMB3 will outshine a lot of games released today and I think that’s a good thing. Great game design is somewhat timeless.

pdkl95• 5 years ago

https://www.youtube.com/playlist?list=PLHQ0utQyFw5KCcj1ljIhE...

You may be interested in this series on SNES hardware features and how they were exploited. The videos have very informative visual representations of memory/io/etc. (the other videos on the channel are also good)

sircastor2• 5 years ago

I wrote an NES game as my senior project for college. It was a singular experience as the vast majority of my development experience had been web technologies.

I had the advantage of full-featured emulators, breakpoints, examining the code as it was running, and a very searchable community online. I have sometimes pondered on the challenges of writing 6502 assembly without any of these things. It’s really interesting to see some of what that was.

djmips4• 5 years ago

It certainly is so much easier to get documentation or read forum posts and ask questions today. Back then, we did have fairly decent dev systems though, could do breakpoints and examine code as it was running. It was also cross-development so you could edit and download from your computer onto the dev system attached to the console. To be fair, some people had much more primitive systems, I feel lucky since others could only test by burning EPROMs.

noobermin• 5 years ago

Could you qualify one thing? One that might help is code back then was almost always single threaded and thus easy to reason about. I mean, even today concurrent code is difficult to deal with.

nom• 5 years ago

Does anyone know how it is done today, like with Micro Mages?

https://youtu.be/ZWQ0591PAxM

djmips4• 5 years ago

For NES there are many development environments now... Probably dozens. The main modern advantage is emulators. I do enjoy folks who take a different approach like this dev who is using Lisp to make a NES game. http://www.dustmop.io/blog/2019/09/10/what-remains-technical...

sircastor2• 5 years ago

I used an emulator called NinTaco, a 6502 assembler, and VS Code. My game was very simple and completed in about 3 months (I didn’t have any sound and a very limited game)

I think the crucial piece is the assembler and documentation about the start up and loop processes.

dormento• 5 years ago

I do it in C (good enough for most purposes, although a little slow and bloated - most people do it straigh in ASM with extensions).

I use Ubuntu, good old Sublime Text with C extension, FCEUX (Windows version on wine) and YY_CHR (for working with graphics). To compile, check out the awesome CC65 suite (it has a compiler, assembler, linker... the whole thing).

ec109685• 5 years ago

Reference point to what Mac development was at the time (Think C from 1991): https://www.youtube.com/watch?v=zkhcBeK4V_4

lwansbrough• 5 years ago

Wow, remarkable to see 30 years later how much remains the same.

alkonaut• 5 years ago

What's the reason for using ASM? Were there no good compilers for higher level languages (like C) available for the platform, or were the developers simply accustomed to using ASM, or was the platform limitations such that developers simply had to use ASM?

dan_hawkins• 5 years ago

6502 is just not that viable for C-like languages. Mostly because of its tiny hardcoded stack, so for C you need to either emulate the stack in software (slow) or figure out workarounds (mostly involving precious zero page.)

colejohnson66• 5 years ago

Not to mention that there’s only three registers (A, X, and Y (and P, technically)). And each one has a different purpose; There were no “general purpose registers”

What it was like developing for NES back in 1990

Related Stories