Re: [hatari-devel] GEMDOS emulation and host-side DTA caching

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 2/16/20 11:21 AM, Christian Zietz wrote:
> seen here: <http://www.atari-forum.com/viewtopic.php?f=51&t=38406>. A
> user wanted to copy a complex directory tree from a GEMDOS emulated
> drive. The recursive Fsfirst/Fsnext required to do so exhausted Hatari's
> tiny [1] host-side DTA cache, therefore resulting in only a partial copy
> operation.
>
> A simplified test case is attached. It needs to be run from a GEMDOS
> drive C: with some files on it. Also the folder C:\TEST has to exist and
> it too needs to contain some files. Expected behavior is getting a file
> name from C:\, but the test program will output a file name from C:\TEST
> instead.
>
> I don't have a solution for this; I just wanted to bring this up to
> discussion. Ideas I came up with:
>
> - Simply increasing the cache size, like the user did.
>   Only makes the issue less likely, but easy to implement.

I'm inclined to this solution, but I'm wondering
about the gemdos.c code comments:
----------------
#define  BASE_FILEHANDLE     64    /* Our emulation handles - MUST not 
be valid TOS ones, but MUST be <256 */
#define  MAX_FILE_HANDLES    32    /* We can allow 32 files open at once */
----------------

Why it says "can allow"?  (Thomas?)

Are there Atari programs that break if more file
handles are "allowed"?

(Large handle values do break some programs, which is why 
BASE_FILEHANDLE can't be increased.)


> - Somehow cram all host-side state into the Atari-side DTA, more
> specifically its 'reserved' field. Probably not doable, also dangerous
> because the emulated program could corrupt the host-side state.

Won't fit as host side state includes things
like the host path for the file name.

(Host paths are needed when Atari programs
wants to get or set file mode, and for error
logging.)


> - Instead of linearly incrementing the index of the host-side DTA cache
> entry, using a hash of the Atari-side address of the DTA as index into a
> (sufficiently large) array. Collisions can still occur, but if an
> application (like my test program or the Desktop) reuses DTAs, this
> makes sure that an unneeded cache entry is overwritten instead of a
> potentially still needed one.

I.e. some kind of index, like the DATA address
is needed.  Normally programs don't use many
handles so maybe even sorted array could be
used instead of a hash (*).


	- Eero

(*) This assumes file open & close for adding
& removing file handles are much more rare operations in Atari programs 
that operations
done using those handles (read/write/etc)...