You just upload the zip file in the PCB section of the GitHub under the CAD directory (those labeled with Gerbers). No timeline on the build guide right now unfortunately as I’m quite busy but hopefully in the next month or so I’ll release it.
Worklog Retro Lite CM4 - A StonedEdge and Dmcke5 collaboration
- Thread starter Dmcke5
- Start date
Yeah there is no resource really, the first ones were hand made from 3rd party switch lite screen protectors and painted, but I ended up buying samples from Retro Game Repair Shop (RGRS) for the final ones who had them custom made based on the specifications we provided.
Hi all,
Life got a bit busy recently so I haven't been able to update as frequently as I would like, but the docking station is almost complete now after several bugs were squashed with the serial input routine handler loop! I'd say I'm about 60% of the way there.
A simple button toggles all of the metadata sent over to the end user. I have also integrated sleep mode now so that the display will sleep with inactivity after 1 min. The user can wake the dock by pressing the button or by doing any other command, like exiting a game or re-entering a different game, for example. This prevents OLED burn in (yeah, I know, pretty unlikely... but it never hurt to be cautious).
The remaining features include showing some play statistics such as most games played by times and duration, game description via hardware scrolling and other metadata + a small video of each game. Also shutting the dock down when the system is powered off should be relatively simple, too so that it doesn't hang when power is killed from the regulators.
Next post, hopefully in the cutting edge!
youtube.com
Life got a bit busy recently so I haven't been able to update as frequently as I would like, but the docking station is almost complete now after several bugs were squashed with the serial input routine handler loop! I'd say I'm about 60% of the way there.
A simple button toggles all of the metadata sent over to the end user. I have also integrated sleep mode now so that the display will sleep with inactivity after 1 min. The user can wake the dock by pressing the button or by doing any other command, like exiting a game or re-entering a different game, for example. This prevents OLED burn in (yeah, I know, pretty unlikely... but it never hurt to be cautious).
The remaining features include showing some play statistics such as most games played by times and duration, game description via hardware scrolling and other metadata + a small video of each game. Also shutting the dock down when the system is powered off should be relatively simple, too so that it doesn't hang when power is killed from the regulators.
Next post, hopefully in the cutting edge!
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
youtube.com
Last edited:
ubanov
.
- Joined
- Jul 23, 2023
- Messages
- 1
- Likes
- 0
I love this project. I want need one retro lite cm4... It have all that I need: big screen, very portable, and open with raspberry pi.
But... 900$ for 5 kits of mounted pcb... (what another user have said about Makerfabs)
And where and how could I ask the aluminum cover... may be I could try to print the std in a 3d printer as an alternative? (I prefer aluminum, but I don't know where to ask it).
And I haven't found the screen model. Where and how much is it?
I think it will be very difficult to build one of this :-(
Thanks in advance.
But... 900$ for 5 kits of mounted pcb... (what another user have said about Makerfabs)
And where and how could I ask the aluminum cover... may be I could try to print the std in a 3d printer as an alternative? (I prefer aluminum, but I don't know where to ask it).
And I haven't found the screen model. Where and how much is it?
I think it will be very difficult to build one of this :-(
Thanks in advance.
Hi! None of these individual parts are for sale unfortunately as I’m not making kits & don’t plan to anytime soon. I am spending most of my time working on a new revision. Any generic 5 inch 40 pin TTL display that is 24-bit RGB (800x480p) should work in this version. As for the aluminum cases, I can’t really help you there. You’ll have to either reach out to a professional machinist to get them done if you can’t do it yourself, all of the files are on my GitHub and available. 3D printing the case as mentioned before can work but it’s very thin and feels cheap and flimsy. I have a couple of completed builds though that are for sale, if you’re interested you can message me through DM.
Last edited:
NeoGoku
.
- Joined
- Apr 14, 2024
- Messages
- 1
- Likes
- 0
I have created an account just to leave a comment here. First of all I just want to say wow. I think the project and the heartfelt work you put into it is simply Great, and I want to give you my respect.Unfortunately, my understanding and craftsmanship skills are absolutely not sufficient to recreate something like this. Is there any way to get a model?
- Joined
- May 19, 2024
- Messages
- 3
- Likes
- 0
Hey, appreciate I'm pinging an old thread here but I have a question around the display and TFP401. My understanding is you have a separate EEPROM to provide the EDID and can see this EEPROM exists as U2 on the main board schematic. How is this EEPROM initially programmed? Is this something you handle with the Arduino. Is an EDID strictly necessary if a resolution is forced as part of the raspi-config setup?
No worries. EDID is not necessary if you’re forcing a resolution.
- Joined
- May 19, 2024
- Messages
- 3
- Likes
- 0
Oh cool thanks, so is the EEPROM module not actually needed in this instance?
Also the driver for wm8960, the GPIO you used to link to the CM4 - is this determined by the driver? I'm designing my own CM4/CM5 device but simplified - more towards the GBA size of things with no need for docking, etc. Looking to use the same FPGA (TFP401) to drive the display and likely the same audio amplifier. I'm still getting my head round USB buses/controls and things like this as some of it's quite new to me and it's the script side of things I'm unsure on.
Am I right in saying the CM5 should be able to handle the display side of things through USB-C?
Also the driver for wm8960, the GPIO you used to link to the CM4 - is this determined by the driver? I'm designing my own CM4/CM5 device but simplified - more towards the GBA size of things with no need for docking, etc. Looking to use the same FPGA (TFP401) to drive the display and likely the same audio amplifier. I'm still getting my head round USB buses/controls and things like this as some of it's quite new to me and it's the script side of things I'm unsure on.
Am I right in saying the CM5 should be able to handle the display side of things through USB-C?
No, you dont need an EEPROM - the internal resolution is forced and the display resolution is always a known factor. No need to read any data in.
The GPIO mappings can be found in the CM4 datasheet for the I2S bus. If it were me doing this same project again, I would not use the TFP401 decoder for handling video in a handheld. Yes it works, but at what cost? It's extremely power hungry (draws around 350mA). You would be better off investing time trying to get a MIPI display working via DSI to save yourself some power in my opinion if you've got the technical knowhow to get it working, or maybe just using DPI via GPIO. A first step is finding a Linux driver in the kernel that is compatible with your display controller and then getting your display timings set up properly as per the manufacturer. I just used it because it was all I knew at the time that was a proven working solution.
Not sure what you mean by the last part. The CM4 - BCM2711 (nor the BCM2712 SoC) doesn't have a DisplayPort bus, whereas the RK3588s has a DisplayPort bus directly available from the SoC with working DP drivers - at least in kernel 5.10.160, mainline drivers are still WIP. You're out of luck with video over USB-C when it comes to Raspberry Pi devices AFAIK (you will need to convert HDMI to DisplayPort with some form of translator IC) if you want video out over the Type-C interface.
Another advantage of the RK3588 is that it has two I2S buses, whereas the BCM2711 only has one.
Good luck!
The GPIO mappings can be found in the CM4 datasheet for the I2S bus. If it were me doing this same project again, I would not use the TFP401 decoder for handling video in a handheld. Yes it works, but at what cost? It's extremely power hungry (draws around 350mA). You would be better off investing time trying to get a MIPI display working via DSI to save yourself some power in my opinion if you've got the technical knowhow to get it working, or maybe just using DPI via GPIO. A first step is finding a Linux driver in the kernel that is compatible with your display controller and then getting your display timings set up properly as per the manufacturer. I just used it because it was all I knew at the time that was a proven working solution.
Not sure what you mean by the last part. The CM4 - BCM2711 (nor the BCM2712 SoC) doesn't have a DisplayPort bus, whereas the RK3588s has a DisplayPort bus directly available from the SoC with working DP drivers - at least in kernel 5.10.160, mainline drivers are still WIP. You're out of luck with video over USB-C when it comes to Raspberry Pi devices AFAIK (you will need to convert HDMI to DisplayPort with some form of translator IC) if you want video out over the Type-C interface.
Another advantage of the RK3588 is that it has two I2S buses, whereas the BCM2711 only has one.
Good luck!
Last edited:
- Joined
- May 19, 2024
- Messages
- 3
- Likes
- 0
Thanks for all the info!
Have you done anything with the MIPI or DPI options? I saw you're working on a CM5 version for when it's released. I appreciate what you said about the power draw on TFP401. My issue is I don't really have experience on the software side of things (have only built arduino programs) and so was trying to build a PCB that would work almost plug and play with a batocera or retropie image (I imagine I'll need to do something for the controls). For that reason it put me off the other two options a bit but perhaps it's not as hard as I'm making out. Certainly looks easy enough to edit the config.txt in raspian for DPI and you can access raspi-config from the images so perhaps it is as easy as that?
Also what made you use the ATTiny85 for the global power/shutdown? Was this also a power saving measure? Could this routine also have been handled by the Arduino you used for the controller?
Have you done anything with the MIPI or DPI options? I saw you're working on a CM5 version for when it's released. I appreciate what you said about the power draw on TFP401. My issue is I don't really have experience on the software side of things (have only built arduino programs) and so was trying to build a PCB that would work almost plug and play with a batocera or retropie image (I imagine I'll need to do something for the controls). For that reason it put me off the other two options a bit but perhaps it's not as hard as I'm making out. Certainly looks easy enough to edit the config.txt in raspian for DPI and you can access raspi-config from the images so perhaps it is as easy as that?
Also what made you use the ATTiny85 for the global power/shutdown? Was this also a power saving measure? Could this routine also have been handled by the Arduino you used for the controller?