IPF Support

ransom
Posts: 14
Joined: Wed Jul 29, 2020 4:07 am
Has thanked: 1 time

IPF Support

Unread post by ransom »

Does this core support IPF's ? if not is it a possibility to add?

FPGA64
Top Contributor
Posts: 937
Joined: Mon Mar 01, 2021 3:10 pm
Has thanked: 49 times
Been thanked: 374 times

Re: IPF Support

Unread post by FPGA64 »

No it doesnt

breiztiger
Top Contributor
Posts: 468
Joined: Sun May 24, 2020 7:17 pm
Has thanked: 35 times
Been thanked: 99 times

Re: IPF Support

Unread post by breiztiger »

Ipf would be a very good addition for all floppy base core

CPC-Power Staff
rhester72
Top Contributor
Posts: 1321
Joined: Thu Jun 11, 2020 2:31 am
Has thanked: 15 times
Been thanked: 213 times

Re: IPF Support

Unread post by rhester72 »

If you search, there's a VERY lengthy thread on this already.

Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

That's an Amiga thread, though, they might not know about it.

Upshot: IPF is a proprietary format, using proprietary code, and none of the Mister devs seem interested in supporting it.

User avatar
RealLarry
Top Contributor
Posts: 881
Joined: Mon May 25, 2020 4:04 am
Location: San Junipero/DE/Earth
Has thanked: 120 times
Been thanked: 385 times

Re: IPF Support

Unread post by RealLarry »

I also can remember that this was already discussed somewhere and sometime. But even if IPF - along with KF, SCP and STX - wouldn't get supported, most of the games are available as (patched) ST image and as HDD version, so not a drama IMHO.

Contributor of tty2oled, author of tty2tft, tty2rpi and update_tty2xxx
Telemachus
Posts: 27
Joined: Tue Jul 12, 2022 11:23 am
Has thanked: 3 times
Been thanked: 3 times

Re: IPF Support

Unread post by Telemachus »

RealLarry wrote: Fri Jan 13, 2023 6:33 am

I also can remember that this was already discussed somewhere and sometime. But even if IPF - along with KF, SCP and STX - wouldn't get supported, most of the games are available as (patched) ST image and as HDD version, so not a drama IMHO.

The situation is similar for the Minimig core, At least for the Amiga you could just say WHDLoad and screw everything else. But that isn't really the experience of how people used the Amiga back in the day.

I'd say supporting an archival format like IPF is essential not just for having that retail copy experience but many cracked games in ADF/ST format are
simply broken.

Not all installs behave correctly either and not all games have installs.

Also setting up an HD can be annoying process for people and I'm not going to point people to some pre-made HD image that often doesn't
cover everything the user wants.

If someone is going to do make their own installs or get the latest install update they need to be able to use an IPF file to create the install
as cracked disk images are not supported anymore.

Ultimately I believe the objective should be about preserving authenticity and not "this is good enough" solutions.
Developing cores is hard but I have to confess I'm starting to see the original objective of this project go a stray and turning into a mad dash
of bare minimum requirements to get over the finish line then dump said core development.

More people could learn from furrtek. :)

User avatar
RealLarry
Top Contributor
Posts: 881
Joined: Mon May 25, 2020 4:04 am
Location: San Junipero/DE/Earth
Has thanked: 120 times
Been thanked: 385 times

Re: IPF Support

Unread post by RealLarry »

@Telemachus absolutely correct. And from the point of view of an "archaeologist" it is important to have a 1:1 copy of the original media. This is what the Floppy Disk Stream Image Repository is doing, for example. But what I said is the factual situation and either one dev has to implement the "archive routines" or the user has to learn how to use and handle the alternatives meanwhile.

Contributor of tty2oled, author of tty2tft, tty2rpi and update_tty2xxx
Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

IPF is proprietary, and the SPS has never published any code to drive it, AFAIK.

This is a free, GPL-based project. The devs are not going to implement IPF unless someone out there has written an authoritative, GPL-compatible library. The SPS has no interest in doing so, and generally aren't a very good outfit, so they're not going to be releasing any such code. Ergo, there will never be IPF support in Mister. You can marshal all the arguments you like for why it would be a good idea. It will still not happen, at least not unless some third party decides to write an IPF driver from scratch.

If you don't like this, go lean on the SPS, don't bother anyone on this project. Proprietary DLLs don't work for a GPL project.

User avatar
Chilli_Vibes
Posts: 129
Joined: Sat Mar 12, 2022 4:47 pm
Has thanked: 53 times
Been thanked: 33 times

Re: IPF Support

Unread post by Chilli_Vibes »

Telemachus wrote: Fri Jan 13, 2023 9:26 am

Ultimately I believe the objective should be about preserving authenticity and not "this is good enough" solutions.

100% Spot on.

Optiroc
Posts: 107
Joined: Sun May 24, 2020 7:29 pm
Has thanked: 7 times
Been thanked: 38 times

Re: IPF Support

Unread post by Optiroc »

IPF is closed source, which is quite unfathomable for a preservation project. I couldn’t believe what I was reading when I first encountered the project (SPS etc).

