A Poor Prognosis

The Game Boy handheld platform served as many things over the years, thanks to a wide array of accessories. It was a camera. It was a printer. It was a sonar. It was a barcode reader. It was a music player. It was a movie player. It connected to cellphones, videophones, sewing machines, TV remotes, PC modems, toys, and racetracks. Game Boys were seemingly capable of doing everything and anything imaginable, especially when accounting for unlicensed third-party hardware. However, there was one area that it never really explored: the medical field. Some may point out the PediSedate as the earliest example of a Game Boy medical device, however, it's been sensationalized over the years on countless blogs and articles. In reality, there was nothing Game Boy-specific about the PediSedate at all, and it was advertised as working with anything with a 3.5mm jack, including CD players.

The first true medical device for the Game Boy didn't appear until very late in the GBA's lifetime. On November 14, 2007, an Australian company called Guidance Interactive released the Glucoboy. This specialized game cartridge doubled as a glucose meter. By inserting testing strips at the top, its hardware would analyze the blood sample and report the results to the user. The Glucoboy was intended to aid diabetic children, using video games as an incentive to regularly test themselves and keep their glucose within healthy limits. Paul Wessel invented the Glucoboy after observing his own diabetic son, noting how he always carried around his Game Boy. From there, Wessel came up with the idea of integrating a glucose meter into a cartridge and using software to reward kids when playing games. After designing and patenting his work, the Glucoboy was born.

Well, almost born. Wessel tried for years to get Nintendo's approval and make it an officially licensed product. The Japanese company initially balked. Part of the reason may have been Nintendo's unwillingness to open themselves up to any potential liabilities if the Glucoboy did not work or were misused. They may have also been sensitive to the optics of a malfunctioning Glucoboy leading to someone's injury or illness. Compounding all of this was the fact that juevenile diabetes is very rare in Japan, creating a sort of cultural barrier. In the end though, Wessel finally managed to convince Nintendo to give their blessings to the project. The delay was pretty extreme. News of the Glucoboy's plans date back to late 2004, almost 3 full years before it hit the market! By that time, the Nintendo DS was already dominating mobile gaming, and the GBA was on its way out.

When it launched, the Glucoboy was exclusive to Australia. According to Wessel, some 70,000 units were sold. The German pharmaceutical giant Bayer took note of what was happening and sought to buy Guidance Interactive. Their goal was to bring a newer international version of the Glucoboy to the DS. They did just that and released the Bayer Digit in April 2009. Unfortunately, Bayer seized and destroyed any unsold stock for the Glucoboy. It was a tragic mistake in terms of video game preservation, but a logical captialistic manuever for the company. They likely didn't want the older Glucoboy to take away from any future sales of the Bayer Digit. They also probably wanted to avoid any consumer "confusion" about two similar devices.

As a result of its limited release in Australia and the subsequent annihilation of some copies, the Glucoboy became an incredibly rare Game Boy accessory. Over the course of a decade-plus, the hardware proved extremely elusive. No one seemed to have any photos of it. No one seemed to even have come across any current or past auctions. The ROM had never been dumped, as far as the internet at large was concerned. Evidence of the Glucoboy's existence became so hard to come by that a few game collectors thought it had never hit retail shelves at all. It was effectively deemed "lost media" by the community, as any info related to the hardware was wrapped in pure mystery. It wasn't until 2018 that game historian Kelsey Lewin managed to contact Wessel and obtain gameplay footage for a brief documentary on the Glucoboy. Even so, the game and cartridge remained inaccessible. For a time, it looked as if this unique part of the Game Boy's history would never be recovered...

A Panacea Arrives

The Glucoboy's situation presented a fairly challenging dilemma. My ultimate goal is to emulate every officially licensed piece of hardware for the Game Boy platforms. The question here is how does one emulate something no one seems able to get their hands on? It's one thing to only have access to the ROM. The software alone typically acts like a blueprint for how the hardware should function. For example, LIJI32, author of the SameBoy Game Boy emulator managed to support the unreleased WorkBoy, despite not having access to actual hardware. All that was necessary was a peek at the ROM here and there. However, with the Glucoboy, not even that much could be done. As mentioned above, at this point, the Glucoboy's ROM simply wasn't available to anyone. Just getting access to that data would have been enough for me to figure out how the hardware works. I even said this explicitly on Reddit some years ago:

If I could get my hands on it, it'd be emulated, I guarantee it. ... Theoretically, I wouldn't even need to physically have the Glucoboy. A lot could be reverse-engineered if we just had a ROM dump of the cart and a picture of the inside components.

