WANTED: most missing images

[greatguy]

Does anyone have the original 3 disk release of Zak McKracken? I´m trying to image my game but no matter how much I clean the disks I still get read errors.

I have at least managed to get clean images of my original release of Maniac Mansion.

[Stefan jL]

I have it I try and image it.

[greatguy]

I have it I try and image it.

Great, hope you get clean copies from your version.

[Stefan jL]

hmm... now when i found my Zak copy so did it turn out to be the 2 disk version... sorry

[greatguy]

hmm... now when i found my Zak copy so did it turn out to be the 2 disk version... sorry

You can still try to make SCP images of those disks if you want and have the time. Would be really nice to at least have those in my collection.

[Stefan jL]

ok.. here is the 2 disk (not kixx) version, i also made a scp of the savegame disk http://www.ym2149.com/scp/zak_mckracken_scp.7z

[greatguy]

ok.. here is the 2 disk (not kixx) version, i also made a scp of the savegame disk http://www.ym2149.com/scp/zak_mckracken_scp.7z

Thank you!

[greatguy]

Does anyone have the original 3 disk release of Zak McKracken? I´m trying to image my game but no matter how much I clean the disks I still get read errors.

FYI

Just bought a "new" three disk version of Zak McKracken from eBay. Luckily this version works 100%

[Brume]

dlfrsilver asked me for Albedo.
I imaged it some weeks ago, but I was sure someone has already done it and posted it somewhere... Well, faulty memory

@AtariZoll: so do you still want it? I dumped it in SCP, KF and STX formats.
The STX file doesn't work with Steem (it was done on the original machine). Then, I tried to generate a STX file with the RAW and the SCP files with Aufit: same thing, it doesn't work with Steem.
But the .CTR dump works very well. Have played a long with it and didn't notice any bug.
Let me know.

[Maartau]

Does anyone have the original 3 disk release of Zak McKracken? I´m trying to image my game but no matter how much I clean the disks I still get read errors.

FYI

Just bought a "new" three disk version of Zak McKracken from eBay. Luckily this version works 100%

Also interested by dumps if possible ...

[DrCoolZic]

me too (I mean albedo)
Do you know the protection?
Something not supported by STX format?

[dlfrsilver]

me too (I mean albedo)
Do you know the protection?
Something not supported by STX format?

albedo can be processed in STX with latest Aufit version and runs only with Steem 3.7.0 beta.

it uses St bootsector, but all the remaining is amiga tracks.... If you tried to convert the dump in *.ST, you'll see that out of the boot sector, it's not ST format.

It uses something equivalent to the amiga version (which use 4us tracks, created on a macintosh drive/computer), but here it's very long tracks.

I let Brume post his dump

[Brume]

albedo can be processed in STX with latest Aufit version and runs only with Steem 3.7.0 beta.

What is the number of the latest version? I used v0.4c that is available on Aufit website and it didn't work...

Link to Albedo package (SCP, KF and STX files):

https://mega.co.nz/#F!XYkm0ZJR!lOoW3RHySXtKf1xjb5PMqg

[AtariZoll]

dlfrsilver asked me for Albedo.
I imaged it some weeks ago, but I was sure someone has already done it and posted it somewhere... Well, faulty memory

@AtariZoll: so do you still want it? I dumped it in SCP, KF and STX formats.
The STX file doesn't work with Steem (it was done on the original machine). Then, I tried to generate a STX file with the RAW and the SCP files with Aufit: same thing, it doesn't work with Steem.
But the .CTR dump works very well. Have played a long with it and didn't notice any bug.
Let me know.

Yes, i want STX image of it, even if works not in Steem. As said, it is likely protection not supported by Pasti, but that's not problem for me
Ah, there is DL link ... Will inform about protection check later. Thanx

[dlfrsilver]

dlfrsilver asked me for Albedo.
I imaged it some weeks ago, but I was sure someone has already done it and posted it somewhere... Well, faulty memory

@AtariZoll: so do you still want it? I dumped it in SCP, KF and STX formats.
The STX file doesn't work with Steem (it was done on the original machine). Then, I tried to generate a STX file with the RAW and the SCP files with Aufit: same thing, it doesn't work with Steem.
But the .CTR dump works very well. Have played a long with it and didn't notice any bug.
Let me know.

Yes, i want STX image of it, even if works not in Steem. As said, it is likely protection not supported by Pasti, but that's not problem for me
Ah, there is DL link ... Will inform about protection check later. Thanx

The protection is supported, but you need to use latest version of Aufit with the dump, and steem v3.7.0 beta.

[DrCoolZic]

albedo can be processed in STX with latest Aufit version and runs only with Steem 3.7.0 beta.

What is the number of the latest version? I used v0.4c that is available on Aufit website and it didn't work...

Link to Albedo package (SCP, KF and STX files):

https://mega.co.nz/#F!XYkm0ZJR!lOoW3RHySXtKf1xjb5PMqg

