A
Anonymous07/18/25, 20:43No.2932429DIY Pocket Console
So, together with a friend, we have decided to make our own console for fun and giggles. This surely is an undertaking but this is an idea we were considering for a long time and as we got more and more experienced with circuits, embedded programming, 3d printing and stuff like that, I feel like it would be finally in our reach.
I never really looked at other people's similar projects, I have no idea what I'm doing honestly, but I can write code and I can use google so I think we will figure it out and get there eventually.
I will post our progress in this thread.
58
Replies
A
Anon07/18/25, 20:48No.2932431
Since I know pretty much noting about electronics, my friend will be taking care of designing the hardware. It will take a while and since I also do not want to start "production" before I know if this all even makes any sense, I decided to get all the components and assemble a sort of dev board to test things on first. Today I got all the parts needed so I can try to get something working.
A
Anon07/18/25, 21:11No.2932435
Just so you're aware there is a decently large industry for single board computer handheld emulator devices.
I'm not telling you to just buy one but I am bringing this up because if you use a common chipset it is feasible that you could steal a compatible operating system easily so you can focus on the hardware side of things.
E.g. Anbernic Rg35xx
See: retrogamecorps on youtube
A
Anon07/18/25, 23:13No.2932466
Just build a portable wii or something. You'll want to kill yourself less afterwards.
A
Anon07/19/25, 06:29No.2932559
https://www.hackster.io/megazoid/crokpocket-a0ff83
A
Anon07/21/25, 03:30No.2932987
None of these chips have clock rates > 1 GHz or RAM in excess of 1 GB. You can't emulate much on that. Unless you're slapping a FPGA in there you need at least 1 GHz clock rate and 1 GB RAM to emulate everything SNES and before.A FPGA would also allow you to prototype hardware for what is essentially your motherboard, so you could design it in the FPGA with the plan to integrate it with the FPGA. Then from there implement it in hardware and work out the bugs.
A
Anon07/21/25, 18:11No.2933116
I think you should be focusing on building something that can run existing emulators rather than thinking about building a device that games could be made for.
If you got no games, you got no gaming console.
A
Anon07/21/25, 21:39No.2933176
YeyAnyone has any idea why does the screen grid is offset? The absolute size is correct but top left corner of physical pixel grid seems to actually be at x=1, y=2. I have to be drawing to 1..160 x 2..129 inclusive in order for the image to properly align with the pixel grid. Might this be specific to this particular display model or maybe manufacturing problem?
Video format (.mp4) not supported YET!
View here : Click here
A
Anon07/28/25, 23:43No.2934941
Update. I had to rewire stuff to fit everything but now it's all connected(except for gain). Still haven't programmer and tested it but that will come next.
In the mean time, I tried to get Lua running but that's not exactly straightforward for Rust on esp32. I don't think anyone has done it yet and the existing libraries only really target x86 and wasm. But there exist a C++ IDF Lua module and WIP Rust Lua interpreter, which gives a couple of options:
>get that interpreter running on esp (currently it causes stack overflow for some reason, even at 32k stack. some corruption maybe?)
>get lua-src to compile Lua on xtensa, trying to imitate that IDF Lua, so mlua library can work
>try to integrate IDF Lua module directly into the project and write my own bindings/wrapper
Every option requires some non-trivial work and neither is guaranteed to work. However the first one would probably be the nicest since it would give us full control over the interpreter. We could emulate Pico-8 fixed point precision and whatever other wacky idea they had. But I have no idea how stable and usable this project is. The author still seems to be actively working on it so I could try contacting him. Alternatively second option, if it works, it would give us really nice, battle-tested bindings, since mlua is quite popular library.
3rd option would probably take most work and would suck so better save it for last.
A
Anon07/29/25, 13:39No.2935031
what are you all doing
A
Anon07/31/25, 23:29No.2935536
Got Lua working using piccolo(Lua interpreter in Rust)!
Turned out sdkconfig should be in the workspace root rather than specific crate's directory. Without that it defaulted to 3k stack size.
Also got analog stick working and implemented deadzone. I also ditched embedded graphics core and wrote my own functions that operate on framebuffer instead of directly on screen. Drawing framebuffer is still synchronous since that's how the random st7735 library I found works, so I will have to write custom driver based on DMA and interrupts. It will probably require double buffering/swap chain I guess.
A
Anon08/02/25, 22:26No.2935876
>ESP32You need the Bluetooth version so you can hack satellites.Why not include a minidisc player while you’re at it for Sony PSP emulation
A
Anon08/14/25, 00:25No.2938143
Not a diy, more of a humanities type of guy but I can point out a couple of things you should look out for based on the OP image.>emulation
Would have a lot of legal concerns if encouraged by you, or made profit off of you. It's still technically illegal, so letters would start piling up. A way around it would be to make it have an OS that had emulation systems built in already, like android, and provide a legal way for customers to emulate (also for free?)>easy to make games for
Modern game engines require some heft, if you want it to be have games on a larger scale you might want to have beefy specs. Also consider what game engines are compatible with which OS, and how multilayer would work
A
Anon08/24/25, 18:12No.2940424
Bump because I am back from vacations and the project is still ongoing.Only after moving to esp-hal, I realized I2S support is not that great compared to SPI/DMA. I only use it for sound which probably won't be needed for a while, but since I already set my oscilloscope up and prepared test program, I might as well go for it and implement other standards beyond the most basic stereo TDM Phillips.
Well, if I knew just how many different standards and moving parts there is to I2S I would probably procrastinated on it longer, but it's too late now. Now I bury myself in technical references to see how to properly implement at least remaining TDM standards and channel configurations it for the whole esp32 family.
A
Anon08/25/25, 00:27No.2940517
Im just gonna buy one.
A
Anon08/29/25, 03:39No.2941570
Check out muh Nitender Oui-oui.
A
Anon09/08/25, 16:07No.2943777
Back to square one(0-indexed).
I got I2S driver to do what I needed and rewrote everything to no-std.
Now it's time to port the lua vm to no-std.
Pic related is current, improved communication with the touch screen. Since I got oscilloscope hooked I also checked how did the previous one perform and I have no idea how did it even work. It completely shit on the protocol, yet somehow managed to work by pure chance. No wonder why I was getting sort of noise in position, it is so much more precise now. Not that I will even be needing touch screen much but it's still nice to see things work properly.
A
Anon09/21/25, 22:54No.2946191
Bump because progress.Not much to show off visually right now.
Pico-8 uses fixed point Q16.16 math and to make the emulation accurate I will have to change the lua interpreter to do the same. I could probably just use some general purpose fixed point library, but I decided to roll my own code since I want to try some interesting trig approximations I have seen recently. So far I managed to write/wrap integer-style math methods. Trigs, pows, logs, etc will come next.In the meantime I also wrote script to embed Pico-8 system font in the code and support for in-memory custom fonts. There isn't any way to see them until I implement print() function though.
A
Anon10/02/25, 22:35No.2948432
This was way more difficult than I thought, but after spending quite some time researching and modeling things in Desmos, I managed to implement all the math functions I needed. They should be quite fast, possibly faster than polyfilled float math, and precision is acceptable. The pic related shows the error(in multiplies of machine epsilon, 1/2^16). However this is not comparison to exact values but to what pico8 uses. My algorithms are actually more precise, but based on values pico8 returns I suspect they use lookup tables for trigonometry and possibly exp/ln that might be used for computing exponentiation. That's where this fuzz comes from, especially in sin/cos. They do not interpolate the values from these tables, just pick one the nearest.
Later I might try different methods, including lookup tables and benchmark them. But having 100% precise math emulation is not important right now, or ever really. It can be done later.
A
Anon10/02/25, 22:41No.2948433
Your project is perfect!!! a few more adjustments and it could become real.
A
Anon10/14/25, 01:19No.2950706
The project goes on.I forked the lua library and made it run fully on fixed point math, no more floats and integers. That took a while and I had to abandon all lua stdlib but that's fine since pico-8 doesn't use it either.
Having fixed point numbers used everywhere have weird consequences. For example, tables and strings that grow past 2^15, return negative lengths because of wrapping. Lists in particular are susceptible to this, once all whole number indexes are used up, they just return size 0 and keep pushing new elements into 1th index. Strings on the other hand can grow past 2^16, but that means part of it can be not addressable.
I am not going to try to match all these weird behaviors for now. Instead I will just crash game when it tries to create such pathological collections. Considering how resource constrained pico-8 is and that no official or unofficial documentation ever mentions it, mostly likely no game would ever depend on this weird behavior.
Next, the lua library will have to be changed to use p8scii encoding natively. Right now, it works with any ascii extension, so this probably won't be that much of a deal like math. The lua will probably also have to somehow be aware of pico memory model in order to support custom operators like peek and poke.
Video format (.mp4) not supported YET!
View here : Click here