lordcoxis wrote:That should be right (for 0.8.x at least). Which bits do you suspect are wrong?
There's some confusion about what the bits are doing. Some emulator authors are using at least one of the modes to open files for append writes, which I seem to recall esxdos doesn't do. (I don't have real hardware so I have to test under emulation).
For example, I opened a file with flags "ESXDOS_MODE_W | ESXDOS_MODE_OC" (0x0a) and the emulation caused all writes to append to an existing file.
Maybe this can be sorted out if a description of the mode bits can be spelled out:
# File Access Mode
There is one file pointer shared by read and write
define(`__ESXDOS_MODE_READ', 0x01) # read access
define(`__ESXDOS_MODE_WRITE', 0x02) # write access
define(`__ESXDOS_MODE_OPEN_EXIST', 0x00)
Open if the file exists else return an error.
The file pointer points at the beginning of the file.
Writes will overwrite file contents as the fp moves forward.
define(`__ESXDOS_MODE_OPEN_CREAT', 0x08)
Open if the file exists else create a new file.
The file pointer points at the beginning of the file.
Writes will overwrite file contents as the fp moves forward.
define(`__ESXDOS_MODE_CREAT_NOEXIST', 0x04)
If the file exists return error else create a new file.
define(`__ESXDOS_MODE_CREAT_TRUNC', 0x0c)
Create a new file or empty an existing one.
define(`__ESXDOS_MODE_USE_HEADER', 0x40) # use +3DOS header passed in DE
Also I want to confirm that files opened with both RW mode enabled is allowed. They share the same file pointer so that you can alternate reads/writes and seek through the file. The emulators are not allowing this.
In the bmp2next.c dot command in the zip I linked, I'm doing this for the case where bmp2next is not given an output filename as in ".bmp2next zxnext.bmp". In this case the file "zxnext.bmp" is opened in RW mode so that it can be modified in place. The program reads X bytes into a buffer, operates on it, seeks backward by X bytes and then writes X bytes. This repeats until the entire file has been processed.