http://nebula.emulatronia.com/


This is a small bugfix release:
Fixed (hopefully at last) the analog wraparound bug.
Fixed wrong colour table translation in vcop medium and expert levels.

Added a couple of useful features:
Launch game from command line (just add the driver name. ex: Emulator.exe stcc)
Auto-switch to full screen after game loading (the option is in the Video menu)


S

It even works with my EMS USB2 \o/

Same problem as before...

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

> 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.

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
> 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.
>