Where the donk does mGB store its channel 3 waveforms?

June 30th, 2014

mGB, trash80’s Gameboy MIDI synth for use with Arduinoboy has support for selecting various waveforms for use with channel 3. If you look at the data loaded into wave RAM and search for it in the ROM you find nothing. Is the data generated algorithmically, perhaps? Let’s look into it.

I may actually have the mGB source code lying around somewhere, but this is easy to figure out using BGB. First add an access breakpoint (debug, access breakpoints) to FF30 (the lowest address in the channel 3 wave buffer) and hit run. If mGB was already started, change the waveform or reset the CPU to make the write happen again.

If you read the code, it seems like the waveform index is loaded from somewhere, and is then added to C14D, an address in RAM. If you go to that address in the data panel in the bottom of the window you can confirm that there are indeed waveforms there. Let’s place a write breakpoint to the address in RAM, maybe disable the old one, and rinse and repeat.

The code that creates the waveforms in RAM consists of a long row of instructions on the form

ld  de,C14D
ld  a,01
ld  (de),a
ld  de,C14E
ld  a,23
ld  (de),a

This is likely the GBDK C compiler’s output from something like…


…and so on. Or this may just be an example of the compiler doing something really stupid when you define a const array. The performance and size of such code compared to an optimized alternative is not exactly flattering, but that doesn’t matter much in this case.

In other words, the actual data starts at address 3C9C and is spaced out so every 6th byte is waveform data. Above, the bytes for 0th waveform (starting at the hex editor’s cursor) are marked in a light, not-quite-cyan, blue. Click for a bigger image.

Can we do it better? Let’s try to patch the ROM to store the data in a linear fashion and then copy it into the position in RAM where it is later used. Or even better – as the wave data is not likely to be modified after the being copied into RAM – make the program read them directly from ROM instead of from RAM.

First start mGB and grab the wave data from RAM, for use later. First a back of the envelope calculation: there are 16 waveforms, each of size 16 bytes, leading to a total of 256 bytes. When mGB is at the main screen, select file, memory dump in the debugger. Choose a place to save the dumped file. We know from above that the data is stored starting at C14D, so enter that as the starting address. As size, enter 100, hex for 256.

Then go to 3C98 in the disassembly, which is the first instruction of the row of instructions that are used to fill up the wave data in RAM. The similar instructions before that one are used to initialize other memory. Don’t touch those.

We know form above that there are 256 bytes of wave data. We also know that it takes 6 bytes worth of instructions to copy one byte to memory. This means we can now calculate the end of this code area, or rather, the first address containing other code as 3C98+(100*6)=4298 (all hex, mind you!) You can now go to this address in the disassembly to confirm it’s correct. Press ctrl+G and enter 4298.

The group before that position reads

ld  de,C24C
ld  a,03
ld  (de),a

C24C is 255 bytes after C14D, and the next byte being written to, C254, is non-consecutive. This means 4298 seems like the correct address to jump to.

Now go back to 3C98 and create a jump to 4298. You can do this by simply placing the cursor at the correct place and starting to type jp 4298. When you type the first character, an assembler winow pops up to let you continue writing the instruction. Pressing enter or clicking ok will assemble the opcode. If all goes well you will now see it in the disassembly.

So, now to plan for where to put the 256 (100 hex) block of data. The area 3C9B-4297 is now “dead”, consisting of code that will never be executed. We could now place the data directly at 3C9B and 100 (hex) bytes forward. Or we could make our lives easier when editing and put the data at something easy to remember 4000 and 100 (hex) bytes forward. Any area that fits within the now dead memory area is ok, which is true for 4000-40FF.

Now press ctrl+G and go to 28B3, which is the place where the base address for the waveform lookup is loaded into the HL register. Start typing ld hl,4000 and press enter.

Time to save the file. Normally I would recommend to do file, fix checksums at this point, but since the file will be further edited, the checksum will change later anyway. So select file, save ROM as and save the file, preferably under a new name. Use whatever method your hex editor provides (or doesn’t provide) to overwrite 100 (hex) bytes from 4000-40FF. In my trusty ol’ xvi32, I had to first delete 100 bytes, then select file, insert and select the file previously saved containing the waveforms.

You can select an address to go to by pressing ctrl+G. You can select characters by selecting edit, select chars.

A better hex editor may have a better method of overwriting an area with data form another file.

Confirm that the newly inserted waveform data is located at 4000 and not anywhere else. Press ctrl+page down to go to the last address. Confirm that the file is the right size by checking that the last address is FFFF or 65535 (depending on whether you are on the hex or character side of the display.) Save.

