SCP disk images !

Moderators: DrCoolZic, Moderator Team

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

Re: SCP disk images !

Postby ijor » Fri Dec 23, 2016 3:44 am

JimDrew wrote:The index pulse sensor is typically a hall sensor with 3.5" disks, and an optical with 5.25" disks. Even with 5.25" disks the optical sensor response time is in tens of nanoseconds and consistent, not microseconds and triggering randomly, so there should never be any type of problem getting the same data start position every time you read a revolution.


Ok, let's dump some tracks to see if practice matches your theory. For each rev, the first four and the last four samples, plus total # of transitions on that rev:

Code: Select all

Rev 0: 002E 0080 0080 007F  ... 0081 007E 0081 007F  - Transitions: 42292
Rev 1: 0080 007F 0080 0080  ... 0080 007F 0080 007F  - Transitions: 42293
Rev 2: 0081 007F 0080 0080  ... 007F 0080 0080 0080  - Transitions: 42294
Rev 3: 007F 0080 0080 0080  ... 007E 0080 0080 0080  - Transitions: 42293
Rev 4: 007F 0081 007F 0080  ... 0080 007F 0080 007F  - Transitions: 42292

Rev 0: 0011 0088 007D 0081  ... 007F 0081 007E 0088  - Transitions: 38454
Rev 1: 00F1 0087 007E 0081  ... 0081 007E 0088 00F1  - Transitions: 38455
Rev 2: 0088 007E 0080 0080  ... 007F 0081 007E 0088  - Transitions: 38453
Rev 3: 00F1 0088 007E 0080  ... 0080 007F 0087 00F2  - Transitions: 38455
Rev 4: 0087 007E 0081 007F  ... 007F 0081 007E 0088  - Transitions: 38453

Rev 0: 004A 009A 009E 00E7  ... 00E7 00ED 00E6 00EA  - Transitions: 43175
Rev 1: 009A 009F 00E7 00ED  ... 00E8 00ED 00E5 00EB  - Transitions: 43174
Rev 2: 009A 009F 00E7 00ED  ... 009D 00E7 00EE 00E5  - Transitions: 43173
Rev 3: 00EA 009A 009F 00E7  ... 009D 00E8 00EC 00E6  - Transitions: 43174
Rev 4: 00EB 0099 009F 00E7  ... 00E9 00ED 00E5 00EB  - Transitions: 43175

Rev 0: 0099 00EB 009A 009F  ... 009E 00E9 00ED 00E5  - Transitions: 42433
Rev 1: 00EB 0099 009F 00E7  ... 0099 009E 00E9 00ED  - Transitions: 42431
Rev 2: 00E5 00EA 009A 009F  ... 0099 009E 00E9 00ED  - Transitions: 42432
Rev 3: 00E6 00EA 0099 00A0  ... 009A 009E 00E9 00ED  - Transitions: 42432
Rev 4: 00E6 00EA 0099 009F  ... 009A 009E 00E9 00EC  - Transitions: 42432


The first transition shows that the jitter sometimes is quite considerable. The last transitions, if you check the range, you can see that sometimes they don't match across revolutions.

This was taken from a handful of images I processed recently. I am posting, obviously, only those tracks that the dump shows jitter. Some tracks were neat, without any apparent jitter, at least not with this simple hex dump. But I didn't have to dump many tracks to find those with jitter. And I didn't code any special analysis routines to search for jitter. Just dumped the first few tracks from a handful of images.

Now let's see track 0 for that image that was making trouble to NewRisingSun:

Code: Select all

Track: 0/0
Rev 0: 006D 00A3 00A7 00E4  ... 00E3 00F8 00EB 00F1  - Transitions: 45115
Rev 1: 00A0 00A4 00E8 00F5  ... 00A2 00A5 00E6 00F4  - Transitions: 45112
Rev 2: 00EC 00F2 009F 00A4  ... 00A1 00A2 00E6 00F9  - Transitions: 45112
Rev 3: 00EA 00EF 00A3 00A3  ... 00A3 00E8 00F6 00E9  - Transitions: 45115
Rev 4: 00F1 00A2 00A3 00E8  ... 00A5 00E3 00F6 00E8  - Transitions: 45114


The jitter is obvious, and it is expected that you might have troubles trying to build a circular buffer out of a single rev.

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

Re: SCP disk images !

Postby ijor » Fri Dec 23, 2016 3:57 am

