Pasti images that should, but don't work

[AtariZoll]

Unfortunately Aufit do not currently have write track data capability ... so I cant do it
Pure speculation ...
The code is probably looking for the non readable last sector located after sector 9 in the read track data
For that matter look for A1 A1 A1 FB sequence and compare the first few bytes (looks like byte 8 is a good candidate)
If you want to simulate what you can do is put a break point after reading track and substitute byte 8 ion the non readable last data record ...

Well, if Aufit could do it, I would not ask for those track dumps
I can extract track dumps easily from STX images, so if you can make 5 STX images where in each track 78 dump is from different rev. , it would be good enough for me.
I already tried to fool with changing some data in track read, but it worked not. Code is sophisticated.

[npomarede]

See the attached file : track 78 side 0 was read 5 times with Hatari and capslib, using the CTR dump posted by Brume with several revolutions.
From a quick look, we see different results on each read, this should be good for your test I think.

Nicolas

[JimDrew]

I took a look of track 78, side 0 (bottom) with SCP's editor/analyzer. You can see that in fact there are fuzzy bits and valid sectors.

Yes, this is the same result as in the STX image : 5 "normal" sectors and 4 "fuzzy" ones.
Are you able with your analyzer to see if those fuzzy bytes are only in the data part of the sectors or if they happen in gaps too (maybe you could have an option in your analyzer to zoom on the graph and to show some vertical line for the boundaries of sector data for example ?)

Although I am adding the Zoom and overlay features (so you can see the difference between rotations), I am only working with flux data. Aufit works well for decoding Atari sectors, and that is not something that I really want to get into.

[DrCoolZic]

