| |
lft
Registered: Jul 2007
Posts: 369 |
The "same drive" problem
Hi!
Can we talk about why some loaders fail to read disks that weren't written on the same drive?
I can think of two possible reasons: Different alignment and different RPM. But I also read that alignment is not a problem with 1541-II, and that RPM is often very close to 300 rpm. Then what is the problem?
Then there's the matter of *how* this leads to trouble. Are some loaders ignoring checksums? Are there multiple bit errors that cancel so the EOR checksum works out anyway? Or does the loader hang because it does verify the checksum, but keeps getting read errors on the same block?
Has anybody tried to find the root cause of this problem in any kind of systematic way? |
|
... 2 posts hidden. Click here to view all posts....
|
| |
lft
Registered: Jul 2007
Posts: 369 |
Good points.
Although, the unstable transferloops would be a separate issue, I think. That would happen if the loader is only tested on a setup where the c64 clock frequency and the drive clock frequency are close together, say. On a different drive, that would not be the case, so the transfer would fail. But writing the disk with that drive would not solve the problem.
It is possible that the relationship between drive clock frequency and RPM is involved (because that affects how "large" the bits are on disk). If so, then that could be compensated by adjusting the RPM, I suppose. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting tlrShould be easy to test by tweaking the drive speed.
By the way, a word of warning: I tried this on my drive yesterday and it may have broken as a result. Possibly the belt was almost worn out, and tweaking the RPM caused it to stretch out beyond its usual range, so that it tends to slip now. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting lftIt is possible that the relationship between drive clock frequency and RPM is involved (because that affects how "large" the bits are on disk). If so, then that could be compensated by adjusting the RPM, I suppose.
Sure, they will both appear as a bitrate difference to the loader. Note that the potential frequency difference is at least a magnitude less than the potential rotational speed difference though. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting tlrShould be easy to test by tweaking the drive speed.
By the way, a word of warning: I tried this on my drive yesterday and it may have broken as a result. Possibly the belt was almost worn out, and tweaking the RPM caused it to stretch out beyond its usual range, so that it tends to slip now.
Very unfortunate. Shouldn't be much of a strain to change the speed a few percent, but sure something changes so that could trigger latent problems.
IIRC only some of the drives have drive belts. I think the older ones do not. |
| |
Zer0-X
Registered: Aug 2008
Posts: 78 |
Just yesterday I dumped two disks that were originally formatted with one drive and then written to with another drive, which had been slightly out of alignment (towards the outer rims due to banging).
Haven't tried reading those disks with any C= drive yet, but a HD floppydrive with a narrower head had problems with crosstalk from the previous formatting. Getting good data from the disks required some manual misalignment. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting tlrIIRC only some of the drives have drive belts. I think the older ones do not.
I think there are two versions of the 1541-II. One version (with the Chinon mechanism) has no belt, but also no way of adjusting the speed. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting lftQuoting tlrIIRC only some of the drives have drive belts. I think the older ones do not.
I think there are two versions of the 1541-II. One version (with the Chinon mechanism) has no belt, but also no way of adjusting the speed.
That seems familiar. I have experience mainly with the regular 1541, short and long board.
Adjustable speed is probably doable with modification btw. Haven't looked at the 1541-II specifically but I did do such a modification to an Amiga external 3.5" for writing long tracks with it.
Basically there was a 455KHz ceramic resonator giving the reference frequency to the motor driver. I removed that and injected an external clock on the pin I determined was the clock input. Worked quite well. |
| |
lft
Registered: Jul 2007
Posts: 369 |
I confirmed what we knew from theory: If you write a disk with a slow drive (low rpm), you'll have trouble reading it with a fast drive (high rpm). But the other way around works fine.
Hence, what you need to frame and put on your wall is this simple rule:
WRITE FAST, READ SLOW
I tried this using two drives at 290 rpm and 300 rpm. Each drive can read disks written by itself, but the 300 rpm drive cannot read disks written by the 290 rpm drive. (If somebody else could repeat the experiment, that would be appreciated.)
So as you're all preparing your compo entries for X, it might be a good idea to make sure to master them at a high rpm. In practice, belt drives get slower over time, so it's unlikely that you'll run into any >300 rpm drives. Mastering the disks at 300 rpm should therefore be fine. Drives without a belt (i.e. those that have no speed-adjustment potentiometer) are stable at 300 rpm, so try to write using one of those.
In my experiment, I used Spindle. But note that e.g. Krill's loader has the same tolerances (actually even tighter, depending on the version) in regards to reading from disk. For Spindle, anything in the range 299-301 can be considered close enough to 300. So if your drive spins at 299 rpm or higher, then you can safely master Spindle demos on it. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Did such tests a few months ago and can confirm, depending on the loader used a different range of speed tolerance works. You can even try to turn down speed while loading and see how the loader gets into trouble. However i discovered when spinning too fast it can happen that checksum tests get bypassed at some moment.
The crosstalk stuff/misalignment can also lead to problems on drives. I have one specific 1541-ii where i happen to read chunk on certain tracks, but with valid checksum. I tracked that down to the mechanics, the same mechanic bears the same problems when connected to known good electronics/controllers. Also, there exists a drive that needs 4 cycles extra per transferred byte to not choke. Not sure if it is equipped with a wrong chip type or a broken chip, i can simulate the same problem when exchanging the 74ls14 on the 1541 with a 7414 type. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Â…and now you can measure exactly how fast your drive spins with RPM Test 1.0.
Thanks to LFT for testing; I can't reach my hardware at the moment. |
| Previous - 1 | 2 - Next |