NewRisingSun wrote:In the meantime, if you have the time, could you please take a look at the same FTP server, file "/SCP/IBM-PC/[SCP-IBM PC] JOE & MAC CAVEMAN NINJA (ELITE SYSTEM - EURO version) - IBM PC - (C) 1991 DATA EAST - ELITE SYSTEM LTD.7z"?


Checked the image. It seems to be recorded at HD, and unfortunately I don't have many tools for processing HD. But a rudimentary decode doesn't find syncs or marks. And there are lots of huge transitions. Only thing that comes to mind, may be an HD disk read on a DD drive? A shoot in the dark, but it might explain why so many transitions seem to being lost.

Edit: I just used HxC to convert my working Kryoflux image to SCP format, then used my SCP decoder to find that the Kryo->SCP converted image works nicely. My SCP decoder may be good after all, and I just may be wasting a lot of time on what might be a bad dump after all.


May be it's a bad disk, and/or a bad dump. But I think that there is some decoding issue there, which could be besides the dump being bad, if it is bad indeed.

I don't think that processing successfully an image converted with HxC proves that the other image is bad. Note that HxC doesn't perform a one to one conversion.

If you want to be sure, IMHO, you need to decode the SCP original image with some other method. Not trying to match a single revolution. That image has 5 revs per track. So you can concatenate 3 revs and easily make a circular buffer.

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

Re: SCP disk images !

Postby ijor » Fri Dec 23, 2016 7:16 pm

NewRisingSun wrote:It checks, among other things, that the data of sector 11 at the splice point is exactly as expected on cylinder 0, head 0.


Btw, I guess you noted that sector 11 on the other tracks has a size field of 0x2E, which doesn't seem to be documented. Just out of curiosity, do you know how this is interpreted by the PC FDC? I know exactly how the FDC on the Atari (by WD) will interpret that, but at this level they are not compatible with Nec or Intel FDCs.

Or more general, is there a detailed reverse engineering of the Nec/Intel FDC?

NewRisingSun
Retro freak
Retro freak
Posts: 12
Joined: Wed Dec 21, 2016 11:09 pm

Re: SCP disk images !

Postby NewRisingSun » Fri Dec 23, 2016 8:35 pm

Not that I know of. And I don't know how a size code of 0x2E would be interpreted, as these sectors are never read by the keydisk checking routine anyway. My guess is that they're just there to fool copiers. The keydisk checking routine only reads three sectors in the following order:
  • 0-0-10, containing a decryption key for the protected program as well as an offset at which the counting of bytes in the following sector starts;
  • 2-0-10, which contains some kind of configuration information. The subroutine parsing this data has a branch to code displaying the message "The use limit is reached", although this particular disk seems to have been configured without a use limit.
  • 0-0-11, the index-spanning sector whose number of identical bytes from said offset until the write splice that comes after the index serves as the initial register value for the decryption routine;
If you want, I can try to read those sectors on my Tandy 1000 TX (Intel 8272A) and my Asus P2B-LS (some Intel chipset) to see what happens. How does the WD controller react to that?

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

Re: SCP disk images !

Postby ijor » Fri Dec 23, 2016 8:53 pm

NewRisingSun wrote:0-0-10, containing a decryption key for the protected program as well as an offset at which the counting of bytes in the following sector starts...


Interesting. The SCP (troublesome) disk seems to have this sector overwritten, or at least seems written in a separate pass. While your copy doesn't.

I am guessing from what you say, that this sector is modified after the track is formatted and the write splice of sector 11 was already measured. But then, I would except that your copy shows also signs of the sector written afterwards.

Btw, I was aware that this kind of protection was used in the pc. It is quite unique because in a sense it is never copied, it is created slightly different each time a disk is recorded. You format the track, measure the write splice on the last sector, and only then you create the key. But I thought this was never used on mass duplicated software. And it does seem this game has this kind of protection.

If you want, I can try to read those sectors on my Tandy 1000 TX (Intel 8272A) and my Asus P2B-LS (some Intel chipset) to see what happens. How does the WD controller react to that?


Nah. I was just curious. Most WD variants simply ignore bits 2-7 of the sector field. Only allowed sizes are then 128-1024 taken from the two lowermost bits. Earlier WD variants has an alternate mode, not IBM/PC compatible, that takes any value.

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

Re: SCP disk images !

Postby Steven Seagal » Fri Dec 23, 2016 9:28 pm

ijor wrote:The jitter is obvious, and it is expected that you might have troubles trying to build a circular buffer out of a single rev.


