SCP disk images !

[DrCoolZic]

Thanks for the information. So it looks like I may have a problem.
By the way it would be great if you could upload the images to the repository on Mega http://atari-forum.com/viewtopic.php?f= ... 45#p345545

We already have about 400 titles but it looks like you have much much more!
If you want I can give you access on the Mega repository like I did to kodak80

[kodak80]

@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.

I have come across this issue. Only option I found was to reduce revolutions until the error stopped. 4 revs normally solves for me.

[JimDrew]

In most case the fact that the first value is incorrect

That is not the case. The first value is correct. The value will be the duration from the index position until the end of that bitcell. If you add the first bitcell value to the last bitcell value (which ends somewhere during the index position), you get the correct length for the first bitcell.

[JimDrew]

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.

As explained in the documentation, this is due to reading too many revolutions at a time. The SCP hardware has 512K of RAM on board. If 5 revolutions exceeds 512K of space, you will get this error. Reduce the number of revolutions to 4. The maximum number of bitcells possible with an Atari disk is about 125000. 5x125000 > 512K. Typically, tracks average around 75K, so 5 revolutions are not a problem.

[DrCoolZic]

Help

As I had more and more problem imaging floppies I have decided to change the drive. The good news is that I have tested another floppy drive and the results seems much better.

So I decided to put it in my setup to replace the old drive. Now the bad news: Unfortunately I have connected the floppy data connector in reverse direction so obviously it did not work. I disconnected and reconnected the floppy cable in the good position but now it does not work anymore. Seems like the drive is not detected so when I start SCP I cannot select drive in the source it is stuck to "Flux image".

Does that mean that my board is dead? When I connect the SCP device the USB light goes green, the third pretty light blink in red, then the second light goes green, nothing happen on the first light.

Putting the floppy cable incorrectly is certainly not a good idea but does anybody knows if this kill the board? Can it be repaired?
Red stripe is pin 1 and normally on the left when looking at the back of the drive.

I guess I need to buy another one

[DrCoolZic]

In most case the fact that the first value is incorrect

That is not the case. The first value is correct. The value will be the duration from the index position until the end of that bitcell. If you add the first bitcell value to the last bitcell value (which ends somewhere during the index position), you get the correct length for the first bitcell.

I do not think this is right. From What I have seen what you say for the first cell is correct (count from index to end of cell). But the cell that starts before the index and stops after the index is correctly "pushed" to the next revolution. Therefore in the second revolution you get the right length for the first cell, but this also mean that the last cell of the first revolution is the one just "before the index" (which is correct). Therefore the last bitcell is not truncated it is correctly pushed to the next revolution. So the second revolution gives you perfect values for all the cell.

[JimDrew]

Help
Putting the floppy cable incorrectly is certainly not a good idea but does anybody knows if this kill the board? Can it be repaired?

Yes, plugging the cable in backwards destroys the HUEY and/or DUEY chips on the SuperCard Pro board. The good news is that there is a lifetime warranty on the board, even when you destroy it.

You just have to pay the shipping cost to me and back to you.

The SuperCard Pro's bus is bi-directional (it can also be a floppy drive emulator), so there was no way to buffer the hardware so that it couldn't be destroyed when flipping the cable around backwards.

[JimDrew]

There is nothing "pushed" to any revolution. The dump is straight without any modifications done. The index to index pulse time is used to determine the exact position of where the bitcells are split on multi-revolution images. You have to use the index to index pulse time, along with the total bitcell times added together to get the exact spot of where the index pulse appears in the middle of a bitcell.

[DrCoolZic]

Help
...
You just have to pay the shipping cost to me and back to you.
...

Many thanks for this exceptional service
board has been sent

[DrCoolZic]

There is nothing "pushed" to any revolution. The dump is straight without any modifications done. The index to index pulse time is used to determine the exact position of where the bitcells are split on multi-revolution images. You have to use the index to index pulse time, along with the total bitcell times added together to get the exact spot of where the index pulse appears in the middle of a bitcell.

Here is a zoomed view of track 8.0 from Turrican. As we can see the No Flux Area overlap the Index. Not so obvious from the picture the NFA flux (flux 0 of the revolution) is 4.3 ms long and starts 1.3 ms before the index (and therefore terminates 3 ms after the index).

T08.0.png

Here are the data from SCP

Code: Select all

Rev 0 – Flux count = 39289 – Index Time = 199940300
Fluxes = 1344900, 5275, … , 24625, 2700
Sum of fluxes = 198625575 – Delta = 1314725

Rev 1 – Flux count = 39290 – Index Time = 199922800
Fluxes = 4298950, 5300, … , 24625, 2700
Sum of fluxes = 199923400 – Delta = -600

Rev 2 – Flux count = 39290 – Index Time = 199922500
Fluxes = 4296950, 5275, … , 24625, 2675
Sum of fluxes = 199921925 – Delta = 575

Rev 3 – Flux count = 39290 – Index Time = 199911075
Fluxes = 4298700, 5300, … , 24625, 2675
Sum of fluxes = 199911100 – Delta = -25

