|Re: [hatari-devel] "IKBD buffer full" problem
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 13/09/2012 16:19, Eero Tamminen a écrit :
On torstai 13 syyskuu 2012, Eero Tamminen wrote:
I run into a program that causes loads of "IKBD buffer full"
messages after moving mouse a bit.
After that Hatari refuses to process any information for TOS,
*even* if I coldboot the emulation.
I.e. there seem to be two problems; the IKBD buffer full issue,
and reboot not getting rid of it...
This seems a regression, as it doesn't happen with Hatari v1.4.
The program causing the issue is attached.
Found another game causing similar issues, called "Downfall".
the problem is in fact in the $16 command IKBD_Cmd_ReturnJoystick (which
already has a comment about downfall doing silly things).
This game is sending continuous $16 command to the ikbd without really
waiting for the 3 returned bytes (so basically, this game is rather
crappy :) )
From a real ikbd point of view, only one new command should be queued
until the current command is completed. But IKBD_Cmd_ReturnJoystick has
an initial 35000 cycles before returning the 1st byte, although command
$16 takes ~8000 cycles to be sent.
This means that after 8000 cycles, the game will be able to send other
$16 command and they will eventually fill the buffer ring, since each
command adds 3 bytes to the buffer that are read much later.
For commands that return several bytes, we should have a "command in
process" flag to ignore new command suntil the last byte is sent by the
ikbd (as a real ikbd is not multitasking, he can't process new commands
while sending back bytes at the same time from a previous command).
I will see if I can modify that, but I'm seriously thinking about
rewriting completly the whole ACIA emulation ; it should not be so
merged with the ikbd itself, and some shortcuts were taken to get a
functional behaviour, but without really emulating the inner real
behaviour described in the datasheet.
This is why we keep on having problem in the acia/ikbd, and often
regressions. Patching it again each time a new problem arises is not the
good solution, rewriting it as a state machine with all the regs /
latches described in the datasheet will certainly help starting on more