Worklog AutumnCart64 - a N64 Flashcart for Portables

[Y2K]

Hello everyone!

I thought about bringing back PSXpress for this year's contest, but I'm pretty confident that I won't be able to finish it in time for this year's deadline given all that I want to do, so I came up with a new idea!

The idea of a sleek & compact N64 portable has been fairly alluring to me. Currently, lot of the driving force behind the formfactors of most builds is not what you'd immediately think. The trim itself is very small, but the games are not!

While I love the convenience of a cart slot in a N64 portable, it's no doubt that many of us have sought out a solution for an internally wired flashcart. With limited success using the clone Everdrives, and the real Everdrive being a very expensive piece of kit (not to mention completely closed source), I think a compact & somewhat-affordable N64 flashcart made specifically for use in portables would be very desirable!

Enter, the SummerCart 64 - a fully open source & feature-rich N64 flashcart:

The SummerCart 64 is an absolutely fantastic piece of hardware, and has a ton of features, including a great loader menu, rock solid game compatibility, and 64DD emulation. However it's got some extras that we probably don't need for a N64 portable, specifically it's debugging/USB capabilities, and we can probably go without the RTC for the one game that uses it. I thought about a trim, but why don't we go even further beyond:

This is a concept image Yveltal had shared with me as I was discussing this idea in the BitBuilt Discord server. The FPGA and SDRAM have BGA equivalents that are 100% compatible with the original chips used on the SC64, and they are way smaller at that! With this, I can create a N64 flashcart that is fully featured for our needs, and is way smaller than a standard cartridge!

My plan is as follows:
1. Strip out unnecessary features from the SC64 HDL.
2. Redesign the motherboard to use a BGA version of the Lattice MachXO2 FPGA and 512Mbit SDRAM.
3. Reduce the size of the board to be as small as possible.
4. Eliminate the cart edge connector, and replace it with a flat-flex connector.
5. Create an example flex cable that solders directly to a trimmed N64 motherboard, and can be easily modified to suit your needs in your designs.

I can't wait to get stuck into this project. This will be my first experience designing around BGA parts, and I cannot wait to learn all about the intricacies in BGA circuit design so that I can deliver you all a high quality end product that's worthy of this great community. And yes, as always, it will be fully open source! Stay tuned for more updates as this progresses!

Edit 5/13/2024 @ 1:23PM
Quick update that doesn't need it's own post: I have forked the SC64 repo, so all development effort that isn't covered in the update posts can be found here.

 

[Konker]

Looks Great! Recently got a few GBA's and was quite surprised at the price of the Everdrive. Makes sense as it must take a lot of work to assemble and distribute being a niche item, but your project looks great!

 

[Y2K]

Figured I'd update y'all with the progress made so far. Still a lot of work to be done, the current component layout is far from finalized, and not everything has been placed on the board & routed yet, but this should give you a rough idea what I'm going for!

As it stands right now, the overall footprint for the "cartridge" stands at ~35mm², which is even smaller than my initial 40mm² plan!

I have found fully compatible BGA versions of both the Lattice MachXO2 FPGA & the 512Mbit SDRAM, and have pretty much finished the routing & decoupling capacitor placement for both of those. I've also sourced a compatible QFN version of the STM32G0, which is essentially identical to the original used, just with more I/O.

Additionally, I've decided to offer many different ways to interface with the storage of the flashcart. The SummerCart64 is designed to work with SD cards, however I realized that there was a ton of different ways we employ for a user interact with an SD card in a portable. Whether having the card removable and accessible from the outside of the build, or having it be non-removable & accessed through a USB port like the 4LayerTech PMS-PD 3 for Wii portables, I didn't want to force anyone into one option, so I'm adding them both!

The cartridge will feature an on-board half sized microSD slot, as well as a FFC connector for a microSD extender board that I also plan on making. Said extender board will be designed to-spec with proper impedance & length matching, and can be modified to be the exact length you need for your build. You can also always use an off the shelf microSD extender cable if you so desire. Also, there will be a USB interface on-board based on a GL835 SDIO reader chip, which will be properly muxed with the FPGA to prevent any accidental interference or corruption, similar to the 4Layer PMS-PD!

