It would be nice to assign keyboard keys to a,b,x,y,L,R buttons like in zx emu.
Yes, I'll add this. I've reserved room for 256 possible key maps per button - at least for ABXY. L/R I'm keeping reserved for scaling which is desperately needed on this emulator (but less so on SpeccySE where the screen resolution fits nicely so I can spare those keys).
Appreciate your help on the early versions, djl. I know some of them were a bit rough around the edges
I used to post more technical details and kinda fell out of that habit. I'll endeavor to put some thoughts down here:
The version of FrodoDS that I started with was a bit of a mess... that's not the fault of the original porter(s) who did an admirable job of cobbling in the DS infrastructure nor of the original Frodo emulator author who has provided a nice clean base. It's just that those versions didn't really play to the strengths of the DS. Having four years of experience under my belt, I could see immediately some missing elements. Here is the main things I did for speedup:
- Moved the entire CPU emulation handler into ITCM fast memory. This alone gives an almost 10-12% speedup.
- Moved a ton of buffers (especially VIC and SID memory) into DTCM fast memory. This gained another 5%.
So with just those two simple things, we get 15% speedup with no other changes to the code.
Then I looked for the obvious 'wins'. From having optimized 9 other emulators, the first few took very little time:
- Look for places where we write 1 byte at a time when we could be doing 2/4 bytes at a time.
- Look for times when we're drawing blocks of the same color - especially when we're drawing the background color and just blast those out 32-bits at a time. These last two bullet points probably gained 10% speed.
- Look for memory copies that don't need to happen... the biggest gain here was in sprite rendering. Some games don't use sprites at all... and many games that use them, don't utilize them on every raster line. So we were clearing this (relatively) big buffer of sprite collisions on every raster line when we really only needed to do so on lines where sprites were enabled. This gained almost 15% speed gain.
- Look for any Flush memory operations - which are done so we don't try to render screen data that has been cached via DMA. The easiest trick here is to actually render the NEXT line coming up which is roughly 1 frame behind the current drawing algorithm... that scanline is never going to be cached because so much memory has been read/written since it was last drawn (1/50th of a second earlier) and so the flush can be skipped. And memory flushes are expensive. I later switched to drawing portions of the screen directly to the LCD (borders mostly) such that I don't have to double-buffer anything. The best thing you can do is not move big blocks of memory... but the next best thing is to not move it more than once.
Once those six things were done above, we had almost a 2x improvement in rendering speed. I was able to turn off the frameskip on the DSi and above (FrodoDS was skipping 50% of fames) and greatly reduced the frameskip on the DS-Lite/Phat (was rendering 1/3 of all frames and still had slowdown... now rendering 2/3 of all frames with almost no slowdown).
I've backported a lot of fixes and improvements from the more recent versions of FrodoDS - so the accuracy is much better. More games should run more closely to correct. There are still some graphical glitches and some games that hit the virtual hardware in ways that are difficult to emulate correctly - but I'll keep making improvements.