PlusCart(+) + SD

[+Andrew Davie]

9 minutes ago, bigmessowires said:

Ah, I saw you mention something about that Brazilian board in another thread. Aren't they required to share it under GPL?

In short, yes. That's my understanding, and it's why I'm shirty about the situation. My view (but not the consensus) is that we have no obligation to "support" the PlusCarts sold in violation of GPL (if indeed that is the correct interpretation). As each has a serial # and we pretty much know the exact location of each cart via IP... in theory the seller's product could be rendered inactive. However that would harm innocent parties, so was not the course of action taken.  But yes, GPL... violation... annoying. I'll caveat that with "that's my understanding".

 

9 minutes ago, bigmessowires said:

I have some experience designing boards similar to this, and might be able to help. I think the PCB layouts and schematics of all the STM32 Discovery Boards are made public by ST, which would make a good starting point. Although it might be an Altium file or something and would need to be converted to Eagle or KiCad. But then you could just start with a known-working layout for all the most complicated bits involving the STM32, and just delete whatever you don't need, and add the other stuff.

I would encourage you to go for it!  Perhaps with @Al_Nafuur's advice about the appropriate chips to use.

 

9 minutes ago, bigmessowires said:

Do you happen to know how The Brewing Academy is able to continue manufacturing Uno 2600 carts right now? That uses an all-in-one PCB which requires a bare STM32F407, which doesn't seem to be available for sale anywhere at the moment.

No, but I do know @batari buys perhaps thousands of chips in advance when they're available and cheap. Perhaps the Brewing Academy has a significant stock of those chips - and in any case I would guess UnoCart sales are low.

 

9 minutes ago, bigmessowires said:

There's also a question of economics here. While an all-in-one PlusCart would be aesthetically appealing, and it might be nice to switch to a lower pin count STM32 package at the same time, it might not actually be cheaper. If the sales numbers of PlusCarts are pretty low, then the cost to buy a bare STM32 and assemble it onto a PlusCart PCB could actually be more than the cost of an STM32 Discovery Board (or a clone of one). Because those things can be sold in huge volumes, while I assume PlusCarts would sell more like hundreds or thousands at most?

No.  PlusCarts might sell in the tens.  I would guess there are maybe 200 "out there", give or take. We're talking homebrew volumes here. We, the community, do these things despite the insane low demand for the things we do. Moreover, we spend years of effort in doing so.  Because we can

 

9 minutes ago, bigmessowires said:

These are the musings of someone who only showed up in the Atari scene last week, and has never even laid eyes on a PlusCart, so I might be way off base. But it's what jumped to mind after reading some of the hardware-related threads here. I design and sell a conceptually similar gadget for Apple II computers (an SD card floppy disk emulator), so this is sort of in the same headspace.

The nice thing about the PlusCart - aside from the really cool idea - is the open-source nature has allowed several members of the community, including me, to collaborate on it in areas that they find interesting.  For those who are non-technical, the PlusCart provides access to online curated lists of newly released homebrews and demos - also maintained by community member(s).  It's just an all-round feel-good project. Anyone participating is going to do so at the cost of their own time and perhaps money - but take-home satisfaction of doing something that's .. .pretty cool.

The Atari scene is (mostly) not about money - although AtariAge does make a successful business out of it. But here we are using their free forum as a gathering place for our community. So I feel that I give to AtariAge and the community with what technical and educational skills I can - and in return I benefit from being a part of a pretty tolerant and friendly community who share my interests.

 

Also, the groupies....

[+Al_Nafuur]

 

2 hours ago, bigmessowires said:

I'm curious about the current hardware status of the PlusCart Duo. If I understand correctly, the build process is:

 

1. start with the Unofied Pluscart PCB created by Andrew Davie, earlier in this thread

2. STM32F407VGT6 Discovery board

3. Micro-SD card breakout board

4. ESP8266 board (which one?)

 

Then you assemble all these into a sandwich and solder them together?

Assembly for the PlusCart (without SD): https://pluscart.firmaplus.de/pico/?assembly

there is also a very good YT video from @Fierodoug5

 

 

2 hours ago, bigmessowires said:

Has there been discussion or interest in integrating all four of these into a single PCB? I believe there's already an open source UnoCart PCB design that includes items 1-3 on that list (https://github.com/rglenn/unocart2600-pcb) so it would "only" be a matter of integrating an ESP8266. Or even if the ESP8266 remained as a separate module, it would still cut down the total number of modules to two instead of four.

I have started to modify rglenn's PCB a few month ago and add a ESP-12F and a USB connector. I gave the WIP to @ZackAttack who might finish it someday..

 

 

2 hours ago, bigmessowires said:

I know that STM32 parts are in short supply right now. How closely tied is the firmware to the STM32F407 specifically? If the user were willing to give up support for very large ROMs (say 128KB or 256KB) would it be possible to directly substitute a different STM32 variant in the same 100-pin QFP package and with a compatible pin-out? This document from ST describes how the built-in hardware peripheral capabilities differ between the F0, F1, F2, F3, and L1 families. https://www.st.com/resource/en/application_note/an3364-migration-and-compatibility-guidelines-for-stm32-microcontroller-applications-stmicroelectronics.pdf F4 has tons of goodies like ethernet and multiple USB ports, but the PlusCart doesn't need any of that, so maybe it could use an STM32F3 or something else.

Yes there are cheaper variants, but I haven't found a discovery board of them for the DIY soldering. It is very important to me that anyone with a soldering iron (and a few soldering experience)  can build its own PlusCart.

 

2 hours ago, bigmessowires said:

For that matter, does PlusCart really need the 100-pin package of this chip? I didn't count, but I think there are only about 30 I/Os total needed for the cartridge slot, SD card, and ESP8266. With a PCB redesign, it could maybe get away with using a 64-pin or even 48-pin package, opening up a lot more options for sourcing chips, while still remaining firmware-compatible with the existing PlusCart board.

 

Just to pick one example: STM32F405RGT6 is available in large quantities from an authorized ST distributor: https://www.newark.com/stmicroelectronics/stm32f405rgt6tr/mcu-32bit-168mhz-lqfp-64/dp/07AH7027?CMP=AFC-OP It's basically a lower pin count version of the STM32F407 with 64 pins, and it lacks the FSMC peripheral that supports external SRAM or Flash memory, which PlusCart doesn't need anyway. Other than that, I think it's functionally identical. It looks like it might work.

The cheaper variants might be a good alternative for the SMD board.

 

 

 

2 hours ago, Andrew Davie said:

That's still an enormous price (say, $11 in quantity) compared to the discovery board prices I was paying when PlusCart first came out. I think I was paying in the order of just over $7/unit. Yep...  see image.  I would have hoped we could find something down in the range of $3-$4/unit that was suitable.

 

 

The good old days. When I started the PlusCart project the discovery board was available for $5.50 to $6.00 at aliExpress and of very good quality. Now the quality of the discovery boards is 30% waste and the price is still triple of that.

 

1 hour ago, bigmessowires said:

I have some experience designing boards similar to this, and might be able to help. I think the PCB layouts and schematics of all the STM32 Discovery Boards are made public by ST, which would make a good starting point. Although it might be an Altium file or something and would need to be converted to Eagle or KiCad. But then you could just start with a known-working layout for all the most complicated bits involving the STM32, and just delete whatever you don't need, and add the other stuff.

I can send you my current version of the modified rglenn PCB.

 

 

1 hour ago, bigmessowires said:

Ah, I saw you mention something about that Brazilian board in another thread. Aren't they required to share it under GPL?

No it is not required. The PCB used by the Brewing Academy for the UnoCart (AFAIK designed by @electrotrains ) isn't open source too (and also not required to).

