Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectModel 2 Emulator 0.5a new Reply to this message
Posted bySune_S
Posted on05/29/07 04:22 PM




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




Subjectaddicted to vstriker and bringing back good memories :)) new Reply to this message
Posted by[seh]
Posted on05/30/07 11:34 AM



It even works with my EMS USB2 \o/


Subjectsteering STILL broken for me in Daytona new Reply to this message
Posted byMegaHurtz
Posted on05/30/07 06:56 PM



Same problem as before...


Subjectaccording to Elsemi new Reply to this message
Posted byIceMan
Posted on05/31/07 07:46 AM



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




SubjectOk, so... Reply to this message
Posted byMegaHurtz
Posted on05/31/07 09:18 AM



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


SubjectRe: Ok, so... new Reply to this message
Posted byElSemi
Posted on05/31/07 09:31 AM



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





Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode