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 documentation. 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: www.thesinclairshop.com/PDF/sinclairserialadaptor.pdf) 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, type 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 (QemuLator) 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 mdv1_index_dbf the program scans the file, once finished it then prompts for the destination, enter ser1 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 somehow. 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. Cheers, John -------------------------------------------------- From: "Dilwyn Jones" <dil...@evans1511.fsnet.co.uk> Sent: Thursday, June 04, 2009 1:16 PM To: <ql-us...@q-v-d.com> 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 www.daria.co.uk/qdos/ > > 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 > http://www.q-v-d.demon.co.uk/smsqe.htm -- ------------------------------------------------- Visit Pipex Business: The homepage for UK Small Businesses Go to http://www.pipex.co.uk/business-services _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm