MiSTer FPGA Forum

Telemachus wrote: ↑Mon Jan 16, 2023 12:19 pm

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.

As I said, IPF is a preservation format intended to reproduce 1:1 physical copies of discs in the future, nothing that has anything to do with MiSTer.

Nuked cracks should be flagged in collections and they are flagged. On disc based systems there are usually no "bad dumps" as with rom-dumps (and even with rom-dumps the idea is simply to flag the bad dumps e.g. with (b)).

There are countless cases in which copy protection stands in the way of preservation (lenslock, online activation, etc.) I agree that copy protected media should be archived in a way that makes a recreation of the original possible, but by no means this would make cracked media obsolete. On a daily use basis the advantages of having a cracked software outweighs the advantages of having software with working copy protection.

In most cases copy protection is harming the usability of software and archiving it serves no purpose besides preservation.

I am not aware of non working games, because of "non cracked" disc images. Do you have any examples for this?

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

I am not aware of non working games, because of "non cracked" disc images. Do you have any examples for this?

I don't have a list of non working games because of bad cracks but you can find many posts about it on various forums.
The problem is people boot these games and see that it loads and think it is fine.
But what often happens is the game will break later on, this can happen at a certain level or boss fight and it can often be deliberate by the copy protection. As kids we often didn't get far in these games and never saw the problem and the cracks were often not fully tested either.

https://www.atari-forum.com/viewtopic.php?t=15703 One topic example, there are plenty on the Amiga too.

So in actuality it is the cracks that harm the usability of the software not the other way around.

These days I really don't want to play the lottery of will this cracked copy hold up. I'd rather have the confidence in a perfect backup that works.

Malor wrote: ↑Mon Jan 16, 2023 10:56 am

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.

The TG-68K CPU module the MiSTer core uses is not cycle accurate though

From AtariST Readme:
Cycle accurate FX68K CPU core

jca wrote: ↑Mon Jan 16, 2023 3:52 pm

From AtariST Readme:
Cycle accurate FX68K CPU core

I was only commenting about Minimig core which uses a different CPU module . TG-68K holds back the Minimig core speed too

Armakuni wrote: ↑Mon Jan 16, 2023 3:29 pm

Malor wrote: ↑Mon Jan 16, 2023 10:56 am

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.

The TG-68K CPU module the MiSTer core uses is not cycle accurate though

I'll cheerfully admit my expertise on the Minimig is low, but I'm sure I read that the A500 is cycle-exact, as that's the mode to fall back to with troublesome programs. I could have misunderstood or other posters might be wrong, but I've seen cycle-exact 68000 claimed multiple times.

Regardless, IPF shouldn't need cycle-exact CPU timings. It should need cycle-exact floppy timings, since the purpose of the format is to precisely replicate physical floppies. Dependence on CPU timings would be the province of actual Amiga programs. If the IPF library is done right, and a 68020 fails to load a game, it should also fail to load the same game on real hardware.

Malor wrote: ↑Mon Jan 16, 2023 4:53 pm

Armakuni wrote: ↑Mon Jan 16, 2023 3:29 pm

Malor wrote: ↑Mon Jan 16, 2023 10:56 am

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.

The TG-68K CPU module the MiSTer core uses is not cycle accurate though

I'll cheerfully admit my expertise on the Minimig is low, but I'm sure I read that the A500 is cycle-exact, as that's the mode to fall back to with troublesome programs. I could have misunderstood or other posters might be wrong, but I've seen cycle-exact 68000 claimed multiple times.

Regardless, IPF shouldn't need cycle-exact CPU timings. It should need cycle-exact floppy timings, since the purpose of the format is to precisely replicate physical floppies. Dependence on CPU timings would be the province of actual Amiga programs. If the IPF library is done right, and a 68020 fails to load a game, it should also fail to load the same game on real hardware.

It's stated in the TG-68K GitHub

"The core does not value cycle accuracy"

https://github.com/TobiFlex/TG68K.C

This is possibly why we still see some issues with the Minimig core in demos and even in games. The same module covers OCS/ECS and AGA

Telemachus wrote: ↑Mon Jan 16, 2023 2:58 pm

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

I am not aware of non working games, because of "non cracked" disc images. Do you have any examples for this?

I don't have a list of non working games because of bad cracks but you can find many posts about it on various forums.
The problem is people boot these games and see that it loads and think it is fine.
But what often happens is the game will break later on, this can happen at a certain level or boss fight and it can often be deliberate by the copy protection. As kids we often didn't get far in these games and never saw the problem and the cracks were often not fully tested either.

https://www.atari-forum.com/viewtopic.php?t=15703 One topic example, there are plenty on the Amiga too.

So in actuality it is the cracks that harm the usability of the software not the other way around.

These days I really don't want to play the lottery of will this cracked copy hold up. I'd rather have the confidence in a perfect backup that works.