I was adamant about keeping my word. Give me the ROM and the Glucoboy was as good as emulated, simple as that. Nevertheless, I didn't get that chance, at least not right away. Slowly over the years, small bits of info on the Glucoboy began to emerge. After Lewin's video, a streamer known as TheKBLife played some of the Glucoboy's games as part of the Extra Life 2018 charity event. Evidently, they had worked at the game studio responsible for developing the software, so it made sense that they had access to the ROM. Sadly that data wasn't widely shared or leaked. In early 2022, I received several high-resolution photos from someone acquainted with Lewin that showed the Glucoboy's PCB. Apparently the Video Game History Foundation (VGHF) had contacted someone with an actual Glucoboy. They'd tracked down this individual and were in the long process of verifying things. Here was absolute proof that the hardware did exist; contrary to what some believed, people had their hands on units Bayer had not eliminated.

I assumed the VGHF would release the results of their work when it was ready, so for most of 2022 I focused on handling hardware I currently had access to: the Advance Movie Adapter, the GBA Jukebox, the Magical Watch, and some other odds and ends. As 2023 rolled around, I was beginning to get a bit nervous, however. My infamous Triforce of Terror was basically all that was left when it came to emulating everything on the GBA. Both the Play-Yan and the Campho Advance were being reverse-engineered and documented quite thoroughly. The Glucoboy remained the only one left behind in terms of research, since I had nothing to work with. Truth be told, the Glucoboy was one of the hardest chapters to write in my book, Peripheral Vision, given the relative lack of materials. I started to wonder if we'd ever see any meaningful progress on digitally preserving one of the oddest Game Boy cartridges ever made.

Thankfully, right at the end of May that year, the VGHF shared the fruits of their labor. As I understand it, they had an evaluation unit of the Glucoboy in their possession, and they wanted to determine whether or not it was the same as what was sold in stores. That is to say, everything had to be checked out and authenticated. Real preservation work requires some amount of investigation, after all. While the wait was a bit worrisome on my end, I do appreciate being thorough and meticulous. At any rate, at long last, a fully functional ROM for the Glucoboy was available. Someone had helpfully uploaded it to the Internet Archive for all to access, and now I could keep my promise and get this thing emulated.

It took quite a long time for someone to finally get a hold of the Glucoboy, but somehow they managed.

Before getting into the process of dissecting and analyzing the ROM, I'd like to take a moment to talk about a serious subject concerning video game preservation. For every single Edge of Emulation article so far, I've always had the required materials on hand. No matter how rare or exotic, I managed to grab a copy myself, and in some cases I've been able to rely on cooperation from others online. The Glucoboy was an entirely different case. Procuring it for any sort of testing was likely beyond me, so I couldn't just go on and make my own dump. I'd have to rely on *gasp* downloading a ROM from the internet. Now, personally, I don't find anything morally wrong about doing that. It's not like I'm trying to sell a bundle of ROMs on some cheap Android TV stick or something to make a quick buck. There's a valid educational and academic purpose here: to document how the Glucoboy works and ensure emulators can preserve that experience long after the hardware disappears.

Sadly, copyright and intellectual property laws (at least in the U.S.) are pretty inflexible on the matter. While it seems clear to those of us involved with video game preservation that people should have access to older works for research, downloading ROMs in such cases has not been proven Fair Use in any court over here. Ideally, we'd have something like a digital library where validated users are granted access to preserved game data. When I was in college, I remember getting blanket authorization to tons of pay-walled papers and databases simply by being a university student, so I see no reason why something similar shouldn't exist for other published media. Why even stop at video games too? Let movies and music in there as well.

Of course, that's not the world we live in. Far too many companies are preoccupied with wringing every last (mostly imaginary) dollar and cent out of their inventory, even if their stuff was published 10, 25, or 50 years ago. The very thought of losing any "potential profit" sends every bean-counting suit with an MBA into a cold sweat, probably. It's an industry-wide attitude that favors maximum money above all else, even common sense. There's no indication that giving researchers access to older video games would mean companies would see a sudden drop in revenue. Most of these games are available secondhand, meaning no money would get transferred to Giant Media Corps anyway. And in the case that a game is rare and expensive on the used market, researchers have been able to turn to "unauthorized copies" of games since, well, forever. Even so, groups like the Electronic Software Association have fought against DMCA exemptions for remote access to archived games.

With the Glucoboy, we have a situation where someone is trying to study the hardware and software to keep its history alive. There's no way I'd be able to get my hands on this thing any time soon, so remote access, such as getting a copy through the Internet Archive or some other repository, would be a great way to achieve this. Regrettably, the law doesn't allow for that, and some folks with the ESA think that would lead to undue piracy (ignoring the fact that undue piracy happens elsewhere all the time). It would be great to have a legit means of probing the Glucoboy, but copyright, particularly the DMCA, is rigid over here, and companies always got money on their mind. Nevertheless, I'm simply not willing to let the Glucoboy fade away into obscurity, so for me there was only one thing to do. I'm sure everyone can guess what that was.

A Routine Proceedure

