| Re: [hatari-devel] IKBD regression with EmuTOS |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 10/02/2013 19:29, Vincent Rivière 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.
Also, on Hatari, I don't understand why it works fine after Reset, since
the EmuTOS initialization code is the same.
Yes, it's also possible there's a limitation in the acia's emulation,
see below.
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.
sending $1a and $12 during the reset is not a documented behaviour of
the ikbd (even if some games used it) and is different from sending them
after the reset.
I think that if emutos is to be used as a tos alternative, it should put
the machine in a similar state as a real tos does.
That's why I think you should just reset the ikbd, then send $1a and $12
after the reset is complete.
for example do sthg like :
- send $80 and $01 to $fffc02 to do a reset
- test bit 0 of $fffc00 (RDRF)
- when it's '1', it means you receive the $f1 byte that indicate the
ikbd has completed its reset. You should then read $fffc02 to clear the
RDRF bit.
- send $1a and send $12
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".
Maybe it's not precise enough on that subject, but it's clearly
explained in the IKBD's documentation. See
http://www.kernel.org/doc/Documentation/input/atarikbd.txt for example.
Can you describe what emutos is supposed to do to handle this $f1 byte ?
Currently, AFAIK EmuTOS does not expect that $f1 byte.
note that depending on the ikbd version, you could received a $f0 or a
$f1. In any case, just reading $fffc02 when bit 0 of $ffc000 is set will
be enough to clear RDRF.
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.
In Hatari, after the first start, the acia's clock is started only when
writing $96 to $fffc00. If you receive byte from the ikbd before the
acia is set, this will create the observed error under emutos (due to
the overrun). If you then reset Hatari, the acia's clock remains
initialized, so the ikbd will work correctly this time.
The ACIA's doc is not clear on the value of bits 0 and 1 of $fffc00
after a reset. From what you say, if it works on real hardware, then it
would mean that the acia processes serial data after the first start
(bits 0 and 1 would be 0 and clock divider would be 1).
I will modify the acia's code to behave like this when Hatari starts,
but still you should read $fffc02 after a reset when RDRF is set, else
you might get problem in other cases.
Nicolas