A lot of hardware manufacture today are using GPLed code/components in their products. I think it is nearly impossible to buy any electronic device today that doesn't contains anything GPLed.

 

1 hour ago, Andrew Davie said:

In short, yes. That's my understanding, and it's why I'm shirty about the situation. My view (but not the consensus) is that we have no obligation to "support" the PlusCarts sold in violation of GPL (if indeed that is the correct interpretation). As each has a serial # and we pretty much know the exact location of each cart via IP... in theory the seller's product could be rendered inactive. However that would harm innocent parties, so was not the course of action taken.  But yes, GPL... violation... annoying. I'll caveat that with "that's my understanding".

Building and sellling PlusCarts is only a violation of the GPL, if you not inform your customer about the GPL source used in the product. However the PlusCart is pretty useless without a online service like the PlusStore

 

1 hour ago, Andrew Davie said:

No.  PlusCarts might sell in the tens.  I would guess there are maybe 200 "out there", give or take. We're talking homebrew volumes here. We, the community, do these things despite the insane low demand for the things we do. Moreover, we spend years of effort in doing so.  Because we can

There a currently 575 PlusCarts know to the PlusStore. Distribution of firmware version and country can be seen here: https://pluscart.firmaplus.de/statistics.php?stat_id=3 (page has very long loading time, so here is a screenshot:

 

1 hour ago, Andrew Davie said:

The nice thing about the PlusCart - aside from the really cool idea - is the open-source nature has allowed several members of the community, including me, to collaborate on it in areas that they find interesting.  For those who are non-technical, the PlusCart provides access to online curated lists of newly released homebrews and demos - also maintained by community member(s).  It's just an all-round feel-good project. Anyone participating is going to do so at the cost of their own time and perhaps money - but take-home satisfaction of doing something that's .. .pretty cool.

The Atari scene is (mostly) not about money - although AtariAge does make a successful business out of it. But here we are using their free forum as a gathering place for our community. So I feel that I give to AtariAge and the community with what technical and educational skills I can - and in return I benefit from being a part of a pretty tolerant and friendly community who share my interests.

👍

1 hour ago, Andrew Davie said:

Also, the groupies....

🤣

 

[ZackAttack]

2 hours ago, Al_Nafuur said:

I have started to modify rglenn's PCB a few month ago and add a ESP-12F and a USB connector. I gave the WIP to @ZackAttack who might finish it someday..

 

I just created a PR to add the WIP to Al-Nafuur/United-Carts-of-Atari (github.com) so it's available for anyone to work on. I had planned on working this once the basic 7800 support is finished, but if someone else wants to work on the PCB before then that would be great. It still needs the external crystal oscillator, SPI flash, and other refinements to bring it in line with the ST hardware design guidelines.

[+Al_Nafuur]

25 minutes ago, ZackAttack said:

I just created a PR to add the WIP to Al-Nafuur/United-Carts-of-Atari (github.com) so it's available for anyone to work on.

 

25 minutes ago, ZackAttack said:

I had planned on working this once the basic 7800 support is finished, but if someone else wants to work on the PCB before then that would be great. It still needs the external crystal oscillator, SPI flash, and other refinements to bring it in line with the ST hardware design guidelines.

And maybe we can remove the UnoCart GPIOs (D8-D15 ?). Then the "old" UnoCart firmware v17 wouldn't work with this PCB, but we would avoid it possibly interfering with BUS stuffing (supposed by you here: https://forums.atariage.com/topic/344287-next-hardware-revision/?do=findComment&comment=5164518

 

[bigmessowires]

1 hour ago, ZackAttack said:

if someone else wants to work on the PCB before then that would be great. It still needs the external crystal oscillator, SPI flash, and other refinements to bring it in line with the ST hardware design guidelines.

I could take a look at this if it's helpful. But probably I should build myself a regular PlusCart first, so I have some better context for understanding how it all works. Is there a TODO list somewhere of exactly what's still missing?

 

External crystal oscillator - Should be easy enough, but didn't the rglenn PCB already include this? Did it need to be changed for PlusCart usage?

SPI Flash - What's this for, a future improvement to support larger ROMs? The Discovery board you're using now doesn't seem to include any SPI Flash.

Other refinements to bring it in line with the ST hardware design guidelines - Like what? Best practices on capacitor placement and trace routing, things like that?

 

I might suggest omitting the USB connector. It's only needed for initial programming, which can also be done more reliably with an ST-Link II V2, and those are readily available for about $10. Or design the PCB so that the USB connector is optional.

 

-----

 

OK then, a few different ideas for experimentation:

 

1. Design an alternative "module sandwich" that's similar to the current one, easy for anybody to build at home, but that uses a different STM32 module that's cheaper and easier to find. The obvious candidate here is the STM32 Black Pill, based on the STM32F411CE or STM32F401CC, or maybe even the lower-spec'd Blue Pill STM32F103C8. This would require redesigning Andrew Davie's PCB to fit a different size and shape of STM32 module, as well as changes to the PlusCart firmware to support the different chip. Depending on the specific chip, those firmware changes might be simple, or difficult, or impossible. There would be less ROM and RAM (STM32F411CE has 512KB of flash and 128KB of SRAM), and the max core speed would be lower (100 MHz, 84 MHz, or 72 MHz). But if all went well, any game that runs on the existing PlusCart would also run on this, as long as it could fit in the available ROM and RAM space.

 

2. Design a single PCB solution based on the current chip, STM32F407VG or STM32F407VE. This is what Al_Nafuur and ZackAttack have already been working on. This would make it easier for somebody who wants to manufacture a bunch of PlusCart Duos and sell them to the Atari community. But it's less interesting for most people who wish to build a single PlusCart for personal use. The STM32F407V* are very hard to find from any authorized distributor right now, but Newark does have the STM32F407VE https://www.newark.com/stmicroelectronics/stm32f407vet6/32-bit-microcontroller-ethernet/dp/73T7121 .

 

3. Design a single PCB solution based on a different STM32 chip. Possibly there's a chip that's pin-compatible with STM32F407V*, so it could be a direct drop-in for the PCB in idea #2. But more likely it would be a different chip, lower-spec'd and with lower pin count, to reduce costs and select a chip with better availability. So this idea is really like a combination of first two ideas.

 

 

[bigmessowires]

7 hours ago, Andrew Davie said:

PlusCarts might sell in the tens.  I would guess there are maybe 200 "out there", give or take. We're talking homebrew volumes here.

I think there could be potential for a lot more, if the path for newbies were smoothed as much as possible. Speaking as a newbie, I can report that the Atari 2600 Flash Cart situation was extremely confusing! 🙂 I really searched hard for some basic overview and documentation of Harmony, or UnoCart, or PlusCart, but didn't find one, which is why I started that comparison matrix thread that went a bit off the rails. I found a lot of forum threads, and some web sites discussing or selling flash carts, but they mostly assumed the reader was already familiar with the topic. For example, here's the first paragraph from https://pluscart.firmaplus.de/pico/

 

Quote

