Odroid-Go v2

[crashoverride]

PCSX_rearmed

That is actually what I had in mind as I wrote the post. I do not think the dynarec would be the bottleneck. The render path is NEON (SIMD) optimized on armv7[1]. Without a GPU, SIMD, or another core, I don't see PSX being playable. This would make a dynarec moot.

[1] https://github.com/notaz/pcsx_rearmed/t ... on/psx_gpu

[sydarn2]

PCSX_rearmed

That is actually what I had in mind as I wrote the post. I do not think the dynarec would be the bottleneck. The render path is NEON (SIMD) optimized on armv7[1]. Without a GPU, SIMD, or another core, I don't see PSX being playable. This would make a dynarec moot.

[1] https://github.com/notaz/pcsx_rearmed/t ... on/psx_gpu

I am just saying that is one pro if choosing an armv7+neon SoC. You do get psx.

I am not sure how they did it for MIPS, I don't think they used any SIMD instructions for the psx_gpu, see here https://github.com/senquack/pcsx4all/tree/master/src, but only a dynarec. And it does run fairly well on 1Ghz Ingenic jz4770.

[sydarn2]

SoCs/SiPs with integrated RAM that I know of:

Sigmastar, many options
Ingenic X2000 (128MB)
Ingenic X1000 series (Multiple options)
Ingenic T31 (64MB/128MB)
Allwinner V3s (64MB)
Allwinner F133 (64MB)
Allwinner, several SocS based on ARM926EJ-S (ARMv5TE) (32MB and 64MB)
Microchip SAMA5D2 (Multiple options, there website seems to have problem at moment so could check which options there are)
Rockchip RV1108G (128MB)
Rockchip RK3308G (64MB)

I will update this list if I think of more relevant, less than 32MB of RAM is assumed irrelevant.

[sydarn2]

There are no vector extensions (SIMD) for RISCV and no GPU on the SoC, so there are no optimizations to consider.

I don't think we can say for sure if the D1s has vector instructions or not. The datasheet for D1 specifies XuanTie C906 RISC-V CPU, which can be configured with vector extensions [1]. The explanations for the extensions are here [2].
Sunxi specifies the following extensions RV64IMAFDCVU for D1s [3] but it is unclear what the source for that is.

It is indeed an interesting SoC and hopefully it reuses peripherals from Allwinners other chips, so that it can sooner benefit from mainline linux.

Btw, there does exist one dynarec for RISC-V RV64IM, for 32X in picodrive [4]

[1] https://occ.t-head.cn/vendor/cpu/index? ... 5983423488
[2] https://en.wikipedia.org/wiki/RISC-V#IS ... extensions
[3] https://linux-sunxi.org/D1s
[4] https://github.com/irixxxx/picodrive

[sydarn2]

Actually, the user manual [1] of D1s/F133 does specify the instruction set architecture. It is 64GCV, where G is a grouping for standard instructions meaning following extensions "IMAFDZicsr Zifencei", and V is for vector execution unit.

And btw, I remembered there is a dynarec for psx called lightrec [2], that uses GNU lightning for code emitter, which means it in theory does support Risc-V. Although I am not aware of it ever being tested. There is also PCSX4ALL Fork [3] that uses this dynarec as well.

[1] page 45: https://whycan.com/files/members/5266/F ... l_V1.0.pdf
[2] https://github.com/pcercuei/lightrec
[3] https://github.com/pcercuei/pcsx4all

[crashoverride]

And it does run fairly well on 1Ghz Ingenic jz4770.

For completeness, I should note that JZ4770 does have a GPU (Vivante).

Actually, the user manual [1] of D1s/F133 does specify the instruction set architecture. It is 64GCV, where G is a grouping for standard instructions meaning following extensions "IMAFDZicsr Zifencei", and V is for vector execution unit.

Hopefully, boards using it will be available so that real-world testing and evaluation can be done. There were other Allwinner chips that looked promising on paper in the past.

[sydarn2]

And it does run fairly well on 1Ghz Ingenic jz4770.

For completeness, I should note that JZ4770 does have a GPU (Vivante).

Yeah, but it doesn't use the GPU. (It also runs on the jz4760b) In fact I have been told that using GPU for psx doesn't gain you any speed, but only more features. I actually think the PCSX4ALL fork with lightrec could be interesting to test. It is not as efficient as a native dynarec, but I think at least many games could be playable. I heard some games with lightrec on the jz4770 runs full speed (the native dynarec runs most full speed).

