RWAP wrote:Simone should not need originals of these, so worth checking
The easiest way to transfer software I find, is to use q-emulator - you can use the free version as I have stored all of the preserved images as windows folders which can be attached to q-emulator and copied to QL disk.
For QPC, I would have to re-zip the packages on the QL side to create a QL zip package (as that preserves the file headers).
Rich might not appreciate me pointing this out, but here goes anyway.
"Easy" is a word I might dispute in this respect:
(1) Q-Emulator stores executable programs on non-QDOS media by adding several bytes to a file because Windows, Linux, Mac, Dropbox et al don't know about QL headers and just forget them. Result - destroyed program files which less experienced users can't hope to recover without help.
(2) zipping direct from these non-QDOS media doesn't store the files correctly for QDOS on other platforms - such zip files will only work on QemuLator and anything else which understands QemuLator modified files.
(3) to work around this, copy the files to a QDOS medium such as ramdisk or QDOS format floppy disk before zipping them. That will ensure they work on other systems too, because it forces QemuLator to "un-modify" the files by copying them to a medium it knows can handle QL executable file headers. Been caught out by this in the past and accidentally put QemuLator format stuff (sent to me ready zipped by well intentioned users) on my site without me checking them (Rich knows, I've moaned in the past).
(4) use of zip on QemuLator is complicated by the fact it takes 110 seconds just to read a directory on my system. I've tried more than one version of QDOS zip with similar results, and you get the same results when using ACP or Zip Manager for example. I've always had zip use ramdisc for its temporary files, would be interesting to reconfigure it to put them elsewhere to see if it solves this. This is just one of QemuLator's little foibles - try using hotkeys assigned to non-letter keys in SBASIC on QemuLator, the only way is to HOT_DO them!!!
(5) what this means is in addition to copying stuff out of the non-QDOS media to un-modify the files, you have to wait 110 seconds for it to try to read a non-existent zip file, then wait for it to add the files selected into the zip, then wait for it to read the directory again at the end (another 110 seconds - by now I'm finding watching the paint dry more interesting) - it all takes more than two or three times the time of a BBQL or QPC2 to do the same thing. Makes no difference using QDOS or SMSQ on QemuLator, by the way.
Rant over.
To be less negative, there are plenty of redeeming features:
QemuLator drive slot assignments make it very easy to read files direct from a Dropbox or other non-QDOS media without having to go through convoluted transfer software.
QemuLator lets you treat a zip file as a drive by assigning it to a drive slot. You can only read the file, not add to it directly, you have to use QDOS Zip to do that.
QemuLator gives you access to QDOS and SMSQ/E, and can emulate Aurora and Q40/Q60 colour modes with the appropriate version of SMSQ/E. This is fantastic for testing software, you can do so much on one system. You can tell it to use 128K RAM or expanded memory sizes, and tell it to run at normal QL speed, Gold Card, or as fast as your PC/Mac will allow it to (which is usually really fast!)
Before anyone thinks I was moaning too much... Since an invitation was extended to try to get helpers, I wanted to make you aware of the kind of things which can be problematical, which you might not expect to cause this work to take up more time than you'd expect. So, don't let it put you off, but it you volunteer to help with the work and immediately run into issues like this, ask us to share our experience before letting it put you off immediately!
