Replies: 14 comments 22 replies
-
|
Great work. 😄 One additional thing that might be worth adding to the main PCB is a dedicated AMS1117 3.3V regulator so that the Cart Reader doesn't need to piggyback on the LCD's 3.3V regulator anymore(solder jumper on the LCD module left open). And someone who doesn't want to solder SMD components could still use the current way of bridging the solder pads on the LCD module and just leave off the new regulator. |
Beta Was this translation helpful? Give feedback.
-
|
I went with the AZ1117IH because I have those in my parts box, but they both come in an SOT-223 footprint so either should work. |
Beta Was this translation helpful? Give feedback.
-
|
Looking great! One thing I'd like to see - that can be completely optional for folks who don't want to use it - is to expand the 5V pad where you connect to the Arduino, by adding a GND pad next to it at the standard 2.54mm spacing. I think plugging the Arduino in by a 90° JST facing out the side is nicer than having an awkward single header pin which faces up. It allows you to insert the Arduino while no wires are limiting your range of motion, and then plug in the power second, using the outward-facing JST. However, of course, a 2-pin JST header has nowhere to go on this board. Giving it a second pad for GND would give it stability. Of course the extra GND is completely redundant, and anyone who likes could leave it unconnected with no ill effect. Its purpose would be mainly to provide mechanical stability for a common 2-pin part. I figure since there are some changes to that area of the board it would be a great opportunity to add it in.
In the above picture, I've actually snipped the second pin of the header since it has nowhere to go - but this subjects it to a lot of stress and it's not ideal. Hopefully it illustrates the reason I think this would be a nice addition. (Everything said here could equally apply to a 2-pin dupont female connector and 90° 2-pin dupont header if that's the builder's preference.) Of course, just a suggestion, please ignore if you disagree! |
Beta Was this translation helpful? Give feedback.
-
|
I use a single wire and a horizontal header like the N64 controller port has but with 1 pin instead of 3. I face mine towards the inside, though the new design doesn't allow for that so I'm still trying to figure out a better solution as I don't want the wire to stick out the side. A ground wire isn't necessary as the path to ground on the mega mini is already pretty short, using a wire might even make it longer because of needing some slack to allow for installation/removal of the module. Also, you should be keeping that wire as short as possible. Ideally, the port would be on the main PCB but then you'd have to solder the much smaller data +/- wires to the mega. That's why HW7 just integrates all the components onto the main PCB -- there is only 1 PCB in HW7. Right now I'm not too concerned about making HW5 "perfect", there are just a few things I wanted to add because they made me uncomfortable. The lack of proper ESD protection, overvoltage protection, etc, were the big ones I wanted to fix. The rest I'm addressing in future hardware revisions as they would change HW5 so much that it wouldn't be HW5 anymore. To give you an idea of what I'm working on, here are most of the big features of HW7:
As you probably guessed, HW7 will be expensive, especially to self-build, and is not aimed at the DIYer. It's intended to be entirely machine assembled and should hopefully cost around $250-300+ fully assembled (price not final yet). Weirdly enough, despite the insane amount of additional features, it looks like the smallest full-featured version of HW7, which only has the universal slot, will be significantly smaller than any previous hardware revision -- it'll be just a bit bigger than the PCI-E slot. A GBx-only version could be made even smaller, so small it could fit into a coat pocket. You might be wondering why I skipped HW6. That's actually why! I plan to make a "lite" version of HW7 which drops some features to make it easier to DIY, this will be called HW6. HW6 drops the harder-to-solder features entirely, like the battery module, USB hub, etc. Then, most other features, like USB PD, will be optional. Finally, it uses the much cheaper RP2040 (the chip on the Raspberry Pi Pico). It will support soldering a Pico to the board for easy DIY, or if you want more features (such as USB C/USB PD [sink-only]) you can solder the RP2040 directly to the board yourself. It requires hot air, a reflow oven, or a hot plate, but isn't nearly as hard to DIY as the STM32 and DDR3 ICs are. The cost of HW6 should be about the same as HW5, however, due to a few SMT components that cannot be avoided/made optional, it still doesn't completely obsolete HW5. So, while HW6 is better in almost every other way, HW5 will still be a useful project for someone looking to dip their toes into electronics assembly/soldering. HW6 is not as good as HW7, but it is a good project if you want something that is only intermediate difficulty. HW6 only supports USB 2.0 full-speed, so the data transfer rate is slower. It also has limited memory (264 KB SRAM on HW6 vs 512 MB DDR3 on HW7) and storage for the firmware (16 MB of flash on HW6 vs HW7 which is limited only by the size of the SD card you use). Also, since HW7 isn't really approachable for most people to DIY there likely won't be any kits for it. That means that if someone that can DIY HW6, then it can be had for a lot cheaper than HW7. A kit for HW6 should only cost around $100 -- it might even be cheaper than HW5 due to the Pico/RP2040 being cheaper than the mega and significantly fewer components that require hand assembly. Most of the cost of HW6 is actually in the I/O expanders since the RP2040 does not have enough I/O and even if it did it isn't 5V tolerant. HW6 has fewer headers to solder vs HW5 since it's also a single-board design, however, it will have more components. It has support for a lot of the really nice QoL features of HW7, including the universal slot, cart insert detection, and arbitrary voltage supply via I2C. Yes, that means as with HW7 the cart slots won't be powered unless being actively utilized by the system (this is one of those things that bugs me about HW5). The main features HW6 drops are the performance of the STM32, expandability/future-proofing via the M.2 form-factor slots, USB accessory support (i.e. thumb drives), battery pack support (and thus USB PD source capability), and a few other minor features. Even the FPGA will be supported via HW6 (it will be optional, as although it is small, it is still a BGA package). It'll still be a very capable system and a significant improvement/upgrade over HW5. After HW6 is out, I suspect preassembled HW5s to go away. Much like HW7, HW6 will also be designed with machine assembly in mind, though unlike HW7 it won't be designed with that being the primary/only way to do so. As such, a preassembled HW6 might actually/should be cheaper than a preassembled HW5. A pre-assembled HW6 might cost as little as $150, which is about what it costs to source the parts to build HW5 (in terms of single-unit pricing i.e. via aliexpress, not via kits, as I sell kits for $100). Finally, to give you an idea of the robustness/complexity of HW7's USB support, here's the current schematic for it: Note that this is only the USB-specific components. Power is handled on another sheet, HW7 has several sheets. It's extremely complex which is why it's taking so long. Here's the dev board I made to test USB PD:
Also, while these components aren't super expensive, it's taken so many iterations that the cost is really starting to add up. I've already spent over a thousand USD working on HW7 (most of which was buying small runs of prototype PCBs) and I haven't even attempted to build an actual HW7 yet. Right now I'm just doing a proof-of-concept for the main individual components as nearly all of them have no dev boards available (only the STM32 and FPGA had [useful] dev boards available). The PD controller I'm using had a dev board, but it was not appropriate for my/our use case. At this point, I've got HW7 (and HW6) mostly figured out. The limiting factors right now are just time and money. Hell, the reason I started selling kits and preassembled OSCRs was specifically to fund development. When I start prototyping the actual main board that's when it's going to get really expensive, as the STM32 and DDR3 are not cheap. The STM32 chip, by itself, is just over $20. This is made worse by the fact that BGA chips are annoying to move between boards to the extent that it isn't worth it for me to do it as reballing a BGA chip is labor-intensive and a reballed chip is more likely to have issues when installing on a board (because it's more likely you reballed it incorrectly than it is that a new one from the factory was balled incorrectly). So I'm trying to be as close to 100% sure the design will work as I can be before attempting it. Edit: Edited to fix some typos and clarify a few things. |
Beta Was this translation helpful? Give feedback.
-
|
So, things got interesting...
|
Beta Was this translation helpful? Give feedback.
-
|
As an individual who has followed and contributed to this project for over 4 years, HW7 sounds terrible. It feels like a big middle finger to the community that has made this possible and destroys the DIY nature of the project. Here are a few of my concerns Only people with deep pockets or expensive equipment can put one together. Companies like Cypress make development boards that HW7 could be based on without making it impossible for average individual to build. Are you going to be one of the few that can actually manufacture these? This will greatly increase cost and skill to build, slowing the ability to quickly reiterate hardware and software. This could break combability with all the current hardware adapters. 4 Layer PCBs are much more expensive than the 2 we use now. Between hardware 5, 6 and 7 it will split software development into three different platforms that will all need to be maintained. During the pandemic RiPi stopped selling to individuals and prioritized business customers making the hardware very expensive and hard to get. This could potentially happen again with HW6 being a causality. In 5 years 2560s will still be available will RiPi still be making 2040s? While I agree the 2560 platform is reaching its limit, not a lot of systems are left to add. Perhaps it is time to switch but this HW7 seems to be a bad way forward. Adding GG to the board is a a nice addition. Changing the build making it impossible for the average DIYer is really out of the scope of why this even exists in the first place. It feels way out of line. You have good ideas and the design work looks great but the implementation undercuts the spirit of this project Handles |
Beta Was this translation helpful? Give feedback.
-
|
I’m a hobbyist who has been soldering for a few years now and regularly assembles boards far more complex than these by hand, and my $90 Yihua 8796D is perfectly sufficient to complete this project. I guess I’m really just commenting to say that an increase in complexity or skill requirement does not necessarily mean something is no longer DIY. Personally I’m excited to make this project, and if anyone out there needs soldering pointers, I’m sure I’m not the only one that will walk people through the proper way to do it. That being said, if you or anyone else needs help mastering the skills necessary to solder this together, I’m willing to help. |
Beta Was this translation helpful? Give feedback.
-
Hot air stations aren't cheap, but they aren't prohibitively expensive. If you want to learn SMT soldering, where are you supposed to start? HW5 already has SMT parts on it. Some parts only come in SMT and there are no THT alternatives or the THT alternatives use more components (and are more expensive) or don't work the same. A THT decoupling capacitor basically doesn't exist. Can you add a THT capacitor next to a chip? Sure. Does it do anything? Not really, no. Dev boards are limiting. Even the Arduino Mega, not all the pins on the Mega are broken out. I put the Mega on the new HW5 main PCB coming out soon. Because of this, I got access to some pins we didn't have before. People who put their mega on the main PCB instead of a module will be able to get features others cannot. I can't do everything I'd like because it would break compatibility with using the module, but I still want to add as much as I can to HW5. If I just choose a dev board, we are right back here to having no control over certain aspects of it. We are back to lots of manual labor. We are back to having a board that's limited because we are trying to support tight integration and a modular design at once. You cannot have your cake and eat it too. I looked at dozens and dozens of dev boards and not a single one ticked every box. The ones that came close cost over $100 just for the dev board. After adding the other components and markup, that could make a prebuilt unit cost $400+ and a kit being around $200 -- all this while still having fewer features than what is planned. Not only that, but doing it this way would raise the barrier of entry for people to join in offering prebuilts in their country due to the high cost of stocking the dev board. It just doesn't work when the cost of HW7 is just a bit over the cost of the dev board I'd use in its place. Sure, I could go with a cheaper dev board/platform, but then it doesn't fix all the issues that I'd like to see addressed. HW7 is the solution, meanwhile, HW6 already is the compromise. Don't want the expense? Use HW6. Prefer HW5? Keep using HW5. Everything is open source, I couldn't stop you even if I wanted to, which I don't.
The skill will go up, but pre-built units will cost about the same as they do now. Most of the cost in HW5 is the manual labor required due to the use of so many THT components that can't be machine-assembled.
I fail to see how this makes it harder to work on the software. A prebuilt HW5 costs around $200-250 depending on who you buy it from. Quite a few people who contribute to the software side are using prebuilt OSCRs. As for reiterating hardware, no one needs to. That's the whole point of HW6 and HW7. They incorporate some expandability features, which is especially true of HW7. If someone wants to add something that isn't a new console/system to HW5 right now then in most cases they need to edit the main PCB and everyone needs to replace their main PCB or use a bunch of bodge wires and a module taped to it. With HW6 and HW7, you make a module for one of the expansion slots and just insert it in there. They have so much IO hanging around (again, especially HW7) that there are just free IO pins ready to be used, not to mention HW7's USB 480 Mbps USB host support -- something that's required for one of the main features that even prompted me to do this to begin with. Otherwise, the RP2040 would be enough.
It will not, but making and using new adapters will give additional features that were previously unavailable (like detecting when a cart is inserted into an adapter, which obviously current adapters have no way to do that, as well as the OSCR knowing what system the adapter is for and how to use it without you having to tell it -- these are optional features that only increase the material cost of adapters by 30-50 cents, by the way).
It will not. The UI logic will need to be maintained on its own but the core logic is the same for all platforms.
RP2040s were still available and have been stocked fairly regularly since their launch. There was only a shortage of them for about a month because people were trying to buy them out instantly. Once the scalpers gave up the stocks were fine. You aren't entirely wrong though. At first I looked at the CM4 but the stock issues made me decide against it because what's the point if you can't get them? But the RP2040 didn't really have this issue. HW6 uses RPi's silicon, but HW7 uses the STM32. If both of these are out of stock, chances are every other modern chip is as well so it's moot. And HW5 with the mega is still there as a fallback. If RPi EOLs the RP2040 it'll likely to be to replace it with something else that's similar but better (see the Zero for instance). In the mean time, Arduino is the main reason the mega still lives. You know they are pushing people away from the mega, right? So will the mega still exist in 5 or 10 years or will Microchip EOL it? 8- and 16-bit AVRs are falling out of favor. I looked at 32-bit AVRs but they aren't that well supported. I chose platforms that are.
You cannot enable many more than the default systems due to the limited program size. You'd need 3 HW5s if you wanted to be able to support every system without reflashing. There are people who do this because they don't want to constantly reflash their OSCR. Oh, and the flash memory does have a limited number of write cycles. It's pretty high but if you are switching multiple times a day you can hit that limit and you'll need a new mega.
The spirit of the project is a cheap open-source cartridge reader. Sanni's stated goal was for someone to be able to get the readers cheaply. Adding SMT footprints to HW5 should make it possible for US-based sellers to sell a prebuilt for around $150. That's $100 cheaper than prices now. HW7 just steps into the position of the $250 unit for those who want more features and HW6 should be able to be sold for around $100 as a prebuilt -- that's cheaper than even a kit is right now. You honestly think these changes are bad? Also, HW6 is somewhat DIY-friendly, you do drop features to fully DIY it easily, but that's also true of HW5 now. There's no vselect without using SMT, there's no RTC without SMT, etc. HW6 is intended to replace the mega versions while HW7 is intended to sit alongside HW6. Support won't be dropped for HW5, but we have hit a wall. There are no more IO pins left on the Arduino Mega for us to use. We are long out of program memory. We are low on RAM. The mega doesn't have a fast enough USB connection to reasonably transfer data via USB (RP2040 has the USB issue as well). The platform has reached its limit, it's time to start looking forward. |
Beta Was this translation helpful? Give feedback.
-
Will they?
The ATMEGA328 is the Uno's chip. With the 2560 being almost 20 years old and 8-bit AVRs being 27 years old, how long will it really be before the 2560 is EOL? Even Arduino is moving on, the GIGA WiFi uses an STM32. |
Beta Was this translation helpful? Give feedback.
-
|
There have been some new developments... Things got MEGA! (heh, get it?)
LEDs!
OooOOOooo what's this do?
Heh.
Tired of needing to build the new revision for new features? Me too...
Can't have an on-board mega without an ISP header...
It works for the module version too :3 |
Beta Was this translation helpful? Give feedback.
-
|
i am happy to see the n64 connector points to be angled. allowing it to be turned into a header pins. might i suggest using JST instead of dupont? reason: they are keyed. |
Beta Was this translation helpful? Give feedback.
-
|
I considered it but didn't want to add to the already increasing part count. |
Beta Was this translation helpful? Give feedback.
-
|
The right angle JST XH has almost the same footprint. And the same pitch as DuPont. So a XH spot can be populated with a XH, DuPont, or direct wire to board. This would give people choice. |
Beta Was this translation helpful? Give feedback.
-
|
It's 2.5 mm vs 2.56, it probably would work without any changes since it's only 3 pins. |
Beta Was this translation helpful? Give feedback.
-
|
ive used 3 and 4 pin XH and dupont interchangeably in the past. |
Beta Was this translation helpful? Give feedback.
-
|
This looks really cool. Any ideas when rev 6 will be complete? Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
“The ATMEGA328 is the Uno's chip. With the 2560 being almost 20 years old and 8-bit AVRs being 27 years old, how long will it really be before the 2560 is EOL? Even Arduino is moving on, the GIGA WiFi uses an STM32.” Is alerting strangers about discontinued parts that are not part of Sanni BOM and ignoring important questions like FatBeards really the best use of your time? |
Beta Was this translation helpful? Give feedback.
-
|
I cannot provide answers when even I don't know the answer. Is being combative with volunteers really the best use of your time? |
Beta Was this translation helpful? Give feedback.
-
|
Status update: Currently up to Rev 8. Rev 6 and 7 both contained errors. Revision 2 of the OSCR TC2050 ISP board I created has been validated. This uses the same USB circuit as the new HW5 revision so it should mean HW5 Rev 8 validates as well.
|
Beta Was this translation helpful? Give feedback.
-
|
One thing I could use some feedback on is the new revision's SMT LEDs near the USB port:
All of them except for STAT are specced in the BOM as blue LEDs (XINGLIGHT XL-1608UBC-04; LCSC Part Number C965807, DigiKey Part Number 5962-XL-1608UBC-04TR-ND), though they could be replaced by any 0603 SMD LED. Currently, to keep the number of unique parts on the BOM to a minimum, I used a part that was already used elsewhere, a 1k SMD 0402 resistor. Despite the LEDs being able to use a resistor closer to 100 ohms they are still pretty bright since they are blue LEDs. For an open-frame build, the 5V and USB LEDs are probably too bright but the 3.3V LED is about right. However, if someone is putting the board into a case the USB and 5V LEDs are about right and the 3.3V LED is a bit too dim. Also, and perhaps more importantly, should the LEDs stay all the same color? The USB, 5V, and 3.3V LEDs are primarily to show that everything is functioning properly: That USB power is being received, and that 5V and 3.3V are present. That means when not troubleshooting a device these LEDs aren't all that useful. However, the CBUS LED is meant to show when the cartridge slots are powered to let you know not to hot-plug a cartridge. So perhaps it should be a different color? CBUS could be either 3.3V or 5V, so it's difficult to spec the resistor for this LED as it will be brighter when 5V is being supplied. This could be viewed as a feature though, since you could use the varying brightness to know what voltage is being supplied. Finally, the STAT LED is an RGB LED that is exclusively controlled by the ATmega2560 directly installed on the main PCB and is unavailable when using a MEGA EMBED/MINI module. This LED is intended to be used to indicate the status of VSELECT but could be used for other purposes. It can only produce solid colors at full brightness as all of the PWM pins were already used. I used 1K resistors for this LED as well. Trying to keep the number of unique parts to a minimum, these are the choices for resistor values:
It's worth noting that changing the color of the LEDs also requires changing the value of the resistor. Blue LEDs are notorious for being bright. If someone were to install a red LED instead, it would be extremely dim with a 1k resistor, especially on 3.3V. |
Beta Was this translation helpful? Give feedback.
-
Ah, that makes that easier, then, the Mega concerns don't matter as much, other than for STAT. |
Beta Was this translation helpful? Give feedback.
-
|
The STAT LED is part number NH-B1515RGBA-HF (JLCPCB Part Number C2874115). |
Beta Was this translation helpful? Give feedback.
-
I personally like to limit how much I use the hot-air station I have at work, to reduce heat stress to everything (a reflow-oven would at least be even stress and ideally relatively quick). But yeah, I can do 0402 by hand-- it just looks like a pig with a soldering iron did the soldering, lol. I manage to make significantly better soldering connections with some magnfication.
Fair enough. I'd have to see the rest of the entire board to see if I can move components around, lol. Maybe I'll do something like that for a personal revision of the board, should I bother to try to replace my current revision (where I did replace all 0402s with 0603s).
That's my kind of reasoning, lol. I definitely need more of that kind of practice. |
Beta Was this translation helpful? Give feedback.
-
|
So in terms of intensity, if that blue LED is the cheapest you can find, lol, it should be fine, you may want to swap some resistors with your first prototypes to see if you can get the intensity you want (could stick to the resistor values in you BOM first). |
Beta Was this translation helpful? Give feedback.
-
If I hide the copper fills it becomes pretty obvious how tight it is around the USB port:
As well as the area around the ATmega in general:
Granted, if I could put components on both sides it would be a lot less cluttered. However, I wanted to minimize the number of components on the back of the PCB so economic assembly was viable for a mix of configurations. The only components on the back (other than the existing battery retainer) are the 4 capacitors required by the USB specification and the AUX header:
Omitting the caps violates the spec but will still probably work with most devices/supplies. The AUX connector has no functionality at present and might never. So, both are somewhat optional. |
Beta Was this translation helpful? Give feedback.
-
|
I should probably also mention I've fixed the footprints so that when exporting the PCB for production the positions of the parts shouldn't need to be fixed when uploading them to JLCPCB for assembly. Additionally, configuring the PCB's BOM has been improved:
Note: Configuring the BOM doesn't set the jumpers. When I commit the new revision there will be 2 production files provided:
|
Beta Was this translation helpful? Give feedback.
-
|
Well, it took a while, but it's finally at least partially working. I haven't tested everything yet, but so far, most of the important stuff I have tested is working. What I've tested so far: Portected USB Type-C-compatible PortThe USB Type-C-compatible port (the "-compatible" part is because it's a trademark that needs a license to actually call it that) appears to work. Mine is a little flaky and sometimes disconnects, but I believe that's just my assembly not being great rather than anything wrong with the design -- the solder paste is only good for a short time, and it takes far longer than that to manually place all the components on the board. It also potentially could be the lack of components on the bottom side of the board, which I omitted for this test. Not installing them technically violates the USB specification, so some issues are to be expected. I used a similar design (same components, slightly different layout) for the USB programmer (described later in this update) and the machine-assembled version of that does not experience these issues. Whether that's because the fab did a better job or because all the components are present is unknown, but also moot at the same time. But the board gets power from real USB Type-C Power Delivery (C-to-C) compliant power adapters and works with my computer's Type-C port. The components specified request up to 3A @ 5V from compliant power supplies, which is far more than the OSCR needs for most people. The extra power draw capability could be handy for later accessories, but shouldn't ever really go above 1A of draw, regardless. I don't have the equipment to properly test the added protection against ESD, short-to-VBUS, etc, so I just have to assume it's working as I followed the "Typical Application" section of the data sheets for the protection components. I have not tested if the ferrite bead makes a meaningful difference when it comes to noise on VBUS, but I can test that with the scope later on (it needs to be fully assembled to be a true test). If it doesn't, it could either be omitted and the contacts bridged or replaced with a polyfuse of the same footprint instead. Happily, the CH340N seems to work fine, and I can flash the ATmega2560 over USB with the Arduino IDE as normal. The CH340N is nice because it is a smaller package than the CH340G on the module we normally use, and it doesn't require an external crystal, reducing the number of components on the BOM and thus the cost to produce the assembled board. The USB port can be used with the integrated ATmega2560 or with the module -- either works. If you want to use the port, most of the components are required to complete the needed circuits. If you just want the protection offered to VBUS and are fine with using the port on the module, you can do that, and only a few of the components are needed, since then the USB data lines are not used. Integrated ATmega2560, Clock Generator, and 3.3V RegulatorOf course, the headline feature of this revision is the integrated ATmega2560. The integration not only reduces the cost of mass production by making the board require less manual assembly, but it also increases the number of features the board can offer. When the Arduino team made the Arduino MEGA, they did not break out all of the pins to the headers, leaving quite a few unused. Placing the ATmega2560 directly onto the board gives us access to these pins. Some of these I've already made use of but a few remain unused. I've broken out all of the previously unused pins, including the ones I've already used, as well as all of the voltage rails and the I2C bus, to a header on the bottom of the board. This header, the AUX header, is for future expansion. It should hopefully allow someone to easily add any new hardware features to this revision (and newer) without having to replace the entire main PCB. Additionally, I routed 2 of the unused pins to the headers going to the top PCB. They are physically pins PE2 and PE7, and I labeled them CA0 and CA1 on the silkscreen and schematic. These pins replace D0 and D1, which could not be used anyway because they are used by the ATmega2560 to communicate with a PC via UART (using the CH340). These 2 pins could be used for adapters, though, because they require the on-board ATmega2560, they should only be used if there are no other pins available. Another reason someone might want to use them is that they are routed to the AUX connector on the bottom of the main PCB, so if you wanted to have an adapter able to talk directly to something that only needs 1 or 2 pins. Though you could put most things like that directly onto the adapter, it could make sense if you have multiple adapters that can make use of something. It also could make sense to relocate something you need to plug in so that it could be left plugged in even when removing the adapter. Additionally, the clock generator and 3.3V regulator have been added to the main PCB. These can be installed with or without the integrated ATmega2560. When using the onboard 3.3V regulator, you don't need to bridge the jumper on the LCD. A solder-jumper is provided to allow choosing between connecting the 3.3V rail of the main PCB to the one on the LCD. This jumper is closed by default since normally you need to close the jumper on the LCD to enable 3.3V out. When using it with an old LCD that is already bridged, you can either remove the bridge on the LCD or cut the solder jumper on the main PCB. This option was provided so you could keep an LCD configured to provide 3.3V while still having an onboard 3.3V regulator -- useful for people who want to have multiple revisions but only one LCD. Indicator LEDsI still need to toy with the values of the resistors to adjust the brightness and decide on colors, but these appear to be working fine. The LEDs labeled USB/VBUS, 5V, 3V3, VCC, and CBUS (described later) are all wired directly to their respective power rails. So, if those LEDs aren't lit then that means those voltages aren't working. Another LED named STAT is an RGB LED connected to the ATmega2560. Because the PWM pins are already in use, the colors can only be toggled on or off, but it allows some limited feedback on what is happening in the background. I intend to use it to indicate the voltage chosen by the firmware/VSELECT, since, at present, there's no visual indicator anywhere about which voltage is selected. Cartridge Power Rail (CBUS)I've tested this and it is mostly working. Adding a fairly cheap "ideal diode" to the board allows for toggling the voltage that goes to the cartridges on and off. Once implemented in firmware, this should make hot-swapping cartridges without powering down the OSCR safe to do. As mentioned above, there is an LED on the board that is illuminated when CBUS has power. This lets you know when CBUS is powered and when it is not, so you have a visual indicator of whether or not it's safe to insert or remove a cartridge. This LED is powered directly by CBUS and doesn't rely on the firmware to toggle it directly, meaning that even if the firmware were to have a bug that enabled it when it shouldn't, the LED should still illuminate to indicate that. It might also help with unlocking SA1 chips since it allows for precise timing of when the cartridge, and thus the SA1 and CIC module/chip, receive power, but this requires more in-depth testing. Voltage Monitors (VMON)
The status pin of the TPS2113 (VSELECT) is also connected to one of the pins of the ATmega2560, allowing for monitoring of VSELECT as well. All of this will be handy as it will enable the firmware to check that all of the voltage rails are present and that VCC is toggled to the correct value. I'll be adding some "safety" features to the firmware that will check if VCC is sane before toggling the cartridge power on. This should help to protect 3.3V carts if 3.3V is unavailable (or 5V) for some reason, as the firmware will be able to see that the VCC monitor is still seeing 5V and let the user know something is wrong without ever exposing the cartridge to that 5V. Closing ThoughtsI think this revision attempt is fairly promising so far. The only thing left to test is the ribbon connectors going to the top PCB, as well as the new top PCB that makes use of those connectors. There are a few other minor things I didn't mention in this post (extra capacitors and such), but they aren't really a big deal. There is one other thing I didn't mention that I'm excited about, but I want that to be a surprise, so you'll have to wait for the commit to see it :) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I have a few updates since my last post. First, I managed to get the BIGTREETECH LCD module working on the new revision: Here is a side shot of the R8 prototype showing the FPC/FFC connections: ...and here is a shot of the back showing off the new Game Gear slot option: The connection for the Game Gear slot is made via the FFC/FPC connector on the top PCB. As such, only the RetroSix slot is supported -- the OEM Game Gear slot is incompatible. The reason I was able to get this to work here is due to the way RetroSix did the slot. Since it uses that flat cable I didn't need to worry about the THT pads under it as they would have to be where the GBx slot is. Oh, and as a few people in Discord pointed out, if you omit the Game Gear slot you can make this new HW5 quite thin (height-wise) since there aren't any headers needed to clear other than the LCD. For an extremely compact HW5, you could either do a headless (no-LCD/serial-only) build or solder the IDC cable directly to the main PCB. It would still be quite deep, but you could reduce the height significantly. I'm still working on the new firmware update but one of the things I'm adding to the firmware is the ability to mix-and-match hardware revisions. For instance, you could easily use HW5's pinout but the LCD module and buttons from HW3. That will be possible because I'm splitting out the UI code from the rest of the code based on the type of LCD (or serial, if headless). Each UI has a dedicated file, and the functions are standardized between them. For instance, you will call the function to print a menu with all the options for the menu and the function itself decides how to display that menu. Another change I made to the firmware is splitting the strings into a dedicated file. This should allow for translations. You'll be able to specify a language via the If people would like a more non-technical way (as in, not having to edit a source file) to do translations, let me know. I was thinking I could make something to sync a wiki page or something to the git but I'll only do that if there's at least a few people who would like to contribute but don't want to have to edit code/learn to use git. Anyway, stay tuned for more updates! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I forgot to include a screenshot of what a language file looks like. Here:
This isn't final yet, I might call the namespace something else other than |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Yes! You read that correctly, seven-slot adapter. I've finally got it to where I want it so I decided to start showing it off a bit and get some feedback. I've been kicking this idea around for a while but finally decided now is the time.
So, what system is the 7th? None other than the Game Gear, of course! I managed to squeeze the mounting holes onto the main PCB as well as the RetroSix-style header onto the slot adapter PCB...
However, adding the mounting points for the GG Slot is not the only change for the main PCB R6...
There are a few new optional components that you can install to improve the resiliency of the OSCR. As you may or may not know, the way we power the OSCR is by removing the fuse from the mega and then jumping a wire to the main PCB. Some of you may have noticed we don't reuse that fuse and thus leave the entire system without much, if any, protection.
So to remedy this, I have added some things I've been working with for use on HW7 as with HW7 there is no module, it's being designed to be entirely machine assembled so everything is integrated onto a single PCB. That means I had to work out implementing the full USB spec. I decided to backport the safety features to HW5. Here's a snippet from the new schematic showing the changes:
A few things are happening here. First, a 10nF decoupling capacitor is near where the power comes onto the board, as required by the USB specification. Then we have our star of the show, the TVS2200. This provides the OSCR with ESD and surge protection. Sadly it is only available in a WDFN package, which requires hot air, a reflow oven, or a hotplate to solder. Then we have a 4.7uF capacitor and a ferrite bead, which will filter out power noise. This is most useful if you are using a computer to power the OSCR, as the USB power from a computer can be pretty noisy. After that, everything else is the same.
Overall, the changes to the main PCB only add less than $1 to the cost of parts using single-unit quantities from Digikey. The parts are optional, but you will have to bridge the ferrite bead pads if you aren't using it.
For the Seven-Slot Adapter, quite a few things have changed. Since the only reason to use the 7 over the 6 is for the GG slot I used the SMT version of the Six-Slot Adapter that I had already been working on. When installed it looks pretty much the same, but the bottom of it is a different story...
You can see the GG slot header at the top. But you may also notice that the CIC PCB header is absent, opting instead to place the components directly on the PCB. Great care was taken when routing the clock and CIC signals for the SNES. I tested both adapters and it seems like unlocking might be more reliable, but I only have 3 SA1 carts to test with so I couldn't prove it.
You might have noticed the footprint for the N64 controller changes a bit. I switched to using a horizontal header so that I could use a connector for the N64 controller port. I felt like this is a more user-friendly design as it makes it much easier to take the OSCR apart. This also makes it easier to replace the port for those buying pre-built OSCRs as you can swap out the port without having to solder anything.
Also, you probably noticed there are a ton of footprints for decoupling capacitors. These are optional but do seem to help a little with some systems/cartridges.
Finally, the more keen-eyed among you may have noticed the lack of a ground fill. That's because the Seven-Slot Adapter is a 4-layer PCB. The inner layers are for power and ground. Because of this, there is no ground-fill. Going with 4 layers was necessary to implement all the new components that were added to the board. Here's the PCB Editor view:
I still need to work out the new build steps as a few things have changed regarding assembly and parts. Not only the obvious, but the height of the spacers had to be increased to accommodate the GG slot which sits above the GBA slot. I haven't tested assembling it yet as this is all still a work in progress, but as of right now, it appears that 22mm spacers will be needed, possibly even having to go with 24mm.
Also, to clarify, the main PCB is an update to the existing main PCB. It retains compatibility with most existing accessories and the existing Six-Slot Adapter. The frame/housing is the only thing that will need to be modified again, both to accommodate the GG slot and because the RTC battery had to be moved. On the other hand, the Seven-Slot Adapter will be a new adapter and will not replace the Six-Slot Adapter, which will still exist. However, I will be committing a change for the Six-Slot Adapter too which contains the modified N64 controller port header as this doesn't increase the difficulty of assembling the PCB. I kept the revisions of the PCBs in sync to make it easier to compare them since a change in one is likely to affect the other.
Anyway, let me know if anyone has any questions/suggestions/ideas/changes for these updates.
Beta Was this translation helpful? Give feedback.
All reactions