Rev 4 – Flux count = 39290 – Index Time = 199923575
Fluxes = 4299225, 5300, … , 24625, 2700
Sum of fluxes = 199923550 – Delta = -25

I thought I could make sense of these data to find out the position of the first flux but now I am lost? For the first revolution the first flux is 1.345 ms and the sum of flux is 198625575. So the difference with the index time (199940300) is 1.315 ms
In reality the post index part of the first flux is 3 ms and the position of the index is 1.3 ms. Where can I find these numbers?
Also strange is the fact that the first revolution has 39289 transitions where all the following have 39290. Seems not so important but the strange thing is that if you look at the values they start and ends with similar values. Not possible to easily compare all transitions but it seems like one transition is added somewhere in the middle? For information KF results have two transitions less (39288) and starts and ends with similar values?

In most cases the position of the index inside the first “normal flux” is not important (only pushing the position by few µs), but in case of NFA it is bad not to be able to describe the reality.

So questions are:

• during sampling the counter is reset each time a new transition is detected. Correct?
• For the first revolution the counter is started when the index is found and reset at the next transition after the index. Therefore, the value is supposed to be the post index part of the first flux. Correct?
• Assuming above is true why we do not get the right number for Turrican?
• How can I find the position of the index?

If you want to test the image you will find it here https://mega.nz/#F!9RJixYhI!ozJAY06nUpYj2vzpuWORRg name Turrican.7z

[JimDrew]

The SCP uses a hardware capture feature of the CPU. Every time there is a transition of the READ DATA line, the time is captured. As you know, there is a short pulse followed by a long duration to the next short pulse. The capture is programmed to ignore the short pulse and time from bitcell to bitcell. It's done in hardware and stored in the 512K RAM. It's done in an interrupt, so there is nothing that can alter anything. The index pulse is also captured the same way, using another hardware capture input.

The problem with NFA is that the LONG bitcell times will vary depending on the disk drive. I have some disk drives that have NFA regions that vary dramatically (milliseconds), and I have some disk drives that give you the same result every single time. So, for NFA (and for weakbits to some extent) the drive plays a huge roll in how accurate the results will be. Normally, you can just add all of the bitcell times together and it will equal the index to index time. The only variation at that point would be drive speed warble and typically it's off by no more than a microsecond (if that much). You might want to try a few different disk drives. I seem to have worst results for NFA regions when using the JU-475 drives.

With SCP, *everything* is queued off of the index pulse. So, when the index pulse appears the hardware capture events are started. At that point, the bitcell times are recorded up until the index pulse occurs again (when you are using a single revolution). If you are using mulitple revolutions then the last bitcell when the index pulse occurs is not cut short (due to being somewhere in the middle of the index pulse). On the last revolution, the last bitcell will be cut short. If you use SCP's editor/analyzer you can see exactly where the index pulse is while viewing the data. When doing a multi-revolution read the bitcell where the index pulse occurs is highlighted in yellow.

[MarkusNaslund]

Any Update to the following Post from the past? I cannot find it despite some decent searching...

FTP Login Detail Reminder:
ftp://retrobackup.com
user: mybackups
pass: Backup#1

Thanks,

-MN.

[JimDrew]

Alexshiv has apparently taken the site down. I will ask him if this is permanent.

[MarkusNaslund]

Alexshiv has apparently taken the site down. I will ask him if this is permanent.

Wow, and I thought I would place a copy all my .SCP files there and maybe DL the few I don't have and want a Flux copy of...hmmm...that would indeed bite.

[MarkusNaslund]

Alexshiv has apparently taken the site down. I will ask him if this is permanent.

Btw, it does ask for Username and PW so maybe that's a good sign?

I hope...

[JimDrew]

The public FTP was closed.

[MarkusNaslund]

The public FTP was closed.

So how does someone 'Register' to become a 'Member'?

Also, is there another resource for SCP files where one can share/exchange/browse SCP files?

There's one: mega.nz for Atari ST that looks good, although at the moment Commodore/Amiga are of interest to me.

-MN

[JimDrew]

Mega.nz is just a cloud storage system. You would have to know the exact link to data within that storage system.

[MarkusNaslund]

Mega.nz is just a cloud storage system. You would have to know the exact link to data within that storage system.

I have a link but only for Atari ST /SCP files...would like Amiga SCP Files and even C64/128 files but it seems like a guarded Secret of sorts...? ++

-MN.

[JimDrew]

The intention of public FTP site was for people to store image files of disks that they own. Copyright concerns is why it was shut down.

[MarkusNaslund]

Yes, I get that but why are SCP's available for other Platforms and D64s, ADF's, etc available all over the place...Copyright would be equally applicable to the various Platforms and Disk Formats?

[JimDrew]

Yes, that is correct. Some people don't care, but it is clear that copyrights are now actively being enforced with retro products making a come back. Atari, Nintendo, Sony, and other companies are taking legal action for copyright infringements.

[sonick5]

Hey, I know that this is an old post but does anyone have the dosbox-tc mentioned before here?