Homebrew Emulation GameYob, a gameboy emulator for DS

[Joelgp83]

@RocketRobz do you know which source is used to build the version of gameyob that's included in twilight menu?

On a similar vein, 4d1xlaan -- are you able to or have you already put your build's source up somewhere (github, etc.) so that your, er, fork could be tracked for sake of not losing a what's frankly a pretty decent one-off fix to time / dead links?

 

[4d1xlaan]

On a similar vein, 4d1xlaan -- are you able to or have you already put your build's source up somewhere (github, etc.) so that your, er, fork could be tracked for sake of not losing a what's frankly a pretty decent one-off fix to time / dead links?

no point, all you have to do is copy the bios loading code into main function, because the way gameyob does it right now bios loading only happens when you explicitly load a rom from the file chooser

arm9/source/main.cpp:

int main(int argc, char* argv[])
{
    REG_POWERCNT = POWER_ALL & ~(POWER_MATRIX | POWER_3D_CORE); // don't need 3D
    consoleDebugInit(DebugDevice_CONSOLE);

    defaultExceptionHandler();

    time(&rawTime);
    lastRawTime = rawTime;
    timerStart(0, ClockDivider_1024, TIMER_FREQ_1024(1), clockUpdater);

    /* Reset the EZ3in1 if present */
    if (!__dsimode) {
        sysSetCartOwner(BUS_OWNER_ARM9);

        GBA_BUS[0x0000] = 0xF0;
        GBA_BUS[0x1000] = 0xF0;
    }

    fifoSetValue32Handler(FIFO_USER_02, fifoValue32Handler, NULL);

    sharedData = (SharedData*)memUncached(malloc(sizeof(SharedData)));
    sharedData->scalingOn = false;
    sharedData->enableSleepMode = true;
    // It might make more sense to use "fifoSendAddress" here.
    // However there may have been something wrong with it in dsi mode.
    fifoSendValue32(FIFO_USER_03, ((u32)sharedData)&0x00ffffff);

    initInput();
    setMenuDefaults();
    readConfigFile();
    swiWaitForVBlank();
    swiWaitForVBlank();
    // initGFX is called in initializeGameboy, but I also call it from here to
    // set up the vblank handler asap.
    initGFX();

    consoleInitialized = false;

    if (argc >= 2) {
        char* filename = argv[1];

        if (!biosExists) {
            FILE* file;
            file = fopen("/_nds/TWiLightMenu/emulators/gbc_bios.bin", "rb");
            biosExists = file != NULL;
            if (biosExists) {
                fread(bios, 1, 0x900, file);
                fclose(file);
            }
        }

        loadRom(filename);
        updateScreens();
        initializeGameboyFirstTime();
    }
    else {
        selectRom();
    }

    runEmul();

    return 0;
}

a cleaner way to do this would be to put bios loading code into a separate function, and just call the function in both places instead of duplicating the code (or maybe do bios loading in loadRom() if possible?), but duplicating the code here was easier and the end result is the same. I would bet that compiler optimization recognizes it and makes up for it anyway

 

[Joelgp83]

no point, all you have to do is copy the bios loading code into main function, because the way gameyob does it right now bios loading only happens when you explicitly load a rom from the file chooser

