Software incompatibilies?

[belg4rion67]

Hi, my configuration is: standard QL with issue 7 board, Rom Minerva ver 1.98 + TKII ver 2.13 + Sandy fdd interface with 512k ram on board and another TKII:
I've tried to transfer some of demo program stored in Dilwyn site to floppy disk and run it but often when there is a bytes part to load with lrespr or exec_w my system report bad parameter...only basic programs works properly and even with the old JM rom my ql has same problem
Can someone help me to check this strange issue?
Many thanks

[RWAP]

Are you enabling the Toolkit II ROM (needed for LRESPR especially):

Add TK2_EXT to your boot file.

[dilwyn]

Hi, my configuration is: standard QL with issue 7 board, Rom Minerva ver 1.98 + TKII ver 2.13 + Sandy fdd interface with 512k ram on board and another TKII:
I've tried to transfer some of demo program stored in Dilwyn site to floppy disk and run it but often when there is a bytes part to load with lrespr or exec_w my system report bad parameter...only basic programs works properly and even with the old JM rom my ql has same problem
Can someone help me to check this strange issue?
Many thanks

Bad Parameter when using EXEC or EXEC_W usually means that the executable file header has been lost in transfer. It is always best to move the .zip file you have downloaded onto a QL disk (or emulator) before unzipping it. Non-QL operating systems such as Windows don't understand QL file headers and break them.

It's also possible there may be some dud zip files on my website. One example of this happened fairly recently where the Infocom adventure game packages and utilities had lost their executable headers before I zipped them up on the QL so I had to go back to source to find intact versions.

Can you let me know which packages this happened with? I can then check and test them to see if I have accidentally put dud versions up on my website.

If you are unsure about the whole file transfer thing, the easiest and most reliable method is to copy the .zip file to a QL disk. Make sure you have a copy of QL Unzip on a disk - it is a sad catch 22 that you normally have to have a copy of Unzip toUnzip the copy of Unzip... so best thing is to use the self-execute SFX version if that works on your system. If not, download the Unzip binary and the little SuperBASIC patch program which is used to restore the Unzip program's file header. Both are available on the Archivers page on my website. Scroll down to the Unzip section and read the bit about the special unzips.

Emulators can be different, but with a standard QL it is always best to transfer the zip file to a QL and unzip it there.

It may be that in your case it has nothing to do with this of course (hard to tell without hands on the system concerned).

Dilwyn

[belg4rion67]

Many thanks Dilwyn, I'll try your suggest to use zip file; however issue described to me was succeded with trial version of D-Day mk2 from RWAP: it give me bad parameter at line 17 of third step of booting during execution of "EXEC_W flp1_day_deployment" instruction... I think that your hint is right because some other programs that use LRESPR or EXEC_W works fine (ie PSION software packages or QL Chess)

Cheers

[nichtsnutz]

Hello Dilwyn,

I have a question about the executable header of the files.I have backuped all my readable microdrives using a custom made PC program over the serial line of the QL.I have done this
with the command "copy mdv1_filename to ser2z" and the command sends a 14 bytes header
over the serial line to the PC.I have not saved the header infront of the binary.Is this wrong ?
Do I have to save this 14 bytes header ? I read yesterday in the QL Technical Guide that the header
includes the length of the dataspace for the executable (job?).
I guess that I will have to save all the files again!
Maybe you know the exakt file format that I have to use ?
I unfortunately do not have programmed the other way until now.

Thank you very much in advance,
Vassilis

[dilwyn]

Hello Dilwyn,

I have a question about the executable header of the files.I have backuped all my readable microdrives using a custom made PC program over the serial line of the QL.I have done this
with the command "copy mdv1_filename to ser2z" and the command sends a 14 bytes header
over the serial line to the PC.I have not saved the header infront of the binary.Is this wrong ?
Do I have to save this 14 bytes header ? I read yesterday in the QL Technical Guide that the header
includes the length of the dataspace for the executable (job?).
I guess that I will have to save all the files again!
Maybe you know the exakt file format that I have to use ?
I unfortunately do not have programmed the other way until now.

Thank you very much in advance,
Vassilis

You may be OK by doing this - the essential executable file details are contained within the first 14 bytes of the header, including the file type byte and dataspace value for executables. This should be enough to restore the backup when moved back to QL.

I haven't saved backups in this way before, so I can't be 100% confident it will work although I can't see any obvious reason why it should not work correctly. Of course, QL files saved on a PC in this way can't be executed on the PC, but for backups I hope it will be fine.

In theory, all you now need to do to restore a backup is copy the file back to a QL, then using code like this to re-save the file - this is just an outline not a working program of course.

1. allocate enough space to load the file into heap memory on the QL
2. remember that because the total length of the file is original length+14, set the save start point to 14 bytes from the start (i.e. just after the 14 byte header preamble you added) and reduce the total file length by 14
3. check file type byte
4. if file type is 1 (executable program file) then
5. SEXEC the file from base+14,filelength-14,dataspace of PEEK_L(base6),filename
6. else
7. SBYTES the file from base+14, filelength-14,filename
8. end if

