Re: [hatari-devel] "IKBD buffer full" problem

[ Thread Index | Date Index | More 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".

	- Eero


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 solid bases.


Mail converted by MHonArc 2.6.19+