The Atari 2600 PlusCart is based on Robin Edwards Unocart-2600 (https://github.com/robinhedwards/UnoCart-2600) and the extensions of Christian Speckner's (DirtyHairy) fork (https://github.com/DirtyHairy/UnoCart-2600). The PlusCart has no SD-Card, but an ESP8266 to connect to a local WiFi Network and the Internet. The PlusCart downloads the ROM-files from an Server in the Internet called the "PlusStore". The way this is done is similar to the way the Unocart-2600 loads ROMs from the FAT filesystem on the SD-card, while the VCS is performing a waitroutine in his RAM. Additionally the PlusCart has one more interesting feature. It offers internet access to the ROM Developers, these functions are called "PlusROM".

 

With profuse apologies as I don't wish to be critical of anybody, however this text could be more beginner friendly. The beginner won't understand most of these references and comparisons. He just wants to know what this thing is, in plain language, and what it can do for him. He's not yet interested in developer name-dropping, GitHub links, terms like ESP8266 or wait routine, or feature comparisons versus other hardware that's not offered on the site. Replacing the intro paragraph with some text like this would help beginners, and probably boost sales:

 

Quote

The PlusCart is a game cartridge emulator for the Atari 2600 video computer system. It enables your Atari to load and run game ROMs over a WiFi internet connection. Game ROMs can be selected from a curated online collection called the "PlusStore" or from a private game collection. PlusCart is compatible with all 520 games published during the Atari 2600's original lifetime, as well as the growing library of modern homebrew games.

 

This could be accompanied by photos of an assembled PlusCart and the menu UI, some basic specs about max supported homebrew sizes, a brief note about it being open source hardware (with "click here to learn more"), a link to view the up-to-date manual, and some genuine reviews/testimonials. The photos of the internal PCBs and guts could go somewhere else, maybe on a PlusCart developer sub-page, so they wouldn't mislead or confuse a beginner who simply wants to buy a plug-and-play product. I would also suggest omitting discussion of PlusROM internet connectivity from the introductory paragraph, since it only involves a very small number of homebrews, and mentioning it in the introduction complicates the basic product explanation. I would move it further down to the specs section, or to a developer sub-page. Sales would probably also increase with a North American distributor and prices in US dollars.

 

Please don't take this the wrong way - I know that sales aren't anybody's first priority, and this is mainly just a fun community project, nobody's getting rich off it. I just think that a smoother beginner path would help newcomers and increase sales with no real downside. Maybe it would boost sales to a level where batch assembly of that hypothetical single-PCB design would become more economically viable.

 

[+Al_Nafuur]

29 minutes ago, bigmessowires said:

I think there could be potential for a lot more, if the path for newbies were smoothed as much as possible. Speaking as a newbie, I can report that the Atari 2600 Flash Cart situation was extremely confusing! 🙂 I really searched hard for some basic overview and documentation of Harmony, or UnoCart, or PlusCart, but didn't find one, which is why I started that comparison matrix thread that went a bit off the rails. I found a lot of forum threads, and some web sites discussing or selling flash carts, but they mostly assumed the reader was already familiar with the topic. For example, here's the first paragraph from https://pluscart.firmaplus.de/pico/

 

 

With profuse apologies as I don't wish to be critical of anybody, however this text could be more beginner friendly. The beginner won't understand most of these references and comparisons. He just wants to know what this thing is, in plain language, and what it can do for him. He's not yet interested in developer name-dropping, GitHub links, terms like ESP8266 or wait routine, or feature comparisons versus other hardware that's not offered on the site. Replacing the intro paragraph with some text like this would help beginners, and probably boost sales:

 

 

This could be accompanied by photos of an assembled PlusCart and the menu UI, some basic specs about max supported homebrew sizes, a brief note about it being open source hardware (with "click here to learn more"), a link to view the up-to-date manual, and some genuine reviews/testimonials. The photos of the internal PCBs and guts could go somewhere else, maybe on a PlusCart developer sub-page, so they wouldn't mislead or confuse a beginner who simply wants to buy a plug-and-play product. I would also suggest omitting discussion of PlusROM internet connectivity from the introductory paragraph, since it only involves a very small number of homebrews, and mentioning it in the introduction complicates the basic product explanation. I would move it further down to the specs section, or to a developer sub-page.

These are all very good suggestions.

 

(Web-)design and documentation are not my strengths and focuses. I can copy/paste your suggestions, but if someone wants to maintain the webpage and the manual, then I can set up FTP access for him to administer the site.

 

29 minutes ago, bigmessowires said:

Sales would probably also increase with a North American distributor and prices in US dollars.

 

Please don't take this the wrong way - I know that sales aren't anybody's first priority, and this is mainly just a fun community project, nobody's getting rich off it. I just think that a smoother beginner path would help newcomers and increase sales with no real downside. Maybe it would boost sales to a level where batch assembly of that hypothetical single-PCB design would become more economically viable.

 

Yes a US distributor would be nice. But I think that would only be interesting for someone with a good single PCB design.

 

 

[bigmessowires]

I spent some quality time researching possible substitute MCUs with STM32CubeIDE and Octopart. In the IDE, you can double-click the .ioc file to see the design view, and then choose the menu option to get a list of pinout-compatible MCUs for the project. For some reason this feature requires a huge amount of memory and brings my computer to its knees. The UI also appears broken, and the button to retarget the project to a new MCU is missing, but I was still able to create a potential list. Then I cross-checked the list of parts with Octopart to see which ones are available from distributors. You can view the spreadsheet here: https://docs.google.com/spreadsheets/d/1Jts1QVO6YtuaWNUW14g7UL6We2q0FsQl2Lu_yAPGdlg/edit?usp=sharing Let me know if you want editing privileges to help curate the list.

 

I think the IDE is showing a list of MCUs where the footprint and pin assignments are compatible, given the project's GPIO and peripheral usage. That doesn't necessarily mean the MCU would work though - it might have a different maximum clock speed, or different core (M3 or M4F instead of M4), or it might not have 5V-tolerant I/Os. 

 

FWIW, the 100-pin MCUs in my spreadsheet are the complete list of alternatives from STM32CubeMX when limiting the choices to 256KB Flash minimum and 80 MHz CPU speed minimum. The 64-pin MCUs in the spreadsheet aren't the complete list from STM32CubeMX, but are the closest matches. I have not yet checked these for availability with Octopart. The 48-pin MCUs in the spreadsheet are a few cherry-picked options from DigiKey's parametric search, because STM32CubeMX ran out of memory and never completed the 48-pin options for me.

 

Questions for somebody who's familiar with the firmware and hardware requirements:

 

- Does the MCU need to have 5V tolerant I/Os? I'm guessing yes. I was unable to find an easy way to filter the results by 5V tolerance capability.

- Will the firmware still work correctly at lower core clock speeds? What's the minimum speed? What breaks below that speed?

- Is there any specific dependency on M4 core features, or could M3 be used? Or M4F?

 

Quick highlights: 

- There is nothing that's straight-up better than the MCU already being used.

- The cheapest potential substitutes are still at least $5 each when bought in quantities of 100

- The price difference between 48-pin and 100-pin parts is not that much - a couple of dollars. Switching to a lower pin-count chip might open up more supply options, and allow the PCB to be smaller and simpler, but it probably won't save a ton of money for BOM cost. 

 

A couple of standouts:

 

48-pin STM32L431CCT, tens of thousands available, 80 MHz, 256KB Flash, 64KB RAM, $4.93

100-pin STM32F411VCT, thousands available, 100 MHz, 256KB Flash, 64KB RAM, 128 $6.80

 

 

[ZackAttack]

Here's my best attempt to answer all your questions. Hope this helps.

12 hours ago, bigmessowires said:

External crystal oscillator - Should be easy enough, but didn't the rglenn PCB already include this? Did it need to be changed for PlusCart usage?

The WIP in the UCA github repo doesn't have an external oscillator and will need to have it added in order for USB to work properly.

12 hours ago, bigmessowires said:

SPI Flash - What's this for, a future improvement to support larger ROMs? The Discovery board you're using now doesn't seem to include any SPI Flash.

I designed a standalone cart that's intended to be used for publishing games that are based on the new elf format and other modern schemes. This cart includes a 16MB SPI flash. Since the cost difference is insignificant, I think it would be wise to include it in the multi-cart. In theory we could use the SD card to emulate the SPI flash, but that would require much more effort than adding it to the PCB.

12 hours ago, bigmessowires said:

Other refinements to bring it in line with the ST hardware design guidelines - Like what? Best practices on capacitor placement and trace routing, things like that?

 

Exactly. Capacitor placement. Trace widths and spacing. Should you decide to take on this project, I would be happy to look everything over before do a run of boards.

12 hours ago, bigmessowires said:

I might suggest omitting the USB connector. It's only needed for initial programming, which can also be done more reliably with an ST-Link II V2, and those are readily available for about $10. Or design the PCB so that the USB connector is optional.

My preference is to keep the USB connector. Having the ability to unbrick without an st-link is nice for less tech savvy users. There's also the possibility of using USB-OTG in the future.

7 hours ago, bigmessowires said:

Does the MCU need to have 5V tolerant I/Os? I'm guessing yes. I was unable to find an easy way to filter the results by 5V tolerance capability.

Yes. 5V tolerance is mandatory. Also, be careful when checking for 5V tolerance. Most STM32 chips have a

 

mix of tolerances and which pins are 5V tolerant can change depending on the pin count. The Chameleon cart uses weird pin assignments because some of the GPIOA pins are only rated for 3.3v when using the higher pin count parts.

7 hours ago, bigmessowires said:

Will the firmware still work correctly at lower core clock speeds? What's the minimum speed? What breaks below that speed?

This was tested and the result was a 192MHz minimum for /Public ROMs/PlusROMs/sokoboo Plus.bin and 144MHz minimum for /Public ROMs/PlusROMs/C.A.V.E. Apocalypse/C.A.V.E. Apocalypse NTSC.bin

Currently the latest version of the UCA firmware has the stm32f407 clocked at 216MHz.

7 hours ago, bigmessowires said:

Is there any specific dependency on M4 core features, or could M3 be used? Or M4F?

I believe there are some ACE files created by @MarcoJ that make use of the FPU in the M4F.

12 hours ago, bigmessowires said:

The STM32F407V* are very hard to find from any authorized distributor right now, but Newark does have the STM32F407VE https://www.newark.com/stmicroelectronics/stm32f407vet6/32-bit-microcontroller-ethernet/dp/73T7121 .

jlcpcb has had these in stock every time I've ever checked. They also have a parts bin feature which lets you purchase parts ahead of time so you can be sure you'll have the parts you need in the future. I think the supply issue is more relevant to the discovery boards used in the DIY builds.

[bigmessowires]

21 hours ago, Al_Nafuur said:

(Web-)design and documentation are not my strengths and focuses. I can copy/paste your suggestions, but if someone wants to maintain the webpage and the manual, then I can set up FTP access for him to administer the site.

You're welcome to use that text if you like it. I read through the manual and it looks pretty good, and up-to-date, including what I think was a recent change to exit games with Right+Reset. I'll try going through the manual in more detail after I've built a PlusCart.

[bigmessowires]

@ZackAttack thank you, this is a lot of great information! OK, I will definitely check out the PCB in the next couple of days and see what I can do.

 

For the external crystal, I think I understand now. The UnoCart and the rglenn PCB don't have a crystal, so they must be using the internal oscillator. That's handy, but the timing isn't accurate enough for USB.

 

For a stand-alone cartridge, could you store the game ROM and the PlusCart firmware all in the MCU's Flash? So the external SPI Flash would only be needed for very large game ROMs?

 

Understood about 5V tolerance. If there's some STM32 variant that looks perfect but lacks 5V tolerance, the board could include level shifters. But using an MCU with built-in 5V tolerance would be much nicer.

 

216 MHz! Wow, I didn't realize the MCU was overclocked. That's a pretty significant amount of overclock too. Have there been any stability problems reported? Unfortunately that rules out pretty much every alternative MCU on the spreadsheet I put together, except for a small handful. Is the high speed needed because those games have a large amount of ACE code that must run within a short time window? For just basic ROM and bank-switching emulation, I wouldn't think you'd need more than tens of MHz.

 

It looks like the STM32F407V is and M4 and not M4F, so I don't think @MarcoJ could be using hardware floating point support unless I've misunderstood.

 

OK, I'll take a stab at this. If I were to build and sell these myself (which I'm sort of maybe considering), I'd probably design an LC "low cost" variant that omits the USB, crystal, and SPI flash. It's not so much that those parts are expensive, but every part that must be loaded and soldered during batch assembly adds to the cost, increases the PCB area a little, and creates more places where assembly problems can occur. So the fewer parts, the better. I'd maybe use a lower-end STM32 part as well, with less memory or lower clock speed. But that would mean the LC variant wouldn't really be a PlusCart anymore, it would be a PlusCart LC that can handle original Atari ROMs and most homebrews, but not especially large homebrews or homebrews that make heavy use of ACE with tight timing requirements. And that could be an annoying proliferation of compatibility problems, which might be worse than the cost savings. Something to consider for the future.

 

