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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 03/01/2013 23:31, Thomas Huth wrote:
> [...]
> > 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.
>
> Is there a good reason to keep this big output buffer? I think we
> might just have used this in the past to workaround other bugs that
> should be fixed now. Have you tried to change it to the same size as the
> real IKBD output buffer?

hi

I wondered about this ; the only difference I could see is that through 
SDL we might get key/mouse/joystick reports at a different rate than on 
a real ST. So maybe sometimes it could be useful to buffer a little more 
to avoid loosing some events (IIRC we only poll every 64 HBL, while a 
real IKBD can potentially poll anytime).

On the other hand, having a bigger buffer could hide some (rare) timing 
issues when compared to a real ST (as seen in Fokker/Downfall, bigger 
buffer means bigger latency so the 68000 could think there's no buffer 
full and no lost events, while it would already be the case on a real ST)

In normal use, I don't think we have more than 2 or 3 packets at the 
same time in the output buffer, so the buffer's size won't matter 
regarding timing ; only when "silly" programs are flooding the IKBD.

This would need to be measured/tested, maybe 64 bytes instead of 1024 
would be enough, but appart from saving a few bytes, I don't think it 
would have any impact on the emulation. Let's see later if no other 
problem arise, but fell free to test this on your side if you want.

Nicolas