I was interested in this as well when adding SCP support in Steem.
Here's a comment in the source code:

Turrican SCP will fail if we don't start on rev1 so that it reads
sector data of rev2 over IP (index pulse).
So we make it a generality (the way it is coded, normally it will
also do it with rev 3, 4... in the unlikely case that it's needed).
This is because IP is by nature imprecise, and it won't fall on the same
bitcell each time (unless you have mastering hardware, not mama's drive).
One rev from IP to IP, unless "doctored", may have one or two bits too
few or too many at the beginning or the end.
Doing rev1 -> rev2 ensures that we use the exact same timing for IP,
and no bit is lost or gained.
It will work with 1rev versions if the copy is 100% (not our
responsibility) or if data at IP isn't important (most cases).


Is this in agreement with what you're saying about jitter?
Are there superior mastering drives? Or did duplicators just move the write splice to have data over IP?

NewRisingSun
Retro freak
Retro freak
Posts: 12
Joined: Wed Dec 21, 2016 11:09 pm

Re: SCP disk images !

Postby NewRisingSun » Fri Dec 23, 2016 10:13 pm

So, I can run the troublesome SCP image if I decode from the end of rev0 over the index signal into rev1, then keep the original track length by rotating the buffer by the number of bits between the index signal and the first write splice. I detect the write splice by looking for three zero bits in a row before the first A1 sync mark. Not the way I would like to do it, but at least it gets the image working in DOSBox-TC without breaking anything else.

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

Re: SCP disk images !

Postby JimDrew » Sat Dec 24, 2016 1:39 am

The bitcell duration changes depending on when the index pulse is read due to drive speed, but the position in relation to the head should not be able to change. The disk is spinning, the head is reading the same position of where the hall sensor is detecting the index magnet. Unless you had a really poor hall sensor you should not lose the actual bitcell definition (01/001/0001). If I read a track over and over again, I see the same bitcell definition for the first bitcell (although it fluctuates in value a few hundred nanoseconds).

If you use the SCP analyzer, you can read the IBM PC HD track and even use the decoder to look at the MFM conversion. So you can see that 448944894489 (a SYNC) converted to what a FDC generates for a SYNC.
I am the flux ninja

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

Re: SCP disk images !

Postby ijor » Sat Dec 24, 2016 4:44 am

Steven Seagal wrote:Here's a comment in the source code:
...
Is this in agreement with what you're saying about jitter?


Not sure I understand what exactly you meant in the source. But yes, I think we are talking about the same type of jitter.

Are there superior mastering drives? Or did duplicators just move the write splice to have data over IP?


Duplicators use custom drives, but the write splice location can be managed by the controller. A standard FDC will locate the write splice at the index pulse. But a custom controller can easily place the write splice anywhere you want.

NewRisingSun wrote:So, I can run the troublesome SCP image if I decode from the end of rev0 over the index signal into rev1, then keep the original track length by rotating the buffer by the number of bits between the index signal and the first write splice.


I think you should try that. I can't say, of course, if the image doesn't have some other problem. But the decoding under the index shouldn't be an issue as long as you decode that way.

I detect the write splice by looking for three zero bits in a row before the first A1 sync mark. Not the way I would like to do it, but at least it gets the image working in DOSBox-TC without breaking anything else.


Detecting the write splice might sometimes be tricky. You can do that at the flux level, or at the decoded level, or even combining both. But for emulation purposes the write splice normally doesn't matter. You just report exactly what is present at the image. The write splice location is more important for writing back purposes.

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

Re: SCP disk images !

Postby ijor » Sat Dec 24, 2016 5:01 am

JimDrew wrote:The bitcell duration changes depending on when the index pulse is read due to drive speed, but the position in relation to the head should not be able to change. The disk is spinning, the head is reading the same position of where the hall sensor is detecting the index magnet. Unless you had a really poor hall sensor you should not lose the actual bitcell definition (01/001/0001).


Well, again, see the dumps I posted. The bitcell definition (in relation to the index) is definitely changing across revolutions in those tracks I dumped:

Code: Select all

Track: 0/0
Rev 0: 006D 00A3 00A7 00E4  ... 00E3 00F8 00EB 00F1  - Transitions: 45115
Rev 1: 00A0 00A4 00E8 00F5  ... 00A2 00A5 00E6 00F4  - Transitions: 45112
Rev 2: 00EC 00F2 009F 00A4  ... 00A1 00A2 00E6 00F9  - Transitions: 45112
Rev 3: 00EA 00EF 00A3 00A3  ... 00A3 00E8 00F6 00E9  - Transitions: 45115
Rev 4: 00F1 00A2 00A3 00E8  ... 00A5 00E3 00F6 00E8  - Transitions: 45114


See the above track as an example. The second transition is a small one (one MFM data bit) on revs 0,1 and 4; but it's a mid size transition (one and a half MFM data bit) on the other revs. See also similar changes in the transisions at the end of the rev. It is more than obvious in this case that the jitter does change the bitcell relation to the index pulse.

Obviously it doesn't happen in every single track, and it depends a lot on the specific drive. Some drives have much more jitter than others. But even for those drives that have a very small jitter (and all have some), it still might happen, it just makes it less likely. It is common sense. Because all it takes is a flux transition to be too close to the index pulse for the smallest of the jitter to be relevant and significant enough to move the transition to the other side of the index.

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

Re: SCP disk images !

Postby JimDrew » Sun Dec 25, 2016 5:21 am

I don't see it with any drives I have tested. You can use the editor/analyzer to re-read a track over and over. It really doesn't make sense for the position to change. The rotational location of the head and index pulse should be physically the same unless the center hub was slipping.
I am the flux ninja

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

Re: SCP disk images !

Postby ijor » Sun Dec 25, 2016 5:47 pm

JimDrew wrote:It really doesn't make sense for the position to change. The rotational location of the head and index pulse should be physically the same unless the center hub was slipping.


It makes all the sense to me. Of course that the position doesn't change. But the sensors are not that precise. They have jitter by definition because nothing on earth (short to quantums?) doesn't have it. Even pure electronics have jitter, that's one of the reasons we use synchronous designs. Let alone here that some mechanics are involved. And on 5.25 disks it is usually worse, because at least in some drives, probably the outer sleeve gets involved. Conceivable, even some fluff might affect the exact timing here.

But regardless of the theory, after all I didn't perform any lab scientific analysis (neither heard somebody ever did on this), it is clear that some tracks show some jitter for whatever reason.

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

Re: SCP disk images !

Postby ijor » Sun Dec 25, 2016 5:58 pm

JimDrew wrote:By the way, if you dump from index to index, you are never going to be missing any data. That will spool 100% of the bitcells contained within a single revolution. The very first bitcell time and the very last bitcell time needs to be added together and replaces either the first or last bitcell time. The first and last times will be split by the index mark.


Btw, without much relation to the index pulse jitter, I tried to understand what you are saying here. And I'm not sure I can't make much sense with that and the actual samples on most (all) SCP images.

If you are saying that the first and the last samples should be added and joined, one would understand that the first transition sample is measured from the first index pulse, and that the last sample is measured up to the second index pulse. That is, that both samples aren't really a complete a complete flux transition, they are the same one that was split.

But looking at the actual samples, I can see that indeed, the first sample is short. It is obviously measured from the first index pulse, not from the previous transition. But the last sample seems to be always complete. Never seems to be short as if was measured up to the second index pulse only. So adding both would most of the time give a wrong value.

Furthermore, if I add all the samples in the first rev, and then compare this total with the duration as specified on the track header, sometimes one is bigger, and sometimes the other ???

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

Re: SCP disk images !

Postby Steven Seagal » Mon Dec 26, 2016 10:13 am

When reading a track, the result until the first sync is random. Some games depend on this behaviour.
eg War Heli track 68
Doesn't it indicate that bits around IP are variable from rev to rev, if not reading continuously (and so ignoring IP)?

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

Re: SCP disk images !

Postby ijor » Mon Dec 26, 2016 1:16 pm

Steven Seagal wrote:When reading a track, the result until the first sync is random. Some games depend on this behaviour.
eg War Heli track 68. Doesn't it indicate that bits around IP are variable from rev to rev, if not reading continuously (and so ignoring IP)?


It is related, but not exactly the same thing.

The IP jitter in relation to flux transitions will of course be relevant, but it is not the only cause for this seudo random behavior as seen by the FDC. It is also a consequence of the FDC clock being asynchronous to the drive signal. And the FDC won't sync completely with the drive signal until receiving the first sync. That's precisely why it is called a sync mark after all.

In other words, even if the IP signal would have zero jitter, you would still get seudo random bytes until the first sync when reading a track. However, the variation would be smaller, probably just one cellbit (half data bit). With the contribution of the IP jitter, you might get a shifting of a couple of full bits.

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

Re: SCP disk images !

Postby JimDrew » Mon Dec 26, 2016 6:07 pm

The write splice(s) cause the track length to change on every revolution, unless there is some absolute luck and there is only a single write splice and that write splice ends up being exactly within the window of a bitcell (4us/6us/8us). Anything out of the upper/lower bounds will cause the drive to output an invalid bitcell time (too short or too long). Depending on exactly when the FDC starts its decoding, the data will be off by 1 or more bits, and this gives you an apparent "randomness" to the data stream. This "jitter" is expected. Jitter from an index pulse sensor is expected, but it's only measured in tens of nanoseconds. I use standard off the shelf hall sensors in critical flight control system applications for measuring positions with incredible accuracy. I am sure every type of drive is different for accuracy, but I have not seen any accuracy issues that are remotely close to a bitcell duration.

The difference in time between the actual bit cells read (added together) and physically duration is due to drive speed warble. You can determine just how good a drive is at keeping it's rotational speed by comparing these values.
I am the flux ninja

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

Re: SCP disk images !

Postby ijor » Tue Dec 27, 2016 4:19 am

JimDrew wrote:The write splice(s) cause the track length to change on every revolution ... Depending on exactly when the FDC starts its decoding, the data will be off by 1 or more bits, and this gives you an apparent "randomness" to the data stream.


In first place, sometimes the write splice just doesn't provoke any weak bits effects. I don't think that is very unusual. You can see that when you read a track with multiple write splices. Many of them read always exactly the same.

Write splice might produce the random bytes Steve mentions, but only in some cases. If the write splice is before the index (which is very common), then the start of the read track won't be affected. If it is after the index, then it might affect the bytes between the write splice and the first sync. The bytes before the write splice won't be affected. And of course that for those tracks not aligned at all with the index, with the write splice not close to the index, then it won't affect this "randomness" in any way whatsoever.

However you always see some seudo random bytes at the start of the read track. If we assume no significant IP jitter, then the only thing that might produce this is what I mentioned in the previous post. The PLL is already locked, and the FDC starts decoding synchronously to the IP edge. The only possible variation could be transposing the clock and the data pattern, because this is not synced by the PLL, only by the mark detector. Then, you should only see two patterns, one reading the clock, the other reading the data. But on most tracks you see several patterns, not just two, indicating that besides the clock/data transposition, decoding was shifted by at least one full data bit. This can only be produced by jitter of the IP.

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

Re: SCP disk images !

Postby ijor » Tue Dec 27, 2016 4:34 am

Intentionally addressed this in a separate message ...

JimDrew wrote:The difference in time between the actual bit cells read (added together) and physically duration is due to drive speed warble. You can determine just how good a drive is at keeping it's rotational speed by comparing these values.


I don't see the relation. We are talking about the very same revolution. Variations in the drive speed might affect the difference between them. Yes, of course. But warble can never change which one is bigger. If the last bit cell stored is before the IP, then physical duration should always be bigger. Sometimes slightly more bigger than others, but always bigger. And if the last bit cell stored is after the IP, then it is the other way around, physical duration should always be smaller.

But what I see, is that sometimes adding all the bit cells produces a higher value than the physical duration (on the same track, of course). And on other tracks it is the other way around, the physical duration has the higher value. Don't understand why this happens in the SCP images. Can you explain that?

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

Re: SCP disk images !

Postby JimDrew » Wed Dec 28, 2016 7:10 pm

Can you provide a flux image where you see this? I don't ever see this.
I am the flux ninja

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

Re: SCP disk images !

Postby ijor » Sun Jan 01, 2017 3:40 pm

Hi Jim,

JimDrew wrote:Can you provide a flux image where you see this? I don't ever see this.


Well, I see it in almost every image I check, unless I am doing something wrong? Two cases I have at hand right now are, Turrican II (Atari ST) and Boulder Dash (for PC). Both from the retrobackup server.

Boulder Dash:
Track: 0. Rev: 0. Total samples: 7999296. Track duration: 7999327. Diff: +31
Track: 3. Rev: 0. Total samples: 8004710. Track duration: 8004704. Diff: -6

Turrican II:
Track: 0. Rev: 0. Total samples: 7999098. Track duration: 7999238. Diff: +140
Track: 4. Rev: 0. Total samples: 7991387. Track duration: 7991376. Diff: -11

User avatar
flyers80
Atarian
Atarian
Posts: 6
Joined: Wed Nov 30, 2016 7:37 pm

Re: SCP disk images !

Postby flyers80 » Tue Jan 03, 2017 8:02 am

coolhaken wrote:
flyers80 wrote:Hi
Uploaded to "Incoming SCP" Xenon 2 and other games for IBM PC


Hi,

I am the guy left message in the ftp for you.
Boulder Dash's copy protection has a sector across the index signal. This means that the SCP file must be dumped in "non-blind" mode.
Look at the SCP manual, page 25, in particular the "Copy Mode" options. You are supposed to use the "Splice" copy mode.
Please change "Copy Mode" to "indexsplice" and redump Boulder Dash and Paperboy again.
Thank you very much.


hi
Are already dumped in splice mode (5 revs.)
I also loaded the games required in index mode.
P.S. sorry for delay

coolhaken
Atariator
Atariator
Posts: 18
Joined: Mon Dec 19, 2016 11:50 pm

Re: SCP disk images !

Postby coolhaken » Tue Jan 03, 2017 11:14 am

The new dump of BoulderDash was decoded ok and works fine.
This is the PCE emulator (for windows) with this game (convert to PSI format), you can try it.
https://mega.nz/#!6pRQlAAa!UA82qO_AzI1k ... y3Pw_gybJU
Password is your ID ;)

The game Paperboy doesn't work because it's protection tracks are missing in both dumps.
So this game will not work even on a real machine.

User avatar
flyers80
Atarian
Atarian
Posts: 6
Joined: Wed Nov 30, 2016 7:37 pm

Re: SCP disk images !

Postby flyers80 » Tue Jan 03, 2017 5:01 pm

coolhaken wrote:The new dump of BoulderDash was decoded ok and works fine.
This is the PCE emulator (for windows) with this game (convert to PSI format), you can try it.
https://mega.nz/#!6pRQlAAa!UA82qO_AzI1k ... y3Pw_gybJU
Password is your ID ;)