I spent a little time playing with STM32CubeIDE, and unfortunately I don't think it'll be as simple as I'd hoped to experiment with retargeting for different MCU variants. As I mentioned in another post, the IDE feature to list pinout-compatible MCUs for the current project seems broken (maybe it's just my computer or display), so I can't actually change the MCU assignment. I will try this on a different computer. But aside from that, it looks like it's impossible for different targets in the same project to have different MCU assignments. So for example if there's a future PlusCart variant that uses a 64-pin STM32, I think it would need a completely separate project, with all of the files and build settings and pin assignments duplicated from the current project, instead of simply being a different build target like exists now for Plus Cart, Plus Cart Duo, and Uno Cart. That would be an awkward and cumbersome setup.

[bigmessowires]

On 1/27/2023 at 1:03 AM, Andrew Davie said:

In short, yes. That's my understanding, and it's why I'm shirty about the situation. My view (but not the consensus) is that we have no obligation to "support" the PlusCarts sold in violation of GPL (if indeed that is the correct interpretation).

For support of PlusCarts that aren't made and sold by @Al_Nafuur - regardless of their GPL status - I think there are some interesting questions. PlusCarts are dependent on the continuing operation of the PlusStore, which requires Al_Nafuur's time and money to keep running. If a third-party vendor is selling a bunch of PlusCarts then Al_Nafuur is effectively supporting that vendor's customers for free. He may be willing to do this for now, as long as it only requires some extra storage space on his server. But if "support" also needs to include upgrading server capacity or troubleshooting connectivity or firmware issues unique to that vendor's version of the PlusCart, which appears to be happening right now in another thread, then it seems unfair to expect Al_Nafuur to do this indefinitely out of sheer generosity.

 

Even if Al_Nafuur were willing to do this, it also creates a risk for a vendor to sell a hardware product dependent on an online service that's maintained by somebody else. The ongoing usability of the vendor's product would be outside their control.

 

My suggestion is that third-party vendors selling PlusCarts should pay Al_Nafuur a fee for PlusStore support and maintenance. It would be more fair to him and less risky for the vendor, because there would be a specific support agreement to help keep the vendor's customers up and running. If vendors didn't want to pay a fee, they could also fork the PlusStore and maintain their own version of it.

 

I will now take off my businessman's hat, don my engineering hat, and go look at that PCB in KiCad.

[ZackAttack]

On 1/28/2023 at 11:40 AM, bigmessowires said:

It looks like the STM32F407V is and M4 and not M4F, so I don't think @MarcoJ could be using hardware floating point support unless I've misunderstood.

 

Directly from ST:

The STM32F405xx and STM32F407xx family is based on the high-performance Arm® Cortex®-M4 32-bit RISC core operating at a frequency of up to 168 MHz. The Cortex-M4 core features a Floating point unit (FPU) single precision which supports all Arm single-precision data-processing instructions and data types. It also implements a full set of DSP instructions and a memory protection unit (MPU) which enhances application security.

 

That said, I have been targeting arm-v6 in all my projects because that leaves the option of using the stm32g0 when publishing individual games. I'm hoping the esp-01s can be used as a sort of GPU/co-processor eventually.

