Creating your own IPFs

[Don_Adan]

Originally Posted by kremiso

the 68000 lock is the worst thing imo;
strange that in the v2 manual is written that the emulator can work also on 68020 (despite no speed gain btw), but it doesn't, at least with my tests with the cracked version

You tested on A2000 with 68020 Commodore turbo and kick 1.3?

[kremiso]

Originally Posted by Don_Adan

You tested on A2000 with 68020 Commodore turbo and kick 1.3?

not yet, it would be great to check better with specific configs
also, it could be a crack generated issue

if Abaddon reaches to made a working ipf we can check for differences

[demoniac]

Originally Posted by Abaddon

the emulator works (just as poorly as v1).

When I tested the UnitA version with an A1020 5.25" drive, the software took forever to load a screen. Games would either be too slow to play or simply stay on the title screen like Knight Games. The A1020 drive was pretty much useless from that point on.

P.S. I can't be sure if it was the A1020 or a real C64 floppy at a friend's house. Either case, the A1020 is doorstop.

[Abaddon]

The 64 Emulator V2 Unofficial IPF uploaded to the zone. Track 20.0 could not be decoded, but it does not appear to be used. Will look into it a bit more to see if track 20.0 uses a different sync than what the game code calculates.

[Snoopy1234]

Originally Posted by Abaddon

The 64 Emulator V2 Unofficial IPF uploaded to the zone. Track 20.0 could not be decoded, but it does not appear to be used. Will look into it a bit more to see if track 20.0 uses a different sync than what the game code calculates.

Thank You What was it that caused the SCP image not to load in an emulator?

[Abaddon]

Originally Posted by Snoopy1234

Thank You What was it that caused the SCP image not to load in an emulator?

Never tested the scp in WinUAE. My assumption is that the odd syncs used caused the problem.

0x5ADA, //1
0x6955, //2
0x52D5, //3
0x52D5, //4
0x6A8A, //5
0x6A8A, //6
0x556A, //7
0x556A, //8
0x6A8A, //9
0x6A8A, //10
0x556A, //11
0x556A, //12
0x556A, //13
0x546A, //14
0x546A, //15
0x556A, //16
0x556A, //17
0x546A, //18
0x546A, //19
0x546A, //20
0x3455, //21
0x3455, //22
0x5569, //23
0x5569, //24
0x5534, //25
0x5569, //26
0x5534, //27
0x1562, //28
0x1562, //29
0x5563, //30
0x1562, //31
0x5563, //32
0x4A6A, //33
0x2D65, //34
0x4A6A, //35
0x6554, //36
0x4D1A, //37
0x1352, //38
0x1235, //39
0x1D23, //40 does not decode

[Snoopy1234]

Originally Posted by Abaddon

Never tested the scp in WinUAE. My assumption is that the odd syncs used caused the problem.

0x5ADA, //1
0x6955, //2
0x52D5, //3
0x52D5, //4
0x6A8A, //5
0x6A8A, //6
0x556A, //7
0x556A, //8
0x6A8A, //9
0x6A8A, //10
0x556A, //11
0x556A, //12
0x556A, //13
0x546A, //14
0x546A, //15
0x556A, //16
0x556A, //17
0x546A, //18
0x546A, //19
0x546A, //20
0x3455, //21
0x3455, //22
0x5569, //23
0x5569, //24
0x5534, //25
0x5569, //26
0x5534, //27
0x1562, //28
0x1562, //29
0x5563, //30
0x1562, //31
0x5563, //32
0x4A6A, //33
0x2D65, //34
0x4A6A, //35
0x6554, //36
0x4D1A, //37
0x1352, //38
0x1235, //39
0x1D23, //40 does not decode

Thank you for the list. I might try the disk in a real machine someday to see if it works.

[PascalDe73]

Originally Posted by Snoopy1234

Thank you for the list. I might try the disk in a real machine someday to see if it works.

Hi,

The IPF Works on a real Amiga 500 with a Gotek after a conversion in HFEv3 file.

[Snoopy1234]

Originally Posted by PascalDe73

Hi,

