The Sinclair QL Forum

In case anyone is interested, I have updated my FDI floppy disk image device driver, to support HD and ED disk images, and to also support sub-directories.

It is based on the SMSQ/E device level 3 driver, and can be download here http://www.dilwyn.me.uk/utils/FDI2Driver200.zip from Dilwyn Jones web site.

Looks great, Martin

I just had a quick fiddle at this point; everything seems to work as advertised, at least on QPC.

However, on stressing things a little, I find a few anomalies: I notice that whenever a drive is mounted a channel to the image file gets opened. This channel does not appear to be entered into the S*Basic channel table, so cannot be closed using CLOSE. Unmounting the FDI closes the channel again. But since it is possible to mount a new image to the same FDI drive number without unmounting any previous image, these open channels could keep piling up, requiring an external utility to close them again.

1) Is it necessary to keep an open channel to the image while the drive is mounted? (It would be best if this could be dispensed with..)
2) If it is necessary, then Mount should close any previously opened channel for a given drive number before accepting to mount a new image, or refuse to mount a new image before the old one has been Unmounted.

Also it shouldnt be possible to Unmount or remount an image while files are open on that image, as this causes problems which could ultimately crash the system.

No criticism intended, just trying to be helpful. If you really want a "trial by fire" let Dilwyn have a fiddle: If something can get broke, sooner or later, he will brake it

Per

pjw wrote:No criticism intended, just trying to be helpful. If you really want a "trial by fire" let Dilwyn have a fiddle: If something can get broke, sooner or later, he will brake it

Per

Umm, excuse me, ahem!

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

Still struggling to get back up to speed and catch up with QL things after the bereavement, so poor Martin won't be getting a twenty page list of problems from me in the very near future he'll be glad to hear ...

I would love to be able to get ED image support added to the HxC floppy disk emulator, but we unfortunately could not figure out how the (Super) Gold Card detects an ED disk drive, as it simply refused to recognise the image...

Hi,

There was talk a while back in other circles about using Gotek USB Floppy Emulator that may support IMG files.

There is a very good implementation for the Amiga, that requires a flash update to read Amiga ADF file images.

I have a un-flashed Gotek, which only cost £12 on Ebay from China, not yet tried... I am wondering if the updated driver could read the IMG files on the USB drive.

With regards to QL Disk Interfaces, would FDI work on a Trump Card or other Disk Interfaces that plugin a BBQL.

Derek_Stewart wrote:Hi,

There was talk a while back in other circles about using Gotek USB Floppy Emulator that may support IMG files.

There is a very good implementation for the Amiga, that requires a flash update to read Amiga ADF file images.

I have a un-flashed Gotek, which only cost £12 on Ebay from China, not yet tried... I am wondering if the updated driver could read the IMG files on the USB drive.

With regards to QL Disk Interfaces, would FDI work on a Trump Card or other Disk Interfaces that plugin a BBQL.

FDI?

Certainly the HxC floppy emulator works with disk images for both DD and HD disks when connected to the QL (although you need a (Super) Gold Card for HD disk images). DD's work fine with any QL disk interface with the HxC

pjw wrote:I notice that whenever a drive is mounted a channel to the image file gets opened. This channel does not appear to be entered into the S*Basic channel table, so cannot be closed using CLOSE. Unmounting the FDI closes the channel again. But since it is possible to mount a new image to the same FDI drive number without unmounting any previous image, these open channels could keep piling up, requiring an external utility to close them again.

The image file does not belong to SBASIC, it belongs to the device driver, so would not be in the SBASIC channel table, or be able to CLOSE it.

I thought I had allowed for trying to mount to an already mounted drive number. I will have to have a look at my source code, and test it out.

1) Is it necessary to keep an open channel to the image while the drive is mounted? (It would be best if this could be dispensed with..)
2) If it is necessary, then Mount should close any previously opened channel for a given drive number before accepting to mount a new image, or refuse to mount a new image before the old one has been Unmounted.

1. This could be nasty. Imagine a fetch bytes situation e.g. IO_FBYTE. Open a channel, fetch a byte, close a channel. Open a channel, fetch a byte, close a channel. etc. Or am I misunderstanding what you are trying to say?

2. As I said above I need to check this out.

Also it shouldnt be possible to Unmount or remount an image while files are open on that image, as this causes problems which could ultimately crash the system.

This should (fingers crossed) be no different than popping a floppy disk out of its drive while there are files open. Also if you had a program that crashed while a file was open, you would not be able to unmount the drive.

No criticism intended, just trying to be helpful.

Feedback is good, Someone else testing your code finds all the obvious things that you just miss.

Its years ago since I experimented with (virtual) device drivers under Qdos, so I write in the capacity of an ancient user and not one of the cognoscenti. I vaguely remember trying to tunnel between my driver and another driver using normal Qdos channels and I/O calls but didnt get it to work. To me, without studying your code, it seems that you did manage, as this would explain the open channel to the image file: Your driver's Physical Layer is merely a set of calls to the existing device driver for the medium the image file is on. Is this correct? Youll however notice that on Qdos device drivers dont normally do that. Of course it may be the only solution in this case, since the virtual device is hosted on another Qdos device.. There should be one or two people here who have written device drivers in the more recent past. I hope they will chip in with their insights..

Under the Qdos paradigm attempting to unmount or remount a device that has channels open on it should return an In Use error and not succeed. If the image has somehow been forcibly removed (equivalent to floppy being removed) the dreaded Bad or Changed Medium error is appropriate. As it stands, QPC crashes.

All the best

pjw wrote:Your driver's Physical Layer is merely a set of calls to the existing device driver for the medium the image file is on. Is this correct? Youll however notice that on Qdos device drivers dont normally do that. Of course it may be the only solution in this case, since the virtual device is hosted on another Qdos device..

Basically what the FDI driver does. Is when the SMSQ/E driver would have tried to read/write a slave block, it converts that access to a read/write at the correct position in the image file that is stored on another QL directory device.

Under the Qdos paradigm attempting to unmount or remount a device that has channels open on it should return an In Use error and not succeed. If the image has somehow been forcibly removed (equivalent to floppy being removed) the dreaded Bad or Changed Medium error is appropriate. As it stands, QPC crashes.

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.

The driver should give a 'bad or changed medium' if the image file gets changed 'on the fly'. I will look into it. What did you do that made QPC2 crash? So I can test for that problem.

Derek_Stewart wrote:With regards to QL Disk Interfaces, would FDI work on a Trump Card or other Disk Interfaces that plugin a BBQL.

I have not tried it on a real QL. But I see no reason why it should not work. Of course a Trump card only supported up to double density disks, so you could only have a single density (360k) image file. And if the Trump card did not have a level 2 driver EPROM, directories may be a problem.

However it would be interesting to know if the driver works OK with a QBIDE, or a SD system.

Best Regards