Power Drift and Pasti & patch

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: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Power Drift and Pasti & patch

Postby AtariZoll » Tue Jan 28, 2014 10:16 am

As is stated ( viewtopic.php?f=47&t=8372&p=224627&hilit=+power+drift#p224627 ) Power Drift 3 floppy original release can not be imaged with Pasti image tool. I looked in code to see why it fails. Was not hard to trace down problem. There is fuzzy data in track 1, side A of floppy 2, and that track has no sectors, so track read command is used , 2 times in row, and then some data is compared between 2 track reads. There must be difference, otherwise it will not accept disk. As I see, Pasti format has no support for fuzzy data in track dumps, and this is why this fails.
I did patch in image of floppy 1, where code is - just skipping that comparison, and it works now in Steem. Don't see any checksums or other tricks. Start with image with aP at end of filename. I included original STX image too, so may see what is patched - only 2 bytes.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Tue Jan 28, 2014 2:33 pm

I thought Pasti has fuzzy bits support, which is why Dungeon Master and many others work fine when converted from a .scp flux image to .stx using Aufit?
I am the flux ninja

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

Re: Power Drift and Pasti & patch

Postby npomarede » Tue Jan 28, 2014 3:22 pm

JimDrew wrote:I thought Pasti has fuzzy bits support, which is why Dungeon Master and many others work fine when converted from a .scp flux image to .stx using Aufit?

Pasti has fuzzy bits support only at the sector level, not at the track level. Same for timing variations, .stx files can only store variation of the default 32 microsec per byte at the sector level, not at the track level.
That's why in another thread I wrote that STX format was IMO limited as it can not store intra gap variations for example (which IPF format can). Of course, STX format could be extended, but that's another story.

Nicolas

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

Re: Power Drift and Pasti & patch

Postby AtariZoll » Tue Jan 28, 2014 3:26 pm

Of course there is fuzzy support in Pasti. And there is many SW using it in protections. However, as I see after quick look to Pasti specs. , it is limited for fuzzy data in regular sectors and no support for fuzzy data in track dumps. DrCoolZic could say more about this. I guess that reason is simply that it is very rare used protection system .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Wed Jan 29, 2014 1:32 am

I really think supporting flux level images in Hatari, Steem, etc. is the way to go. It's the same format used for other emulators already and its easy enough to implement. Jeff also has the C source code available that is used in HxC for reading/writing SCP images. It's just a matter of making a WD1772 core that clocks the flux data instead of trying to decode the .stx file and stick it into the WD1772 core. There are no 'cases' required when converting flux, no fuzzy bits or anything else to handle specifically... it just works for everything.
I am the flux ninja

Feltzkrone
Atarian
Atarian
Posts: 2
Joined: Mon Jan 06, 2014 4:34 pm

Re: Power Drift and Pasti & patch

Postby Feltzkrone » Wed Jan 29, 2014 11:26 pm

Most of the time. And depending on your drive's capabilities. :wink:

No-flux-areas (strong-bits, just to adapt your wording) have been discarded even though they have the perfect feature of not being copyable the analogue way. The reason for that is that they didn't work as expected with every drive model that has been used in a particular computer type. Weak bits are aswell delivered differently depending on the drive. Some deliver flux transitions which leave room for variation and random data through emulation while others just forward random timings which are in bit cell ranges typical for the encoding used by the target platform, in which case you end up with 2 variants in case you dump 2 revolutions. While this could generally be considered "weak" and will be satisfactory for some titles there are copy protections which read a track more than just 2 times in a row and expects a value at a particular position to be different always, i.e. no two reads may lead to the same value.

Regardless of what you are doing there will always be edge cases where there just is no straightforward solution...
Lord Crass on C64PP wrote:syncr0l0k - This awful little protection writes to the disk. It writes to t/s 19/02 and that must succeed or it tries over and over. Then it tries writing to t/s 20/02. This must fail or it tries over and over again. The protection seems to be based on physically damaged sectors that need to return errors when attempts are made to write to them.[...]

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

Re: Power Drift and Pasti & patch

Postby AtariZoll » Thu Jan 30, 2014 7:46 am

I agree that flux level images are the right thing. Now, is implementing it easy ... It needs detailed (to say so) emulation of WD1772 chip. which is at least complex as some 8-bit CPU . SCP team already did some emulation, although it is for IPF images, but we can not know how it is good really, since there is not much SW imaged. And I don't think that they want it to be open source.
"There are no 'cases' required when converting flux, no fuzzy bits or anything else to handle specifically... it just works for everything." - that may be true for images self, but in WD1772 emulation you need to 'handle' fuzzy bits and other things :D

Considering Pasti system, we could say some bad things about it and about lack of support, later development etc . But it is surely very useful and popular format. As main good I see possibility to make images on regular Atari ST(E) machines, without special cards. Currently about 95% of Atari ST SW is imaged in Pasti format, and there are only few cases when image works not (not talking about bad images), and even in such cases, most works not because CPU emulation and not imaging error or unsupported protection.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Thu Jan 30, 2014 11:51 pm

AtariZoll wrote:I agree that flux level images are the right thing. Now, is implementing it easy ... It needs detailed (to say so) emulation of WD1772 chip. which is at least complex as some 8-bit CPU . SCP team already did some emulation, although it is for IPF images, but we can not know how it is good really, since there is not much SW imaged. And I don't think that they want it to be open source.
"There are no 'cases' required when converting flux, no fuzzy bits or anything else to handle specifically... it just works for everything." - that may be true for images self, but in WD1772 emulation you need to 'handle' fuzzy bits and other things :D


You just need a WD1772 emulation. The emulation is really just a data separator. DrCoolZic has one done. I think at this point it's just a matter of changing it so that instead of bit shifting in MFM clock and data bits, raw flux transitions are used - which then get turned into MFM and decoded as the original WD1772 does. That automatically takes care of fuzzy bits and *everything else* because you are emulating the hardware (not interpreting what it does) and relying on the flux image to provide exactly what a real FDC gets for its data. The great thing about that is you have the ability to read/write Atari ST and PC 720K/1.44MB images with the same controller emulation, using the same flux format (.scp).
I am the flux ninja

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

Re: Power Drift and Pasti & patch

Postby npomarede » Fri Jan 31, 2014 11:29 am

JimDrew wrote:You just need a WD1772 emulation. The emulation is really just a data separator. DrCoolZic has one done. I think at this point it's just a matter of changing it so that instead of bit shifting in MFM clock and data bits, raw flux transitions are used - which then get turned into MFM and decoded as the original WD1772 does. That automatically takes care of fuzzy bits and *everything else* because you are emulating the hardware (not interpreting what it does) and relying on the flux image to provide exactly what a real FDC gets for its data. The great thing about that is you have the ability to read/write Atari ST and PC 720K/1.44MB images with the same controller emulation, using the same flux format (.scp).

Hello
As already discussed in other threads, I don't think anyone is denying the method to use to decode MFM bits and build the byte as they would come from the WD1772, but I'm afraid you're underestimating the time it takes to do it, it's just that it take a lot of time to write a full WD1772 emulation, from MFM decoding, to interpreting byte, to emulating all type I,II,III,IV commands, emulating all status bits, ...

And even when you follow all the WD1772 datasheet, guess what ? Some cases won't work, because the WD1772 has behaviour not documented, and then the only solution is to do your own HW test with a real WD1772 in a real STF, and do all sorts of timings in different scenario to get the same results in emulation as on real ST. Trust me, I spend a lot of time recently to improve FDC emulation in Hatari, the datasheets are just not enough.

So maybe flux level support will be added sometimes in Hatari (or in Steem), I don't know, but it's certainly not as trivial to do as you describe it when you say "you just need a WD1772 emulation", WD1172 emulation is a rather large subject (flux level support would allow to bypass some STX limitation, but the IPF format can already handle Power Drift, so it's not as if we don't have any other alternative for now)

Nicolas

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Fri Jan 31, 2014 3:45 pm

DrCoolZic has a complete WD1772 emulation done and will be sending me the data. So, I don't think it is really that much work at this point.
I am the flux ninja

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

Re: Power Drift and Pasti & patch

Postby npomarede » Fri Jan 31, 2014 4:09 pm

JimDrew wrote:DrCoolZic has a complete WD1772 emulation done and will be sending me the data. So, I don't think it is really that much work at this point.

I know he wrote tools recently in C#, if that's the case, it will be harder to reuse ; best would be a C library that can be reused in various emulator like Hatari or Steem or Saint (like capslibrary or pasti.ddl)

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Fri Jan 31, 2014 5:06 pm

He told me he has a complete emulation, which is what is required. A library is not going to be useful really. You need it part of the emulation core just like audio, video, etc. - something that can simply be .inc'd in replacing the current FDC code.
I am the flux ninja

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

Re: Power Drift and Pasti & patch

Postby npomarede » Fri Jan 31, 2014 6:13 pm

JimDrew wrote:He told me he has a complete emulation, which is what is required. A library is not going to be useful really. You need it part of the emulation core just like audio, video, etc. - something that can simply be .inc'd in replacing the current FDC code.

Yes, external library, code that can be included in the project, that's similar. But as far as I known DrCoolZic codes mostly for windows in C# or .NET, not sure it will fit nicely in Hatari which is written in C for Linux/Windows/OSX (or Steem in C++). Let's see what DrCoolZic will describe when he's back in the forum.

Nicolas

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Fri Jan 31, 2014 10:57 pm

I am not sure how you guys write your emulations. With all of mine, every part of the sub-system is included into the main emulation. Libraries are only used to call really high level functions, not any part of emulating real hardware. When DrCoolZic returns, we can discuss what data he has, and what format it is in. If it needs to be re-written in assembly (68K or x86) I can do that. If it needs to be converted to C or C++ then someone else will need to do that.
I am the flux ninja

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

Re: Power Drift and Pasti & patch

Postby npomarede » Sat Feb 01, 2014 12:25 pm

JimDrew wrote:I am not sure how you guys write your emulations. With all of mine, every part of the sub-system is included into the main emulation. Libraries are only used to call really high level functions, not any part of emulating real hardware. When DrCoolZic returns, we can discuss what data he has, and what format it is in. If it needs to be re-written in assembly (68K or x86) I can do that. If it needs to be converted to C or C++ then someone else will need to do that.

In the case of Hatari, most emulation code is written by us, as this is too specific to be found elesewhere, but we also use external libraries for PNG, SDL, ZIP support, ...
But Pasti or IPF support is using external libraries ; they provide library, there would not be real benefit to include the code in the Hatari project library when you can link directly against these libraries.

We don't use x86 or 68k in Hatari, one of the goal of the project is too be portable (windows, osx, linux, android, amiga,rasperry, ...), so including assembly would only benefit to one architecture, but we would still need the C equivalent for the others. So for Hatari, it needs to be C code if we want to include it directly in the project directory, or it needs to be an external library (in that case, we don't care in which language the library was written).

