I prefer games/md and Shadowrun with the 2058 mod (patched with ips.pl, but no perl on 9front). Altough a patcher could have been written in days with awk.
I want to preface this by saying I only add little bits and bobbles, and a huge chunk of the heavy lifting was done by aiju. Most of my answer is talking about code written by them.
Both gb and gba make an attempt to preserve the cycle timing for each instruction and memory access (ie some of the later portions of the gba cartridge rom have increased load times). For gb I have thrown a couple of those "acid tests" and it usually does pretty good, but I have yet to really sit down and extensively test. When I implemented the serial cable link over tcp for gb I did find there to be some desync in stuff like pokemon battles, that smelled like perhaps a timing accuracy issue but I have yet to really figure it out. My current theory is that the hand off between the cpu and the ppu are not quite accurate. Its cute code that uses some setjmp/longjmp magic, but perhaps not true to hardware.
To me the selling point of these emulators are not "these are the most accurate to hardware around" but more their general simplicity of implementation. They are really quite compact for what they do, almost all are just a couple thousand lines of C.
The choice is most likely deliberate: this is a 9front crowd (Plan9's aesthetic choices are rather peculiar). It's what man(1) should display on a 80-column or so terminal.
Debatable: 80 columns ease reading, as each line is completely within the cone of vision. It's not enforced in their style(5)[0], but the code mostly and naturally (e.g. short variable names) falls within this limit (random sample[1]).
(I don't think that Plan9's "not thinking in terms of terminals", which is more of a "a better-than-X11 GUI is the default UI" is really relevant in this context)
EDIT: I don't have a Plan9 box around, but at least on plan9port, man(1) by default wraps lines to 72 columns or so.
Groff's HTML output is very poor. It's a sad day when it's more convenient to generate postscript and convert to PDF than it is to read the directly generated HTML output...
I think it may have something to do with display:flex. CSS isn't a strength of mine but looking at the computed view, there's a wide inflexible margin on the right side that causes the text to wrap before it otherwise would need to on smaller screen widths. The nav causes the same on the left side.
Yeah but I have more than enough available screen real estate for 70 chars. Seems like some pretty excessive padding on the page causes the lines to wrap much sooner than they should or something effectively similar.
I think it would be clearer if the "description" sections didn't wrap under the "header" sections (e.g. when you narrow the page the descriptions wrap and display to the left of their headers, which is real weird). That's because the content is in a big `pre` block--any spacing on the left is just blank space in the content--so it'll wrap as one block. I'm pretty naive here, but it's probably way easier to say "put this in a `pre` block" than "parse the roff and generate HTML" (although I'm sure there are tools that do this really well...)
The emulator is not named nintendo, this is the common manpage for the gb, gba, nes and snes commands. Having said that, some if not all of them are also trademarks but since the 9front system is not sold, I am not sure trademark protection really apply. I believe the point of trademark is to prevent a product to have a same name as a competing one which is not really the case here.
It does. Nintendo is able to make free products too, and trademarks are certainly about provenance. Nintendo could claim that the use of their trademark could confuse users on the origin of this free product.
> On February 26, 2024, Nintendo of America filed a lawsuit against Tropic Haze LLC, the legal entity behind Yuzu's development. Development and official distribution of Yuzu ceased on March 4, 2024, after Tropic Haze settled the lawsuit with Nintendo of America for $2.4 million.
That was because the devs were idiots who kept a "stash" of pirated games on a shared server. They would have been cooked in discovery if the lawsuit progressed.
A dev team that was actually clean and didn't pirate a single thing would have done much better.
I think GP is implying that the main goal of the Yuzu emulator was explicitly pirating Nintendo games, unless other emulation projects where enabling piracy is just a side-effect, so to speak.
No, that wasn't the main goal, but the developers had their own private NAS and discord server where they shared pirated switch ROMs. That would have killed them if (when) it came out in the lawsuit so they decided to end it right there.
Notice how the other emulator, Ryujinx, isn't being targeted. There is no talk of a dev "stash" on its discord server.
The main thing people are forgetting is how Yuzu presented itself. They made a big thing out of support for 4k60 Tears of the Kingdom on PC before the game was released.
The marketing people inside Nintendo must have been completely furious to have their supremely controlled media cycle completely sidetracked by them. They clearly sicked the legal department on them after that.
Any time an emulator developer, or a fan game artist gets a cease and desist from Nintendo, it's always because marketing gets wind of their existence.
I don't have much empathy for the Yuzu team precisely because of this. Nintendo is notoriously litigious but has been careful not to go after all the completely fair and legal emulation projects out there. The Yuzu people were playing with fire in a big way. Pirating brand new games has nothing to do with preservation.
Ultimately, Ryujinx's emphasis on accuracy makes it the better Switch emulator for actual preservation anyways, and I imagine that project is seeing a lot more support now that Yuzu is dead.
Nintendo's entire argument in that case revolved around the unauthorized use of their encryption keys to bypass their DRM. None of the consoles mentioned in this manpage use encryption this way (and aren't powerful enough to do so in software.) So they're fine. IANAL.
Note that 10NES style lockout systems are NOT "technological protection measures" under the DMCA, because they don't restrict access to the copyrighted works themselves (the games), but instead restrict what games the console will play.
The one Game Boy emu dev who canceled their project was being overly cautious
If you’re not going to go into the specifics of why then this is FUD. I’m calling it out because this FUD has been widespread across multiple discussion communities including this one.
Tropic Haze (Yuzu) didn’t settle because all they were doing is writing an emulator. As others have pointed out, Nintendo had very strong reason to believe the Yuzu devs were engaged in outright and flagrant piracy. Among the allegations in Nintendo’s filing was that the devs (who publicly bragged about launch day support for new releases) were contributing the compatibility patches for new games prior to release.
Further, Tropic Haze didn’t lose the lawsuit in the sense that they went to court and had a judgement against them. They likely knew they were cooked and chose to settle.
For more on the legality of emulation in the US, review Sony vs Connectix.
Do they really say that? I've had encounters with Nintendo's "copyright czar" and their official position on emulation hasn't been that. Heck, Nintendo even licenses emulators for their SDKs, and sometimes for their games... and has at least hired one emulator developer.
> While we recognize the passion that players have for classic games, supporting emulation also supports the illegal piracy of our products.
Nintendo has never, ever, called the rerelease of their older titles emulation. Nintendo makes a conscious distinction between what they do internally, and external emulation. They have somewhat softened the wording of their statements, but their actions have shown they consider emulation outside Nintendo as a scourge.
> But can’t I make a backup copy if I own the video game?
> You may be thinking of the backup/archival exception under the U.S. Copyright Act. There is some misinformation on the Internet regarding this backup/archival exception. This is a very narrow limitation that extends to computer software. Video games are comprised of numerous types of copyrighted works and should not be categorized as software only. Therefore, provisions that pertain to backup copies would not apply to copyrighted video game works and specifically ROM downloads, that are typically unauthorized and infringing.
I really doubt anything happens. The three big reasons why nintendo attacked yuzu were: It was a modern console, developers were making a profit working on it, and it violated DMCA by shipping a circumvention for game encryption. No one at 9front is making any money from this work, and we fail to fit in to the other two due to the age of the systems.
What am I looking at? I can see it's a man page for some emulators but I feel like I'm missing some context. The site seems to be deliberately obtuse about what it is.
It's the man page for the Nintendo device emulators of 9Front. 9Front is a distribution of the Plan 9 operating system (most likely the most usable because it's the most actively developed one)
The link is interesting because these emulators seem to be part of the standard distribution of 9Front. Most likely those are written from scratch, given that Plan 9 is not a POSIX system (unless they are using http://doc.cat-v.org/plan_9/4th_edition/papers/ape).
Without looking I'm going to guess that ape is A POSIX Emulator, so we have an emulator emulating an emulator.
Edit: it's A POSIX Environment, but it still contains features that are unnatural in Plan9 and could by bypassed with more work, so much like emulation.
Close. It’s ANSI/POSIX Environment. It’s been there since Plan 9 second edition. I think it was put there basically for TeX, but don’t quote me on that because I no longer remember where I read that and it isn’t in the original paper.
Which really means this is a terrible way to emulate games.
The bug list is pretty darn unacceptable for a usable emulator.
You can’t even emulate PAL region games.
It’s a nice novelty that this is built in to the OS but the Linux/Android retro handheld scene is so much more wildly sophisticated than a half-broken command line emulator. Just jump on YouTube and search for an OnionOS overview to see what I mean.
I’m pretty sure in the context of the manual it means PAL games don’t work.
Why can’t I compare them? If someone wants to emulate games they ought to compare operating systems. Like I said, cool that 9front has a built in emulator, but that doesn’t mean it’s a good use case of the OS.
Ah, ok, moddy has an ips patcher:
https://shithub.us/moody/ips
Both gb and gba make an attempt to preserve the cycle timing for each instruction and memory access (ie some of the later portions of the gba cartridge rom have increased load times). For gb I have thrown a couple of those "acid tests" and it usually does pretty good, but I have yet to really sit down and extensively test. When I implemented the serial cable link over tcp for gb I did find there to be some desync in stuff like pokemon battles, that smelled like perhaps a timing accuracy issue but I have yet to really figure it out. My current theory is that the hand off between the cpu and the ppu are not quite accurate. Its cute code that uses some setjmp/longjmp magic, but perhaps not true to hardware.
To me the selling point of these emulators are not "these are the most accurate to hardware around" but more their general simplicity of implementation. They are really quite compact for what they do, almost all are just a couple thousand lines of C.
[1] https://en.m.wikipedia.org/wiki/Man_page
(I don't think that Plan9's "not thinking in terms of terminals", which is more of a "a better-than-X11 GUI is the default UI" is really relevant in this context)
EDIT: I don't have a Plan9 box around, but at least on plan9port, man(1) by default wraps lines to 72 columns or so.
[0]: https://man.cat-v.org/clive/6/style
[1]: https://github.com/plan9foundation/plan9/blob/main/sys/src/c...
(I know other roffs are available).
> On February 26, 2024, Nintendo of America filed a lawsuit against Tropic Haze LLC, the legal entity behind Yuzu's development. Development and official distribution of Yuzu ceased on March 4, 2024, after Tropic Haze settled the lawsuit with Nintendo of America for $2.4 million.
A dev team that was actually clean and didn't pirate a single thing would have done much better.
Notice how the other emulator, Ryujinx, isn't being targeted. There is no talk of a dev "stash" on its discord server.
The marketing people inside Nintendo must have been completely furious to have their supremely controlled media cycle completely sidetracked by them. They clearly sicked the legal department on them after that.
Any time an emulator developer, or a fan game artist gets a cease and desist from Nintendo, it's always because marketing gets wind of their existence.
Ultimately, Ryujinx's emphasis on accuracy makes it the better Switch emulator for actual preservation anyways, and I imagine that project is seeing a lot more support now that Yuzu is dead.
Citation please? Yuzu couldn't start the game at all without a patch, which I don't believe was being promoted by the Yuzu team.
Of course the patch + game + yuzu got bundled together and offered as a download on many websites, perhaps this is what you're thinking of.
Note that 10NES style lockout systems are NOT "technological protection measures" under the DMCA, because they don't restrict access to the copyrighted works themselves (the games), but instead restrict what games the console will play.
The one Game Boy emu dev who canceled their project was being overly cautious
Tropic Haze (Yuzu) didn’t settle because all they were doing is writing an emulator. As others have pointed out, Nintendo had very strong reason to believe the Yuzu devs were engaged in outright and flagrant piracy. Among the allegations in Nintendo’s filing was that the devs (who publicly bragged about launch day support for new releases) were contributing the compatibility patches for new games prior to release.
Further, Tropic Haze didn’t lose the lawsuit in the sense that they went to court and had a judgement against them. They likely knew they were cooked and chose to settle.
For more on the legality of emulation in the US, review Sony vs Connectix.
Nintendo has never, ever, called the rerelease of their older titles emulation. Nintendo makes a conscious distinction between what they do internally, and external emulation. They have somewhat softened the wording of their statements, but their actions have shown they consider emulation outside Nintendo as a scourge.
Several developer kits have used the word emulation without much ado.
> But can’t I make a backup copy if I own the video game?
> You may be thinking of the backup/archival exception under the U.S. Copyright Act. There is some misinformation on the Internet regarding this backup/archival exception. This is a very narrow limitation that extends to computer software. Video games are comprised of numerous types of copyrighted works and should not be categorized as software only. Therefore, provisions that pertain to backup copies would not apply to copyrighted video game works and specifically ROM downloads, that are typically unauthorized and infringing.
The link is interesting because these emulators seem to be part of the standard distribution of 9Front. Most likely those are written from scratch, given that Plan 9 is not a POSIX system (unless they are using http://doc.cat-v.org/plan_9/4th_edition/papers/ape).
Edit: it's A POSIX Environment, but it still contains features that are unnatural in Plan9 and could by bypassed with more work, so much like emulation.
http://doc.cat-v.org/plan_9/4th_edition/papers/ape
Ah that's the info I was missing, thanks! Indeed very interesting that emulators are part of the distribution.
The bug list is pretty darn unacceptable for a usable emulator.
You can’t even emulate PAL region games.
It’s a nice novelty that this is built in to the OS but the Linux/Android retro handheld scene is so much more wildly sophisticated than a half-broken command line emulator. Just jump on YouTube and search for an OnionOS overview to see what I mean.
Probably they would run faster and that's it.
Also, you can't compare GNU/Linux with 9front.
Why can’t I compare them? If someone wants to emulate games they ought to compare operating systems. Like I said, cool that 9front has a built in emulator, but that doesn’t mean it’s a good use case of the OS.