Anyway, I think the D1s software platform could be inspired by opendingux, which runs on Linux on really low resource platforms. For example the the rs90 flavour which runs on only 32MB of ram, and uses musl. If sdl1.2 is used most emulators from opendingux could be reused, except basically regba, which relies on the mips native dynarec.

Actually, the user manual [1] of D1s/F133 does specify the instruction set architecture. It is 64GCV, where G is a grouping for standard instructions meaning following extensions "IMAFDZicsr Zifencei", and V is for vector execution unit.

Hopefully, boards using it will be available so that real-world testing and evaluation can be done. There were other Allwinner chips that looked promising on paper in the past.

MangoPI are going to start mass production in November and it will be available on TaoBao and Seeed. Apparently software will be Allwinners Tina (based on OpenWRT). You can read about it in this thread [1].

[1] https://twitter.com/mangopi_sbc/status/ ... 7558627335

[lordhardware]

I am just saying that is one pro if choosing an armv7+neon SoC. You do get psx.

In all honesty, psx is not a win for a Odroid Go 2.
Even at its most simple, you now need at least 6 more input buttons for the majority of games.

I’d rather not have more than a two button console anyway, it’s kind of the charm of the Odroid Go.

But if you we’re going to change it, have a single extra button which gives access to most of the MegaDrive and arcade libraries, and a little more power which would make the current compatible systems work better.

[crashoverride]

Apparently software will be Allwinners Tina (based on OpenWRT).

This is what concerns me:
https://github.com/orgs/tinalinux/repositories

All of the Tina Linux repos were last updated in 2017 with linux 3.10 being the most recent kernel.

[sydarn2]

Allwinner D1/D1s/F133 specific Tina Linux BSP supports Kernel 5.4.61 at least. That BSP can be downloadable from a Chinese Baidu server probably.

Screenshot from 2021-11-08 11-48-28.png (726.28 KiB) Viewed 8564 times

But, there seems not to be any mainlining activities.

BTW, I found the screenshot from this Hackaday blog.
https://hackaday.io/project/182389-the- ... ter-by-now

[sydarn2]

I am just saying that is one pro if choosing an armv7+neon SoC. You do get psx.

In all honesty, psx is not a win for a Odroid Go 2.
Even at its most simple, you now need at least 6 more input buttons for the majority of games.

I’d rather not have more than a two button console anyway, it’s kind of the charm of the Odroid Go.

But if you we’re going to change it, have a single extra button which gives access to most of the MegaDrive and arcade libraries, and a little more power which would make the current compatible systems work better.

I wouldn't mind a new Go with the esp32-s3. But if we are going the route with 1Ghz CPU and linux, the firmware will be totally different and it will have enough power to emulate SNES. So it would make sense to make a SNES compatible control scheme.

I think with the ESP32 modules you pay a lot for the fact that they are Wifi certified which isn't strictly necessary for an emulation handheld. If you can find a regular application SoC (armv7/v8, RISC-V, mips32) with integrated RAM that costs about the same but with 1GHz cpu, it would make sense to consider it. You can always expose a USB-A host port for Wifi upgrade path.

[crashoverride]

You can always expose a USB-A host port for Wifi upgrade path.

Looking at the D1s block diagram, it has 2 USB roots. USB-OTG and USB-HOST. I think the USB-HOST should be dedicated to a WiFi/BT module like the ODROID Wifi 5B (RTL8821CU) and the OTG port exposed for general use. The OTG port would allow customers to attach regular USB devices or function as a mass storage device for loading applications, ROMs, etc.

I would also like to see the IR RX/TX implemented. This would make remote control of consumer electronic devices possible. It should also enable "learning remote" functionality.

There also needs to be a way to expose the SDIO, SPI, I2C, UART, PWM, I2S, and GPIO as an "expansion" connector. What form this connector should take is still up for debate. The original ODROID-GO was always about more than playing games to me. It was more like an electronic version of a Swiss Army Knife: multiple functions in minimal space, portable, and versatile.

[sydarn2]

The original ODROID-GO was always about more than playing games to me. It was more like an electronic version of a Swiss Army Knife: multiple functions in minimal space, portable, and versatile.

Sure, you should make it a tinkerer device. But also make it an out-of-box decent emulation device, I think that will help with sales. But yeah, you have to find a niche not yet exploited by others. I think RISC-V would help, people like new stuff, and it would be the first RISC-V (gaming) handheld, which would appeal to some.

