Emulation is a difficult thing to do, particularly when you’re trying to emulate a complex platform like a game console, with little to no public documentation available. Often, you’ll have to figure things out by brute force and dumb luck, and from time to time everything will come unstuck when a random piece of software throws up an edge case that brings everything screeching to a halt.
The Classic NES series was a handful of Nintendo Entertainment System games ported to the Game Boy Advance in the early 2000s. What makes them unique is a series of deliberately obtuse programming decisions that make them operate very differently from other titles. These tricks utilize advanced knowledge of the way the Game Boy Advance hardware operates and appear to have been used to make the games difficult to copy or emulate.
The games use a variety of techniques to confuse and bamboozle — from “mirrored memory” techniques that exploit addressing anomalies, to putting executable code in video RAM and writing to the audio buffers in unusual manners.
Even more confusingly, these techniques only appear to have been used in the Classic NES series of games, and not other Game Boy Advance titles. It’s not obvious why Nintendo went to special effort to protect these ports over other titles; perhaps the techniques used were for other reasons than just an attempt at copy protection. Speculate amongst yourselves in the comments.
This isn’t the first time we’ve discussed emulation of Nintendo systems — check out this effort to reverse engineer the Sony Pocketstation.
[Thanks to [[[Codifies]]] for sending this in!]
There are lots of reasons to use techniques like that, or there was back then. RAM was a precious commodity so if you could make a program faster by using a bit of video RAM it was worth it. Copying was also a problem that could in part by addressed by making the code hard to understand. It was also a good technique to employ if you wanted to be able to identify code of it was stolen by a competitor.
Beyond those reasons, in the 80s programmers liked to show off by using weird signature tricks like that. Coleco ADAM and ColecoVision code is chock full of weird tricks. One of my ADAM CP/M utilities used video RAM as buffer space. That’s just how things were.
I think it’s very unusual because this does not seem to affect copying, emulators while existing were not a issue. And this would not stop people using flashcarts.
Perhaps Nintendo was worried up about fake GBAs, I mean we have the GBA and GBC touch which I think are fabulous devices.
I think I agree with you in that it was likely someone showing off the techniques with no real aim.
I doubt these techniques would have benefited performance seeing as simple emulation on the GBA works well enough.
Can you elaborate on the GBA/GBC Touch? Never heard of them.
Can you elaborate on the GBA GBC Touch thing? Never heard of em.
Under £25 (30 USD).
http://www.ebay.co.uk/itm/Nintendo-GBC-Touch-Game-Console-Clear-Game-Boy-Advance-Custom-Transparent-/152258408442?hash=item23734eeffa:g:9~YAAOSwzaJX6~u2
Slightly larger than a GameBoy Color, it’s a clone runs the carts, is *backlit* and has a built in cart with some games (which can be co-opt into a flash cart).
For a little less the GBA touch.
http://www.ebay.co.uk/itm/Nintendo-GBA-Touch-Game-Console-Game-Boy-Advance-Custom-/112157268481?hash=item1a1d181a01:g:QFwAAOSwOyJX85W3
Looks alot like the GBA not sure on size, clone runs GBA and GBC carts.
Youtube breakdown: https://www.youtube.com/watch?v=wfaehijVodQ
Youtube review: https://www.youtube.com/watch?v=Ro4npBMKdmU
really? try a little before asking a basic question
GBA is Gameboy advanced
GBC is Gameboy color
you’re lazy
Then you are ignorant. Did you even read the post before your ego made you reply something nobody had any problem understanding and nobody asked for?
In the days of slow media, copying data was much faster if you can gulp down a lot at once. On the ADAM, the drives and especially tape had long seek times. Using video RAM sped things up a lot.
You’re right that the tricks did nothing for slowing people down from copying to run on the same hardware. It frustrated the hell out of people who want to make compatible hardware. They also did wonders to puss off people who wanted to reverse engineer your code.
Im certain about the showing off. Guilty as charged.
Memory was always a problem. Back in the ZX Spectrum days, programs often used the 256 bytes of the printer buffer to run a small loader that could fill main program memory to the very last byte.
Writing data to the blanking locations was common. most TV sets never showed it so it was a safe place to put things for short term use.
When porting a NES game to the GBA you should be in no danger of running out of resources, so that’s not the reason. Most of the tricks listed are also specifically anti-emulator tricks, not optimizations.
Like others here, I’m guessing they were just trying to protect their games from being pirated and played on emulators and/or clone hardware. Similar techniques have been used in computer software as either copy protection or anti-debugging mechanisms. Nowadays I’m guessing it’s mostly malware trying to detect whether it’s being executed under a virtual machine, to make detection and analysis more difficult.
I can agree with all this, but it’s such a strange decision because it was only for the Classic NES series, which was a whopping 42 games or so out of the 1000 games available.
Obviously these were re-releases of NES/Famicom games, and some with very minor changes that hardly mattered in the grand scheme of things. They were also apparently emulated rather than ported per se. Maybe that’s a reason for obfuscation, although pocketNES is a fully functional NES emulator for GBA.
I might add that mgba is imho probably the best GBA emulator out there, I’m currently replaying Golden Sun yet again and loving it!
I use mednafen since it supports a whole bunch of systems, means for a clean system.
But if mgba allows you to use your save files in an emulator as well as rip them from a nds and on a ez flash I’d be keen.
A friend used a copy protection trick that worked on the IBM PC, but isn’t relevant to the GBA. In the original PC, they used a DMA channel to seemingly needlessly read a range of addresses over and over. This was done to refresh the DRAM, as the first PCs used a lot of TTL and so using DMA to do it instead of adding a counter and muxing it into the DRAM address would have cost more chips.
So my friend did the usual obscuring tricks, and then disabled the DMA. He made sure his program loop would touch each of the 128 or 256 address offsets every video display cycle in order to keep memory alive. But if someone came in with a debugger and tried to single-step the code, suddenly all of DRAM would fade to bit rot.
Cool trick but very hardware specific! IIRC there were even some early XT clones that didn’t use DMA in that way…
GBA game sales suffered terribly from bootlegs and piracy so I assume Nintendo decided to use this series to field-test various copy protection strategies without having to mess about with their main development kit for GBA games.
One of the problems with these anti-emulation strategies is that they eventually become counter productive. Some of the larger publishers I worked for over the years (EA, Activision, THQ etc) made quite a bit of money by selling packs of their “classic” titles decades after the originals were released. The one problem I saw time and again was trying to circumvent and disable our own copy protection years after the original team members had left. Should have just downloaded a warez’d copy and shipped that! :)
Now that is very interesting. If you ever write up your experiences about such things be sure to tip us off!
If you are interested there was the case of Ubisoft using a reloaded no-CD crack when they were having trouble with Rainbow Six Vegas 2 back in ’08.
http://www.bit-tech.net/news/gaming/2008/07/21/ubisoft-uses-reloaded-crack-as-patch/1
By the conversation used here I think people are confused by the article. The strange decisions used on the NES classic series (NOT on the original NES carts) was for copy protection. If you have a cart with a working NES emulator it becomes trivial to find the bit on the eeprom that contains the rom and swap it out for another game. If they hadn’t made programming for the cart’s emulator so cumbersome, 100s of carts with old nes games on them would have showed up on the black market. Even back then Nintendo was extremely protective of their back catalog.
This comment needs more attention. It is not the roms that were being protected (they were readily available at that time) but rather the emulator that was being protected. This is because one could easily modify a generic emulator cart to run any nes rom, which would allow a pirate to release hundreds of gba games based off of the library of available nes roms.
There’s already NES emulators for the GBA, have been for years before this.
Maybe because these carts are quite small (just the emu + like 32K or whatever of game cart), Nintendo’s programmers decided to try a few tricks just to see how they went. The carts weren’t bound to be great sellers anyway.
Nintendo is still very protective of their back catalog, see Project AM2R for instance. :(
It is weird that they put so much effort into preventing the emulation of games whose NES counterparts were easily emulatable.
I doubt these are anti emulator or even copy protection tricks. First copy protection – do any of these stop you copying a rom?? Probably not. It seems the author has experience of writing an emulators but does he have experence of writing a game on GBA or NES? I mean I’ve written a little 8bit stuff and I did work in the GBA era on games too. My friends current 8bit game uses tons of tricks and self modifiying code to eek out every last bit of performance and ram, a side effect is his code gets more obfuscated.
Actually I see he has written something homebrew for the GBA, but it would be interesting to investigate each claim and see if there are other reasons you might do the trick, or hardware reasons.