Author Topic: New Arnold port for Trimui Model S and Miyoo based Handhelds  (Read 361 times)

0 Members and 1 Guest are viewing this topic.

Offline Liartes

  • CPC664
  • ***
  • Posts: 52
  • Country: fr
  • Liked: 24
  • Likes Given: 13
Hi,
I ported Arnold for GX4000 gameplay on the Trimui Model S (aka Powkiddy A66)
You can checkout the sources and download the release zip here : https://github.com/liartes/arnold_gcw0
An enthusiast developer ported this build to the Miyoo based devices, sources and release zip here : https://github.com/salvacam/arnold_gcw0
There is some issues with sound that I am currently trying to fix, and I would love to implement a zoom but the learning curve is steep for a Java developer  ;D
I mentionned the GX4000 converted game repositories in my release note, I hope it is OK. Let me know if I must remove it.

Offline eto

  • Supporter
  • 464 Plus
  • *
  • Posts: 371
  • Country: de
  • Liked: 226
  • Likes Given: 220
Nice... I didn't even know about this device. Maybe you can share a bit more about your experience with it and if it's worth a recommendation.

Offline Aeliss

  • CPC464
  • **
  • Posts: 30
  • Country: fr
  • Liked: 14
  • Likes Given: 9
Hello, I have do same, and use something for the sound. The emulator use a precise timing, and the "sound playing core" on modern hardware is not compatible, frequency compatibilities problems. So I have modified the code to synchronise the emulator on the "sound playing core" instead of using the "cpc timing", it s less accurate, but less problem with sound.   

You have the complete code here https://www.cpcwiki.eu/forum/emulators/another-version-of-arnold-emulator/ in the file arnold.cpp   

To resume I wait for the Cycles>=19968 AND a sound buffer filled enought, if the buffer is not perfect I wait for some more cycles.   

And BTW, the device seem realy nice, do you have video on arnold running on it ?
« Last Edit: 18:31, 20 June 21 by Aeliss »

Offline Liartes

  • CPC664
  • ***
  • Posts: 52
  • Country: fr
  • Liked: 24
  • Likes Given: 13
Thanks for the hint about the sound issue ! After much tinkering, I get the best result tonight by modifying the frequency constant in audioevent.c from 50.8 to 50 frames per second.this value is used to dimension the sound buffer and I experienced no more echoes / ghosting in Fruity Frank, but still in Commando or Switchblade. I will dive into your source code tomorrow  :D .


About the device, you must be warned : the screen is small (2 inches) and games lisibility may vary.
The build quality is good, buttons and D-pad are flat switches (feels similar to Gameboy Advance Sp) with a satisfying clicky sound when pressed, and perfect for 8 bits clicky-buttons era games.


At the moment I spend more time developing than playing, but I would recommend it to someone who can accomodate the very little screen. Not as a main handheld console, but as a pocketable thing you can bring anywhere and grab for killing time.


I didn't have a video to share right now, sorry. Games I tested are running fullspeed.

Offline Liartes

  • CPC664
  • ***
  • Posts: 52
  • Country: fr
  • Liked: 24
  • Likes Given: 13
The code is completely different, I can't figure out (yet !) how to pickup your fix without rewriting a lot of things right now.
« Last Edit: 18:18, 21 June 21 by Liartes »

Offline Aeliss

  • CPC464
  • **
  • Posts: 30
  • Country: fr
  • Liked: 14
  • Likes Given: 9
Ha yes 2 inches ... less than the gameboy, not terrible.   

The arnold core Im using is a recent version gived by arnoldemu (but 2/3 year old at least ^^), but more recent than the version you can find.   
The other part is specific to windows, I don't remember all the reason, but to explain my code   

The hardware sound engine have a frequency = 44100 Hz with 4 Bytes per sample
The Display have a 50 Hz frequency, we have 64 * 39 * 8 = 19 968  Nops per seconds (Nops by frame * Frequency)   
We need 44100 / 50 = 882 samples per screen refresh   
We need 882 / 19968 = 0.044120.... sample per nops   The sound buffer size = 0.044120 *4 * 19968 = 3524 Bytes.   

But values are not "whole". If you debug around the code that check cycles   

Code: [Select]
        while (Cycles <19968)        {        }   

On your code it's around here   

Code: [Select]
        /* nop counter is used to define when we render the whole display */
        if (LocalNopCountToDate<=0)       
        {
   

You will see you have sometime the sound buffer with 3528 data, sometime with 3524, not possible having something fixe, So have used this kind of hack   
Code: [Select]
        while ( ((Cycles <19968) && (!Hack_Synchrosound)) || ((GetLenghtBuff() < 3528) && (Hack_Synchrosound)) )
        //while (Cycles <19968)
        {
            int NopCount;

            /* execute the instruction */
            NopCount = CPU_ExecuteCycles();

            if (NopCount==0) break;

            if (BoostZ80 > 0)
            {
                /* Accumulate the Nop counts */
                NopCountAcc += NopCount;
                /* See if we accumulated enough */
I can use core synchronisation with (Cycles <19968) or sound buffer synchronisation with (GetLenghtBuff() < 3528)   

It s in the arnol.cpp file in the win folder. All file in "cpc" folder are "native", all modified file are in the folder "cpc_modified", and all in "win" folder are specific to windows.     
On your side you just need to use a fonction that calculate sound buffer size already filled, and use this value instead of counting nop.
« Last Edit: 23:20, 23 June 21 by Aeliss »

Offline Liartes

  • CPC664
  • ***
  • Posts: 52
  • Country: fr
  • Liked: 24
  • Likes Given: 13
Thanks for the explanation, I understand a bit more what is happening with this sound buffer now  :D
I made another release using the Cycles control and it is a bit better, I will give another try to the buffersize solution in the light of what you shared here.