Load in BGB and confirm that the ROM doesn’t crash. To get the right warm fuzzy feeling inside, select file, fix checksums and then file, save ROM as, again.

For your convenience, you can download the modified ROM here.

Furrtek’s Airaki: quick game review and ROM dump download

May 14th, 2014

Furrtek's Airaki: envelope and contents

I’ve got mail! What’s inside? A cartridge of Furrtek’s second, and so far, latest game Airaki. The envelope (as well as the title field in the ROM header) is marked with the number 1, suggesting I’m receiving the first cartridge of this batch. The cartridge comes in a resealable “drug bag”, and there’s also an instruction sheet explaining the game mechanics.

Furrtek's Airaki: front of the cartridge

The game comes in a generic “game” shell, a type often used by pirates. The cartridge has a label with our muscular furry hero holding his massive sword in an erect position. *cough*
Read on…

Dell PSU third pin fix

April 25th, 2014

A few years ago, I bought a PSU for my Dell D600 on eBay which turned out to be a really crappy Chinese pirate PSU which suffered badly from interference. When I wanted to fix the interference by connecting the plug to a different, and genuine Dell PSU, I stumbled upon a problem. All modern Dell PSU’s have a ID feature to confirm that the PSU is genuine, using a 3rd pin center pin connected to an EEPROM. If this chip does not match, the laptop won’t allow the battery to be charged. While a less scrupulous 3rd party manufacturer can nag one of those ID chips from a broken genuine Dell PSU and pass the test with a any poor quality PSU, I had to transplant this ID chip somehow, to make the PSU work.

New PSU cable splice New PSU cable splice

I recently got another Dell laptop with a broken PSU, which I could have if I could fix the PSU. Like last time, I decided to splice the cable with a board containing the chip.

Dell power adapter ID chip board

This board was made from veroboard, and ws a bit bulky, so I decided to design and order a new one. This posted is an illustrated guide to how this board is used.

Dell power adapter ID chip board

Read on…

Pocket Music GBC version GBA fix

December 17th, 2013


Pocket Music for Gameboy Color refuses to run on GBA. It shows a screen similar to when you run the game on a monochrome Gameboy, saying “this game is intended only for use with a Gameboy Color.”

Maybe they decided to do this because the sample playback sounds like crap on GBA. This patch fixes both those problems. It bypasses the GBA check so you can use Pocket Music on GBA, and it uses my “antispike” fix (also seen in LSDj) to almost completely remove the whine from the sample playback.

Use an IPS patcher to apply the patch to the Pocket Music GBC ROM.

Download here

Gameboy project week 9: The EMS cartridges: Something old and something new. Something black and something blue. And how sloppy cartridge design affects you.

March 4th, 2013

EMS Gameboy cartridges

Top left: EMS 32M cartridge, rev 2. Top right: EMS 32M cartridge, rev 1.
Bottom: EMS 64M USB cartridge.

The HKEMS company is probably the oldest manufacturer of Gameboy flash cartridges still in business. Among the original era companies, the most famous was probably Bung, but it eventually collapsed under the legal threats from big N. EMS survived, however, and continues to develop its line of products, including their 64 Mbit GB cartridge.

There’s a thread in the Gameboy dev subforum of NESDev about trouble using the cartridge with certain games. In that thread, I said in good faith that EMS cartridges have good emulation of MBC1’s quirks, but also that I needed to investigate it further. Which is what I’ve done this week. And, I was wrong, at least regarding the newer cartridges.

First a bit of background: The Gameboy CPU is an 8 bit CPU with a 16 address bus. This allows the CPU to address up to 65536 bytes of memory. In that space, it needs to fit all it’s ROM, RAM and control registers. If you want to address more memory than that, you cannot do it directly, but need to employ a method called bank switching. This is done by a chip called an MBC (memory bank controller) which is situated on the cartridge. The normal memory layout seen by the GB CPU is one 16 kiB area of ROM called bank 0 which never changes, and one selectable 16 kiB area to which any 16 kiB window of the ROM (with a couple of exceptions) can be switched in. In bank 0, a game or program can store code and data it wants to have easily accessible.

However, for a flash cartridge this might present a problem if you want the user to be able to choose between different games/programs stored in the flash memory. This is where multi ROM capabilities come into play. Just like the banking lets you select a small window of memory that is visible in the Gameboy memory map, multi ROM lets you select an area of the flash chip which then appears to the Gameboy as a Gameboy cartridge.

