Homebrew [Release] Bread Box (C64 Emulator)

  • Thread starter Thread starter spinal_cord
  • Start date Start date
  • Views Views 105,054
  • Replies Replies 450
  • Likes Likes 46
You guys can download the latest build and source below (also in the first post once i edit it).

I changed the file loading a little. Now it will automatically list the files on the .d64 when you select it.
To load a game, HOLD 'R' and tap the d-pad UP/DOWN until the cursor is on the line with the filename you want to load, then, while still holding 'R', hit 'A'.

As you can hear, the sound is terrible. If anyone has a clue why it sounds like that please let me know. At this point I don't know if it's a C64 issue or a 3DS issue. If anyone can tell from listening what might be the cause of the symptoms PM me or something :-)
 

Attachments

  • Like
Reactions: SLiV3R
If anyone is any good at audio on the 3DS, I probably need some pointers.

Code:
    sound_calc_buf = (int16*)linearAlloc(SAMPLE_BUF_SIZE);

    csndPlaySound(8, SOUND_FORMAT_16BIT | SOUND_REPEAT, SAMPLE_FREQ, 1, 0, sound_calc_buf, sound_calc_buf, SAMPLE_BUF_SIZE);

Is the above the correct way to set a sample repeating?
I'm getting awful distortion.

It's correct. The only thing to check is the buffer size related to the buffer filling callback function frequency. It's very related to emulator fps, with a fixed FPS it's easy to tune everything, but with a variable FPS you'll never get a good result.

For the resulting ugly sound (if we assume to have a steady FPS) here are some of my experiences with some emulators:
  • the code you're using for CSOUND is expecting 16 bit signed samples, but sometimes an emulator can produce unsigned samples, that interpreted as signed produce a fast bumping sound. In this case you have to convert the samples.
  • in my experience it's better to use a buffer size 4x the audio lenght you expect to play in a frame.
  • you could try to overfill a little (10%) on the first frame the buffer to handle small glitches, but the result depends on how the emulator produces samples. If the emulator can't anticipate samples and use 0 values to handle extra requestes, this is not a good idea.
  • to fill the buffer you have to use a pointer to the next filling position that have to be updated by a costant value every frame (assuming the framerate is constant). Remember to handle the reach of the end of the buffer so to reset the position handle to the beginning of the buffer
  • check if the number of samples per frame is an integer or there is the risk of losing some fraction of samples every frame, going out of sync (with possible audio deterioration) after few seconds.
  • when you start a loop remember that the sound start always from the first position of the buffer. So if you pause the audio, befor restarting it you have to move the samples, already loaded in the buffer but not played, to the beginning of the buffer and update the position of the buffer index at the and of this chunk of samples. For a simpler solution you can discard all the loaded samples and reset everything as you where loading the audio samples of the first frame. But check that this doesn't produce problems on audio quality.

Hope this helps your work.
 
Last edited by nop90,
  • Like
Reactions: SLiV3R
You guys can download the latest build and source below (also in the first post once i edit it).

I changed the file loading a little. Now it will automatically list the files on the .d64 when you select it.
To load a game, HOLD 'R' and tap the d-pad UP/DOWN until the cursor is on the line with the filename you want to load, then, while still holding 'R', hit 'A'.

As you can hear, the sound is terrible. If anyone has a clue why it sounds like that please let me know. At this point I don't know if it's a C64 issue or a 3DS issue. If anyone can tell from listening what might be the cause of the symptoms PM me or something :-)

I can't tell if this is the exploit or if it is the emulator, but... well, this:



It happens after I quit breadbox and try to load another app.
 
Yes to both of them! For the lower screen switch off. I guess you can simply copy the code from handy3ds or some other emulator that has that function!

For the sound, I currently have no idea what the problem is. It's a bit crackly on the lower pitches and generals a bit fuzzy. I've looked at the SID emulation code, can't make much of it, but it seems to be following nop90's advice pretty closely already. I've even looked at other ports of frodo and there's nothing much different at all with the SID stuff, so I can't think what the problem might be.

I'm thinking of redoing the gui completely. Not 100% sure what I intend to do, but I want to do something to it.
 
  • Like
Reactions: SLiV3R
I just did a quick test, dropping the audio into a file on the SD while the emulator was running and guess what, it sounds perfect, if a little slow (probably because the emu slowed down) so the audio problem lies entirely on the 3DS side of things, not the SID emulation!

No idea where to go from here.
 
  • Like
Reactions: SLiV3R
I just did a quick test, dropping the audio into a file on the SD while the emulator was running and guess what, it sounds perfect, if a little slow (probably because the emu slowed down) so the audio problem lies entirely on the 3DS side of things, not the SID emulation!

