> Quote:
>
> As you noticed, the emulator stores the calibration value as 1 byte, so for
> 65535 (0xFFFF) it stores 0xFF, that when transformed back to 65280 (0xFF00).
> When adjusting the analog range to the calibrated range, all values over the max
> are clamped to 0xFFFF, so it's not a problem, the same for values below the min.
>
>
> The actual problem was not there, but in the daytona analog inputs processing
> function. The function converts back from the 16 bit analog range that the
> emulator input subsystem computes to 8 bit digital inputs (in model 2 and 2a
> there are no dedicated analog ports, there is an ADC with its output bits
> connected to the digital inputs).
> The function that adjusts the range (from 0x3 to 0xFD with 0x80 center) was
> taking a byte value as input, while the adc output was ranging from 0 (left) to
> 0x100 (right) and the function was masking out the top 8 bits, thus sending a
> 0x00 at top right, that was converted to the top left value. The solution has
> been chaning that function to receive a full 16 bit value :)
>
> Quote from here
>

Did El Semi just figure this out, or was this his solution that he implemented in 0.5a? If this was what he did in 0.5a to fix it... It doesn't work.