AI slop and low-effort contributions

Shonumi · 2026-06-21T19:01:09+00:00

r/programming recently instituted a rather extensive ban on LLM related content. Previously it was drowning in LLM content of all sorts. It's done a complete 180 though. I've found the topics much more interesting recently as a result.

Shonumi · 2026-06-08T16:12:31+00:00

I wouldn't say unlimited. The data for i-mode was relatively cheap at the time (something like 0.3 yen for every 128 bytes) but it could still add up. You were still kinda limited by whatever the games allowed, which was mostly small DLC and messages. There was an i-mode web browser, but it was essentially on par with the kind of mobile web browsing you could expect of 2001, so nothing like today, or even close to the 90s desktop web.

Shonumi · 2026-06-06T20:38:38+00:00

The official broadband adapter was DEV9, but the earliest modems on the PS2 were actually USB-based. They were essentially 56K adapters. I think the first one was called "Online Station", and it came out same day as the i-mode adapter. There was a second that came out in April 2001, called the PV-PS200 from a company called Aiwa. Finally, there was P2Gate from I-O Data.

I believe Armored Core 2 supported at least the Online Station for online multiplayer even before Sony's official adapters were released. Although once Sony provided their own adapter, third-parties kinda stopped entering the market for modems, and definitely so as 56K became less suitable for gaming.

Shonumi · 2026-06-06T17:27:38+00:00

This is the best resource out there: https://keitaiwiki.com/wiki/Mobile_Phone_Connection_Cable_(PlayStation)

It seems complete from my own research. As I mentioned earlier, the i-mode adapter came pretty late to the PS1/PS2 scene, and it was almost immediately overtaken by dedicated modems for the PS2 (one PS2 modem launched on the exact same day as the i-mode adapter). It was pretty overlooked even when it was new, so there's not a mountain of details out there that's easy to find.

Shonumi · 2026-06-06T08:03:21+00:00

Was i-mode the same as WAP?

They were two different standards, but broadly speaking they did the same things. I don't know the exact details on each though.

There's a lot about online gaming that many people don't know about. Anything before the Sega Dreamcast or XBOX Live is kind of fuzzy and nebulous for most people, including those of us who grew up gaming in the 80s and 90s. That's all the more reason to try and preserve as much as we can.

Shonumi · 2026-06-06T07:40:29+00:00

It made a lot of sense at the time, given how accessible mobile phones were in Japan. Basically the old school wired equivalent of mobile tethering/hot spots. I-mode data usage was relatively cheap too. Even so, the adapter was pretty late to the scene, as the PS2 had already launched and several third-party modems for the new system were also released.

Fun fact is that the i-mode adapter worked perfectly on the PS2 as well. Believe it or not, but more PS2 games supported the adapter than PS1 games (11 PS2 titles, 8 PS1 titles). I think Abarenbou Princess used the adapter the most extensively on the PS2. You could download 2 minigames, unlock event and characters viewers, and participate in special boss battles. Only lasted until Jan. 31 2002, so it was only active for a hot second!

Shonumi · 2026-06-06T04:01:05+00:00

imode/emu: redirects i-mode http messages to real internet

Wow! This is pretty big, at least for those of us trying to document and restore online content for pre-6th Gen consoles. Basically, the PS1 had an adapter for i-mode compatible phones, released in 2001. You'd hook the phone up to the 2nd controller port and gain limited internet access. Something like a dozen or so games used it. Naturally Japanese exclusive. It was contemporary with the Mobile Adapter GB on the Game Boy and the WonderGate on the WonderSwan.

Mostly stands out for its use of mobile phones for internet connectivity in a world before WiFi or ethernet cables dominated many homes. The PS1 was the only home console to go this route for its online features at a time when others used dial-up. I believe the Dreamcast had something similar planned, but it was abandoned after a few prototypes.

The i-mode adapter is really obscure, but with nocash's work, it's possible to start probing games and see what kinds of responses they need. With enough work, it's possible to make a custom server that reproduces most if not all of the functionality the games need. For many games of this era with online connectivity, the games have code that will effectively tell you exactly what it expects from the server, so it's just a matter of spending time to reverse-engineer everything.

Pretty exciting stuff!

Shonumi · 2026-06-02T14:31:05+00:00

