Tschicki
.
It’s about time for a new update!
I did not post anything lately, but that doesn’t mean there was no progress. There was a little summer break indeed, but apart from that the design has progressed considerably. Here are the topics I have updates for:
JLC housing vs. FDM
The SLS housing from JLC arrived after 4 long weeks of waiting and I must say that I was pretty disappointed. The accuracy is great, but I’m not happy with the dimensional stability of the PA12 parts. The material is simply too soft for this thin & flat design and on top of that, both top and bottom housings arrived slightly warped. The warping was acceptable in the beginning, but it got worse a couple of weeks after I received the parts (I suspect due to the hydroscopic nature of PA12). Surface finish would be acceptable, although I’m not a big fan of the rough texture. What bothers me about the surface, though, is that you can see all the polygons of the STL file, due to all the curves. This could have been avoided by uploading the files as STEP, but there the online calculator always failed to process the parts correctly.
To have a comparison I printed the housing on my X1C using PLA and to be honest, I much prefer the FDM printed housing over SLS. The overhangs might need some polishing, and the surface finish is not as uniform, but for some reason the FDM part feels more “premium” (probably just my bias towards FDM… ).
Due to the material being PLA, the housing is also much stiffer than the SLS parts.
To sum it up – I will proceed with FDM for the final housing. Not just the above aspects are worth considering, but also the benefit of having full control over the printing process – I can do different colors, materials, or even combinations of the two (PLA housing with TPU grips??), and all that with as many quick iterations as I want.
Speaker housing
In a previous update I was describing already how I failed to come up with a switch oled speaker housing that is both slim and sounds good. After way too many iterations, I finally have an acceptable design. Now it’s designed after the original part from Nintendo, with heavy modifications to make it fit my housing. The idea is that this will slot into the battery compartment and form a part of the left and right gamepad assembly. The speaker housing itself now consists of a top and bottom part, which will most likely be glued together to get an airtight seal. The chamber behind the speaker will for sure need some tweaking when I assemble the first prototype, but I left plenty of space for that.
Gamepad emulator with PIO
With the help of @stuckpixel I managed to rewrite a large chunk of the DS2 emulator code, to ditch the ARM PrimeCell SSP peripheral for a proper PIO implementation. The problem with the SPI peripheral of the RP2040 was that the DS2 communication protocol is quite unusual, and on top of that the PS2 likes to stop/start communication randomly (often during transfers). A big chunk of the interface code was actually recovering the PrimeCell from situations like that, using the brute force way of resetting the whole peripheral after every transfer to get it back into a known state. While this worked, it had lots of overhead and sometimes broke timings. I actually found 3 games during testing that were not compatible with the old implementation (the Spyro games and Shadow of the Colossus).
Now with PIO the code is much more elegant and especially the ACK is much faster and more predictable. While debugging I also found a bug regarding the device type, where the emulator wouldn’t switch between analog and dualshock mode correctly. After some more testing I found that the 3 incompatible games also work properly now.
Gamepad flex
The left and right gamepad flex PCBs were designed and ordered. Here I decided for a big change – in order to optimize the BOM and for saving costs, I replaced the I2C IO expanders and I2C ADCs with one RP2040 per side. While it’s way overkill, that way I can reuse all the BOM items of the syscon. I can also save the I2C LED driver for the power LED this way, and many more functions can be integrated in the future. The LDOs for 1.8V joysticks were omitted too, as my preferred ones accept 3.3V. This change to the RP2040 does come with drawbacks though:
Memory card flex
Done, at least the first version. This one is fairly simple, as it only contains the SD connectors and the circuitry to differentiate my SD memory card from a normal SD card. There was a little issue though, the SD card slots I used so far are obsolete now and I had to find an alternative (which hopefully still fits the SD memory card, as the thickness is on the upper range of the allowed tolerance).
As it is larger than 100mm in one direction, there is a steep price increase for this one on JLC. It’s why I decided to order it later, maybe together with the heatsink. Not having it for testing will for sure prevent me from testing actual games on the new mainboard, but I’m happy already if I can make it boot at all.
Mainboard
The mainboard was finished and ordered too. This one was challenging, as some heavy cost saving measures were needed to satisfy all my requirements. While the circuits themselves were fairly straight forward, as I have working versions of all subcircuits, the main challenges involved these points:
Stackup
The stackup I chose for the previous mainboard revision fits this application perfectly. It had a larger spacing between layers 2 and 3 and a smaller spacing between layers T-1-2 and 3-4-B. That meant I could also route signals on the two internal power planes, without being too worried about crossing power plane splits, or noise coupling. With JLCs default stackup it’s the other way around with layers 2 and 3 having a tiny spacing. While they also offer a more suitable stackup at a moderate surcharge, it’s only economically viable below 100x100mm. Go even 1mm above that and the price explodes! With the other stackups they offer, I could either not hit my target impedances at reasonable trace widths, or simply not afford them.
So, the compromise is the default 1.2mm 6-layer stackup with a couple of hacks. It ended up as a 1.2mm stackup, because the spacing between 1-2 and 3-4 is smaller than with 1.6mm, which is a benefit in my case. For all the traces I absolutely had to route on one of the power layers, I made sure to fill the adjacent space with GND.
Battery and thermistor connection
The battery connection was also very challenging. The first idea was to have a mezzanine on either side of the mainboard, to connect a flex PCB which is soldered to the battery contacts. That way I would be really easy to disconnect the left and right gamepad assemblies from the mainboard – with just 2 mezzanines. It also meant I had to route the battery voltage on the power layers to the battery management, so across the whole mainboard. The main challenge here is again JLCs stackup – unlike the last mainboard revision, this one would only have 0.5oz copper on all inner layers. With the space I had for routing the battery connections there was simply no way I could reach my power loss targets for the battery connections. The worst would have been 0.8W loss at maximum load and almost empty batteries…. just for the connection from battery to battery management. As the default stackup option with 1oz internal copper is even less suitable for my mainboard, I was considering the alternative of switching to an 8-layer board (with 2 layers reserved for battery routing). 8 layers would not be much more expensive for smaller PCBs, but again, going over 100x100mm results in a bad day for your wallet. On top of that, the flex PCBs I wanted to use for the battery compartment would have been quite expensive too, because the default 1/3oz copper would have caused too big of a power loss.
In the end I decided to ditch the whole idea and to use wires for connecting the batteries. For that I selected Molex Pico-EZmate HC connectors and 22AWG wire. The wires will be directly soldered to the battery contacts and routed through the gamepad assembly & below the screen to the battery management. There are some advantages to that:
Cost and time saving
There are almost 500 components on the mainboard and the BOM sums up to quite a lot, so you can imagine I had to optimize component choices as much as possible. But also, time saving is something to consider – those components need to be placed manually, so I tried as much as possible to place them on the most convenient layer for less work during reflow. Especially on the bottom I wanted to reduce the number of heavy components that I have to manually fixate while doing the top side reflow.
There are still quite some components on the mainboard that may be omitted (mostly passives), but it’s a problem for the next revision, as some of them are currently needed for debugging.
The boot rom module was rationalized away for the same reasons - I can save 4 mezzanine connectors, a flex PCB and a bunch of time by directly soldering the flash to the mainboard.
These 3 challenges are of course not the only ones, but the ones that caused the biggest headaches, and the solutions actually had quite an impact on costs.
Assembly planning
I took some time off in mid-October to assemble the next revision. While the feasibility work I did so far has dramatically increased the chances of this thing actually being functional, there is still so much that could go wrong that I fully expect lots of issues and troubleshooting.
This time I will do the reflow process differently, fully leveraging the power of my reflow oven. The battle plan is to first bake the donor mainboard for a couple of hours to get rid of any moisture in the chips. My plan for removing them this time involves the reflow oven. I will try to create a prolonged lead-free reflow profile and will use the suction pen to remove the chips as fast as possible, while the board is still in the oven. Not sure yet whether I could actually take them off before the board cools down too much, but it should stress the chips a lot less than blasting them with 360°C hot air.
The reballing process will most likely be the same, as it worked very well last time.
For reflowing I’m planning to use the oven again, with a lead-free profile (I’m using leaded paste & balls, but the T20 and SDRAM have lead-free balls). First the bottom side, excluding the boot rom and PLL chip. Then I will fix the heaviest components with copper tape and flip the board around. Not sure yet what to use as support for the top side, as the board cannot sit flat on the tray (but I should probably support a few points to prevent warping). Then as a last step I will solder the boot rom and PLL manually.
Before doing this on a 90k mainboard I will probably give it a try with a spare 75k I have here (especially the removing and reflowing part). I did the same last time, where I removed all chips, reballed them, and resoldered them to check whether the PS2 would still work.
Until my vacation I will try to update the SysCon firmware to the new pinouts and to implement the new gamepad solution in code. The video processor code will also need to be updated to match the new pinouts.
That’s it, I will write the next update once I managed to assemble all PCBs in October!
I did not post anything lately, but that doesn’t mean there was no progress. There was a little summer break indeed, but apart from that the design has progressed considerably. Here are the topics I have updates for:
JLC housing vs. FDM
The SLS housing from JLC arrived after 4 long weeks of waiting and I must say that I was pretty disappointed. The accuracy is great, but I’m not happy with the dimensional stability of the PA12 parts. The material is simply too soft for this thin & flat design and on top of that, both top and bottom housings arrived slightly warped. The warping was acceptable in the beginning, but it got worse a couple of weeks after I received the parts (I suspect due to the hydroscopic nature of PA12). Surface finish would be acceptable, although I’m not a big fan of the rough texture. What bothers me about the surface, though, is that you can see all the polygons of the STL file, due to all the curves. This could have been avoided by uploading the files as STEP, but there the online calculator always failed to process the parts correctly.
To have a comparison I printed the housing on my X1C using PLA and to be honest, I much prefer the FDM printed housing over SLS. The overhangs might need some polishing, and the surface finish is not as uniform, but for some reason the FDM part feels more “premium” (probably just my bias towards FDM… ).
Due to the material being PLA, the housing is also much stiffer than the SLS parts.
To sum it up – I will proceed with FDM for the final housing. Not just the above aspects are worth considering, but also the benefit of having full control over the printing process – I can do different colors, materials, or even combinations of the two (PLA housing with TPU grips??), and all that with as many quick iterations as I want.
Speaker housing
In a previous update I was describing already how I failed to come up with a switch oled speaker housing that is both slim and sounds good. After way too many iterations, I finally have an acceptable design. Now it’s designed after the original part from Nintendo, with heavy modifications to make it fit my housing. The idea is that this will slot into the battery compartment and form a part of the left and right gamepad assembly. The speaker housing itself now consists of a top and bottom part, which will most likely be glued together to get an airtight seal. The chamber behind the speaker will for sure need some tweaking when I assemble the first prototype, but I left plenty of space for that.
Gamepad emulator with PIO
With the help of @stuckpixel I managed to rewrite a large chunk of the DS2 emulator code, to ditch the ARM PrimeCell SSP peripheral for a proper PIO implementation. The problem with the SPI peripheral of the RP2040 was that the DS2 communication protocol is quite unusual, and on top of that the PS2 likes to stop/start communication randomly (often during transfers). A big chunk of the interface code was actually recovering the PrimeCell from situations like that, using the brute force way of resetting the whole peripheral after every transfer to get it back into a known state. While this worked, it had lots of overhead and sometimes broke timings. I actually found 3 games during testing that were not compatible with the old implementation (the Spyro games and Shadow of the Colossus).
Now with PIO the code is much more elegant and especially the ACK is much faster and more predictable. While debugging I also found a bug regarding the device type, where the emulator wouldn’t switch between analog and dualshock mode correctly. After some more testing I found that the 3 incompatible games also work properly now.
Gamepad flex
The left and right gamepad flex PCBs were designed and ordered. Here I decided for a big change – in order to optimize the BOM and for saving costs, I replaced the I2C IO expanders and I2C ADCs with one RP2040 per side. While it’s way overkill, that way I can reuse all the BOM items of the syscon. I can also save the I2C LED driver for the power LED this way, and many more functions can be integrated in the future. The LDOs for 1.8V joysticks were omitted too, as my preferred ones accept 3.3V. This change to the RP2040 does come with drawbacks though:
- An additional firmware is needed (simple I2C slave with a couple of registers to read and write from)
- Switching from 3.3V to 1.8V joysticks is more inaccurate, as the RP2040 ADC reference cannot be changed (as far as I know). But it's still plenty for the joystick
Memory card flex
Done, at least the first version. This one is fairly simple, as it only contains the SD connectors and the circuitry to differentiate my SD memory card from a normal SD card. There was a little issue though, the SD card slots I used so far are obsolete now and I had to find an alternative (which hopefully still fits the SD memory card, as the thickness is on the upper range of the allowed tolerance).
As it is larger than 100mm in one direction, there is a steep price increase for this one on JLC. It’s why I decided to order it later, maybe together with the heatsink. Not having it for testing will for sure prevent me from testing actual games on the new mainboard, but I’m happy already if I can make it boot at all.
Mainboard
The mainboard was finished and ordered too. This one was challenging, as some heavy cost saving measures were needed to satisfy all my requirements. While the circuits themselves were fairly straight forward, as I have working versions of all subcircuits, the main challenges involved these points:
Stackup
The stackup I chose for the previous mainboard revision fits this application perfectly. It had a larger spacing between layers 2 and 3 and a smaller spacing between layers T-1-2 and 3-4-B. That meant I could also route signals on the two internal power planes, without being too worried about crossing power plane splits, or noise coupling. With JLCs default stackup it’s the other way around with layers 2 and 3 having a tiny spacing. While they also offer a more suitable stackup at a moderate surcharge, it’s only economically viable below 100x100mm. Go even 1mm above that and the price explodes! With the other stackups they offer, I could either not hit my target impedances at reasonable trace widths, or simply not afford them.
So, the compromise is the default 1.2mm 6-layer stackup with a couple of hacks. It ended up as a 1.2mm stackup, because the spacing between 1-2 and 3-4 is smaller than with 1.6mm, which is a benefit in my case. For all the traces I absolutely had to route on one of the power layers, I made sure to fill the adjacent space with GND.
Battery and thermistor connection
The battery connection was also very challenging. The first idea was to have a mezzanine on either side of the mainboard, to connect a flex PCB which is soldered to the battery contacts. That way I would be really easy to disconnect the left and right gamepad assemblies from the mainboard – with just 2 mezzanines. It also meant I had to route the battery voltage on the power layers to the battery management, so across the whole mainboard. The main challenge here is again JLCs stackup – unlike the last mainboard revision, this one would only have 0.5oz copper on all inner layers. With the space I had for routing the battery connections there was simply no way I could reach my power loss targets for the battery connections. The worst would have been 0.8W loss at maximum load and almost empty batteries…. just for the connection from battery to battery management. As the default stackup option with 1oz internal copper is even less suitable for my mainboard, I was considering the alternative of switching to an 8-layer board (with 2 layers reserved for battery routing). 8 layers would not be much more expensive for smaller PCBs, but again, going over 100x100mm results in a bad day for your wallet. On top of that, the flex PCBs I wanted to use for the battery compartment would have been quite expensive too, because the default 1/3oz copper would have caused too big of a power loss.
In the end I decided to ditch the whole idea and to use wires for connecting the batteries. For that I selected Molex Pico-EZmate HC connectors and 22AWG wire. The wires will be directly soldered to the battery contacts and routed through the gamepad assembly & below the screen to the battery management. There are some advantages to that:
- Less losses in wiring
- Much cheaper, as I can avoid all the stackup or copper surcharges + omit two whole flex PCBs for the batteries
- Safer, as the risk of a short is much higher when routing those connections on the mainboard (thinking about the 100s of GND vias piercing the battery voltage planes at 0.125mm clearance…)
Cost and time saving
There are almost 500 components on the mainboard and the BOM sums up to quite a lot, so you can imagine I had to optimize component choices as much as possible. But also, time saving is something to consider – those components need to be placed manually, so I tried as much as possible to place them on the most convenient layer for less work during reflow. Especially on the bottom I wanted to reduce the number of heavy components that I have to manually fixate while doing the top side reflow.
There are still quite some components on the mainboard that may be omitted (mostly passives), but it’s a problem for the next revision, as some of them are currently needed for debugging.
The boot rom module was rationalized away for the same reasons - I can save 4 mezzanine connectors, a flex PCB and a bunch of time by directly soldering the flash to the mainboard.
These 3 challenges are of course not the only ones, but the ones that caused the biggest headaches, and the solutions actually had quite an impact on costs.
Assembly planning
I took some time off in mid-October to assemble the next revision. While the feasibility work I did so far has dramatically increased the chances of this thing actually being functional, there is still so much that could go wrong that I fully expect lots of issues and troubleshooting.
This time I will do the reflow process differently, fully leveraging the power of my reflow oven. The battle plan is to first bake the donor mainboard for a couple of hours to get rid of any moisture in the chips. My plan for removing them this time involves the reflow oven. I will try to create a prolonged lead-free reflow profile and will use the suction pen to remove the chips as fast as possible, while the board is still in the oven. Not sure yet whether I could actually take them off before the board cools down too much, but it should stress the chips a lot less than blasting them with 360°C hot air.
The reballing process will most likely be the same, as it worked very well last time.
For reflowing I’m planning to use the oven again, with a lead-free profile (I’m using leaded paste & balls, but the T20 and SDRAM have lead-free balls). First the bottom side, excluding the boot rom and PLL chip. Then I will fix the heaviest components with copper tape and flip the board around. Not sure yet what to use as support for the top side, as the board cannot sit flat on the tray (but I should probably support a few points to prevent warping). Then as a last step I will solder the boot rom and PLL manually.
Before doing this on a 90k mainboard I will probably give it a try with a spare 75k I have here (especially the removing and reflowing part). I did the same last time, where I removed all chips, reballed them, and resoldered them to check whether the PS2 would still work.
Until my vacation I will try to update the SysCon firmware to the new pinouts and to implement the new gamepad solution in code. The video processor code will also need to be updated to match the new pinouts.
That’s it, I will write the next update once I managed to assemble all PCBs in October!
)