Moving on, with the Glucoboy software on hand, I started digging into the mysteries contained within. The first order of business was to just see what happened when my emulator tried to run it. Much to my relief, the Glucoboy booted with no issues. There's always the chance that such devices may require emulation of large portions of the hardware in order to display any graphical output. The Advance Movie Adapter was perhaps the most notorious example of that kind of behavior. Thankfully, that was not the case this time. Eventually after a few company logos, the Glucoboy came to a screen waiting for user input. Upon pressing the Start button, the Glucoboy tried to retrieve something called Glucose Reward Points or more simply known as GRPs. These points were given to children when they regularly tested their glucose levels and stayed within acceptable ranges. GRPs acted as a sort of in-game currency that could only be gained through a healthy lifestyle.

Although any GBA emulator could boot the Glucoboy, none handled the process of reading GRPs.

By some unknown means, the Glucoboy was trying to access some kind of data. At this stage of the reverse-engineering process, I had no idea what it was doing. At any rate, the Glucoboy returned an error after a few moments, as nothing was properly emulated. Even so, the software let me access the main menu where I could create a character and start exploring the actual game. Players would find themselves in a bedroom with an arcade machine, a game console, and a poster of a clown. These contained 5 games in all. Lost Star Saga was a full-fledged sci-fi RPG, while Knock'em Downs was a top-down carnival-themed action game; these 2 comprised the bulk of the Glucoboy's entertainment. The other 3 were shorter minigames. Solar Wing was a horizontal shooter, Plexus was similar to Breakout, and Raccoon Rancher was a puzzle where players had to separate raccoons with a controllable fence. Yeah, that last one is... it's definitely different, and surprisingly challenging.

The Glucoboy didn't skimp on gaming, offering children a wide variety of options to choose from. Everything's pretty fun to play.

When starting a fresh new game, only Knock'em Downs was initially unlocked. The other 4 required players to accumulate and spend GRPs. Unfortunately, GRPs were not immediately available without emulating the hardware. At first glance, it may seem like these games are lost to us unless we know how the Glucoboy really works. However, the save data in EEPROM can easily be hacked to give players free GRPs. Additionally, editing values in RAM via cheat codes can achieve a similar effect. Last but not least, there is a legit way to earn GRPs without emulating the Glucoboy or using hacks. Every so often, if the player idles in the bedroom for a while, a brief 3-choice quiz will pop up. These are always related to diabetes, such as best practices for maintaining good glucose levels to trivia such as which pop stars and movie celebs (circa 2007 anyway) were diabetic. Each quiz nets the user a small amount of points. Using an emulator's turbo/unlocked speed mode and save states, anyone can gather points in a reasonable timeframe.

Given all of that, the Glucoboy's games were readily accessible. Still, emulating the Glucoboy would ensure that no one needed to resort to such measures. It was time to take a closer look at how the software interfaced with the hardware to obtain GRPs. Going back to the screen where the Glucoboy tried to read GRPs, I used my emulator, GBE+, to scan for any suspicious addresses read from or written to. There only seemed to be one located at 0xE000000. At first it wrote the value 0x00 to this location, perhaps as a means of resetting some of the Glucoboy's hardware. Then it wrote the value 0x20 and... did absolutely nothing else. This kind of set off a few alarms in my head. Some kind of I/O was being written, but nothing was being read. The Glucoboy couldn't get any GRPs if it wasn't reading anything. My immediate hypothesis was that the Glucoboy was waiting for something, some kind of signal, maybe an interrupt... generated by the cartridge...

At first I didn't want to believe it. This was the work of my most feared enemy: the Game Pak Interrupt. As I explained previously in my last article about the Play-Yan, Game Pak interrupts basically give the cartridge free license to do all sorts of things. The conditions for triggering that interrupt could be anything. The cartridge could expect various bits of data before or after a Game Pak interrupt fires. It's just one giant headache if you're trying to figure out how a piece of hardware works, especially when there's zero documentation on hand. I manually confirmed that the Glucoboy used Game Pak interrupts by looking at what interrupts the software had enabled, and sure enough there it was. To say the least, I was prepared for a long, hard fight.

Fortunately, that fight never came! The Glucoboy uses Game Pak interrupts in a very simple way. Essentially, any time the software reads or write to 0xE000000, it waits for a Game Pak interrupt. The interrupt itself seems to alert the game code when the cartridge is ready to send or receive data. It's completely different from the Play-Yan, and it's about as basic as you can make something like this. I was able to breathe a sigh of relief and reclaim a small fraction of my remaining sanity.

With the Game Pak interrupt out of the way, I quickly hacked together some code in GBE+ that would allow it to process those IRQs whenever. After this, I let the Glucoboy run on its own to see what kinds of reads and writes it made. Altogether, the software accessed 0xE000000 over 120 times, but no other memory location was ever touched. It appeared that all data going in or coming out of the Glucoboy was restricted to a single I/O register. Typically I would have expected more, but sometimes it's just easier to design and develop hardware like this. In any case, it vastly simplfied emulation as well. I decided to name this register GLUCO_CNT, short for Glucoboy Control.

