SMSQ/E Executables

[Derek_Stewart]

Hi,

I was entering a message on the QL Facebook group with regards to the Q68 and storage container files:

https://www.facebook.com/groups/3069939 ... _tn__=R]-R

When a comment was entered that SMSQ/E could save QDOS executable header information on FAT12 system:

SMSQ/e has solved this by modifying the name in FAT systems. Unfortunately that driver only works up to FAT12. Ergo the simple yet effective manipulation of the time field I was talking about above, which can store the header info just fine and can be also transmitted, copied through diverse systems without loss. An emulator should not be mandatory to transfer files between QL and foreign systems. It makes life much harder. We have evolved from the time where FAT meant "PC". Now FAT is just a FS on a medium which we can take from our Mac to our Spectrum Next to our PC to our phone. The QL should just read and execute off it

Does this mean SMSQ/E on a FAT12 system, does ot need an extra header or trailer?

[dilwyn]

Well, I knew that QPC2's DOS driver could save executables with a QemuLator-style header from v5.00 of QPC2. As far as I knew, it was exclusive to QPC2's DOS driver, though. Would love to be proven wrong though!
EDIT: I should have read the full thread first before replying, I misunderstood what he was on about, so my answer above is a little irrelevant. But I'll leave it there as some might not know that QPC2 can do a QemuLator with native drives.

[Derek_Stewart]

Hi,

I thought the emulator programme: QPC2 v5, SMSQmulator, SQLux, Q-Emulator added QDOS header or trailer to store the executable information.

The emulator programme then removed this header/trailer when moved to a QDOS environment.

What is being implied on the QL Facebook Group, is that SMSQ/E has this functionality built into the operating system if a executable file is stored on a FAT12 filesystem, which I take to be a Floppy Disk formatted on Windows or MSDOS. I have never knew about this. Is this correct?

[tofro]

Hi,

I thought the emulator programme: QPC2 v5, SMSQmulator, SQLux, Q-Emulator added QDOS header or trailer to store the executable information.

The emulator programme then removed this header/trailer when moved to a QDOS environment.

What is being implied on the QL Facebook Group, is that SMSQ/E has this functionality built into the operating system if a executable file is stored on a FAT12 filesystem, which I take to be a Floppy Disk formatted on Windows or MSDOS. I have never knew about this. Is this correct?

Erm, no.

SMSQ/E puts a header for a file onto the file system if this allows it, and not, if there's no room for it. (FAT12, like all foreign file systems, has no room for a file header).

The emulator might put a Q-Emulator header in front of files on file systems that normally have no room for that. But that's completely transparent to SMSQ/E itself and rather done in the emulator. If the file a header is requested for by the OS contains a Q-Emulator header, that one is delivered, if it doesn't, an empty one is created on the fly. If a file contains a QL-emulator header, the emulator will offset all its reading and writing to the file contents behind the header.

Someone must be confused on facebook what is the emulator and what the executed OS.

[dilwyn]

Sorry, I think I confused everyone with my reply since I didn't understand it correctly when I first read it.

I think Phoebus and those involved with that project (I think it was in the context of QL core for the Spectrum Next) meant something completely different, and weren't referring to placing additional data at the start of the file. Sounds like he was hinting that dataspace or some other aspect of the header might stored somewhere in the time or date area of the native file system. If I'd read Derek's quote properly or followed the link to see the full conversation I might have understood a bit better.

As tofro said, the QemuLator/QPC2 method slightly modifies the QL file by adding a small preamble at the start of the file when saving to a native drive, documented in the QemuLator manual, and automatically removes those extra bytes when copying to a QL format medium such as a ramdisk or QL floppy disk. It's only of concern if you send a file to someone copied or zipped directly from a native format drive - it's then that it actually becomes a nuisance as that file needs to have those extra bytes removed to work properly on a QL.

Don't know how what they mentioned works, and it was said in the context of a floppy disk, not a hard disk anyway.

Apologies for causing the misunderstanding.

[Sparrowhawk]

I think it was in the context of QL core for the Spectrum Next

Can you say more, for those of us not on Facebook? - In another thread if it's likely to spawn a discussion and hijack this one? (it will, I will pester you for more info ) I know there was one as a work in progress by Victor Trucco, but apart from some screenshots a few years ago, I have not heard whether it got anywhere.

[tofro]

I think it was in the context of QL core for the Spectrum Next

Can you say more, for those of us not on Facebook? - In another thread if it's likely to spawn a discussion and hijack this one? (it will, I will pester you for more info ) I know there was one as a work in progress by Victor Trucco, but apart from some screenshots a few years ago, I have not heard whether it got anywhere.

Yep, that would be interesting. I don't book face as well.

[dilwyn]

I think it was in the context of QL core for the Spectrum Next

Can you say more, for those of us not on Facebook? - In another thread if it's likely to spawn a discussion and hijack this one? (it will, I will pester you for more info ) I know there was one as a work in progress by Victor Trucco, but apart from some screenshots a few years ago, I have not heard whether it got anywhere.

OK, here is a short summary from the Bookface discussion for those not on there (all stolen without asking permission, and IMO not worthy of a separate thread as there is no more information ATM).

On his Facebook page Phoebus Dokos posted QLKS1.7z with the description "ZX Spectrum Next KS1/N-Go/X-Berry Π only: C:/MACHINES/QL . Press C upon boot" and posted this picture:

Photo of Next running QL core

A discussion followed where one prson asked if it was "a QL core for the Next or something Phoebus Dokos? At 32 bit (or is it 16bit) processor for the Next?" and Phoebus replied that it was a 68010 in there and said "theoretically speaking SMSQ/e can run; but the core is just dumb. I am actively looking for someone to improve it"

He also said "I’m actively looking for someone, that a. Knows enough VHDL, b. Knows the QL or is willing to learn. Any Next QL core shouldn’t be as bad as the MiST(er) core; it must be closer to the Q68 ie a real implementation and hopefully improvement over an original QL. I'm also thinking to offer a bounty for said improvements under the precondition that the resulting core will stay open-source. In the meantime I've sourced VHDL for ZX8301 (improved one with 16 colours) and several other peripherals that have been present in the QL's past and are relevant today. "

Someone else asked if this was the core ported to Next KS1 by V Trucco and the answer given was Yes.

Bear in mind, this was 7 weeks ago, and was cautioned elsewhere in the discussions as "Thank me when it works properly. Now it's a mess."

[Sparrowhawk]

Thanks Dilwyn. Potentially psoitive news re QL on a Next then.

[Derek_Stewart]

Hi,

I asked advice from Wolfgang Lenerz.

Who had a quick look at the code, that seems to be true (the file is given the extension"EX"), but he did not didn't really investigate any further (file dv3_msd_drset_asm).
The file date is in 1998....

So it would seem, that an executable file coukd be stored on a FAT12 Floppy Disk and the executable information still be in tact.

I do not know whether this works or not.