Now, a concern I had with this approach is how you'd only want the internal SD card to be accessible while the unit is off, and with potentially backfeeding power into the cartridge or the rest of the build through the USB port when connected to a computer. With some gentle guidance from @YveltalGriffin, I was able to come up with this concept on how to pull all this off.

This idea is still quite preliminary, but the gist is to employ a TPS2101 power mux IC to handle the switchoff between VBUS and VSYS (the portable's 3v3 rail) for this part of the cartridge, prioritizing VSYS for when the portable is on. The PI3A27518Q is a 6 channel, high-speed, bidirectional mux designed to handle SDIO/QSPI, and is what is handling the switchoff between the FPGA and the GL835. The SDIO mux's input selection lines are pulled low by a resistor until VSYS is present, so the GL835 will be considered the active device until the portable is on, which then the FPGA will stay selected until the portable is turned back off.

The only downside with this circuit is that the USB port *has* to be presenting 5V, as its being stepped down to 3v3 through a LDO. I implemented an over-voltage protection circuit so that you can still use USB-C PD without destroying something, however if you happen to use a PD power supply or a computer with a USB C to C cable that outputs PD voltages, the zener diode will clamp the voltage to 5V and burn the rest off as heat, which may be a concern especially at higher PD voltages. Perhaps I will consider an SMPS setup instead so that PD voltages aren't at all an issue, but I believe that will increase the BOM cost of the whole thing, so I'm not sure which route I will go.

In any case, I've been making slow but steady progress with the little time I have to work on projects at the moment, but things are coming along!

Edit: Minor update that again doesn't warrant a new post, I have settled on the name "AutumnCart64" as the final name for this project. Thanks to Yveltal and others on the BitBuilt discord for the inspiration and suggestions!

 

[PiR8_BTY]

Such a fantastic idea! Definitely agree with removing the RTC and making options for the SD card access.

 

[polprzewodnikowy]

Hello, original project author here. Cool to see people interested in it. However, I have some suggestions about your adaptation.

First, I would highly advise against straying too far from the original hardware design. Source project is far from being finished and if you make your version firmware incompatible with my official release, then it is guaranteed you will stay behind latest improvements. This may come as a surprise but my project is full of bugs in the FPGA code that I'm actively working towards fixing them.

Second, I'd rather stay away from any muxing chips between FPGA and SD card. SD clock speed is 50 MHz and the FPGA design is written in a way to compensate for the specific clock skew and bus turnaround. Introducing more delay might make SD card just not work. Also I don't really understand why you removed FDTI chip and introduced this weird contraption just to access SD card via USB. I think it would be easier to add some USB commands to handle SD card read/write from the PC. This is actually a highly requested feature for the SC64 but I haven't gotten to implement it yet.

Third, the RTC chip is used for more than just keeping the time. I use battery backed SRAM inside the RTC chip to store persistent settings and, most important, console region.

I hope you can give one more thought about these design changes.

If you have any questions feel free to ask, I'm here to help!

 

[Y2K]

Hello, original project author here. Cool to see people interested in it. However, I have some suggestions about your adaptation.

First, I would highly advise against straying too far from the original hardware design. Source project is far from being finished and if you make your version firmware incompatible with my official release, then it is guaranteed you will stay behind latest improvements. This may come as a surprise but my project is full of bugs in the FPGA code that I'm actively working towards fixing them.

Second, I'd rather stay away from any muxing chips between FPGA and SD card. SD clock speed is 50 MHz and the FPGA design is written in a way to compensate for the specific clock skew and bus turnaround. Introducing more delay might make SD card just not work. Also I don't really understand why you removed FDTI chip and introduced this weird contraption just to access SD card via USB. I think it would be easier to add some USB commands to handle SD card read/write from the PC. This is actually a highly requested feature for the SC64 but I haven't gotten to implement it yet.

Third, the RTC chip is used for more than just keeping the time. I use battery backed SRAM inside the RTC chip to store persistent settings and, most important, console region.

I hope you can give one more thought about these design changes.

If you have any questions feel free to ask, I'm here to help!

Hi there, nice to meet you!

While I fully understand where you're coming from in regards to straying away from the original hardware design, not doing so would make this entire project quite infeasible given the design goals I have. Replies I have to your points and suggestions:

1. The main intent of this project for me is to be a hardware design challenge, and to hopefully not mess around too much with the firm/software. The changes made boil down to a device & pinout change in the FPGA RTL and STM32 code, which I see no reason for that to cause issues when down streaming any changes you make. I did illude to the possibility of trimming away any unused portions in firm/software, however I will try to avoid this as much as possible given your warning. In this case, respectfully, I see no problem with straying from the original design and will continue as planned in that regard.
3. In regards to SD access, I suppose you make a fair point here for keeping the FTDI chip. I'll have to look more into it and see if it's at all possible to find them in a smaller package & if it'll make sense to include here. I'm still pretty early on into the design conceptualizing phase of this project, so suggestions like this are more than welcome!
4. I took a look into your claims about the RTC and only found documentation on the LED_ENABLE settings being stored in RTC SRAM. I didn't see anything about it being used for anything more than that. Furthermore, the carts being sold by Phenom Mod do not ship with an RTC battery and function perfectly fine without it (from my understanding, please correct me if I'm wrong), so could you elaborate further on how it's exclusion could be an issue here?

