> 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.

> 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.

https://knowyourmeme.com/memes/events/near-byuu-suicide is one of the least-comprehensible stories I've ever read. I've been on the Internet since 1989, and practically none of that means anything to me.

> ...awful internet community called KiwiFarms.

The free speech Alamo. It often leads to funny results, like lesbians finding it to be the only place they could complain about some psycho in Canada targeting women operating small businesses - Youtube and Twitter banned several people over it before the Canadian media started covering it. Sometimes it leads to not so funny results, because that is the cost of agency - its kinda crazy that even has to be pointed out... but we seem to be at that point.

Holy shit, I didn't know. I'm sorry, I'm shocked and just don't know what to say. Thanks byuu for all your work. Hope you find peace. You will be remembered.

Isn't it actually down to sub instructions?

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.

> 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.)

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.

Yes. Even if that weren't the case, the NES would have needed to separately buffer the whole frame (or worse) if you did not want to repeat the scroll register dance per field, which is where I went wrong.

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.

Ah, duh, you're completely right. I somehow hallucinated another buffer between PPU-generated frames and video output. Which would have been rather expensive at the time...

Also I only just learned that because the NES does not actually output the half scanlines that make interlacing work, both fields are drawn on top of each other, effectively making it 50/60 actual frames per second anyway, instead of interlaced fields! (https://wiki.nesdev.com/w/index.php/NTSC_video)

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!

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?

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.

> 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.

Microsoft put out a video soon after purchasing Bethesda where someone from that team mentioned doing a similar trick in the Xbox port of Morrowind. If the game was approaching the relatively tight 64MB RAM limit of the platform it could soft reboot the console during a loading screen and then reload to the current point.

Yeah, MVG did a video on it ;-) I can confirm that the exact same trick is still used on modern games.

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.

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).

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...

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.

I looked for that, found it on github and then looked at the build instructions, followed the link provided to GBDK and saw my credit as one of the contributors. Totally forgot about that... :)

Are you participating in the re-launch of development for Infinity? (great to see it happening)

If so, what approach are you taking for the toolchain? Keeping the existing version that had been used/modified? Updating to newer tools (and code changes that may go along with that)?

Everything's up to Incube8, although I'll be advising. In general, my recommendation is to consider better tooling for managing assets and running builds but be very careful with the code (e.g. don't change compiler versions, don't refactor anything).

Thanks for the reply. It'll be interesting to follow the progress.

Can definitely see wanting to keep the compiler and code in a known state. Though modern SDCC generates code that's probably 50% faster in some cases and with 90% less bugs than versions from the early 2000s.

Lots of great Game Boy releases have been coming out.

Edit: add a little more.

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.

IIRC, SNES had those, NES did not.

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

today everything seems so decoupled

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.

I know, I mean the thought process when designing a program in such constraints where any aspect of a system might be a useful resource and you had almost no other choice (kinda like abrash rotated texture trick on pentium) .. it's so at odds with current processes where everything is split and isolated as much as possible.

Computers do over 1000x as many instructions per second now.

They do more instructions per second than a whole 15min game play.

Imagine trying to coordinate all those interactions without abstractions.

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

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.

And how would one know the bit was set... polling?

Yes: but it's messy. You spin in a loop with a BIT instruction polling the PPU_STATUS register and a BVC instruction pointing backwards waiting for bit 6 to be set. Besides the fact that you're stuck doing this, the main problem is synchronization, this little loop takes 7 CPU cycles (with each CPU cycle taking 3 PPU cycles, or 3 "pixels" of distance) leading to an 21 "pixel" variance. When dealing with the very short horizontal blanking period between scanlines, it leaves very little time to do anything meaningful with the PPU in that window.

If you've ever noticed some "weird flickering" near status bars in NES games, this is probably the culprit: Few very skilled developers were able to pull it off cleanly.

Yes, polling.

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

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

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.

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