The IPF Works on a real Amiga 500 with a Gotek after a conversion in HFEv3 file.

Hi PascalDe73. The seller demonstrated the disk working on his A500 so I think that works ok. Abaddon has created a working image which will be fine for most. I haven't tried writing the ipf to disk.

[Abaddon]

Originally Posted by Snoopy1234

Hi PascalDe73. The seller demonstrated the disk working on his A500 so I think that works ok. Abaddon has created a working image which will be fine for most. I haven't tried writing the ipf to disk.

New version uploaded to the zone includes track 20.0 intact

T0.0: AmigaDOS Long Track (106600 Bits)
T0.1: The 64 Emulator
T1.0-20.0: The 64 Emulator V2
T20.1-79.1: AmigaDOS Long Track (106600 Bits)
T80.0-83.1: Unformatted

Going by v1 that track 20.0 was the same as as 19.1 I was able to locate the correct sync (0x5354) using the data from track 19.1 of v2 to find it.

[Snoopy1234]

Originally Posted by Abaddon

New version uploaded to the zone includes track 20.0 intact

T0.0: AmigaDOS Long Track (106600 Bits)
T0.1: The 64 Emulator
T1.0-20.0: The 64 Emulator V2
T20.1-79.1: AmigaDOS Long Track (106600 Bits)
T80.0-83.1: Unformatted

Going by v1 that track 20.0 was the same as as 19.1 I was able to locate the correct sync (0x5354) using the data from track 19.1 of v2 to find it.

Bravo

[kremiso]

seems another one preserved, great work

i'll do some tests comparison between the ipf and the cracked version;
the cracked v2 was strangely more unstable than v1, many games just lead to a guru at the end of loading

[Galahad/FLT]

So, does V2 need a complete recrack?

[acd2001]

keirf disk-utilities 2024-04-12 git 3845efb

Added support for The 64 Emulator V2, several AK Avalon titles, removed
dizzy dice (duplicate), updated a couple of protections, and cleanup

[rygar]

Originally Posted by acd2001

keirf disk-utilities 2024-04-12 git 3845efb

Added support for The 64 Emulator V2, several AK Avalon titles, removed
dizzy dice (duplicate), updated a couple of protections, and cleanup

Thank you!!! I was waiting for this release

[Snoopy1234]

The US release of Spirit of Excalibur (Virgin/Mastertronic) [2852] SPS shows unexpected track length in disk-analyse. The Format is amigados. Is it the right format for the US NTSC version?

[BarryB]

Originally Posted by Snoopy1234

The US release of Spirit of Excalibur (Virgin/Mastertronic) [2852] SPS shows unexpected track length in disk-analyse. The Format is amigados. Is it the right format for the US NTSC version?

If ADF's work then it's probably been duplicated with tracks slightly longer than normal! You can either ignore it or use a parameter that has * amigados_unknown_length as that will create an ipf with the nearest long tracks!

Checked my UK copy and that is 3 Disks and normal length tracks!

[Snoopy1234]

Originally Posted by BarryB

If ADF's work then it's probably been duplicated with tracks slightly longer than normal! You can either ignore it or use a parameter that has * amigados_unknown_length as that will create an ipf with the nearest long tracks!

Checked my UK copy and that is 3 Disks and normal length tracks!

Thanks! BarryB.

[TjLaZer]

Created another SCP dump from a disk I have, in the Zone. Amegas. DigiTek release. Not sure if this is the US release or not, but it works in NTSC. Tried to make an IPF but it won't work, must be different from the other version.

[Abaddon]

Originally Posted by TjLaZer

Created another SCP dump from a disk I have, in the Zone. Amegas. DigiTek release. Not sure if this is the US release or not, but it works in NTSC. Tried to make an IPF but it won't work, must be different from the other version.

Looks like the copy has an actual protection check. It uses the frank_neuhaus_protection on track 0.1

You can update the format file definition to create a working IPF (see below for the update), but you may need to redump the game as it has one bad track (T57.0: sectors 1, missing)

"Amegas"
    1 amigados frank_neuhaus_protection
    158 amegas_high_scores amigados
    * amigados