nesdev.com

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$

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

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.

Sheep It Up, and Tobu Tobu Girl - this looks like those Pokemon clones.

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.


The trouble with discrete logic is how it'd be made compatible with existing emulators that expect the MBC family.

Adding emulator support for self-flashing is the hard part, not making a discrete logic mapper that's compatible with an MBC5 subset.

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.

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

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.

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.

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.

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.

_________________
http://www.frankengraphics.com - personal NES blog

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

_________________
Gameboy Genius (Blog) - Gameboy development forum (+wiki and file area)

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.

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.

_________________
Gameboy Genius (Blog) - Gameboy development forum (+wiki and file area)

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.

... seriously? augh.

I guess that explains why I've never seen any carts that were just 32K ROM with battery-backed RAM then.

Yes, but this would not need any additional logic over the pseudo-MBC5 circuit.

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

_________________
Gameboy Genius (Blog) - Gameboy development forum (+wiki and file area)