IIRC filenames on a FAT system should only ever be stored in uppercase (I'm not talking about Win95+ long names but about the 8.3 names that DOS uses). It's up to the software how to display it of course, but in the directory blocks on the actual medium it should be uppercase only. I have the feeling that that port doesn't do this for some reason. Unfortunately I don't have the necessary hardware to try it out.

Edit: How do you access the SD card? Do you mount it under Linux and then run DOSBox on the mounted file system. or does DOSBox directly access the raw block device?

I'm reasonably sure that it's mounting the SD card, and not directly accessing it. I'll ask the author to confirm this.

It acts as if the specific filename case (per character for the entire name) is hard-coded into the game, and it's attempting to read the files from the file system in that specific filename case. Thus, it tries to read objblkBC, doesn't find OBJBLKBC, and it promptly croaks.

Have you had a chance to test this in Linux?
If it doesn't happen in a PC Linux environment with vanilla DosBox 0.72, then I'm completely baffled by this problem, since I'm positive that the authors didn't modify any code related to the read/write functionality while porting it.

Note that the complete source code for the port is available at:
http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,46,2586

On my PC Linux (Ubuntu Hardy 64-bit) it works fine, on a VFAT file system, on a MSDOS file system, and on an Ext3. I don't keep dosbox 0.72 around however, I used the most recent CVS version.

I could sort of reproduce your problem (saving became impossible) by mounting a MSDOS file system with -o check=strict. Maybe that is your problem? Though I doubt it. But I do recommend you read the mount(8) man page and check whether any options could help. Also try both -t msdos and -t vfat. For -t vfat, you could maybe try experimenting with the different -o shortname options.

Edited this post: removed unintended smiley.

I think you may have nailed what the problem was. However, I don't know how the GP2X mounts the SD card, as it's done automatically at boot.

There's one way to be sure, though. When you reproduce the error, does it say that it can't read the file objblkBC? If that's what it's saying, try renaming the file to that exact filename case ("objblkBC"). Then see if it halts/loops on a different file.
If it does, then I'm almost completely sure that mounting is the problem.

Would there be a way to modify DosBox's read/write behavior to account for this?
Since this is for only this particular port, and mounting is done automatically, it would be preferable to do it code-side.

If it is possible, please point out where the relevant code resides.

At least for the meantime, I can experiment with remounting the SD card in a virtual terminal to confirm this.

Skutarth - Please note that the GP2X port of DOSBox is not done, nor maintained, by any of the developers you will meet in this forum. If you have suggestions for changes to the port, you have to get in contact with the GP2X porter.

Skutarth wrote:

There's one way to be sure, though. When you reproduce the error, does it say that it can't read the file objblkBC? If that's what it's saying, try renaming the file to that exact filename case ("objblkBC"). Then see if it halts/loops on a different file.

Unfortunately that's not possible. -o check=strict on an ms-dos file system disallows uppercase in filenames.

Minimax: He is aware of that, I suggested that he should post here to get some more ideas on the problem.

I think looking into the mounting is a good idea. Skutarth you may want to look at the fstab file. The automounting to /mnt/sd may be done there.

Using Termula2x, fstab reports the SD card to be mounted as:

/dev/mmcsd/disc0/part1
/mnt/sd
vfat
iocharset=utf8,sync,noatime,rw 0 0

The fstab file might not tell the true story. Better (if possible) check how the actual mounting looks like. Or maybe do some experimentation on the mounted disk. Make some files from that Termula2x (a terminal emulator?) with names in lowercase, uppercase, mixed case, etc, and see how that goes.

Blah. I'm going to need to set up tel-net via USB connectivity.
I'll be back once I can sort out exactly how it's being mounted.

I think I cracked the egg.
I'm pretty sure mounting was the issue.
It may have been because I launched Dosbox from telnet, but I doubt it.
Here's how I mounted it for it to work:
umount /mnt/sd
mount /mnt/sd -t vfat -o rw,sync,noatime,check=r

I'll be back in a second to find out whether or not it will work by executing a shellscript.

EDIT: Blah, I didn't think about it until now, but you can't unmount a filesystem from a shellscript on it. If I run it from nand, it should work. Be back soon.
Also, I was dumb when mounting above. Fixed.

That shell script could copy itself to /tmp, ~/tmp or whatever, do a cd / (to get away from the mounted FS), and then exec the copy in /tmp.

It does work off of internal flash memory.

MiniMax wrote:

That shell script could copy itself to /tmp, ~/tmp or whatever, do a cd / (to get away from the mounted FS), and then exec the copy in /tmp.

Was just trying that, actually.
It keeps telling me the filesystem is busy if I do it that way, though. Hm.
But if I do all of the commands via telnet immediately after boot (including copying it to /tmp first, and running it from /) it works.
If I execute a shellscript from another shellscript, does the original shellscript continue to run, or something?

Skutarth wrote:

If I execute a shellscript from another shellscript, does the original shellscript continue to run, or something?

Of course. It will hang around, waiting the the sub-shell (the child process) to finish and pick up the exit status. And if it (the parent process) have it working directory on the mounted filesystem, then you are can not unmount it.

Using

exec /path/to/script

instead of the usual

/path/to/script

will cause the existing process to abort what it is doing and load /path/to/script into memory and start exec'uting that instead of the old script code. So now you do not have a parent/child pair, just the (reborn) parent.

Everything is up and running. I'll just have the shellscript remount to the original filesystem settings upon exiting Dosbox.
It'll be tedious to do this for every game that has compatibility problems like this, but this is the best possible solution.
It will be funny if I find out GPH changed the mount settings in another firmware. At least it will now work with the firmware I have, and technically this method should work for any firmware that has problems.
I'll be sending this to Pickle so he can add it to the readme for the next release (not that anybody tries reading readme files, anyway).

Thank you for all the extremely constructive posts.
Case closed.