These are bad cracks, not "non cracked disc images" and yes, everyone should look the crack up before playing a specific game. Doesn't change the fact that the overwhelming majority of cracks on the ST works as intended and often has advantages over the original, e.g. double sided 1 disc versions instead of single sided 2 disc versions.

Don't get me wrong, feel free to request IPF support, but I wouldn't get my hopes high if I were you. It is not trivial to implement if you want to do it right and the benefit would be minimal. It will be hard to convince someone in putting the effort in it.

Malor wrote: ↑Mon Jan 16, 2023 4:53 pm

Regardless, IPF shouldn't need cycle-exact CPU timings. It should need cycle-exact floppy timings, since the purpose of the format is to precisely replicate physical floppies. Dependence on CPU timings would be the province of actual Amiga programs. If the IPF library is done right, and a 68020 fails to load a game, it should also fail to load the same game on real hardware.

You would need at least cycle accuracy for the CPU and the FDC as they have to communicate in cycle accurate manner to get the copy protection work. On the ST I guess the DMA chip is necessary too.

The minimig core uses FX68K for 68000 and TG68K for 68020.

Optiroc wrote: ↑Mon Jan 16, 2023 6:25 pm

The minimig core uses FX68K for 68000 and TG68K for 68020.

Thanks for the clarification as it's not clear on the GitHub as it only states TG68K for the Minimig core

Armakuni wrote: ↑Mon Jan 16, 2023 4:11 pm

jca wrote: ↑Mon Jan 16, 2023 3:52 pm

From AtariST Readme:
Cycle accurate FX68K CPU core

I was only commenting about Minimig core which uses a different CPU module . TG-68K holds back the Minimig core speed too

This thread is somewhat messy as it is about IPF but in the Atari ST thread and there are mentions of both Atari ST and Minimig.
That said, and if I am not mistaken, Minimig uses FX68K for 68000 and TG-68K for 68020.

jca wrote: ↑Mon Jan 16, 2023 7:06 pm

Armakuni wrote: ↑Mon Jan 16, 2023 4:11 pm

jca wrote: ↑Mon Jan 16, 2023 3:52 pm

From AtariST Readme:
Cycle accurate FX68K CPU core

I was only commenting about Minimig core which uses a different CPU module . TG-68K holds back the Minimig core speed too

This thread is somewhat messy as it is about IPF but in the Atari ST thread and there are mentions of both Atari ST and Minimig.
That said, and if I am not mistaken, Minimig uses FX68K for 68000 and TG-68K for 68020.

That was mentioned above but there is no mention of FX68K on the GitHub only TG-68k which is what confused me

The ST core also supports the 020. It's probably using the TG-68K code for that part.

The MAME IPF code is BSD (e.g. perfectly GPL-compatible) and handles every IPF I've thrown at it. It's at https://github.com/mamedev/mame/blob/ma ... pf_dsk.cpp

The current wd1772 verilog code in, at least, https://github.com/MiSTer-devel/AtariST_MiSTer, is not capable of handling a floppy disk at a low enough level to handle protections.

BSD code is legally not GPL-compatible. What gives you that idea?

EDIT: For reference: look at how Linux did not get ZFS support for years while FreeBSD was able to lift it from the opened Solaris source code almost immediately. While probably not as hairy as that particular case (Oracle's suited sharks probably won't be looking at MiSTer).. still.. you can NOT legally just lift BSD code and drop it into a GPL project.

Malor wrote: ↑Mon Jan 16, 2023 10:56 am

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.

Technically, the wd1772 (in the ST) is a lot more complicated than paula's floppy support.

Bas wrote: ↑Fri Mar 10, 2023 9:55 am

BSD code is legally not GPL-compatible. What gives you that idea?

We chose our variant of BSD for it to be compatible. And in any case I can dual-license the code to GPL if necessary, I'm the copyright holder in the first place.

Then you need to dual-license it explicitly to prevent issues if you're concerned with such things in the first place.

If someone who actually does the work and who has doubts about the license asks me to dual-license, I will.

Indeed, do as you see fit. I just wanted to address the point that BSD-licensed works do not mix into GPL-licensed works at all.

Just letting you know, IPF (as well as SCP) formats is on my ‘todo’ list for my MiSTer Minimig Floppy project (this will already boot copy protected games from disk in real time) - I’m discussing use of the IPF library with the SPS at the minute and have a few options.
Now I haven’t started implementing these formats yet, as my focus is still on real disks, but I’m sure you understand that a good amount of the work to make real disks work will help here!

(deleted)

Some Amstrad cpc emulators like caprice forever or sugarbox have ipf support with codes from scratch to read or write ipf files

breiztiger wrote: ↑Mon Jan 22, 2024 7:36 pm

Some Amstrad cpc emulators like caprice forever or sugarbox have ipf support with codes from scratch to read or write ipf files

Rob Smith has stated in his latests video he is working on IPS

Cool