Re: [hatari-devel] Hatari/EmuTOS Conflict

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 12/06/2013 00:23, Vincent Rivière wrote:
> I see that TOS 1.2 sends the IKBD reset at 0xfc03ba. After that, it
> waits in a CPU delay loop, then does not read anything. I guess that the
> actual returned value will be read later by the interrupt routine, when
> interrupts are enabled.

Hello

I think I found an explanation to what is happening :
 - without patch #4566 from 9 june, we saw that emutos < 0.91 had 
problem with mouse or keyboard not responding until another reset is made

 - emutos cvs includes change to wait for a byte after doing an ikbd 
reset, to be sure reset is complete before sending new commands.

 - when looking at the traces, I saw that despite this, emutos still 
sent comands during the reset.

This is what we have with Emutos CVS + Hatari dev rev #4567 after a cold 
start :

acia ikbd write fffc00 cr=0x03 video_cyc=59888 452@117 pc=e06b1a
acia ikbd write fffc00 cr=0x96 video_cyc=59912 476@117 pc=e06b20
-> init acia

acia ikbd read fffc00 sr=0x02 video_cyc=60040 96@118 pc=e06a8e
acia ikbd write fffc02 tdr=0x80 video_cyc=60116 172@118 pc=e06ab4
-> check tdr is empty and send 0x80

acia ikbd read fffc00 sr=0x00 video_cyc=60268 324@118 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60360 416@118 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60452 0@119 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60552 100@119 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60652 200@119 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60752 300@119 pc=e06a8e
acia ikbd read fffc00 sr=0x00 video_cyc=60852 400@119 pc=e06a8e
acia ikbd read fffc00 sr=0x02 video_cyc=60952 500@119 pc=e06a8e
acia ikbd write fffc02 tdr=0x01 video_cyc=61036 76@120 pc=e06ab4
-> buffer sent, send 0x01 and wait for reset to complete

acia ikbd read fffc00 sr=0x00 video_cyc=61116 156@120 pc=e06b36
acia ikbd read fffc00 sr=0x83 video_cyc=76412 212@150 pc=e06b36
acia ikbd read fffc02 rdr=0xf1 video_cyc=76460 260@150 pc=e06b40
-> receive 0xf1, allow to send another command (see below)

acia ikbd read fffc00 sr=0x02 video_cyc=76588 388@150 pc=e06a8e
acia ikbd write fffc02 tdr=0x1a video_cyc=76664 464@150 pc=e06ab4
-> send command 0x1a

acia ikbd read fffc00 sr=0x00 video_cyc=81412 132@160 pc=e06a8e
acia ikbd read fffc00 sr=0x02 video_cyc=81512 232@160 pc=e06a8e
acia ikbd write fffc02 tdr=0x12 video_cyc=81596 316@160 pc=e06ab4
-> command 0x1a sent, send command 0x12

acia ikbd read fffc00 sr=0x83 video_cyc=58248 336@114 pc=e0026c
acia ikbd read fffc02 rdr=0xf1 video_cyc=58284 372@114 pc=e00276
-> receive another "unexpected" reset confirmation, see below

acia ikbd read fffc00 sr=0x83 video_cyc=104748 100@206 pc=e0026c
acia ikbd read fffc02 rdr=0x39 video_cyc=104784 136@206 pc=e00276
-> space bar pressed

So, what we see is that the 1st 0xf1 received that is interpreted as a 
"ikbd reset complete" doesn't come in fact from the 0x80 0x01 command, 
it comes from powering on the ikbd (when the emulation starts), which 
does an automatic reset and send 0xf1. This is the result of a hard reset..

The problem is that this 0xf1 is received at the same point where emutos 
expects a byte in return to the soft reset that was just sent. Emutos 
gets a 0xf1, and considers the reset to be done. So it sends 0x1a and 0x12.
But the soft reset is not complete in fact, as we can see we receive the 
0xf1 later.


When powering on, acia and ikbd are not initialized. The ikbd will 
perform an automatic reset (this is a small cpu, it can boot and init 
itself), but not the acia. This means that the ikbd will send 0xf1 on 
the serial line while this serial line is not yet initialized on the 
acia's side (0x03 and 0x96 were not written yet).

On real HW, this 0xf1 should be lost, which was not the case in Hatari, 
and created later the problem we saw with emutos (note that the fix in 
emutos to wait for 0xf1 after sending a reset was needed anyway, even 
for real HW)

I committed a new version that :
 - cancel the change #4566, so acia will not default to 9600 on first boot.
 - ignore byte sent by the ikbd until the acia is correctly initialized 
with 0x03 and 0x96

With this, I can boot + move mouse with emutos 0.87 or emutos cvs for 
example, without doing a reset with alt+c or alt+r.

David, could you check it also works for you ?

Now, Emutos should be correct regarding the byte to expect after a soft 
reset, and Hatari should be correct regarding the serial line's state 
just after a cold start.


Nicolas