Bug reports

[LordCrass]

How accurate is the index sensor?

[admin]

Accurate to within 50ns, +/- the drive speed deviation. During the read startup, I wait for the next bitcell period before starting the read because you can have a bitcell appear directly under the start of the index pulse. This is the only time you will get a shift. You can use the analyzer and click READ TRACK to get an idea of how often data shifts, and you can see it is by one bitcell period at most (unless you have a drive with severe speed issues, which I have seen).

[DrCoolZic]

Do you have the capability to measure the time between the start of the bitcell and the index. This very important in case on No flux are (what you call strongbits).
In that case you may have several ms between the start of the cell and the index. Without this value it is not possible torepresent the data on the disk correctly

[admin]

If you add together all of the bitcell times from the start of the index to where the no flux area occurs, you know the exact length of time it is from the index to the no flux area. ALL of the bitcell times added together should also equal the total index to index duration, within the speed deviation of the drive - and that is always the case. Typically, I see no more than a few microseconds of difference.

[hawui1]

Some minor points I noticed, thye might be non-errors but I leave you to judge:


- When loading an .SCP the number of tracks on the target disk doesn't appear to be automatically set, but since the program should know how many tracks are contained in the SCP file this would be a nice feature

- When copying a disk from drive 0 to drive 0, after the source disk is read and program asks to Insert destination disk, there's a long delay before the motor light of the drive goes out and the head is returned to track 0. Something like 15-20s. Don't know if this is necessary to the program but it would be nice if this interval is reduced to the minimum

- When copying from Disk 0 to Disk 0 in blind mode, if the target disk is found to be write protected, program opens a dialog to inform the user. Here, again, the led of the drive takes 15-20 seconds to switch off.When the disk is extracted, made write enabled, reinserted and the Alert dialog is dismissed pressing "Retry", an error is displayed saying "No Index pulse found" no matter of how many times "Retry" is pressed. This forces the whole read to be started from scratch

- In the menù "Drive Settings"->"Drive Type" I see only two 5.25" options either 48 or 96 tpi but the floppy I connected is a 3.5" model. Tested with two floppy cables, tested with two 3.5" floppy drives always the same. I might be seriously wrong here but if I remember correctly, in a previous version, this detection was working (?)... At any rate, even with the wrong model displayed/selected, the read/write seems to be working anyway

[admin]

Some minor points I noticed, thye might be non-errors but I leave you to judge:


- When loading an .SCP the number of tracks on the target disk doesn't appear to be automatically set, but since the program should know how many tracks are contained in the SCP file this would be a nice feature

Information about the .scp image file is not shown at all.

- When copying a disk from drive 0 to drive 0, after the source disk is read and program asks to Insert destination disk, there's a long delay before the motor light of the drive goes out and the head is returned to track 0. Something like 15-20s. Don't know if this is necessary to the program but it would be nice if this interval is reduced to the minimum

This is normal, and deliberate. This saves wear and tear on the drive motor by leaving it on for a period of time. A drive that has been spinning for awhile has a more accurate speed. So, when copying multiple disks the drive will usually stay on the entire time until you are done.

- When copying from Disk 0 to Disk 0 in blind mode, if the target disk is found to be write protected, program opens a dialog to inform the user. Here, again, the led of the drive takes 15-20 seconds to switch off.When the disk is extracted, made write enabled, reinserted and the Alert dialog is dismissed pressing "Retry", an error is displayed saying "No Index pulse found" no matter of how many times "Retry" is pressed. This forces the whole read to be started from scratch

Thanks for pointing this out... I will correct that. If the drive is off, it should turn it back on... but the long delay will always be there.

- In the menù "Drive Settings"->"Drive Type" I see only two 5.25" options either 48 or 96 tpi but the floppy I connected is a 3.5" model. Tested with two floppy cables, tested with two 3.5" floppy drives always the same. I might be seriously wrong here but if I remember correctly, in a previous version, this detection was working (?)... At any rate, even with the wrong model displayed/selected, the read/write seems to be working anyway

Any option for a 5.25" drive only applies to a 5.25" drive. Ignore this setting unless you are using a 5.25" drive.

[hawui1]

Information about the .scp image file is not shown at all.

Infact, so i have to open the .ipf first, see how many tracks it contains, convert it to .scp and then I must set the start/end track correctly. If .scp file already contains start/end track they could be set automatically (always leaving the user the possibility to change them after if necessary before starting real write to file)

This is normal, and deliberate. This saves wear and tear on the drive motor by leaving it on for a period of time. A drive that has been spinning for awhile has a more accurate speed. So, when copying multiple disks the drive will usually stay on the entire time until you are done.

so this means I can extract the original disk with the light of the drive still switched on? Could it be I ruin the disk by doing this?

Any option for a 5.25" drive only applies to a 5.25" drive. Ignore this setting unless you are using a 5.25" drive.

ok, fine I tought (my bad) applicationw as detecting the drive type, instead it was just an option that could be set

[admin]

Information about the .scp image file is not shown at all.

Infact, so i have to open the .ipf first, see how many tracks it contains, convert it to .scp and then I must set the start/end track correctly. If .scp file already contains start/end track they could be set automatically (always leaving the user the possibility to change them after if necessary before starting real write to file)

No. The information contained in the .scp image is used. So, however the file was created is how it will be written back. The only exception is being able to select the "override" option to change the number of tracks.

This is normal, and deliberate. This saves wear and tear on the drive motor by leaving it on for a period of time. A drive that has been spinning for awhile has a more accurate speed. So, when copying multiple disks the drive will usually stay on the entire time until you are done.

so this means I can extract the original disk with the light of the drive still switched on? Could it be I ruin the disk by doing this?

No, it causes no harm to the disk.

Any option for a 5.25" drive only applies to a 5.25" drive. Ignore this setting unless you are using a 5.25" drive.

ok, fine I tought (my bad) applicationw as detecting the drive type, instead it was just an option that could be set

Correct!

[Thraka]

I've connected two devices to the unit, device 0 is a 5.25 drive, and device 1 is a 3.5 drive.

On the Disk Archiver tool (v1.10), the Target Device combo box does not list Flux Image File, only Device 0 and 1.

[admin]

OK, I see the issue. You are using a PC disk type. For now, go set the disk type to Amiga and then close the SCP application. When you re-launch the app there will be a bunch of image file formats, including two "ADF" entries - which is also a bug. You can then select IBM360K or whatever you were using to make an image.

I will need to correct this.