10 hours ago, bigmessowires said:

I will now take off my businessman's hat, don my engineering hat, and go look at that PCB in KiCad.

Great!

[bigmessowires]

I spent a long while reviewing the work-in-progress single PCB version of PlusCart Duo, as well as all the earlier versions of PlusCart and UnoCart. I might not be as much help with this as I’d hoped, because there’s a significant learning curve moving from Eagle to KiCad and also because I’m just not very familiar with all the project details. Here are a bunch of notes and ideas for finishing the PCB.

 

Initially I didn't realize that the existing PlusCart version doesn’t use the official STM32F4 Discovery Board that’s sold by ST, but a DIYMORE third-party STM32F4 board with a completely different footprint, different programming method, and opposite behavior of the BOOT0 jumper. Good to know for anyone who’s reviewing the design.

 

Board Routing and Layout

 

This PlusCart Duo work-in-progress is based on an earlier UnoCart PCB design by rglenn, but the most critical layout and routing from the rglenn PCB appears to have been undone. Was that necessary? Rglenn had the microcontroller square to the PCB, and all the decoupling caps carefully placed, with traces already routed through the tight space between them. PlusCart Duo WIP has the microcontroller rotated 45 degrees to the PCB, and all of the decoupling capacitors have been moved away, and the routing is unfinished. If possible, I would recommend going back to the rglenn placement and routing, or as close to it as possible, as this would save a lot of tedious P&R work.

 

The PCB also has all the data bus signals connected twice: to PE0-PE7 and redundantly to PE8-PE15. I would recommend to only use PE0-PE7, since this would help simplify the routing task. My understanding is PE0-PE7 is what the PlusCart firmware already uses, and PE8-PE15 is only for backwards compatibility with old versions of the UnoCart firmware. If so, I don’t think it’s worth the routing hassle. It’s not about the eight extra traces, but the extra traffic jam they may create in a crowded space on a 2-layer PCB. Just tell everyone that this PCB is compatible with the UCA firmware, but not with older UnoCart firmware.

 

Board Shape

 

Is the WIP PCB specifically designed for @Andrew Davie's 3D printed case? Why does the PCB have a hole in the center? None of the other PlusCart/UnoCart PCBs that I saw have a hole there, and Andrew’s 3D-printed case doesn’t need a hole. I would suggest getting rid of the hole, to create more room and ease of routing.

 

The placement of the USB connector will have it completely hidden inside the case - is that intentional? Why not extend the PCB all the way to the edge of the case, and mount the USB connector there, so it would be accessible through a hole in the case instead of needing to disassemble the case?

 

Questions on Existing Work

 

I’m unclear what’s intended with the SWD programming header. I think it should only need SWDIO, SWCLK, and GND, but it has several other signals. Some issues specific to this header:

• It’s a proprietary Tag Connect footprint that won’t be usable by most people unless they have the hardware for it. I’d recommend replacing it with a standard 0.1 inch pin header anybody can easily use.
• RST - I’m pretty sure this isn’t needed for SWD. It’s not present on the ubiquitous STM32 Blue Pill and Black Pill boards, nor on Robin Edward’s original UnoCart PCB.
• 3V3 - Is this intended so the ST Link can power the PlusCart? I thought the PlusCart was always supposed to be powered by the Atari. If that’s correct, then I would remove 3V3 from the SWD header to eliminate the possibility someone would get confused and power the PlusCart from the Atari and the ST Link at the same time.
• BOOT0 - I don’t think this belongs in the SWD header. BOOT0 is for enabling the USB bootloader, it’s not related to SWD. 

In the schematic, BOOT0 is also left floating at an undetermined voltage if nothing is plugged into the SWD header. That won’t work reliably. For consistency with the existing PlusCart, I think it needs BOOT0 to have a pull-up resistor to 3V3, with a jumper to optionally pull it to GND, so that removing the jumper activates the bootloader. This is opposite from the ST-brand Discovery board where BOOT0 has a pull-down resistor and a jumper can be used to pull it high.

 

I would recommend using a regular pin jumper for BOOT0, like the existing PlusCart PCB. Or if you want to get fancy, USB VBUS could be used to automatically set BOOT0 to 1 when a powered USB cable is plugged in. Put a pull-down resistor on BOOT0 so it’s normally low, and also connect it to USB VBUS. It would need a voltage divider to bring the 5V VBUS down to 3.3 volts for the BOOT0 input.

 

The PCB has USB VBUS tied directly to the board’s 5V power rail. If I’m correct that PlusCart is always intended to be powered from the Atari, then this VBUS connection to 5V isn’t needed or wanted. 

 

The USB D+ and D- traces usually have 22 ohm series resistors, but there aren’t any on this PCB. I’m not certain why they’re needed - maybe for proper electrical termination - but they’re present on most designs I’ve looked at including the Blue/Black Pill and the ST-brand Discovery board. I would recommend adding them.

 

USB D+ also needs a 1.5K ohm pull-up resistor to 3.3V, which tells the host this is a USB Full Speed device. This pull-up is present in the Black Pill and also the ST-brand Discovery board. Without it, the PlusCart will be identified as a Low Speed device with about 1/10th the maximum data rate of Full Speed. Note the Blue Pill uses the wrong pull-up value for this: 10K ohm (this might be fixed in some versions of the Blue Pill).

 

@ZackAttack mentioned the possibility of USB OTG. I’m not very familiar with this, but at a minimum the board would need to connect the USB ID pin, which isn’t connected in the schematic right now. I think it'd also need a way to disable or bypass those 1.5K and 22R resistors when the cart is functioning as a USB host instead of a USB device. I would recommend not worrying about USB OTG for now.

 

I might also suggest reintroducing the PAL/PAL60 jumper that was previously removed. Just in case somebody sets the TV mode to the wrong value in the menu interface, and then has a hard time seeing the menus to change the value, this would provide an easy fix. With two jumpers you could have four possible states for NTSC, PAL, PAL60, and menu-selected.

 

Questions on New Parts

 

For USB support, An 8 MHz crystal should be connected to the PH0 and PH1 pins, with some parallel capacitors around 20 pF. But the ST design also calls for an external feedback resistor in the crystal circuit, and I’m unsure what value is needed for the resistor. The ST-brand Discovery schematic says it uses 200 ohms, but I think that’s a documentation error. I couldn't find any schematic for the DIYMORE board - maybe somebody can measure it. I found several different numbers in the STM32F407 datasheet and other ST literature, but they vary by a factor of more than a thousand! One says 200K ohms is typical, another says 1-5 megaohms at 10 MHz or 5-10 megaohms at 1 MHz, and a third does some math to calculate a value of 1326 ohms for 8 MHz with 15 pF capacitors. I don’t know what’s right.

 

For the new SPI flash chip, I’m assuming this should be a plain vanilla 8-pin SPI flash, not Quad SPI or something else. Is there already a plan for which pins and which SPI peripheral will be used? The SD card uses SPI2 on pins PB13-PB15. It might be possible to share that with the SPI flash chip too, just by adding an extra chip select signal, but it’s probably cleaner to use a wholly separate SPI peripheral. SPI1 at PA5-PA7 and SPI3 at PC10-PC12 are both potential options. We could look at the routing to see which choice would be easier to run the traces.

[+Andrew Davie]

19 minutes ago, bigmessowires said:

 

The PCB also has all the data bus signals connected twice: to PE0-PE7 and redundantly to PE8-PE15. I would recommend to only use PE0-PE7, since this would help simplify the routing task. My understanding is PE0-PE7 is what the PlusCart firmware already uses, and PE8-PE15 is only for backwards compatibility with old versions of the UnoCart firmware. If so, I don’t think it’s worth the routing hassle. It’s not about the eight extra traces, but the extra traffic jam they may create in a crowded space on a 2-layer PCB. Just tell everyone that this PCB is compatible with the UCA firmware, but not with older UnoCart firmware.

 