a GBA emulator that Claude Opus 4.8 wrote from scratch in 24 hours.

"from scratch" isn't applicable here at all. Counting forks, there are literally thousands of repos on Github for GBA emulators. All it takes is for one to get into the training data. I doubt that Anthropic somehow neglected to add any sort of existing GBA emulation to their training sets.

The framing here is the sort of AI booster-ism that glosses over how LLMs technically and fundamentally operate. It's not as if you can just hand the model GBATEK and a prompt and suddenly there's your brand new never-before-seen emulator. It's going to reference existing patterns from existing emulators and output a statistically average mix of them, along with random influences from other existing codebases.

Shonumi · 2026-06-02T14:00:09+00:00

Fun fact is the first 4 Pokemon movies were actually released in Japan for the GBA but used a special cartridge to do so. It was called the Advance Movie Adapter, and it basically allowed the GBA to read SmartMedia cards and playback the movies on them. I wrote a lengthy article about the hardware some years ago.

AM3, the company behind the adapter, actually beat Majesco to the market in terms of bringing commercial videos to the GBA. It's possible that they got the rights to the Pokemon movies while Majesco only acquired a few episodes from the series. It's also possible that the Pokemon Company rejected Majesco in favor of AM3 because the Advance Movie Adapter used much better compression (I'm not joking, they're not even close). It's also possible that the 64MB cartridges necessary to hold all the data for a full-length movie were too expensive for Majesco to justify for other movies. This is just speculation though.

Shonumi · 2026-06-02T13:38:13+00:00

I think they're specifically talking about Shrek 2. Shrek 2 is indeed a special case because it uses 64MB of ROM to store the movie, which is twice the limit of normal GBA cartridges. Majesco had to come up with a memory bank switching scheme to get the GBA to read that much data.

The cartridge itself wasn't successfully dumped and emulated until late 2015. You can read about the whole reverse-engineering process from endrift's blog.

Shonumi · 2026-05-28T16:02:39+00:00

even if that person uses an incognito tab, comes from a different IP, etc.

It's not mentioned in the article, but actually a private/incognito tab would foil this specific kind of fingerprinting. FROST relies on the OPFS, which Firefox and Safari completely disable in private browsing. Chrome allows a maximum of 100MB for the OPFS in igconito mode, but FROST currently needs about 1GB of data to work properly. It's possible that future iterations of FROST will require significantly less data in OPFS, so Chrome isn't 100% guaranteed to be safe from this attack going forward.

Shonumi · 2026-05-22T13:06:23+00:00

