Problem Creating file on DOS device

[Martin_Head]

I've just run into a problem creating a file on a DOS device in QPC2. I thought I would ask here before I spend a lot of time investigating it, in case it is a known problem.

I have written a machine code SuperBASIC procedure which creates a file. It works fine if I create the file on FLP. But if I uses the same command, and just change the device to DOS. The command does not complete, but you can CTRL-Break back to basic.

On the DOS device the file is created, but nothing is written to it.

I create the file with an IO.OPEN trap, with D3 set to =2 new(exclusive)file.

The DOS device is OK, as I can do a DIR on it fine.

[Paul]

Not knowing anything about floppy, dos devices or system calls,
Can you save to the dos device?
Kind regards
Paul

[tofro]

Martin,
maybe the problem is with the name of the file - The DOS device is sometimes a bit picky with names that contain specific characters or where part of the name aligns with a DOS directory.
Check whether you can save to a file of that name directly from basic.

Tobias

[RWAP]

Can you let us know what the name of the file is - that is the easiest way of checking...

[Martin_Head]

I need to do some more investigation. But late yesterday I had a quick look.

I separated the command from the rest of the application it is in, in case something else was getting in the way. But I still seem to have the same problem.

I can access the DOS device from BASIC with a OPEN_NEW -- PRINT something -- CLOSE. which works fine, and the file is created on the DOS device.

The command seems to work fine when asked to create a file on Floppy or Win, but leaving the command line the same, and just changing the device e.g. flp2_ to dos6_ the command fails. Or rather it does not complete, but a CTRL-Break will return to Basic with a Incomplete error.

Can you let us know what the name of the file is - that is the easiest way of checking...

Nothing special just "dos6_dostest", and "dos6_test_img"

Theres nothing in my program that looks for a CTRL-Break. So I'm guessing either the IO_OPEN, IO_SBYTES, or IO_CLOSE traps are not completing in the routine, and one of them is detecting the CTRL-Break.

I doubt it's the CLOSE, as nothing is written to the file. It could be the IO_SBYTES failing on the first use, or the IO_OPEN never finishing. I plan on trying to trace the program through opening a file on the DOS device to see what happens.

I also tried the routine in Qemulator, attaching FLP2 to the same folder as the DOS device. And the command seemed to work fine. Although in the command I was referring to FLP2_ and not a DOS device.

I've attached a copy of the code and the assembler source. If anyone wants to try it.

The procedure creates blank floppy disk image files.

Just LRESPR test_cde

It adds the keyword MAKE_FDI "filename","Diskname","size" - where size is "s" for 360K and "d" is for 720K

example - MAKE_FDI "flp2_test360","Work","s"

Creates a disk image file named 'test360' on 'flp2_', of 360K, with a medium name of 'Work'

[tofro]

The "not complete" is a sign that the dos drive is mounted to a dos/windows device that doesn't exist.

If I mount dos2_ to "D:\" (which is not a valid drive on my system) and do a

Code: Select all

SBYTES dos2_test,1234,1234

or anything else that accesses that dos drive, QPC2 will come back with a "not complete".

Saving to an existing drive works well here.

Tobias

[Martin_Head]

I think I've found the problem. Line 236 of the assembly listing has a 'move.l' which should have been a 'lea' .

Instead of setting the pointer to a position in the buffer for IO_SSTRG, It was setting the pointer to minus 1. I don't know why the FLP, WIN, and RAM device drivers didn't care, but the DOS device driver did.

When I traced the program through with a monitor, the IO_SSTRG trap was called, and it did not return.
I guess when I pressed CTRL-Break, the operating system ended the trap call with a Not complete error which my program picked up and returned.

Thanks for the assistance
Martin Head