Board Shape

 

Is the WIP PCB specifically designed for @Andrew Davie's 3D printed case? Why does the PCB have a hole in the center? None of the other PlusCart/UnoCart PCBs that I saw have a hole there, and Andrew’s 3D-printed case doesn’t need a hole. I would suggest getting rid of the hole, to create more room and ease of routing.

 

 

I haven't been following this, but my name mentioned above asks a couple questions I can fill in details for.  I was the one who originally added the extra traces to the (original?) PlusCart board - the idea here was to have a single board that was PlusCart/UnoCart compatible.  Why?  Because it was not previously possible (memory tells me) to build your own UnoCart... the board was not public domain. This change corrected that problem, so people could build UnoCarts.

 

It seems from the mention of various stuff I have no idea about, that there's a completely new board in the works, so I hopefully am not responsible for some of the other issues mentioned, like trace rerouting. I did reroute traces in the "original" as I have my own preferences about through-holes (i.e., none, if possible).

 

The hole in the center - I know nothing about this. No, my 3D shell does not have/require a hole. I don't recall anything about this at all. Maybe one of the new moulded shells require this hole for mounting the board firmly.

Hopefully I haven't screwed things up in my previous efforts. I did things that were for reasons that seemed good to me. But I know nothing about USB stuff, surface mounted component rotation, removal of PAL jumpers, etc., etc.

 

 

[ZackAttack]

3 hours ago, bigmessowires said:

I spent a long while reviewing the work-in-progress single PCB version of PlusCart Duo, as well as all the earlier versions of PlusCart and UnoCart. I might not be as much help with this as I’d hoped, because there’s a significant learning curve moving from Eagle to KiCad and also because I’m just not very familiar with all the project details. Here are a bunch of notes and ideas for finishing the PCB.

All your notes are super helpful. I'm looking forward to seeing where you take this.

 

2 hours ago, bigmessowires said:

This PlusCart Duo work-in-progress is based on an earlier UnoCart PCB design by rglenn, but the most critical layout and routing from the rglenn PCB appears to have been undone. Was that necessary? Rglenn had the microcontroller square to the PCB, and all the decoupling caps carefully placed, with traces already routed through the tight space between them. PlusCart Duo WIP has the microcontroller rotated 45 degrees to the PCB, and all of the decoupling capacitors have been moved away, and the routing is unfinished. If possible, I would recommend going back to the rglenn placement and routing, or as close to it as possible, as this would save a lot of tedious P&R work.

 

Assuming the GPIO assignments are compatible with everything we want to include I see no reason not to go with such an approach. 

2 hours ago, bigmessowires said:

The PCB also has all the data bus signals connected twice: to PE0-PE7 and redundantly to PE8-PE15. I would recommend to only use PE0-PE7, since this would help simplify the routing task. My understanding is PE0-PE7 is what the PlusCart firmware already uses, and PE8-PE15 is only for backwards compatibility with old versions of the UnoCart firmware. If so, I don’t think it’s worth the routing hassle. It’s not about the eight extra traces, but the extra traffic jam they may create in a crowded space on a 2-layer PCB. Just tell everyone that this PCB is compatible with the UCA firmware, but not with older UnoCart firmware.

Yes, that's what we were discussing before. I have concerns that extra traces could interfere with bus-stuffing. There's no need to retain compatibility with the older UnoCart firmware. UCA is the one that will be getting all the new features.

 

It really doesn't matter which GPIO are used for 6507 Address and Data bus connections. The only requirements are:

• Data bus is byte aligned
• Address bus is uint16 aligned
• GPIO 13-15 of the address bus are either grounded or NC. We don't want the performance hit of masking the address values.

2 hours ago, bigmessowires said:

Is the WIP PCB specifically designed for @Andrew Davie's 3D printed case? Why does the PCB have a hole in the center? None of the other PlusCart/UnoCart PCBs that I saw have a hole there, and Andrew’s 3D-printed case doesn’t need a hole. I would suggest getting rid of the hole, to create more room and ease of routing.

I second this. The need to have USB and SD ports already makes the PCB incompatible with an original, unmodified cart shell. If this were a stand-alone cart for publishing games, it would be a different story.

 

2 hours ago, bigmessowires said:

It’s a proprietary Tag Connect footprint that won’t be usable by most people unless they have the hardware for it. I’d recommend replacing it with a standard 0.1 inch pin header anybody can easily use.

Agreed. .1 inch pin header would be ideal. (right angle for clearance)

2 hours ago, bigmessowires said:

• RST - I’m pretty sure this isn’t needed for SWD. It’s not present on the ubiquitous STM32 Blue Pill and Black Pill boards, nor on Robin Edward’s original UnoCart PCB.

I vote for including nRST. In theory it can help with programming if you accidentally change the SWDIO/SWCLK pins to GPIO or alt functions. It would also be handy for communicating directly with the ESP32.

2 hours ago, bigmessowires said:

• 3V3 - Is this intended so the ST Link can power the PlusCart? I thought the PlusCart was always supposed to be powered by the Atari. If that’s correct, then I would remove 3V3 from the SWD header to eliminate the possibility someone would get confused and power the PlusCart from the Atari and the ST Link at the same time.

I do think it would be good to have a power pin for the initial firmware programming. Though, in my designs I've always brought 5V to the connector because I didn't think it would be good to connect a 3v3 power source to the output of the VREG. Perhaps 3v3 should be replaced with 5V?

 

3 hours ago, bigmessowires said:

In the schematic, BOOT0 is also left floating at an undetermined voltage if nothing is plugged into the SWD header. That won’t work reliably. For consistency with the existing PlusCart, I think it needs BOOT0 to have a pull-up resistor to 3V3, with a jumper to optionally pull it to GND, so that removing the jumper activates the bootloader. This is opposite from the ST-brand Discovery board where BOOT0 has a pull-down resistor and a jumper can be used to pull it high.

 

I would recommend using a regular pin jumper for BOOT0, like the existing PlusCart PCB. Or if you want to get fancy, USB VBUS could be used to automatically set BOOT0 to 1 when a powered USB cable is plugged in. Put a pull-down resistor on BOOT0 so it’s normally low, and also connect it to USB VBUS. It would need a voltage divider to bring the 5V VBUS down to 3.3 volts for the BOOT0 input.

 

Pin jumper or micro switch would be fine. BOOT0 would only be used for initial firmware flashing and unbrinking. I think a micro switch that's accessible via a paper clip sized hole would be the most professional looking option.

3 hours ago, bigmessowires said:

The PCB has USB VBUS tied directly to the board’s 5V power rail. If I’m correct that PlusCart is always intended to be powered from the Atari, then this VBUS connection to 5V isn’t needed or wanted. 

 

Wouldn't it be needed for USB-OTG? I'm not that familiar with USB-OTG either. It seems like we would need to have the ability to switch power to the USB VBUS from the MCU. Maybe there's an application note for this?

3 hours ago, bigmessowires said:

The USB D+ and D- traces usually have 22 ohm series resistors, but there aren’t any on this PCB. I’m not certain why they’re needed - maybe for proper electrical termination - but they’re present on most designs I’ve looked at including the Blue/Black Pill and the ST-brand Discovery board. I would recommend adding them.

 

USB D+ also needs a 1.5K ohm pull-up resistor to 3.3V, which tells the host this is a USB Full Speed device. This pull-up is present in the Black Pill and also the ST-brand Discovery board. Without it, the PlusCart will be identified as a Low Speed device with about 1/10th the maximum data rate of Full Speed. Note the Blue Pill uses the wrong pull-up value for this: 10K ohm (this might be fixed in some versions of the Blue Pill).

 

