State of GB repro boards

Discussion of programming and development for the original Game Boy and Game Boy Color.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

State of GB repro boards

Post by calima »

Gathering up all GB(C) repro board info in one place.

- BitBuilt:
---- 2mb + RTC + 32kb SRAM, MBC3, 45$
---- other versions too, but their store is down, and google cache only has that
- J. Rodrigo:
---- 2mb + 32kb FRAM, MBC5, 37.70$
---- 4mb + 32kb FRAM, MBC5, 47.20$
- BennVenn:
---- 2mb + SRAM, MBC1/2/3/5, 20$
---- 2mb + FRAM, MBC1/2/3/5, 24$
---- 4mb + SRAM, MBC1/2/3/5, 24$
---- 4mb + FRAM, MBC1/2/3/5, 28$
---- 4mb + SRAM, unknown mapper, 13$
- CatSkull (Sheep It Up):
---- 32kb, 10$
- RetroStage
---- 4mb + FRAM, MBC5, 18.50
---- 8mb + FRAM, MBC5, 21

Then there are Chinese Pokemon clones at about 4$, but they come with the usual quality issues, saving issues, wrong voltage parts, etc. Doesn't seem too good right now, even with volume discounts publishing homebrew wouldn't be too tenable. BennVenn's cheaper cart might be ok if it comes with a decent mapper, but his products are out of stock 95% of the time. If I missed an option, please post.

Sheep It Up had custom boards made, at least one release used the Pokemon clones, no idea what Tobu Tobu Girl uses. I recall INL saying it'd be nice to get into the Gameboys, competition would be welcome ;)
Last edited by calima on Wed Feb 26, 2020 1:17 am, edited 2 times in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: State of GB repro boards

Post by lidnariq »

One of the major problems is that Micron just discontinued their 2 MiB 5V flash, leaving only Macronix with 1 MiB 5V parts (and other vendors of even smaller parts). The carts are small enough that fitting in any voltage translation is tricky.

On the other hand, if people were actually going to start making new games rather than moonshine, simple discrete logic mappers with self-flashing and without RAM support are simple, fit easily, and don't provide meaningfully fewer features than the OEM options.
User avatar
tmk
Posts: 14
Joined: Tue Nov 28, 2017 2:40 pm
Contact:

Re: State of GB repro boards

Post by tmk »

calima wrote:Sheep It Up had custom boards made, at least one release used the Pokemon clones, no idea what Tobu Tobu Girl uses.
Sheep It Up, and Tobu Tobu Girl - this looks like those Pokemon clones.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: State of GB repro boards

Post by tepples »

lidnariq wrote:if people were actually going to start making new games rather than moonshine
I'd be glad to pitch in if there were a good resource for making the transition from 6502 or full Z80 to LR35902, in particular how object state data should be organized for a player or enemy movement routine in a platformer, shmup, etc.
lidnariq wrote:simple discrete logic mappers with self-flashing and without RAM support are simple, fit easily
The trouble with discrete logic is how it'd be made compatible with existing emulators that expect the MBC family.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: State of GB repro boards

Post by lidnariq »

Adding emulator support for self-flashing is the hard part, not making a discrete logic mapper that's compatible with an MBC5 subset.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: State of GB repro boards

Post by calima »

Thanks, I wasn't aware the Sheep folks were selling theirs, added. Tobu is indeed a Pokemon clone, 5V SRAM but 3V flash.

@lidnariq
Krikzz managed it I believe, with the Everdrive GB X series?

Self-flashing for saves does come with issues: how to prevent bricking if the user turns off during writes/loses battery power, if a code bug causes writes to the main area, and how to handle wear leveling (with the worst flash cells only tolerating tens of writes before dying). I think that to be safe, such a board would need a separate chip for the saves, and it would have to be higher quality flash, or include wear leveling inside it/with a controller.

@tepples
Emulators aren't an issue for development, well as long as you don't want to use proprietary ones like BGB. Adding support for mappers is quite easy.

If you mean for users, like with the fceux revision, that does pose an issue if you want your game easily playable as a ROM. Perhaps include the emulator next to your ROM download then.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: State of GB repro boards

Post by lidnariq »

calima wrote:Everdrive GB X series
picture of one Yeah, I said tricky, not impossible. I was expecting it to have to be a 4-layer board, but looking at this picture I think he managed to get away with a 2-layer one...
Self-flashing for saves does come with issues: how to prevent bricking if the user turns off during writes/loses battery power, if a code bug causes writes to the main area, and how to handle wear leveling (with the worst flash cells only tolerating tens of writes before dying). I think that to be safe, such a board would need a separate chip for the saves, and it would have to be higher quality flash, or include wear leveling inside it/with a controller.
Wear leveling is a bigger concern in NAND flash, and especially multilevel NAND flash, than NOR flash.

Micron calls out wear levelling as an additional concern for NAND flash relative to NOR flash.

Cypress (i.e. Spansion) discusses wear levelling on NOR flash, but also points out that typical program-erase count limits for NOR flash are orders of magnitude greater than for NAND flash.

