SCP disk images !

[flyers80]

Thanks for the information
I did not think there were emulators PC / dos with support of protected disk images.
Now I'll try to do testing.

Every dump of the other one doesn't contain the protection tracks, so doesn't work.

It's a shame because it was a rare version with high-resolution EGA support instead of the Tandy mode
you can bypass the protection system with a crack?

[coolhaken]

It's a shame because it was a rare version with high-resolution EGA support instead of the Tandy mode
you can bypass the protection system with a crack?

Sorry, I can't crack it.

[flyers80]

hi all
Uploaded to "Incoming SCP/Amiga by flyers80" another 16 Amiga games

[ijor]

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.

I finally had a chance to perform some authoritative measurements. I hooked a Logic Analyzer to a floppy drive and captured the index and read signals while reading the track. It was taken at the floppy cable. There is no FDC, controller, FPGA, CPU or whatever involved. This is what the drive outputs. I recorded a special track handcrafted to avoid any write splice issues and to make easy to identify the flux transitions.

These are the captures on two consecutive revolutions:

FlpyIndexJitter-1.jpg

FlpyIndexJitter-2.jpg

As you can see, the distance between the index edge and the short flux transition differ in more than 5 microseconds between both revolutions. And the captures clearly show that in one case the first transition after the index is the short one, in the other is a long one.

This is from a high quality (TEAC) 5.25" drive. If I can I'll measure with a 3.25" drive, that I expect to have a smaller index jitter.

[JimDrew]

Look at the end of the track (to the next index pulse). You will likely see that the track is just shifted forwards/backwards in reference to the index mark. The bitcell times are still all the same (when taking account for drive speed). Some drives apparently do this, and definitely the ones I have tested don't. This a hall sensor that triggers on a magnet passing. It's not like an optical sensor where the index hole can be slightly off depending on how the disk centers.

[ijor]

This a hall sensor that triggers on a magnet passing. It's not like an optical sensor where the index hole can be slightly off depending on how the disk centers.

It is an optical sensor. As I noted, it's a 5.25' drive, not a 3.5" one.

[JimDrew]

Ah... ok, that makes sense then. Yeah, the disk itself can actually "wobble" on the hub as it rotates.

[ijor]

Well, now I measured with a 3.5" drive. Hall sensor or not, the jitter is not much better than the 5.25" drive I measured before. Index edge jitter is still in the order of microseconds. This is not a track shift, I captured multiple consecutive revolutions, and the index pulse relation to the flux transitions changes (slightly) across revolutions.

I used a different logic analyzer that can capture in segmented mode. The beginning of each revolution, just around the active (falling) edge of the index is captured:

Segmented-Annotated.png

The image shows two segments, numbered 6 and 7. They correspond to two consecutive revolutions. Each segment starts just before the index edge. The top waveform signal is the flux transitions on the Read signal. The bottom one is the Index signal. The green dotted bars (one on each revolution) mark a couple of shorter transitions that I recorded to measure the position. If there wouldn't be any Index jitter at all, the distance from the index edge to the bar should be always the same.

Count the transitions between the falling edge of the index and the green dotted bar. The first revolution has three transitions. The second one has four. The fourth transitions before the green bar is marked with a blue oval. In the first revolution is before the index edge, but in the second one is after the edge. This simply means that this particular transitions is omitted if the first revolution is captured edge to edge.

Conclusion:

As I was saying, capturing a single revolution might not get the complete track, one (or more) transitions might be missing. If the track has, so called, data under the index, then simply some data might be missing.

Obviously this doesn't happen always. Not every track has data under the index. In some platforms is very common (typically 8-bit ones), in others not so much. And even then, the jitter is not always that bad that a transition is missed in a revolution as shown in the posted image.

[JimDrew]

It's always been the case that if there is data under the index pulse that you have to capture 2 revolutions.

What 3.5" drive did you test? I don't see this with Samsung 321 and a few others that I have tested.

[ijor]

What 3.5" drive did you test? I don't see this with Samsung 321 and a few others that I have tested.

TEAC combo (3.5 and 5.25). Can't check the exact model number right now. Note that they are really two piggybacked independent drives. But fitting in a single internal bay, the combo is very convenient. Tested the 3.5 drive only on the combo. The previous capture was on a different 5.25, DD (not HD) drive.

[Stefan jL]

I added an SCP image of Zone Warrior at Atarimania... please check it out It claims to have no on-disk copy protection (only password from manual protection).
http://www.atarimania.com/game-atari-st ... 10936.html

[Stefan jL]

That Zone Warrior dump has been confirmed good.
Here are some more SCP dumps, i made som quick testing in Steem with all of them and they worked.
milestones_softgold.7z - This is the Milestone compilation that contains: Spherical (version 2), Hard'n Heavy, Circus Attractions and Grand Monster Slam.

[Maartau]

Thanks a lot

