MiSTer FPGA Forum

Hi,

I was just wondering if there is any plans to introduce IPF support to minimig core.

Thanks!

Pretty sure Sorgelig has not planned on doing it, as in having looked into how it would be done and such. I do think its a feature he hopes to add to the core, but I suspect its most likely to happen if someone else begins to implement it and figure out the details of it first.

Seems Sorg already commented on it back in 2018:
https://www.atari-forum.com/viewtopic.p ... &start=100

Since Minimig is already ported from a different FPGA, it also depends on whether one of the other Minimig implementations ends up getting support for it.

There is also this, which might be referring to what Sorg was on about:
https://www.gitmemory.com/issue/MiSTer- ... /815990331

"@ransom1122, Minimig doesn't have ipf support on the real Minimig board and other case is no support of expanded adf (used for save on Cannon fodder if you use floppies). Not sure if it is possible to add those supports in the future."

So maybe the Minimig core itself and the way it handles floppies right now does not support extended floppy disks, so essentially unable to read the parts of floppy disks where the copy protection is usually stored.

Ipf can be use for all Kind of computer floppy, not only amiga

You can find ipf for amstrad cpc, spectrum, ibm pc ...

Protection scheme can be store in ipf

breiztiger wrote: ↑Fri Jun 04, 2021 5:44 pm Ipf can be use for all Kind of computer floppy, not only amiga

You can find ipf for amstrad cpc, spectrum, ibm pc ...

Protection scheme can be store in ipf

Yes, same of SCP the file format for the SuperCard Pro. It has so low level floppy data that it can fit any type of floppy, but it seems the Minimig core does not at the moment support that deep level of complexity of floppy data, and the same might go for other cores.

This would be a huge value-add for me.

I understand why this is on the backburner though, as really the IPF format is more or less closed, and not only that but the only "issuing entity" that is able to create the .IPF files are the SPS themselves. They create the images from Kryoflux images sent to them by users of valid disks. Furthermore, their license to use the SPS IPF technology may interfere with some of the MiSTer as well, but I'm no expert on this.

Hopefully we see it sooner rather than later. I think it would be a tremendous add to those who are trying to get as close to the real hardware as possible.

mcj wrote: ↑Mon Jun 21, 2021 1:05 pm I understand why this is on the backburner though, as really the IPF format is more or less closed, and not only that but the only "issuing entity" that is able to create the .IPF files are the SPS themselves. They create the images from Kryoflux images sent to them by users of valid disks.

Really? I was under impression that SPS is a dormant group and haven't released anything for a long time. And other people are releasing .ipfs too, eg: http://eab.abime.net/showthread.php?t=107369

mcj wrote: ↑Mon Jun 21, 2021 1:05 pmFurthermore, their license to use the SPS IPF technology may interfere with some of the MiSTer as well, but I'm no expert on this.

Yeah it does - their licenses are fundamentally incompatible with the GPL, so if support were ever added it would have to be a clean-room re-implementation from scratch.

it's possible as caprice forever and sugarbox does for amstrad from scratch

good doc
http://info-coach.fr/atari/documents/_m ... tation.pdf

akeley wrote: ↑Mon Jun 21, 2021 1:30 pm Really? I was under impression that SPS is a dormant group and haven't released anything for a long time. And other people are releasing .ipfs too, eg: http://eab.abime.net/showthread.php?t=107369

Dormant is correct, but according to their FAQ I linked, they state:

I have imaged my disks using your tool. How do I make IPF files from them?
It is not possible for contributors to do this, it is a very complicated process. What happens is disk images are submitted to us, and our technical members create the IPF‘s only if the disks they were taken from are 100% correct and authentic. This is explained in much detail here.

Maybe the software is out there that allows people to do this, but I'm unsure if this was intended or not, or if someone just happened to have connections to those who authored the software and allowed them to use it to preserve that game in specific. Suffice it to say that your average laymen doesn't have access to the creation tool though.