There was an immediate and obvious pattern to the reads/writes to GLUCO_CNT. The Glucoboy would always write an 8-bit number, then it would read either 4 times or just once. Those 8-bit numbers looked to be some sort of index, a value that the Glucoboy would receive when it was supposed to lookup specific data. For example, if the software wanted to read back the player's current GRPs, it would use one index. Other data, such as the player's current streak of days with healthy glucose level, would use a different index. The data stored in each index was evidently either 32-bit or 8-bit, which explained why the Glucoboy did 4 reads or 1 read. After all of these reads and writes, the main game never touched GLUCO_CNT at all. Whatever data the Glucoboy wanted, it was grabbed shortly after boot. The question now was what did each index represent?

A sample of the initial data logs for GLUCO_CNT. The function of each index was unknown.

Clinical Trial and Error

It was time to break out one of my favorite tools when working with software: the old spray and pray methodology! The idea here was to change values randomly and see how that affected the game. For this operation, I only had to focus on each index. When the Glucoboy requested an index's data, I returned whatever number I could smash on a keyboard, then observed how that changed anything when running the software. The first 3 indices I tried manipulating didn't seem to do anything at all, no matter what I changed them to read. Strangely, I tracked where those values were stored in RAM, and the Glucoboy seemed to ignore them entirely. They weren't used or referenced in any capacity.

This was quite curious behavior, but I reasoned that it was probably reading data from the Glucoboy that wasn't relevant to any actual gameplay. It was potentially reading data like the real-time clock, which the Glucoboy only used internally to make sure blood testing was done frequently. The game itself only needed to know if GRPs were rewarded, and if so how much. There was also the possibility that it was reading old debug information that was necessary during development, but for a retail release it was non-essential data. In any case, I had no idea what those mysterious indices did because they had no visible impact on the software.

Fortunately, the next series of indices were used by the game. Altogether, there were only 4 indices that the Glucoboy really cared about. Daily GRPs Earned represented the amount of GRPs earned for a given day after the player had tested themselves. Bonus GRPs Earned was an extra amount of GRPs earned for consecutive days of maintaining good glucose levels. Current Number of Good Days was the number of days the player had maintained this good streak. Number of Good Days Until Bonus Rewarded was the remaining days players needed to maintain a streak until they got a bonus. These values could all be checked in-game when the player moved to a piggy bank in their virtual bedroom. When testing various values, this feature made it clear which indices controlled which properties.

All of these indices were 32-bit, so they could contain some fairly large numbers. The Glucoboy's software treated them as signed values, and it only registered positive values. The maximum allowed for each category was 2147483647. Imagine playing with the Glucoboy for so long that you managed to maintain a streak of... 5.8 million years of healthy glucose levels! Can't wait to see someone do a "Let's Play" of that! Those 8-bit indices, however, seemed to have a completely different purpose. As far as I could tell, they acted as binary flags. Any non-zero value caused the Glucoboy to freeze when reading GLUCO_CNT and eventually return an error after timing out. Whatever they were, these indices had to hold a value of zero, otherwise it would abort reading GRPs altogether.

The last index was also a bit of a puzzle. Unlike the others, the Glucoboy actually wrote data to it instead of reading from it. The Glucoboy wrote 6 bytes every time, and all in all, it accessed this index 10 times. I had no clue what the Glucoboy would need with all of that input. Nevertheless, the Glucoboy never actually read data from that index, so it basically had no effect on the software. It felt as if half of the Glucoboy's indices weren't being used at all. I questioned just how much data really wasn't useful for the main game, or how much debug information had been dropped. I couldn't do much about it as I didn't have the hardware in front of me.

However, I had finally discovered exactly how the Glucoboy read and used GRPs. This was the most important information, after all. With that, an emulator could artificially generate as many GRPs as the player wants. It could dole out points like candy and instantly unlock every game in one fell swoop. With 2 billion GRPs on hand, players could also buy as many in-game items as they wanted. Now, all of this looks like cheating (and, well, it is), but it's also breaking down barriers so people can easily experience the Glucoboy's games. The key thing here is that the glucose testing hardware is no longer required, so current and future gamers can understand what it was like playing masterpieces like Raccoon Rancher. For preservationists and video game historians, the Glucoboy becomes much more accessible to study, analyze, and comment on. And last but not least, everyone gains a bit more insight on the hardware itself.

