OpenMSX - FPS drops during Serial read/write

Page 2/2
1 |

By Grauw

Ascended (8735)

Grauw's picture

05-02-2020, 22:53

Well I don’t know the details of your implementation, but what that behaviour looks like to me is that it buffers characters rather than immediately processing them, and flushes after a time-out or immediately on lf. A sensible optimisation for bulk data transfer, but bad for latency… Is there some setting on the API you use to control buffering and flushing behaviour?

By S0urceror

Resident (44)

S0urceror's picture

06-02-2020, 14:55

Grauw wrote:

...what that behaviour looks like to me is that it buffers characters rather than immediately processing them, and flushes after a time-out or immediately on lf...

No, my implementation is a CHGET hook that returns a character as soon as it gets one from the USB bus. It does not discriminate between normal characters or a LF. The hook does wait on a user pressing a key, just like the normal CHGET routine in the BIOS does. As soon as a character is returned it gives it back to the running program, in this case the BASIC interpreter. The BASIC interpreter immediately echoes the character via CHPUT.

On the real MSX this is immediately visible. On OpenMSX after a delay of around 2 seconds. Unless the typed character is RETURN in which case the redraw happens almost immediately. Please check the video's to see the difference.

My guess is that blocking IO reads/writes on the host OS somehow block OpenMSX doing a refresh. I believe that is because OpenMSX wants to be as accurate as possible. Normally a IN a, (*) takes 11 clock cycles. On the real hardware that is true. In my emulated hardware this might take longer because of the blocking IO on the host OS. This leads to a slow down of the emulated computer.

On CocoaMSX certain parts of the emulated hardware run independent of each other. For example the frame rate stays 50/60. As a result H.TIMI is continued to be called at 50 or 60 frames while H.CHGE is waiting on a response of the USB bus via serial IO. Hence on CocoaMSX it reacts faster on a return character vs OpenMSX.

Just my thoughts.

By Manuel

Ascended (16125)

Manuel's picture

06-02-2020, 21:42

I don't think it's possible that the emulator runs the Z80 emulation in such a way that one hook is called at 50 or 60 times per second and another hook is allowed to wait/block. What would the PC of the Z80 look like in time? It can't be at two places... the Z80 has only a single thread, remember?

I still think that blocking I/O should be done on a separate thread and then posted on the main thread as input for the MSX.

Page 2/2
1 |