The Sinclair QL Forum

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.

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

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

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

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'

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
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

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