Printed Amstrad Addict magazine announced, check it out here!

Main Menu

New Arnold port for Trimui Model S and Miyoo based Handhelds

Started by Liartes, 09:54, 20 June 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


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 :
An enthusiast developer ported this build to the Miyoo based devices, sources and release zip here :
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.


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.


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 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 ?


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.


The code is completely different, I can't figure out (yet !) how to pickup your fix without rewriting a lot of things right now.


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   

        while (Cycles <19968)        {        }   

On your code it's around here   

        /* 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   
        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.


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.

Powered by SMFPacks Menu Editor Mod