|Re: [hatari-devel] Error in SetClock / ReadClock|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 28/12/2012 12:12, Thomas Huth wrote:
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.
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...
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
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).