The Sinclair QL Forum

Martin_Head wrote: I checked the source code, and I had not allowed for an attempt to mount to, an already mounted image file. It should not be a problem to sort out, and to give an 'in use' error if you try to do it.

Id reserve the In Use error for the case when one tries to unmount an image when there are still files open on it. You might consider allowing an implicit Unmount on mounting a new image to the same drive as an already mounted drive (provided, as before, no files are open on the current image). If (for whatever reason) this is not possible, trying to mount a new image on a drive that already has a image mounted, could perhaps fail and return a Not Complete (-1) error?

The driver should give a 'bad or changed medium' if the image file gets changed 'on the fly'. I will look into it.

Considering the way you have implemented the driver, off the top of my head I cant think of a situation where this condition would occur: Presumably the driver for the device the image is on would detect that and return the error to your driver?

What did you do that made QPC2 crash? So I can test for that problem.

I wasnt able to replicate the problem in the time available. I suspect the point is moot once the other issues are resolved.

dilwyn wrote:Goes back to DJC days actually, ask the authors who wrote for DJC for proof of that particular ability!!!

Speaking as one of the afore mentioned authors, I think it was called "Peer Review"

My wife, Alison, is a professional software tester. She gets paid to break software!


Cheers,
Norm.

pjw wrote:

The driver should give a 'bad or changed medium' if the image file gets changed 'on the fly'. I will look into it.

Considering the way you have implemented the driver, off the top of my head I cant think of a situation where this condition would occur: Presumably the driver for the device the image is on would detect that and return the error to your driver?

The test I have been trying over the weekend is to mount an image, open a file on that image, unmount the image, mount another image, and then try to read from the previously opened file.

I would have expected an error of some sort (bad or changed medium?), but it does not error, it may return nothing, or just wait, or rubbish? I think I will try the same thing with a couple of real floppy disks to see what the real thing does in that situation.

Looking at the code reminded me of why I thought this 'disk swapping' was handled already. The SMSQ/E driver seems to have a flag system, that monitors if a drive is rotating. During an OPEN, if the drive is rotating then it could not have been changed since the last time it was checked. If it has stopped rotating then it may have been changed, and needs to checked. My mount and unmount commands set the flag to stopped, so that the next time OPEN is called it knows to check for a disk change.

So I was working on the theory that once the image file is flagged as rotating (the OPEN routine does this), it never stops until its unmounted. But I now don't think that the I/O routines check if the drive has stopped (as a floppy may). So by opening a file, unmounting an image, then mounting another image. The I/O routines think nothing has happened. I'm not sure how the real thing handles I/O if the drive has stopped. Unless its handled by the slave block mechanism (which I don't use).

I may need to add a check in the I/O, and maybe the CLOSE routines, to check if the drive has stopped, and return an error (bad or changed medium?).

Sorry if I've rambled on a bit...Now I hesitate to ask, but there's been no mention of any problems with using the driver itself. So do I take it that it seems to be working OK otherwise.

Martin.

Martin,

I did not stress test the FDI driver or push against the edges, but I was able to EXecute, Load and Save to the drive on QPC without problems. Hopefully more feedback will come.. (In the QL world, no news is assumed to mean good news, as people are quick to point out errors but determinedly tight-lipped when things work

To my mind (given the caveats as to competency already declared) many of the issues you mention will vanish if you 1) disallow remounting before unmounting any previous mount to a given device number. Surely, that is entirely under your driver's control? 2) Unmounting must be conditional on there being no files open to the device. (There is a counter in the physical definition block specifying the number of channels open to a given device number. Perhaps that could be used?)

I dont know if this is relevant to your implementation, but here is a comment by Marcel (QL-users, "Microdrives for Q40", May 2000) that may give some indication:

Fabrizio [] wrote:
> Btw, does anyone know why i have to perform a "DEL_DEFB" command
> after having swapped (hot) the md , before to see the right content?

Marcel:
The driver doesn't see that the drive has changed and thus returns the
contents of the slave blocks. Perhaps you can label it as removable
through the WIN_REMV command.

Per

pjw wrote: To my mind (given the caveats as to competency already declared) many of the issues you mention will vanish if you
1) disallow remounting before unmounting any previous mount to a given device number. Surely, that is entirely under your driver's control?

2) Unmounting must be conditional on there being no files open to the device. (There is a counter in the physical definition block specifying the number of channels open to a given device number. Perhaps that could be used?)

1) Done

2) I agree with what you are saying, but I'm a bit hesitant about this, Firstly I'm not entirely sure on how to find the correct Physical Definition Block for that drive. You need the device number and the drive number. The drive number you know e.g. FDI2_, but I guess to get the device number you need to scan the list of directory device drivers to find the FDI driver, counting them as you go. Once you have found the correct Physical Definition Block, you could then set the number of open files to zero. But do you then remove the Physical Definition Block (the DEL_DEFB command above)? And what about the Channel Definition Blocks for the open files? Where do you draw the line? And at what point do you start to tread on the toes of the Operating System?

After all with a real floppy disks there is nothing stopping you popping out the disk at any time. So the Driver/Operating System should be able to handle it.

I wrote: The test I have been trying over the weekend is to mount an image, open a file on that image, unmount the image, mount another image, and then try to read from the previously opened file.

I would have expected an error of some sort (bad or changed medium?), but it does not error, it may return nothing, or just wait, or rubbish? I think I will try the same thing with a couple of real floppy disks to see what the real thing does in that situation.

With real floppies you get a bad or changed medium error eventually, after the old slave block empties and it tries to read another.

Whereas the FDI driver was returning not complete, which is why nothing seemed to happen. I've stuck a test into the I/O routine to see if it thinks the drive is still turning, and return bad or changed medium if not. But I've not had a chance to test it yet. Other that that the FDI driver seems to behave the same as the FLP driver when swapping disks about.

If you or anyone else would like a copy of this work in progress, just say and I will post it here. I would like to iron out as many problems as I can before I send it to Dilwyn Jones as a new version.

Martin.

There's been no mention here for a while of any more problems, So I will assume no news is good news, and release version 2.01 of the driver.

I've emailed the update to Dilwyn Jones for his website.

The main fixes in the new version are -

Blocks the mounting of image files to FDI slots that already have a mounted image file.

The checking for changed image files has been tightened up, giving a 'bad or changed medium' error if I/O is attempted after an image file is changed.

Fixed the driver not working with JS ROMS.

Fixed FDI_FILE$ not returning the image files name.

Martin.

Does it support IMA Images made with WinIMAGE? Does QPC2v4 Support those Images?

Ralf R. wrote:Does it support IMA Images made with WinIMAGE? Does QPC2v4 Support those Images?

I'm not familiar with IMA image file format. The driver supports images that are plain sector by sector copies of the original disk, with no extra information added. You could just try one, and see if it works.

If you look at the file size of the IMA file, it may indicate whether the image has any extra information stored. A 720K (DD) image file suitable for the driver would be 737280 bytes (1440 sectors of 512 bytes).

Martin