I don't know if a form factor is set yet, but I guess it would make sense to make a small device since HK already offer a medium and large size handheld. And the Go form factor was really nice because it is so slim (and small). It would make it very suitable as mp3player for example. And built in IR sounds like a really cool idea!.

I personally think that it should remain small and cheap. For me a 320x240 display is still enough (IPS would be nice though), and if consider going to another screen please still remain by 4:3 format, people will not like it if there is 3:2 or 16:9 display when it can only emulate systems that are 4:3. But also try to fit in 4 real face buttons, snes is immensely popular by retro gamers. I have though about it, and you could have two pair of rockers high up on each side, so you can reach them with you index fingers. They could work as both R1/2 and L1/2 as emulation device, and as volume rocker and track skipper in mp3 mode.

[crashoverride]

For me a 320x240 display is still enough

The display resolution will be a constraint. The larger the display resolution, the more memory is required for frame buffers. In the ODROID-GO, this was mitigated in that 8bit buffers were color converted and scaled "in place" during rasterization to the LCD. This can not (typically) be done on a device with a real display controller. Instead, a minimum of double buffering of the actual frame contents is required.

320 x 240 x 2 (16bit) x 2 (buffer count) = 307200 bytes = 0.3MB
480 x 320 x 2 (16bit) x 2 = 614400 bytes = 0.6MB
480 x 320 x 4 (32bit) x 2 = 1228800 byte = 1.2MB

Since most 480x320 LCD panels are actually 16bit internally, the 16bit frame buffer makes the most sense. The 32bit is required for alpha compositing (overlays) and would be used internally by applications/emulators.

The maximum sound buffer memory would be:
48000 (samples) x 2 (channels) x 2 (16bit) = 384000 bytes / second
384000 bytes / 60 (fps) = 6400 bytes / frame
6400 x 2 (buffers) = 12800 bytes

[crashoverride]

Some possibly relevant info:
https://www.robertlipe.com/allwinner_d1s_f133/

Unfortunately for many developers, D1 supported only 0.7.1 of Vector, which has source and binary incompatibilities with the final 1.0 version of that extension which is currently (October 2021) in final stages of public review. This part also really requires Allwinner’s own use of GCC/Binutils to use these extensions well. Interestingly, the RISC-V part of this SoC comes from Alibaba’s XuanTie C906 line, which was itself recently open-sourced, though there have been serious issues trying to land Alibaba’s incompatible work in upstream projects like GCC and QEMU.

[sydarn2]

Some possibly relevant info:
https://www.robertlipe.com/allwinner_d1s_f133/

Unfortunately for many developers, D1 supported only 0.7.1 of Vector, which has source and binary incompatibilities with the final 1.0 version of that extension which is currently (October 2021) in final stages of public review. This part also really requires Allwinner’s own use of GCC/Binutils to use these extensions well. Interestingly, the RISC-V part of this SoC comes from Alibaba’s XuanTie C906 line, which was itself recently open-sourced, though there have been serious issues trying to land Alibaba’s incompatible work in upstream projects like GCC and QEMU.

Sad, I have also tried to research Allwinners G2D, which provides hardware scaling which is very relevant for emulation, while it is present in A10 and A20 which are very old it still seems it haven't been up-streamed to Linux mainline.
Honestly Rockchip seems like a better choice in general, since they provide good support out of the box and their RGA (which provides hardware scaling) is in mainline Linux. RV1108G does have RGA according to the datasheet, but I don't know how much it costs. Maybe it is too expensive.

[sydarn2]

I just took a deep dive into DGP/fifteenhex's work on linux mainline for Sigmastar SoCs. Appearantly he already has drm driver that works for SSD202D, and maybe more SoCs, would have to ask him. So it seems support is pretty far, sound is still missing though.

EDIT: Here is the product brief for SSD202D: https://linux-chenxing.org/infinity2/SS ... _S_v01.pdf

[lordhardware]

I am just saying that is one pro if choosing an armv7+neon SoC. You do get psx.

In all honesty, psx is not a win for a Odroid Go 2.
Even at its most simple, you now need at least 6 more input buttons for the majority of games.

I’d rather not have more than a two button console anyway, it’s kind of the charm of the Odroid Go.

But if you we’re going to change it, have a single extra button which gives access to most of the MegaDrive and arcade libraries, and a little more power which would make the current compatible systems work better.