Knowing how the GRPs worked, I quickly implemented a way for GBE+ to insert its own values from the user. By reading data from its .ini configuration file, GBE+ could put any value it wanted in the four indices mentioned above. In doing so, the Glucoboy was now technically emulated! Players had full control of their GRPs and could explore everything the Glucoboy had to offer. Overall, the whole process was incredibly straightforward as far as reverse-engineering goes. There weren't many surprises. It only took me a couple of hours over the course of 3 days to get everything in GBE+ setup. It was one of the easiest and fastest projects I'd worked on. Even so, it was kind of huge relief. Cartridges with special hardware can often be absolute nightmares. I anticipated a long, hard battle with the Glucoboy, but everything went very well. To see one of the last undocumented GBA cartridges fall so quickly and smoothly felt great. Sometimes you just don't want to deal with overly complicated devices and take a nice, enjoyable win.

With literal billions of GRPs at our disposal, we could buy everything and anything in-game.

Remission and Relapse

Even though the basics of the Glucoboy were now emulated, I still couldn't help but feel there should have been more to its story. For something that had proved so elusive, I figured it would at least have some more secrets left inside. As one of the infamous members of the Triforce of Terror, I expected a bit more intrigue. It was rather anticlimatic, honestly. There just had to be something more...

Of course, there were plenty of unknown indices. Their purpose remained obscure and inscrutable. The Glucoboy's software treated them as if they didn't exist at all after accessing them. Not knowing what they were supposed to do bothered me. It meant that, even though the peripheral worked via emulation, there were still elements of its hardware that we simply didn't understand, details that might disappear if all the world's Glucoboys ever stopped working. To me, it were as if the job was only half-finished. But how exactly would I be able to probe these unknown indices without having a Glucoboy myself? The software was my only guide, and it revealed nothing, or so it seemed at first.

Some months after I had added support for the Glucoboy in GBE+, I returned to my research and decided to take a peek at the ROM. Out of curiosity, I ran the strings Linux command on the Glucoboy's ROM. This command pulled every identifiable ASCII string from the file; I redirected its output to a text file for further analysis. Looking through a binary file's strings is often a good way at piecing together a bunch of clues about the software that might otherwise remain hidden. On many occassions, strings will be labels for text and menus, or even messages used for debugging. It can expose a lot of internal naming schemes that may go unused or unnoticed when actually running the game. When looking for tips about how certain software functions, its a good first step.

Now, pulling ASCII strings isn't perfect. The technique doesn't distinguish what's a real word versus random bytes that happen to map out to readable ASCII characters. So while it can find strings like "GLUCOBOY", it also finds garbage data like "Mhyhp(y(phzhq(z(qi{ir({(r". All of the strings require manual review to determine what's nonsense and what's actually noteworthy. There's no guarantee that anything useful will turn up, but unless that data is checked, no one will ever know. I started skimming over dozens and dozens of lines in the text file holding the strings. Most of it was useless noise, but I soon found something that really captured my eye.

There was a group of readable strings with values such as "CLEAR REG", "WRITE REG", and "READ REG". I assumed they were all in reference to memory-mapped registers or something along those lines. It seemed to hint at some sort of hardware behavior, and by the looks of all the printf type fields like %d, %s, and %x, I guessed these strings were used for debugging. More importantly, however, I stumbled upon the following list:

DATE

FLAGS

SERIAL

DAILY POINT

BONUS POINT

GOOD DAYS

DAYS LEFT

LD THRESH

GAME STATS

Now, the ones like "DAILY POINT" and "BONUS POINT" referenced the same indices I had previously studied, the ones the Glucoboy used to read GRPs, bonuses, and calculate when to reward bonuses. The rest of the stuff, however, I had no idea what they were. My first thoughts were that they corresponded with the unused indices from the Glucoboy's boot process. These same strings appeared together again in the Glucoboy's ROM, further reinforcing this theory.

System Date

Hardware Flags

Serial Number

Daily Points

Bonus Points

Good Days

Days Left

LD Threshold

Game Stats

So, it seemed that those other indices were reserved for information such as the Glucoboy's RTC, some flags indicating the status of various bits of the Glucoboy's hardware, a serial number, some sort of threshold, and something else related to gameplay statistics. While it was nice to have some labels to attach to these previously unnamed indices, there was no information on what those values did or what sort of format they were expected to have. For example, the System Date was a simple 32-bit number, but how did that translate into an actual measurement of time? Was it a Unix timestamp, or something else entirely? What was the valid range of years (2000 to 2099, or 2000 to 3000, or 2000 to 2030)? Did it take just a calendar date, or did it also include details like hours, minutes, and seconds? And which bits affected which categories?

Once again, these types of questions would be readily answered by probing the hardware itself. Since that's not an option, the software has to act as a blueprint. However, it wasn't clear that the software made use of these indices in any capacity. With the presence of these strings though, I suspected that there had to be some debugging code left behind by the developers. It was possible that the strings simply hadn't been deleted but the actual code was long removed. The only way to know for sure was to dive into the ROM and look at where the strings were located.

