Jump to content



1

Fixing known bugs in Handy emulator


58 replies to this topic

#51 LX.NET OFFLINE  

LX.NET

    Star Raider

  • 78 posts

Posted Sun Mar 25, 2012 3:22 PM

View Posttwipley, on Sat Mar 24, 2012 3:52 PM, said:

Would it be feasible (and motivating) for you LX to provide a patch for the crackling audio to be fixed?

http://sourceforge.n...313&atid=640866 -- just to know your thoughts about that.

Hi Twipley,

Yes, motivating/motivated pretty much so.
This is one of my outstanding points of improvement to the emulator. Handy is built using a circular audio buffer, and I think that hickups in the emulation speed might be causing the buffer (0,25 seconds) to either be overrun or underrun. I use a reasonably similar method and experience the same thing.

I have heard that mednafen runs the audio perfectly. Can anyone confirm that? If so, I'll give it a spin and check out the source code.

#52 sage OFFLINE  

sage

    Moonsweeper

  • 391 posts
  • Location:Germany

Posted Mon Mar 26, 2012 2:11 PM

View PostLX.NET, on Sun Mar 25, 2012 3:22 PM, said:


I have heard that mednafen runs the audio perfectly. Can anyone confirm that?

yes!

#53 GadgetUK OFFLINE  

GadgetUK

    Star Raider

  • 72 posts

Posted Tue Mar 27, 2012 4:07 PM

I am very interested in this from both a Lynx development point of view, and porting the fixes back into the GP2X version of Handy. There's a guy who ported it over to the GP2X from Handy sources a few years back and that version exhibits the problems you've addressed so far. The problem at the moment is I cannot get hold of the author and he never made the source open - ironic as it was open source to start with... Anyway, I will progress with the issues you've raised and fixed and try and get the GP2X version of Handy updated. The GP2X is a linux based handheld btw - i've developed a few games on it myself previously as well as bits and bobs on other platforms - wrote a NES emulator which has a 6502 CPU - I think the same as the Lynx, it's been a while since I looked at the 6502, from what I remember it was 8bit with 16bit addressing which fits with the Atari CPU spec ive seen (65SC02 - not sure what the SC code means).

Moving forward I am looking at getting an SDK, and possibly a Lynx flashcard (might be hard, seem to be next to none around) and developing some games for the Lynx. Keep up the good work, it's nice to see that some one has passion and enthusiasm for the Lynx - keeping it alive!!

#54 GadgetUK OFFLINE  

GadgetUK

    Star Raider

  • 72 posts

Posted Tue Mar 27, 2012 4:20 PM

Incidentally, when I got to emulating the pAPU (embedded in the NES 6502), I ran into the same problems you are having with the crackling. A big part of the problem was timing and a few issues with the standard circular buffer approach:-
1) Timing - ie. writting bytes to active parts of the buffer, and the buffer size itself. I got better cleaner sound by creating an entirely new buffer each time and pointing to a new buffer. And if the code from the CPU (or pseudo CPU etc) sets bits and bytes to change frequency, amplitude etc, then in the real harware it probably doesnt just change instantly from one wave form to another without a tiny bit of drop off etc - probably explaining this badly, a simple example of what I am trying to say is, imaging a square wave and suddenly it changes to a saw tooth. Without some leveling / merge on some of the bytes you will get a an audio spike as you get half square half saw tooth.
2) Changing from one wave form to another but with an unclean join (as above).

I was not an expert on audio emulation at all though so take what I am saying with a pinch of salt - getting audio emulated perfectly is still a tiny bit of a black art to me and I gave up before I perfected audio in my NES emulator. I paid no attention to existing methods out there and just jumped in at the deep end. Used a circular buffer, created the standard wave forms (square, triangle etc) and applied logic to change amplitude and frequency, then merged the seperate audio channels over the top of each other using bit logic - it worked but wasnt great and lowered performance a lot. I guess a better way would have been to use a seperate audio stream for each of the 4 channels the NES 6502 pAPU had and and let directx merge them.

Edited by GadgetUK, Tue Mar 27, 2012 4:29 PM.


#55 LX.NET OFFLINE  

LX.NET

    Star Raider

  • 78 posts

Posted Wed Mar 28, 2012 2:46 AM

View PostGadgetUK, on Tue Mar 27, 2012 4:07 PM, said:

