List of difficult to copy disks

Moderators: DrCoolZic, Moderator Team

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

Re: List of difficult to copy disks

Postby DrCoolZic » Fri Mar 21, 2014 8:18 am

IFW wrote:Correct, but remember the emulator only does read - so short of decapping the chip what is there is as far as is possible to know for reading :)
For writing obviously a different logic is needed with the blind setting of CDB4, as you say.

I know this is a shame that we do not have the capability to write FD in the emulator when using protected format (this apply to IPF as well as STX) :(

I am experimenting with WD1772 write commands, but the main reason I tested writing invalid sequences of syncs was to be able to read them :)
... and while doing that I felt it would be interesting to documents the way it works even if that is of interest to very limited number of people (the same apply to IAM)

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Fri Mar 21, 2014 3:09 pm

It is possible to write these formats, but only how it is done in WinUAE. In fact that applies to any other format as well that is not as simple as a sector dump - way too much work for very little gain.
It's doable, but everyone saves it for an extremely rainy day for the time when there is nothing else cool to do remains ;)

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

Re: List of difficult to copy disks

Postby AtariZoll » Fri Mar 21, 2014 3:26 pm

Writing what is used in games is usually with normal sectors. So, in most of cases it should be not something problematic. And that's normal, because writing on protected tracks is not really possible with ST.
So, basically you need to support format - but it it not always a must. And writing sector contents. Why no write support for STX in Pasti ? I think that author was on reasoning that originals should not be written ever, and that's OK in fact. But there are some stupid cases when orig. most be not write protected.
It should be not so hard to add support for writing standard sectors in case of STX and IPF, I guess. If can to write in ST format ...
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.

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1479
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: List of difficult to copy disks

Postby dlfrsilver » Fri Mar 21, 2014 3:34 pm

AtariZoll wrote:Writing what is used in games is usually with normal sectors. So, in most of cases it should be not something problematic. And that's normal, because writing on protected tracks is not really possible with ST.
So, basically you need to support format - but it it not always a must. And writing sector contents. Why no write support for STX in Pasti ? I think that author was on reasoning that originals should not be written ever, and that's OK in fact. But there are some stupid cases when orig. most be not write protected.
It should be not so hard to add support for writing standard sectors in case of STX and IPF, I guess. If can to write in ST format ...


winuae is doing an ADF save aside the original. That's how it works for amiga IPF. Why not making Steem doing *.st files aside the STX originals like winuae ? This way the STX has not to be deprotected to write on it :)
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Fri Mar 21, 2014 3:59 pm

Yes, that's the idea.
Any track marked as "dirty" in the ADF (EXT) file is used from there, otherwise the emulator switches to the image file containing the original data.
Maybe for ST you want a "dirty sector" map instead as you can write at sector level, not just an entire track at once like on Amiga.

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

Re: List of difficult to copy disks

Postby AtariZoll » Fri Mar 21, 2014 5:05 pm

Yes, one possible solution is to perform writes on some kind of 'shadow' ST image (shadow of STX image) . But writing directly into STX image is possible too, without need to update track dumps, which are not used in highscore & position saves/loads.
And we are at big but now, as Pasti is not open source. Hmmm - I see here chance for Hatari :D
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.

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1479
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: List of difficult to copy disks

Postby dlfrsilver » Fri Mar 21, 2014 5:08 pm

AtariZoll wrote:Yes, one possible solution is to perform writes on some kind of 'shadow' ST image (shadow of STX image) . But writing directly into STX image is possible too, without need to update track dumps, which are not used in highscore & position saves/loads.
And we are at big but now, as Pasti is not open source. Hmmm - I see here chance for Hatari :D


not open source, but ijor has not told us to stop :)
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

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

Re: List of difficult to copy disks

Postby DrCoolZic » Fri Mar 21, 2014 8:08 pm

AtariZoll wrote:Yes, one possible solution is to perform writes on some kind of 'shadow' ST image (shadow of STX image) . But writing directly into STX image is possible too, without need to update track dumps, which are not used in highscore & position saves/loads.
And we are at big but now, as Pasti is not open source. Hmmm - I see here chance for Hatari :D

Updating Pasti file should not be a problem even if using protected track.
Specially as you mention most protected track are not writable on a real Atari so it makes things even easier :)

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

