The Sinclair QL Forum

Although I've owned a QL for quite a long time now, it is only recently I've been able to spend some time with it.

As my mdv1_ is not working so well (mdv2_ is ok), I've invested in a vDriveQL and vMap, which I think is great, and it's allowed me to easily remap mdv1_ to the external SD card which has neatly circumvented my problems with the dying mdv

However, it has kind of highlighted the problem of all my failing mdv carts, now that I'd like to back them up to MDV image files, which in itself has left me with other questions.

So, here are the questions, sorry if they've all been asked before:

1. What is the recommended replacement for the foam pads of microdrives cartridges? I have tried with some felt pads for cassette tapes, and it works ok ish, but they're a bit thick and can't be cut easily.
2. Is there a recommended tool to copy working cartridges across to MDV images using vDrive QL? What would you all recommend? I have Toolkit 2 and 640K of RAM if it'll help.
3. I have the following original software:
And if I can't repair and copy the carts, I'd like to potentially download MDV images of it all so that I can at least use the software, some of which goes with my ICE GUI ROM cart + mouse.

So I guess the question is, what is the best repository of MDV files where I might be able to replace the above.

Thanks in advance all

Use mdump_task to create images of the real carts. It may be possible to copy an image to a blank vdrive (if the image size turns out not too large) and then you'd have to use an emulator to get the image-within-an-image off of the vdrive, and then associate that image with a vdrive. I've never actually tried saving an mdump image to vdrive as have always used win1_ or flp1_ as the target, where a lot more space is available.

See here:

http://qxl.win/ql_cartridge_recovery.htm

Chr$ wrote:Use mdump_task to create images of the real carts. It may be possible to copy an image to a blank vdrive (if the image size turns out not too large) and then you'd have to use an emulator to get the image-within-an-image off of the vdrive, and then associate that image with a vdrive. I've never actually tried saving an mdump image to vdrive as have always used win1_ or flp1_ as the target, where a lot more space is available.

See here:

http://qxl.win/ql_cartridge_recovery.htm

Thanks for the info, much appreciated I will take a look.

I too have floppy drives, however whilst I do have a nice retro space, the amount of room I have is a bit limited so I can't easily have them out permanently, though I might be able to use them temporarily for imaging purposes.

roninfourseven wrote:
I too have floppy drives, however whilst I do have a nice retro space, the amount of room I have is a bit limited so I can't easily have them out permanently, though I might be able to use them temporarily for imaging purposes.

That'll be much easier, best not to bother with the vdrive as target then. From memory the space within a vdrive virtual cartridge is about 123k, which is probably fine for some images but when mdump_task has issues with a cart it will also save some alternative bad sectors and the resultant images can be well over 200k.

Good luck.

Chr$ wrote:

roninfourseven wrote:
I too have floppy drives, however whilst I do have a nice retro space, the amount of room I have is a bit limited so I can't easily have them out permanently, though I might be able to use them temporarily for imaging purposes.

That'll be much easier, best not to bother with the vdrive as target then. From memory the space within a vdrive virtual cartridge is about 123k, which is probably fine for some images but when mdump_task has issues with a cart it will also save some alternative bad sectors and the resultant images can be well over 200k.

Good luck.

Thanks again, I'll see what I can do and report back

Chr$ wrote:Use mdump_task to create images of the real carts.

More questions I'm afraid @Chr$....

I've been able to get mdump_task from the latest version of Q-Emulator, and I've also managed to get it over onto floppy using wxqt2, but....

If I try to execute with the info from here: http://qxl.win/ql_cartridge_recovery.htm, all I get is 'bad parameter'.

I've tried it with and without the toolkit, so exec_w flp1_mdump_task, with the toolkit, so ew flp1_mdump_task and also the same with Minerva and the standard ROM.

As in my other post about Minerva, my disk interface is a Sandy device, so I'm using TK2 2.09, but it also gives me an extra 512KB RAM, so 640 KB in total, so plenty of RAM.

I'd appreciate any thoughts you might have.

You may want to read this (especially the part about QDOS file headers and unpacking QL zip files never on a PC).

Your mdump_exe file header can be repaired with (You're saying you got TK2, so this should work)
After this, the header should be repaired and mdump1_exe should be properly executable.

How did you get the program onto the QL. It sounds as if it may not have the "Resource Fork", as it would be called on the Mac, half of the file, only the "Data Fork". The RF holds meta data such as the file type and the stack size etc.

Hi,

From the link to: http://qxl.win/ql_cartridge_recovery.htm

The section on µDump says: the µDump programme is located: "Program Files (x86)/Q-emuLator/QL Software/FileUtil/' path and is named 'mdump_task'. This file needs to be exec'd on a QL, e.g. with the command 'ew flp1_mdump_task',

Your problem the mDump_task executable will have a QDOS header prefixed to the file, so that thee Qemulator can excute QDOS executable files from a PC file system.

If you copy the mDump programme with Qemulator (Registered copy) to a QWA container or also known as QWL.WIN file, the QDOS header will be removed, then use WXQT2 to transfer the programme to a QDOS disk.

If you have not registered Qemulator, I will upload the programme in a zip file, just upzip in a QDOS system.

This us the curse of the Emulators...

stephen_usher wrote:How did you get the program onto the QL. It sounds as if it may not have the "Resource Fork", as it would be called on the Mac, half of the file, only the "Data Fork". The RF holds meta data such as the file type and the stack size etc.

Noob error I think, I unzipped the files on PC