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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 24 syyskuu 2012, Nicolas Pomarède wrote:
> 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 :) )

Is it the same problem with both of the games?


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

If there's no straightforward way to deal with this immediately, maybe
you can add your description to the todo.txt bug section?


	- Eero

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