Re: [hatari-devel] Hatari/EmuTOS Conflict

["Roger Burrows" <rfburrows@xxxxxxxxx>]

On 11 Jun 2013 at 19:21, Roger Burrows wrote:
> On 12 Jun 2013 at 0:46, Vincent Rivière wrote:
> > On 11/06/2013 01:03, Nicolas Pomarède wrote:
> > > But there's a problem in Emutos : we can see it still sends 0x1a and
> 0x12
> > > *during* the reset, which is not correct, it should send them after
> > getting
> > > a 0xf0 or 0xf1 from the ikbd.
> >
> > I will setup a test environment (latest Hatari, EmuTOS, MIDI debugging....),
> > but I'm currently very busy. Anyway, I will need to find the time to look
> at
> > that before the next Hatari/EmuTOS release.
> >
> I have some free time - I'll go ahead with the test unless I hear otherwise.
>
I've done tests with the latest Windows builds from antarctica.no (dated 10
june) and the latest EmuTOS snapshot (CVS-20130604, 512K ROM version).  I
tested with both hatari-debug.exe (ST at 8MHz) and hatari-winuae-debug.exe
(Falcon at 16MHz).  I set a breakpoint at the entry to kbd_init() and then at
the point in ikbd_readb() where ACIA_RDRF is found to be set (actually it isn't
a separate function in the code since GCC has expoanded it inline).

In both cases, ACIA_RDRF was detected before the timeout.  For the Falcon, 25
loops out of the 300 had been completed; for the ST, 35 loops.  So there's
plenty of safety margin there.  When I took the debug a little further, I could
see that $f1 was being returned from the keyboard.  The $1a and $12 were not
written to the keyboard until after that.

I then repeated this test for winuae but adding "trace ikbd_acia".  The traces
showed the timer for the acia reset completing ("ikbd reset timer completed")
and subsequently that $f1 was returned ("acia ikbd read") before $1a/$12 were
written ("acia ikbd write").

So I can't see any problem with Hatari or EmuTOS behaviour here.  As noted
above, this is with the 512K ROM version of EmuTOS.  If the problem is on a
different ROM version, let me know & I'll repeat the tests.

Roger