Hacking TempGBA: NDSGBA revival

[nitendo]

#if defined SERIAL_TRACE || defined SERIAL_TRACE_SOUND
    serial_timestamp_printf("In sound loop");
#endif
 
    do
        audio_buff = ds2_getAudiobuff();
    while (audio_buff == NULL);
 
#if defined SERIAL_TRACE || defined SERIAL_TRACE_SOUND
    serial_timestamp_printf("Out of sound loop");
#endif

What would happen to the emulation if the loop is exited with the variable audio_buff = NULL - would it cause a crash?

// Try a thousand times - then give up
int i = 0;
do
audio_buff = ds2_getAudiobuff();
while ((audio_buff == NULL) && (i++ < 1000));

/dACE

 

[BassAceGold]

If a NULL buffer is returned, it's looping infinitely probably since the buffers aren't flushed until ds2_updateAudio() is called to do so. If need be, you could try using the 0.13 sdk which has the 16 audio buffers to see if it works any better. Chances are you wouldn't be able to fill all 16 buffers at once. Or you could try calling a ds2_updateAudio when a null buffer is detected and then try again to grab an empty one.

 

[d.d.d.]

But, but...

I second this.
I use 0 on games that can handle it and when the games can, it's very, very nice.
If it's mainly just Mario Tennis, well, make a note of it in the read me or just disable it for the title IDs for the versions of Mario Tennis (if that's possible).

 

[Aeter]

I second this.
I use 0 on games that can handle it and when the games can, it's very, very nice.
If it's mainly just Mario Tennis, well, make a note of it in the read me or just disable it for the title IDs for the versions of Mario Tennis (if that's possible).

You can always use v1.42 for FS 0.

 

[Deleted member 319809]

I second this.
I use 0 on games that can handle it and when the games can, it's very, very nice.
If it's mainly just Mario Tennis, well, make a note of it in the read me or just disable it for the title IDs for the versions of Mario Tennis (if that's possible).

It's actually all games except really simple ones to emulate, like Bomberman Tournament and Super Mario Advance games (though Super Mario Advance: Yoshi's Island freezes at random places for some people, so I'm hesitant to call even that one easy). All other games are prone to freezing at equally random places at 0 frameskip so far. Mario Tennis is just faster to get a freeze in.

What would happen to the emulation if the loop is exited with the variable audio_buff = NULL - would it cause a crash?

It would cause a TLB load exception after the code attempts to write to the newly-acquired NULL buffer, which would -- instead of freezing the game -- show a Guru Meditation screen that would make the emulator equally unusable.

// Try a thousand times - then give up
int i = 0;
do
audio_buff = ds2_getAudiobuff();
while ((audio_buff == NULL) && (i++ < 1000));

/dACE

Here's what I tried in the next commit:

    audio_buff = ds2_getAudiobuff();
    if (audio_buff == NULL) {
#if defined SERIAL_TRACE || defined SERIAL_TRACE_SOUND
        serial_timestamp_printf("Recovered from the lack of a buffer");
#endif
        return -1;
    }

It would quit the sound_update function and enter it again later as part of the emulation loop. I tried that, but it is forever NULL if it is NULL once at 0 frameskip. At 1 frameskip it is NULL once, then the emulation loop does recover.

If a NULL buffer is returned, it's looping infinitely probably since the buffers aren't flushed until ds2_updateAudio() is called to do so. If need be, you could try using the 0.13 sdk which has the 16 audio buffers to see if it works any better. Chances are you wouldn't be able to fill all 16 buffers at once. Or you could try calling a ds2_updateAudio when a null buffer is detected and then try again to grab an empty one.

I'll try that later today in the code above, even though I don't think it will work that well.

 

[Prof. 9]

This is probably a really roundabout solution, but how about creating a save state when it looks like you're stuck in the NULL loop?

 

[Deleted member 319809]

This is probably a really roundabout solution, but how about creating a save state when it looks like you're stuck in the NULL loop?

The DSTwo may be in an inconsistent state that doesn't allow it to do that.

When ds2_getAudiobuff() returns NULL after the 2nd retry of sound_update, the following things happen:
* the serial line continues outputting properly;
* the game continues running, not accepting any input from the B, A, Start, Select, L, R, X and Y DS buttons (not sure about the Touch Screen and d-pad, see below);
* images and sound output, which are driven by interrupts and DMA, are forcibly stopped;
* the recompiler continues running, and on the serial line, I can see "Clearing IWRAM metadata: Last tag reached" every so often;
* touching the Touch Screen stops the game and enters the menu, which does not display -- thereafter, any input to exit the menu is ignored (because at least the input from the B key is ignored).

