Hi,
I've built an IPF-generating tool which I am interested in testing on real Amigas via HxC SD. However, my primary interest is copy-protected games and I would need non-uniform density support, which is apparently missing from HxC SD right now. So I was wondering whether there is a plan to add support in future? From what I can gather it looks like the focus until recently was primarily on supporting sector dumps (e.g., ADF), and so the HFE image format simply can't represent timing information as yet. Implementing this would be great, *loads* of original Amiga images will need non-uniform density support for their Copylock/Speedlock tracks.
A further question: is the HFE format documented, or encode/decode source published? If so I would add direct support for it to my conversion tool.
Regards,
Keir
Non-uniform density on HxC SD
Re: Non-uniform density on HxC SD
About the HFE non uniform density support, i am working on a new HFE format. But i am not sure if this will be reliable enough/possible on the actual hardware. I recommend the use of the USB version for the moment.keir wrote:Hi,
I've built an IPF-generating tool which I am interested in testing on real Amigas via HxC SD. However, my primary interest is copy-protected games and I would need non-uniform density support, which is apparently missing from HxC SD right now. So I was wondering whether there is a plan to add support in future? From what I can gather it looks like the focus until recently was primarily on supporting sector dumps (e.g., ADF), and so the HFE image format simply can't represent timing information as yet. Implementing this would be great, *loads* of original Amiga images will need non-uniform density support for their Copylock/Speedlock tracks.
A further question: is the HFE format documented, or encode/decode source published? If so I would add direct support for it to my conversion tool.
Regards,
Keir
I am working slowy on this point (see the last part of the post)
Yes the HFE format is documented but i don't recommend the to recoding all the stuff. A library will be available soon (already use in the VFD : https://hxc2001.com/floppy_drive_emulat ... fd_hxc.zip )
But about the IFP itself i have a problem :
This licence is based on the MAME licence and is intended for use in all non-commercial projects and environments. Other licensing options are available. Don't hesitate - please contact us at licensing@kryoflux.com.
LICENCE
Redistribution and use of the IPF DECODER LIBRARY (CLL; "CAPSImage", "CAPSImg", etc.) code or any derivative works are permitted provided that the following conditions are met:
- Redistributions may not be sold, nor may they be used in a commercial product or activity.
...
...
...
COMMON QUESTIONS
Q. Can I include the IPF DECODER LIBRARY with my product?
A. No. The IPF DECODER LIBRARY is not licensed for commercial use. Using IPF DECODER LIBRARY as a "freebie" or including it at "no cost" with your product still constitutes commerical usage and is forbidden by the licence.
Q. Can I sell my product with the IPF DECODER LIBRARY or associated logos (e.g. SPS) on it?
A. No. Putting the name or logo on your product makes it appear that the product is something officially endorsed.
Q. Can I use the IPF DECODER LIBRARY or the SPS logo to advertise my product?
A. No. Using the name or logo in your advertising makes it appear that the product is something officially endorsed.
Q. Can I use the term "IPF DECODER LIBRARY" in the name of my software?
A. Generally, no, especially if it is something that is sold. However, if you are producing a free IPF DECODER LIBRARY-related piece of software, it is common that permission is granted. Send a query to double-check first, please.
This means that i will have to drop the IPF support soon or late...
Re: Non-uniform density on HxC SD
Hi, Thanks for your reply! I was hoping that the non-uniform density feature would not be a problem for the older SD hardware, but wasn't sure. Fingers crossed!
Regarding IPF support, so long as you are dynamically linking to the decoder library, and accessing it through the "Access API" (see http://www.softpres.org/download, but I have little doubt you are, as it basically *is* the dynamic library's API), and it is your users who have to download the IPF library, then you are not bound by the library license for your own product.
This is probably why many applications link to the library on demand at runtime (e.g., dlopen() on Linux, probably there is similar on Windows).
Regarding IPF support, so long as you are dynamically linking to the decoder library, and accessing it through the "Access API" (see http://www.softpres.org/download, but I have little doubt you are, as it basically *is* the dynamic library's API), and it is your users who have to download the IPF library, then you are not bound by the library license for your own product.
This is probably why many applications link to the library on demand at runtime (e.g., dlopen() on Linux, probably there is similar on Windows).
Re: Non-uniform density on HxC SD
Also, the HFE format looks quite straightforward. I would just add support for targeting it in my own library, and of course accept the pain of chasing any updates you make to the spec. Apart from your IPF licensing concern, I am a Linux guy so if I can avoid booting my Windows VM then all the better!
Re: Non-uniform density on HxC SD
The library can be compiled for linux!keir wrote:Also, the HFE format looks quite straightforward. I would just add support for targeting it in my own library, and of course accept the pain of chasing any updates you make to the spec. Apart from your IPF licensing concern, I am a Linux guy so if I can avoid booting my Windows VM then all the better!
And i will never support any user coming with a problem with your lib. i am wondering : why do you remake something that is already existing ?
The actual hxc software (windows & linux + mac compatible) already does the file images conversions (and even more
).Re: Non-uniform density on HxC SD
The Licence doesn't say this :keir wrote: Regarding IPF support, so long as you are dynamically linking to the decoder library, and accessing it through the "Access API" (see http://www.softpres.org/download, but I have little doubt you are, as it basically *is* the dynamic library's API), and it is your users who have to download the IPF library, then you are not bound by the library license for your own product.
This is probably why many applications link to the library on demand at runtime (e.g., dlopen() on Linux, probably there is similar on Windows).
This is exactly the case here, even if i don't provide the dll...... nor may they be used in a commercial product or activity....
Anyway i have to remove all reference to SPS / IPF on the website :
Q. Can I use the IPF DECODER LIBRARY or the SPS logo to advertise my product?
A. No. Using the name or logo in your advertising makes it appear that the product is something officially endorsed.
Q. Can I use the term "IPF DECODER LIBRARY" in the name of my software?
A. Generally, no, especially if it is something that is sold. However, if you are producing a free IPF DECODER LIBRARY-related piece of software, it is common that permission is granted. Send a query to double-check first, please.