How SNES emulators got a few pixels from complete perfection(arstechnica.com)
arstechnica.com
How SNES emulators got a few pixels from complete perfection
https://arstechnica.com/gaming/2020/04/how-snes-emulators-got-a-few-pixels-from-complete-perfection/
166 comments
I'm sure the answer is no, but I emailed a few people at NERD (Nintendo European Research & Development). Asked the obvious question about the documentation even existing anymore, and if there were any possibilities of it ever being made public.
You've probably done that already, but I figured it was worth a shot. I'll update if I actually get a response.
You've probably done that already, but I figured it was worth a shot. I'll update if I actually get a response.
Nintendo's official development manual is available at archive.org [0]. However, AFAICT it is rather low-quality and incomplete, and it pales in comparison to the wealth of documentation created by years of reverse-engineering effort from hobbyists like byuu.
I imagine that the official documentation was leaked rather than publicly released. Nintendo wants to make money selling re-releases of classic games, so they are extremely unfriendly towards emulator developers. Just look at the all the propaganda on their corporate website: "The introduction of emulators created to play illegally copied Nintendo software represents the greatest threat to date to the intellectual property rights of video game developers [...] Such emulators have the potential to significantly damage a worldwide entertainment software industry which generates over $15 billion annually, and tens of thousands of jobs." [1]
[0]: https://archive.org/details/SNESDevManual/mode/2up [1]: https://www.nintendo.com/corp/legal.jsp
I imagine that the official documentation was leaked rather than publicly released. Nintendo wants to make money selling re-releases of classic games, so they are extremely unfriendly towards emulator developers. Just look at the all the propaganda on their corporate website: "The introduction of emulators created to play illegally copied Nintendo software represents the greatest threat to date to the intellectual property rights of video game developers [...] Such emulators have the potential to significantly damage a worldwide entertainment software industry which generates over $15 billion annually, and tens of thousands of jobs." [1]
[0]: https://archive.org/details/SNESDevManual/mode/2up [1]: https://www.nintendo.com/corp/legal.jsp
I would assume that from a practical standpoint, the SNES emulation 'war' is lost for all practical definitions of it - pirates can run everything they want in more than sufficient quality using any of multiple options.
So Nintendo doesn't have much to lose by letting the few geeks that want perfection for perfection's sake have it.
So Nintendo doesn't have much to lose by letting the few geeks that want perfection for perfection's sake have it.
That's not how corporations work though. The default decision is "no" and an individual employee has no benefit from getting through all the red tape to get a "yes".
It is also about consistency. Let’s say for argument’s sake they decided to sue the creators of the emulators. If even one time Nintendo cooperated with and assisted the emulator developers, it is easy for the defense to argue that Nintendo implicitly endorsed the work and therefore why are they suing them.
Third-party SNES emulator are more accurate than Virtual Console.
It's worth noting that the Virtual Console SNES emulator doesn't really have a reputation for inaccuracy. For sure it's not as accurate as Higan/bsnes but by all accounts it's pretty decent. Of course it was made for running in different constraints. It runs many games very well on the New 3DS' 804MHz ARM11 or the Wii's 729MHz PowerPC G3. Bsnes won't run much in those constraints.
IIRC each game for the Virtual Console comes bundled with its own emulator, tuned specifically to run that game. So there is no single Virtual Console 'emulator'.
I thought this was true for N64 Virtual Console games, but most older consoles were using pretty much the same emulator.
Wasn't Sony caught using an open-source PS1 emulator for their recently-released(ish) Playstation Mini?
I don't think "caught" really is the proper word to use, when they credited the PCSX-Rearmed project in the menu of the Playstation Classic. It might be considered somewhat embarrassing they didn't make their own better emulator (I guess?), but it's not as if they were actively hiding it either.
It may be embarrassing from a PR / image standpoint, as seen by the mainstream who doesn't know better and will read some headline followed by sensational lines like «Sony sued emulator projects to death (and lost) and now uses them for profit in products!»
The truth is that the amount of work and dedication that goes into a great emulator, with all the quirks and ad hoc settings for the whole library... no corporation on Earth can get that within months, it's actually a textbook example of the Mythical Man-Month (you need a few "hotshots" that will give their life for years to reach that level of refinement, you just can't hack it with a team of 10x averages without the heart that goes into it).
And even if you could, it's ridiculous cost versus 'free'.
Sony did the right thing by crediting them explicitely in-GUI. It's a classy move. There's a certain school within Sony that's extremely friendly to open-source, I surmise it's the historical engineering ethos of that company that hasn't entirely left their premises— in some buildings, some labs, the Sony-spirit of old is alive and kicking, e.g. their Sailfish-OS friendly phones (i.e. open-sourced drivers for these models, fully rootable etc).
The truth is that the amount of work and dedication that goes into a great emulator, with all the quirks and ad hoc settings for the whole library... no corporation on Earth can get that within months, it's actually a textbook example of the Mythical Man-Month (you need a few "hotshots" that will give their life for years to reach that level of refinement, you just can't hack it with a team of 10x averages without the heart that goes into it).
And even if you could, it's ridiculous cost versus 'free'.
Sony did the right thing by crediting them explicitely in-GUI. It's a classy move. There's a certain school within Sony that's extremely friendly to open-source, I surmise it's the historical engineering ethos of that company that hasn't entirely left their premises— in some buildings, some labs, the Sony-spirit of old is alive and kicking, e.g. their Sailfish-OS friendly phones (i.e. open-sourced drivers for these models, fully rootable etc).
> The truth is that the amount of work and dedication that goes into a great emulator, with all the quirks and ad hoc settings for the whole library... no corporation on Earth can get that within months
It can and has been done. Have a look at "Connectix Virtual Game Station"[1]. It's a commercial prodcut that played virtually every PS1 game flawlessly on a 233MHx iMac. I spent thousands of hours playing games on that thing, and glitches were very rare in a huge range of games, even the most demanding like Metal Gear Solid.
Jobs even demoed it on stage.
[1] https://en.wikipedia.org/wiki/Connectix_Virtual_Game_Station
It can and has been done. Have a look at "Connectix Virtual Game Station"[1]. It's a commercial prodcut that played virtually every PS1 game flawlessly on a 233MHx iMac. I spent thousands of hours playing games on that thing, and glitches were very rare in a huge range of games, even the most demanding like Metal Gear Solid.
Jobs even demoed it on stage.
[1] https://en.wikipedia.org/wiki/Connectix_Virtual_Game_Station
It may have run most popular games with few glitches, but it was far from being accurate.
Yeah, I meant 'caught' as in they were caught in that they couldn't do better.
Shouldn't this fact be celebrated rather than shamed? PCSX-Rearmed gets immense validation, and Sony doesn't waste years of engineering time reinventing the wheel.
As I said right above, (https://news.ycombinator.com/item?id=22759876)
I think it's not that easy. Not that corporations like Sony are necessarily lacking, but the greatest emulators are works of art, some masterpieces of reverse-engineering.
I think it's not that easy. Not that corporations like Sony are necessarily lacking, but the greatest emulators are works of art, some masterpieces of reverse-engineering.
I can't confirm it, but it wouldn't surprise me in the least. Throw some scripts in there at boot to do some env setup and then let 'er run. Probably plays nicer with COTS hardware, and no heavy back-end coding required.
Which is essentially the point of re-releasing that, or selling old Nintendo games on the Wii/Switch market -- easy cash grabs with little overhead effort.
Which is essentially the point of re-releasing that, or selling old Nintendo games on the Wii/Switch market -- easy cash grabs with little overhead effort.
If ever there's a law passed that allows Nintendo to get non-licensed emulators banned entirely, I have no doubts they'd do everything in their power to have them wiped from existence by the next day.
If they give up and give assistance to emulator devs, there's no going back on it.
If they give up and give assistance to emulator devs, there's no going back on it.
Luckily laws are limited to countries.
Nintendo have successfully killed fan projects before, with cease-and-desist letters.
https://webcache.googleusercontent.com/search?q=cache:B094-P...
https://webcache.googleusercontent.com/search?q=cache:B094-P...
You do know that Square Enix is not Nintendo right?
Oh? See: lobbyists.
IANAL but my understanding is that while practically speaking the war is lost for SNES, corporations have to be seen to be defending their IP (particularly game characters in Nintendo's case) otherwise they run the risk of it becoming public domain in the long term. An example of this is brand names becoming generic names (e.g. dumpster, chapstick, escalator...). The corporations that owned these terms lost control of them because they weren't able to do enough to defend their IP. Since many of their modern titles are reliant on old IP it is vitally important that they retain a grip on it from a legal standpoint.
That’s specific to trademarks which don’t automatically expire. Copyright and patents are mostly enforced via lawsuits, but in theory are in full effect until the clock runs out.
The response was as expected. Nice people, but it wasn't confirmed if they have documentation or not, and I was told that if they do or don't the policy is not to make any of that public.
thanks for all the work you do byuu!
Interesting tangent from the article:
>Today, SNES emulation is in a very good place. Barring unusual peripherals that are resistant to emulation (such as a light-sensor based golf club, an exercise bike, or a dial-up modem used to place real-money bets on live horse races in Japan), every officially licensed SNES title is fully playable
I had to look up the 'dial-up modem' reference - apparently it's a Japan-only peripheral called the "Famicom Network System" that did in fact have software available that allowed for bets to be placed on live horse races.
https://en.wikipedia.org/wiki/Family_Computer_Network_System
http://niwanetwork.org/wiki/JRA-PAT
>Today, SNES emulation is in a very good place. Barring unusual peripherals that are resistant to emulation (such as a light-sensor based golf club, an exercise bike, or a dial-up modem used to place real-money bets on live horse races in Japan), every officially licensed SNES title is fully playable
I had to look up the 'dial-up modem' reference - apparently it's a Japan-only peripheral called the "Famicom Network System" that did in fact have software available that allowed for bets to be placed on live horse races.
https://en.wikipedia.org/wiki/Family_Computer_Network_System
http://niwanetwork.org/wiki/JRA-PAT
A brazilian bank released software for the Mega Drive. Looks like it could display the accounts as well as manage investments and credit cards. Wonder how many people actually used this...
https://segaretro.org/Telebradesco_Residência
https://www.sega-brasil.com.br/Tectoy/Telebradesco_Residenci...
https://www1.folha.uol.com.br/fsp/1995/3/22/dinheiro/26.html
https://segaretro.org/Telebradesco_Residência
https://www.sega-brasil.com.br/Tectoy/Telebradesco_Residenci...
https://www1.folha.uol.com.br/fsp/1995/3/22/dinheiro/26.html
So awesome... I guess someone at that bank tried to pull of a fantastic side-move. It was just 20 years too early, but that guy saw "apps" before Jobs had even returned at Apple!
I wonder what the security solution was, assuming this didn't use SSL/TLS
The security solution was probably that the user had to type the account's PIN, and that it uses the phone line instead of the Internet. It's from 1995 (check the date of the Folha de São Paulo article above), not using encryption at all was very common back then; and even today, phone lines are still considered reliable enough that one can type the account PIN on it without any encryption (for instance: if I want to solve any issue with my credit card through the phone, I must type the full number on the card and the credit card PIN before the URA will connect me to an operator).
Faxes are unencrypted and send medical crap all the time today.
Most fax machines today aren't actually sending faxes - they're sending emails, using SSL.
As someone who works in the telecom industry and has to deal with faxes in medical facilities all the time, no they're not. I fucking wish they were.
I beg people to use e-fax solutions if they insist on using fax at all, but there are so many damn human macros out there who learned how to do something one way and totally break down if you try to make them do something different.
Annoyingly while most modern fax machines are also network printers and support email in both directions, the majority do not provide any way to configure a mapping so that a user can type in a number like a normal fax machine and the machine will convert it to the required email format for an e-fax service. This would be so easy and solve so many problems.
I beg people to use e-fax solutions if they insist on using fax at all, but there are so many damn human macros out there who learned how to do something one way and totally break down if you try to make them do something different.
Annoyingly while most modern fax machines are also network printers and support email in both directions, the majority do not provide any way to configure a mapping so that a user can type in a number like a normal fax machine and the machine will convert it to the required email format for an e-fax service. This would be so easy and solve so many problems.
SSL e-mail isn't ETE though
Yeah, that was my first thought as well. I doubt the 68000 could have done any serious encryption.
I guess many - Sega was uuuuuuge in Brazil. It was almost like a PC.
Interesting. Do you remember the Mega PC?
https://en.wikipedia.org/wiki/Amstrad_Mega_PC
It was a Sega Mega Drive and a PC.
It was a Sega Mega Drive and a PC.
I only learned about it long after
What the heck?!? This is awesome!!!
If this is interesting to you, I recommend this (1) documentary on XBAND, a peripheral used to access an Xbox Live-like service for the Super Nintendo. It's a fascinating piece of engineering for the time.
(1) - https://youtu.be/k_5M-z_RUKA
(1) - https://youtu.be/k_5M-z_RUKA
I rented an XBAND from Blockbuster video in 1995 and it was one of my first “online” experiences outside of using USENET in elementary school. We got a new family computer (a Pentium 90!) with a 14.4 modem and Windows 95 about 6 months later — and that’s what started me on the life I know now. But the XBAND and the article in Nintendo Power about it were an early party of my lifelong love affair with the web.
Nintendo had dial up modems and their own intranet in 37% of Japanese households in the mid 80s? How did I not know this was a thing.
>Nintendo had dial up modems and their own intranet in 37% of Japanese households in the mid 80s?
That Wikipedia link says that the Famicom (NES) was in 37% of households. Nintendo only shipped 130,000 modems, a tiny percentage of the total Famicom units sold.
That Wikipedia link says that the Famicom (NES) was in 37% of households. Nintendo only shipped 130,000 modems, a tiny percentage of the total Famicom units sold.
SNES was 90s iirc?
Yes, I believe it was, but this peripheral and the software was (unless I read or interpreted incorrectly) designed for the original NES.
(There is a note that there were remakes of the horse race betting software for SNES and Dreamcast)
(There is a note that there were remakes of the horse race betting software for SNES and Dreamcast)
Not the Famicom according to GPs wiki.
I imagine that these could still be emulatable in software, right? I.e. you could simulate whatever data the golf club was generating and pipe it into the emulator, such that you could play that golf game with a Wiimote or some other peripheral.
Similarly you could have some shim code for the online games like the horse race one that talks to some community run server, re-enabling a new kind of net experience.
Similarly you could have some shim code for the online games like the horse race one that talks to some community run server, re-enabling a new kind of net experience.
You can to varying degrees, yes. There's a barcode scanner, an exercise bike, a baseball bat, and more. I designed higan around a modular tree structure so that you can just create a new derived node for any peripheral, and define whatever API you like, so that we can emulate the protocol. Then it's up to the GUI to figure out how to do something when it sees Node::ExerciseBike, and how to do I/O with its API interface.
One could imagine, for instance, connecting an actual USB barcode reader to emulate the Barcode Battler, or providing a text box to hand-type a barcode number.
I don't see anyone actually bothering to simulate the entire horse betting network complete with virtual bank accounts, but if you're really interested, Raphael Assenat reverse engineered quite a bit of the JRA-PAT system for fun here:
https://www.raphnet.net/divers/retro_challenge_2018_09/index...
It's a pretty good read as well!
One could imagine, for instance, connecting an actual USB barcode reader to emulate the Barcode Battler, or providing a text box to hand-type a barcode number.
I don't see anyone actually bothering to simulate the entire horse betting network complete with virtual bank accounts, but if you're really interested, Raphael Assenat reverse engineered quite a bit of the JRA-PAT system for fun here:
https://www.raphnet.net/divers/retro_challenge_2018_09/index...
It's a pretty good read as well!
They also had a Satellite service (Satellaview) where they delivered a 4 episode Zelda Game that could only be playing during certain hours.
https://zelda.gamepedia.com/BS_The_Legend_of_Zelda:_Ancient_...
https://en.wikipedia.org/wiki/Satellaview_games_from_The_Leg...
https://zelda.gamepedia.com/BS_The_Legend_of_Zelda:_Ancient_...
https://en.wikipedia.org/wiki/Satellaview_games_from_The_Leg...
This can actually be played today, with the FM sound track, all translated into English
https://bszelda.zeldalegends.net/bs1files.shtml
https://bszelda.zeldalegends.net/bs1files.shtml
For those curious, here it is in action:
https://m.youtube.com/watch?v=wtMlEcf8x6Q
The linked story about Higan's NEC uPD772x emulation being used by Stephen Hawking is pretty amazing, both as a story in its own right and as a parable about the value of open source and code getting used in wildly different contexts from what it was originally designed for: https://www.sfchronicle.com/bayarea/article/The-Silicon-Vall...
It's sad that Nintendo doesn't seem to see this as an opportunity to earn free press and goodwill by simply releasing all the design documents, mask images, etc.
The community is going to get there eventually without their help, but they could probably make it much faster and cheaper to get there.
Doubly so because they sell products which almost certainly benefit from these open source emulation efforts.
The community is going to get there eventually without their help, but they could probably make it much faster and cheaper to get there.
Doubly so because they sell products which almost certainly benefit from these open source emulation efforts.
Nintendo is still actively selling SNES games via Nintendo Switch Online, and as far as I know rolls their own emulator(s) for this rather than using existing open source ones as Sony did for the PS Classic, so I doubt this will happen any time soon.
Tangentially related, there's some evidence the ROMs Nintendo was selling a couple years ago were ones they downloaded. Not bulletproof, but more likely than not.
https://www.eurogamer.net/articles/2017-01-18-did-nintendo-d...
https://www.eurogamer.net/articles/2017-01-18-did-nintendo-d...
I can almost guarantee Nintendo did not use a downloaded ROM. I don’t have direct experience with how the ROMs are sourced, so it’s not 100%, but I worked on a team handling emulation at Nintendo and can say the processes are incredibly careful and strict.
The company is extremely micromanaged and pedantic, and this is not the kind of thing that could possibly be overlooked at Nintendo.
The company is extremely micromanaged and pedantic, and this is not the kind of thing that could possibly be overlooked at Nintendo.
It's just weird then that they put a header originally defined by pirates, and now otherwise only used by third party emulators. Including matching the even more informal parts of the header byte for byte with the most common dump of the ROM on the high seas.
> ...a header originally defined by pirates...
Specifically, the "iNES header", originally created by Marat Fayzullin for use with his NES emulator, iNES[1].
If you look at the iNES manual[2], way down at the bottom in the changelog for version 0.7, you can see "Sound support completely rewritten, thanks to Kawase Tomohiro".
If you search the Internet for Kawase Tomohiro, you'll find[3] somebody by that name seems to work for Nintendo as a programmer, and in particular worked on the NES emulator used in 2001's Animal Crossing.
Of course, that's not conclusive evidence, but given the competing claims "Nintendo, a notoriously uptight company, has been downloading pirate ROMs to sell" versus "Nintendo hired a pioneer of NES emulation to work on their emulators, who kept using the tools and formats he was used to", I feel like one is more likely to be true and the other is more likely to get ad impressions.
[1]: https://fms.komkon.org/iNES/
[2]: https://fms.komkon.org/iNES/iNES.html
[3]: https://nintendo.fandom.com/wiki/Tomohiro_Kawase
Specifically, the "iNES header", originally created by Marat Fayzullin for use with his NES emulator, iNES[1].
If you look at the iNES manual[2], way down at the bottom in the changelog for version 0.7, you can see "Sound support completely rewritten, thanks to Kawase Tomohiro".
If you search the Internet for Kawase Tomohiro, you'll find[3] somebody by that name seems to work for Nintendo as a programmer, and in particular worked on the NES emulator used in 2001's Animal Crossing.
Of course, that's not conclusive evidence, but given the competing claims "Nintendo, a notoriously uptight company, has been downloading pirate ROMs to sell" versus "Nintendo hired a pioneer of NES emulation to work on their emulators, who kept using the tools and formats he was used to", I feel like one is more likely to be true and the other is more likely to get ad impressions.
[1]: https://fms.komkon.org/iNES/
[2]: https://fms.komkon.org/iNES/iNES.html
[3]: https://nintendo.fandom.com/wiki/Tomohiro_Kawase
It isn't wrong for Nintendo to use the same file format as other emulators, although it is hypocritical. (But including such improper stuff as "DiskDude" (which the emulator doesn't even use, and doesn't properly belong in the header anyways) is a bit wrong, and is even more hypocritical.)
I mean, you'd want to use a file format that would allow you to cross-test your emulator's behavior on the same ROM files against existing emulators' behavior on those ROM files. So you'd format your ROMs (which you dumped yourself) the way that existing emulators would expect them to be formatted.
Sorry, I was being a bit coy when I said the "more informal parts of the header". It literally still has the dumper's signature in the unused portion of the header. Traceability as to who gets props for the first good dump drives a lot of decisions in that scene.
Could you be more specific? I've heard this mentioned before but not seen an example. Something like one of those Diskdude! strings? What game?
http://wiki.nesdev.com/w/index.php/INES#Flags_10:
> Older versions of the iNES emulator ignored bytes 7-15, and several ROM management tools wrote messages in there. Commonly, these will be filled with "DiskDude!", which results in 64 being added to the mapper number.
> Older versions of the iNES emulator ignored bytes 7-15, and several ROM management tools wrote messages in there. Commonly, these will be filled with "DiskDude!", which results in 64 being added to the mapper number.
That would surely be a giveaway, but I haven't seen any evidence that tagged headers like this were actually used in official Nintendo releases.
What other explanation would there be for those headers? They serve no purpose otherwise.
The other explanation is that they're using an open-source emulator (or some derivative thereof) in their product, so the iNES header would be the expected format to convey the necessary information.
It's commonplace for original arcade and console game manufacturers to download ROMs from a ROM site and then send a C&D to that same site ordering it shut down. The company owns the rights to the ROM in the first place, and thus are the only party legally entitled to download it. Sure beats the cost of dumping it from an old cartridge themselves. (And no, for old video games there's no source repository. The original sources may be lost.)
Lol, well they don't own the copyright of the header added by the original dumper in that case.
The header likely does not contain enough creative content to even be covered by copyright.
Seriously[1]? This supposed lack of "creative content" has become the de facto standard in the domain.
[1] https://wiki.nesdev.com/w/index.php/INES
[1] https://wiki.nesdev.com/w/index.php/INES
Thats 16 bytes of data, not nearly enough to be covered by copyright. Its not about how important it is. Like how a single line slogan isn't copyrightable even if its unique and clever, they can be covered by trademarks however. I doubt a 16 byte header could be covered by trademarks either.
> Thats 16 bytes of data, not nearly enough to be covered by copyright
Gee. Maybe they should've put it in the form of a haiku? :)
Gee. Maybe they should've put it in the form of a haiku? :)
"16 bytes of data" is also the size of an AES-256 key, which is apparently able to be copyrighted.
This is nonsense. An encryption key can never be copyrighted, it's only illegal to redistribute it because it's a circumvention device under the DMCA, and possibly illegal under the CFAA, not because it's copyrighted.
What's your source on that? Doesn't seem likely to me.
https://en.wikipedia.org/wiki/AACS_encryption_key_controvers...
I wish people would point that out more often when there's discussion around backdooring systems to allow for government surveillance. With how quickly keys got out for HDDVD and Blu-ray, there's no reason to thing something similar wouldn't happen with a government backdoor, and that's if it's not for sale on the dark web before it goes public.
I wish people would point that out more often when there's discussion around backdooring systems to allow for government surveillance. With how quickly keys got out for HDDVD and Blu-ray, there's no reason to thing something similar wouldn't happen with a government backdoor, and that's if it's not for sale on the dark web before it goes public.
> https://en.wikipedia.org/wiki/AACS_encryption_key_controvers...
Actually refutes your claim that an AES key can itself be covered by copyright.
The given reason to attempt to have it removed was not that copying the key itself violates copyright, but that it was used to circumvent copyright-protection mechanisms.
Actually refutes your claim that an AES key can itself be covered by copyright.
The given reason to attempt to have it removed was not that copying the key itself violates copyright, but that it was used to circumvent copyright-protection mechanisms.
yeah, but it gives the opportunity for the parent company of the source material to redistribute something without meaning to.
header-bourne SNES malware? Probably not, but one can dream.
header-bourne SNES malware? Probably not, but one can dream.
Random anecdote. For Turner's GameTap, a sort of subscription-based library of games for many different platforms from around 15 years ago, they absolutely were using downloaded ROMs. Worse, they were unable to find clean ROMs for several games, and several of the versions that were used had Demoscene cracktros added in. They got around the problem by just playing through the cracktro, saving the state, and loading that state when a player loaded the game.
The level of perfection being sought in this article is essentially irrelevant to competition with emulators + illicit copying.
The existing emulators are more than good enough to be replacements to the commercial offerings (and in most cases, a lot better... e.g. the lookahead rendering).
While what you suggest might be a factor in their actions, I don't think it's an especially good one.
As far as rolling their own emulators, I don't doubt that they do. But I do doubt that they're doing so without researching the existing open source emulators.
The existing emulators are more than good enough to be replacements to the commercial offerings (and in most cases, a lot better... e.g. the lookahead rendering).
While what you suggest might be a factor in their actions, I don't think it's an especially good one.
As far as rolling their own emulators, I don't doubt that they do. But I do doubt that they're doing so without researching the existing open source emulators.
> using existing open source ones as Sony did for the PS Classic
That’s interesting, I wonder if that is the case the for the PS1 emulator on the PS3/Vita used for the PlayStation Classics titles
That’s interesting, I wonder if that is the case the for the PS1 emulator on the PS3/Vita used for the PlayStation Classics titles
I think that's a proprietary in-house emulator known as POPS. The fact that Sony already had an in-house PlayStation emulator for the ARM-based Vita makes their decision to use something else for the PS Classic a bit strange.
I imagine some third party approached Sony with a "we'll do the work, take the risk, etc. You just give your blessing, tell us who do we need to contact for final approval to make sure the brand is being well represented, and where to send the royalty checks" kind of deal.
Whilst the vita was an arm based system, it also included almost all of the psp hardware for backwards compatability.
They simply reused pops from the psp, with no major changes, so it still ran on a mips system.
They simply reused pops from the psp, with no major changes, so it still ran on a mips system.
This is also how the PSP runs PS1 games - by essentially being a PS1 and loading the game data from UMD or Memorystick.
"Nintendo ... rolls their own emulator(s) ... rather than using existing open source ones"
Wouldn't it be possible to reverse engineer these emulators? Maybe the official Nintendo SNES emulator has all the right S-PPU1/2 values in it.
Wouldn't it be possible to reverse engineer these emulators? Maybe the official Nintendo SNES emulator has all the right S-PPU1/2 values in it.
Doubtful. Byuu’s emulator is already much more accurate than Nintendo’s own.
What's sad is they don't just release the entire SNES/NES library for people who buy into their Nintendo online service. It's shameful how they've treated people who have bought and rebought into previous iterations only to have their libraries wiped out with new hardware generations. I'm looking at you virtual console.
What's truly shameful is the fact these 30+ year old games are still protected by copyright. Nintendo and all the third party developers have already made their money many times over. It's time for these works to enter the public domain.
I personally dislike the fact that copyright is tied to the person rather than the release year. It results in a lot of ugly compromises in copyright. The idea behind authors life + 70 years is that you don't want to discourage old people but if copyright was based on the release date none of this would matter.
70 years is way too much. It should be something like 10 years. The idea is to give creators appropriate reward and then release works into the public domain. 10 years is more than enough time to make a fortune off of one's creations. They should have to invent new stuff if they want more money.
What happens today is creators want to strike gold once and then enjoy a lifetime of royalties for themselves and their children. When was the last time something entered the public domain? Probably in the early 20th century. Public domain might as well be a forgotten footnote of history. There's no reason for the public to recognize copyright as legitimate when it's being systematically robbed of its rights.
What if the copyright is owned by a company? I don't know. Do they have to go bankrupt for the 70 year count to start? In any case, they'll probably just lobby for even more extensions before their terms run out anyway.
What happens today is creators want to strike gold once and then enjoy a lifetime of royalties for themselves and their children. When was the last time something entered the public domain? Probably in the early 20th century. Public domain might as well be a forgotten footnote of history. There's no reason for the public to recognize copyright as legitimate when it's being systematically robbed of its rights.
What if the copyright is owned by a company? I don't know. Do they have to go bankrupt for the 70 year count to start? In any case, they'll probably just lobby for even more extensions before their terms run out anyway.
Also, none of these companies would even be able to sell old games if it weren't for amazing developers writing the emulators (and people playing pirated games on them). All these games would be lost forever.
They don't have rights to the entire library, but yeah, just release everything you own on there at once and move on to ironing out N64.
It's not just about what they own; it's also about what they think they can get away with bundling into "collections" alongside spiritual sequels/HD remasters/etc. (S)NES Online is just for everything left over after the other departments slice the IP up for remixing.
And then they don't seem to have any real sense of urgency at actually making those collections. Earthbound is obviously missing so they can do a big bundle collection, but also their not confident enough in it to put the resources into translating Mother 3.
And so the final, most extreme approach, would be to expand upon our decapping efforts. We have 20x die scans, but the resolution is not enough to make out and reconstruct individual logic circuits from them, such as was done with the Visual 6502 project.
That was done with the NES too:
https://github.com/SourMesen/VisualNes
That was done with the NES too:
https://github.com/SourMesen/VisualNes
> It combines both simulators into a single simulation and allows the simulation to run NES roms (albeit at roughly 1/1000th of the speed of a real NES)
What is this emulator doing that causes it to emulate so slowly? Even if it's doing perfect emulation, are modern processors still so slow that they can't emulate a couple 35-year-old processors at something closer to real time?
What is this emulator doing that causes it to emulate so slowly? Even if it's doing perfect emulation, are modern processors still so slow that they can't emulate a couple 35-year-old processors at something closer to real time?
Visual 6502 emulates the CPU not just at a logical level (performing equivalent instructions) but at a silicon level, simulating each transistor in the original chip at an electrical level as closely and as accurately as possible. This is far more intensive, as there's a whole bunch of state to maintain and thousands upon thousands of tiny components that need to remain in perfect sync. Of course the goal here is not to run the processor at anything resembling real-time speeds. Quite the opposite; the developers have created a marvelous way to slow down the components so that humans can observe each tiny step, which normally takes a fraction of a fraction of a fraction of a second on the physical chip.
[deleted]
[deleted]
Would using die scans start to run into copyright issues?
There are special copyright laws for chips. In the US, it only lasts 10 years.
https://en.wikipedia.org/wiki/Integrated_circuit_layout_desi...
https://en.wikipedia.org/wiki/Integrated_circuit_layout_desi...
I haven’t heard about this, thank you for the link!
If you found this interesting, the author's website has a number of informative, in-depth articles about emulator development & console architectures: https://byuu.net/
I just want to say that some of the most fun I’ve ever had on the PC has been in a SNES emulator. The sheer variety, depth, hours of content, ease of accessibility, and great music has been nearly unmatched on most other platforms.
I highly recommend anyone with an interest in games to grab a bunch of ROM packs (including Japanese exclusive games and fan translation hacks) and spend some of your quarantine on the SNES.
I highly recommend anyone with an interest in games to grab a bunch of ROM packs (including Japanese exclusive games and fan translation hacks) and spend some of your quarantine on the SNES.
SNES graphics has aged really well! I introduced my kids to NES and SNES through emulators, and while they played Super Mario Bros on NES, they really liked Super Mario World, Super Tennis, and Clay Fighter on SNES.
I'd like to get them to play A Link to the Past and Chrono Trigger, but I don't think that they're patient enough. Still, beautiful games with great soundtracks.
I'd like to get them to play A Link to the Past and Chrono Trigger, but I don't think that they're patient enough. Still, beautiful games with great soundtracks.
> SNES graphics has aged really well!
Exactly! and even more so with the filters in modern emulators. Along with the funky cool music, many SNES games are easily on par in the looks department with most mobile games, so kids won't be turned off by the first impression or anything.
If you have kids sitting bored at home, consider repurpos an extra/older PC or Mac [0] as a pseudo-console + emulator for the SNES (and other platforms).
[0] http://openemu.org
Exactly! and even more so with the filters in modern emulators. Along with the funky cool music, many SNES games are easily on par in the looks department with most mobile games, so kids won't be turned off by the first impression or anything.
If you have kids sitting bored at home, consider repurpos an extra/older PC or Mac [0] as a pseudo-console + emulator for the SNES (and other platforms).
[0] http://openemu.org
Especially Chrono Trigger! That game is amazing!
Chrono Trigger will always be one of my all-time favorite stories on any medium.
A few other SNES recommendations from the top of my head:
• EarthBound (aka Mother 2, another popular RPG with fun music. Combat may feel too grindy/frustrating though)
• Super Gussun Oyoyo (Lemmings + Tetris)
• Live A Live (RPG where you play characters from multiple timelines)
• Pop'n TwinBee (shoot-em-up and platformer with very colorful graphics in a pastelly palette)
• Terranigma (RPG spanning multiple eras)
• Treasure of the Rudras (Japan-only RPG with fan translation)
• Bomberman (hilarious couch PvP)
• Pocky & Rocky (cute shoot-em-up with a Japanese folklore theme)
• Yoshi's Island (one of the best platformers)
There were a bunch of other obscure titles with unique gameplay mechanics that I can't recall the names of at the moment. Will have to comb my ROMs folder.
A few other SNES recommendations from the top of my head:
• EarthBound (aka Mother 2, another popular RPG with fun music. Combat may feel too grindy/frustrating though)
• Super Gussun Oyoyo (Lemmings + Tetris)
• Live A Live (RPG where you play characters from multiple timelines)
• Pop'n TwinBee (shoot-em-up and platformer with very colorful graphics in a pastelly palette)
• Terranigma (RPG spanning multiple eras)
• Treasure of the Rudras (Japan-only RPG with fan translation)
• Bomberman (hilarious couch PvP)
• Pocky & Rocky (cute shoot-em-up with a Japanese folklore theme)
• Yoshi's Island (one of the best platformers)
There were a bunch of other obscure titles with unique gameplay mechanics that I can't recall the names of at the moment. Will have to comb my ROMs folder.
I really want it on the Switch! I played the emulated version on PC, and I know it's now available on both Steam (I heard that they fixed the broken early version) and mobile, but it would be very convenient to have it on the Switch. I read that due to licensing it's unlikely to show up in SNES Online, but I don't see why they don't release it as a separate game.
They don't need to remaster or remake anything, just release it as is, and I'm sure it would sell well. I would anyway prefer the original with original graphics and soundtrack to a 3D remake or similar.
They don't need to remaster or remake anything, just release it as is, and I'm sure it would sell well. I would anyway prefer the original with original graphics and soundtrack to a 3D remake or similar.
The DS version is an excellent port - much better than the Final Fantasy ports to the GBA, because they didn't have to compromise on the resolution. It's selling for about $55 now.
(Yes, I know this is quite different than having it on the Switch, but I mentioned it in case you have a DS and wasn't aware.)
(Yes, I know this is quite different than having it on the Switch, but I mentioned it in case you have a DS and wasn't aware.)
On the last extreme idea, it seems one thing to do for starters is to get the 100x magnification of the PPUs from someone and put it in the GitHub repo.
Then anyone who has the ability to start converting that to VHDL or any sort of identification of components can start on part of it and contribute to the repo.
With some started, it may be possible for less expert people who have a little bit of VHDL or whatever to contribute to some degree with expert supervision.
Then anyone who has the ability to start converting that to VHDL or any sort of identification of components can start on part of it and contribute to the repo.
With some started, it may be possible for less expert people who have a little bit of VHDL or whatever to contribute to some degree with expert supervision.
Admiration to those people like byuu write emulators with their devotion, if without them, we have no today's splendid retro culture.
Is there any SNES emulator that runs on arm?
I've got retroarch v1.3.6 on Stretch on aarch64. It has crashed with a "file not found" and "bus error" for bsnes. Higan segfaults when I try to run it.
I've got retroarch v1.3.6 on Stretch on aarch64. It has crashed with a "file not found" and "bus error" for bsnes. Higan segfaults when I try to run it.
Not helpful to you except as an existence proof, but you can install Retropie on a Raspberry Pi and it will play SNES ROMs fine. I believe the emulator is a variant of SNES9x.
retropie runs fine on some arm platforms. you can also use lakka. However the latest retroarch is 1.8.5, while the 1.3.6 version is from 2016, I would imagine nothing would work on Stretch, so I recommend an upgrade or any OS that isn't debian. If in doubt, gentoo always works, though its source based.
https://retropie.org.uk/ http://www.lakka.tv/
https://retropie.org.uk/ http://www.lakka.tv/
I've been running it on a Fire stick 4k but in 32 bit mode
Error in the article: 32x32bit multiply (i.e. 2^64 bits) is not a "heat death of the universe" thing.
It's a lot, yes. Not practical for these purposes. But there's a reason we don't use 64bit encryption.
64bit encryption is easily brute forced.
If you want to keep it in a table, sure that's 18 exabytes (multiplied by element size in bytes), but that's before compression. I imagine multiply output compresses very well. And that's a lot of RAM. But not anywhere near "heat death of the universe" amounts.
I bet FAANG easily have that much RAM. Each of them.
It's a lot, yes. Not practical for these purposes. But there's a reason we don't use 64bit encryption.
64bit encryption is easily brute forced.
If you want to keep it in a table, sure that's 18 exabytes (multiplied by element size in bytes), but that's before compression. I imagine multiply output compresses very well. And that's a lot of RAM. But not anywhere near "heat death of the universe" amounts.
I bet FAANG easily have that much RAM. Each of them.
Has Nintendo released officially, or leaked, the RTL for any of the processors in the SNES? If someone could get their hands on that, then the emulation authors should be able to achieve perfection.
Looks like some people are trying to re-create it at least. https://github.com/srg320/FpgaSnes
AFAIK chips from this era were designed and layed out by hand, rather than with an HDL.
I'm sure that I was playing Zelda Link to the Past and Super Metroid without any problems about 20 years ago. What's changed since then? I thought this was already solved :) apologies for my ignorance
Nintendo Switch Online subscription includes an "official" SNES emulator. How does it compare to BSNES, and would a decompilation of the emulator help with resolving the PPU issues?
Nintendo's emulators are usually equivalent to what the state of the art was 15-20 years ago. They have plenty of bugs, usually fixed with duct tape and game specific hacks. They are designed to run the set of games they sell and nothing else -- once you get out of what the QA team has explicitly tested, it's not uncommon to find unemulated or badly emulated hardware features.
Also, when you think about it, if a game behaves differently when run in an emulator, as part of an emulator-and-ROM bundled software product released by Nintendo... then that behavior is just how that particular release of the game has been canonically chosen to behave. Any bugs in the emulation of a Virtual Console title, or a SNES Classic title, or a SNES Online title, are just "how that version of the game is." Much like any typos in a particular printing of a book are "just how that release of the book is." They're now part of the authorial intent of that release; part of the text. If you later ported that game, you'd seek to be bug-for-bug compatible with the bugs introduced by that emulator, because those bugs are what Nintendo released, and so those bugs are now, in part, what it means to play that game.
Or, to put that another way: there's no real difference between a bug introduced by wrapping a game in an imperfect emulator, and a bug introduced during recompilation/porting/remastering of the game. Either way, you now have a new "variant" of the game with its own bugs, but one which is also a canonical, supported release of the game.
Interestingly, sometimes—because of one of these slight variances—the fastest [and so preferred] version of a game to speedrun, is a Nintendo-sanctioned emulated (e.g. Virtual Console) release of the game. It says something important, I think, that these releases of the game aren't automatically shunned by the speedrunning community, the way that runs of the game under an arbitrary emulator on someone's PC would be; but rather are just treated as their own separate category-set, in the same way the speedrunning community differentiates different region releases, or version releases, or port/remaster releases.
Or, to put that another way: there's no real difference between a bug introduced by wrapping a game in an imperfect emulator, and a bug introduced during recompilation/porting/remastering of the game. Either way, you now have a new "variant" of the game with its own bugs, but one which is also a canonical, supported release of the game.
Interestingly, sometimes—because of one of these slight variances—the fastest [and so preferred] version of a game to speedrun, is a Nintendo-sanctioned emulated (e.g. Virtual Console) release of the game. It says something important, I think, that these releases of the game aren't automatically shunned by the speedrunning community, the way that runs of the game under an arbitrary emulator on someone's PC would be; but rather are just treated as their own separate category-set, in the same way the speedrunning community differentiates different region releases, or version releases, or port/remaster releases.
> Interestingly, sometimes—because of one of these slight variances—the fastest [and so preferred] version of a game to speedrun, is a Nintendo-sanctioned emulated (e.g. Virtual Console) release of the game.
Not that that necessarily has anything to do with bugs. Some VC games simply have reduced lag when a lot is loaded, because they throw somewhat more power at the game than the original console could.
Not that that necessarily has anything to do with bugs. Some VC games simply have reduced lag when a lot is loaded, because they throw somewhat more power at the game than the original console could.
Sure, definitely.
One more interesting difference, that you'll see with N64 games specifically (e.g. VC Paper Mario on the Wii) is that the original console will hard-lock in places where the VC version will just keep on truckin' (presumably because it has access to more memory, or the emulator just discards crazy out-of-bounds writes, or because the emulator treats open-bus address reads differently. Something like that.)
Anyway, that means that there are glitches that can be used save time on the VC version, which in some sense don't exist at all on the original version of the game, because they're gated behind a fault that the original hardware can't get past.
One more interesting difference, that you'll see with N64 games specifically (e.g. VC Paper Mario on the Wii) is that the original console will hard-lock in places where the VC version will just keep on truckin' (presumably because it has access to more memory, or the emulator just discards crazy out-of-bounds writes, or because the emulator treats open-bus address reads differently. Something like that.)
Anyway, that means that there are glitches that can be used save time on the VC version, which in some sense don't exist at all on the original version of the game, because they're gated behind a fault that the original hardware can't get past.
I don’t agree. Canonical status is bestowed by the artist/author, not the publisher, and certainly not a republisher. If Lord of the Rings is republished with page 527 arbitrarily missing, that omission doesn’t become canon.
Yes but if there was a second edition released by Tolkien, that would be canon. There could have been changes in page 527, such as Sam and Frodo run away to start a domestic life together, and it would be official. It would also cause quite a stirring and fracture the community. You see smaller scale scandals of the same variety everytime nintendo rereleases a poorly emulated title. Copyright needs to be fixed.
Canon is whatever your heart (or in the case of roms, the speedrunning community) declares it to be. I'd previously be arguing for authorial intent, but JK Rowling ruined it for everyone.
I agree that the community decides on what is canon. However, I don't think anything can become canon. Fanfiction will always be splintered from canon until it gets adopted and published by the IP owners. So, "Goat Simulator" speedruns will always be performed on a version released by Coffee Stain Studios, or whoever owns the game in the future. You could rip up the source code, mod the game, whatever, and do speedruns. If it's popular then it's a new category, but it won't be a "Goat Simulator" speedrun, it will be a "Goat Simulator++" speedrun. What official version of the game the community decides to use for the "Goat Simulator" category can be contentious, as the developer could have a range of releases that change things significantly. Just look at half life 2. The most popular category is the release version of the game because you can fly around at mach 1.
Maybe if you're just a fan, sure. But there is a very strong and explicit meaning to "the canonical work" when you're doing archival/conservatorial work. There's what the artist created (as seen through the lens of how it was first released/shown, which certainly might involve a publisher or curator—thus the concept of a "director's cut"); and then there's what previous middle-men (curators, other conservators, republishers who acquired the rights after the creator's death, etc.) tacked on after that initial release.
You'll see the effect of this in gaming in the forms of e.g.:
• The https://www.no-intro.org project, whose goal is to curate a database of hashes of "canonical ROMs" (i.e. ones that are don't have demoscene "intro" greetz; but also which don't have the extra headers that some copiers add; and, obviously, which aren't bad dumps.)
• The policies of some emulators (e.g. MAME, Higan) to replace, whenever possible, High-Level Emulation code that "works perfectly" (i.e. matches console output on every frame for every known software title!) with Low-Level Emulation, which requires a BIOS/firmware dump of a chip to run. The goal in these types of fixes isn't to run existing games, but rather to make the emulator match the behavior of the hardware for running even novel or previously undiscovered games, such that it can be a useful tool in future conservation efforts, when the original hardware is long gone.
• The file-formats of some emulators (again: MAME, Higan) which keep individually-dumped coprocessor ROMs as separate files in a software title's archive file/folder, each with their own metadata; rather than inventing custom merged-binary file-formats for each system. This both allows future archivists to easily re-verify that individual dumps are correct; to replace bad dumps with better ones without invalidating the hashes for other ROMs that make up the same software title; and, in theory, this provides a (coincidentally machine-executable) schematic of the software-title-as-hardware-system, which could be used to reconstruct it wholesale in a future where all existing hardware was lost.
• The transition from the archivists at Archive.org preferring to see Apple II disk images in raw bit-dump (DSK) file-format, to wanting them as flux-trace (https://applesaucefdc.com/woz/) files, which in turn means that copy-protected games can now be preserved in their original, copy-protected state, rather than first needing to be cracked.
You'll see the effect of this in gaming in the forms of e.g.:
• The https://www.no-intro.org project, whose goal is to curate a database of hashes of "canonical ROMs" (i.e. ones that are don't have demoscene "intro" greetz; but also which don't have the extra headers that some copiers add; and, obviously, which aren't bad dumps.)
• The policies of some emulators (e.g. MAME, Higan) to replace, whenever possible, High-Level Emulation code that "works perfectly" (i.e. matches console output on every frame for every known software title!) with Low-Level Emulation, which requires a BIOS/firmware dump of a chip to run. The goal in these types of fixes isn't to run existing games, but rather to make the emulator match the behavior of the hardware for running even novel or previously undiscovered games, such that it can be a useful tool in future conservation efforts, when the original hardware is long gone.
• The file-formats of some emulators (again: MAME, Higan) which keep individually-dumped coprocessor ROMs as separate files in a software title's archive file/folder, each with their own metadata; rather than inventing custom merged-binary file-formats for each system. This both allows future archivists to easily re-verify that individual dumps are correct; to replace bad dumps with better ones without invalidating the hashes for other ROMs that make up the same software title; and, in theory, this provides a (coincidentally machine-executable) schematic of the software-title-as-hardware-system, which could be used to reconstruct it wholesale in a future where all existing hardware was lost.
• The transition from the archivists at Archive.org preferring to see Apple II disk images in raw bit-dump (DSK) file-format, to wanting them as flux-trace (https://applesaucefdc.com/woz/) files, which in turn means that copy-protected games can now be preserved in their original, copy-protected state, rather than first needing to be cracked.
I don't understand this reply—it doesn't disagree with anything I said. If Tolkien publishes intentional changes, they are some form of canon, even if it's of the "Han shot first" variety. Tolkien changing the words on page 527 is new canon.
If the publisher modifies the work particularly in a manner devoid of creative intent—such as unintentionally omitting page 527—the modification cannot possibly be considered canonical. Imperfections in an emulator are not the work of the original author and they're certainly not any form of artistic intent.
If the publisher modifies the work particularly in a manner devoid of creative intent—such as unintentionally omitting page 527—the modification cannot possibly be considered canonical. Imperfections in an emulator are not the work of the original author and they're certainly not any form of artistic intent.
I think the parent is applying Death of the Author here, implying that what we should make of a work is separate from whatever the author is. After all, Takashi Tezuka doesn't provide any commentary on what Goombas are; although English-speaking manual writers might.
While all of Nintendo's official emulators are afaik made internally, it's interesting to note that Sony used an existing open source emulator (PCSX ReARMed) for their Playstation Classic.
https://arstechnica.com/gaming/2018/11/sony-using-open-sourc...
https://arstechnica.com/gaming/2018/11/sony-using-open-sourc...
> While all of Nintendo's official emulators are afaik made internally
I believe the consensus is that the NES classics on GBA were done using an open source emulator. The emulator itself was liberally licensed and I think someone asked the author's thoughts and they were 'ya, that's half the purpose of the license. i don't care'
I believe the consensus is that the NES classics on GBA were done using an open source emulator. The emulator itself was liberally licensed and I think someone asked the author's thoughts and they were 'ya, that's half the purpose of the license. i don't care'
[deleted]
[deleted]
Can original SNES hardware play ROMs somehow?
Yes! These are called flash carts (short for cartridge). Here is a popular one for SNES: https://www.amazon.com/dp/B0052URJKM
Many people who stream older console games on twitch seem to use them as well as people who like to play romhacks.
Many people who stream older console games on twitch seem to use them as well as people who like to play romhacks.
Back when SNES was still current and flash memory chips were still relatively small and expensive, there were "copiers", which a few SNES enthusiasts still collect just like other vintage peripherals. These are larger devices that contain a floppy drive, DRAM, save RAM, and the necessary logic to provide the most common cartridge mappings. You would dump a cartridge to floppies and then load it into the DRAM to play it. Well-known models include the Game Doctor SF7 and Super Wild Card DX2.
Also nintendo just straight up sold people carts you could flash with new games at Seven-Eleven: https://en.wikipedia.org/wiki/Nintendo_Power_(cartridge)
If you’ve gone to a pop culture convention in the past few years you will also see reproduction cartridges (repro carts). The first one I saw was a legend of zelda ocarina of time master quest N64 cart, but there are new NES and SNES games that are being written from scratch and sold on repro carts.
This wasn’t possible for N64 titles until relatively recently[1]. Interestingly, the method of cracking N64’s boot security sounds rather standard when compared to the 3DS and switch glitching[2][3].
1. https://youtu.be/z5uOK0nR934
2. https://youtu.be/CzVZgdkzBn8
3. https://youtu.be/Ec4NgWRE8ik
This wasn’t possible for N64 titles until relatively recently[1]. Interestingly, the method of cracking N64’s boot security sounds rather standard when compared to the 3DS and switch glitching[2][3].
1. https://youtu.be/z5uOK0nR934
2. https://youtu.be/CzVZgdkzBn8
3. https://youtu.be/Ec4NgWRE8ik
Yes. Nowadays, you'd use an Everdrive.
https://gamesconnection.co.uk/blogs/games-connection/what-is...
In the past, even when the console was still on sale, there were game backup devices.
https://en.wikipedia.org/wiki/Game_backup_device
https://gamesconnection.co.uk/blogs/games-connection/what-is...
In the past, even when the console was still on sale, there were game backup devices.
https://en.wikipedia.org/wiki/Game_backup_device
Worth mentioning: https://news.ycombinator.com/item?id=11639919
It is interesting to me how some systems are easier to emulate than others, and the ease of emulation seems to correlate somewhat with ease of programming model. The infamous example which comes to mind even far beyond the SNES is of course the Sega Saturn, while on the other end of the spectrum, Dolphin has support for multiple consoles at once.
Counting the GameCube and the Wii as two consoles is kind of cheating, the Wii is barely more than an overclocked GameCube with an irrelevant OS running on the side exposing some I/O through a fairly well defined I/O interface. The hardest part of emulating a Wii is emulating a GameCube.
Dolphin is also nowhere close to the accuracy of emulators like bsnes. There are many games that plain don't boot, mysterious bugs that have resisted debugging for years and years (some game breaking, e.g. if you have too many characters unlocked you cannot finish Fire Emblem Radiant Dawn on Dolphin), etc.
Dolphin is also nowhere close to the accuracy of emulators like bsnes. There are many games that plain don't boot, mysterious bugs that have resisted debugging for years and years (some game breaking, e.g. if you have too many characters unlocked you cannot finish Fire Emblem Radiant Dawn on Dolphin), etc.
Dolphin has support for two consoles: Gamecube and Wii. It supports both of them because the architectures are extremely similar. I don't get what you mean by "ease of programming model". Saturn/Playstation/N64 were the first to have games programmed primarily in C with libraries provided by the system developers. This generation is harder to emulate simply because the system architectures contain more chips connected with wider buses running at much higher clock speeds. All of those factors make low level analysis, like with a logic analyzer, impractical. Another factor is the popularity of the system and level of interest in emulation of the system. The original XBox is a good example of this. Gamecube and PS2 have much more polished emulators because they have more titles that interest people, while little effort is spent on emulating the original Xbox (despite being essentially a PC) arguably due to the lack of exclusive titles to make it worth it.
Nintendo consoles seem to always have the best emulators, likely due to being almost all exclusive games. Every nintendo console recently has had a working emulator before the end of the consoles life. I remember nintendo ds emulators adding support for games that had only just come out.
The other reason Nintendo consoles have the best emulators is because Nintendo generally avoids cutting-edge technology, or at least they prioritise "simple" and "cheap" over CPU and GPU performance.
Apart from the latest consoles (the Wii U and the Switch), the worst-emulated Nintendo console is the Nintendo 64, which also had the strangest hardware (RAMBUS RAM, a general-purpose GPU, etc.)
Apart from the latest consoles (the Wii U and the Switch), the worst-emulated Nintendo console is the Nintendo 64, which also had the strangest hardware (RAMBUS RAM, a general-purpose GPU, etc.)
On that note about the N64, there is a project (created by a friend of mine in college) that is looking to go down the cycle accurate route that the Byuu has gone down with higan.
It's called CEN 64 and can be found at https://github.com/n64dev/cen64
Lots of work that still needs to be done but it's quite impressive!
It's called CEN 64 and can be found at https://github.com/n64dev/cen64
Lots of work that still needs to be done but it's quite impressive!
I played SNES games emulated on a 66MHz 486/DX2 using an emulator named "esnes". No sound[1] and translucency was more miss than hit, but good enough to play through the entirety of ChronoTrigger. It was pretty cool to play a current (if aging) system emulated on a PC.
1: Sound was eventually implemented, I don't remember if it was before or after I upgraded to a Pentium though.
1: Sound was eventually implemented, I don't remember if it was before or after I upgraded to a Pentium though.
Did the same, with ZSNES running on Win95. Sound was disabled and I'd toggle layers on and off since transparency killed the framerate. Sometimes, when my parents weren't home, I'd copy my saves onto a floppy and boot the game up on the family Pentium 166 for sound and full FX. But I beat most of the game on my 486!
The savegame support of ZSNES and the easy way to hex edit memory are still fond memories of mine.
In the off chance anyone is able to help with this, I've set up a Discord channel (#ars) for coordination here: https://discord.gg/Fx7TfKh
Every member of the bsnes-emu project is on said server.
Thanks so much!