ZX Spectrum Next speaks QL

[Derek_Stewart]

Hi

I think you have this a little mixed up.

The emulator adds the QDOS Header or XTcc trailer.

The NFA device in SMSQmulator does add and header or trailer file, the SFA device does this.

QPC2, sQLux, Q-emulator perform the header or trailer automatically

SMSQ/E does not perform this function.

Not sure what you mean by SMSQ/E format.

[stephen_usher]

The SMSQmulator documentation states that it's using the "SMSQ/e format header" so that's what I typed here.

For example:

Code: Select all

However, suppose you now try to create a new file called "file1" on the SFA drive, for
example by typing “SAVE SFA_file1”. You would expect this to succeed. For the SFA
drive, this would be valid, since, for it, there is no file called "file1" on the underlying
directory, as it only "sees" those with an SMSQE file header. But, of course, on the native
file system to where SFA1_points, there already IS a file called file1, only, because it is not
an SMSQE style file, SFA1_ doesn't show it to you. If you now try to get SFA1_ to save a
new file with exactly that file name, this would means that it would try to overwrite the file
called "file1" in your directory – even though you might not want to do that, since, perhaps,
you only did a DIR of SFA1_ and thus forgot that there is already a file called "file1" in that
native directory.

Anyway, this doesn't matter... this format for use on a native filesystem is already defined and available, so why not use this on the Next's QL core?

The alternative would be to use the XTcc tail on executables.

[Derek_Stewart]

Hi

Yes, but it is not SMSQ/E going this but the device in SMSQmulator.

SFA is not part of SMSQ/E.

[pjw]

QPC2 does this transparently: copy an executable to a DOS device and you can execute it from there directly. The same file is also executable from Q-emulator, and Q-emulator executables are also executable from QPC2.

[Peter]

Can not see that a QL FPGA core relates to software emulators with regard to PC filesystem access.
Like any native hardware, it would require a native FAT32 driver.
The only related project I'm aware of is Tobias' yet unreleased FAT32 driver.
Who knows, maybe the Spectrum Next has motivated him to finish it.

[stephen_usher]

Can not see that a QL FPGA core relates to software emulators with regard to PC filesystem access.
Like any native hardware, it would require a native FAT32 driver.
The only related project I'm aware of is Tobias' yet unreleased FAT32 driver.
Who knows, maybe the Spectrum Next has motivated him to finish it.

It's not the core access as such I was commenting upon but whatever layer does the filesystem translation. In the case of this FPGA core it would be the filesystem driver layer. Because FAT doesn't have the concept of file metadata in the same way as the QDOS one something has to be done to allow executables to work correctly, be it adding a header to all files or adding a tail section.

My comment was about hoping that Pheobus and the team don't create yet another standard but use one of those established by emulators already when accessing native filesystems.

We currently don't know who's code is being used, it could be all new stuff for all we know. From the screenshots it looks like it's running Minerva, so it could be a highly customised Minerva with the whole filing system code replaced, we just don't know.

[Peter]

My comment was about hoping that Pheobus and the team don't create yet another standard but use one of those established by emulators already when accessing native filesystems.

Agreed - and I don't think there is much risk.

From the screenshots it looks like it's running Minerva, so it could be a highly customised Minerva with the whole filing system code replaced, we just don't know.

They distribute binaries, so they need to respect the licences of the open source code in use.
For Minerva, this is the GPL, so the sourcecode of such customizations would have been published. Or at least they should.

If they actually have working FAT32 support for the QL side, I'd rather expect a separate driver like the one from Tobias.
Or some executable tools like those from Leon. But not a heavily modified OS.

[dilwyn]

My comment was about hoping that Pheobus and the team don't create yet another standard but use one of those established by emulators already when accessing native filesystems.

Not directly related to what you were discussing I know, but I agree - no more QL file formats please!

My website can be chaos enough as it is trying to maintain some sort of consistency, I try to keep everything pure QL zipped where possible, but it's hard when people send me QemuLator format files, zipped, within a .MDV or something. Somehow, some with "double QemuLator headers" managed to get in according to a discussion on Sinclair QL For Everyone but until they explicitly let me know which ones on which page I have no idea which ones.

So, please, no new file formats. We already have to cope with QemuLator, QXL.WIN, QLWA, .MDV (more than one type), Qubide, NFA, SFA, XTcc not to mention a few old obscure ones...

That said, ToFro, I am looking forward to the FAT32 system Peter referred to...

[tofro]

That said, ToFro, I am looking forward to the FAT32 system Peter referred to...

Don't hold you breath

[Derek_Stewart]

... so you're not part the Next project to produce this SMSQ/E file system