Discuss Mikhail Tkach's InfoNES port

[criznach]

MikeT - what version of InfoNes is this built on?  I thought I'd do some profiling in visual studio to see where the inner loops spend most of their time.

[cool_walking_]

InfoNES v0.97J RC1

Yes, I do have a habit of answering questions addressed to other people.

[Chronon]

It's not the worst habit ever!  

[criznach]

InfoNES v0.97J RC1

Yes, I do have a habit of answering questions addressed to other people.

Thanks!  I guess I couldn't see past all the japanese in the readme...

Funny though, when I build the windows version of .97JRC1 in visual studio, it uses the cpp files.  The rockbox version uses the .c files.  I haven't checked to see if there are differences yet.

I was able to profile the windows version in VC6 and learned a few things.  The sound code eats a lot of processor time.  So I suspect that adding sound for rockbox is going to be a challenge.  Also, the K6502_Read function eats around 25-30% of the cpu just reading opcodes and parameter bytes from ROM.  The windows version runs the emulator in a separate thread.  I'm not sure how or if that would benefit rockbox, but I'll continue to look at it.

[ComposerDude]

Rockboy uses one thread for both sound and graphics emulation; this is because of resource eating. On some targets, the sound is pretty good, on others it's unbearable. This is also the reason why there's an option to turn the sound off in Rockboy, and why disabling sound speeds up the game so dramatically.

I don't know what it would take to write this into InfoNES, but it would certainly make it more compatible with other supported DAPS, if my logic serves correctly.

Enjoy the day, fellow travelers,
ComposerDude

[criznach]

No, no working sound unfortunately.

I downloaded your broken sound files and discovered a few clues...

First, the performance hit from sound isn't as big as I thought, because if I turn on the mute flag to prevent InfoNES_pAPUVsync from being called, the framerate doesn't increase by much.  I guess profiling a windows build of InfoNES isn't going to give me very useful data.

It looks like rockbox's pcm_play_data function is expecting stereo samples, while infones is feeding it mono samples.  So I tried doubling the final buffer and writing each byte twice.  I then pass pcm_play_data samples*2 as it's length parameter.  This makes the sound almost tolerable.  It's still very chunky and not pleasant.  But it sounds a bit more like what I expect  I thought changing the pAPU_QUALITY define and the sample rate would improve the performance, but something isn't right when I do that.

[criznach]

I just noticed that the InfoNES_Wait function is empty in the system_rockbox code.  That normally regulates the frame skipping and times the sound buffers to prevent skipping.  I think implementing that using another platform as a model will even things out.  Look at the windows src for a good example.  On windows the timer runs in the UI thread and the emu thread checks a flag.  On rockbox, we could put the timer in a thread or if there are other benefits, put the emu in another thread.  Looks like multi-core firmware is just about ready to tinker with

MikeT: have you been able to work on the InfoNes lately?

[Chronon]

criznach, please "modify" your posts instead of double posting.

[MikeT]

MikeT: have you been able to work on the InfoNes lately?

I've been wrecking my brains out trying to understand why sim build was acting so strangely. Turns out I forgot rb->yield(). So I've been working on it but haven't got much done.

[criznach]

criznach, please "modify" your posts instead of double posting.

Oops - what did I double post?

[Llorean]

Double posting means not only "posting the same thing twice" but "creating a second post in the thread immediately after another post of your own" and can be avoided by using "Edit" to add new information when nobody else has posted.

Your post will still show up with the (New) tag next to it, and the rule is primarily as part of the rule against bumping posts, but it's easier all around if it's enforced evenly.

[fugot]

could someone make a build for a 30gb 5g ipod so i can test it out?

[cool_walking_]

could someone make a build for a 30gb 5g ipod so i can test it out?

This has a couple of other patches in there because I'm too lazy to remove them. I don't have a 30GB to actually test this on.  I'm an idiot, I'm not responsible when your iPod explodes.. blah blah blah.

[Link removed by Admin: Unsupported builds do not belong here]

[fugot]

im trying to patch my self. i downloaded the source files and in the readme it says "2: add "ines" to $ROCKBOX/apps/plugins/Subdirs" what does that mean?

[nls]

It looks like rockbox's pcm_play_data function is expecting stereo samples, while infones is feeding it mono samples.  So I tried doubling the final buffer and writing each byte twice.  I then pass pcm_play_data samples*2 as it's length parameter.  This makes the sound almost tolerable.  It's still very chunky and not pleasant.  But it sounds a bit more like what I expect

pcm_play_data expects interleaved 16 bit samples so writing each 16 bit word twice should work better.