Thanks to Ghidra, a tool capable of picking apart all manner of binary blobs and analyzing their programming, I was able to track down the exact spot where the strings occurred as well as the code that used them. After briefly skimming through a few instructions, I saw that my assumptions were correct. The code here was used for debugging! This part of the Glucoboy's ROM would write to GLUCO_CNT to access a specific index, then read/display the 32-bit contents of that index. For an index like the System Date, it seemed to handle converting that value into a calendar date as well.

This progress proved most welcome, as I now technically had all the information regarding how each index was used. Even so, I wanted to go even further. The debug menu seemed completely intact inside the Glucoboy's ROM. Unfortunately, there didn't appear to be any easy way to access it. If I could reach the debug menu, I'd have a way to actually test and verify these indices once emulated in GBE+. It would avoid the awkward situation of trying to implement something but having no means to ensure its correctness. Plus, as a fan of websites like The Cutting Room Floor, I've always wanted to uncover something buried away in a game.

Although the debug menu didn't look accessible under normal conditions, there had to be a way to trick or force the ROM to start executing its code. For this task, Ghidra provided a lot of support. The first step was to find out if the debug menu was completely isolated or if it was linked to other sections of code. If the former case were true, that meant that the debug menu had basically been stripped from the main program and it was just hanging out in ROM by itself. Accessing the menu would be quite troublesome then, as all the variables it needed to run would have to be hacked into place somehow. If the latter case were true, I just had to find some existing codepath that eventually executed the debug menu, and hopefully the rest of the Glucoboy's code would handle any variables as expected.

Luckily, the debug menu was connected to another function within the Glucoboy. Better yet, this function was connected to another one, and another one, and another one. I followed this chain until I reached an area of code that the Glucoboy ran periodically, once per frame. So, the debug menu was reachable under the right conditions. The next step was figuring out how to go from the Glucoboy's main loop all the way down to the debug menu. Once again, Ghidra made this work feasible, as it allowed me to jump across sections of code with a single click. I had hoped that I'd need only change a single variable at startup to enable the debug menu, but I couldn't find such a mechanism. Instead, it looked like I had to alter a total of 4 variables sometime after boot. As long as they held the correct values, the debug menu should have popped up. Below is a chart of the memory locations in RAM along with the expected 8-bit data:

0x200015E = 0x09

0x200015F = 0x04

0x2000160 = 0x02

0x2000161 = 0x01

GBE+ has a built-in debugger that allows the user to arbitrarily change any value in memory. After a bit of fiddling with that, I managed to make some text appear on-screen. The rest of the Glucoboy froze, but there it was definitely showing at least the first bits of the debug menu. I tried changing those 4 variables at different times during the startup process. If they were changed too soon, the Glucoboy only showed a black screen. If they were changed too late, sometimes fragments of text would appear, and sometimes nothing at all would show up. In all cases, the Glucoboy seemed to come to a halt. There was only one scenario where things actually worked: the brief period where the Glucoboy accessed GLUCO_CNT to read GRPs. Setting the 4 variables at that moment finally caused the debug menu to reveal itself, and this time nothing froze.

This debug menu was hidden away for the past 16 years.

As I had hoped, the menu had the strings I had located earlier. Perhaps the most striking thing about the debug menu was that it referred to GLUCO_CNT as something else, MAGIC PORT. This was most likely the internal name used by the development team. The language makes sense, in that a single MMIO register is basically where all the "magic" happens on the Glucoboy. Although this tidbit had no real bearing on anything technical, it did offer some previously lost insight into the Glucoboy's history. Still, the real treasure trove was the debug menu itself.

Sadly, the menu was not immediately usable. It was designed to read/write certain indices, but it got stuck in an infinite loop when trying to do either. Because I had bascially forced the menu to appear instead of taking its proper codepath, some things didn't quite act right. The issue here was related to one of the GBA's timer interrupts. After reading or writing to GLUCO_CNT, the Glucoboy was programmed to delay very briefly before moving on. This delay was measured precisely by the GBA's hardware timers. Interrupts from the timer alerted the CPU when a certain amount of cycles had passed. However, when executing my hack, all interrupts for the GBA's timers were disabled. When the Glucoboy ran code for the debug menu, it kept waiting for an event that never came.

Rather than enable interrupts, I actually patched the ROM to avoid all timer-related code. Only a dozen 16-bit THUMB instructions had to be replaced. GBE+'s debugger can edit ROM values as well, so the patch was done in real-time. After eliminating timers from the debug menu, I gained full access to the Glucoboy's indices. As a result, I rapidly tested each one to figure out how they worked.

Medical Mysteries

