OdroidGo Emulator (CPC Caprice Engine)

[millim]

Hello community!

I decided to go for a Odroid-Go, because it is right at the edge of a NUC on the one side and a micro controller on the other side. Assembly and setup was easy and have already apps running on it.

Now, how to proceed on software development? I mean, finding bugs by compiling, flashing, and "printf" monitoring is a waste of time, right?

Can you please provide me some details how to do software development and code debugging with the kit. Here some requirements I am aiming for:
- should include RTOS
- should include task switching of the CPUs, because Audio and Video rendering is executed on the aux CPU.
- emulation of Audio and Video

Regards
millim

[crashoverride]

finding bugs by compiling, flashing, and "printf" monitoring is a waste of time, right?

This was the method used to develop all of the go-play software.

Now, how to proceed on software development?

An internet search that includes the term "ESP32" should provide many resources for software development with "esp-idf". You can also consult the wiki for Arduino based development:
https://docs.espressif.com/projects/esp ... t-started/
https://wiki.odroid.com/odroid_go/ardui ... uino_setup

[millim]

finding bugs by compiling, flashing, and "printf" monitoring is a waste of time, right?

This was the method used to develop all of the go-play software.

.. so obviously not a waste of time . Yes, for an experienced programmer, I think it is reasonable to go that route.
I go along SDL2 as recommended by another post. So, I can test the basic functionality on Linux, test and debug larger increments on the OG.

THX
millim.

[ducalex]

The best way to debug an esp32 is through JTAG but that isn't really possible on the GO. The second best way is the monitor with printf and abort/assert. Thankfully the esp-idf documentation is very good and all in one place, it is a joy to work with it.

PS: If you prefer to use the most recent esp-idf instead of crasnhoverride's older 3.2 fork you will have to apply this patch and this patch. 4.0 has much improved event handling and IPC and SPIRAM management and faster builds which might all be useful for porting SDL2.

[millim]

Thank you ducalex for your suggestions.

The best way to debug an esp32 is through JTAG but that isn't really possible on the GO. The second best way is the monitor with printf and abort/assert. Thankfully the esp-idf documentation is very good and all in one place, it is a joy to work with it.

I will do twofold, first do much as possible on a linux machine to test the code and second by using the idf-monitor on the GO for final debug.

PS: If you prefer to use the most recent esp-idf instead of crasnhoverride's older 3.2 fork you will have to apply this patch and this patch. 4.0 has much improved event handling and IPC and SPIRAM management and faster builds which might all be useful for porting SDL2.

Well, I am not considering a SDL2 port to the GO. I am using SDL2 on the linux machine to emulate display, keyboard and file I/O as a wrapper of the software I want to port to the GO. What I am about to do is to port an Amstrad CPC emultion, because I think it is a lot of fun to do so. It's all about the kit is for - fun in learning/improving skills.

I think, I have all the ingredients together to start:
* The base engine will be taken from Caprice32 for PalmOS. It features also a nice virtual keyboard. I will not use the mouse pointer to navigate through the keyboard, more left, right, up, down GO hard keys, way faster to navigate.
* The GUI will be greatly simplified to something like as on the C64 emulator based on the uGUI lib.
* The disk cat will be similar to frodo, just select and click to start the game, so now keyboard necessary to cat-select-type-and-start a game.
* For code exploration and understanding, I will use Sourcetrail to find and cut the code.
* The GO video and audio skeleton, I will scratch from go-play, it is very clear and straightforward.

Yes, applying the patch to get improved handling on IPC and SPIRAM is necessary, because only the framebuffer will go into DMA internal RAM, everything else goes into SPIRAM. Thank you for suggesting these patches. Btw, Caprice32 for PalmOS has already a nice memory management implemented, easy to map to the SPIRAM space, I think even without using heap_caps_malloc() on the ESP32.

Regards
millim

[ducalex]

Very cool!

By the way you don't need to use heap_caps_malloc (except for DMA), you can tune the behaviour of the memory allocator to also use SPIRAM and you can set a size threshold.

The only thing not accessible by the memory allocator is the upper 4MB of SPIRAM, it needs to be bank switched and it's a pita.

[millim]

Here a short update:

ogo-shell is a very good starting point to manage simulation and the GO together. I have stripped it down to a skeleton starting to implement the emulator. The palmOS version of Caprice is so well architect. So I am basically done with the simulator:



On the GUI, I was not able to find a proper variant that has the 5 way navigation as the central idea. So I was ending up with my own library, I call it ttgui (tiny text gui). It allows only text objects in panels with access/leave/press callers.

Next is to compile it for the GO and launch it.
Keep fingers crossed to get it done - with the limited time I have.

millim

[millim]

Hello Again!

It was a seamless move from the simulator to the real hardware.
Frame rate is not on target. It is not running in dual core mode, yet. Dual buffering is in. Need to setup Video task. Then enable sound, tune speed and implement settings options. Done!

[millim]

Hello Again,

Video and Audio works now. Video Task and Audio Task run on CORE1 now. Still I miss 20% of performance to get it working real time.

