Creating your own IPFs

[Keir]

You need to

cd /usr/local/lib
sudo ln -s libcapsimage.so.5.1 libcapsimage.so.5

[BarryB]

disk-analyse says it's looking for libcapsimage.so not libcapsimage.so.5, even if I link to libcapsimage.so disk-analyse still says it can't find libcapsimage.so

Think it's time for a break, you've spent enough time spoon feeding!!

[Keir]

Originally Posted by BarryB

disk-analyse says it's looking for libcapsimage.so not libcapsimage.so.5, even if I link to libcapsimage.so disk-analyse still says it can't find libcapsimage.so

Think it's time for a break, you've spent enough time spoon feeding!!

The error message is mistaken, I'll fix it. It is definitely looking for libcapsimage.so.5. /usr/local/lib may not be on your library search path. See the Disk-Utilities/README for ways to add it.

[Retroplay]

I fixed the search path issue by adding it to ld.so.config

sudo pluma /etc/ld.so.conf (pluma is my txt editor, you may use another like gedit)

Add /usr/local/lib or /usr/local/lib64 (if using 64-bit Linux) and save then do a sudo ldconfig

[BarryB]

I've got both paths in my ldconfig, does that matter?

After wrestling with it last night I switched off thinking it was sorted but as usual with me, there's always something else

Tried converting a plain AmigaDOS .CT image 688.ct to IPF but get:

disk-analyse: caps: Could not prefetch image data

[Keir]

Originally Posted by BarryB

I've got both paths in my ldconfig, does that matter?

After wrestling with it last night I switched off thinking it was sorted but as usual with me, there's always something else

Tried converting a plain AmigaDOS .CT image 688.ct to IPF but get:

disk-analyse: caps: Could not prefetch image data

Out-of-date libdisk.so.0. A bang up-to-date version of the library will print more information than that, when it fails to load a CT Raw image.

EDIT: Not totally sure on that actually. Maybe you don't really have v5 of libcapsimage.so installed. The latest FS-UAE should be able to load your CT Raw image if you do have the library correctly installed.

[Keir]

The Disk-Utilities/README should now give new users a fighting chance.

[BarryB]

Read the new readme, started again but can't see what the problem is as nothing has shown an error when making or installing as I now get:

disk-analyse: Unable to open libcapsimage.so.5 or libcapsimage.so.4

libcapsimage.so.5.1 compiled/installed without an error.

in /usr/local/lib I have symbolic link 'libcapsimage.so.5' and the file it points to: 'libcapsimage.so.5.1'
in /usr/local/lib64 I have symbolic links libdisk.so that points to: libdisk.so.0 which points to file: libdisk.so.0.0

in /etc/ld.so.conf I have the lines: include ld.so.conf.d/*.conf + /usr/local/lib + /usr/local/lib64

Seems I'm always 1 step forward then 2 steps back

[Retroplay]

Are you using 64-bit Linux ?

If that's the case you should only use /usr/local/lib64 afaik.
Install libcapsimage to lib64 and see what happens.

[BarryB]

Using Fedora 20 64bit.

Copying the files in lib to lib64 generates the 'disk-analyse: caps: Could not prefetch image data' message which kaffer says is a stale libdisk.so but it's been copied to lib64 at build!!

The caps library compiled and installed itself to usr/local/lib so the compile/install must have worked.

[Keir]

Originally Posted by BarryB

Using Fedora 20 64bit.

Copying the files in lib to lib64 generates the 'disk-analyse: caps: Could not prefetch image data' message which kaffer says is a stale libdisk.so but it's been copied to lib64 at build!!

The caps library compiled and installed itself to usr/local/lib so the compile/install must have worked.

You could "ldd disk-analyse" to check it is pulling in the libdisk in /usr/local/lib64. But now I really wonder whether your raw image is good. Feel free to email it over and I'll check.

[BarryB]

Originally Posted by kaffer

You could "ldd disk-analyse" to check it is pulling in the libdisk in /usr/local/lib64. But now I really wonder whether your raw image is good. Feel free to email it over and I'll check.

Actually, you've just nailed it!

Now I think about it, I did have problems with a build of DTC not creating working CT RAW images from some streams I'd previously made with an earlier DTC build, either the build of DTC was the problem or the way I'd dumped the streams as WinUAE complained about the floppy disk being damaged when used with new v5 caps library. That's how I now check CT RAW files are good, if WinUAE doesn't complain when I select an image file then it's a good CT RAW image!

Just found some more CT RAW dumps and loaded them into WinUAE and it didn't complain, so tried with disk-analyse and got it to convert to IPF. So nothing was actually wrong (after lots of hoop jumping initially).

[barryb@localhost ~]$ Disk-Utilities/disk-analyse/disk-analyse -v --format="probe_amiga" DungeonMaster.ct DM.ipf
Found format "probe_amiga"
T0.0: AmigaDOS
T0.1: Unformatted*
T1.0-79.1: AmigaDOS
T80.0-83.1: Unformatted
** WARNING: 1 tracks are damaged or unidentified!

At least it's working now, no thanks to big daft me

[Supamax]

Originally Posted by kaffer

The first 8 bytes of the file have a signature. EXT1 has signature UAE--ADF, EXT2 has signature UAE-1ADF. I think EXT2 is a lot more common these days, and is also the better format.

Thanks

[caiusfabricius]

Resuming this quie old thread.
I successfully compiled the tools under Ubunt 64-bit (virtualized in Virtual Box), they works wery well allowing me to convert disk images to/from different formats, it's a great piece of software, my congratlation to Kaffer.It would be possible to add other formats espacially in writing?CT RAW and Kryoflux RAW Stream could be very useful as the first is now supported in many emulators, the latter can be written to real disk using Kryoflux device.

[Keir]

Originally Posted by caiusfabricius

Resuming this quie old thread.
I successfully compiled the tools under Ubunt 64-bit (virtualized in Virtual Box), they works wery well allowing me to convert disk images to/from different formats, it's a great piece of software, my congratlation to Kaffer.It would be possible to add other formats espacially in writing?CT RAW and Kryoflux RAW Stream could be very useful as the first is now supported in many emulators, the latter can be written to real disk using Kryoflux device.

Pleased to hear it is still in use. I am unlikely to add major features in the near future while I concentrate on the FlashFloppy Gotek firmware.

For emulators the best format is IPF, already supported for writing, and decoded for emulators by the same library that does CT RAW.

For writeback I agree that KF RAW would be nice, however I switched over to Supercard Pro as the hardware spec is published so I could write my own toolset. I would happily take a patch to implement KF RAW write support, and even advise on how to go about it within the codebase, but realistically won't get round to it myself.

[chip]

Can IPF format be used with emulator ?

Or it is useful only to be write back to real floppies ?

[caiusfabricius]

IPF can be used with some emulators but not all.WinUAE support this format.

[chip]

Thanks for the info caiusfabricius (ciao :-)

I didn't know that, so WinUAE can read IPFs ..... interesting

[caiusfabricius]

Google is your friend as well as a bit of time and patience...

[DamienD]

Originally Posted by chip

Thanks for the info caiusfabricius (ciao :-)

I didn't know that, so WinUAE can read IPFs ..... interesting

Yes chip, it's exactly the same .DLL required as for reading RAW images i.e. http://www.softpres.org/download

Extract into the root of your WinUAE installation / directory.