Re: List of difficult to copy disks

Postby DrCoolZic » Fri Mar 21, 2014 8:10 pm

dlfrsilver wrote:
AtariZoll wrote:Yes, one possible solution is to perform writes on some kind of 'shadow' ST image (shadow of STX image) . But writing directly into STX image is possible too, without need to update track dumps, which are not used in highscore & position saves/loads.
And we are at big but now, as Pasti is not open source. Hmmm - I see here chance for Hatari :D


not open source, but ijor has not told us to stop :)

Yes it even provided me some information to help in describing stx format. But I have not heard from him for a long time.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: List of difficult to copy disks

Postby Steven Seagal » Fri Mar 21, 2014 9:05 pm

AtariZoll wrote:It should be not so hard to add support for writing standard sectors in case of STX and IPF, I guess. If can to write in ST format ...


No, not so hard if we limit ourselves to sector R/W, but still a big feature.
It must be worth it, with decent amount of games it would help (highscores?) in both STX and IPF formats.
In pasti writes are supported and memorised for the session I think (Sundog).
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Sat Mar 22, 2014 8:20 am

Yes, highscores are common, but sometimes even internal state gets saved to the disk while playing to e.g. keep the results from character selection, instead of just using memory for that - probably to exchange data between program modules written by different people or teams.. One example of this is Times of Lore.

EDIT:
Maybe just move all posts related to saving onto non-sector based disk images (STX, IPF etc) into a brand new topic? It has nothing to do with copying and will probably be a long ongoing discussion while it gets implemented in the various ST emulators.
Can a mod do that please?

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

Re: List of difficult to copy disks

Postby AtariZoll » Sat Mar 22, 2014 8:47 am

Yes. pasti does some fake writes, which are internal, and not go into STX image. But who will make updates without sources of Pasti.dll ? Ijor did not say that stop, but what we need from him is little push :D
Updating Pasti not only with writes, but fixing couple recently discovered bugs - in first place bug in track read (start data shifting) - Jupiter Msterdrive case .
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.

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

Re: List of difficult to copy disks

Postby Jeff_HxC2001 » Sat Mar 22, 2014 12:08 pm

AtariZoll wrote:... But writing directly into STX image is possible too, without need to update track dumps, which are not used in highscore & position saves/loads. ...


:? this sound like a bad idea...

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

Re: List of difficult to copy disks

Postby AtariZoll » Sat Mar 22, 2014 1:44 pm

Jeff_HxC2001 wrote:..
:? this sound like a bad idea...


Yes, it sounds as bad idea. But: user will not work (play) with archive file, but with copy. There will be different data in sectors and track - but that's not problem, because track dump is not used at all in such cases. Remember: track dumps are there in 98% cases just 'for case'. It is possible even to remove them (when SW does not track read of), without making STX file non-working.
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.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: List of difficult to copy disks

Postby Dio » Mon Mar 24, 2014 1:40 pm

The solution for both cases (STX, IPF etc.) is to have an overlay addendum carried in an adjacent file for sector writing.

So you'd have blah.ipf and blah.ovl and the original file wouldn't be modified; the emulator detects sector writes and puts those into the overlay, and checks the overlay when a sector read is issued and preferentially performs it from the overlay file.

This would also not affect the track image, but I doubt this is ever an issue. Timing might possibly be in some edge cases, but it is a very rare game that involved writes in protection.

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

Re: List of difficult to copy disks

Postby DrCoolZic » Mon Mar 24, 2014 3:39 pm

Dio wrote:The solution for both cases (STX, IPF etc.) is to have an overlay addendum carried in an adjacent file for sector writing.

So you'd have blah.ipf and blah.ovl and the original file wouldn't be modified; the emulator detects sector writes and puts those into the overlay, and checks the overlay when a sector read is issued and preferentially performs it from the overlay file.

This would also not affect the track image, but I doubt this is ever an issue. Timing might possibly be in some edge cases, but it is a very rare game that involved writes in protection.

This is obviously the best solution but the most difficult to implement :)

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

Re: List of difficult to copy disks

Postby AtariZoll » Mon Mar 24, 2014 4:16 pm

