|Re: [hatari-devel] Error in SetClock / ReadClock|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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?
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.