EasyPtr4

[RalfR]

As far as I know, the problem with executing menu_rext things in smaller job windows was discussed here elsewhere. I think, Per Witte has a solution at his Knoware site, Poxology.

[pjw]

As far as I know, the problem with executing menu_rext things in smaller job windows was discussed here elsewhere. I think, Per Witte has a solution at his Knoware site, Poxology.

Pox is about larger-than-window popup messages. FSEL is more specific to the issue at hand. It can be found here. Like most of my programs, including EasyPtr ones, it comes complete with source code..

One way of avoiding problems programming with the likes of EasyPtr is to ensure one is using the latest version of all the software involved, from the emulator and OS, to the likes of menu_rext and EasyPtr itself, which is now in version 4.

[RalfR]

Ah yes, I have remembered the wrong one

[Martin_Head]

I think I have finally got my latest EasyPtr4 program working.

I tried a suggestion by desin to get around my FILE_SELECT$ problem. But I could not get it to work. I also looked at (but not tried) FEL by pjw.

I decided to just drop using FILE_SELECT$, As it just didn't seem worth the hassle for what I wanted to use it for.

The program allows you to create blank image files for floppy disks and Microdrives.

You will need the Qliberator run-times installed before running the program.

Select the check box for the type of image file you require, Enter an image file name and medium name. Then click Create Image.

For Microdrives, If you leave Sectors blank, then the default is 255 sectors. Likewise the random number, If left blank, then a random number will be used.

If the Image file name is blank, then an appropriate extension is added, and when you click on the filename, the cursor will appear at the left hand side. If you just start typing the supplied extension will be removed. You need to press the left cursor key once, before you start typing the device and filename. You will also have to press enter twice to actually enter the filename. This is due to the MINPUT command in EasyPtr4.

The program is compiled with Version 3.45a of Qliberator, with the NOWINDS option.
I have tried the program in QPC2 and the Q68. I don't know about QDOS, The EasyPtr manuals says it's for SMSQ/E.
Also it won't be able to handle Mode 8 displays.

The following files are supplied
ImageUtil_obj Qliberated program with a Qemulator header
ImageUtil_zip As above, but without the Qemulator header

Sources
ImageUtil_bas The BASIC program
ImageUtil_cde SuperBASIC extensions for creating the image files
ImageUti_cde An APPMAN file containing EasyPtr4 extensions and the menu
ImageUti_men The EasyPtr4 menu

[tofro]

Martin,

I'm not sure if it's relevant, but at least interesting in this context what I found by disassembling some of the MG ROM code:

The later QL ROMs (MG and Minerva) are a bit more picky than the earlier ones when formatting a cartridge and will return a "Format failed" when

• Less than 200 sectors fit onto the cartridge (well, that's obviously a bad cartridge)
• More than 253 sectors fit onto the cartridge (i.e. 254 or 255 - Not sure how this could happen)
• All sectors on the cartridge are "good" (i.e. there must be at least one un-usable sector - Unlikely to happen as the tape seam [where the loop is glued] would always result in at least one bad sector)

I don't quite understand why this tests (at least the latter two of the three) are there (as both figures should be impossible on real drives), but it they are probably there for a reason. That also means images like you seem to create using your software defaults could not physically exist on real drives.

Tobias

[Derek_Stewart]

Hi,

Very nice programming...

[Martin_Head]

Martin,

I'm not sure if it's relevant, but at least interesting in this context what I found by disassembling some of the MG ROM code:

The later QL ROMs (MG and Minerva) are a bit more picky than the earlier ones when formatting a cartridge and will return a "Format failed" when

• Less than 200 sectors fit onto the cartridge (well, that's obviously a bad cartridge)
• More than 253 sectors fit onto the cartridge (i.e. 254 or 255 - Not sure how this could happen)
• All sectors on the cartridge are "good" (i.e. there must be at least one un-usable sector - Unlikely to happen as the tape seam [where the loop is glued] would always result in at least one bad sector)

I don't quite understand why this tests (at least the latter two of the three) are there (as both figures should be impossible on real drives), but it they are probably there for a reason. That also means images like you seem to create using your software defaults could not physically exist on real drives.

Tobias

I think the second and third, are to test if the Microdrive motor is running too slow. So more sectors will fit on the cartridge. I don't know the theoretical maximum number of sectors that will fit on the tape loop. But 253 sound a bit high.

I think the first also covers the motor running too fast.

I default to 255 sectors, as that's as many as the Microdrive driver will support.

[RalfR]

As it is possible to create a real FLP from a *.img file, is it possible to do the same with an MDV?

[Martin_Head]

As it is possible to create a real FLP from a *.img file, is it possible to do the same with an MDV?

To go from an image file to MDV like a FLP is tricky.
The big problem is that the target microdrive will almost certainly have bad sectors in places that the original image file has good ones.
So you would need to move sectors about, updating the microdrive map as you go.
There's a couple of smaller things you would have to also do, and you might screw up some copy protection by messing with the microdrive map.

At the simplest level, If you networked a QL to an emulator with say, sernet. You could WCOPY the files from an image file to a real microdrive.
I don't think I have ever tried it, But the MDI driver should run on a real QL with memory expansion (and disk interface). Then you could mount the image, and WCOPY mdi.. TO mdv..
Of course this would screw up any copy protection.

Alternatively,
Before I wrote the MDI driver, I wrote some SuperBASIC code to read and extract the files from MDI images.
It's MDIProgs_bas in the MDI driver here http://www.dilwyn.me.uk/utils/MDIdriver108.zip
Which could probably be altered to handle Qlay and Qemulator files.

[Martin_Head]

This is the documented (and debuged) SuperBASIC extensions that I used in my EasyPtr Image Utilities program.

Along with creating floppy disk and microdrive image files. It can also convert existing microdrive images between the MDI, Qemulator, and Qlay formats.