From the hardware point of view, there’s an interface that lets you select which portion of the flash chip should be visible to the Gameboy CPU by performing a sequence of writes. If well designed, the multi ROM commands should not conflict with any other commands normally used by any type of MBC, or by writes which exist in a few games especially designed to mess up multi ROM and similar extended functionality and crash the program (as anti piracy feature.)

On the software side of things there’s a menu ROM which scans the flash memory for valid ROM images, presents a menu, and after a user selection performs the special menu sequence to switch the ROM, and finally jumps to the ROM entry point.

I sat down to investigate exactly what the menu ROM does, and what effect each command has on the cartridge. You can see the full report HERE. But here are some points I discovered:

The USB 64M cartridge (as well as the second revision of the blue, pre-USB 32M cartridges) have reduced functionality compared to the original revision of cartridge. This means that some ROMs will have to be patched in order to run on the cartridge in the future as well. Bummer!

The default menu ROM leaves SRAM open (unprotected, [$0000]<-$0A) without good reason. This could potentially trash one bank of SRAM, especially for games that don't use SRAM because they won't enable the SRAM protectopn again.

From a quick glance, it seems like the EMS 64M USB utility finally aligns the ROMs correctly to size boundaries when flashing multiple ROMs through the application. However, the menu still has trouble finding some ROMs in an experiment I did.

The EMS application also pads the files with $00 (all bits zero) instead of $ff (all bits one) which will contribute a microscopic amount to wearing out the flash faster. Will it actually matter, nah, but it’s a sign of not paying attention to detail.

LittleFM 0.5.1

LittleFM EMS multi ROM error
As a proof of concept, I’ve released LittleFM 0.5.1 with integrated EMS multi ROM support. As it is a proof of concept, it does not come with a special patcher, check that ROMs are correctly aligned or handle save data at all. However, to show that I paid attention at least slightly to detail, it does not show repeated entries when used in an emulator, and also gives you an error message if the switching failed, unlike most similar menus.

You have to prepare a ROM yourself, by first patching an LSDj ROM with LittleFM as usual, then concatenating whatever ROMs you want at the end, respecting the alignment of course.

copy /b lsdj-4_7_0-lfm.gb + rom1.gb + rom2.gb out.gb
cat lsdj-4_7_0-lfm.gb rom1.gb rom2.gb > out.gb

Then burn out.gb as the only ROM onto your EMS cartridge, USB or non-USBB. Press start to bring up the EMS multi ROM menu.

Since it doesn’t do save management or anything fancy it’s kind of pointless except maybe for musicians who want noise maker ROMs alongside LSDj on a cart. A future version will be able to store save data in a (compressed) LSDj-like file system, and also come as a standalone menu replacement without LSDj. But that’s for the future.


Looking elsewhere, you have the newly developed menu by MottZilla which I haven’t tried but I’m sure it’s decent. (Discuss on NESDev.)

Gameboy project week 8: The white Nintendo Power official flash cartridge, a tale of reverse engineering, sweat and tears

February 25th, 2013

npdump-130224 026

This week’s project concerns this cartridge, the official Nintendo Power flash cartridge. It used to actually be sold by Nintendo for 2500 yen and you could by games from a special kiosk starting at 800 yen at the Lawson department store. (About US$27 and US$9 respectively at today’s exchange rate.) The kiosks are long gone, but the cartridges remain in the wild. (However one page in Japanese from the time remains. It mentions how the launch is delayed because of the earthquake in Taiwan, the massive 921 earthquake)

Since these are flash cartridges they are in theory writeable, which would make them useful for, for example Little Sound Dj or other homebrew software. However, writing to them has proven difficult. The currently only known way of writing to them is with a software called FMGBx by Mootan. The program works but requires flasher hardware that is difficult to get and and in all cases are using an LPT port interface. Options include Bungs GB Xchange, a modified GBA flasher and two homebrew solutions using discrete 74hc logic. Clearly, there’s room for improvement.
Read on…

Rez - a unique Gameboy synth ROM

December 11th, 2012

 |  _ \ ___ ____
 | |_) / _ \_  /
 |  _ <  __// /
 |_| \_\___/___| by nitro2k01

What is it?

Rez is a unique synthesizer program for the Nintendo Gameboy. It crudely simulates a resonant filter in a way inspired by the resonance algorithm used by the Casio CZ series phase distortion synthesis. Whether I’ve come close to this type of synthesis, I leave to the users of the program to decide. It can both produce sounds meant to emulate this effect, and sounds more reminiscent of a hard sync oscillator. It also produces a graphical pattern on the Gameboy screen.

