|Re: [hatari-devel] Hatari/EmuTOS Conflict|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
> > > *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
> > 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.