Also, I'm specifically referring to making new carts using the same SST39 parts as are currently used by mappers 29, 30, and 111, which already use the same NOR flash for saves. While "we're already doing that" isn't a good enough argument by itself, I don't think I've heard of people having problems with bricking their games that use those boards.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: State of GB repro boards

Post by tepples »

Saving can be done by reserving the last* 4 or more erase sectors of flash for a log-structured file system. It might consist of a circular buffer containing (file ID, version, length, data, checksum), where the total area is at least twice as big as the intended save capacity. A file is "superseded" when a file with the same ID and a greater version exists. When free space comes close to 1 sector, the un-superseded files from the oldest sector are copied to the free sector, and the source sector is erased to become the new free sector.


* On Game Boy or Game Gear, you'd reserve the last sectors. On NES, you'd reserve the first sectors because the last contain the reset vector.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: State of GB repro boards

Post by calima »

With the batteries being an additional weak point vs NES, I'd really like some extra assurances that the game code can't be bricked, no matter what.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: State of GB repro boards

Post by FrankenGraphics »

lidnariq wrote:if people were actually going to start making new games rather than moonshine
Since i saw sheep it up it has been on my 2018 agenda to get into making graphics and music for gb once another project is crossed off my list as done.

I might be fooled but it seems to me gbdev would allow for smaller projects, at least assets-wise. I could use a bit of that between the long-running NES projects.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: State of GB repro boards

Post by nitro2k01 »

If you only need ROM mapping, a "MBC5" is 4 74 series logic chips (maximum ROM size 1 MiB) or 3 chips (maximum ROM size 256 KiB).
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: State of GB repro boards

Post by lidnariq »

Just to spell that out explicitly: for something compatible with an MBC5 subset, you "just" need to latch on writes to the memory region $2000-$2FFF, or [A15 downto A12] = '0010'. This can easily be done with a 74'138.

In contrast, for a self-flashable option, you need two disjoint memory regions; one for flash write and one for bankswitch write. Fortunately, the gameboy cart slot already decodes $A000-$BFFF for you.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: State of GB repro boards

Post by nitro2k01 »

lidnariq wrote:In contrast, for a self-flashable option, you need two disjoint memory regions; one for flash write and one for bankswitch write. Fortunately, the gameboy cart slot already decodes $A000-$BFFF for you.
Why? If the address is decoded correctly so the bank switch mechanism only reacts to writes in $2000-$2FFF or $2000-$3FFF region, you can use $4000-$7FFF for writing to flash. That is, assuming the cart is only using a single flash chip for everything, which is the simplest, and probably the cheapest solution.

And no, the /CS signal does not decode external SRAM completely. /CS is also asserted on accesses to the GB's internal work RAM, at least on DMG and maybe even on GBC. So you would need some additional decoding, FLASH_CS=CS or A14.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: State of GB repro boards

Post by lidnariq »

nitro2k01 wrote:Why? If the address is decoded correctly so the bank switch mechanism only reacts to writes in $2000-$2FFF or $2000-$3FFF region, you can use $4000-$7FFF for writing to flash. That is, assuming the cart is only using a single flash chip for everything, which is the simplest, and probably the cheapest solution.
See also, having two disjoint regions.

I mean, yes, the flash can overlap the bankswitching register as long as there is some region that the bankswitching register doesn't respond to and the flash does, but this only works because flash is protected with the multi-write sequence to program and/or erase.
And no, the /CS signal does not decode external SRAM completely. /CS is also asserted on accesses to the GB's internal work RAM, at least on DMG and maybe even on GBC. So you would need some additional decoding, FLASH_CS=CS or A14.
... seriously? augh.

I guess that explains why I've never seen any carts that were just 32K ROM with battery-backed RAM then.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: State of GB repro boards

Post by nitro2k01 »

lidnariq wrote:See also, having two disjoint regions.
Yes, but this would not need any additional logic over the pseudo-MBC5 circuit.
lidnariq wrote:I mean, yes, the flash can overlap the bankswitching register as long as there is some region that the bankswitching register doesn't respond to and the flash does, but this only works because flash is protected with the multi-write sequence to program and/or erase.
Yes, but we can now rely on that. If that was ever a problem, there's still something you can do. Only use 4000-7FFF for flash writes. Ie FLASH_WR=WR or ~A14. Not too comfortable for a low chip count circuit though, since you'd need an inversion as well. In practice, this should never be a problem for any chip that's JEDEC compliant. Intel chips need not bother though.

Actually, it WOULD be a problem for one chip I've seen in the wild: AM29F016 (as opposed to AM29F016b or some other variant of the chip.) Not because it was lacking the multi-write sequence, but because the addresses used for it needed all of A0-A14 to be a checkerboard pattern. Literally $2AAA and $5555. In this case, filtering writes would make sense. With that fix, the unlock sequence would become:
[$2000]<-$01
[$5555]<-$AA
[$2000]<-$00
[$6AAA]<-$55
Not the prettiest thing in the world, but it would work in the end.

But other than AM29F016 and any Intel chip, I believe every other chip I've come across would "just work".
Post Reply