The game Paperboy doesn't work because it's protection tracks are missing in both dumps.
So this game will not work even on a real machine.


hi
2 questions out of curiosity:
How do I convert the images in PSI format?
Is there a way to use disk images protected with dos emulators?

I own another paperboy disk, I uploaded all, if you want to do other tests (SCP Incoming / Paperboy Test Msdos)

coolhaken
Atariator
Atariator
Posts: 18
Joined: Mon Dec 19, 2016 11:50 pm

Re: SCP disk images !

Postby coolhaken » Wed Jan 04, 2017 1:50 pm

flyers80 wrote:How do I convert the images in PSI format?
Is there a way to use disk images protected with dos emulators?


You can use the PCE tools (pfi.exe, pri.exe, psi.exe) to convert your SCP dumps to PSI image :
http://www.hampa.ch/pub/pce/pre/pce-201 ... -win32.zip

Then use the PCE emulator to run your game without crack :
http://www.hampa.ch/pub/pce/pre/pce-201 ... -win32.zip

PCE's homepage : http://www.hampa.ch/pce/

BoulderDash as example :

1st step, run pfi "Boulder Dash (MSDOS)(Index Mode).scp" -p analyse
You can see all tracks up to 39 are detected as MFM at (about) 500KHz.

Then,

Code: Select all

pfi "Boulder Dash (MSDOS)(Index Mode).scp" -r 500000 -p decode pri DISK.PRI
pri DISK.PRI -p decode mfm DISK.PSI
psi DISK.PSI -e position -1 -p comment-set "" BD.PSI

BD.PSI is what we need.

Please also refer to this thread : https://winworldpc.com/winboards/viewto ... f=1&t=7877

flyers80 wrote:I own another paperboy disk, I uploaded all, if you want to do other tests (SCP Incoming / Paperboy Test Msdos)


Thank you. I'll try them later.

coolhaken
Atariator
Atariator
Posts: 18
Joined: Mon Dec 19, 2016 11:50 pm

Re: SCP disk images !

Postby coolhaken » Wed Jan 04, 2017 3:57 pm

The alternate dump of Paperbpy works fine, no matter you dump it in index mode or splice mode and how many revolutions you set.
Every dump of the other one doesn't contain the protection tracks, so doesn't work.
This is the PCE emulator with the working image :
https://mega.nz/#!apxS0LRK!sCwB4LOPGT08 ... t-i1xTl1lw
Password is still your ID ;)


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 2 guests