"Emulate async read" parameter

[SWAT]

(14.04.2023 02:48)sundance2 писал(а):  it also allows to keep the Dreamcast in pristine (original) condition,
and that's what I'm after for this unit.

Buy another one for this They are not expensive.
All modifications can be made so that it looks like the pristine from the outside.

(14.04.2023 02:48)sundance2 писал(а):  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 ?

This is for PIO mode and non-optimized images.
SD card is PIO only device.

(14.04.2023 02:48)sundance2 писал(а):  May I ask why is 16 the maximum possible value ? Why not, for example, 32 ?

It makes no sense, if you need to get more, just choose "none" to get max.

(14.04.2023 02:48)sundance2 писал(а):  

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

Exactly.

(14.04.2023 02:48)sundance2 писал(а):  Another example I'm not sure how to categorize : when there is a video cutscene, what's preferable ? High async values, or small ones ?

8/16. Here the main problem is the low connection speed of this device.
It is not enough to play video in full quality.

(14.04.2023 02:48)sundance2 писал(а):  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.

Application can request one or a lot of sectors, for example it can load megabyte in one request, there is >500 CD sectors (during gameplay lower of course, but still a lot).
In a real DMA mode, application make request and get back CPU control immediately. Then applications check syscalls for status every frame (KATANA behavior) and/or waiting IRQ (WinCE behavior).
If we load 500 sectors in PIO mode, it's block CPU for a long time and in game you get lag. To reduce this effect, I divide the reading into parts (emu async value) and read each frame by this part, to prevent block CPU for a long time. But the number of frames in the game still falls, it just happens more smoothly, not jerkily. And it also stretches the overall load time, as we put control of CPU to application through each part.
By this reasons the SD card is a very limited device, it not only has a slow connection, it also cannot read data asynchronously, again due to the connection method.