No, in 0.5a I added that extra post-processing function to clamp to 0x3-0xFD, but it was wrong. I have to fix it for the next release, but at least it will work :).
> > 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
> > are clamped to 0xFFFF, so it's not a problem, the same for values below the
> > 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)
> > 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.