breiztiger
Top Contributor
Posts: 468
Joined: Sun May 24, 2020 7:17 pm
Has thanked: 35 times
Been thanked: 99 times

Re: IPF Support

Unread post by breiztiger »

IPF has been implement from scratch in several emu like caprice forever (amstrad CPC) and sugarbox (Amstrad CPC)

the authors can help anyone that want to implement real ifp floppy image support ;-)

EDIT : without need of SPS DLL

CPC-Power Staff
User avatar
Retro-Nerd
Posts: 279
Joined: Fri Jul 08, 2022 2:47 am
Has thanked: 11 times
Been thanked: 80 times

Re: IPF Support

Unread post by Retro-Nerd »

And WinUAE. I guess Toni Wilen would glady help when somebody ask him.

breiztiger
Top Contributor
Posts: 468
Joined: Sun May 24, 2020 7:17 pm
Has thanked: 35 times
Been thanked: 99 times

Re: IPF Support

Unread post by breiztiger »

i think, but i can be wrong, that winuae use SPS DLL

CPC-Power Staff
User avatar
Retro-Nerd
Posts: 279
Joined: Fri Jul 08, 2022 2:47 am
Has thanked: 11 times
Been thanked: 80 times

Re: IPF Support

Unread post by Retro-Nerd »

True, it's a CapsImg.dll. But on the softpres site there are linux versions too. Aren't there uncompiled source files included too? There is a developer package too for Linux

http://www.softpres.org/download

rhester72
Top Contributor
Posts: 1321
Joined: Thu Jun 11, 2020 2:31 am
Has thanked: 15 times
Been thanked: 213 times

Re: IPF Support

Unread post by rhester72 »

No, there is no source available from SPS. The Caprice implementation only covers the portions of the format that apply to the Amstrad AFAIK.

FPGA64
Top Contributor
Posts: 937
Joined: Mon Mar 01, 2021 3:10 pm
Has thanked: 49 times
Been thanked: 374 times

Re: IPF Support

Unread post by FPGA64 »

This has been beaten to an inch of its life already in

viewtopic.php?t=2730

Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

breiztiger wrote: Fri Jan 13, 2023 5:14 pm

i think, but i can be wrong, that winuae use SPS DLL

I'm just about certain this is correct. You have to drop the DLL file(s?) into the WinUAE directory for IPF images to work.

FPGA64
Top Contributor
Posts: 937
Joined: Mon Mar 01, 2021 3:10 pm
Has thanked: 49 times
Been thanked: 374 times

Re: IPF Support

Unread post by FPGA64 »

Malor wrote: Sun Jan 15, 2023 5:28 am
breiztiger wrote: Fri Jan 13, 2023 5:14 pm

i think, but i can be wrong, that winuae use SPS DLL

I'm just about certain this is correct. You have to drop the DLL file(s?) into the WinUAE directory for IPF images to work.

Yes thats the way WinUAE handles IPF. It does baffle me why a supposed Archival Format has a closed source reader for it. Surely the whole point is to be open so that in years to come it can still be read without closed source dlls

User avatar
desin24
Posts: 26
Joined: Sat Jun 06, 2020 6:25 pm
Been thanked: 6 times

Re: IPF Support

Unread post by desin24 »

Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

I don't think that's GPL compatible, so it's not usable in this project, and probably isn't going to get much wider acceptance. The non-commercial clause just isn't going to fly almost everywhere. WinUAE couldn't use it that way, for instance, nor Cloanto, nor MiSTer.

Telemachus
Posts: 27
Joined: Tue Jul 12, 2022 11:23 am
Has thanked: 3 times
Been thanked: 3 times

Re: IPF Support

Unread post by Telemachus »

Malor wrote: Mon Jan 16, 2023 6:41 am

I don't think that's GPL compatible, so it's not usable in this project, and probably isn't going to get much wider acceptance. The non-commercial clause just isn't going to fly almost everywhere. WinUAE couldn't use it that way, for instance, nor Cloanto, nor MiSTer.

" We have finally released the IPF library source code, under the same terms as MAME (non-commercial use)."

MAME = License GPL-2.0-or-later

How much of MAME has gone into the MiSTer Project already?

WinUAE is sold as part of Cloanto's Amiga Forever package so it is understandable why IPF support is externally implemented.

Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

If MAME has a restriction against commercial use, then it's not GPL, full stop. Even if they claim otherwise, a restriction on any downstream use is not compatible with the GPL.

FPGA64
Top Contributor
Posts: 937
Joined: Mon Mar 01, 2021 3:10 pm
Has thanked: 49 times
Been thanked: 374 times

Re: IPF Support

Unread post by FPGA64 »

Telemachus wrote: Mon Jan 16, 2023 7:34 am
Malor wrote: Mon Jan 16, 2023 6:41 am

I don't think that's GPL compatible, so it's not usable in this project, and probably isn't going to get much wider acceptance. The non-commercial clause just isn't going to fly almost everywhere. WinUAE couldn't use it that way, for instance, nor Cloanto, nor MiSTer.

" We have finally released the IPF library source code, under the same terms as MAME (non-commercial use)."

MAME = License GPL-2.0-or-later

