"Emulate async read" parameter

[sundance2]

Thanks for these great answers @SWAT.
Let me provide additional details below :

(13.04.2023 13:50)SWAT писал(а):  If you plays with this value seems you are SD card user?

Yes, I should have mentioned it, I'm using a SD Card reader on the serial port.
I'm aware that this setup offers limited performance, compared to an IDE mod.
However, it also allows to keep the Dreamcast in pristine (original) condition,
and that's what I'm after for this unit.

Do I understand correctly that your comment implies that the "async" parameter is actually only useful for the SD Card scenario ?
And that, rule of thumb, higher values generally offer higher performance ?

May I ask why is 16 the maximum possible value ? Why not, for example, 32 ?

(13.04.2023 13:50)SWAT писал(а):  For some games better use lowest value, like Shenmue and Crazy taxi better use "1+" for emu async. Slow loadings, but smooth gameplay.

This part is very interesting.
So there are some drawback to larger values, and you imply that large values are not good when games load data during gameplay, or said differently, small values offer smoother gameplay.
That's very useful to know, because many games indeed load resources during gameplay.
One big example comes to mind, Dead or Alive 2.

Another example I'm not sure how to categorize : when there is a video cutscene, what's preferable ? High async values, or small ones ?

But it's still unclear to me how a smaller values leads to "smoother gameplay".
So I'm still trying to get my mind around how this work.

You also mentions that the "async" parameter "emulates DMA".
So let me rephrase it, to check if my understanding is correct :

1) In full SYNC mode, the program asks for one sector, the program blocks until it receives the sector, and once this is done, execution resumes.

2) In "async" mode, the program asks for a first sector, the request is triggered but execution immediately comes back to the program, and it may request a second sector before the first has arrived. And it can chain these requests, until it reaches a threshold, which is the "async" number. At which point, execution will finally block, and wait for some data to be delivered before resuming.

I'm not sure if this is the correct way to see the system working, because:
- The ability to request more data seems to be application driven, which must also reserve enough memory space to receive data from so many sectors.
- At some point, execution must still be interrupted, because the cpu is fully involved in the receiving of data from the SD card.
- I'm not sure to understand how a smaller async queue leads to "smoother gameplay".

So it's unclear if I've understood the underlying mechanism.