mcj wrote: ↑Mon Jun 21, 2021 2:10 pm Maybe the software is out there that allows people to do this, but I'm unsure if this was intended or not, or if someone just happened to have connections to those who authored the software and allowed them to use it to preserve that game in specific. Suffice it to say that your average laymen doesn't have access to the creation tool though.

I think one of the guys (dlrfsilver) from the thread I linked to is a current member (if there is anything to be a member of, that is). In any case, even if no new images are created regularly, there is still a huge library that could be of use (which is where I agree with your first post).

It's a bummer if a licensing issue was the main obstacle, but perhaps they could be contacted and some sort of solution found.

You can Make your own ipf, for exemple with

https://eab.abime.net/showthread.php?t=62217

https://www.cpcwiki.eu/forum/applications/sugarconvdsk/

Why make ADF files into IPF? That does not make much sense to me. If they start out as ADFs, they should not have any special copy-protections and such anyway.

If you want to convert between different advanced or simple disk images I would recommend the HxC Floppy Emulator tool. It supports IMG, IPF, SCP, ADZ, ADF, HFE... well, the list if very long there is a patch notes file here:
https://hxc2001.com/download/floppy_dri ... _notes.txt

The guy who wrote this tool also wrote Gotek software drivers and such, pretty sure he even invented the HFE format, which is split up into different versions where v3 is one that supports most copy protections and such.

This would require significant changes to the arm side of things, the minimig side of things, and the interface. Right now the minimig requests a track of data from the arm side, and ipf deals with flux… to support ipf (or real disk drives) this interface would need to change and pass raw flux data to Paula within minimig. I think

Wonder if there are any changes in plan to include IPF support for minimig core.

To remind all, IPF is verified 100% copy of amiga's floppy disk.

It requires SPS' dll to work on emulators.

http://www.softpres.org/download

I have been hoping to see this get supportted for a long time now and have asked Sorgelig about it. I have also been asking for support for real floppy drive support.

Sorg does argue that it would make more sense to support IPF and such than it does to support real floppy drives, and I agree. But for either to be possible, there would first need to be better floppy support because as it is now the implementation only supports ADF. That is, ADF files does not have nearly as much data about the actual disk compared to IPF and such format. So currently it lacks something in the floppy controller that would allow it to get those extra layers of data.

I do think its mainly a question of time before we see it implemented thought. If it is implemented on the Minimig core for the MiST, Minimig or TC64 then it will likely get ported to the MiSTer. TC64 just got CD support added to it, and it even got support for audio tracks as well. So I hope that means we will see that on the MiSTer as well.

One of the likely challenges for getting IPF support is the closed-source nature of the solution that the SPS group provides. To date, no reverse-engineered implementation (of the reader code) has been created for any platform.

some emulator sure sugarbox (amstrad) have ipf implantation from scratch with sps docs

rhester72 wrote: ↑Sun Sep 11, 2022 1:43 pm One of the likely challenges for getting IPF support is the closed-source nature of the solution that the SPS group provides. To date, no reverse-engineered implementation (of the reader code) has been created for any platform.

What do you mean? AmiBerry is open source and it implements IPF support. So it must be documented how to read the IPF format. Several emulators support reading it. There is also the floppy emulator thing developer for the Gotek drives that can help convert to and from IPF to various other formats.

https://github.com/BlitterStudio/amiber ... r/src/caps
Source that implements using the IPF format.

But it cannot be used in the Minimig core before the way it reads floppy disks is updated so it can do more than read the limited ADF format. As I wrote above, it does not support reading subsectors or something advanced like that, which is where you often find copy protections and such.

They all use the supplied SPS dll as far as I know and thats closed.

