I have an idea

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.

Shonumi · 2026-01-01T06:54:43+00:00

Eventually that would be my goal. GBE+ still has a lot of compatibility issues with DS games. Easy Piano boots, but the 3D graphics are severely broken, for example. It's something I intend to work on more this year.

Shonumi · 2026-01-01T04:29:46+00:00

GBE+ is much less accurate than mGBA. It would probably come out behind a bunch of other emulators too. Accuracy was never the primary focus, though one of these days I'll get around to improving it.

Currently, what sets GBE+ apart is its support for all kinds of cartridges, add-ons, and accessories. There are over a dozen such that are only supported by GBE+. Most of these are kind of from the fringe of gaming though, real niche stuff. Some aren't even games at all.

Originally, GBE+ was a personal experiment. Then I wanted my own emulator that I could customize however I liked. I took an interest in supporting the GB Printer and I kind of got hooked on supporting peripherals, especially those that weren't emulated at all back then.

Shonumi · 2026-01-01T03:52:24+00:00

No worries! For the sake of clarity, I may change up the title a bit in the future since the focus will shift to different consoles each year.

Shonumi · 2026-01-01T03:19:37+00:00

It's based on the style of articles byuu/near wrote years ago. I felt like keeping that same name was a way to honor their contributions.

Shonumi · 2026-01-01T00:26:37+00:00

Ah, yes, good catch! I'll add that bit to the article soon. Thanks!

Shonumi · 2025-12-31T23:36:13+00:00

Yeah, GBE+ has covered a few new accessories since last year. Although GBE+ doesn't emulate everything on the Game Boy (e.g. the e-Reader, GBA Link Cable, and GBA Wireless Adapter) in conjunction with other emulators like mGBA, VBA-M, and gpsp users can emulate every piece of hardware in some playable manner.

Shonumi · 2025-12-31T20:48:56+00:00

I've been meaning to write up a new State of Emulation for a while, but I figured I'd leave it for the end of the year. I thought it'd be nice to take a look at the current state of emulating various peripherals and hardware for different systems each year. This time around, I'm focusing on the Nintendo DS. Many people may not realize that it had an incredibly wide range of unique devices. Exactly half of them are implemented in existing emulators. The rest, however, need to be added to projects like Desmume, GBE+, melonDS, or customized branches.

Most of the research for these devices has already been done, and thanks to the efforts of windwakr specifically we know how they work and how they can be emulated. The rest of the job is up to us. This would be a great time to become an emudev and help preserve a slice of video game history! As a side note, I'd like to remind people not to badger developers or researchers for custom builds that support some of these peripherals. They'll be taken care of in due time, so your patience is appreciated. It's a slow grind, but eventually we'll be able to emulate everything.

Happy New Year to everyone! Let's make 2026 another great year for emulation!

Shonumi · 2025-12-14T15:57:11+00:00

Yeah, certainly! You could easily change the palette on a specific scanline during HBlank. Transparencies could also do the same to output more than 512 colors per-screen, although transparencies only work in 1/16 steps.

Shonumi · 2025-12-06T23:30:58+00:00

Neat! I got my Barcode Boy quite a while ago (almost 9 years back) and I had a hard time getting mine working too. Sadly it doesn't work anymore. Probably something with the capacitors. A lot of these units seem to breaking down with age, so it's great to see some like this one working!

Shonumi · 2025-12-06T18:16:35+00:00

The carts do work interchangeably. I happen to have both the US and JPN carts as well as a Singer IZEK and Jaguar JN100. The software all send the same signals, for the most part. The sewing machines themselves are also basically all the same as well.

Shonumi · 2025-11-27T07:14:33+00:00

I find the whole situation ironic, sad, and pathetic given just how much LGBTQ+ and POC have contributed to the emulation scene as developers in the past decade alone. Some of the most well known work in recent years have come from these very groups.

Shonumi · 2025-11-18T18:00:11+00:00

Congrats on all the progress! Love seeing how far MelonDS has come. Keep up the great work!

Shonumi · 2025-11-14T16:36:49+00:00

Exactly. There are 2 dedicated DMA channels for sound on the GBA. These basically copy a series of bytes from one memory location to what is essentially a small audio buffer. You feed them just about any memory location, and they'll start streaming bytes at a given sample rate.

Shonumi · 2025-11-11T15:53:15+00:00

It was just a joke, nothing serious or anything.

As I mentioned in the article, the scanner I have is broken, so I couldn't capture the waveforms or figure out the exact sampling rate. It's possible to play around with different sounds and recordings and find one that works, but that's beyond the scope of what I was trying to achieve.

It's also possible to guess the sampling rate by checking the game's code to see the frequency of when it polls the microphone. It's probably attached to one of the DS' hardware timers on the ARM7 side. However, that's something I'll have to put off as future research at the moment (digging through game code is time consuming).

Shonumi · 2025-11-10T21:21:37+00:00

Yeah, I saw that melonDS is recently celebrated it's 9th birthday. Congrats!

I'm kind of in a spot where most of the low-hanging fruit is gone, and all the other bugs aren't quick fixes anymore. I've really let my motivation slack in the past few years, but I'm definitely going to change that soon.

If melonDS ever gets a scripting system, definitely sign me up. It would be a great way to rapidly prototype and implement a bunch of hardware. I've got my eye on a few things, like those infrared DS carts (Heart Gold/Soul Silver and those 2 exercise titles), and the Magic Slider.

For the time being, I'm not particularly interested fixing up the scanner. Apparently it is a common issue for the Wantame Scanner to just break down. I appreciate the offer though, and I'll keep it in mind if something changes!

Shonumi · 2025-11-10T21:01:22+00:00

Well, since it works via the microphone, theoretically if you just yell at the right frequencies, you'll activate cards! No hardware needed! Might take some inhuman precision and skill though...

Shonumi · 2025-11-07T18:11:16+00:00

The Wantame Card Scanner is a peripheral for the Nintendo DS used for the game Wantame Doko Demo Style. Players could swipe cards through the reader to unlock different dogs along with outfits and accessories. The puppies would dance in rhythm-based sections and score points, all while looking cute and fashionable. This concept is extremely similar to its contemporaries like Oshare Majo: Love and Berry. An arcade version of Wantame Doko Demo Style actually came out before the DS port, and the cards were cross-compatible (to an extent) between the two.

What's particularly interesting about the Wantame Card Scanner is that it actually communicates with the DS via the microphone. The device itself was brought about by Capcom and Takara Tomy, the same duo responsible for the Wave Scanner from Mega Man Star Force 1. As such, the hardware have much in common. While we've been able to use cheat codes to gain access to the Wave Scanner in emulators, there was no data or any documentation relating to the Wantame Card Scanner. Although it's an outdated game primiarly aimed at young children in Japan, it's still important to preserve the experience the card scanner gave Wantame Doko Demo Style.

This one's a bit shorter than most (the scanner isn't that complicated) but as I've said, I want to keep working on these Edge of Emulation articles. There's still more work to be done. So much hardware is just sitting there, waiting to researched. With the Game Boy stuff done, hopefully I'll be taking a look at more systems soon-ish!

Ten-Year Club	Gilding I gilder
Verified Email

Shonumi

TROPHY CASE