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
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.
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.
Gameboy project week 8: The white Nintendo Power official flash cartridge, a tale of reverse engineering, sweat and tearsFebruary 25th, 2013
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.
____ | _ \ ___ ____ | |_) / _ \_ / | _ < __// / |_| \_\___/___| 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.
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
(Early) sound sample on SoundCloud, during development.
Better sound sample by Victory Road showing more of what Rez can do.
This image has been going around Facebook lately. What is the answer?
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.
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.
Today the Handheld Heroes compilation was finally released. It comes in two versions, a digital download version with only MP3’s (or whatever formats Bandcamp offers) and one physical DVD version with a number of extras. One of those extra items is an LSDj ROM with four of the songs from the album in an LSDj player that I made, as well as a funky menu to select a song from. The player stores the songs in ROM space and does not require SRAM to work. The video above contains a short demonstration of this ROM.
The songs included in this ROM are as follows:
- Maru303 - Orgypsy Dubstep
- Bokusatsu Shoujo Koubou (BSK) - Handheld Heroes
- nordloef - A New Dawn
- Saskrotch - Handheld Hullabaloo
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.
Everybody is so negative about SOPA and PIPA and ACTA. Nobody sees the opportunities! In the US legal system, plaintiffs who can prove willful infringement are entitled to up to $150,000 per work in damages. Let’s make a conservative estimate that a million Americans have downloaded 100 songs each. This would mean potential damages of $15M ($15,000,000) per person. Across a million people, that’s 15 million million, or 15 trillion US dollars in damages.
What does this number remind you of? You’re right, the US gross public debt. So hear me out on this modest proposal. Use this money to pay back the public debt. Then give each of the million people a 400 year prison sentence (not unheard of in the US) and let them work their asses off for 400 years to pay back the debt that is now on their shoulders. (Should anyone try to die from natural causes prior to the end of the sentence, you simply threaten to kill the person in question, which is usually enough to make him or her want to stay alive.) Putting another million people in prison won’t even double the US prison population, so the relatively small increase would hardly be a strain on the American correctional supervision system.
It’s doubtful whether anyone could object to this modest proposal which would instantly solve the two biggest problems America is facing today, copyright infringement and rampant public debt.
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.