Nicolas

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

Re: Power Drift and Pasti & patch

Postby JimDrew » Sat Feb 01, 2014 11:32 pm

Understood! Thanks!

It's too bad you don't have the ability to use assembly. I just so happen to have the absolute fastest 68040 CPU emulation available, written in hand optimized x86 assembly. It's what I used for FUSION, my Mac emulation for the PC.
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: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 3:31 pm

AtariZoll wrote:As is stated ( viewtopic.php?f=47&t=8372&p=224627&hilit=+power+drift#p224627 ) Power Drift 3 floppy original release can not be imaged with Pasti image tool. I looked in code to see why it fails. Was not hard to trace down problem. There is fuzzy data in track 1, side A of floppy 2, and that track has no sectors, so track read command is used , 2 times in row, and then some data is compared between 2 track reads. There must be difference, otherwise it will not accept disk. As I see, Pasti format has no support for fuzzy data in track dumps, and this is why this fails.
I did patch in image of floppy 1, where code is - just skipping that comparison, and it works now in Steem. Don't see any checksums or other tricks. Start with image with aP at end of filename. I included original STX image too, so may see what is patched - only 2 bytes.

Quite interesting. First time I hear about this kind of protection!
Would you have an scp of KF files for this games.

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 3:45 pm

npomarede wrote:Pasti has fuzzy bits support only at the sector level, not at the track level.
Correct
Same for timing variations, .stx files can only store variation of the default 32 microsec per byte at the sector level, not at the track level.
Correct. However unless AtariZool find a games with a track that has no sector and byte variation it is not usefull. The most common on a track is to use a shorter/longer time for bytes that results in a track that has more or less bytes.
That's why in another thread I wrote that STX format was IMO limited as it can not store intra gap variations for example (which IPF format can).

Is this used somewhere? do you mean gap bytes with varying lenght?
As far a s I remember IPF file does not store any timing information directly. It just refers to a density format (e.g. short, long, speedlock, ...) and the library is responsible of converting this to timing values, so yes anything is possible.

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 3:54 pm

Feltzkrone wrote:Most of the time. And depending on your drive's capabilities. :wink:
No-flux-areas (strong-bits, just to adapt your wording) have been discarded even though they have the perfect feature of not being copyable the analogue way. The reason for that is that they didn't work as expected with every drive model that has been used in a particular computer type.

Very interesting can you provide more information. From what I understand the NFA is obtained by providing a high bit rate data write signal to the floppy drive. When reading the data signal is shifted beyond normal boundary resulting in no transition. From what I have heard it is difficult (and drive dependent) to find the right frequency for the write signal.

Weak bits are as well delivered differently depending on the drive. Some deliver flux transitions which leave room for variation and random data through emulation while others just forward random timings which are in bit cell ranges typical for the encoding used by the target platform, in which case you end up with 2 variants in case you dump 2 revolutions. While this could generally be considered "weak" and will be satisfactory for some titles there are copy protections which read a track more than just 2 times in a row and expects a value at a particular position to be different always, i.e. no two reads may lead to the same value.

No sure you are right on this one or I may not understand your point?

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 3:55 pm

Feltzkrone wrote:Most of the time. And depending on your drive's capabilities. :wink:
No-flux-areas (strong-bits, just to adapt your wording) have been discarded even though they have the perfect feature of not being copyable the analogue way. The reason for that is that they didn't work as expected with every drive model that has been used in a particular computer type.

Very interesting can you provide more information. From what I understand the NFA is obtained by providing a high bit rate data write signal to the floppy drive. When reading the data signal is shifted beyond normal boundary resulting in no transition. From what I have heard it is difficult (and drive dependent) to find the right frequency for the write signal.

Weak bits are as well delivered differently depending on the drive. Some deliver flux transitions which leave room for variation and random data through emulation while others just forward random timings which are in bit cell ranges typical for the encoding used by the target platform, in which case you end up with 2 variants in case you dump 2 revolutions. While this could generally be considered "weak" and will be satisfactory for some titles there are copy protections which read a track more than just 2 times in a row and expects a value at a particular position to be different always, i.e. no two reads may lead to the same value.

No sure you are right on this one or I may not understand your point?

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

Re: Power Drift and Pasti & patch

Postby npomarede » Fri Feb 07, 2014 3:57 pm

DrCoolZic wrote:Is this used somewhere? do you mean gap bytes with varying lenght?

Not that I know, but as Power Drift shows some protection that can't be imaged with Pasti, maybe some other games could use it.
For example, on a 9 sectors track, you have approx 600 bytes of GAP (usually value $4e) at the end of the track.
One could imagine a protection where those bytes would not be written at 32 ns, but 30 or 34 ns. In that case, you could check that when you read the track you have 128 consecutives bytes $4e that last 128*30=3840 ns instead of 128*32=4096 ns (similar to macrodos, but at the track level)

This is just theoretical, maybe no game was protected this way, but having a generic format where each byte is stored with its duration would be better than just handling the special case of the sector.

Nicolas

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 3:58 pm

AtariZoll wrote:Considering Pasti system, we could say some bad things about it and about lack of support, later development etc . But it is surely very useful and popular format. As main good I see possibility to make images on regular Atari ST(E) machines, without special cards. Currently about 95% of Atari ST SW is imaged in Pasti format, and there are only few cases when image works not (not talking about bad images), and even in such cases, most works not because CPU emulation and not imaging error or unsupported protection.

You are right! At some point I have been thinking of expanding stx format or rewriting a new format, but as you say it is a de facto standard even if we do not like it

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 4:06 pm

JimDrew wrote:DrCoolZic has a complete WD1772 emulation done and will be sending me the data. So, I don't think it is really that much work at this point.

I have some code that emulates the way the WD1772 decodes data from flux transition. Therefore I cover type II and type III commands.
As I have said many times I have no expertise in machine emulation so I am not 100% sure how the code can be used in an emulator.
What I can say is that when I compare the results that I obtain compared to a real WD1772 it is very close. I believe that this is mainly due to my DPLL code ...

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

Re: Power Drift and Pasti & patch

Postby DrCoolZic » Fri Feb 07, 2014 4:15 pm

npomarede wrote:
JimDrew wrote:DrCoolZic has a complete WD1772 emulation done and will be sending me the data. So, I don't think it is really that much work at this point.

I know he wrote tools recently in C#, if that's the case, it will be harder to reuse ; best would be a C library that can be reused in various emulator like Hatari or Steem or Saint (like capslibrary or pasti.ddl)

The wd1772 "emulator" was initially written in C++ (but it could be considered as C) for the KFProject (programs released about 2 years ago) see http://info-coach.fr/atari/software/pro ... oflux_prog

It is only recently that I have converted to C# to be able to integrate more easily with WPF GUI.

This part of the code is 95% C (even if written in C#) so this is not really an issue.
The best organization would be to have a C++ lib + a C/CLIWrapper lib. However I did not took this route because I already had to learn C++ and WPF and I did not want to learn C++/CLI on top of that ;)

By the way the KFProject can also read IPF files. Something Aufit cant do at this time.
Last edited by DrCoolZic on Fri Feb 07, 2014 4:34 pm, edited 1 time in total.

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

Re: Power Drift and Pasti & patch

Postby AtariZoll » Fri Feb 07, 2014 4:24 pm

Lord Crass on C64PP wrote:syncr0l0k - This awful little protection writes to the disk. It writes to t/s 19/02 and that must succeed or it tries over and over. Then it tries writing to t/s 20/02. This must fail or it tries over and over again. The protection seems to be based on physically damaged sectors that need to return errors when attempts are made to write to them.[...]


Hmm ... I had recently look in protection check of game ECO, described as something with nasty protection. Maybe it looked so with flux analysis SW.
However, all protection check does almost exactly what is described above: tries to write in some sector, where it must be OK, and in another where it must fail. Testing of it is done with simple TOS floppy read/write calls. You can produce such seemingly damaged sectors even with Atari self - which will be reported as RNF or CRC error.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.


Social Media

     

Return to “Pasti & VAPI”

Who is online

Users browsing this forum: No registered users and 1 guest