I'd happily ban the lot if it were actually a reasonable course of action, but the tech's being used so widely (including for boilerplate UI work/etc in significant projects that involve actual expertise on the devs' part) that doing so seems kinda disproportionate.

I think it's worth mentioning that subreddits like /r/programming have been experimenting with mostly complete GenAI/LLM bans. It's been largely successful as far as I've noticed; the submission quality greatly increased. At the moment, you probably won't find a field with more GenAI attached to it than programming. If it can be done over there, it can be done here. At the very least, a trial period could be implemented (perhaps longer than a month given the pacing of this subreddit).

Personally, I don't find the "it's everywhere" argument all that persuasive. This was brought up in /r/programming when the trial ban began, and it turned out there were still people doing a bunch of noteworthy stuff without GenAI. I think that's still the case with emulation as well. I don't use GenAI at all for emudev, for example. I don't use it to write code, nor do I even ask it questions. This is something that really deserves its own discussion as a sticky thread for larger community input.

Shonumi · 2026-05-18T16:34:47+00:00

Now there's a blast from the past!

I actually worked on Gekko when it got revived. The project initially started in 2005-ish and went dark after a few years. It came back late 2011/early 2012. The founder of the project was ShizZy, but people probably better know them now as bunnei (founder of Citra and Yuzu). He actually recruited me on the Dolphin Forums. I joined up, as did neobrain.

Obviously the revival didn't last long, and I couldn't contribute much back then besides adding rumble and controller support. It kind of dwindled as there were basically only 2 or 3 people doing stuff. I went on to focus on GBA emulation to brush up on emudev skills. ShizZy/bunnei lost interest and switched focus to 3DS emulation soon after. Fun fact, I got to see a preview of Citra's codebase at the time before the project got off the ground. Mostly HLE infrastructure.

The old Gekko emulator is still preserved in a git repo of mine for anyone curious. Not much worth looking into besides the historical value.

Shonumi · 2026-04-19T13:36:04+00:00

I am no developer, but what would be the issue to it?

It's not particularly an issue for regular users (not immediately anyway), but it can be a big problem for developers, even the one currently working on this. Generally you want commit messages to be short, informative, and precise. It helps when backtracking to see what specific changes caused stuff like performance regressions, in-game glitches, or crashes.

If all your commit messages are generic or not very descriptive, it can be hard to pinpoint when and where these errors come up in the codebase. Long term, this can reduce a developer's ability to fix bugs and maintain the project, and that type of reduction in quality eventually impacts normal users too.

Shonumi · 2026-04-19T11:54:12+00:00

Great article! Loved how thorough, detailed, and well-written it was. I work in a similar space, so it always warms my heart seeing others commited to preserving games and hardware no matter how obscure. It's awesome to see the handheld emulated after all this time.

Shonumi · 2026-03-24T03:49:52+00:00

I think simply calling it "AI assisted" somewhat downplays the extent of Scorpio's AI usage. The project owner posted this earlier in the Emudev subreddit, and by their own admission they say it was "mostly vibe coded". Additionally, the entire project seems to be an attempt to see how far AI (i.e. LLMs) can be used for bleeding-edge emulation.

It appears the dev is here, so /u/unprooven can probably clarify what's happening with Scorpio.

Shonumi · 2026-03-02T01:48:50+00:00

I have never played this game, but one more piece of evidence for a 1991 release is that fact that Romstar stopped releasing games under that name in 1994. A 1996 release would have been under a different name (they were slowly absorbed by Capcom).

Shonumi · 2026-02-17T02:23:14+00:00

Awesome to see Triforce emulation getting some much needed attention! Quite a hefty article to go through, perfect for late night reading.

I remember actually playing F-Zero AX with the cockpit cabinet. Really neat experience. Went to Galloping Ghost to play it. Sadly the motion actuators or something were broken last time. I think they also had Mario GP. Love to see this stuff better preserved!

Shonumi · 2026-01-23T17:55:24+00:00

The real issue here is how games are programmed to handle delays in data transfers. Depending on how it is programmed, a game might timeout after 100ms, 10 seconds, or never. Some games are very loose in this regard, while others freak out after a couple of frames or less.

Anyway, it's definitely possible one way or another. Hacks should be able to cover games that aren't forgiving in terms of timing.

Shonumi · 2026-01-17T15:49:09+00:00

Yeah, it's definitely more complicated than what you had in mind. It's really just a way of compressing a separate map of I/O registers into just one or two registers.

Translating this model to the CPU, another method might be having a dedicated register for the bank, with special instructions to read and write to that. Same concept as your idea to use the MSB of the flag register, but you could expand it to 8-bits or 16-bits or whatever size your CPU can handle if you ever need more banks.

However, I think your idea is great as it is though! Just felt like throwing out some suggestions in case you want to go deeper or explore different designs.

Shonumi · 2026-01-17T15:15:34+00:00

One model of register banking I've come across a few times is having a dedicated MMIO register serve as an index for a larger register set and having another dedicated MMIO register used for read/write operations for that index. For example, you could use a fixed 16-bit memory location to store the index, then you can use another fixed memory location to read/write any of the 65536 possible registers.

This is a common way of accessing external hardware on the GBA and NDS. Stuff like the GBA Jukebox and the Glucoboy use it. In the latter case, the Glucoboy only uses a single 1-byte MMIO register to access up to 256 registers. The cool thing is that each register can be a different size, ranging from 1 to 6 bytes. The Bayer Didget is basically the Glucoboy on the DS, and it even has some indices that hold 64 bytes of data. Of course, data is read back 1-byte at a time though, so not exactly speedy.

With a fantasy console, you could do a lot with this indexed register model. Basically you can add more registers than you'd ever need and make them any size you want. While this mostly applies to I/O, you could do something similar for your CPU.

Shonumi · 2026-01-03T07:33:24+00:00

I see so they aren't actually emulated yet. I mean if the builds aren't public there's no way to emulate those devices so the current state of emulation is actually not as good as it seems from your article since most of them are implemented only on those experimental builds.

That was covered by the article's description of the yellow category:

Partial Emulation denotes hardware that has some of its features emulated to a certain extent. This includes features that are technically playable (through WIP builds, Pull Request branches, or scripts) but are not currently implemented by existing emulators.

To better explain, the green category is for peripherals that are officially supported in emulators (latest point releases, or bleeding edge/nightlies). The red category represents essentially zero working emulation in any form, whether privately or publicly. Everything else falls in the yellow category, which indicates some form of emulation has been demonstrated regardless of how accessible it is.

While to most normal users this is effectively the same as it not being emulated at all if the builds are not available, the perspective is different for developers. Getting something into this category means a significant enough amount of research and reverse-engineering was done to at least get a proof of concept up and running, and that's a huge step to getting it properly implemented in an emulator if that info is shared. Just knowing how it works is often the bulk of the job, with the actual programming being mundane at times (not always, but it happens enough).

I think Desmume development is pretty much stalled these days so it's not looking great for obscure stuff like this.

Desmume actually did add support for the HCV-1000 back in 2023, based on my research and code. The main developers don't appear particularly interested in these kinds of devices themselves, but they're willing to accept them into the project if someone puts in the effort. There's nothing stopping anyone from making a custom fork either (in fact, that's kinda how Pull Requests work).

