Re: [hatari-devel] Maybe a gemdos bug, I don't know

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 13 kesäkuu 2012, Laurent Sallafranque wrote:
> In my program, I have the following :
> 
> toto_01l:        dc.b    "DATA\CHARS\TOTO0\BIN_LEFT\IDLE1.SPR",0
> toto_01r:        dc.b    "DATA\CHARS\TOTO0\BIN_RIGHT\IDLE1.SPR",0
> 
> 
> I load these files with the loader.s rout from DHS (thanks to them for
> this code).
> 
> On hatari, it loads well and I don't have any problem, while on my real
> falcon, I get the following message :
> 
> DATA\CHARS\TOTO0\BIN_RIGHT\IDLE1.SPR not found
> 
> I think this may due to the 9 characters of the directory, but hatari
> and my Falcon don't behave the same here.

I've now written a test program that tries different cases where
program gives larger file name than 8+3 characters and in *ALL*
cases all TOS versions for 1.02 to 4.04 are able to handle them
fine.

Test program, test files and the sources are included on
the attached test disk image.


So, I think the problem isn't that the name you gave was longer than
the directory name, but that it was different than the directory
name.  For example your directory name was "BIN_RIGH.T" and you
tried to find it with name "BIN_RIGHT".


I'll make Hatari GEMDOS emulation to clip both parts of the file
name and give warning about that.


	- Eero

Attachment: fopen.st.gz
Description: GNU Zip compressed data