There were several unknowns to investigate. I began at the top and made my way down. First was the System Date. This index was never used by the Glucoboy in-game, but the GBA could still read its value. The debug menu lets users pick a date, then it writes the equivalent 32-bit value to GLUCO_CNT. By playing around with some dates, I was able to see the minimum/maximum ranges for days, months, and years, and I could see which bits of the index were affected when changing the time. As it turns out, the Glucoboy handles minutes, hours, days, months, and years, but it does not provide an interface to read seconds. This is similar to the HuC-3 cartridge on the DMG/GBC. That level of granularity just isn't useful, I suppose.

Next, I took a look at "Hardware Flags". This index used only a single byte's worth of data, despite being 32-bit in size. The debug menu displayed a total of 7 unique flags, all of which presumably held the status of various components within the Glucoboy. Hardware Flags presented some of the most fascinating and significant details about the Glucoboy, showing a side of the device that would have otherwise gone unnoticed. Each bit represented a different status using a 0 or a 1. The list of flags was as follows:

BIT 0 :: GMEM FAULT

BIT 1 :: PMEM FAULT

BIT 2 :: INCENTIVE

BIT 3 :: PNEW STATS

BIT 4 :: MEASUREMENT

BIT 5 :: GMETER FAULT

BIT 6 :: PMETER FAULT

Most of it looks pretty obscure until one considers what sort of tasks a glucose meter needs in order to do its job. GMEM FAULT and PMEM FAULT looked to be flags about some kind of memory error. According to published articles when the Glucoboy was released, the cartridge was able to save somewhere between 400 to 500 blood testing results (the exact number varies based on the source). It makes sense that the Glucoboy would have the ability to check on it, since it seems like a pretty big error. But what do the "G" and "P" stand for? Most likely, they refer to memory used to save general glucose and postprandial glucose results. The latter are glucose results taken after a meal.

The INCENTIVE flag seemed to reference the Glucoboy's proprietary method of determining how to best reward and encourage players to live as healthily as possible and keep their glucose levels in check. Paul Wessel did a lot of work tuning the Glucoboy's algorithms for handing out GRPs. While that exact formula is not found anywhere in the ROM, as far as I could tell, this flag seemed to indicate whether or not the player was fulfilling the Glucoboy's expectations. This flag would probably have changed depending on when players tested themselves.

PNEW STATS conceivably marked any time new postpandrial test results had occurred, thereby signaling to the Glucoboy to update any statistics relating to the user's performance in terms of healthy glucose levels. Basically, this flag probably told the Glucoboy to check to make sure the user was on track when new data was available. MEASUREMENT seemed much more straightforward; it simply told the Glucoboy whether or not a new measurement for blood glucose had been made, or something to that effect. GMETER FAULT and PMETER FAULT indicated whether or not there was some kind of error with the actual testing meters.

Interestingly enough, although most of the System Flags involved serious hardware failures, the Glucoboy happily ignores them. Whether or not those flags are set, the Glucoboy goes in-game without so much as a warning to the user. As I mentioned earlier, the System Flags are only used in the debug menu. While some of the flags are not at all relevant for players to know, it seems like an oversight to not inform them about issues that might make the Glucoboy unusable. In any case, most of the interpretations of the System Flags are at best an educated guess. Despite being prone to diabetes myself due to heredity, I'm not exactly knowledgable about the disease and certainly not an expert on glucose meters. I could be completely off-target, but at least we have some new clues about what's going on inside the Glucoboy.

Once finished with the System Flags, I turned to the "Serial Number" index. This looked easy enough to grasp. Every Glucoboy may have had its own identifiable serial number. It's hard to say exactly what the serial number looked like or how it was made. Perhaps it worked like the Game Boy Camera, which had 8-digit IDs randomly generated and saved to SRAM. Perhaps it was somehow hardcoded into a small component, similar to the 128-bit IDs used in SmartMedia cards. Without knowing more about how the Glucoboy was made, I can't provide a definitive answer. Given the debug menu's ability to write a new serial number, I'd say it's probably closer to the first scenario. What I did find out, however, was that the serial number was written in Base 10 instead of hexadecimal and had a range of 00000000 through 99999999. Interestingly enough, the Glucoboy the VGHF obtained was an evaluation unit, and on the back it has a serial number that's also 8-digits long.

A real example of the Glucoboy's serial number.

"LD Threshold" was more challenging to parse. Like the Serial Number, this index worked on Base 10 numbers and had the same minimum/maximum range for values. Its purpose was puzzling. As best as I could tell, one possible reading was "Low-Data Threshold", a number that represents the smallest amount of data that's useful for a given tool/system/process. It's like a cutoff value at which point the data is too small to be helpful and signifies it should probably be ignored. This is used frequently in areas like sampling. Now, the Glucoboy could get accurate test results from a surprisingly low amount of blood, but even it had limits. It stands to reason that LD Threshold was that sort of value.