Well, fair enough if its so trivial a fork would be overkill. Out of curiousity, would just making a (forgive me if I've got the github terminology wrong), pull request with the changes to the main repo would be more appropriate for this sort of thing?

 

[4d1xlaan]

Well, fair enough if its so trivial a fork would be overkill. Out of curiousity, would just making a (forgive me if I've got the github terminology wrong), pull request with the changes to the main repo would be more appropriate for this sort of thing?

probably, but then you would have to choose between submitting it to the original gameyob, gameyob mavica, or ds-homebrew fork (I suspect this is what twilightmenu uses, but without confirmation I can't be sure)

I can't say I'm interested in using github and making a pull request, but this isn't my code anyway. if anyone wants to implement it or make a pull request themselves then they are welcome to

btw: do you have the same problems using the official 0.5.2 build? because it's also possible that my build environment is bad and that my build is bad because of it

https://github.com/Stewmath/GameYob/releases/download/v0.5.2/gameyob.zip

I wasn't able to find Infinity which you mentioned, all I can find is some 2001 proto and I don't know if that's the right one considering that the one you mentioned came out in recent years

 

[Joelgp83]

probably, but then you would have to choose between submitting it to the original gameyob, gameyob mavica, or ds-homebrew fork (I suspect this is what twilightmenu uses, but without confirmation I can't be sure)

I can't say I'm interested in using github and making a pull request, but this isn't my code anyway. if anyone wants to implement it or make a pull request themselves then they are welcome to

btw: do you have the same problems using the official 0.5.2 build? because it's also possible that my build environment is bad and that my build is bad because of it

https://github.com/Stewmath/GameYob/releases/download/v0.5.2/gameyob.zip

I wasn't able to find Infinity which you mentioned, all I can find is some 2001 proto and I don't know if that's the right one considering that the one you mentioned came out in recent years

The Infinity I'm talking about is the one that came out recently, and does exist as either a bespoke gbc cart or a gb rom you can buy/download from them.

Admittedly I haven't checked against the official 0.5.2 build. I'll try it out when I find time

 

[Joelgp83]

btw: do you have the same problems using the official 0.5.2 build? because it's also possible that my build environment is bad and that my build is bad because of it

Alright, so just tested the official 0.5.2 build, seems the sound timing issues are not there compared to your build. This is being done with Wait for Vblank set to off -- on your build, setting it on seems to introduce some extra throttling that seems to keep the sound speed in check at the cost of some games being too slow with it on sometimes. So I'd say yeah, something changed between the official build and what you've done.

 

[4d1xlaan]

Alright, so just tested the official 0.5.2 build, seems the sound timing issues are not there compared to your build. This is being done with Wait for Vblank set to off -- on your build, setting it on seems to introduce some extra throttling that seems to keep the sound speed in check at the cost of some games being too slow with it on sometimes. So I'd say yeah, something changed between the official build and what you've done.

yeah, the code is the same, the only thing that's different would be build environment. unfortunately that's very difficult to debug, and drenn didn't give documentation to know which exact version of every build tool that was used to build gameyob so I'm kind of working blind here

 

[RocketRobz]

@RocketRobz do you know which source is used to build the version of gameyob that's included in twilight menu?

I forgot which one was used.
Also, if you're wanting to send a PR, send it to the DS-Homebrew fork.

 

[Joelgp83]

I forgot which one was used.
Also, if you're wanting to send a PR, send it to the DS-Homebrew fork.

Oh, Hi there RocketRobz! Two things:

1.) Just wanted to say thanks for Twilightmenu, I've gotten a heck of a kick out of it on my DS Phat. I've gotten more mileage out of my DS in the past two years than I did in the past decade, so kudos.

2.) The fork on DS-homebrew seems to be a fork of the Mavica build, which itself seems behind compared to whatever build you've included on twilight menu, since the mavica build has graphical glitches (i.e., flat shaded with bad outer lines instead of the gradient seen on real HW) in rendering the text boxes in Infinity, and whatever's included in current twilightmenu does alot better (the gradient is there, but coloring seems slightly off). Granted, nitpicking, but it was a relatively big difference I noticed when attempting to decide what build to, uh, "daily drive" for my GB/GBC on DS needs.

 

[4d1xlaan]

the gameyob.nds in twilightmenu is from october 2020, so it cant be that new to be fair

 

[Joelgp83]

the gameyob.nds in twilightmenu is from october 2020, so it cant be that new to be fair

Well, that's weird, as the timestamps for gameyob in the twilightmenu archive (this is before extraction) are showing from this year (sept 2024). I'm curious where you are looking to have got a date from oct 2020. Not trying to argue, just trying to get on teh same page in case I'm wildly off base here.

 

[4d1xlaan]

Well, that's weird, as the timestamps for gameyob in the twilightmenu archive (this is before extraction) are showing from this year (sept 2024). I'm curious where you are looking to have got a date from oct 2020. Not trying to argue, just trying to get on teh same page in case I'm wildly off base here.

it's normal that the time stamp in the archive will be different, the way they're making the archive touches the files in a way where the os thinks the file was modified, so the files end up being all a similar time stamp (by a matter of seconds)

this is what you're looking for, and if you compare the checksums, this is the same file that's in the release archives

https://github.com/DS-Homebrew/TWiL...zfile/_nds/TWiLightMenu/emulators/gameyob.nds

I mixed up the dates btw, october 2020 is the 0.5.2 official release being reuploaded (which was originally from feb 2017). twilightmenu has something from may 2020 but we dont know what source was used to build it, all I know is that it's different from the 0.5.2 release

 

[Dragon_Types]

Is this still the best GB emu for DS?

 

[retro_tastic]

Does anyone know what is the total input lag and sound latency of GameYob when compared to the original Game Boy Color hardware? Do you play rhythm games on it? Nintendo DS seems to be pretty baremetal, I guess the best scenario would be "scaling off" and using the DSi CPU speed?