Gameboy Genius

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

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

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.

Download

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.)

Posted in Uncategorized | 9 Comments »

Rez - a unique Gameboy synth ROM

  ____
 |  _ \ ___ ____
 | |_) / _ \_  /
 |  _ <  __// /
 |_| \_\___/___| 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.

Posted in Uncategorized | 5 Comments »

Flash cartridge friendly versions of PixelH8’s GB tools

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.

https://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.

Posted in Uncategorized | 2 Comments »

BGB 1.4 Gameboy emulator/debugger released

Today BGB 1.4 by beware was released. BGB is a Gameboy emulator and debugger. BGB 1.3, released little over a year ago focused mostly on emulation accuracy. It was the first update to BGB for 5 years and brought BGB past KiGB (which is actually a “compatible” emulator rather than a terribly accurate one, despite bold claims.) and up to par with Gambatte.

My personal interest in BGB is mostly the debugger. My choice, before BGB 1.4 existed, was between no$gmb, which had the better debugger, and BGB which had the better emulation. After a lot of persuasion, I managed to get beware to implement a number of debugging features, some of which existed in no$gmb and some of which were new requests. The big new debugger features are support for debug symbols and an “online” assembler which allows you to immediately start typing instructions or data to be assembled to the cursor position. Plus a big number of bug fixes, small improvements and optimizations in all areas of the program.

One noteworthy feature (which I’m not personally is not very interested in) is improved link port emulation for games. In particular, pawkemanz linking now works reliably, as do Tetris and LSDj.

And lastly, an invitation to anybody interested in Gameboy development: please join the IRC channel #gbdev on EFNet.

Posted in Uncategorized | 1 Comment »

Korg monotribe Firmware 2.0 analysis

As has already been established, Korg monotribe is MIDI capable. Howver, it is still limited with regard to certain things, such as being able to use more than 8 seqeuncer steps for the synth part or using a filter envelope separately from and LFO. All things that should be very much technically possible on the microcontroller device in the unit. One thing I’ve considered is to modify or even rewrite the firmware of the ‘tribe. Apart from the obvious work of actually rewriting the firmware, you need a way of flashing it onto the device. And preferably a copy of the original firmware, so the ‘tribe won’t be a useless brick until development is done. The microcontroller in the monotribe does support JTAG, a protocol for reading and writing firmware data, among other things, but this function may be locked down for security reasons.

Korg recently announced the 2.0 firmware for the monotribe, which actually gives you 16 step, velocity control and a few other new features. More full information and download available on Korg’s homepage.

But what’s interesting about this upgrade is how you install it. You hold a secret key combo of three buttons on startup to go into upgrade mode, and then play a special audio file into the sync jack to perform the actual upgrade. This is potentially an easy way to hack the firmware of the monotribe (although with the same risk of bricking.)

Below, I’m posting the first step towards that goal, to extract the firmware image from the audio file. First, a big thanks to Th0mas for doing the initial groundwork of figuring out how the data is encoded. In fact, my code below below relies on having a transformed and cleaned up version of the audio data.
Read on…

Posted in Uncategorized | 6 Comments »