What's new

Worklog Some PS2 Project

Joined
Dec 25, 2022
Messages
43
Likes
412
Location
Landeck, Austria
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.

housings_2.JPG


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.

speaker_1.png
speaker_2.png


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
gamepad_left.png
gamepad_right.png


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.

memcard_flex.png


Mainboard

mainboard_1.png

mainboard_2.png


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…)
While this solution is less elegant and also involves crimping the battery wires manually (Molex don’t sell ready-made cable assemblies for that specific model), it’s better in every way than the old idea. This one was difficult though, it involved evenings of calculating conductor power losses (planes and wires), trace impedance and systematically browsing through JLCs quoting system to find economically viable options.

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!
 
Joined
Mar 17, 2016
Messages
84
Likes
52
Absolutely incredible work, cannot wait to see the finished product! Glad I was able to help with the controller code. I probably wouldn't be able to finish such an ambitious project, personally, but I'm happy I could contribute, even it was in such a small way. I hope everything goes as smoothly as it can for you
 

cfc_12

.
Joined
Apr 28, 2017
Messages
180
Likes
71
Location
Philippines
Portables
11
your case design looks amazing!

It's looks like from an official handheld product
 
Joined
Apr 12, 2017
Messages
221
Likes
147
Location
Canada
Hey! Welcome back!

So I guess the idea of using a left brain/right brain on the controller isn't that weird after all! Yea sure, you could call it overkill, but I prefer to think of it as thoroughness. Kind of brings to mind the left brain, right brain piloting system from Pacific Rim. It should certainly cut down on signal interference and latency issues relating to the joycon sticks. The shorter the traces the better.

Also, good call on using conventional wires for power transmission. I too have felt the pull of the PCB design lol. The desire to do everything in nice, clean cut designer PCBs, and make it look like something Tony Stark dreamed up... But you made the right decision, wires all the way for batteries! You may look at adding solder to the crimped connections though. Maybe I'm just paranoid, but tightness just isn't the same as intermetallic phase bonding.

I don't suppose your case design could be feasibly printed on an STL printer, could it? It's a pretty large object for such a limited printing area, but it should make the case very rigid, and I've heard of people splitting their models into pieces to be printed separately, and then photo-resin was used to bond them during UV curing. Just a thought.

Looking amazing as always, hope you enjoyed the summer break! Lord knows it was a gorgeous season this year.
 
Joined
Dec 25, 2022
Messages
43
Likes
412
Location
Landeck, Austria
Hey! Welcome back!

So I guess the idea of using a left brain/right brain on the controller isn't that weird after all! Yea sure, you could call it overkill, but I prefer to think of it as thoroughness. Kind of brings to mind the left brain, right brain piloting system from Pacific Rim. It should certainly cut down on signal interference and latency issues relating to the joycon sticks. The shorter the traces the better.

Also, good call on using conventional wires for power transmission. I too have felt the pull of the PCB design lol. The desire to do everything in nice, clean cut designer PCBs, and make it look like something Tony Stark dreamed up... But you made the right decision, wires all the way for batteries! You may look at adding solder to the crimped connections though. Maybe I'm just paranoid, but tightness just isn't the same as intermetallic phase bonding.

I don't suppose your case design could be feasibly printed on an STL printer, could it? It's a pretty large object for such a limited printing area, but it should make the case very rigid, and I've heard of people splitting their models into pieces to be printed separately, and then photo-resin was used to bond them during UV curing. Just a thought.

Looking amazing as always, hope you enjoyed the summer break! Lord knows it was a gorgeous season this year.
Thanks!
Yeah I still think hooking the left and right gamepad up via I2C is a pretty cool idea. In the beginning the main reason for doing it was the lack of IO on the RP2040, but it also simplified wiring a lot. And the interference reduction on the analog sticks is a good point too! With the IO expander and standalone I2C ADC the functionality was a bit limiting though (and especially the ADC is quite expensive), that's why now all that got replaced by 2 RP2040s. Also makes it easier to PWM the RGB power LED and maybe in the future even add rumble motors or other functions!

