Hello Handle Enthusiasts. I bring you great news from the HANDLE.
A lot has happened since the last post.
I want to go over features and where we are at on them first.
SCREEN:
Thanks to
@YveltalGriffin we know that Anbernic's sorta new RG40XX/H handheld for once has a landscape panel, and not only that, it isn't MIPI! (MIPI is the enemy of fun)
It is a fantastic 4" 640x480 laminated IPS panel, and holy crap does it look nice. It is the perfect size for so many possible portable designs, and it is what I wanted to use from the start.
2 Problems.
First, while it is RGB888, it has a custom pinout, so an adapter flex is required, easy enough.
Second, most (all?) LCDs need to be initialized over SPI, this isn't anything new, the 3.5" panel the kiddos use in their GBoys also need this.
The problem is that although the 3.5" 640x480 panels and the 4" use the same on panel controller chip, the init sequences are different!
Luckily some thankless Linux nerds already documented the init sequence
here.
@Aurelio and Yveltal solved this several months ago by making a bitstream to have RVL-DD send the new init sequence to the new panel, which is the simplest possible way to fix this.
Unfortunately things didn't quite line up for me to just use this new bitstream in the competition.
The good news? You can use a Pi Pico for anything. After a few days of reading C tutorials, stack exchange posts and forum threads I managed to figure out how to send the init sequence to the panel with an RP2040.
So with an adapter flex with a Xiao RP2040 on it, we are back in business!
DIRECT DRIVE:
So this is a big one, while there are other ways I could drive my screen, I REALLY wanted a direct drive solution.
However, there is no direct drive solution "for GameCube" We have RVL-DD which is designed for Wii portables,
and there is a way to use a Retro-GEM as an LCD driver
The latter of which is a pretty large solution for that kind of usage. I thought for sure I was screwed and had to use HDMI or VGA.
After asking Aurelio out of desperation, I found out that there wasn't a real reason RVL-DD *couldn't* be used with the GameCube.
I am sure I am over simplifying this too much, but the digital video bus of both consoles is the "same" the only difference is the GC has 3v3 video and Wii has 1v8.
The nice thing is the FPGA RVL-DD uses can handle either, you just have to supply the IO VDD pad (Labeled 1v8 on the DD PCB) 3v3 and it works with the GC 3v3 levels.
The real issue is that when used with a Wii the DD relies on the Wii to send the bitstream to it from NAND, a luxury I don't have with the GameCube.
But the SPI lines used to send the bitstream from a Wii are broken out to pads so I can just......Yeah you got me, I just send it via SPI with the same XIAO RP2040 I already mentioned and you already saw.
Wow amazing, a GameCube directly driving an LCD with RVL-DD:
ANALOG TRIGGERS:
There aren't enough ways in the universe to say how little I enjoyed designing these.
I would have gone through so much less suffering if I had just decided to use dual action tactile switches, but nooooooo had to have analog.
Hall effect would have also been way simpler, but for some reason I wanted needless levels of authenticity and used OEM GC trigger sliders.
Why were they difficult to design?
Well first reason is uh, some dummy decided to use 21700s and barely made the housing big enough for them, wonder who.
Linear triggers suck in general though, they are surprisingly quite a bit more mechanically complex than pivoting triggers.
Additionally due to so many constraints I only brought on myself the triggers and potentiometers weren't even in line with each other either, the right trigger for example pushes in diagonally right, while the potentiometer slides diagonally left. WHY DO I DO THIS CRAP?
After legitimately days straight on working on NOTHING BUT the triggers I finally worked out a working design, and I wanna say it is sorta clever?
The triggers slide inwards on precision dowel pins and use an extension spring to return them.
The cool part that I came up with, is it uses a cut lenght of ABS filament to decouple the horribly out of line axis of the triggers and potentiometers!
Felt dumb at first but it is a cheap easy solution to a mechanically awkward problem.
The whole setup completely clears the batteries and battery PCB too!
I will have to go over the digital part of them in a later post.
GAMEBOY PLAYER:
I KNOW I said it was a "stretch goal" and now this just looks like rampant scope creep, but uh, I uh,
@subierekt made me do it, yell at him!
He sent me a GBP cause he knew it would force my hand and my entry would be as good as done for.
Sabotage aside, I have made huge progress on it.
The custom chip is already RE'd
And I already have nearly complete routing done for the GBA part of it.
I still need to handle voltage switching (For GB/C support) and the regs for the DOL and GBA sides of it, but I am close!
It ended up not being a very painful feature to do in the grand scheme of things.
There's not a lot to say about this feature cause it is mostly just RE work and not super interesting engineering.
CONCLUSION:
I have worked on a bunch of stuff on this design already, I have made some amount of progress on every single feature and aspect of it.
While I would like to talk about all of it, with my weird workflow we would be here all week. A lot of stuff is half or more done but doesn't look like much, but should be presentable very soon.
I make way more frequent status updates and outline things I am trying to solve over in the Discord server.
I would like to flip the dynamic on that one but I am just really bad at remembering to write updates in non real time.
We both know I am lying but I wanna say I should post again fairly soon, so like, stay tuned.
Thanks nerds.
PRAISE THE HANDLE
