Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > The "same drive" problem
2016-08-30 11:15
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....
 
2016-08-30 12:29
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.
2016-08-30 12:32
lft

Registered: Jul 2007
Posts: 369
Quoting tlr
Should 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.
2016-08-30 12:40
tlr

Registered: Sep 2003
Posts: 1790
Quoting lft
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.

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.
2016-08-30 12:43
tlr

Registered: Sep 2003
Posts: 1790
Quote: Quoting tlr
Should 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.
2016-08-30 14:10
Zer0-X
Account closed

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.
2016-08-31 06:41
lft

Registered: Jul 2007
Posts: 369
Quoting tlr
IIRC 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.
2016-08-31 08:01
tlr

Registered: Sep 2003
Posts: 1790
Quoting lft
Quoting tlr
IIRC 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.
2016-10-07 07:43
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.
2016-10-07 08:29
Bitbreaker

Registered: Oct 2002
Posts: 508
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.
2016-10-07 09:34
ChristopherJam

Registered: Aug 2004
Posts: 1409
Â…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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Bieno/Commodore Plus
Flashback
DeMOSic/MS^LSD^ONS
wil
Guests online: 96
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Sabbi  (9.5)
4 Morpheus  (9.4)
5 CreaMD  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.06 sec.