Can Everdrive-GB run homebrew?

In this topic, Great Hierophant claimed that the EverDrive GB makes all other Game Boy flash solutions obsolete.

From the product page at kitsch-bent:

• "compatible with all systems which support GB and GBC cartridges, including Super Game Boy"
  But the cartridge appears to no corner cutout for the power switch, so it'll fit in a Super Game Boy, Game Boy Color, Game Boy Advance, Game Boy Advance SP, or Game Boy micro, but not an original Game Boy or Game Boy pocket. There's a cutout on the PCB inside, but with SMT at that pitch, dust might pose a problem.
• "support for Game Boy and Game Boy Color games (official titles)"
  Does "(official titles)" mean it's like a RetroN 5 and won't run homebrew? This parenthetical doesn't appear on the page on krikzz.com.
• "simple menu"
  If it does run homebrew, what rules of thumb should one use to avoid inadvertently relying on the difference between the state of a Game Boy with a "normal" cartridge after the intro animation and the state after having run this menu?

I have an Everdrive GB, but used it very little. I certainly didn't try any homebrews yet, but knowing krikzz's products I don't see why they wouldn't work. As for the case, I believe the ones sold by krikzz himself do fit all Game Boys, but I'm not sure. Will check later on my GB Pocket.

EDIT: Just looked at a photo on krikzz's and you're right, the case is similar to a GBC one. I've seen people using classic cases though.

Tried a few homebrews/protos/hacks/translations/etc. and everything ran fine. I think the only thing that didn't run was those NES ROMs.

When I bought mine, it didn't come with a shell (you had to hack up your own), but the ones they currently offer do have a small slot for the DMG's power switch.

PS. Does not fit in Game Boy Micro, since the Micro only supports GBA carts And GB Pocket doesn't need a notch, just the DMG.

I expounded on its virtues more here : http://nerdlypleasures.blogspot.com/201 ... e-boy.html

It fits in a DMG Game Boy just fine and works in it too. There is a cutout on the back of the case that allows the power button tab the room it needs.

The rules for homebrew are simple, if the game uses no MBC or the official MBC 1, 2, 3 or 5 (or compatible clone or emulator, it should work. If it uses custom hardware then it won't. When you turn the system on, it boots to the menu after displaying the Nintendo(R) or GAME BOY Nintendo(R) logo. Then you select a game and the system reboots (except on Super Game Boy), displaying the logo again. That way homebrews should have no issues with the protection check, just like regular games.

I saw on Krikzz' forum though that Everdrive GB seems to have trouble with the Nintendo 64 GB-Pak device. That's one thing that makes old MBC5 based flashcarts still useful.

w00t, a Gameboy flashcart with an SD card interface?! $92 is a bit pricey, but I foresee a puchase in the near future. Being able to keep everything on one cart, not having to worry about overwriting saves, etc sounds nice.

That's the standard for flash carts nowadays... once you get used to that, it's hard to go back to the pain that is working with less capable devices.

Was there anything you needed tested?

A random sampling of PDRoms perhaps. I was planning on getting into Game Boy homebrew sometime, even if only to write client programs for connecting a Game Boy's link port to the second NES controller port.

I have the feeling that "official titles" refers that it most likely doesn't include support for custom mappers used in unlicensed games.

Yeah it's said to support only official memory controllers between MBC1-5 except MBC3+RTC. I think that as long as you make your homebrew within specs and fix the header checksum, there should be no difference between it and a retail ROM.

Even if the initial state of the Game Boy are messed with by the Everdrive, a game probably shouldn't rely on their initial values anyway, since those values differ a bit between Game Boy models.

Isn't the initial state rather unpredictable in practice? (in fact this is one thing that annoys me from the Everdrive flashcarts, since they have a firmware they initialize the hardware before the game starts, so if you have an initialization bug in your game you will not be able to catch it using them).

True, it's probably best to test homebrew on a custom cart as well before releasing it.


The bootstrap ROM runs initialization routines before loading the ROM cart, so it is somewhat predictable (although for example DMG and CGB works differently). It sets up sound and other things so a Game Boy game doesn't need as much init code as a NES/Famicom game does.

Or a flashcart without firmware. But yeah, especially if you plan to release cartridges anyway (as opposed to just a ROM, in which case at worst you just release a patch).


Oh right, forgot about the Game Boy's own firmware (but there's no guarantee that the Everdrive firmware will leave it in the same state).

Maybe, but I think the Everdrive uses the reset line to reset the Game Boy so that the bootstrap should load up again. On Super Game Boy you would have to reset manually though.

Can the SGB reset the Game Boy? If so, the menu could possibly upload a small amount of Super NES code that does the job.

There is no SGB command for resetting, but you can send 65816 code so maybe there's a way to reset it like that.

BTW there are apparently games that rely on the initial state. You can detect what Game Boy system the game is running on by reading the accumulator after boot. If it's $FF it's either a Game Boy Pocket or Super Game Boy 2. Tetris DX does this to check if it's running on a SGB2, and if it does it will load up a different SGB border.

I think the question was whether the SGB hardware itself actually provided means to reset the Game Boy, even if that requires poking into it directly.

If you need to reset the Game Boy CPU of the Super Game Boy from software, it should be possible.

You could run code uploaded to the SNES RAM via SGB commands: DATA_TRN/DATA_SND (DATA_SND is more efficient for small transfers, since you don't need to setup VRAM to send the message, you just use the joypad port), then JUMP. You'd need a short 65816 routine to clear bit 7 of $6003 (according to http://www.dforce3000.de/pub/d4s_super_gameboy_notes.pdf). This would reset the GB side, and then you would need to JMP to the reset vector SNES-side to allow recovering from the SGB JUMP command.

Actually, I wonder if the reset handler of the Super Game Boy already causes a GB CPU reset on startup? Then your routine could just JMP ($FFFC) and skip the $6003 writes altogether.

I just want to point out that LSDJ support is poor, and the reason I got rid of the device is that it takes ages to load a new rom as it's written to flash memory, rather than loaded into SRAM or SDRAM with an appropriate controller.

It was not meant for LSDJ, it was meant for games. There are other cards more suitable for chiptune musicians. There is something of a tradeoff between the flashing speed of the EDGB and the vast amount of ROMs available on an SD card, but a 4MB ROM can be flashed in under a minute. Its also has vastly improved compatibility for games. Compared to the klunky interfaces and limited ROM support of the LSDJ cards, it is a revelation. Krikzz is also planning to release RAM-based versions of some of his flash Everdrives (SNES, Master Sytstem, Game Gear, Turbo Grafx-16 and Game Boy) which should make complaints about loading times disappear.

The RAM versions are always significantly more expensive though, so many people still prefer the Flash versions. My reasons for wanting RAM-based carts are not related to speed at all, I simply don't like the feeling that I'm causing my carts to deteriorate a little every time I load a new game, even though these Flash chips will probably outlive me at the rate I get to use my Flash carts...

Here are Krikzz's comments from February, 2015 from his site, about RAM-based Everdrives :

This is the reason I pointed out the speed. At the very least some form of naive wear leveling would have been a nice upgrade.

The reason the speed is irritating is that I found myself more frequently choosing games I know and being less willing to explore new ones - if it's going to take so damn long I had better know I will enjoy the game. At that speed, you can compete with the device using an old EPROM dev cart and a 29F* Flash ROM with a PC-based burner. Obviously no competition for portability, but it's just remarkable how long it takes.

I just pick my games using emulators before copying them to my Flash carts, so...