Pasti images that should, but don't work

In this forum you'll find more information about the Pasti & VAPI Tools and the Preservation Project built around these tools. Come on in to find out more about it and discuss these projects.

Moderators: Mug UK, ijor, Moderator Team

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Tue Jun 03, 2014 7:14 pm

DrCoolZic wrote: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 :D
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.
There is way to stop global warming.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Pasti images that should, but don't work

Postby npomarede » Tue Jun 03, 2014 10:23 pm

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
You do not have the required permissions to view the files attached to this post.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 639
Joined: Mon Nov 04, 2013 5:23 pm

Re: Pasti images that should, but don't work

Postby JimDrew » Wed Jun 04, 2014 1:20 am

npomarede wrote:
JimDrew wrote: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.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Pasti images that should, but don't work

Postby DrCoolZic » Wed Jun 04, 2014 7:18 am

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Wed Jun 04, 2014 8:32 am

DrCoolZic wrote: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 ?" :D God punished you for using so big font :mrgreen:
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 .
There is way to stop global warming.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Wed Jun 04, 2014 8:37 am

npomarede wrote: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 .
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Pasti images that should, but don't work

Postby DrCoolZic » Wed Jun 04, 2014 8:55 am

AtariZoll wrote:
npomarede wrote: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) :mrgreen:

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Wed Jun 04, 2014 9:42 am

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 ?
You do not have the required permissions to view the files attached to this post.
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Pasti images that should, but don't work

Postby DrCoolZic » Wed Jun 04, 2014 4:33 pm

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
Captain Atari
Captain Atari
Posts: 309
Joined: Fri Sep 21, 2007 7:35 pm
Location: Paris - France
Contact:

Re: Pasti images that should, but don't work

Postby Jeff_HxC2001 » Wed Jun 04, 2014 9:59 pm

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

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
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Thu Jun 05, 2014 9:25 am

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

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.
There is way to stop global warming.

Jeff_HxC2001
Captain Atari
Captain Atari
Posts: 309
Joined: Fri Sep 21, 2007 7:35 pm
Location: Paris - France
Contact:

Re: Pasti images that should, but don't work

Postby Jeff_HxC2001 » Thu Jun 05, 2014 2:32 pm

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

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. :D

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 639
Joined: Mon Nov 04, 2013 5:23 pm

Re: Pasti images that should, but don't work

Postby JimDrew » Thu Jun 05, 2014 3:36 pm

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

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.
I am the flux ninja

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Fri Jun 06, 2014 8:26 am

JimDrew wrote: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.
There is way to stop global warming.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 639
Joined: Mon Nov 04, 2013 5:23 pm

Re: Pasti images that should, but don't work

Postby JimDrew » Fri Jun 06, 2014 2:51 pm

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.
I am the flux ninja

ijor
Hardware Guru
Hardware Guru
Posts: 3151
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Pasti images that should, but don't work

Postby ijor » Fri Sep 16, 2016 8:35 pm

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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1988
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Pasti images that should, but don't work

Postby Steven Seagal » Sat Sep 17, 2016 6:32 am

That's great news! Pasti is back!

User avatar
catmando
Atari Super Hero
Atari Super Hero
Posts: 929
Joined: Tue Jan 24, 2006 9:56 pm
Location: London, UK

Re: Pasti images that should, but don't work

Postby catmando » Sat Sep 17, 2016 6:35 pm

Steven Seagal wrote:That's great news! Pasti is back!


+1 :D
Atari Falcon Tos 4.04 | 14mb | IDE CF 2GB
Atari STE Tos 1.62 | 4mb | HxC Slim SD 8GB
Atari STE Tos 1.62/2.06 | 4mb | Floppy A-B Mod | IDE SD 4GB
Atari STFM
Android Devices (Running Hataroid and SToid)

Atari Forum Wiki - Use it before asking

Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2593
Joined: Thu Dec 15, 2005 2:15 am

Re: Pasti images that should, but don't work

Postby Maartau » Sat Sep 17, 2016 8:50 pm

catmando wrote:
Steven Seagal wrote:That's great news! Pasti is back!


+1 :D


+1 :D :D

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Pasti images that should, but don't work

Postby DrCoolZic » Sun Sep 18, 2016 10:21 pm

good to hear you are working again on Pasti :)

User avatar
Marakatti
Atari God
Atari God
Posts: 1310
Joined: Sat Jun 18, 2005 9:58 am
Location: Finland
Contact:

Re: Pasti images that should, but don't work

Postby Marakatti » Mon Sep 19, 2016 8:55 am

Great news indeed :)
-------------< Member of Atarimania >-----------
-< ST / STe / Falcon030 / TT030 archiver >-
-------------> www.atarimania.com <-------------

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2945
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Pasti images that should, but don't work

Postby AtariZoll » Mon Sep 19, 2016 2:11 pm

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.
There is way to stop global warming.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Pasti images that should, but don't work

Postby npomarede » Mon Sep 19, 2016 2:55 pm

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
Hardware Guru
Hardware Guru
Posts: 3151
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Pasti images that should, but don't work

Postby ijor » Mon Sep 19, 2016 4:18 pm

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.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Pasti images that should, but don't work

Postby npomarede » Mon Sep 19, 2016 4:29 pm

ijor wrote: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


Social Media

     

Return to “Pasti & VAPI”

Who is online

Users browsing this forum: No registered users and 2 guests