In the past, I have saved QL files to a PC by making two separate files, one the file itself, the second holding a 64 byte copy of the header. I called it "QH" and it's on my website somewhere. If your method works (I think it should) it is probably a better method than mine.

Good luck with this, it's a great idea for a backup system! Of course, the serial link will be slow but this is probably not too important since QL files are usually pretty small.
Dilwyn.

[dilwyn]

Many thanks Dilwyn, I'll try your suggest to use zip file; however issue described to me was succeded with trial version of D-Day mk2 from RWAP: it give me bad parameter at line 17 of third step of booting during execution of "EXEC_W flp1_day_deployment" instruction... I think that your hint is right because some other programs that use LRESPR or EXEC_W works fine (ie PSION software packages or QL Chess)

Cheers

It is always a difficult issue and hard to detect, because files look normal and no error message occurs when copied between website-pc-QL. Then the QL gives a Bad Parameter error which doesn't always described what happened very well. For someone who isn't yet very confident in using a QL it can be a very difficult issue to resolve.

It usually affects the EXEC/EXEC_W program files. It doesn't always affect LRESPR files, luckily.

Dilwyn

[nichtsnutz]

Hello Dilwyn,

thank you for your awnser.I have changed my small program and I do save the header too.(Unfortunately another Microdrive got unusable by the process of using it to much.If I loose one mdv every month then near the end of the year I will not have any left )
I will also try the other way around as you have suggested but I need some more time to experiment
with QDOS calls and SBASIC.
Also thank you and the other people at the ql-list for the superforth packet,I am learning a bit C1-Forth and the Superforth manual has more explanations for a newbe like me.

Greetings,
Vassilis

[dilwyn]

Hello Dilwyn,

thank you for your awnser.I have changed my small program and I do save the header too.(Unfortunately another Microdrive got unusable by the process of using it to much.If I loose one mdv every month then near the end of the year I will not have any left )
I will also try the other way around as you have suggested but I need some more time to experiment
with QDOS calls and SBASIC.
Also thank you and the other people at the ql-list for the superforth packet,I am learning a bit C1-Forth and the Superforth manual has more explanations for a newbe like me.

Greetings,
Vassilis

I hope you don't mind me asking - how are you saving the filename of the QL file on the PC? The reason I ask is how do you know what the filename is when the file is sent back to a QL?

The filename is not in the 14 byte header, but just after it - a word at offset 14, followed by the characters of the filename (maximum 36 character bytes, this is where the QL filename length limit of 36 characters comes from).

Ideally, I would save the whole 64 byte header, to make sure you have all the header information, even though some of it are not used on a QL with only microdrives. But, of course, I don't know exactly what you are doing, so you may already have sent the filename over the serial link so that the backup files have the same name as those on the microdrive cartridges?

For a QL which saves the dates in the header (not all do, it depends on the drivers) it might be possible to check dates in the header to see whether the file has changed since your last backup. So if you have already made a full backup, the second backup would only need to copy files which had changed since the ast backup, for example. Sadly, I don't think microdrives store the update, reference and backup dates. I have never really used this feature except when using Norman Dunbar's Winback program to make backups of a QL hard disk - the last 4 bytes of the header store a "backup date" which (on systems where it is being saved) you can check this against the update date (also where implemented) to see if it needs a new backup file to be sent because it changed since th elast backup.

But of course the important part of the backup is the part of the header containing the essential information for the executable data files - the file type byte and the dataspace value.

It sounds like a very interesting backup system you have. Of course, regular backups are an essential part of using any computer, so it is very important that it works correctly.

I hope I haven't caused you confusion by trying to give too much information!

[nichtsnutz]

Hello Dilwyn,

thank you for your detailed explanations.First I have to say,that I am not writing a full-fledged backup program,just a quick and dirty hack in C to save the binaries out of my microdrives.
I do not handle the filename right now.I just transfer the raw file data with the 14 bytes header and save them on the PC.I then rename the resulting binary file manually to the right QL filename.I have read in the "QL Advanced user guide" about the 64 byte header of the filing system but I do not know how to read it out.I found the FS.HEADER TRAP #3,D0=47 QDOS call but I do not know for sure how to use it.(I am waiting for the "QL Assembly language programming" book from Colin Opie to hopefully arrive that I have bought on ebay,so that I have more examples about programming in QDOS.)
I have not started right now to experiment with transfering the data back to the QL.I plan to start experimenting this weekend.I have also read the explanations on your site about transfering programs,but I only own an unexpanded plain QL so my possibilities are constrained.
As a more hardware oriented QL user,I do not think that I will make a backup program out of these experiments,I am sorry!

Greetings,
Vassilis