Finally, there was "Game Stats", which obviously stood for... Game Statistics. But what did that really mean? When accessing the Glucoboy's debug menu, selecting Game Stats brought up a list with various values displayed. Unlike the other indices in the debug menu, Game Stats could only be read, not written. Here are the items it displayed:

VCSECS

VCHIGH

KDSECS

KDHIGH

SWSECS

SWHIGH

PLSECS

PLHIGH

RRSECS

RRHIGH

Once again, it's all very obscure at first glance. However, taking a moment to really look at the list, break it down, and think a little about it really makes things clearer. Consider that the first two characters of each string in the list is a reference to the Glucoboy's games. "KD" refers to Knock'em Downs, "RR" refers to Raccoon Rancher, "PL" refers to Plexus, and "SW" refers to Solar Wing. The only odd one is "VC" which seems to have no relation to Lost Star Saga. My bet is that VC might be the initials of the game's earlier working title that got changed at some point in development, or perhaps it was an internal codename.

At any rate, the values seem pretty self-explanatory. Each game has a high score and tracks the play time in seconds. This is the same index that I observed being written 10 times when the Glucoboy booted. Unsurprisingly, there are 10 pieces of data the index can retrieve. As best as I could tell, the game records this information as part of a save data file, stored on the cartridge's EEPROM. It's updated as the player progresses through their games. When turning on the Glucoboy, it grabs data from EEPROM and sends it back to the Glucoboy. Essentially, a copy of the most recent Game Stats is transferred to the Glucoboy every time it starts up. Exactly why the Glucoboy needs Game Stats at all isn't certain. It could have very well been used as input data for the Glucoboy when calculating how many GRPs to rewards players.

Each entry in Game Stats was just an unsigned 32-bit number. For whatever reason, when writing to this index, a special 16-bit number has to be sent first before 32-bit contents. There's no evidence of what that 16-bit number does, but it was a constant value of 0x3000. Perhaps a different number would affect some other operation? Additionally, it appeared that reading and writing were done sequentially. That is to say, to change the value of RRSECS, the other previous 8 entries had to be written first. Strangely, the debug menu not only doesn't write to Game Stats, it just reads the current values from EEPROM.

That pretty much covers everything I managed to learn from the debug menu. The last useful information I gleaned was that technically reading data used one set of indices, while writing used a completely different. For example, when the Glucoboy wanted to read the System Date, it used the 8-bit index 0x20. When the Glucoboy wanted to write the System Date, it would use the index 0x60 instead. All in all, the debug menu provided a glimpse into the Glucoboy that no one (aside from the original developers) previously had before. Thanks to a few bytes of code and a pile of strings, we were able to unmask many of its innermost secrets.

Road to Recovery

Overall, I found my time with the Glucoboy both exciting and satisfying. Even though it was easy to emulate at first, I was actually rather happy to find out there was more to the device. With its debug menu, I was able to emulate parts of the Glucoboy few had ever known about. GBE+, for example, uses the host PC's clock when reading the System Date. These don't affect the actual gaming side of the Glucoboy, but it's very nice for the sake of completeness. I was also thrilled that finally, after many, many long years, the Glucoboy had been digitally preserved. It always seemed like such a monumental task, given how scarce the hardware was. Now, however, the job is done.

The Glucoboy was a very intriguing chapter for Nintendo. It officially marked the last time any Game Boy received specialty hardware licensed or approved by the company. No more crazy cartridges, no more freaky peripherals, and no more exotic accessories. By late 2007, the DS was dominating the mobile video game market. Developers were turning their attention to this platform, and in doing so they began making brand new products. Pianos, guitars, wireless keyboards, pedometers, motion controls, video cameras, TV tuners, rumble paks, card scanners, and much more. While the Glucoboy was the end of the Game Boy's impressive 18 years of innovation, that same spirit persisted, extending into the next generation of handhelds. What started in 1989 with the original DMG-01 and its humble Link Cable continued well into 2010 and beyond.

As far as I'm concerned, that's case-closed for the Glucoboy. Maybe one day we'll be able to emulate the entire device on a low-level and require actual blood samples from the user! For now, I think it's well enough to generate the GRPs via high-level emulation. We also came away with some pretty solid hardware documentation, which is always great. Another foe from the Triforce of Terror has fallen. The Play-Yan is mostly a done deal, with only audio/video output needed. Its cousin, the Nintendo MP3 Player, is slowly but surely cracking as well. The Glucoboy, possibly the most evasive of the trio, has been vanquished. Only one villain yet remains undispatched: the conniving Campho Advance. With a seemingly undumpable ROM, an extremely rare cartridge, and a complex architecture capable of video transmissions over landlines, the Campho Advance poses one of the most challenging obstacles to fully preserving the entire Game Boy Advance library. Will the heroes succeed in their mission, or will the Campho Advance prove too much for them? Find out in the next episode of Edge of Emulation!