pCAPSInit = (CAPSINIT) uae_dlsym(h, "CAPSInit");
pCAPSAddImage = (CAPSADDIMAGE) uae_dlsym(h, "CAPSAddImage");
pCAPSLockImageMemory = (CAPSLOCKIMAGEMEMORY) uae_dlsym(h, "CAPSLockImageMemory");
pCAPSUnlockImage = (CAPSUNLOCKIMAGE) uae_dlsym(h, "CAPSUnlockImage");
pCAPSLoadImage = (CAPSLOADIMAGE) uae_dlsym(h, "CAPSLoadImage");
pCAPSGetImageInfo = (CAPSGETIMAGEINFO) uae_dlsym(h, "CAPSGetImageInfo");
pCAPSLockTrack = (CAPSLOCKTRACK) uae_dlsym(h, "CAPSLockTrack");
pCAPSUnlockTrack = (CAPSUNLOCKTRACK) uae_dlsym(h, "CAPSUnlockTrack");
pCAPSUnlockAllTracks = (CAPSUNLOCKALLTRACKS) uae_dlsym(h, "CAPSUnlockAllTracks");
pCAPSGetVersionInfo = (CAPSGETVERSIONINFO) uae_dlsym(h, "CAPSGetVersionInfo");
pCAPSGetInfo = (CAPSGETINFO) uae_dlsym(h, "CAPSGetInfo");
pCAPSSetRevolution = (CAPSSETREVOLUTION) uae_dlsym(h, "CAPSSetRevolution");
pCAPSGetImageTypeMemory = (CAPSGETIMAGETYPEMEMORY) uae_dlsym(h, "CAPSGetImageTypeMemory");

those are calls to the Caps.dll

no, sugarbox doesn't use sps dll

i think caprice forever also

https://github.com/Tom1975/CPCCore/blob ... PSFile.cpp

CPCCoreEmu seems to be MIT licensed, so that's compatible with GPL.

Whether it needs a DLL or not does not seem that important? IPF files will be going through the Linux side anyway, and the MiSTer Linux system must be able to use the SPS library if its needed. Its not that the core itself needs to support IPF files inherently. Generally images of any kind are handled by MiSTer Main.

But as long as the core itself does not support the full floppy input and output data stream that is needed for IPF, SCP and such advanced floppy images, it would not make sense to try to add support for IPF in the MiSTer Main. But once the core does support the datastream, then the Main can get the support for the different image types that exist. Just like with CHD, VHD, IMG, ADF, cue/bin, iso and all the other files that are supported by MiSTer Main in different cores.

I found this thread confirming that Amiberry does need an external library to support IPF:
https://github.com/BlitterStudio/amiberry/issues/130

zakk4223 wrote: ↑Mon Sep 12, 2022 1:06 pm https://github.com/Tom1975/CPCCore/blob ... PSFile.cpp

CPCCoreEmu seems to be MIT licensed, so that's compatible with GPL.

Yeah, I cannot see this using a library anywhere, and its not just some API getting data from the IPF file, it goes through all the bytes and decodes them.

With this being a thing though, I wonder if the Amiberry developers know about this or if there is some reason for them to not use this to use IPF images?

and sps dll has bug ... like half weak sector on amstrad for example (After Burner ipf doesn't work with sps dll but is ok on caprice or sugarbox)

IPF images support would be great, since images represent unmodified copies of software.

As for writing back to IPF, if I remember correctly, WinUAE creates change file of floppy that you can delete to move back to original floppy state.

IPF does mean all the manual based copy protection is present and its a pain in the arse. Also means you would have to pay much more attention to the config of the Amiga. No WHDLoad fixes would be present

FPGA64 wrote: ↑Wed Sep 14, 2022 6:19 pm IPF does mean all the manual based copy protection is present and its a pain in the arse. Also means you would have to pay much more attention to the config of the Amiga. No WHDLoad fixes would be present

You´re right but at the same time you may enjoy a nice and clean floppy replica without intros, trainers, outros, cracks and similar stuff which sometimes can be really annoying. And, well, WHDLoad fixes are not present in ADF either

FPGA64 wrote: ↑Wed Sep 14, 2022 6:19 pm IPF does mean all the manual based copy protection is present and its a pain in the arse. Also means you would have to pay much more attention to the config of the Amiga. No WHDLoad fixes would be present

But it would allow you to update WHDLoad-ed game to latest version, using them to create new whdload files, something that is not supported from hacked ADFs.

Also it would be an important step towards supporting a real floppy drive. That won't be possible with the current floppy drive implementation on this core.