The Sinclair QL Forum

If I navigate my way to a floppy image at startup, and choose it, I get told off as the "Path was not found". However, as my images live in /data/FloppyImages/ then I can type in the full path for the flp1_ and flp2_ drives as \\?\unix\data\FloppyImages\whatever.img and it will be recognised as a floppy image. Yes, the question mark is required!

Or you could do the sane thing and map that location to a drive letter for that application

XorA wrote:Or you could do the sane thing and map that location to a drive letter for that application

Now where would be the fun in that?

Cheers,
Norm.

RWAP wrote:The better solution would be to ensure that all emulators and QLs supported the q-emulator method of saving direct to (and of course loading / executing from) DOS formatted devices so that those new to the QL scene (or returning after many years) would not even have this query!

There's a reason why I don't do this. When you do a "dir" command the QemuLator method must open every file in a directory to check if there is a file header. That's nice if you have directories with 10 files in it but doesn't scale for directories with 3000 files. And yes, that is a valid usage scenario for me.

Another method is to have a database in a separate file in the directory that holds the header information. This is the method MacOS X uses or even Windows for saving the preview thumbnails for pictures. Better, but has it's own drawbacks like that the header will get lost when you copy the file from within Windows. Also the additional file can be annoying.

3rd method is used in the FLP driver, add the data space to the filename (e.g. xyz.EX2). The added part is hidden from SMSQ/E. Rather hackish but ommits the problems outlined above. Creates problem that two files could potentially have the same name on the SMSQ/E side.

4th method is saving the data in alternative NTFS data streams. This is a little known feature in the NTFS file system and most closely resembles the way the QL headers works, but it shares some problems with the QemuLator method and when I first thought about it 10 years or so ago many machines were still FAT based so it wouldn't have worked for many users. Also probably doesn't work for ZIP files.

5th method is used by SMSQmulator and uses two different devices. One device behaves like QPC, one more like QemuLator. You must always remember which device you used with which directory. I don't quite like this.

So this is a rather complicated problem and I have spend many hours thinking about it. The QemuLator way is pretty pragmatic but I mostly don't like it from a performance point of view and because it alters the file contents. Unfortunately there is no "good" method, which is why so far I opted for "no" method. Sorry about that.

Marcel

Thank you for the detailed explanation, Marcel. It addresses one of my concerns, that we may end up with a number of different solutions across different emulators and so on.

While I understand what you say about the QemuLator method, at least QemuLator is pragmatic in that if you copy an executable from a native Windows/Mac directory, it "unmodifies" the executable to remove the extra information when copied to say ramdisc or floppy.

Probably the best solution is for us all to be aware of WHY this executable file problem occurs in the first place, but I guess I will never see the day when nobody downloads a file from my site, unzips it in Windows then claims the zip file is broken.

dilwyn wrote: Probably the best solution is for us all to be aware of WHY this executable file problem occurs in the first place, but I guess I will never see the day when nobody downloads a file from my site, unzips it in Windows then claims the zip file is broken.

The easiest for this would maybe be a disclaimer box on websites that offer QL downloads:

Never complain about the integrity of downloaded QL zip files, especially not to Dilwyn - He might send you a welsh dragon. Instead look here...

[OK] [Cancel download]

Tobias

tofro - he he.

Hi,
Now I can transfer files without ZIP as mentioned to USB keys, and recover them back again.

However, I am getting incorrect results from the DATE function within QPC2_Turbo_compiled tasks : I always get the same value returned at every call !

Any suggestions?

Regards,
Steve Poole.

stevepoole wrote: However, I am getting incorrect results from the DATE function within QPC2_Turbo_compiled tasks : I always get the same value returned at every call !

That's weird. Can't second that.

Can you verify this with a simple one-liner (100 PRINT DATE) compiled? Be aware DATE called more than once per second will return the same value.

Tobias

Hi,
Egg on my face...

Yes, a three-liner worked OK.
I was running the basic program without clearing the screen before running the EXEC code.
I had forgoten to place a PAUSE before STOP at the end of the basic.
The result was that the task stopped and left me with the basic program timing on screen again.
So ecery time I EXECed with different input values, I got the same timing left on screen!
Nasty, especially as I never met this problem beore...

Many thanks,
Steve.