Here is what I did;  I wrote it so that hopefully even someone in my 
situation (i.e. pretty clueless on QL tech aspects) would be able to get 
results.  I am not a regular QL user; but I am very fond of my QL, and 
occasionally fire it up to remember how things were.  It was the first 
*real* computer I ever owned.

Just as a reminder,  I have a QL that I haven't used since the late eighties 
when I was a teenager.  It is a plain QL with no fancy bits and pieces that 
have come along since, like floppy drives, toolkit II's (whatever that is), 
gold cards, etc.  I also have about thirty microdrives with old files I'd 
created as well as some commercial games with considerable sentimental value 
to me.  A lot of these cartridges are on their last legs, and I wanted to 
get the files off and onto a PC where they will be safe, and I can run them 
on an emulator;  I can't say that I miss that QL keyboard! And I wanted to 
do this using just a serial cable; what followed was hours and hours of 
frustration (well, if I'm honest, I actually I quite enjoyed it, as all 
those QL memories came flooding back...).

I will not cover the usage of QemuLator as it already includes excellent 

There are three steps.

1. Connecting the hardware
2. Getting sofware onto the QL that will allow us to copy files back to the 
PC (i.e. QemuLator) without losing header information.
3. Copying the actual files from the QL to the PC.

1.  Hardware setup

This is what I used:

- My original QL, microdrive cartridges, etc
- Windows XP laptop with QemuLator v.2.5 installed
- Serial cable to link the two together (like the one here:

I did not have to change anything with com port settings on the PC, or 
change any of the defaults on QemuLator.  My laptop has one physical COM 
port which is the usual DB9 male connection and is seen as COM1 by XP.

I connected one end of the cable to the PC's COM port, and the other to the 
SER1 port on the QL.

Connectivity can be tested by typing at the QL

copy ser1 to scr_

the QL's flashing cursor will disappear as the command runs and waits for 
data on the SER1 port.

On the QL, type the following
open #4,ser1
print #4,"Test"

You should see the word "Test" appear in QemuLator

still on the QL, type

close #4

In QemuLator, press ctrl-space, the cursor should reappear.  A "not 
complete" message also appears (this message will appear later when we 
transfer files and press ctrl-space, but can be ignored as the files DO 
transfer correctly).

2.  Getting the program to use for copying over to the QL

The first thing we need to do is copy the MdvToWin program (which is 
supplied with QemuLator) from the PC to the QL and fix it so that it works. 
This program can then be used to transfer files from the QL back to 
QemuLator, correctly preserving them.

So first, we set up an mdv1_ on QemuLator which holds the MdvToWin_exe file.
On the QL, place a writeable microdrive cartridge with free space in mdv1_

To copy from the QL to QemuLator I did not have any problems with defaults 
( I believe the default rate is 9600 bps); however, I could not copy TO the 
QL if I didn't bring this down to 1200, so on both the QL and QemuLator, 

BAUD 1200

(there is no confirmation message from this command)

On QemuLator, type

copy mdv1_MdvToWin_exe to ser1

(the cursor stops flashing)

on the QL, type

copy ser1 to mdv1_MdvToWin_exe

the microdrive will whirr into life as the file is transferred.  You will 
know when the file transfer has completed, because a cursor will start 
flashing on QemuLator, and then the QL microdrive will stop; at this point 
hit ctrl-enter on the QL.

We now have the MdvToWin_exe on mdv1_ on the QL, but it won't run, because 
it's header has been lost (thanks Dilwyn for your explanations on this), so 
it needs to be recovered

the first thing we need to to know is the length of the mdvtowin_exe file in 
bytes.  We can get this by right-clicking on the file in Windows and 
bringing up its properties.  For the version I used, it was 1058 bytes.

Taking this number, on the QemuLator, we type

print alchp(1058)

which (for me at least) displays a result 169220

we then take these two numbers and on the QL we type

lbytes mdv1_MdvToWin_exe,169220
sexec mdv1_mdvtowin,169220,1058,10240

The mdvtowin file is the new file which WILL execute correctly, and is saved 
to mdv1_ by the above command.  I don't know what the 10240 is, but (for me 
at least), it all works.

On the QL, type

exec_w mdv1_mdvtowin

and you should get a program running with a title of MDV -> Q-emulator for 
Windows 95

We can now use this executable to transfer files from the QL to the PC 

3. Now to copy a file from a QL microdrive to QemuLator.

Restart the QL and the QemuLator.  This is to set the baud rate back to 
9600, and get everything to a standard state.

As an example I have a file on mdv1_ on the QL called index_dbf, which I 
want to copy across to the PC.  In mdv2_ on the QL I have the mdvtowin file 
I "created" earlier.  In QemuLator, I have a (virtual) microdrive, mdv2_ set 
up and mapped to a folder on the underlying PC

Connect the QL the PC, and power both on
On the QL:

exec_w mdv2_mdvtowin

The mdvtowin program executes and asks for the source file, give it


the program scans the file, once finished it then prompts for the 
destination, enter


at this point the data is sent down the serial port and the QL no longer 
shows any cursor activity, as it waits for the data to be accepted from the 
other end, so...

