Well, I didn't actually get a chance to look through the log file yet, but I managed to pull together a small C++ program that reproduces the output for a=0, b=255, c=variable case (the pastie link you posted earlier). Thought it'd be more straightforward, but it looks like the original algorithm probably does something with signed numbers, since it apparently changes things up for whatever reason after the index is greater than 0x80.
Here's the link for it: http://pastie.org/private/y32ei9yqkqhenbb5j2o7ca
It's probably not intuitive (at least it's not an elegant one-liner, and it's probably not simplified as much as it could be). The "zones" refer to the 4 segments the algorithm seems to affect (indices 0x21 <-> 0x60 is Zone 0, 0x61 <-> 0xA0 is Zone 1, 0xA1 <-> 0xE0 is Zone 2, and 0xE0 <-> 0x20 is Zone 3. Basically I used the "zones" to determine what should be what I call the "additive".
The basic formula should simply be (Index * 4) - additive, (masked by 0xFF obviously) but that only got me correct values for Index 0 through Index 0x80. Seems that after 0x80, the algorithm calculates values that are technically one step ahead of the Index value, i.e. using (Index * 4) - additive gives a value of 0xFE at Index 0x80, when on real hardware, it jumps immediately to a value of 0x2 at Index 0x80 (which just happens to be the next value at Index 0x81). So from Index 0x80 to 0xA0, the formula is then (Index+1 * 4) - additive
After 0xA0, values are calculated with the regularly using (Index * 4) - additive but how the "zones" are calculated needs to be changed, e.g. treat Index 0xA0 as if it were part of Zone 2 (in which case the additive is not -2, but rather +1). Basically the "zone" boundaries are shifted by 1. Consequently, this also resets adding 1 to the Index, so for Index 0xA0 to 0xFF, the formula is the original (Index * 4) - additive.
Sorry if my explanation seems a bit scattered or confusing, but hopefully this and the code helps you in some way. I'll give the log a good look-over tomorrow but I see if I can come up with something for that too.
Here's the link for it: http://pastie.org/private/y32ei9yqkqhenbb5j2o7ca
It's probably not intuitive (at least it's not an elegant one-liner, and it's probably not simplified as much as it could be). The "zones" refer to the 4 segments the algorithm seems to affect (indices 0x21 <-> 0x60 is Zone 0, 0x61 <-> 0xA0 is Zone 1, 0xA1 <-> 0xE0 is Zone 2, and 0xE0 <-> 0x20 is Zone 3. Basically I used the "zones" to determine what should be what I call the "additive".
The basic formula should simply be (Index * 4) - additive, (masked by 0xFF obviously) but that only got me correct values for Index 0 through Index 0x80. Seems that after 0x80, the algorithm calculates values that are technically one step ahead of the Index value, i.e. using (Index * 4) - additive gives a value of 0xFE at Index 0x80, when on real hardware, it jumps immediately to a value of 0x2 at Index 0x80 (which just happens to be the next value at Index 0x81). So from Index 0x80 to 0xA0, the formula is then (Index+1 * 4) - additive
After 0xA0, values are calculated with the regularly using (Index * 4) - additive but how the "zones" are calculated needs to be changed, e.g. treat Index 0xA0 as if it were part of Zone 2 (in which case the additive is not -2, but rather +1). Basically the "zone" boundaries are shifted by 1. Consequently, this also resets adding 1 to the Index, so for Index 0xA0 to 0xFF, the formula is the original (Index * 4) - additive.
Sorry if my explanation seems a bit scattered or confusing, but hopefully this and the code helps you in some way. I'll give the log a good look-over tomorrow but I see if I can come up with something for that too.