EDIT: Amazing I wanted to test your analyzer stuff ...Went back to copy mode with 5 revolutions and now it miraculously works ????

Hmmm... did you have this RAM error after experiencing the problem with not having the disk in the drive and then not being able to proceed? I could see maybe the buffer pointer is not being reset or something.

That is the total number of bitcells, each 2 bytes wide (16 bits). So 247,470 x 2 = 494,940 bytes of data, which fits inside of 512K of RAM.

So, this should have no issues.

I have tried again when in analyzer I can read trck 1 always correctly (did it about 20 times)the number of bit cells vary up to 251300 without problemAs soon I move to copier only the first track is imaged and the erro message happen

EDIT: Amazing I wanted to test your analyzer stuff ...Went back to copy mode with 5 revolutions and now it miraculously works ????

Hmmm... did you have this RAM error after experiencing the problem with not having the disk in the drive and then not being able to proceed? I could see maybe the buffer pointer is not being reset or something.

Thought this problem had been fixed long ago?But now when I get it I restart the program to be on the safe side

The problem before was that I was reserving memory in the RAM for another buffer so the buffer space was greatly reduced. That was fixed. What you are seeing is something completely new, and it is odd that closing the program and restarting it fixes it.

JimDrew wrote:The problem before was that I was reserving memory in the RAM for another buffer so the buffer space was greatly reduced. That was fixed. What you are seeing is something completely new, and it is odd that closing the program and restarting it fixes it.

I did not say that! I said that to avoid this kind of question I was restarting the program ...in analyzer mode it works, in copy it fails for same number of revolutions

Yes, that is coming. In fact, I have changed quite a bit of how the imaging works. It will appear seemless to you for the most part.

I am adding the ability to select the "heads" for copying. Either both, side 1 (bottom), or side 2 (top). In the .scp image format I have always left the heads field NULL (0) and never used it. You really don't need to look at it because the entry tables will tell you if data is present. So, with the new change, 0=both sides, 1=side 1, 2=side 2. There has always been data present because both sides have always been imaged. So now, when you select a disk format it will auto-fill the basic info: head(s), tracks, density. You can change these parameters after selecting a disk type. When you change a parameter the disk type will show as "custom". This change to the SCP software will let you copy/image just a single side of a disk. I am also extending the batch conversion feature so you can convert from flux image to flux image. So, you will be able to convert an image with two sides to a single sided flux image. This will eliminate the extra data. You can also use this feature to convert a preservation quality image to a non-preservation image just to use with emulators (like Steem), because that modifies the flux so that it compresses substantially better than raw unaltered flux. Non-preservation images will generally not write back correctly, so they should only be used with emulators.

You won't have to re-image your disks that have existing double-sided images. You will be able to do the batch conversion and strip the top side's data and make a new image.