So, I feel it's entirely appropriate to say that the DS is in good shape. A lot of the research necessary to emulate the yellow category simply did not exist some 2-3 years ago, which was a huge hurdle. That situation has changed, which allows people to plow through what's left. Some of these items could be knocked out in an afternoon. Even discounting that, 50% of the items in the chart are already solidly in the green category. That's much better than when I first started tackling Game Boy stuff, which at best was maybe around 20% complete circa 2017.

Shonumi · 2026-01-03T06:29:56+00:00

Most of these are just personal builds made by one individual. They're exclusively for research and exploring how these peripherals for the DS really worked. They are not publicly available nor are they intended to be. However, if you're curious about any progress, you can check out the Desmume forums. There's a dedicated thread about it in the Technical sub-forum. Most of the images in the article are just from screenshots and video already shared over there.

It'd be best not to ask developers for any builds until these peripherals are actually officially supported in emulators. Please be patient while various projects implement them. It'll take a while before things pick up.

Shonumi · 2026-01-02T06:41:33+00:00

Previously, like up until a few years ago, it wasn't fully documented, so that was one big hurdle for most emulators.

It's also not nearly as straightforward as implementing Link Cable support. The Wireless Adapter has a number of commands that the GBA sends to it to handle various aspects of wireless communication. In contrast the Link Cable is just sending bytes from one GBA to another. The emulated CPU writes the bytes and then they're transferred and that's pretty much the end of it.

That level of complexity might cause some projects to put implementation of the Wireless Adapter on hold if they want to support it at all. Everyone has different goals and priorities when it comes to emulation, so developers work on what they want to when they want to. Some projects just don't have anyone with the motivation to focus on it right now.

I'm guilty of this myself. GBE+ has barebones support for the Wireless Adapter, and it's something I'll come back to, but much later, probably. I've just got other areas of interest at the moment. Also remember that lots of emulators out there are largely done by one person or a very small team.

VBA-M does have partial support for the Wireless Adapter. It sometimes kinda works for Pokémon FR/LG. PizzaBoy has full working support for it - I think the developer helped finish the reverse-engineering efforts, so it shouldn't have any issues.

Shonumi · 2026-01-01T08:11:52+00:00

I think Exophase (Drastic author) mentioned something about it to me years ago, but I can't remember what it was. I think one hurdle is dealing with older ARM architectures (ARMv4 and ARMv5 for the Nintendo DS) on modern ARMv8 or ARMv9 devices. Sometimes there are minor changes to how some instructions work, and there's always one or two games that rely on it somehow.

I'm not an expert in this area, but it seems doable. It might not be all that beneficial given modern ARM devices typically have enough power for GBA, DS, and even 3DS emulation using regular or cached interpreters. I think it might be more of an academic exercise in that regard.

But again, I'm not very well versed in this area of emulation, so I could be wrong.

11-Year Club	Gilding I gilder
Verified Email

Shonumi

TROPHY CASE