Dio wrote:The solution for both cases (STX, IPF etc.) is to have an overlay addendum carried in an adjacent file for sector writing.
So you'd have blah.ipf and blah.ovl and the original file wouldn't be modified; the emulator detects sector writes and puts those into the overlay, and checks the overlay when a sector read is issued and preferentially performs it from the overlay file.
This would also not affect the track image, but I doubt this is ever an issue. Timing might possibly be in some edge cases, but it is a very rare game that involved writes in protection.

This is what I proposed already - only that I called it "shadow image" :D
But I think that writing into STX file is better . Don"t know about IPF sector storage, but should be somewhere as 512 bytes block. Only real diff. would be that must calc. track data CRC in case of IPF .
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: 828
Joined: Mon Nov 04, 2013 5:23 pm

Re: List of difficult to copy disks

Postby JimDrew » Mon Mar 24, 2014 4:40 pm

Can you guys start a new thread about this since it pertains to STX files, and not the topic. Thanks!
I am the flux ninja

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

Re: List of difficult to copy disks

Postby AtariZoll » Mon Mar 24, 2014 4:48 pm

Some moderator should move all posts to new thread named something like: Write support for STX images ..
It started on page 18 of this thread .
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.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: List of difficult to copy disks

Postby Steven Seagal » Wed Apr 02, 2014 9:04 pm

JimDrew wrote:OK, I found the problem! I was able to make it pass the protection check within Steem once I figured out the issue.

The problem is in the code before checking the protection. The problem has to do with whatever actually puts the data in the buffer. The STX file has the right data, but for some reason that exact data is not getting copied to the buffer for tracks 2 and 4. I believe there is a shifting issue with the data due to the WD1772 emulation. Look at the capture below:

boiler.jpg


You will notice the track buffer has the wrong first 4 bytes. Those bytes should be 9210 90C2, which is in the STX file. If you replace those 4 bytes with 9210 90C2 for track 4 it passes the protection check. Track 3's info is correct. Track 2 also needs these poked in. Once you do that, the protection check passes and the game loads.

I still really want to test loading a real disk in a real machine with just the read track command and see what the ST returns. I believe there is an issue with the WD1772 emulation for consecutive 000's. If you look at the data and manually shift the bits (leaving bits cleared) it works out exactly as what the protection is looking for with the C2 00 and C2 0B. Maybe that is a fluke, but I don't think so.


Image

This isn't the pasti section but this post accurately describes the problem: image data is correct yet pasti.dll thinks it must randomize the pre sector bytes.
Some of you may remember that long before Steem source was released, long before Steem "SSE", I offered a "no-nag" version of Pasti.dll.
Well, using the same hacker tools (IDA, OllyDbg...), I think I have patched pasti.dll for this problem as well! At least Jupiter's Masterdrive STX now loads. I'll include this new pasti.dll in next beta, maybe the patch breaks something else so some testing is needed.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: List of difficult to copy disks

Postby JimDrew » Thu Apr 03, 2014 2:06 am

Nice job!
I am the flux ninja

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

Re: List of difficult to copy disks

Postby DrCoolZic » Thu Apr 03, 2014 7:28 am

I remember that someone mentioned that there was an option somewhere in Pasti to disable the read track randomization?

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

Re: List of difficult to copy disks

Postby DrCoolZic » Thu Apr 03, 2014 8:35 am

Disable randomization is in Pasti configuration -> options.
But unfortunately it does not seems to work for Jupiter's Masterdrive. Therefore I don't know what it disables?
I have tested with dll 0.2h and 0.2i but none works

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

Re: List of difficult to copy disks

Postby DrCoolZic » Thu Apr 03, 2014 9:17 am

OK just to be sure. I have checked disable randomization and I have used Panzer to read tracks 04
and it still randomize bytes before sync F2 72 72 72 .... and 09 09 09 09 at start of track
So this option might be for fuzzy bits?

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

Re: List of difficult to copy disks

Postby DrCoolZic » Thu Apr 03, 2014 9:31 am

I have also found a strange behavior of Pasti DLL.
In the STX file the length of the track is 6303 bytes and when reading the file under Steem with Panzer the track length is only reported as 6288 bytes ?

So it seems that Pasti DLL does not use the track lenght as the length of the track read command???

I am also curious to learn that the STX file works with Hatari because from what I remember this protection tests that the track is less than 6300 bytes???


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 2 guests