[Stefan jL]

The Data East release of Robocop... sorry i only have the disks.
Seems to work fine in Steem SSE.

http://arcade.ym2149.com/files/scpro/wo ... atarist.7z

[Stefan jL]

And here is Targhan, the disks are marked "march" and i don't know if there was any later Targhan releases that was not budget or part of compilations?
Disk 2 has my savegame... sorry
The SCP's did not work in Steem SSE but i wrote back to ST disks and played on my ST and they worked fine there.

http://arcade.ym2149.com/files/scpro/wo ... atarist.7z

[Maartau]

Thanks a lot

Thanks a lot again [smilie=greencolorz4_pdt_01.gif]

[ijor]

Somebody knows if the ftp server at retrobackup is working? I do can connect but seems that the old known password doesn't work anymore.

Somebody made some kind of mirror?

[DrCoolZic]

Yes login impossible --- JIM help
Tried with username "retrodata" as well as "mybackups" both failed
Less important the server certificate is unknown.

[kodak80]

I think I have most if not all of the Atari dumps from the ftp site on a USB drive. Happy to upload these somewhere if the retrobackup.com ftp site is unavailable.

[DrCoolZic]

I also have downloaded many of the dumps from the ftp retrobackup ...
Plus I have collected images from several people ...
Plus I have made many images from my floppies ...

Therefore I am thinking of restarting the repository I did sometimes ago on Mega. We have 50 Gb for free
Information is there http://atari-forum.com/viewtopic.php?f=104&t=28228
I need a bit of time to cleanup the repository and load what I have there and after that anyone can add more to it ...

[DrCoolZic]

I just read this thread and I would like to comment some information that have been discussed.

I already talked to Jim several time about the sampling of the first flux transition and the positioning of the index in regard with the current bit. As you probably know KryoFlux start sampling BEFORE the first index and stop sampling after the last index. This is the only way to get the correct value for the first flux. On top of that KF also provide the information about the position of the index inside the current flux. This allow to know exactly for the very first cell the “pre-index” time, the “post-index time”, as well as the correct length of the bit.

On the contrary SCP does not provide any information about the position of the index in regard to the current cell and it also provide a truncated value for the first cell. What is happening is that for the first flux the length is computed from the index and not from the beginning of the cell. At the end of the track the last cell is correctly pushed to the next revolution and here you get the correct length for the first cell of the next revolution.

With this information, and assuming there is not too much jitter, between two revolutions you can compute the approximate length of the first cell of the first revolution, and the approximate position of the index in respect to the first cell: You must add the length of all the cell in the first revolution and you subtract this value from the index to index time, the result is the pre-index time (as the pre index is pushed to the next revolution) …

In most case the fact that the first value is incorrect and not knowing the position of the index is not so much important, but in case of a Non Flux Area positioned over the index it is pretty bad as explained here http://atari-forum.com/viewtopic.php?f=104&t=27364

Another problem (mentioned by Ijor) is that in “real life” the PLL is locked to the cells long before the index. Again with KF it is possible to lock the PLL emulation before the beginning of the track and unfortunately there is no way to do this with SCP.

[ijor]

I agree that we should try to setup our own image repository. But probably 50Gb is not enough. May be somebody can provide more space?

[DrCoolZic]

Mega seems to be a reasonable solution. Currently with help of Kodak80 I have uploaded 200 titles. Many games have several disks, some titles are available from different sources, some are imaged both with KF and SCP. So my guess is that this represent probably around 500 to 1000 disk images. The size used is currently 9.5 Gb

If we reach the 50 GB limit this should not be a problem, because we can create as many 50 Gb repositories as we need

[DrCoolZic]

Just wondering if I have a specific problem with my SCP hardware (got one of the first units) or if everybody getting the same error.

Very (very) often when I try to image a floppy I am getting “Read Length > RAM capacity” error and there is no other option than to cancel the imaging process. Sometimes cleaning the FD/drive seems to help but in most cases the only solution is to lower the track end to 79 (instead of 82) and/or to lower the number of revolutions to 4 and even sometimes to 3 (normally I am in splice mode with 5 revolutions).

This is very painful as I have to retry several times and I end up with an images that have less information (revolutions and track numbers) than expected.

I talked about this problem to Jim long ago but there is apparently no solution to it.

I have noticed that some of you (e.g. kodak80) generates scp images that are over 70 MB where I have never been able to generate files above 63-65 MB and therefore I am wondering if my SCP HW is broken.

Can you let me know if you experience the same problem or if this is specific to me ?

[Brume]

@DrCoolZic:
I just encountered this problem (Read Lenght > RAM capacity) with a few games. It mainly concerns Lankhor's games such as Vroom or Maupiti Island, and a few other titles I don't remember.
Otherwise 99% of the dumps i made with SCP (more than 2000 games now) have been done with 5 revolutions splice option and never got the RAM capacity issue.