The battery connection still bothers me a little bit, but in the end it was the better decision indeed. Just looking at the connectors themselves, I'm still amazed by the fact that such flimsy little mezzanine connectors can be rated for 6A+ (on paper at least...). The Pico-EZmate HC connectors look much more adequate for handling the ~3A max. that I need, but yeah crimping them is a little awkward. As I refuse to pay the 500 bucks for their specialized crimping tool, it will probably be a pliers and solder job, as you said :D
A little drawback of the current design is that the termistors are on the gamepad PCBs, which means the system won't work/charge without the gamepads connected (anyway the power button is on the left gamepad PCB).

I designed the housing with my X1C in mind, so the widest part is a bit below 23cm (doesn't even need to be printed diagonally). But yes, SLA printing could be a bit tight depending on the printer. How big do they go nowadays? I only ever worked on a mars 1 back then and that thing had a tiny build volume.


While I'm typing already, I can give a little bit of a spoiler for the next update...
Revision 2 officially boots and the FPGA portion works too! The Syscon is not alive yet, the code I implemented while on vacation has tons of bugs...
IMG_20241014_195741651_HDR.jpg
 
Joined
Dec 25, 2022
Messages
43
Likes
412
Location
Landeck, Austria
This week I was wasting way too much time playing GTA on the new prototype, so I’m writing an update now to at least do something productive!

The spoiler in the last reply already gave it away – my new mainboard revision seems to be fully working so far!
Maybe I’ll start with the assembly process first...

Mainboard assembly

This time I decided to distribute the CBA assembly over 3 evenings for an overall less stressful experience. On day 1 I did the baking and reballing, on day 2 the bottom layer and on day 3 the top layer.

My battle plan heavily involved the reflow oven this time, which worked out very well, except for removing the chips from the donor board. I tried the removal process on a spare 75k first and unfortunately the memory card sockets & ethernet cover started melting before I could get the chips off. So, no success, apart from a lot of smoke…

Anyway, I then baked the 90k donor board at 110°C for about 5h to remove any moisture from the board and chips (to prevent popcorning on the PCB and most importantly on the EE and GS substrates).

As removing the chips with the reflow oven was a failure, I had to go back to the previous procedure using the IR preheater and hot air, which actually worked quite nicely this time. With the Fluke 52II I was able to precisely measure the temperature on the bottom and top layers to avoid overheating the chips. By using it I also figured out that the preheater can heat the bottom layer to about 220°C & top layer to ~130°C using the highest setting (~400°C). Back then I was scared of using it due to the high set temperature, but now I can confirm that the actual temperature is far below it. By doing this I had a much easier time removing the chips, as there was a lot less heat needed from the top & I could monitor the top layer surface temperature with the thermocouple.

Reballing was the same as previously, just with my custom designed stencils this time. They’re much easier to work with than the generic aliexpress stencils I used before & I can skip masking all the unused holes. The tolerance is tighter with 0.55mm balls, which makes the alignment more precise (less manual rework needed). This time I took much more care when cleaning the chips after reballing, removing every speck of dust from the underside to avoid issues during reflow. For cleaning I used 99.9% IPA to add as little moisture as possible, and baked the chips for another hour at 110°C. Afterwards they were sealed in an ESD bag for assembly.

Another thing I did on day 1 was assembling the left and right gamepad flex PCBs. Nothing exciting to report, just manually soldering a couple components.

On day 2 it was pick&place time for the bottom layer. I got myself a fancy pasting fixture, which saves time during the solder paste application & I could potentially run multiple boards without realignment. It’s also a nice PCB holder for placing all parts. Pasting was done with leaded paste again, as I still have some stock. With all parts placed it was time for the reflow oven. I created another custom leaded profile for the bottom layer, which worked out very well - there was only one 0201 cap tombstone and 3 shorted pins on the TXS0102 (really annoying package!).
IMG_20241012_172314299.jpg
IMG_20241012_193124168.jpg

The boot rom flash and PLL chip were intentionally left unpopulated to save them from an additional reflow cycle and to prevent them falling off during the top layer reflow. In hindsight I should have removed their pads from the paste layer, would have saved me some time wiping the solder paste off. Same with the battery connectors.

After the bottom layer was done, I applied copper tape to the heavier & plastic components to prevent them from moving/melting during the top layer reflow.
IMG_20241013_173327938.jpg


Day 3 was top layer day. Same process as the bottom layer, I just have to note that the new fixation made pasting MUCH easier! Pasting the top layer was absolutely miserable last time, because the PCB would not sit flat on anything!
Once all non-BGA components were placed, I applied a thin layer of STIRRI-ASM-TF on all BGA pins and placed all BGAs (also used the same flux for reballing. I can report that it worked, but I would’ve preferred it to be a bit more tacky).
IMG_20241013_201457047_HDR.jpg

With everything placed, I put the mainboard back into the reflow oven and ran a lead-free profile (The T20 and SDRAM are lead-free). For the top side, I shoved the oven's thermocouple into the mounting hole next to the EE, to more accurately capture the PCB's temperature (this time the board was sitting on M6 nuts, so no direct contact to the tray = less heat transfer). Afterwards I programmed the boot rom & soldered the remaining 2 chips to the bottom layer.

Then it was time for an optical inspection and measurement of all supply rail resistances. During the inspection I noticed and fixed a couple of defects:
  • The syscon was perfectly soldered with no shorts… but offset by 1 pin; possibly due to sloppy placement
  • Solder wetting on the DSP pins was absolutely terrible. I had to retouch almost every pin. This could either be due to oxidation or leftover lead-free solder on the pins. Either way, I will try to improve it next time.
  • The solder joints on the new headphone jack needed fixing due to a combination of bad solder wetting and too little paste for good mechanical stability
  • I soldered the wrong USB A socket – seems like there are 2 slightly different variants on the 79k and 90k models. They have the same footprint, but slightly different height distribution between top and bottom layer. The one I used would not have fit into the housing, so next time I have to take good care to use the right one!
  • Various shorts on the QFN parts, which were easy to fix with a knife tip
After verifying that all PS2 supply resistances were good, I continued by closing all the supply rail jumpers (there is a jumper on every power rail to measure the resistances before powering it on). As the firmware was not finished, I had to run a couple of wires to the soft power switch and battery voltage to power the unit. Aaaand when turning it on nothing happened… stupid me forgot to rename one of the nets in the soft power switch when copying the circuit from the last revision! It bothers me a lot, but I had to run a wire to connect that net… you can see it i the picture below

Afterwards it turned on and the current consumption was looking good, but before pressing the PS2 power button I flashed the new bitstream with modified pinout onto the T20. Then it was finally time to press the button…. And it was booting right away!!

It’s important to not that, in contrast to the previous revision, this mainboard was assembled from 100% SCPH-90004 chips. PS2BBL also lists it as a 90k board. This finally confirms that 90k chips work on a 79k layout (which mine is based on), because I was a little worried about the mechacon.

Well that’s the story from PCB assembly to first poweron.
IMG_20241028_192345415_HDR.jpg
IMG_20241028_192415048.jpg


New firmware features

Next was obviously getting the firmware working to test everything else. The state machine of the syscon was almost completely rewritten, with the following features added:
  • Temperature based PWM fan control, currently with a linear fan curve
  • Loading the T20 bitstream via SPI – the T20 video processor code is now packaged with the syscon firmware and can be upgraded via USB
  • RGB LED patterns for SOC and various other modes (any color, blinking speeds and durations)
  • Storing/loading settings and analog stick calibration in flash
  • Completely rewritten gamepad user-functions to work with the new gamepad PCBs
  • Implemented a crude config mode by quick-pressing the power button – can currently change the volume and perform the analog stick calibration
  • New state machine with lots of critical monitoring functions now run by interrupts
  • Fancy circular -> square output transformation for the analog sticks
On top of that I had to create the firmware for the gamepad PCBs, which is actually fairly simple. Both sides share the same firmware, at startup it reads a “side select” pin and configures itself accordingly (left or right). Then it’s just a simple I2C slave with a couple of registers…

That was the theory, next was debugging... it was very time consuming and I won’t state the millions of bugs I encountered… :D

The most interesting one was probably the breakpoint bug…

When doing the debugging I noticed that the syscon would always skip the breakpoint at main when at least one of the gamepads was attached. It’s very annoying and really defeats the purpose of debugging when the firmware starts executing on its own. As I updated the pico SDK to the VSCode extension I thought that maybe some setting caused this behavior, but after troubleshooting in that direction I gave up within a day.
Next thing to do was to get out the scope and trace a couple of signals. When observing the standby 3.3V rail I noticed that it dropped for ~2ms every time the firmware was flashed to the RP2040. This could only happen when the soft power switch turns off, so that was the next thing I probed – it did turn off for 2ms, but only with at least one gamepad attached!
After messing around with the connections to the gamepads for a little while I decided to probe VSYS – the output of the BQ25792. There I saw it – every time I started debugging there was some overshoot, followed by a huge drop to about 4V, without the gamepads it only dropped to 6V! Looks like this caused the soft power switch to turn off momentarily and reset the RP2040, causing the debugger to lose connection and preventing it from hitting the first breakpoint!

Next question was why? This looked suspiciously like an overvoltage fault in the BQ25792, which usually happenes when trying to charge without batteries connected. Observing the charge EN pin solved the mystery – it was at ~1V while the RP2040 was initializing, even though the signal has a 100k pullup! Then it dawned on me… I had a similar issue in the past with the headphone detect pin… the RP2040 has pulldowns on all pins enabled by default, even when in reset. Annoyed by this “unique” design choice I replaced the 100k pullup on charge EN with a 2.2k one – works! This is the only microcontroller I know which has this “feature” and so far, it only caused issues… But not a third time, I swear!

After some more debugging everything seemed to work and I decided to put together a little prototype from the current status of the mechanical design. The pictures nicely display the concept of having an inner “skeleton” along with and outer housing. The skeleton is fully functional on its own and makes debugging a little easier, especially because all test points are below the screen. It also shows how slim the internals really are & how little wiring is needed to connect everything.

There it is!

IMG_20241028_192509277.jpg
IMG_20241028_193744404_HDR.jpg

IMG_20241028_194340236.jpg
IMG_20241028_194748469_HDR.jpg

IMG_20241028_194815572.jpg
IMG_20241028_195214918_HDR.jpg



Luckily PS2BBL can load its config & OPL from USB, which even enabled me to test some games!


Current consumption of the whole system is sitting at about 7W in GTA (display at 100% brightness, fan at 100%, audio at decent volume, a USB stick and rather full batteries). This does not include the SD card and memory card, but I assume their current consumption would be equivalent to the USB stick. Display & FPGA still consume about 1.2W and the PS2+audio ~5.5W, which leaves ~0.3W to the USB stick. The mainboard stays quite cool, even with the 3D printed heatspreader, but the little heatsink I hacked into it is ridiculously small, so I tweaked the fan curve a bit more aggressively.

I was playing quite a bit and in parallel writing down everything I like and don’t like about the design. Here are the most important points:
  • I have to say the shape, weight and balance is perfect!
  • The shoulder buttons and triggers feel amazing
  • The DPAD in its current state sucks. To improve it I added a little spacer for it to protrude a little bit more & I also swapped the 100gf buttons to 160gf for better tactile feedback.
  • The other face buttons don’t feel quite right either and need tweaking. The gamepad flex PCBs currently only have a PEI stiffener, because I was too cheap to pay the surcharges for an FR4 stiffener. It makes the face buttons feel a little bit cheap; they make different sounds when pressing (hard to describe).
  • The analog sticks did suck, before I implemented the square mapping. Now they are good!
  • The gamepad flex PCBs arrived warped due to the copper imbalance between top and bottom, PEI is just not stiff enough to prevent it.
  • Spacing on some tact switches & button cutouts is a little bit off too, I suspect the button 3D models are not 100% accurate yet.
  • Some idiot mixed up the start & select buttons in firmware and hardware… I should have checked the labels on the buttons before implementing things…
  • There is too much empty space inside the housing, which causes resonances with the speakers. I should make sure to fill as much as possible with the skeleton and also print everything with 100% infill.
  • The other mechanical parts fit to 80% I would say, pretty OK for a first test fit. Everything just still needs a little bit of tweaking and rework, but I’m very happy with the first outcomes!
Especially some of the firmware issues I discovered while using it have a fix already. To improve usability, I’ve implemented the config mode and analog stick processing.
In general, the config mode is very simple right now, but I’m thinking about ways to make it ready to communicate with the FPGA in the future. The idea is to have a little & simple on-screen menu to navigate.
The problem with analog sticks is that the PS2 expects a square output and the hall effect sticks have a circular output. It’s mostly noticeable in diagonals, where movement of e.g. players is in some situations much slower. I already added a function for mapping the circular output to a square and it works quite well, but requires a lot of calculations. It also features a “roundness” parameter, which affects the square mapping of smaller stick values -> the smaller the value, the rounder the output will be. The size of this factor determines how aggressive the inner roundness is.

Then we come to the major TODOs for now:
  • Fix all the little issues in CAD (working on it)
  • Redesign the gamepad flex and surrounding parts for the buttons to protrude more (working on it)
  • Finalize the heatspreader and memory card flex for ordering (to finally save games) (working on it)
  • Decrease the air volume within the housing
  • Print the modified parts again to check
  • Research options for the screen lens
  • Create a new revision of the mainboard
  • Fix firmware bugs & refactoring
  • Implement a simple SPI slave in the FPGA for configuring video parameters
  • Implement scaling in the FPGA
The mainboard will get another (final) revision too, to iron out a couple of small things & to remove the bodge - this will happen at a later point, as the new prototype is more than enough for all upcoming tasks.

At some point I will also revisit the FPGA, but I need to get the Efinity software running again to do so. On my new PC it consistently crashes when opening the interface designer and I could not find a fix yet.
 

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,325
Likes
2,836
Portables
6
This project is so unbelievably next level. Always a joy seeing updates. Very exciting seeing it all come together.
 

Kirbo

.
Joined
Jan 11, 2023
Messages
33
Likes
8
Location
Dreamland
Portables
None..... Yet
Wow, I've been following this project since I joined Bitbuilt and its crazy to see it finally being finished.
 

Luigid

.
Joined
Sep 24, 2017
Messages
12
Likes
10
To say that a great job has been done is an understatement... congratulations indeed!
 
Joined
Dec 25, 2022
Messages
43
Likes
412
Location
Landeck, Austria
Time for a quick update!

The first revision of the prototype is looking pretty good now! I think this is the first time where all major hardware functions are present and working flawlessly!

I’m playing way too much on it though, and it’s way too much fun! But in the end, playing games on it is actually pretty important to find & fix bugs (at least thats's what I keep telling myself). Debugging the firmware usually goes like this: I find a bug, fix it and then continue playing a game for another hour with the debugger still attached - It’s not very productive and I should probably never develop a gaming system ever again to avoid this :D

Anyway, let's start with the main topics:

Memory Card Flex
The memory card flex arrived some time ago, which means I’m finally able to use the MX4SIO and save games!

Assembly was quick and easy, but after some first tests I discovered an issue. When my SD memory card was inserted before booting the PS2, everything worked normally, but hotplugging it caused the portable to turn off 9 of 10 times. Sounded like an inrush current issue and measuring the PS2’s 3V3 rail on the scope confirmed it. This bug also confirmed that the power monitoring of the syscon works as intended – if one of the DCDC PG or the red power LED of the PS2 toggle, the syscon shuts down the system immediately via an interrupt to prevent damage to the PS2.

Turns out the couple uF of decoupling on the ports is not enough to handle the inrush current of a memory card. For now, I hacked in more bulk decoupling at the ports, but for the next revision I will include bigger capacitors.

Now it works great! The cool thing is that it still works with 2 memory cards, so copying save files is easy (pressing R1 in PS2BBL launches ULE and copying things is just a matter of seconds). In the future I might design an adapter to connect full size memory cards to make this even easier (kind of the opposite of MX4SIO – full size memory card to SD :rothink:)

IMG_20241208_210521567.jpg


Heatsink
The milled heatsink from JLC came in yesterday and while the quality is not perfect, it’s certainly more than acceptable for the 70 bucks I paid – any supplier in Europe would probably laugh at me for such a part at that price! It did come a bit warped (which was easy to fix) and the endmills they used were obviously not the sharpest ones, but it’s plenty good for a heat sink. Next time I will probably specify bead blasting , to get rid of some rough spots.

The design uses all M1.6 screws, which requires tapping a couple of threads in the heatsink. JLC could do it, but to save a couple of cents with the first prototype I decided to do it myself. At this point you have to know that tapping threads manually is on my top 10 list of things I hate most in life, so I don’t know what I was thinking there…
Anyway, all threads are present now and apart from one hole being blocked by a broken M1.6 tap it went OK (if we exclude all the cursing). In the end, tapping moved up by one spot on my list and I will certainly not do it again, even if it would double the price of the heatsink :facepalm:

Now to the good part: It fits the mainboard perfectly and there is enough clearance everywhere that I’m comfortable with not applying any insulation on the side facing the electronics. I continued the assembly process by applying these thermal pads on the EE, GS, BQ25792 and the power mosfets at the battery. That model of thermal pad is quite nice, because it can deform and adjust to any surface or gap it is placed on. Everything but the GS is cooled directly by the heatsink, the thermal pad of the GS attaches to the metal plate on the underside of the switch lite fan and is cooled by that.

I didn’t have the time yet to do any temperature tests, but maybe for the next update I have some data. What I can say for sure already is that the BQ25792 runs noticeably cooler when charging, man that thing can get burning hot otherwise!
So here is the mainboard with the new heatsink:

IMG_20241207_180111697.jpg
IMG_20241207_181056602.jpg


Housing modifications, buttons
I also used the last couple of weeks to redesign the battery compartments and gamepad portions to make printing/assembly easier and to reduce air volume inside the device. The backside of the speaker assembly has now been merged with the battery compartment again, reducing the number of printed parts by 2. The speaker assemblies can now even be made air tight without glue, requiring only a small sealing (in the future maybe printed with TPU), it’s much easier to handle than the old approach. All those changes even made the speakers sound better!

The buttons were improved too. For that I had to re-measure and modify the freely available PSVITA 2000 button models. I fixed the height and spacing of the models according to the physical buttons I have here and now they are much closer to reality. Now I can even say for sure that the spacings of the square and circle button & the start and select button are off by 0.5mm on my first gamepad flex (explains why the square button feels a bit off).
The gamepad flex PCBs were moved outwards by 0.5mm to make the buttons protrude more and make them feel a bit “stiffer” (especially the d-pad). Now the buttons all feel great, apart from the power button, which protrudes too much (by exactly the 0.5mm I moved all buttons outwards).
Seeing the original PSVITA button PCBs I have no idea how Sony managed to get the power button flush with the housing when all buttons are on the same plane! It’s certainly not the case for me and the power button protruding by that much is absolutely unacceptable. When doing the next revision of the gamepad PCBs I will probably make use of the fact that they’re flex PCBs and have the power button on a different plane, offset by 0.5mm.

The housing's outer surface was adjusted a little bit too, after playing on it for a while I decided to reduce the curvature of the back housing part a little bit around the triggers.

The biggest mechanical issue I have right now is finding a screen lens that suits my needs. The one I have now was a 2 minute job on a 1mm PC plate using a scalpel, which is not acceptable going forward. I tried looking for suppliers that can produce custom glass screen lenses in low quantities, but couldn’t really find any. An alternative I found would be a PSVITA 2000 glass screen protector, but it's just a bit too tall and looks weird on the portable. Another alternative would be cutting the 1mm PC to size on a laser/CNC and painting the bezels. This is still WIP!

Menu system and bugfixes
The overall functionality of the syscon is almost where I want it to be, but one big thing was still missing: the configuration menu.

In the last couple of weeks I spent my commuting time on developing a modular menu to configure and display various parameters of the system. The menu itself is running on the syscon and displayed by the video processor, with a full duplex SPI connecting both.

To start it off I got myself a nice little font, where each character is 8x8 pixels (to make storage easier, and can be easily integer scaled). The font is loaded into the FPGA at powerup and contains all ASCII characters + a couple of special ones to have fun with.
Then I defined the interface between the video processor & syscon and wrote the low level functions to configure the output, load the font, set the cursor, send and erase sprites and change sprite colors. Each sprite can have 2 different 24 bit colors, which can be adjusted via separate registers (e.g. for visually indicating selected menu items). Sprites are written to the screen at the current cursor position, which increments automatically in horizontal direction.

The menu system logic is quite flexible; each menu knows which entries belong to it, the current cursor position, which menu to go back to and what default function to execute (e.g. periodic refresh to update displayed info, or doing the joystick calibration).
The entries mostly also contain the logic needed to run the menu; they know their display content, their coordinates, which menu to launch, whether the cursor should skip them and most importantly their interactions. Each entry has 6 interaction buttons – cross, circle, up, down, left, right; any function can be mapped to any button for each entry, some of them are required to run the menu (e.g. cursor up/down, go back, enter menu), others can be freely mapped (audio up/down, storing settings, inverting joysticks). It makes the menu logic quite simple, because each entry already “knows” what to do.

After some debugging sessions the menu is already up & running, but for now it can only output via UART – displaying sprites is not yet implemented in the FPGA. You can imagine it's fun to navigate through the menu blindly to change the volume! But the menu being implemented & working in the syscon will make testing the FPGA code much easier!

Other functions were also added, improved or fixed – there was for example a nasty bug involving empty batteries; when the batteries run out and the MAX17320 is in undervoltage protection, it will disconnect the batteries from the system until a charger is plugged. The BQ25792 does not really like enabling charging without batteries being attached and triggers an overvoltage fault. The old firmware tried only once to enable charging, if that failed it would enter charging error state. The new firmware checks at startup whether no battery is present and enables charging for 2 seconds until the MAX17320 connects the batteries again. Only then it continues to charge the batteries. This bug was really problematic in the beginning, because the system was essentially bricked when the batteries ran out!

XEB+
A couple weeks ago I saw a video about neutrino launcher for XEB+ and I immediately wanted to try it! Neutrino is apparently an alternative to OPL, with slightly improved compatibility and XEB+ is just an immensely ambitious and impressive frontend for the PS2.


Seeing XEB+ boot on the portable is just incredibly cool, the interface is so sleek! With neutrino launcher it even plays MX4SIO games just fine, maybe even better than the latest OPL beta! I did find a couple of games that work great with neutrino, but crash with OPL. Shadow of the Colossus is a prominent example of a game that just doesn’t work with OPL, but runs flawlessly on neutrino. In general, the latest OPL beta seems to have some stuttering issues that were not present on the OPL I was using previously (OPL BDM 4.7.1)

My only 2 issues with XEB+ and neutrino launcher are:
  • XEB+ must be launched from USB
  • When adding games you must have access to both the SD card and the USB stick to update the game list
Those 2 are completely unacceptable for my use case right now, so I will wait and see how this evolves. I does look very promising though!

As an alternative I found a patched version of OPL that used neutrino to launch games (literally called "OPLNEUTRINO"), in my testing it had a higher compatibility than the default OPL release and was equal to XEB+ with neutrino launcher. I’m using this one from now on, let’s see how it goes!

Video Processor
There is not much to report rigt now, as the hardware and firmware were taking priority, but I managed to get the Efinity software running again. That means I can start working on the video processor again soon!



Now to finish off the update, something rather disturbing:
IMG_20241208_203725402.jpg
 

thedrew

.
.
Joined
Sep 27, 2016
Messages
454
Likes
1,029
The biggest mechanical issue I have right now is finding a screen lens that suits my needs. The one I have now was a 2 minute job on a 1mm PC plate using a scalpel, which is not acceptable going forward. I tried looking for suppliers that can produce custom glass screen lenses in low quantities, but couldn’t really find any. An alternative I found would be a PSVITA 2000 glass screen protector, but it's just a bit too tall and looks weird on the portable. Another alternative would be cutting the 1mm PC to size on a laser/CNC and painting the bezels. This is still WIP!
May I suggest a 3DS XL Glass lens? I am doing that for a project on a 5" 800x480 screen (same size as your screen) and the lens almost fits perfectly. The 3DS XL screen size is 4.88" as opposed to 5", so it is ever so slightly smaller but doesn't bother me. And they are cheap with pretty thin bezels!

https://www.aliexpress.us/item/3256806162241280.html
 
Joined
Dec 25, 2022
Messages
43
Likes
412
Location
Landeck, Austria
May I suggest a 3DS XL Glass lens? I am doing that for a project on a 5" 800x480 screen (same size as your screen) and the lens almost fits perfectly. The 3DS XL screen size is 4.88" as opposed to 5", so it is ever so slightly smaller but doesn't bother me. And they are cheap with pretty thin bezels!

https://www.aliexpress.us/item/3256806162241280.html
Hey thanks for the suggestion! I was looking for glass lenses of portables quite a lot, but the 3DS was completely off my radar!
The frustrating part about searching for such things is that the sellers rarely list the exact dimensions, it always comes down to guessing the size or ordering a sample... the PSVITA 2000 screen protectors for example are 121.5mmx80.5mm with a corner radius of 5mm, but I only found out after receiving them.
The 3DS XL one seems to be about 111mmx69mm(?), which could be a tight fit. Anyway I ordered 10 from the link you sent to give them a try, as they look very promising!

As another option I ordered a sample of a custom-cut tempered glass screen protector from a local company, but it's missing the black bezel I want. From experience the adhesive backing of those protectors (if present) can be peeled off to leave behind a perfect sheet of 0.33mm glass, so the first problem would be solved. Then I would need to come up with a way to color the bezel black - either by using foil, painting, black silicone adhesive or implementing a design workaround (i.e. a 3D printed bezel of some kind?). A lot of work for such a simple component!

It's the two most promising options right now, but I'm sure more things will pop up as I go. Getting such things made is really not easy without a business, maybe in the future I should start using my company email to get quotations, it always works quite well for getting datasheets :D
 

StonedEdge

a.k.a. ClonedEdge
.
.
Joined
Nov 16, 2018
Messages
385
Likes
1,553
Location
Japan, Tokyo
Portables
2
I would reach out to Retro Game Repair Shop for lenses! He had me one custom made for the Retro Lite CM4 and is probably what you want. Here's an image of how it turned out (very nice IMO)!

1733799195807.png


[email protected]
 
Top