A Sega Genesis repro PCB with FeRAM support

[Soniccd123]

Hello,

I'm a old time reader of racketboy but never posted anything. I've been comunicating with Ziggy587 about his thread http://www.racketboy.com/forum/viewtopic.php?f=56&t=36353, i noticed a lack of cartridge PCBs projects available online for Sega Genesis with save support here and everywhere and also schematics explaining how do they work.

I know that there are ready made PCBs for sale with this purpose but often, for non US residents, they are quite expensive, with PCBs production services being considerably cheaper. Also, this is not a versatile solution considering the needs of each individual

So, with lots of time in my hands thanks to COVID-19, i've decided to build my own cartridge with saving capabilities and make it open and available for the online comunity, thinking about modding possibilities this opens and also to improve my design if needed, as i'm not a engineer, just a amateur who likes electronics.

I also dislike battery backed saves (thats a very personal opinion based on some bad past experiences lol) so i've decided to buid the cart based of non volatile FeRAM. I know this may be not ideal for some people, but as the project is open, this can be easily modified for battery SRAM use.

Finally, here it is: https://github.com/soniccd123/Genesis-FeRAM-Cart

It uses a 27C322 32Mb UV EPROM as the main ROM, a FM1808 256Kb FeRAM for saving and some glue logic. All was designed using KiCAD and can be easily modified for other ROM and RAM types as needed. I've also included a rudimentary DIP switch based bank switching circuit for the possibility of burning multiple files to the ROM. I've already built some units and it works in real hardware with no problems.

I hope this can be useful for someone, i'm open for feedback if any problems arrive and be welcome to make modifications to the board as needed.

Soniccd123

Edit: The gerber files for producing the board are included in the GitHub project.

[Ziggy]

Awesome, thanks so much for sharing this!

I haven't had a chance to look at the schematic yet, but does the dip switches control the ROM and the RAM? Or just the ROM?

[Soniccd123]

Awesome, thanks so much for sharing this!

I haven't had a chance to look at the schematic yet, but does the dip switches control the ROM and the RAM? Or just the ROM?

For now just the ROM, it is possible to control the RAM also, but this needs some thinking, maybe use two DIP switches?

[Ziggy]

Hey Sonniccd123, I had a couple of questions about this board. I finally got around to taking a look at it with a gerber viewer and noticed that there aren't any silk screen value identifiers and I didn't notice a BOM. What are the two ICs for U1 and U3? Is R1-R4 just pull up or down resistors for address lines? What is the purpose of JP1 on the back?

[fastbilly1]

I wasnt planning on making any Genesis carts ever, but now I am very interested. Thank you Soniccd123

[Soniccd123]

Hey Sonniccd123, I had a couple of questions about this board. I finally got around to taking a look at it with a gerber viewer and noticed that there aren't any silk screen value identifiers and I didn't notice a BOM. What are the two ICs for U1 and U3? Is R1-R4 just pull up or down resistors for address lines? What is the purpose of JP1 on the back?

Hey, thanks for pointing that! I had totally forgot it ::facepalm::. Will update the project with these informations.

I was testing some games and noticed that 2MB ou less ROMs did not properly identified the FeRAM, JP1 is a jumper to select if you're using a ROM bigger or smaller than 2MB.

U1 is a 74HC74 D-Type Flip-Flop
U3 is a 74HC139 2 to 4 demultiplexer
The resistors are all pull-up, i normally use 1K to each;

I'll add everything in the project and original post.

Thanks again for the insight.

PS: Did the schematic opened correctly in your PC? Just to know if i need to do any modifications.

[Ziggy]

For now just the ROM, it is possible to control the RAM also, but this needs some thinking, maybe use two DIP switches?

Hmm, you could use two DIP switches, but would that divide the RAM into too small of chunks for saves? I'm not big on Genesis, I don't know the typical save file sizes. Another option would be to use the same 4 DIP switch, but control only 2 address lines for ROM and then 2 address lines for RAM. Although, not many Genesis games use game saves. One might make a multi cart where only 1 of the games requires saves.

Hey, thanks for pointing that! I had totally forgot it ::facepalm::. Will update the project with these informations.

Thanks!

I was testing some games and noticed that 2MB ou less ROMs did not properly identified the FeRAM, JP1 is a jumper to select if you're using a ROM bigger or smaller than 2MB.

I see. For games that were 2MB or less, did you mirror the ROM to fill the 27C322 or just leave it blank?

PS: Did the schematic opened correctly in your PC? Just to know if i need to do any modifications.

I loaded the gerber files with KiCAD's gerber viewer and that worked fine. When I tried to load the schematic in KiCAD, I got an error that my version of KiCAD was not support. I guess I have an older version of KiCAD on my Linux laptop. I've only used Eagle before, but I've been wanted to also learn KiCAD. When I get a chance, I'll install the latest version of KiCAD and see if it works.

Thanks again for sharing this!

[Soniccd123]

Hmm, you could use two DIP switches, but would that divide the RAM into too small of chunks for saves? I'm not big on Genesis, I don't know the typical save file sizes. Another option would be to use the same 4 DIP switch, but control only 2 address lines for ROM and then 2 address lines for RAM. Although, not many Genesis games use game saves. One might make a multi cart where only 1 of the games requires saves.

The problem i see in using DIP switches with the RAM addresses is actually human error. From my tests, if you load a save capable game that does not match the corresponding FeRAM stored data, it overwrites the chip with new data, making the user to lose the saves. This problem lies on the diferent rom sizes of the games and save sizes, making the banks not always match exactly and so, the user to make mistakes. Note that this solution is totally possible, just not much user friendly.

Would be very useful also to have a list with save sizes of each game and find the one thats the largest. I have not found this yet, maybe i will compile one myself, i don't know.

I actually used the FM1808 256Kb FeRAM chip because i bought a 5 or 10 unit lot of this particular model, for not only using on the Genesis cart, but also a SNES one that i'm testing (which i actually have a detailed list and know that most games maximum save file is 256Kb) and for switching the SRAM chip in my Sega Saturn and stop losing my saves everytime the battery dies (the FM1808 is pin compatible with the Saturn SRAM). Its perfectly possible that this chip size is overkill for Genesis games, so i need to take a look.

I see. For games that were 2MB or less, did you mirror the ROM to fill the 27C322 or just leave it blank?

I just leave the rest of the chip blank, didn't have problems with any game so far. From what i know there are some SNES games that check for a ROM mirror in the upper addresses of the chip, but Genesis games don't seen to do that in general.

[Ziggy]

I got the latest version of KiCAD installed and the schematic and board loaded up just fine. I might modify this PCB for my own preference, it would help me to finally learn KiCAD. I was thinking about removing the bank switching stuff and changing the two 74 logic chips to surface mount packages, then shrink the height of the board as much as possible. That would make it a little cheaper to produce.

The problem i see in using DIP switches with the RAM addresses is actually human error. From my tests, if you load a save capable game that does not match the corresponding FeRAM stored data, it overwrites the chip with new data, making the user to lose the saves. This problem lies on the diferent rom sizes of the games and save sizes, making the banks not always match exactly and so, the user to make mistakes. Note that this solution is totally possible, just not much user friendly.

Ah, the journey down the rabbit hole. Well you could use a logic IC to switch the ROM and RAM together, that way it would always select the same ROM/RAM pair and avoid that human error.

To switch games, you could use a push button like a tact switch (such as the one that the Everdrive uses for a SMS pause button) where each press of the button would switch to the next game. You would need some button debounce circuitry, otherwise one button press might actually send several signals to the IC. Looks like a simple debounce circuit is made with only 2 resistors and 1 capacitor. I'm not sure if that would be sufficient or not, I've seen larger debounce circuits made from a 555 timer.

Another option than the push button would be to use the console's reset button to switch games, and then you wouldn't have to worry about bounce. But every time you press reset it switches games, which would be annoying if you wanted to reset the console but stay in the same game. If you had a 4-in-1 cart, you'd have to press reset 4 times to reset the console but stay in the same game. The solution to this would be to make it so that you have to hold the reset button for X seconds to trigger the logic IC. I was actually looking into doing this for my multi cart, but was having a hard time finding something. I was going to try and do it with only passive components, but never got around to prototyping it.

Since either using a push button or the console reset button would require some additional circuitry to be ideal, I had the idea to use a microcontroller instead of a logic IC. With a microcontroller, you could use a push button or the reset button and program in debounce or a hold delay. I've been wanting to learn to program microcontrollers, and this seems like a simple enough project to start with.

I actually used the FM1808 256Kb FeRAM chip because i bought a 5 or 10 unit lot of this particular model, for not only using on the Genesis cart, but also a SNES one that i'm testing (which i actually have a detailed list and know that most games maximum save file is 256Kb) and for switching the SRAM chip in my Sega Saturn and stop losing my saves everytime the battery dies (the FM1808 is pin compatible with the Saturn SRAM). Its perfectly possible that this chip size is overkill for Genesis games, so i need to take a look.

They're pretty expensive from a supplier, about $20/ea, but I was able to get a couple from eBay for about $10/ea. I actually just recently got two so I could mod both of my Saturns lol. I know I can get them cheaper from China, but I've been avoiding international shipping during the pandemic. I'm still waiting for something to come in from Japan that I ordered in early July! I was actually looking for something else for the Saturn that would still be drop-in compatible but cheaper and still in production, but couldn't find anything. Although I didn't look that hard.

I just leave the rest of the chip blank, didn't have problems with any game so far. From what i know there are some SNES games that check for a ROM mirror in the upper addresses of the chip, but Genesis games don't seen to do that in general.

