Larry’s Personal & Tech ramblings

The two changes in 0.27 are the release of the Desktop PC version of SmartGear and the addition of the “PAUSE” button to the MasterSystem emulator (mapped as “Select”).

The product page for SmartGear is up –>SmartGear Web Site

You can now download friendly installers for Pocket PC and SmartPhone. The installers also install a Desktop PC version of SmartGear (never released before). A paypal button is at the bottom of the page to allow you to register.

I realize that this is only relevant to about five people in the world, but it may help get others thinking along similar lines.  I’ve come up with a clever idea for those emulating the 6502 on ARM and I’ve decided to share it with my fellow emulator authors. One of the tricky parts of emulating the stack pointer on the 6502 is that it points to 0×100-0×1ff, but it’s an 8-bit register. Modifying its value usually involves masking the 8-bits and then ORing in the 0×100. The ARM barrel shifter allows for a more elegant solution to the problem. By using the upper 8 bits of a register to hold the stack value, and then setting bit 0, it’s value can be modified without having to worry about the 0×100 part. Here’s an example:

Increment the stack: add r0,r0,#0×1000000 ; this doesn’t affect the LSB

Write to the stack: strb r1,[r2,r0,ROR #24] ; r2=ZP/Stack memory, R0 = SP

With the rotated register, bit 0 shifts into position as bit 8 and keeps the pointer in the 0×100 to 0×1ff range.

Enjoy,
L.B.

I started writing an emulator for the 68000 several years ago for a Capcom CPS1 project.  At the time I was targeting the desktop PC, so writing it in C wasn’t a problem.  Lately I’ve had to create an ARM version for portable and embedded systems and speed is definitely an issue.  My first pass at a purely ARM 68k emulator didn’t take too long to get working, but was not terribly fast.  The complexity of the 68k kept me from taking too many chances with some of my optimization ideas.  I’ve spent much time since then thinking about ways of speeding it up without coming up without anything useful.  Starting last week I took another look at the code and I found myself with 5 new ideas for further optimization.  I’ve implemented 4 of them so far and I’ve sped up the code a good amount and reduced the size by 15%.  The last idea will end up growing the code size, but at this point that won’t have much effect on the speed since it doesn’t fit in the code cache anyway.  Without revealing too many details of what I did, here are my ideas which worked:

1) Delayed flag calculation - processors which affect the flags on almost every instruction waste lots of time manipulating them.

2) When possible, use the native ARM flags to calculate things such as OVERFLOW.

3) For Read-Modify-Write functions, try to re-use the effective address efficiently.

4) Use better register management and instruction ordering to reduce pipe stalls and memory accesses.

5) Work with the statistics of the opcodes and focus energy on the most used instructions.

The worst part of embarking on a project like this is that you start with working code and end up breaking while trying to improve it.  Much time is lost figuring out what broke, but in the end it’s all worth it :).