During the development of this program, I’ve encountered a number of subtle issues with the DMG hardware, which you can either see as bugs or charming features of the hardware being (ab)used.

What should you run it on?

Rez is intended to be used on real hardware, in particular on a DMG, the original “brick” variety of Gameboy. If you wish to use an emulator, BGB and Gambatte are good choices.

Honorary mentions go out to no$gmb, TGB Dual and smygb02 for sounding glitchy in ways that may be interesting, even though they sound nothing like intended.

How does it work?

In this version, the controls are simple. Up and down control the “resonant frequency”. Left and right control the “fundamental frequency”. Currently, the synth is not tuned to any scale, so you need to manually tune it if you wish to use it with other instruments.

The values of these parameters are shown on the screen: The four hex digit value is the resonant frequency and the two hex digit number is the fundamental frequency.

A and B toggles between different waveforms which gives the resonance a different character, from relatively smooth to harsh to a hard synced sawtooth oscillator.

On the far right (press A you can’t get any further) there’s a clean sawtooth waveform. This waveform is unaffected by the resonant frequency setting and may be useful for tuning the fundamental frequency to another instrument.

There’s a bug in the DMG hardware which sometimes causes the waveform stored in the channel 3 wave RAM to be corrupted. You can press start to enable a workaround for this issue, at the expense of a slightly different timbre. You may also choose to leave this off which randomly and radically changes the waveform.

Pressing select shows the current contents of the wave RAM. This is a debug feature that I used to debug the wave RAM bug. It may be of interest if you’re curious.

All buttons can be used simultaneously.
TIP: Find a “sweet spot” resonance and fundamental setting and alternate between holding left+up and right+down. This increases one setting and decreases the other. This can give some nice effects.

Future versions

I have plans for more features for Rez, including among other things better ways of controlling the parameters. I don’t want to promise too much yet, but MIDI input support (using Arduinoboy or Nanoloop MIDI-USB) may be plausible. But I felt that I wanted to get a version of this out the door to avoid tweaking the program indefinitely and never releasing it.

Rez is not shitwave 2. Don’t believe the rumors.

Download and sound samples

Download Rez.

(Early) sound sample on SoundCloud, during development.

Better sound sample by Victory Road showing more of what Rez can do.

Interesting question, if 1=5, 2=10, 3=15, 4=20… what is 5=? (Trolling with maths)

November 13th, 2012

Interesting question, if 1=5, 2=10, 3=15, 4=20... what is 5=?

This image has been going around Facebook lately. What is the answer?

Read on…

Gameboy clone “Game Fighter” teardown

November 11th, 2012

Game Fighter, Gameboy clone

Original Gameboy clones are a rarity. Whereas you can get clones of NES, SNES, Megadrive/Genesis and even Gameboy Advance with relative ease, Gameboy clones were made in small quantities back in the day, before the factories got shut down, and the few pieces that exist are now collecting dust in someone’s basement. Or so it seems.

I’ve been trying to get people to lend me one of these units for science, without success. So when a long-time member of #gbdev (on EFNet) informed the channel he had bought one from a local auction web site and wanted to pass it on, I happily accepted the offer. Here’s the result, hi-res photographs of the circuitry inside and comments on the design of the unit. If you have Gameboy clone that you want to lend me for a similar teardown please contact me.

So, the unit I was sent is of the brand Game Fighter. What’s unique about this unit, compared to other knockoffs, is that despite its horizontal layout, it follows the DMG (Dot Matrix Game; the product number prefix of the original Gameboy) design patterns relatively closely. Two such design patterns are the ridged pattern on the top and back of the unit, as well as the bevelling on the lower left and right corners.

It doesn’t look as tacky as, say, the Mega Duck or the Fortune Hand Game with its unibrow style select/start button. (See comparison.) If it wasn’t for the Street Fighter styled Game Fighter logo on the screen cover (which is missing on my unit) this could very well pass for an official Nintendo prototype.

Read on…

Flash cartridge friendly versions of PixelH8’s GB tools

July 20th, 2012

Here’s a quickie: PixelH8’s Gameboy tools are known to crash when used on a real Gameboy with flash cartridges. The cause of this is a simple programming mistake that I was able to fix easily, so here are patched versions of the four Gameboy ROMs.

http://gbdev.gg8.se/files/musictools/PixelH8/ (Click pixelh8-fixed.zip)

Out of the tools, I personally find Deathray to be the most interesting, as it can create some harsh and unique tones that are worse than Shitwave.

If you happen to own one of the originally released cartridges, I’m interested in knowing if there’s a difference between the “free” versions and the retail version. Or even a ROM dump.