My guesses are as follows:
* Some kind of race condition occurs on the MIPS when there's a transition between "there is at least one buffer of audio left to send" and "we have run out of sound data to be sent" -- which manifests when the FPS needs to drop -- and the sound channel disables all the rest;
* The interrupt handler for the DSTwo-to-DS transfer on the MIPS is not re-entrant, and entering it twice disables interrupts;
* Some kind of race condition occurs on the DS when there's a transition between "there is no audio for now" and "we are preparing to receive audio".

The red ones would disallow writing to the SD card, which is an MMC interrupt on the MIPS.

The following cannot happen:
* The interrupt handler for the DSTwo-to-DS transfer on the DS is not re-entrant, and entering it twice disables interrupts. This cannot happen because the Touch Screen works to enter the menu (exactly once), and it's an interrupt.

 

[Deleted member 319809]

If a NULL buffer is returned, it's looping infinitely probably since the buffers aren't flushed until ds2_updateAudio() is called to do so. If need be, you could try using the 0.13 sdk which has the 16 audio buffers to see if it works any better. Chances are you wouldn't be able to fill all 16 buffers at once. Or you could try calling a ds2_updateAudio when a null buffer is detected and then try again to grab an empty one.

That didn't work. It worked for about 1190 seconds, after which there was an endless loop of retries once more.

As I wrote on the CATSFC thread, I'll not use the 0.13 SDK, because that one tears the screen so much and has input press/release latency problems. Unless you meant that I should try 0.13 to see if they fixed the sound, so that I can merge both the sound of 0.13 and the rest of 0.12? (In which case, 0.13 needs the ds_firmware.dat of 0.13, and could not transmit sound properly to the DS-side code of 0.12)

 

[masterz87]

OK I'm going to try your more recent ones, i got multiple issues, tried to repeat but different crashes in different ways so it might by that random one that you talked about. Because when it froze it just kept giving no sounds(sound was on at that time) so I'll try the newer ones. I hope you can get it all working, it sounds like a clusterfuck, so best of luck to you.

 

[Rinnux]

Since we have the source codes, would it be possible to add a full screen option? Sorry if this has already been asked.

 

[Hanafuda]

Since we have the source codes, would it be possible to add a full screen option? Sorry if this has already been asked.

If you look over the last few pages, it looks like Nebuleon's got his hands full with a more fundamental and important issue right now. Not saying it isn't worth asking about, just that you probably shouldn't expect much action or discussion on it for the time being.

 

[Deleted member 319809]

If you look over the last few pages, it looks like Nebuleon's got his hands full with a more fundamental and important issue right now. Not saying it isn't worth asking about, just that you probably shouldn't expect much action or discussion on it for the time being.

I tried a few things already, but the next step was to install an old version of devkitARM on Windows and look at the lower-level code that drives the GPIOs and interrupts on both the MIPS and DS sides. As it turns out, I'm not really interested in that. I also have little time.

I'd also like to say that the full-screen option depends upon the audio stuff. As long as having lots of processing causes audio underflows to freeze the DSTwo, I don't want to add more processing -- having something that freezes even more than now is not an option to me. Frameskip 0 causes lots of processing, and so would frameskip 1/2 + full-screen. This did not happen in CATSFC, however, which makes it all the more suspicious.

Perhaps I will get more clues about the audio stuff, or someone else can take over about it.

 

[Canadacdn]

I know you're busy right now, but do you think you'd be able to add a feature to adjust the level of gamma correction? It would help make a lot of overly bright GBA games look much better on the 3DS.

 

[Deleted member 319809]

I know you're busy right now, but do you think you'd be able to add a feature to adjust the level of gamma correction? It would help make a lot of overly bright GBA games look much better on the 3DS.

I thought about that. But alas, too much processing.

Edit: To elaborate a little on what that means, and beause I usually provide technical explanations for things:

The JZ4740 does not do hardware floating-point calculations, which are required for accelerating calculations made between real, non-integer numbers (x ∈ ℝ, x ∉ ℕ ∀ x). While simple multiplication can be emulated with fixed-point integer arithmetic -- this is done in gpSP's sound frequency calculations --, gamma correction is an exponential function, which can't be emulated this way as efficiently. The result is either 38400 software floating-point calculations per frame (would cause a large slowdown) or a 128 KiB lookup table kept in memory and calculated at startup.

