| Re: [hatari-devel] Hatari/EmuTOS Conflict |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 10/06/2013 14:19, David Savinkoff a écrit :
(1)
I've been looking at the code in emutos/bios/ikbd.c (line 541) and
code in hatari/src/acia.c (line 279). It appears that Hatari somehow
doesn't succeed in performing the software ACIA reset when
EmuTOS writes 0x03 to 0xFFFFFC02 And the keyboard is attempting
to communicate with the ACIA.
I should have a look at this later with --trace acia, but the code in
Hatari looks correct to me.
(2)
I found that this problem was caused by my uncalibrated usb joystick
sending data.
(3)
I also found that the problem can be caused by moving the mouse
when Hatari is booting EmuTOS.
Even on a real ST, moving the mouse or pressing a key while booting can
create such problem (you usually hear the key sound in loop).
(4)
Nicolas' patch at hatari/src/acia.c (line 279) works so well that EmuTOS
code can be commented out as shown at emutos/bios/ikbd.c line 541:
/* On Hatari, it is *mandatory* to wait for the IKBD Reset to complete
* before sending the next command bytes. Otherwise, on cold boot
* no further data will be received.
* This is why we read the IKBD version byte below.
*/
// ikbd_version = ikbd_readb(); /* Usually 0xf1, or 0xf0 for antique STs */
//#if DBG_KBD
// kprintf("ikbd_version = 0x%02x\n", ikbd_version);
//#endif
// UNUSED(ikbd_version);
No, this should not be commented. I disagree with the comment in the
code : it is mandatory to wait for 0xf0/0xf1 after the IKBD reset in all
cases, whether it's under an emulator or under real HW.
Sending commands to the ikbd before receiving 0xf0 or 0xf1 is an
undocumented behaviour, that will likely result in those commands to be
ignored.
A real TOS waits for 0xf0/0xf1 after sending reset, and it's the correct
thing to do.
Nicolas