- Everything is executed from PSRAM. Caprice requires 400k of RAM, so no way to get it into the internal RAM.
- Two frame buffers require 64k each, located in internal RAM
- Audio 8k, internal RAM
- Compile with -Ofast

Here my question: how can I find out the bottleneck(s) on code execution?
- Is execution profiling with gprof possible?
- Best practice for ESP32?

Any suggestion welcome!

Regards
Ulrich

[millim]

Hi ducalex

The best way to debug an esp32 is through JTAG but that isn't really possible on the GO. The second best way is the monitor with printf and abort/assert. Thankfully the esp-idf documentation is very good and all in one place, it is a joy to work with it.

PS: If you prefer to use the most recent esp-idf instead of crasnhoverride's older 3.2 fork you will have to apply this patch and this patch. 4.0 has much improved event handling and IPC and SPIRAM management and faster builds which might all be useful for porting SDL2.

on your response.

Based on your suggestion, I have tried to move to the latest git repository of idf: ESP-IDF v4.3-dev-1197-g8bc19ba89-dirty. After messing around with the Cmake system, I was able to compile the code. I have applied the patches you mentioned.

With that I am not able to mount the SD-CARD
E (1206) vfs_fat_sdmmc: slot init failed (0x103).

How can this be fixed?

[ducalex]

Your error suggests a configuration problem because that particular error happens before the card is actually initialized.

Ideally you should initialize the SD Card before the display (doing that also makes the second patch unnecessary). Otherwise have a look at this code which is the only one I can confirm works on esp-idf 4.3 at the moment.


By the way if you find a way to get gprof working I'd be very interested too! I had to make a poor man's profiler using instrumentation functions because nothing else would work.

Very impressed by your progress, I am eager to test it out

[millim]

Hi ducalex,

Your error suggests a configuration problem because that particular error happens before the card is actually initialized.

Ideally you should initialize the SD Card before the display (doing that also makes the second patch unnecessary). Otherwise have a look at this code which is the only one I can confirm works on esp-idf 4.3 at the moment.


By the way if you find a way to get gprof working I'd be very interested too! I had to make a poor man's profiler using instrumentation functions because nothing else would work.

Very impressed by your progress, I am eager to test it out

- On the SDCARD issue, I have checked the exampled code of the IDF. There is a slight change on how to use the bus and the host. I have used this as a ref and it is working now. Nonetheless, I have experienced no real difference in performance between the original 3.2 and the actual IDF. I have both now running and can switch. Maybe, I will do the release compiled with the actual IDF.
- The difficult part is Audio. It has to be true real time without glitches, , and Caprice uses about 20% CPU to construct real time audio. I have really underestimated this effort. And there is basically nothing left to press out from the ESP32. Still, it is really a high power micro. Even on my 1.9 GHz Ultrabook, the simulator uses 20% of a single 1.9GHz CPU to run smooth. It scales roughly 1:1. Maybe I bet on the wrong horse by using Caprice Palm version as a reference
- Anyway, I am close, some games work already real time. Still, some cool games like "Orion Prime" require an advanced renderer to fit to 320x200 pixels. I might do on version 2.0.
- Hopefully I can release version 1.0 as a Christmas Present to you all

millim

[millim]

Short update:

I have it now working realtime + audio. Tested already a lot of games. Impressive what the ESP32 can deliver!

I will release a pre-release in the next few days:
- Basic functionality to load and execute games + auto load feature.
- Virtual keyboard

Limitations: (still to lazy to do ..)
- No settings options
- No screenshot
- No pause/resume snapshot
- No OSD support (serial debug output in case)
- No volume control
- No mute

millim

[alektronic]

- Virtual keyboard

Hi and thanks for your work, it is great!

Although a virtual keyboard is useful, I wonder if you would consider allowing custom key mappings for each disk image via an identically-named .ini file, as Schuemi's C64 emulator does?
https://github.com/Schuemi/c64-go

[millim]

- Virtual keyboard

Hi and thanks for your work, it is great!

Although a virtual keyboard is useful, I wonder if you would consider allowing custom key mappings for each disk image via an identically-named .ini file, as Schuemi's C64 emulator does?
https://github.com/Schuemi/c64-go

Well, this is makes sense, I thought about already, can you send me an example for testing?

millim

[alektronic]

Well, this is makes sense, I thought about already, can you send me an example for testing?

An example from TOSEC (and one of my favourites) is:
Roland on the Ropes (1985)(Indescomp - Amsoft).dsk

So...
Roland on the Ropes (1985)(Indescomp - Amsoft).ini might be something like:

Code: Select all

[KEYMAPPING]
UP = KBD_UP
RIGHT = KBD_RIGHT
DOWN = KBD_DOWN
LEFT = KBD_LEFT
SELECT = 4
START = 5
A = KBD_COPY
B = KBD_COPY

Schuemi also implemented the same system for his excellent MSX emulator for the GO : https://github.com/Schuemi/fMSX-go

[millim]

I have it implemented, will upload an update soon, including Bluetooth audio support.

millim