While it would be efficient, calculation-wise, to simply use the last line of graphics written (still in the data cache -- big win, right?) as well as a lookup table, reading the lookup table would push that line of graphics out of the cache and into it again repeatedly to make way for the lookup table, destroying the advantage of having the cache and most likely slowing down the algorithm by 50%+.

Again, given that the audio crackles and freezes the DSTwo if there's too much processing, I don't want to add any more.

 

[Normmatt]

I thought about that. But alas, too much processing.

Edit: To elaborate a little on what that means, and beause I usually provide technical explanations for things:

The JZ4740 does not do hardware floating-point calculations, which are required for accelerating calculations made between real, non-integer numbers (x ∈ ℝ, x ∉ ℕ ∀ x). While simple multiplication can be emulated with fixed-point integer arithmetic -- this is done in gpSP's sound frequency calculations --, gamma correction is an exponential function, which can't be emulated this way as efficiently. The result is either 38400 software floating-point calculations per frame (would cause a large slowdown) or a 128 KiB lookup table kept in memory and calculated at startup.

While it would be efficient, calculation-wise, to simply use the last line of graphics written (still in the data cache -- big win, right?) as well as a lookup table, reading the lookup table would push that line of graphics out of the cache and into it again repeatedly to make way for the lookup table, destroying the advantage of having the cache and most likely slowing down the algorithm by 50%+.

Again, given that the audio crackles and freezes the DSTwo if there's too much processing, I don't want to add any more.

You could just modify the palette when its updated. Even if games spam palette rights it shouldn't effect speed much if your only adding say another load and a division to each palette write.

 

[Deleted member 319809]

You could just modify the palette when its updated. Even if games spam palette rights it shouldn't effect speed much if your only adding say another load and a division to each palette write.

Can a GBA read back its palette and act on it? Say, fade it in/out based on how much it has faded out already. If yes, the palette would have to be doubled, wouldn't it?

u16 palette[n];
u16 correctedPalette[n];

Also, where in video.c is the palette handled? I can't read that file for shit.

 

[DiabloStorm]

So...not sure why but switching my games and saves over to tempgba erased my saves, or, save rather... -.- Loaded it up, ran a game, looked for my save, nothing there, open sd on my pc, suddenly the .sav file has been overwritten (???) run on my ds, still no save file showing in game in spite of one clearly being there on my sd. Circle of the moon btw.

 

[Deleted member 319809]

So...not sure why but switching my games and saves over to tempgba erased my saves, or, save rather... -.- Loaded it up, ran a game, looked for my save, nothing there, open sd on my pc, suddenly the .sav file has been overwritten (???) run on my ds, still no save file showing in game in spite of one clearly being there on my sd. Circle of the moon btw.

What was the procedure you followed?

 

[DiabloStorm]

What was the procedure you followed?

Well, I basically just moved the files on my sd to a new location under tempgba folders. =\ (So "gamepak" to "GAMES" etc) I was under the impression they (the saves, not save states)were compatible (I think I remember asking), I was using 1.30 previously. Then I attempted to run the game I had a save for, and no saves appeared in-game. The rest you already know I didn't get past the save selection screen so I have no idea how or why it would overwrite a save I had sitting in the folder. (save file said modified on current date when I went back into SD to check the location)

 

[Deleted member 319809]

Well, I basically just moved the files on my sd to a new location under tempgba folders. =\ (So "gamepak" to "GAMES" etc) I was under the impression they (the saves, not save states)were compatible (I think I remember asking), I was using 1.30 previously. Then I attempted to run the game I had a save for, and no saves appeared in-game. The rest you already know I didn't get past the save selection screen so I have no idea how or why it would overwrite a save I had sitting in the folder. (save file said modified on current date when I went back into SD to check the location)

They're compatible, but you used 1.30, not 1.21. The difference is that a few games have declarations for save types and sizes in game_config.txt.

1.21 supported game_config.txt but not 1.30, and now TempGBA supports it again. It is possible that, for the 128 KiB flash saves and the 512 byte EEPROM saves, some games behave oddly.

I don't know if you changed anything after moving the files. So as usual, make sure your .sav has the name of the ROM you put into /TEMPGBA/GAMES exactly, minus .gba or .zip, plus .sav; that the .sav file of the correct name is in /TEMPGBA/SAVES; that your card is properly formatted with the Panasonic SD Formatter and its size adjustment option, etc.