Latest version is 0.9.xxx here http://www.atari-forum.com/viewtopic.ph ... 34#p266034
thought you would know

I will check tomorow

[npomarede]

The protection is supported, but you need to use latest version of Aufit with the dump, and steem v3.7.0 beta.

Tested this STX of Albedo under latest Hatari 1.8 and it works without any problem.
Track 0 has 5 1024 byte sectors and 1 512 byte sector ; other track are just raw track, without sector (similar to Mortevielle Manor, Vroom, Damocles, ...)
Nicolas

[DrCoolZic]

The protection is supported, but you need to use latest version of Aufit with the dump, and steem v3.7.0 beta.

Tested this STX of Albedo under latest Hatari 1.8 and it works without any problem.
Track 0 has 5 1024 byte sectors and 1 512 byte sector ; other track are just raw track, without sector (similar to Mortevielle Manor, Vroom, Damocles, ...)
Nicolas

this seems to indicate reading gap data before first sector and pasti using complement data in this area

[npomarede]

The protection is supported, but you need to use latest version of Aufit with the dump, and steem v3.7.0 beta.

Tested this STX of Albedo under latest Hatari 1.8 and it works without any problem.
Track 0 has 5 1024 byte sectors and 1 512 byte sector ; other track are just raw track, without sector (similar to Mortevielle Manor, Vroom, Damocles, ...)
Nicolas

this seems to indicate reading gap data before first sector and pasti using complement data in this area

Maybe similar to Jupiter masterdrive which worked under Hatari using own STX support when compared to official pasti.dll

[AtariZoll]

I looked little in code of Albedo early loading stage. it has lot of tack read commands and extremely many checks for diverse patterns. Never seen so long code for testing protection. Hard to follow, but easy to crack It must appear value 6 at some RAM location, then it will start game (counting differences ?). And it just not stops to read track 0 if check fails .. Seems like fuzzy data in track ..
I think that DrCoolZic can say more after analysis ..

[npomarede]

I looked little in code of Albedo early loading stage. it has lot of tack read commands and extremely many checks for diverse patterns. Never seen so long code for testing protection. Hard to follow, but easy to crack It must appear value 6 at some RAM location, then it will start game (counting differences ?). And it just not stops to read track 0 if check fails .. Seems like fuzzy data in track ..
I think that DrCoolZic can say more after analysis ..

STX doesn't support fuzzy data in track, so I don't think the protection checks that bits are fuzzy in some tracks, else it would not pass.

[dlfrsilver]

I looked little in code of Albedo early loading stage. it has lot of tack read commands and extremely many checks for diverse patterns. Never seen so long code for testing protection. Hard to follow, but easy to crack It must appear value 6 at some RAM location, then it will start game (counting differences ?). And it just not stops to read track 0 if check fails .. Seems like fuzzy data in track ..
I think that DrCoolZic can say more after analysis ..

STX doesn't support fuzzy data in track, so I don't think the protection checks that bits are fuzzy in some tracks, else it would not pass.

There is no fuzzy bits, as aufit showed it when i used it on the dump of Brume

Only Long amiga tracks, and a nasty copy protection (maybe less nasty than the amiga one).

[npomarede]

...amiga tracks...

Please, not again ...

[dlfrsilver]

...amiga tracks...

Please, not again ...

Authors have used a macintosh drive to make the amiga version. You know like me that the ST can't read Macintosh track format.

So the only solution remaining is to write long tracks with an amiga for the ST version.

[npomarede]

...amiga tracks...

Please, not again ...

Authors have used a macintosh drive to make the amiga version. You know like me that the ST can't read Macintosh track format.

So the only solution remaining is to write long tracks with an amiga for the ST version.

You're still doing the same confusion : it's not because the track was written with an Amiga that it means the ST can read Amiga track.

The Amiga was used to write an ST track that could not be written otherwise on a ST, because the WD1772 interprets some bytes and prevent you from writing some specific bytes at any position (bytes above $F5 which are "interpreted"). The ST can only read ST tracks, not generic Amiga tracks.

It can't read any random Amiga track, because as already explained the WD1772 will keep its AM detector ON during the read track command and this will cause some resync when certain bytes combinations are encountered, meaning the data you get in RAM after the read track are not the same data that were on disk. If you read an Amiga floppy with read track on ST, chances are high you will get a different (=wrong) content than if you read the same track on Amiga.

Amiga can be used to produce CTR files of Amiga or ST floppies in many conditions (where using fixed bitcells for example), Atari's FDC just can't do that, it will interpret some bytes, and you have no way to know if what you get in RAM is really what was on the floppy (unless the floppy was written to be compatible with the limitation of the FDC, by removing/escaping certain bytes, but in that case this is not a generic track (ie Amiga track if you want) anymore).

The Amiga's FDC is a very versatile chip that can write tracks compatible with some other more limited FDC, but it doesn't mean those other FDC are capable of reading generic Amiga tracks with any content, they read tracks written on an Amiga with a specific content for these FDC, which is not the same thing.

Nicolas