On QemuLator enter

copy ser1 to mdv2_index_dbf

the mdv on QemuLator will light as data is copied to it and the file is 
created.  Once the transfer completes, on the QL there will again be a 
flashing cursor.  Once the copy finishes, i.e. flashing cursor on QL, AND 
mdv "light" extinguishes on QemuLator, press ctrl-space on QemuLator.  The 
mdvtowin executable also reports a successful transfer.

The file is now accessible to QemuLator.

This can be repeated as many times as required to get as many files copied 
as possible.  I successfully transferred the Psion Chess program from the 
original microdrive using this method, and can run it on QemuLator now.

***** THE END ******

I hope the above is all correct.  I've checked it all, but even with the 
best of intentions, I tend to find that mistakes always seem to sneak in 

And once again, thanks to everyone who responded so promptly with help and 
advice.  It's nice to see that there's a community based around the QL 
that's still going strong, even now.



From: "Dilwyn Jones" <>
Sent: Thursday, June 04, 2009 1:16 PM
To: <>
Subject: Re: [Ql-Users] Copying files from QL to PC

>> I sent an e-mail last night but I'm not sure if it was received.  Anyway, 
>> I thought I'd try to copy from my real ql
>> to a q-emulator ql over the serial port, and I'm getting better results 
>> that I was getting using a DOS prompt.  I'm
>> getting so close now I can taste it.
> Wonder what a serial port tastes like? Is there enough voltage on the 
> lines to tingle the tongue. Says he, victim of prank a few years ago when 
> told to test PP3 9V batteries "on the tongue" :-()
>> Using q-emulator's serial port I have been able to copy complete files 
>> back and forth between the emulated and real
>> ql's (no more ctrl-z problems).  I just have one last problem with 
>> executables.
>> I am able to copy the complete file and if I do a copy mdv1_filename to 
>> scr_ on the real and emulated ql's the
>> output on the screen appears identical; but when I try to EXEC the 
>> "target" file (the copy) I get "bad parameter", Ah, usual loss of QL file 
>> headers on non-QL systems. Headers might not be preserved across the 
>> serial link. Might be worth trying Toolkit 2's "COPY_H" command to see if 
>> that manages to preserve headers.
>> whereas the "source" file runs correctly.  I think this must be what 
>> several of you have to alluded to with
>> headers.  I expect that following the suggestion of zipping the files 
>> would help, however, I still have to get zip
>> executable copied across.
> There is a "self-extracting" version of the "unzip" executable which might 
> help with this, available from Jonathan Hudson
> At the top of the page, click on the link to Infozip for SMS/QDOS
> Save the downloaded file to somewhere where QemuLator can find it.
> To get it self-extracted on QemuLator just LRESPR the SFX file:
> LRESPR unzip541xQ.bin
> and follow the prompts it gives. Needs quite a lot of free memory (might 
> be an issue if using the restricted memory unregistered version of 
> QemuLator).
>> Does anyone have a solution that might help with this?  If there's a good 
>> explanation out there regarding these
>> headers and how executables are different, I'd be grateful if you could 
>> point me in its direction (I'm beginning to
>> find all this quite interesting ;).
> QDOS files have 64 byte file headers (not all of it used). There's a bit 
> of info about all this on my website - in the Documentation And 
> Information section, go to the File Formats page, there you'll find the 
> file headers info. Basically, QDOS files come in four main types, general 
> data files (type 0), executable(type 1), the Sinclair Relocatable Output 
> File Format (SROFF-type 2) and Level 2 Directories (type 255 or -1 on 
> systems supporting level 2 directories, or I think type 3 on old Thor 
> computers). A few more file types were invented by certain programs over 
> the years (e.g. The Painter files such as pattern files etc).
> The type 1 files (QL executables, put simply programs you can EXEC or EX) 
> have a long word in the header which specifies how much dataspace (data 
> area for a job, in bytes) a job is to have (Job is the proper term for an 
> executable QL program) and a byte which specifies the file type. If these 
> get lost on a system which doesn't understand QL file headers, tough, back 
> to the drawing board! Actually you can restore them if you have the 
> relevant info using an SEXEC command as I alluded to in revious email, 
> though it's not always easy!
> Other stuff in file headers include the various dates info etc.
> When it comes to QL data files, these have only two vital parts in the 
> header, file length and type. Even a PC can deduce the file length of a QL 
> file, and an emulator will usually assume a type 0 data file unless it 
> knows better, so data files survive loss of headers in these circumstances 
> quite well, though you may lose the dates associated such as when the file 
> was last modified or created.
> There are a few little utilities out there (such as my QH system) which 
> can transfer the header information as a physically separate 64 byte file 
> which can be used to restore the executable information, though it's a 
> tricky thing unless you have experience of all this.
> Actually, if you do get success with the QL to QemuLator serial transfers, 
> this is a subject not covered much at the moment. Would it be possible for 
> you to write up the information you've learned and I could put it on my 
> website to help other users?
> -- 
> Dilwyn Jones
> _______________________________________________
> QL-Users Mailing List


Visit Pipex Business: The homepage for UK Small Businesses

Go to

QL-Users Mailing List

Reply via email to