No idea where to go from here.
port dont flip out. do it. pleaseeeeeeeeeeeeeee
 
I just did a quick test, dropping the audio into a file on the SD while the emulator was running and guess what, it sounds perfect, if a little slow (probably because the emu slowed down) so the audio problem lies entirely on the 3DS side of things, not the SID emulation!

No idea where to go from here.

This means that the data stream is correct but the CSND service reads the data faster than the emulator can fill the buffer.

If this happens the stream ends the available new samples and starts reading the old samples written in the buffer at the previous round, than the buffer is filled again ahead of the reading point.

This result in a fast sound glitch with the same frequency of the video FPS.

It's unavoidable if the FPS is low (leaving a constant audio frequency). Modulating frequency can be worst if it change too often (I tryed it with handy3DS).
 
  • Like
Reactions: SLiV3R
This means that the data stream is correct but the CSND service reads the data faster than the emulator can fill the buffer.

If this happens the stream ends the available new samples and starts reading the old samples written in the buffer at the previous round, than the buffer is filled again ahead of the reading point.

This result in a fast sound glitch with the same frequency of the video FPS.

It's unavoidable if the FPS is low (leaving a constant audio frequency). Modulating frequency can be worst if it change too often (I tryed it with handy3DS).

I have the fps at a constant 50 with a frameskip, and it never dips below 45 without frameskip.
 
I have the fps at a constant 50 with a frameskip, and it never dips below 45 without frameskip.

Do you fill the sound just buffer before limiting the FPS with svcSleepThread()?

If you fill the buffer after the limiter, that's the problem.

--------------------- MERGED ---------------------------

And you also have to check that you start the loop only after filling the samples for the first frame.
 
Do you fill the sound just buffer before limiting the FPS with svcSleepThread()?

If you fill the buffer after the limiter, that's the problem.

--------------------- MERGED ---------------------------

And you also have to check that you start the loop only after filling the samples for the first frame.

I had this issue from the beginning, before limiting the fps, which i'm doing the following way --
Code:
    if(draw_frame) { 
        TheDisplay->Update();
    }
    uint32 tim2 = svcGetSystemTick();
    while(tim2 < tim){tim2 = svcGetSystemTick();}
    tim = svcGetSystemTick() + (TICKS_PER_SEC/50);
 
I had this issue from the beginning, before limiting the fps, which i'm doing the following way --
Code:
    if(draw_frame) {
        TheDisplay->Update();
    }
    uint32 tim2 = svcGetSystemTick();
    while(tim2 < tim){tim2 = svcGetSystemTick();}
    tim = svcGetSystemTick() + (TICKS_PER_SEC/50);

For a correct timing here is how I will do it:

Code:
    if(draw_frame) {
        TheDisplay->Update();
    }
    if (svcGetSystemTick() < tim) {
        ... // fill here the sound buffer with enough samples for the next frame.
        while(svcGetSystemTick() < tim);
        tim +=  (TICKS_PER_SEC/50);
    } else { // a lag happened
        ... // handle here the sound buffer adjustment for the lag, then fill in the samples for the next frame. 
        tim = svcGetSystemTick() +  (TICKS_PER_SEC/50); 
    }

    ... // if the sound loop is stopped, start it now!

A while loop is good for limiting the speed, but remember that it uses all the CPU resources not allowing other threads to run in parallel.

This probably isn't a problem for your code, but in a multithread program it's better to use svcSleepThread().
 
  • Like
Reactions: SLiV3R
I'll give that a shot.
In the meantime, a couple of test have revealed the the audio file that is being saved is exactly 25% of full speed. Could this be a clue to fixing it?
 
Last edited by spinal_cord,
Can't say. It could be some kind of bad casting of the variables used for the samples (can't say if in the emulator or while saving).

Or you could simly Try useing 1/4 of the sound frequency
I'll give that a shot.
In the meantime, a couple of test have revealed the the audio file that is being saved is exactly 25% of full speed. Could this be a clue to fixing it?

Don't know. It could be some kind of bad casting of the variables used for the samples (can't say if in the emulator or while saving).

Or you could simply try using 1/4 of the sound frequency.
 
@spinal_cord, Sorry to go off-topic, but I was thinking about your 3D slider-based scrolling and wondered: what are 2DS users expected to do? (I don't have one personally to check, was just curious.)
I've removed that for now. It wasn't much use for 99% of games anyway.
 
  • Like
Reactions: Vague Rant

Site & Scene News

Popular threads in this forum