Re: [hatari-devel] IKBD regression with EmuTOS

[Vincent Rivière <vincent.riviere@xxxxxxxxxxx>]

On 10/02/2013 19:56, Nicolas Pomarède wrote:
> In Hatari, after the first start, the acia's clock is started only when
> writing $96 to $fffc00.

First, EmuTOS issues an ACIA Master Reset.
Then it configures the control register correctly.
After that, it sends $80 $01.
And you are right, it does not wait enough before sending additional 
commands. This is wrong.

But it does not explain what happens.

> If you receive byte from the ikbd before the acia is
> set, this will create the observed error under emutos (due to the overrun).

No, nothing is received before the ACIA is initialized.

I also can't understand how a buffer overrun could prevent next bytes to be 
received.

> If you then reset Hatari, the acia's clock remains initialized, so the ikbd
> will work correctly this time.

Since EmuTOS properly initializes the ACIA in the same way on cold and warm 
boot, I can't understand why Hatari's behaviour is different in both cases.

> From what you say, if it works on real hardware, then it would mean
> that the acia processes serial data after the first start

If you mean that data can be received before the ACIA initialization, I 
don't know, since EmuTOS does not do that.

> but still you should read $fffc02 after a reset when RDRF is set, else
> you might get problem in other cases.

Sure. I have added that to EmuTOS, with a timeout to avoid hangs when the 
keyboard is unplugged. Unfortunately, in that early initialization routine, 
no timer is available, so I did that with an ugly CPU loop. Not a big 
problem, since it matters only with Hatari, where the CPU speed is limited.

However, I have studied the TOS 1.02 and 1.62 keyboard initialization 
routines. There is timeout management (again, with CPU loop) in the IKBD 
write routine to avoid hangs.

After the IKBD reset, there is again a big delay, but that's all. I didn't 
see any IKBD read for that $f1 byte. I believe it is read later, by the 
keyboard interrupt routine, just as it was in EmuTOS.

So, as you said, the solution in Hatari is to wait for the IKBD reset to 
complete before sending additional command bytes (otherwise, we enable those 
undocumented modes). But I still wonder how that can prevent further data to 
be received from the IKBD, and only on cold boot on Hatari. Jean-François 
Del Nero tested EmuTOS as ROM replacement on his STe, and he never reported 
such problems on cold boot.

Also, I saw strange code in Hatari's src/acia.c.
That's about pACIA->FirstMasterReset and RTS line.
I wonder if that could explain the odd behaviour on cold boot only.

Anyway, my biggest concern is the upcoming EmuTOS 0.9.0 release. Even if we 
have to put a few workarounds inside, it must work fine on all the supported 
platforms.

--
Vincent Rivière