This all sounds good to me. 

3 hours ago, bigmessowires said:

@ZackAttack mentioned the possibility of USB OTG. I’m not very familiar with this, but at a minimum the board would need to connect the USB ID pin, which isn’t connected in the schematic right now. I think it'd also need a way to disable or bypass those 1.5K and 22R resistors when the cart is functioning as a USB host instead of a USB device. I would recommend not worrying about USB OTG for now.

USB-OTG is certainly the lowest priority of everything we've discussed. If it's a lot of effort, we can do without.

3 hours ago, bigmessowires said:

I might also suggest reintroducing the PAL/PAL60 jumper that was previously removed. Just in case somebody sets the TV mode to the wrong value in the menu interface, and then has a hard time seeing the menus to change the value, this would provide an easy fix. With two jumpers you could have four possible states for NTSC, PAL, PAL60, and menu-selected.

This could be solved in software. We could have a region override file in the root of the SD or something if this ever becomes an issue.

3 hours ago, bigmessowires said:

For USB support, An 8 MHz crystal should be connected to the PH0 and PH1 pins, with some parallel capacitors around 20 pF. But the ST design also calls for an external feedback resistor in the crystal circuit, and I’m unsure what value is needed for the resistor. The ST-brand Discovery schematic says it uses 200 ohms, but I think that’s a documentation error. I couldn't find any schematic for the DIYMORE board - maybe somebody can measure it. I found several different numbers in the STM32F407 datasheet and other ST literature, but they vary by a factor of more than a thousand! One says 200K ohms is typical, another says 1-5 megaohms at 10 MHz or 5-10 megaohms at 1 MHz, and a third does some math to calculate a value of 1326 ohms for 8 MHz with 15 pF capacitors. I don’t know what’s right.

 

I think the application note would be the best authority on this. This would be a good reason to use the larger SMD components. We may need to hand solder new resistors onto the first prototypes if we find they are out of spec.

3 hours ago, bigmessowires said:

For the new SPI flash chip, I’m assuming this should be a plain vanilla 8-pin SPI flash, not Quad SPI or something else. Is there already a plan for which pins and which SPI peripheral will be used? The SD card uses SPI2 on pins PB13-PB15. It might be possible to share that with the SPI flash chip too, just by adding an extra chip select signal, but it’s probably cleaner to use a wholly separate SPI peripheral. SPI1 at PA5-PA7 and SPI3 at PC10-PC12 are both potential options. We could look at the routing to see which choice would be easier to run the traces.

Chameleon cart uses W25Q128JVSIQ, plain vanilla 8-pin SPI flash that's cheap and easy to obtain. I think a separate SPI would be preferable.

 

 

I think it would be possible to restrict the design to only SMD components. The ESP-01S could easily be replaced with an ESP32-WROOM or similar. The pin header can be placed over a cart edge connector, making the pin header optional.

 

Another benefit of switching to the ESP32 is that we could add an SPI connection to it as well. My rough estimate is that a buad rate of 15MBit would be necessary to feed the Maria DMA in 7800 mode. If the ESP32 has a dedicated SPI connection it would easily hit that baud rate. Then we could put micropython on it and use the STM32 as a level converter for the ESP32. Being able to write Atari 2600/7800 games in python would be pretty cool.

[+Al_Nafuur]

9 hours ago, bigmessowires said:

Board Shape

 

 

Is the WIP PCB specifically designed for @Andrew Davie's 3D printed case?

No. It is designed to be used in unmodified standard cartridges or in @Sikor's cartridge here:

https://forums.atariage.com/topic/315756-new-injection-mold-atari-26007800-cases/?do=findComment&comment=4929821

 

9 hours ago, bigmessowires said:

Why does the PCB have a hole in the center? None of the other PlusCart/UnoCart PCBs that I saw have a hole there, and Andrew’s 3D-printed case doesn’t need a hole. I would suggest getting rid of the hole, to create more room and ease of routing.

The hole is needed so that the board fits into an unmodified case. So it is non optional.

 

 

9 hours ago, bigmessowires said:

The placement of the USB connector will have it completely hidden inside the case - is that intentional? Why not extend the PCB all the way to the edge of the case, and mount the USB connector there, so it would be accessible through a hole in the case instead of needing to disassemble the case?

5 hours ago, ZackAttack said:

I second this. The need to have USB and SD ports already makes the PCB incompatible with an original, unmodified cart shell. If this were a stand-alone cart for publishing games, it would be a different story.

The USB port is currently only for the initial flashing or for unbricking, so it doesn't need to be accessible.

 

The SD-card and the ESP are optional in production. A PlusCart (or PlusCart Zero) is supposed to fit into a (unmodified) cartridge.

 

 

[ZackAttack]

2 hours ago, Al_Nafuur said:

No. It is designed to be used in unmodified standard cartridges or in @Sikor's cartridge here:

https://forums.atariage.com/topic/315756-new-injection-mold-atari-26007800-cases/?do=findComment&comment=4929821

 

The hole is needed so that the board fits into an unmodified case. So it is non optional.

 

 

The USB port is currently only for the initial flashing or for unbricking, so it doesn't need to be accessible.

 

The SD-card and the ESP are optional in production. A PlusCart (or PlusCart Zero) is supposed to fit into a (unmodified) cartridge.

 

 

Won't that require destroying the label to get to the ports inside the cartridge? Would it be better to keep the hole, but place the ports on the edge of the cartridge and modify the cartridge to add the necessary holes for the ports?

[+Al_Nafuur]

24 minutes ago, ZackAttack said:

Won't that require destroying the label to get to the ports inside the cartridge?

only for the standard cartridge when the screw has been put in place. Sikor's case uses pegs and no screws, so the front label will not be destroyed. Same applies to the standard cartridge when the screw is omitted.

 

24 minutes ago, ZackAttack said:

Would it be better to keep the hole, but place the ports on the edge of the cartridge and modify the cartridge to add the necessary holes for the ports?

Occasionally sending a top label to a user who has bricked his devices (or adding a reserve top label to every PlusCart package) is much less effort than modifying all cartridges in production. Apart from that, I wouldn't know how to make a nice opening in the cartridge.

 

The changes that need to be made for the current version of the PlusCart are all "ugly", but internal only:

https://pluscart.firmaplus.de/pico/?Encasing#tutorial

 

[bigmessowires]

7 hours ago, Al_Nafuur said:

No. It is designed to be used in unmodified standard cartridges or in @Sikor's cartridge here:

 

7 hours ago, Al_Nafuur said:

The hole is needed so that the board fits into an unmodified case. So it is non optional.

 

I don't understand, sorry. An unmodified standard cartridge or @Sikor's cartridge won't work for a PlusCart Duo, because neither of those cartridges has an opening in the top for an SD card, right? If you're going to need to modify the standard cartridge anyway, or create a new molded/printed cartridge with an SD card opening, then why not eliminate the center screw? The existing PlusCart Duo with multiple sandwiched PCBs doesn't have a hole in the middle, and it doesn't seem to be a problem, so I'm unclear why a hole needs to be added now for this revision.

 

EDIT: I think you're saying you'd like this new PCB to work either as a PlusCart Duo or a regular PlusCart? And the hole is required to fit a standard cartridge shell when the PCB is used as a PlusCart with no SD?

Edited February 1, 2023 by bigmessowires

[bigmessowires]

13 hours ago, ZackAttack said:

It really doesn't matter which GPIO are used for 6507 Address and Data bus connections.

How would you all feel about moving the data bus back to pins PE8-PE15, which I think is where the UnoCart had it originally? The downside is that this new PCB would require a different firmware than the existing PlusCart and PlusCart Duo. The upside is that it would match the rglenn PCB exactly, and might make routing easier. I haven't yet looked to see if it would make a major difference, but hypothetically would it be OK to move those pins, or should I take it as a requirement to keep the data bus on PE0-PE7?

 