I wouldn't mind a new Go with the esp32-s3. But if we are going the route with 1Ghz CPU and linux, the firmware will be totally different and it will have enough power to emulate SNES. So it would make sense to make a SNES compatible control scheme.

I think with the ESP32 modules you pay a lot for the fact that they are Wifi certified which isn't strictly necessary for an emulation handheld. If you can find a regular application SoC (armv7/v8, RISC-V, mips32) with integrated RAM that costs about the same but with 1GHz cpu, it would make sense to consider it. You can always expose a USB-A host port for Wifi upgrade path.

Bluetooth and wifi is what set this apart.
If you just want good quality handheld emulation in a tinker-friendly device buy a Retroid Pocket 2+ it does perfect PSX and N64 and up to light GameCube in a pocketable form factor for less than $100US.

But that’s not what the Go is.

[sydarn2]

Fwiw the ESP32-S3 devkit N8R8 is now available on mouser:
https://eu.mouser.com/ProductDetail/Esp ... GQrdg3E%3D

[crashoverride]

Appearantly he already has drm driver that works for SSD202D

"Portable game console runs RetroArch on SigmaStar SSD202D processor"
https://www.cnx-software.com/2021/12/03 ... processor/

[sydarn2]

Appearantly he already has drm driver that works for SSD202D

"Portable game console runs RetroArch on SigmaStar SSD202D processor"
https://www.cnx-software.com/2021/12/03 ... processor/

It has made a full circle now

I told dgp/fifteenhex about the MIyoo Mini here: https://github.com/linux-chenxing/linux ... ussions/41

Then dgp/fifteenhex posted it on twitter, which Jean-Luc saw. And then Jean-Luc wrote the article :p

[crashoverride]

Another suggestion would be to do a FPGA based device. I think it would have huge educational value but an insanely high barrier to entry.
https://hackaday.com/2019/11/04/giganti ... iren-song/

[mad_ady]

The advantage of fpga would be upgradable hardware... Out of curiosity - how much does a fpga cost these days?

[crashoverride]

The best I could make out the part number in the picture is:
LFE5U-45F-8BG381C

It costs $25.35 USD (QTY 1) from Mouser at the time of this post.

They have 0 in stock and a lead time of 27 weeks.

[sydarn2]

MangoPI-MQ is going in production:
https://twitter.com/mangopi_sbc/status/ ... 4303022080

[mctom]

The advantage of fpga would be upgradable hardware... Out of curiosity - how much does a fpga cost these days?

ICE40LP or -HX series have been quite popular among hobbyists lately, with top model at less than $10.
Open source tools are available to program them, what makes them exceptionally attractive for hackers. They are often programmable by replacing contents of associated SPI EEPROM, so any microcontroller or SoC can handle that.
However 7600 cells are usually regarded as insufficient for many tasks. That's what FPGA engineer said in my workplace.
Slightly more advanced FPGAs (such as ICE40UP) have dedicated DSP blocks that can handle multiplication, which vastly simplifies many CPU core applications.

FPGAs in general excel at simple but fast applications, and ICE40 series can be understood as a substitution for some 1000 TTL chips, and clocked at 400MHz, and doing all that at very low power.
In space industry FPGAs are extremely expensive ($20k for an "one time programmable piece, $80k for dev edition), but have much more cells and are used as the main control logic. Microcontrollers are not a thing in space really. Instead, tiny cores are implemented on FPGAs.

Simple CPUs can be implemented on FPGA, for sure, especially those from retro consoles. But that's a lot of work, that partially has already been done.

[sydarn2]

Simple CPUs can be implemented on FPGA, for sure, especially those from retro consoles. But that's a lot of work, that partially has already been done.

A lot of retro consoles have already been implemented as part of the MiSt and MiSTerFPGA projects, so they would just need porting. https://github.com/MiSTer-devel

Personally I think it will be hard to do on a low budget, and there already is the Analogue pocket. Even though it is bit hard to get your hands on.

[mctom]

For sure it's not going to be easy, cheap or quick, you're talking about entering a whole new market after all.
Even FPGA engineers are scarce on the market, at least here. It's not just another programming language after all.

[dgp]

The SSD210 (QFN68) might be a good option... Someone would need to work out the sound hardware though.

[kelbot]

I would still prefer basically a very slight upgrade to the original Go with the ESP32-S3. Better display would be nice but not a deal breaker. Add a headphone jack. I'd be happy with that and being able to buy one again.