I'm not seeing a pattern, here. It doesn't appear to be a simple binary conversion (big or little endian), but I've never been any good at these types of problems.

Hmm, it's pretty weird.

This is the pattern I see.

You have AB CD.

First AB is converted to decimal and multiplied by 2, 4, 8 or 16 depending on how high up in your list it is.

Then 2^((2*D)+1) is added to that number (however that step is sometimes completelety omitted but I haven't figured out the logic that determines when this happens).

Examples:

34 44:

34h= 52
52*4= 208

2^((2*4)+1)=2^9=512

208+512=720

F0 44:

F0h= 240

240*8=1920

09 45:

9h=9
9*16=144

2^11=2048

144+2048=2192

Yes, the high order bits are the elusive part.

Below 80 hex, the multiplier appears to be four, 80 hex and above it appears to be eight.

However, look at 00 43 h and F0 43 h. The difference is 352. Assuming the multiplier as above, 7 * 8 * 16 is already incorrect, so the method is already broken for this example.

F0 43 is one of the cases where only the first part is counted.

F0h= 240
240*2= 480

Why did they invent all these weird, branchy exceptions rather than implement some plain old bitwise arithmetic?

Thanks for the answers, good to know I wasn't being stupid for not seeing an obvious non-changing pattern. If I wasn't lazy I'd register for WSGF forums and ask jackfauste (he widescreen hacked Desperados, and it uses similar values).