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?
2016-08-30 11:32
chatGPZ

Registered: Dec 2001
Posts: 11386
RPM is an important factor for "optimized" loaders. also these days there are sometime significant differences with the oscillator/crystal, which makes tight transferloops unstable (eg the booze designs loader seems very picky in this regard, or the one by dasheele/SD)

i dont think alignment is actually much of a problem usually, even with the oldstyle 1541. from my experience it only becomes a problem when someone tried to align the drive =P

that said, due to the analog nature of the whole thing, its kindof hard to pinpoint a definitive or single root cause - its a combination of all of these and its different with various drives :)
2016-08-30 12:24
tlr

Registered: Sep 2003
Posts: 1790
I too believe the rotational speed is the main issue. The bytes are potentially coming in at a rate a couple of percent off from nominal.

Should be easy to test by tweaking the drive speed.
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.
 
... 2 posts hidden. Click here to view all posts....
 
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
A3/AFL
algorithm
E$G/HF ⭐ 7
iceout/Avatar/HF
Gildan Jondal/Suicyc..
Freeze/Blazon
astaroth/TRSI
wil
Steffan/BOOM!
Copyfault/Extend^tsn..
Walt/Bonzai
The MeatBall
The Syndrom/TIA/Pret..
t0m3000/hf^boom!^ibx
TheRyk/MYD!
MWR/Visdom
Guests online: 95
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 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (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 Musicians
1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

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