Re: [hatari-devel] IKBD regression with EmuTOS |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hello Vincent,
Sunday, February 10, 2013, 8:29:57 PM, you wrote:
> On 10/02/2013 18:08, Nicolas Pomarède wrote:
>> looking at the reset sequence,
> Thanks for your analysis, Nicolas.
> The main oddity is that EmuTOS works fine on real hardware (STe and Falcon),
> while it doesn't in the latest Hatari. So I suspect an inconsistency in Hatari.
I haven't taken a look at the EmuTOS sources in years, so I'm not sure
how it's handling the IKBD reset, but I do know that if you send any
command during the IKBD reset (i.e. within 300ms after issuing the
reset command) it gets ignored. Maybe there's a deliberate pause in
EmuTOS?
Proof: http://pouet.net/prod.php?which=60836, which I debugged for
!Cube. He was doing what I described above, so his "kill mouse"
command was being ignored by real hardware, while it worked ok on
STEem (and possibly hatari).
> Also, on Hatari, I don't understand why it works fine after Reset, since the
> EmuTOS initialization code is the same.
>> It then sends the following bytes to the ikbd : $80, $01, $1a, $12.
>>
>> This resets the keyboard
> Yes.
>> and sends $1a and $12 *during* the reset,
> Do you mean that we send $1a and $12 too early after the reset?
> Do we have to wait a bit?
>> which put the ikbd in a mode where it reports both mouse and joystick. Is
>> this really intended ?
> Yes, we expect to receive mouse and joystick packets.
>> But the main problem could be that after the ikbd reset, you will receive a
>> byte $f1
> Really? I don't see that in "Le livre du développeur".
>> Can you describe what emutos is supposed to do to handle this $f1 byte ?
> Currently, AFAIK EmuTOS does not expect that $f1 byte.
>> When comparing with tos 1.04 for example, it sends only $80 and $01 and read
>> $fffc02 to clean the RDRF bit.
> Ok, EmuTOS will need fixing if $80 $01 really answers with $f1.
> But that does not explain why it works fine on real hardware.
--
Best regards,
George mailto:ggn@xxxxxx