To cap it off, I feel as if our design goals and intentions are quite different here as we target different markets. Typically how things work around here is that we work towards a "quick and dirty" initial product and the community steps in and expands upon that, leaving us with a rock solid product for everyone to use. While you on the other hand have to make sure from the get-go that your design is rock solid to avoid a end-user support nightmare. I have a time crunch & budget to consider as well, so I need to do whatever it takes to get this out the door by the end of this contest deadline, and will be framing my design decisions around that mindset. Theres no reason why I can't come back to this later with a V2 with a cleaner design, and/or the community can step in as I mentioned earlier.

I hope to have your blessing on continuing, as I admire your work and your contributions to the open source community! I really do appreciate your comments regardless, it helps me out a ton!

 

[polprzewodnikowy]

pinout change

That already makes your device firmware incompatible, you would need to maintain your fork separately from mine anyways.
Unless, you would prepare the build process to compile two firmwares, one for my design and second for your. That way I could pull your changes and build the firmware automatically for different targets. Preferably your firmware would require only pinout changes and nothing more.

carts being sold by Phenom Mod do not ship with an RTC battery and function perfectly fine without it

That's partially true for the NTSC consoles as this region is default for the initial configuration. You can remove the RTC but you would need to find another way to set the CIC region. Given that your mod is permanently installed in the console you might just have some pins on the STM32 used to force specific region. If RTC chip is not detected then software could pull config from the external pins.
There still would be the issue of persistent settings not saving, for now it's not a big problem (there is only one setting for LED behavior) but this list might change in the future. This of course can be mitigated by moving storage to some other place (FPGA UFM region, QSPI flash or sacrifice one/two flash page/s in the STM32 to implement EEPROM emulation).
You can always ask what parts could be safely removed from the design. Most will require some changes in the software though, but this shouldn't be a big deal.

community steps in and expands upon that

Wishful thinking, 4 years after starting the project and nobody other than me touched the actual code (FPGA design, MCU code or the PC app). Better to make it correct right from the beginning and prepare your code to be merged upstream eventually.
On the side note, I hate fragmentation caused by forking projects without the intention to merge changes upstream. First example that comes to mind is alternative Everdrive64 menu (Alt64, Altra64, probably other names too). There are endless forks and versions that have different improvements. But there's no definitive version that have them all.
My intention behind open sourcing the project was to extend it with contributions, and not to make hundreds of incompatible different versions.

 

