Re: [hatari-devel] Hatari/EmuTOS Conflict

[David Savinkoff <dsavnkff@xxxxxxxxx>]

On Tuesday 11 June 2013 21:05, Roger Burrows wrote:
> On 11 Jun 2013 at 19:21, Roger Burrows wrote:
> > On 12 Jun 2013 at 0:46, Vincent Rivire wrote:
> > > On 11/06/2013 01:03, Nicolas Pomarde 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

1) Use a Windows Hatari build from June 8 or earlier to test without
   the "Default IKBD's ACIA to 9600 baud after a reset" patch.

2) Delete directory ~/.hatari

3) Execute Hatari,
    press f12,
    select: System
    uncheck: Patch TOS for faster boot
    select: Back to main menu
    select: ROM, and browse for latest etos256uk.img
    select: Back to main menu
    select: Save config
    select: Quit

4) Execute Hatari again while continuously moving the mouse
   across the Hatari window during the boot-up. Notice that
   the mouse is frozen in the Hatari window once EmuTOS has
   fully booted.

6) press altgr-r to reset Hatari; cursor is movable this time.

David