13 hours ago, ZackAttack said:

I do think it would be good to have a power pin for the initial firmware programming. Though, in my designs I've always brought 5V to the connector because I didn't think it would be good to connect a 3v3 power source to the output of the VREG. Perhaps 3v3 should be replaced with 5V?

I agree 5V would be better, so you're not overdriving the output of the VREG. I still worry that somebody would accidentally power the board from an ST-Link and from an Atari at the same time. For initial firmware programming, won't you have the PCB in an Atari anyway, so that you can test the board after it's programmed? Maybe there's a simple way to isolate the two power sources. Or maybe I'm over-thinking this.

 

If there's a 5V pin at the SWD connector, then I'd say VBUS should also be connected to 5V for consistency. Basically we need to decide whether the board is intended to be powered by the programmer / host computer, or it isn't. If it isn't, then disconnect all the power supply connections at the SWD header and the USB port.

 

I think you're right that USB-OTG would require 5V connected to VBUS though. I would vote to shelve the USB-OTG plans for the time being, since it does seem to complicate things.

 

What do you think about the idea of auto-configuring BOOT0 by detecting VBUS? I think the only downside is that it would preclude any future plans of building USB functionality into the PlusCart firmware - maybe something like interactively transferring ROMs from an attached computer over a USB cable. If the USB cable were only ever used for firmware updating, then auto-configuring BOOT0 based on the USB cable's presence seems like the best idiot-proof solution to me.

 

13 hours ago, ZackAttack said:

I think it would be possible to restrict the design to only SMD components. The ESP-01S could easily be replaced with an ESP32-WROOM or similar. The pin header can be placed over a cart edge connector, making the pin header optional.

I'm not very familiar with the ESP variants. The work-in-progress PCB specifies an ESP-WROOM-02, which I think has castellated edges so it can be surface mounted or have pins soldered to it. For this purpose, I assume we'd want to surface mount it. If all the components are surface mount, it would help reduce the batch assembly cost.

 

By the way, it should definitely be possible to hand-assemble one of these even if all the components are surface mounted, so it wouldn't be only for batch production. I've assembled similar boards with just a solder paste syringe and a $20 electric hot plate, no stencil required.

[ZackAttack]

Does anyone know approximately how much a 3d printed cart costs per unit? If it's comparable to the injection molded ones, wouldn't it be easier to go that route and let the USB, SD, and Reset button all be accessible?

 

36 minutes ago, bigmessowires said:

How would you all feel about moving the data bus back to pins PE8-PE15, which I think is where the UnoCart had it originally?

It's just a matter of setting a few pointers in the firmware. No problem at all. ACE and ELF based games should be using those pointers and will work without any modification to the game rom itself.

 

44 minutes ago, bigmessowires said:

I agree 5V would be better, so you're not overdriving the output of the VREG. I still worry that somebody would accidentally power the board from an ST-Link and from an Atari at the same time. For initial firmware programming, won't you have the PCB in an Atari anyway, so that you can test the board after it's programmed? Maybe there's a simple way to isolate the two power sources. Or maybe I'm over-thinking this.

 

If there's a 5V pin at the SWD connector, then I'd say VBUS should also be connected to 5V for consistency. Basically we need to decide whether the board is intended to be powered by the programmer / host computer, or it isn't. If it isn't, then disconnect all the power supply connections at the SWD header and the USB port.

 

I think you're right that USB-OTG would require 5V connected to VBUS though. I would vote to shelve the USB-OTG plans for the time being, since it does seem to complicate things.

Sounds like it might be best to always power the board from the Atari card edge connector. It requires less routing and prevents user error from potentially breaking something.

 

46 minutes ago, bigmessowires said:

What do you think about the idea of auto-configuring BOOT0 by detecting VBUS? I think the only downside is that it would preclude any future plans of building USB functionality into the PlusCart firmware - maybe something like interactively transferring ROMs from an attached computer over a USB cable. If the USB cable were only ever used for firmware updating, then auto-configuring BOOT0 based on the USB cable's presence seems like the best idiot-proof solution to me.

Assuming they all have Wifi equipped, the USB connection wouldn't be that useful. Everything we could do with USB could be done wirelessly via WiFi. Will it really be idiot-proof though? Won't they just leave the USB cable connected and then wonder why the cart isn't working still? Using a microswitch would have the benefit of automatically reverting back to normal boot as soon as they release the button.

 

I don't think either approach is more right or wrong than the other. You should choose whichever you like better.

58 minutes ago, bigmessowires said:

I'm not very familiar with the ESP variants. The work-in-progress PCB specifies an ESP-WROOM-02, which I think has castellated edges so it can be surface mounted or have pins soldered to it. For this purpose, I assume we'd want to surface mount it. If all the components are surface mount, it would help reduce the batch assembly cost.

Yeah, surface mount for sure. It will be nice to have a design that's easy to order fully assembled. The ESP-WROOM and family have flexible I/O, but there are some pins that are better suited for SPI than others. Also, some I/O is already in use by the module because it has external SPI flash built in. Something to keep in mind.

56 minutes ago, bigmessowires said:

By the way, it should definitely be possible to hand-assemble one of these even if all the components are surface mounted, so it wouldn't be only for batch production. I've assembled similar boards with just a solder paste syringe and a $20 electric hot plate, no stencil required.

Agreed. For the higher pin count parts, I prefer surface mounted because you can do many pins at the same time.

[+Andrew Davie]

3 hours ago, ZackAttack said:

Does anyone know approximately how much a 3d printed cart costs per unit? If it's comparable to the injection molded ones, wouldn't it be easier to go that route and let the USB, SD, and Reset button all be accessible?

The two forms of 3D printing for carts that are mostly relevant are FDM (basically a filament printer) and resin printing. FDM is cheaper but slower. Material costs are negligible; the main issue is that it takes many hours to print the components of a cart.  Let's say 6 hours, taking into account print failures and setting up the prints, etc.  It's not quick, so production runs of FDM prints are a bit of a pain. I'm not as familiar with resin printing, but can say the quality will be far superior to FDM prints, and in addition there can be designs that are difficult to print in FDM and simple in resin prints. If considering 3D printing my recommendation would be resin, for sure.  On the other hand, you can get multiple colours with FDM (e.g., the embedded pluscart logo in my design) which will be more difficult/fiddly to achieve in resin prints.

 

If you want a cost-per unit on FDM, then I'd say less than 50 cents of material, but + 6 hours of electricity and your time and frustration - how much is that worth?

[bigmessowires]

Yeah, I'm not sure 3D-printed cases are viable for batch production. I tried using Shapeways to get a quote for the front and back shells of your Atari 2600 PlusCart Shell v5 from Thingiverse, and the quote was about $21 each for the front and $25 each for the back, in quantity 10+ PA12 material, white. More than $50 total with tax and shipping, and that doesn't even include the lettering or logo. Granted Shapeways isn't the cheapest option for this, but even if another vendor were half or one-third the cost, it would still be too much.

 

Injection molds cost thousands of dollars to create, but after that's done the parts are very cheap to make, maybe around $1 each.

[ZackAttack]

I quoted the front and back with https://craftcloud3d.com/ for FDM ABS with the cheapest options it works out to about $4/cart plus $20 shipping. So, buying at least 20 at a time should work out to around $5 a cart. I assume they won't be as pretty as the injection molded shells. I think it's worth it to have the ports exposed though.

 

jlcpcb has a 3d printing service too. They quote about $5 each plus $20 shipping. But that's for SLA resin with sanded finish and it may be possible to combine shipping if the assembled PCBs are included in the order.

 

If we have a design with only the front and back halves it might be viable.