It is currently Mon Jun 18, 2018 8:35 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: State of GB repro boards
PostPosted: Thu Dec 14, 2017 6:18 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 746
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 ;)


Last edited by calima on Thu Dec 14, 2017 12:32 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 12:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 12:14 pm 
Offline
User avatar

Joined: Tue Nov 28, 2017 2:40 pm
Posts: 13
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 12:28 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 12:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
Adding emulator support for self-flashing is the hard part, not making a discrete logic mapper that's compatible with an MBC5 subset.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 12:46 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 746
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 1:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
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...

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


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 1:29 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 2:13 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 746
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.


Top
 Profile  
 
PostPosted: Thu Dec 14, 2017 2:39 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1606
Location: Gothenburg, Sweden
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.

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


Top
 Profile  
 
PostPosted: Fri Dec 15, 2017 5:07 am 
Offline

Joined: Sat Aug 28, 2010 9:01 am
Posts: 219
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)


Top
 Profile  
 
PostPosted: Fri Dec 15, 2017 11:02 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Dec 15, 2017 12:06 pm 
Offline

Joined: Sat Aug 28, 2010 9:01 am
Posts: 219
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.

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


Top
 Profile  
 
PostPosted: Fri Dec 15, 2017 12:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
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.

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


Top
 Profile  
 
PostPosted: Fri Dec 15, 2017 12:51 pm 
Offline

Joined: Sat Aug 28, 2010 9:01 am
Posts: 219
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".

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group