I wasn't aware that SNES games checked ROM like that, I've just always heard that it's good practice to mirror and never leave empty space so if the system accidentally checks the upper half the same data will be there. FYI though, some SNES games check the RAM size as an anti-piracy method. Old copiers would just make 1 huge RAM size to cover all possible sizes and game developers knew this so they would code a check for RAM to see if it was too large.

[Soniccd123]

I got the latest version of KiCAD installed and the schematic and board loaded up just fine. I might modify this PCB for my own preference, it would help me to finally learn KiCAD. I was thinking about removing the bank switching stuff and changing the two 74 logic chips to surface mount packages, then shrink the height of the board as much as possible. That would make it a little cheaper to produce.

Thats nice man! Do as you want, thats the spirit of open hardware!

Ah, the journey down the rabbit hole. Well you could use a logic IC to switch the ROM and RAM together, that way it would always select the same ROM/RAM pair and avoid that human error.

To switch games, you could use a push button like a tact switch (such as the one that the Everdrive uses for a SMS pause button) where each press of the button would switch to the next game. You would need some button debounce circuitry, otherwise one button press might actually send several signals to the IC. Looks like a simple debounce circuit is made with only 2 resistors and 1 capacitor. I'm not sure if that would be sufficient or not, I've seen larger debounce circuits made from a 555 timer.

Another option than the push button would be to use the console's reset button to switch games, and then you wouldn't have to worry about bounce. But every time you press reset it switches games, which would be annoying if you wanted to reset the console but stay in the same game. If you had a 4-in-1 cart, you'd have to press reset 4 times to reset the console but stay in the same game. The solution to this would be to make it so that you have to hold the reset button for X seconds to trigger the logic IC. I was actually looking into doing this for my multi cart, but was having a hard time finding something. I was going to try and do it with only passive components, but never got around to prototyping it.

Since either using a push button or the console reset button would require some additional circuitry to be ideal, I had the idea to use a microcontroller instead of a logic IC. With a microcontroller, you could use a push button or the reset button and program in debounce or a hold delay. I've been wanting to learn to program microcontrollers, and this seems like a simple enough project to start with.

I've been thinking about the microcontroller way for sometime now, i've been using AVR and STM32 microcontrollers for years now, even made my own USB EPROM programmer using the STM32 and they are wonderful little chips. I would be even possible to use Flash memory instead of an EPROM make USB programed cartridge, but i don't really know if this doesnt turn the project in some kind of poormans Everdrive, not thats a bad thing, i just don't know if there is interest in something like this. Using a MCU, the information about which ROM, which size, which bank and the corresponding RAM location could be fed to the chip and it could care about this aspect of the game selection for the user.

They're pretty expensive from a supplier, about $20/ea, but I was able to get a couple from eBay for about $10/ea. I actually just recently got two so I could mod both of my Saturns lol. I know I can get them cheaper from China, but I've been avoiding international shipping during the pandemic. I'm still waiting for something to come in from Japan that I ordered in early July! I was actually looking for something else for the Saturn that would still be drop-in compatible but cheaper and still in production, but couldn't find anything. Although I didn't look that hard.

Yes, they are quite expensive, more so because they're 5V compatible and not in production anymore, there are new FeRAM designs that are cheaper, but most of them have serial I/O or are 3.3V maximum. I've searched for other non volatile chips, but even in 2020, the tecnology is quite there yet

I wasn't aware that SNES games checked ROM like that, I've just always heard that it's good practice to mirror and never leave empty space so if the system accidentally checks the upper half the same data will be there. FYI though, some SNES games check the RAM size as an anti-piracy method. Old copiers would just make 1 huge RAM size to cover all possible sizes and game developers knew this so they would code a check for RAM to see if it was too large.

Yes, some would check addresses above the ROM maximum size and see what would be read, if you think about for example a 1MB ROM, which has address pins ranging from A0 to A19, this rom last physical address would be 0x0FFFFF. If any address above it was read, the A20 pin from the console side would be set high, but, as there is no A20 in ROM chip, this means that efectively, if you were reading like 0x100001, in which A20 and A0 are high, the 1MB chip would only see A0 high (because as said earlier, there is simply no A20 in this chip) and would output data from the address 0x000001, a "mirror" of the ROM. As copiers and other devices have normally larger storage for versatility sake, if one was being used, the output for 0x100001 would be something else (00 or FF or any other data). The software would check one or more of these addresses and activate copy protection if a mirror of the ROM wasn't found.

I think that is also a good practice to always program all of the chip space because of deterioration from write cycles, all kind of programable memory has limited writing life, so if you keep writing to the same addresses all over again, these addresses will wear off much sooner than the others. But i don't know if this apply to us because for 27C322 this limit is like 10000 cycles, i don't think anyone will rewrite a cartridge so many times in his or hers lifetime.