How much of MAME has gone into the MiSTer Project already?

WinUAE is sold as part of Cloanto's Amiga Forever package so it is understandable why IPF support is externally implemented.

Not really Winuae is entirely seperate from Cloanto. Cloanto sell a package with Winuae but Cloanto have no say in how WinUae is developed

Telemachus
Posts: 27
Joined: Tue Jul 12, 2022 11:23 am
Has thanked: 3 times
Been thanked: 3 times

Re: IPF Support

Unread post by Telemachus »

May have been mentioned earlier but it was also reverse engineered by Olivier Galibert from MESS

Stated as 3-clause BSD licensed, which is GPL-compatible.

https://github.com/mamedev/mame/blob/ma ... /ipf_dsk.h

I suggest if anyone has any further questions they would be best directed to Mr. Vince who is the project leader.

http://eab.abime.net/showpost.php?p=782660&postcount=39 To which he stated,

"I think this can be put to rest now...?! The source is there and can be used to extract whatever kind of data you would like to access."

User avatar
Chris23235
Top Contributor
Posts: 982
Joined: Sun May 24, 2020 8:45 pm
Has thanked: 127 times
Been thanked: 197 times

Re: IPF Support

Unread post by Chris23235 »

First and foremost any format besides .ST would need a cylce exact simulation. MiSTery is not cycle exact and can't support IPF or STX.

Malor
Top Contributor
Posts: 860
Joined: Wed Feb 09, 2022 11:50 pm
Has thanked: 64 times
Been thanked: 194 times

Re: IPF Support

Unread post by Malor »

The A500 Minimig core is cycle-exact, and the ST is a far simpler machine, so that shouldn't be out of reach there, either.

Telemachus
Posts: 27
Joined: Tue Jul 12, 2022 11:23 am
Has thanked: 3 times
Been thanked: 3 times

Re: IPF Support

Unread post by Telemachus »

The GitHub page for MiSTery suggests a lot of cycle accuracy.

"Cycle accurate STe GLUE+MMU combo (re-created from the original schematics)
Cycle accurate FX68K CPU core
Cycle accurate Blitter offered by Jorge Cwik
Mostly cycle accurate shifter based on schematics made from reverse engineering"

It isn't clear if using an Atari 520ST config would be completely cycle accurate or if the remaining inaccuracies are for later models.

But yeah, the Atari 520ST is the common/popular and simple model of the series.

I don't know if it has been stated that the .IPF format would have the same limits as .STX when it comes to cycle accuracy.
IPF driver would certainly be handled by the ARM CPU.

On the Amiga side of things I'm pretty sure WinUAE is not cycle accurate in every aspect and it doesn't have a problem with IPF.

User avatar
Chris23235
Top Contributor
Posts: 982
Joined: Sun May 24, 2020 8:45 pm
Has thanked: 127 times
Been thanked: 197 times

Re: IPF Support

Unread post by Chris23235 »

Telemachus wrote: Mon Jan 16, 2023 11:05 am

The GitHub page for MiSTery suggests a lot of cycle accuracy.

"Cycle accurate STe GLUE+MMU combo (re-created from the original schematics)
Cycle accurate FX68K CPU core
Cycle accurate Blitter offered by Jorge Cwik
Mostly cycle accurate shifter based on schematics made from reverse engineering"

It isn't clear if using an Atari 520ST config would be completely cycle accurate or if the remaining inaccuracies are for later models.

But yeah, the Atari 520ST is the common/popular and simple model of the series.

I don't know if it has been stated that the .IPF format would have the same limits as .STX when it comes to cycle accuracy.
IPF driver would certainly be handled by the ARM CPU.

On the Amiga side of things I'm pretty sure WinUAE is not cycle accurate in every aspect and it doesn't have a problem with IPF.

In order to get cycle exact simulation all parts of the machine must be cycle accurate and they must communicate in exactly the same way with each other as in the original machine. This means the cycle accuracy has to be expanded to the communication of the components and peripherals. In this case it would mean to implement a cycle accurate floppy disc controller to the simulation. If you plan on using the ARM, it would mean to syncronize this FDC with the ARM.
I don't say it can't be done (I have no clue about such an implementation on the technical level), but for sure it would be no trivial task. The question is for what purpose? The general idea of IPF is that it should be possible to recreate physical media with the exact specifications of the original from the digital data. The FPGA doesn't work with physical floppy discs, so it seems rather useless.
Are there really games out there that exist only in IPF or STX format?

Telemachus
Posts: 27
Joined: Tue Jul 12, 2022 11:23 am
Has thanked: 3 times
Been thanked: 3 times

Re: IPF Support

Unread post by Telemachus »

Chris23235 wrote: Mon Jan 16, 2023 11:48 am

Are there really games out there that exist only in IPF or STX format?

I believe that is the case but the better case is that accurate backups vs bad cracked ones should offer better feedback on
improving things which gives more confidence in the process of bug fixing.
There are a lot of bad dumps out there even non cracked ones.
Fortunately there are communities dedicated to verifying quality dumps and we should really only be using old cracked backups as novelty nostalgia.

Post Reply