I corrected the list of games with Fuuzy read track (viewtopic.php?f=47&t=8219#p253944)
The first game is Power Drift not Jupiter Master drive.

For reference: I still think that detecting USABLE fuzzy bytes on a read track is not trivial. There are plenty of reasons that two read tracks returns different bytes in many places WITHOUT the usage of fuzzy bytes.
Therefore it is important to only check fuzzy bytes in specific locations (see viewtopic.php?f=102&t=25854&start=150#p247164) for basic explanations

[AtariZoll]

I corrected the list of games with Fuuzy read track (viewtopic.php?f=47&t=8219#p253944)
The first game is Power Drift not Jupiter Master drive.
For reference: I still think that detecting USABLE fuzzy bytes on a read track is not trivial. There are plenty of reasons that two read tracks returns different bytes in many places WITHOUT the usage of fuzzy bytes.
Therefore it is important to only check fuzzy bytes in specific locations (see viewtopic.php?f=102&t=25854&start=150#p247164) for basic explanations

Yes. I wondered about "was it Power Drift actually ?" God punished you for using so big font
I agree that fuzzy bytes in read track is not easy to resolve. But in case of Vroom, track read will always give same content after sync, because there is used byte value 7 to avoid WD1772 resync - talking about tracks holding game data, code. But if there is only 2-3 titles using this type of protection, it is likely not worth to even thinking about some Pasti.dll + format update .

[AtariZoll]

See the attached file : track 78 side 0 was read 5 times with Hatari and capslib, using the CTR dump posted by Brume with several revolutions.
From a quick look, we see different results on each read, this should be good for your test I think.
Nicolas

Thanx npomarede . It solved the problem, and game works as should. Was exactly as expected, but I like to be 100% sure. There is only track read used for tr. 78, and if it reads same content 2x in row, EOR-ing some data 2x with same value will result in start content (0 in this case), what prevents second start of race.
I need to send PM to Marakatti, that add info about STX image's problem at AM .

[DrCoolZic]

See the attached file : track 78 side 0 was read 5 times with Hatari and capslib, using the CTR dump posted by Brume with several revolutions.
From a quick look, we see different results on each read, this should be good for your test I think.
Nicolas

Thanx npomarede . It solved the problem, and game works as should. Was exactly as expected, but I like to be 100% sure. There is only track read used for tr. 78, and if it reads same content 2x in row, EOR-ing some data 2x with same value will result in start content (0 in this case), what prevents second start of race.
I need to send PM to Marakatti, that add info about STX image's problem at AM .

Would be interesting to get more details
Obviously the read track will read different data for the 4 "normal" fuzzy sectors (correctly handled by Pasti) + fuzzy bytes in the "hidden" sector (not handled by Pasti).
So when comparing the read track data is this on the complete track or only on the hidden sector?

And yes I have been struck by Jupiter lightning for using big fonts (in fact the bbcode is not available from the editor and I was curious to experiment - for info you have to put huge value to get something readable)

[AtariZoll]

VroomPr.png

This is main code of protection check.
Well visible that read track is used : $E0 at $554A
After read track it's length is tested for max and min value.
Original content at $55BA is : move.b (a0)+,(a2)+ 2x . Replaced with 2x nop in first execution (at bottom).
EORing is at $55DC .
All 9 sectors are used in EOR-ing, in order (d3 as counter). First sector on track has no fuzzy data, following ones (4 ?) have it.
I don't know why they used sectors here at all - it should work without them too. Maybe because of duplication machines ? Or just confusing ?

[DrCoolZic]

As I mentioned the only way to reliably check randomness in a track is for bytes after sync. therefore using sectors make sense (but could be tested more easily by read sector command) + having this last pseudo sector without ID record definitively requires a read track.
By the way I just added a description for Fuzzy track in mt protection document at viewtopic.php?f=95&t=21952&p=253989#p253989

[Jeff_HxC2001]

I tried the SCP Vroom dump with the good old HxC USB Floppy Emulator : Works perfectly here .

SAM_3053.jpg

Here is the HxC view of the track 78:

Image2.png

and here a closer view to these "in track" flakey bits :

Image5.png

[AtariZoll]

I tried the SCP Vroom dump with the good old HxC USB Floppy Emulator : Works perfectly here .
...

Nice. Except file size, of course.

Btw, I was thinking why this extra protection on track 78, when used tracks are not copyable with Ataris. The answer would be: to prevent possible copy with Amigas - which certainly could copy tracks used here.

[Jeff_HxC2001]

I tried the SCP Vroom dump with the good old HxC USB Floppy Emulator : Works perfectly here .
...

Nice. Except file size, of course.

Not a problem at all : The AFI file take only 803KB

Similar idea as the audio compression : separate the data and the frequency domains, and you can have a very high compression ratio.

[JimDrew]

I tried the SCP Vroom dump with the good old HxC USB Floppy Emulator : Works perfectly here .
...

Nice. Except file size, of course.

Well, you don't need 4 or 5 revs. Just a single rev with Index mode works fine. That makes the fize size substantially smaller. You can also turn off the preservation mode and the image will compress up to 90% (and still works). This is common practice since the main Amiga emulators support compressed .scp image files.

[AtariZoll]

Well, you don't need 4 or 5 revs. Just a single rev with Index mode works fine. That makes the fize size substantially smaller. You can also turn off the preservation mode and the image will compress up to 90% (and still works). This is common practice since the main Amiga emulators support compressed .scp image files.

So, this type of protection ( fuzzy data in track) can be imaged correct with less revs ? In fact, 2 revs should be enough for this concrete case. But some titles check more for fuzzy data. Turning off preservation mode ? I guess that lot of things can be done when user knows what doing, and have time to test copy thoroughly. Somehow I think that for safety reasons long copies will be in use and circulation, as it is with STX images already. That must be not so bad thing, considering modern storage space and prices.
All this makes me to think again about online database with accurate description of copy protections used by Atari SW . Especially useful in case of delayed protections and not supported by Pasti ones.

[JimDrew]

For flux level, yes only a single revolution is needed. A real disk only has a single revolution.

This is why flux level support makes all of these compatibility issues just go away. No patching required, 100% of everything just works at that point. That is how WinUAE and FS-UAE are now with .scp image files.

[ijor]

This is an update on all the titles that have some kind of problem with Pasti. In this post I am just giving information after checking the cause of the problem. I intend to fix all of them, hopefully shortly.

War Heli:

There is a problem with the available images. This title is very sensitive to variations of the SYNC byte when issuing a read track. The standard imaging tool usually fails to provide a correct description. Will try to post a correct fixed image. The problem has no relation to the DLL version or to the "Disable Randomize" option.

Jupiter's Master Drive

Similar situation as War Heli. Here the standard imaging tool misses the first sync and builds an incorrect track description. A correct fixed image will work.

Antago

Works ok. Requires the floppy to be write protected.

Albedo

Sometimes works, sometimes does not. There is a timing misrepresentation issue between the DLL and the emulator. Proper fix on an updated DLL.

Combo racer (4 wheel drive compilation version)

Unless there is some other emulation issue, this is a bug on the title. I don't have an original disk to confirm it (anyone?). But as far as I can see (again, unless there is some other emulation issue), this version will sometimes randomly fail on real hardware. It is just by chance that the available image happens to fail always (that I will fix). And it is just by pure chance that a hacked version of the DLL works.

Power Drift and Vroom

These titles have weak bits read with the Read Track command. Currently not implemented. I intend to implement something shortly.

Necrosys

Demo. Not copy protected. Plain MSA or ST image. Haven't investigated to the end. But it is likely a timing issue. The DLL was never meant to be extremely accurate on non Pasti images. Will try to see how hard is to fix it.

[Steven Seagal]

That's great news! Pasti is back!

[catmando]

That's great news! Pasti is back!

+1

[Maartau]

That's great news! Pasti is back!

+1

+1

[DrCoolZic]

good to hear you are working again on Pasti

[Marakatti]

Great news indeed

[AtariZoll]

Nice news. Pasti is great achievement, and it is good if people can do imaging till' floppies are still in one piece. Not everyone has KryoFlux or SCP.
I saw some mention of MP Golf problem, but now can not find that post. I tried with Pasti 2e instead 2h, but rotation speed problem seems be there with it too, as crashes on same way. All is set to max accuracy
Hopefully this will make more people to dig out their old floppies and maybe some better manual for imaging tool. It is not easy for people without certain level of floppy knowledge.

[npomarede]

Hi
Regarding MP Golf, IIRC the problem under emulation to make it work was to have accurate timings to read sectors at the same speed as real STF, which required to take all GAPs'size into account (even if those tracks are standard tracks with no protections)
Pasti supports timings to tell when a sector starts with reference to the start of the track, so it should have worked, but maybe Pasti assumes some different values for last GAP of a track or things like that, which could explain the difference.
For comparison, a kryoflux/ipf image of MP Golf works under emulation.

Nicolas

[ijor]

The problem with MP Golf was fixed at Pasti DLL 0.2i. Version 0.2h won't work. Yeah, I never uploaded 0.2i to my site, but should be somewhere here at the forum. Otherwise let me know.

I don't think it was related to gap sizes, but I don't remember exactly what was the timing issue. But it was fixed years ago anyway.

Btw Nicolas, there a couple of images that work under Hatari, when they shouldn't. I think you mentioned you are not randomizing read track data? That would make some images (that shouldn't work) work, but it will break others.

[npomarede]

Btw Nicolas, there a couple of images that work under Hatari, when they shouldn't. I think you mentioned you are not randomizing read track data? That would make some images (that shouldn't work) work, but it will break others.

Yes, so far, I don't randomize the first bytes when reading a track.
As you said, this will make some games work (that don't work today with pasti) and other will not work.
On the other end, if I randomize, it will be the opposite, so there's no 100% solution at this time
Hopefully, if you release a new pasti version that work with the images that don't work today, then I will update Hatari to add proper random before the first index mark (IIRC ?)
BTW, what would be some games that won't work under Hatari because I don't randomize ? I tested many STX and they all worked so far.

Nicolas