The problem at the moment is I cannot get hold of the author and he never made the source open - ironic as it was open source to start with... Anyway, I will progress with the issues you've raised and fixed and try and get the GP2X version of Handy updated.
I have looked through my list of emulators and found the GP2X and GP32 emulators there. Like you said, I haven't been able to find any source code for the GP2X, but did have an archive called "handygp02.zip" which contains source code (gpmain.cpp) and a handygp.xfe file (the binary I guess). Not sure if this is helpful, but I thought I would mention it.

View PostGadgetUK, on Tue Mar 27, 2012 4:07 PM, said:

(65SC02 - not sure what the SC code means).

The 6502 was the first chipset, then came the 65C02 and 65SC02. The 65C02 has the largest instruction set of the three and the 65SC02 has most of the extra instructions that the 65C02 has, but missing some (RMB, SMB, BBR and BBS).

View PostGadgetUK, on Tue Mar 27, 2012 4:07 PM, said:

Moving forward I am looking at getting an SDK, and possibly a Lynx flashcard (might be hard, seem to be next to none around) and developing some games for the Lynx. Keep up the good work, it's nice to see that some one has passion and enthusiasm for the Lynx - keeping it alive!!

Thanks. Good to hear.
I've begun programming a port of an Atari 2600 game myself and have gotten my development environment set up. Apart from debugging support I feel like it is very productive. I should really write something on this. It might not suit everyone, but there might be takers.

#56 LX.NET OFFLINE  

LX.NET

    Star Raider

  • 78 posts

Posted Wed Mar 28, 2012 2:50 AM

View PostGadgetUK, on Tue Mar 27, 2012 4:20 PM, said:

Incidentally, when I got to emulating the pAPU (embedded in the NES 6502), I ran into the same problems you are having with the crackling. A big part of the problem was timing and a few issues with the standard circular buffer approach:-
1) Timing - ie. writting bytes to active parts of the buffer, and the buffer size itself. I got better cleaner sound by creating an entirely new buffer each time and pointing to a new buffer. And if the code from the CPU (or pseudo CPU etc) sets bits and bytes to change frequency, amplitude etc, then in the real harware it probably doesnt just change instantly from one wave form to another without a tiny bit of drop off etc - probably explaining this badly, a simple example of what I am trying to say is, imaging a square wave and suddenly it changes to a saw tooth. Without some leveling / merge on some of the bytes you will get a an audio spike as you get half square half saw tooth.
2) Changing from one wave form to another but with an unclean join (as above).

I was not an expert on audio emulation at all though so take what I am saying with a pinch of salt - getting audio emulated perfectly is still a tiny bit of a black art to me and I gave up before I perfected audio in my NES emulator. I paid no attention to existing methods out there and just jumped in at the deep end. Used a circular buffer, created the standard wave forms (square, triangle etc) and applied logic to change amplitude and frequency, then merged the seperate audio channels over the top of each other using bit logic - it worked but wasnt great and lowered performance a lot. I guess a better way would have been to use a seperate audio stream for each of the 4 channels the NES 6502 pAPU had and and let directx merge them.

This is very good feedback. I will look into this a bit further. My (ultimate) goal is to get "pixel-perfect" sound. From the earlier comments and yours I have some approaches I can take. Especially the one you mentioned (mixing channels by DirectX) seem like an idea. The other one is the circular buffer approach (or rather not having one). To me it seems that the buffer is the culprit indeed. You can clearly hear that the hickups are at the 0,25 second buffer edges. I have thought about double buffering the sound. I'll give it a spin in a couple of days.

#57 GadgetUK OFFLINE  

GadgetUK

    Star Raider

  • 72 posts

Posted Wed May 2, 2012 7:38 AM

Any news on this?

#58 LX.NET OFFLINE  

LX.NET

    Star Raider

  • 78 posts

Posted Thu May 3, 2012 1:53 PM

Hi GadgetUK,

Only theoretical preparations. I have looked in to the Mednafen and Handy/SDL source code to see their approach. I still have to look at it a second time to really dig into it. For now I did see different approaches (copying buffers, variable length buffers). Working on a couple of things now and I have to be careful not to spend my time too fragmented. I'll keep updating as I progress.

Alex

#59 GadgetUK OFFLINE  

GadgetUK

    Star Raider

  • 72 posts

Posted Thu May 3, 2012 3:22 PM

Great! I know what its like trying to balance time between different projects, work and family life etc! I am deperately trying to finish an IOS game for release to the app store. Keen to do something Lynx related after that, and before my next IOS release I think. Had ideas to look at NES to Lynx conversion of ROMs but not sure yet. I might just try and do a game for the Lynx instead.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users