[Y2K]

Wishful thinking

Definitely not, this is how this community operates, we're a very collaborative effort outside of these summer contests, which are designed to drive the portablizing scene forward with the contributions made. I'd agree with OSHW at large that it can be hard to get contributions, but you won't find that here.

On the side note, I hate fragmentation caused by forking projects without the intention to merge changes upstream.

While I do understand where you're coming from, this is an unavoidable thing when it comes to open source, especially with the license you picked for this project. Personally if I were in your shoes with a concern for fragmentation, I would have considered a much tighter license that restricts derivative works, or closing off the source entirely so you have complete control over what is done with it. With this being said, I have no issues with contributing back changes I make when it makes sense to do so for the original project, but I imagine a lot of these changes won't make any sense to upstream. I also have no problem trying my best to maintain upstream firmware compatibility, outside of potential build script changes to assist in this as you mentioned.

I'm going to cut this off here though as this conversation is way outside the scope of a worklog. Please reach out to me in DMs if you so desire, either here or on Discord (you'll find me in the BitBuilt Discord, feel free to join and send me a friend request) and we can discuss this further.

 

[Shank]

Hi @polprzewodnikowy! Welcome to the community and thank you for your work on SummerCart64.

From what I can tell, it seems like there's a bit of a misunderstanding. Here's my understanding, and please feel free to correct me if I am wrong.

If I am correct, you are trying to explain that you want Y2K to make sure that his design is compatible with mainline firmware as much as possible. Reason being, you don't want his project to get left behind with future releases, and you don't want the project to get fragmented in a detrimental manner for users so they don't have to choose between two options with pros and cons. Am I understanding this correctly?

I can't speak for Y2K, but from what I can see in this thread, it looks like he is misunderstanding your messages as you telling him not to pursue or fork the project at all, rather than trying to guide him towards unified compatibility.


Our small scene has had a void for flash cart solutions for n64 portables since the 64Drive Portable Edition became unavailable. An ultra-compact, open source n64 flash cart would be an absolute game changer for the N64 portablizing scene. If you have any interest in working with our scene to make that a reality, I know our scene would be absolutely thrilled.

 

[Y2K]

Small update for everyone: I have not heard from polprzewodnikowy at all in regards to his issues with the project as it currently stands. I do feel like we may have gotten off on the wrong foot, but I am going to go ahead and continue as planned, but take some extra considerations for some of the issues he pointed out.

Most importantly, I may consider looking at rethinking the approach for handling SD card access, as it's quite convoluted and is gonna probably end up taking a decent bit of real-estate space on the board. Perhaps I can release a separate module down the line, something akin to PMS-PD 3 from 4Layer, where it connects to AutumnCart but handles the SD and USB muxing itself. I think this could be a valid approach instead of baking it onto the cart, but I'll consider my options here. If I can come up with a solution that even the original SummerCart can benefit from, I will try to go down that route.

I will also try to make this project as compatible as possible with the OG firmware, and down-streaming any future changes should be quite simple. I'll keep myself open to suggestions from polprzewodnikowy in terms of how this should be handled, as I think it'll benefit both of us if a solution can be agreed upon to reduce as much fragmentation between the original project and mine as possible, and of course upstream changes I make when it makes sense for SummerCart to include.

I will also consider keeping the RTC w/ some pads to solder a coin cell battery to, to keep the door open for potential additions to the SRAM stored configuration settings. It's a pretty small chip and I still have a decent bit of space to work with, so I have no problem keeping it. Should help with game compatibility too, despite the minuscule amount of games that utilize it!

And, of course, as a reminder all of these changes will be open-source and made freely available, as per the GPLv3 licensing terms used in the original project repository. I'm not in the business of violating copyright licensing, that's no fun for anyone!

 

[PiR8_BTY]

Glad your moving forward with it.

 

[Benji]

This is amazing work. I look forward to seeing the final project