Re: [hatari-devel] Error in SetClock / ReadClock

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 28/12/2012 12:12, Thomas Huth wrote:
>   Hi again,
>
> Am Fri, 28 Dec 2012 11:49:19 +0100
> schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
>
> > On 28/12/2012 11:04, Thomas Huth wrote:
> > > Ok, never mind, the problem with XCONTROL does not occur with hg tip
> > > anymore. Maybe I forgot to update my checkout after doing a pull,
> > > sorry for the confusion.
> > > I've tested some more revisions, and it seems like the problem
> > > vanished with your commmit e0e2dd72877a (Better timings for the
> > > bytes returned by IKBD). So this was rather related to IKBD timing
> > > than to your new IKBD clock function.
> >
> > hello
> >
> > In fact I thing the better/different timings are hiding the problem,
> > but the cause was maybe similar to "Zombi" and it's possible the
> > crash could still happen.
>
> You're right ... I just tested it again, and now I was moving the mouse
> like a maniac while I was entering a new date in XCONTROL, and it froze
> again! So this is maybe really the same problem as in Zombi...
>
>   Thomas

Hello, and a happy new year to all !

Hopefully, 2013 will be the year when IKBD gets fixed once and for all :)

I made an error while changing the ACIA/IKBD serial interface, because I 
assumed the IKBD's ROM would not handle receiving a new command while 
already sending the packet of the current command.

That's why in the case of Zombi the getclok command was ignored at one 
point when the IKBD had some automatic mouse events to report.

By studying the IKBD's disassembled ROM, there're in fact 2 buffers in 
the IKBD's RAM that allow the IKBD to work asynchronously :
 - an 8 byte input buffer (to store one command and its parameter)
 - a 20 byte output ring buffer (to store events reports or returned 
packets)

Both buffers are handled using and interrupt when the RDR is full or the 
TDR is empty. This way the IKBD can process a command, put the resulting 
bytes in a buffer and immediatly handle a new command.
The bytes will be sent from the IKBD to the ACIA at a latter time, as 
soon as TDR is empty.

In the case of Fokker or Downfall, this means we should not ignore new 
commands when the output buffer is not empty. To work like the IKBD's 
ROM, we should process new commands, but we must discard returned 
packets when the small output buffer is full.

In Hatari, we have a 1024 byte output buffer, this is much more than the 
real IKBD's one. It should not give any problem to store more bytes. 
Only in the case where the buffer is full, we can see a longer latency 
when pressing 'fire' during the title screen in Fokker for example. This 
is because we need to flush 1024/3 joystick reports before sending the 3 
byte packet where fire button is pressed.

I tested Downfall, Fokker, Zombi and Captain Blood with those 
modifications, everything seems fine (I think XCONTROL should work too).


Nicolas