Re: [hatari-devel] Hatari/EmuTOS Conflict

[David Savinkoff <dsavnkff@xxxxxxxxx>]

On Wednesday 12 June 2013 12:12, Nicolas Pomarède wrote:
> On 12/06/2013 00:23, Vincent Rivire 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.
>
> ...
>
> 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

Hi Nicolas,

I tested this new Hatari with my joysticks, keyboard and mouse.
Tested OK. Excellent.

I think this fixes the problems with uncalibrated joysticks I've had
in the past too.

One more thing:

I found that ACIA_Write_CR() in hatari/src/acia.c overwrites the
Set_Line_RTS ( 1 ) made by ACIA_MasterReset( pACIA , CR )
with a Set_Line_RTS ( 0 ).

See the included patch.

Sincerely ,
David

Attachment: acia.c.diff
Description: Binary data