Help diagnosing an XF551 mech...

[ijor]

As you probably know, the XF551 mechanism is a standard PC drive. So in first place I would remove it and test in a PC. Any PC with a built-in floppy controller should be good enough.

 

In second place, it is not clear to me from your posts, if you can read back disk written on the very same drive or not. If you can't, it's unlikely to be a RPM or alignment issue. The drive and the FDC can tolerate quite a big displacement in RPM, head align (in a lesser degree), track-zero sensor position, etc. You wouldn't be able to read disk written in other drives, of course. From all the possible aligments, the head is probably the most critical.

[machf]

As you probably know, the XF551 mechanism is a standard PC drive. So in first place I would remove it and test in a PC. Any PC with a built-in floppy controller should be good enough.

Hmmm... I had thought of that, but I don't have any DD PC diskettes. I guess I could format a new one, but would that be useful?

 

In second place, it is not clear to me from your posts, if you can read back disk written on the very same drive or not. If you can't, it's unlikely to be a RPM or alignment issue. The drive and the FDC can tolerate quite a big displacement in RPM, head align (in a lesser degree), track-zero sensor position, etc. You wouldn't be able to read disk written in other drives, of course. From all the possible aligments, the head is probably the most critical.

No, I couldn't even format a disk with it when I tried... I'm thinking maybe it's looking for track 0 outside the writeable area of the disk.

[ijor]

As you probably know, the XF551 mechanism is a standard PC drive. So in first place I would remove it and test in a PC. Any PC with a built-in floppy controller should be good enough.

Hmmm... I had thought of that, but I don't have any DD PC diskettes. I guess I could format a new one, but would that be useful?

 

Well, it would help to confirm if the problem is in the drive mechanism, or in other components of the drive.

 

It might also help diagnosing because there are some kind of tests that are much easier to do in the PC. i.e., you can measure RPM on the PC without the need of a working disk.

 

No, I couldn't even format a disk with it when I tried... I'm thinking maybe it's looking for track 0 outside the writeable area of the disk.

 

If I understand correctly, you are saying that first few tracks work ok. This would mean that if the problem is the track-zero sensor being out of place, it has to be displaced inwards by about 30 tracks! Assuming this is physically posible, you should be able to detect this easily by operating the drive without the case. Format a disk and watch and/or hear the stepper. If the sensor is so much displaced, then the stepper would stop stepping inwards very soon.

[machf]

If I understand correctly, you are saying that first few tracks work ok. This would mean that if the problem is the track-zero sensor being out of place, it has to be displaced inwards by about 30 tracks! Assuming this is physically posible, you should be able to detect this easily by operating the drive without the case. Format a disk and watch and/or hear the stepper. If the sensor is so much displaced, then the stepper would stop stepping inwards very soon.

No, at first I thought it could read the first sector(s), but it turned out that it was getting garbage, not the actual contents of the sector - and the read buffer would contain the same garbage for each sector I attempted to access.

And why would it have to be displaced inwards? I'm thinking it might be displaced outwards by 1 or maybe 2 tracks... the stepper is going practically all the way, I may try listening and counting the steps to make sure. After it goes through all the tracks and attempts to write data to the boot sectors, it fails and retries the formatting... and fails again (and retries and fails again... what was the default retry count?).

[ijor]

No, at first I thought it could read the first sector(s), but it turned out that it was getting garbage, not the actual contents of the sector - and the read buffer would contain the same garbage for each sector I attempted to access.

And why would it have to be displaced inwards?

 

Because I understood you were saying that the first few tracks do work. Then this couldn't happen if the problem was that the track-zero sensor was displaced outwards. In such a case, the first tracks are the ones that would fail.

 

I'm thinking it might be displaced outwards by 1 or maybe 2 tracks... the stepper is going practically all the way

 

It must be more than just one track, and probably more than two. This is something that you could (at least in theory) verify easily in the PC, by formatting and reading inner tracks. I say in theory because you would need the right software.

 

Conceivable this might be possible in the Atari as well. But I don't remember for sure how the XF-551 firmware behaves when it can't read the first sectors. These drives use the first sectors to check the density. Some drives, depending on the firmware, would assume single density if they can't read them. Then you can read sectors on the inner tracks, even when the first tracks are bad or unformatted.

 

Btw, did you check that the track zero sensor it working at all? (again, easier to check in the PC).

 

But honestly, if you can't read any sectors at all, there are so many things that could be bad, that I'm not sure anymore is worth to spend too much time.

Edited June 25, 2008 by ijor

[machf]

It must be more than just one track, and probably more than two. This is something that you could (at least in theory) verify easily in the PC, by formatting and reading inner tracks. I say in theory because you would need the right software.

Any which you can recommend?

Conceivable this might be possible in the Atari as well. But I don't remember for sure how the XF-551 firmware behaves when it can't read the first sectors. These drives use the first sectors to check the density. Some drives, depending on the firmware, would assume single density if they can't read them. Then you can read sectors on the inner tracks, even when the first tracks are bad or unformatted.

The error code it gives (163) is the same the working XF551 returns for an unformatted disk - so I think it possibly assumes that if it can't read the first sectors.

 

Btw, did you check that the track zero sensor it working at all? (again, easier to check in the PC).

Only thing I've checked on it was that the ribbon cable connected to it had no broken traces...

What can I do to check it?

 

But honestly, if you can't read any sectors at all, there are so many things that could be bad, that I'm not sure anymore is worth to spend too much time.

Well, I don't have money but I have plenty of time, as I'm currently unemployed (technically, I'm self-employed, but business has been very bad these past months).

[ijor]

It must be more than just one track, and probably more than two. This is something that you could (at least in theory) verify easily in the PC, by formatting and reading inner tracks. I say in theory because you would need the right software.

Any which you can recommend?

 

I'm afraid I don't, otherwise I would have already recommended something. Nowadays I do that kind of stuff with a Catweasel, I didn't mess with the PC floppy controller for ages.

 

I don't think there is any such tool for Windows. Possibly there is something for Linux, I don't know (Hias, are you reading this? Are you aware about any such tool for Linux?). But possibly you would need to boot plain DOS or Win 9X, and use something like PC-Tools or Norton Disk Editor.

 

If you are good at programming, you might do some basic tests by accessing the disk via BIOS under plain DOS. Or if you prefer, by hacking the Linux driver with some diagnostic stuff.

 

The error code it gives (163) is the same the working XF551 returns for an unformatted disk - so I think it possibly assumes that if it can't read the first sectors.

 

163 is a CIO error code, not a SIO one. How are you trying to read those sectors?

 

Well, I don't have money but I have plenty of time, as I'm currently unemployed (technically, I'm self-employed, but business has been very bad these past months).

 

I understand, but without the right tools it might be very difficult. Unless you are lucky and the problem is obvious, you usually need a scope for detecting the drive problem, let alone to repair it. Even with a scope it might be not trivial.

[Rybags]

You can in certain circumstances use the PC sound card as a poor-man's oscilloscope (I did, in the thread about Antic 240 scanline behaviour

 

Although you're limited somewhat by whatever sample rate the soundcard is capable of, usually 48 KHz for older cards, but 192 for newer ones.

 

And of course, you'd probably not want to introduce any signal that uses large voltage levels.

[machf]

I'm afraid I don't, otherwise I would have already recommended something. Nowadays I do that kind of stuff with a Catweasel, I didn't mess with the PC floppy controller for ages.

 

I don't think there is any such tool for Windows. Possibly there is something for Linux, I don't know (Hias, are you reading this? Are you aware about any such tool for Linux?). But possibly you would need to boot plain DOS or Win 9X, and use something like PC-Tools or Norton Disk Editor.

I believe a friend of mine still has some old edition of Norton Utilities lying around, I'll ask him... and I still have a really old PC Tools version on a diskette somewhere, wonder if that one has such a tool.

If you are good at programming, you might do some basic tests by accessing the disk via BIOS under plain DOS. Or if you prefer, by hacking the Linux driver with some diagnostic stuff.

Even though I know 80x86 assembly programming, I never got into PC BIOS stuff - I kept using my 800XL as my main computer until 1996 or so...

163 is a CIO error code, not a SIO one. How are you trying to read those sectors?

The usual commands issued to the drive to read a sector... and I get that error when I attempt ro read the disk directory from DOS.

I understand, but without the right tools it might be very difficult. Unless you are lucky and the problem is obvious, you usually need a scope for detecting the drive problem, let alone to repair it. Even with a scope it might be not trivial.

 

You can in certain circumstances use the PC sound card as a poor-man's oscilloscope (I did, in the thread about Antic 240 scanline behaviour

 

Although you're limited somewhat by whatever sample rate the soundcard is capable of, usually 48 KHz for older cards, but 192 for newer ones.

 

And of course, you'd probably not want to introduce any signal that uses large voltage levels.

 

Well, last week I was searching for "software oscilloscopes" for that purpose. Haven't fully tried the ones I found yet, though. I'll take a look at that thread...

 

Thank you both for the input.

Edited June 26, 2008 by machf

[Rybags]

I just recorded with Audacity.

 

Just that is fine if you want the rough graphical representation of what's going on. And if you're only dealing with logic levels, it's more than enough anyway.

Of course, the main issue as I said, is that the sample rate isn't exactly helpful in a lot of situations, although at 192 KHz you can still discern HSync/VSync pulses in a luma video signal.

[sup8pdct]

Well, as the title implies, today after a couple of years without using it, I found out that the Mitsumi mech of one of my XF551 drives isn't working properly. If I try to boot from it, I get the usual "BOOT ERROR" messages; if I try to read a disk's directory on it (using it as D2:, which was how I originally had it - changed it to D1: only to test it alone), I get ERROR- 163 (meaning the drive isn't responding). Any suggestions on where to look? On first sight, I can't see anything suspicious, I'm leaving the multitester testing for tomorrow since it's late already.

 

I've already discarded any electronics problems in the board, swapped the mechs with the other XF551 and found out it's the mech. The motors seem to be OK (drive spins normally and head moves normally too), I also cleaned the head and tried to realign it just in case, no changes. Haven't checked solder points in the mech yet (as I said, it's late already - I'm tired and the artificial lighting isn't good enough either), if anybody knows what the "usual suspects" tend to be, I'd appreciate the help. As I said, I connected my equipment after a 2 year hiatus (more or less), last time it was working fine except for one of the SIO connectors (which I already resoldered today) so overheating and such isn't the issue here...

 

Thanks in advance.

 

It could be the mech it self.

From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.

I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit.

I have no idea about head settle times between different mechs.

 

James

[MEtalGuy66]

Well, as the title implies, today after a couple of years without using it, I found out that the Mitsumi mech of one of my XF551 drives isn't working properly. If I try to boot from it, I get the usual "BOOT ERROR" messages; if I try to read a disk's directory on it (using it as D2:, which was how I originally had it - changed it to D1: only to test it alone), I get ERROR- 163 (meaning the drive isn't responding). Any suggestions on where to look? On first sight, I can't see anything suspicious, I'm leaving the multitester testing for tomorrow since it's late already.

 

I've already discarded any electronics problems in the board, swapped the mechs with the other XF551 and found out it's the mech. The motors seem to be OK (drive spins normally and head moves normally too), I also cleaned the head and tried to realign it just in case, no changes. Haven't checked solder points in the mech yet (as I said, it's late already - I'm tired and the artificial lighting isn't good enough either), if anybody knows what the "usual suspects" tend to be, I'd appreciate the help. As I said, I connected my equipment after a 2 year hiatus (more or less), last time it was working fine except for one of the SIO connectors (which I already resoldered today) so overheating and such isn't the issue here...

 

Thanks in advance.

 

It could be the mech it self.

From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.

I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit.

I have no idea about head settle times between different mechs.

 

James

Hmm. My experience has been exactly the oposite.. Have you been trying 1.2meg HD mechs or something?

 

I own 10 XF551s.. And every PC mech Ive ever used has worked identicly to the mechs that camein the drive. Even some Commodore Colt mechs that used to act "freaky" on my dad's 486 machine back in the day, worked fine on the XF551.. I used to have a huge stack of 360k drive mechs, but regrettabley, I threw most of them away in the mid-late 90s because I needed the storage space they were occupying. (DOH!).. Who knew they would get rare... Heh. The longer I live, the more I learn that I should not give in to the will of others and go against my own "packrat" tendencies...

[sup8pdct]

Well, as the title implies, today after a couple of years without using it, I found out that the Mitsumi mech of one of my XF551 drives isn't working properly. If I try to boot from it, I get the usual "BOOT ERROR" messages; if I try to read a disk's

Thanks in advance.

 

It could be the mech it self.

From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.

I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit.

I have no idea about head settle times between different mechs.

 

James

Hmm. My experience has been exactly the oposite.. Have you been trying 1.2meg HD mechs or something?

"packrat" tendencies...

 

 

I should point out that my mechs would be "old" ones they have jumpers for mech 1 to 4 and have a position for a resistor terminator pack.

I got them for use on the BB. 2 are 360K mechs and 1 is a 1.2. I either got them off my mate for nothing or from old pc's, also for nothing.

All are longer.

I used them when I was copying all my floppies to ATR's. If my 1050 wouldn't read a sector, I would then use the mechs and keep swaping round till I got the sector or I gave up.

I didn't opt for the "PC" type. they can be modded but is a PITA.

 

James

 

James

[ijor]

From my playing around with things, no all pc 360K drives work. most will need a mod to get it to work and then is a problem of length.

I have found the one used in the XF is short compared with the pc ones I have. They hit the heatsink at the back of the drive and won't fit. I have no idea about head settle times between different mechs.

Hmm. My experience has been exactly the oposite.. Have you been trying 1.2meg HD mechs or something?

 

I agree with MEtalGuy66. Most, probably all, PC 360K mechanisims should work. You might need to change the drive selection jumper, and you might have an issue of physical length. But otherwise they should work without problems. In the worst case you won't be able to access the flippy side, but in most cases is again, an issue of right jumper positions. Head settle times is a non-issue here.

[HiassofT]

Possibly there is something for Linux, I don't know (Hias, are you reading this? Are you aware about any such tool for Linux?).

I just stumbeld across this thread, and, yes, this is quite easy in Linux if you have the "fdutils" package installed (it is included in the Knoppix boot CD/DVD).

 

For example: format a disk double sided, double density, 9 (512-bytes) sectors, 42 tracks:

superformat /dev/fd0 ds dd sect=9 cyl=42

"/dev/fd0" is the first floppy drive (A: in dos), use "/dev/fd1" for the second floppy drive (B:). Maybe you might also have to add a "tpi=48", but I'm not sure about this (I don't have a 360k floppy drive here in my PC).

For a really quick test add options "-b 39 -e 41" to superformat, this only formats tracks 39-41.

 

The full documentation of the fdutils is here: http://fdutils.linux.lu/Fdutils.html

 

After you formatted the drive, you can try accessing it. First of all, the floppy device (/dev/fd0) acts like a standard file. So, to read the whole disk you could just do a "cat /dev/fd0 > imagefile". To write an imagefile, use "cat imagefile > /dev/fd0". If you have no data to write, use "/dev/zero" instead of imagefile, this will fill the whole disk with zero-bytes.

 

Then, reading/writing individual sectors/tracks on the disk can most easily be done with the "dd" command. It lets you specify an offset where to start reading/writing, so you just have to know how to calculate this offset:

- we will use a blocksize of 512, so the offset is just the sector number (starting at 0)

- the first 9 sectors are on side 1, track 0, the next 9 sectors are on side 2, track 0. The next sectors are then at track 1 and so on and so forth.

 

So, for example, the offset for the first sector on side 1 in track 40 would be 2*9*40 = 720.

 

Now, lets write to this sector (we will just fill it with zeroes):

dd if=/dev/zero of=/dev/fd0 bs=512 seek=720 count=1

 

And now read it back and write it to "imagefile":

dd if=/dev/fd0 of=imagefile bs=512 skip=720 count=1

 

Note the difference ("skip" in reading, "seek" in writing). To write multiple sectors, just modify the "count=.." parameter.

 

so long,

 

Hias

[machf]

Hi, Hias.

Thanks for the input. Unfortunately, it will take me a whole day to download the Knoppix CD... how old are the fdutils? I still have a Redhat Linux 5.2 partition on the HDD of the Celeron computer where I was going to test the drive, don't know if they were included in the distribution or if they would work under it either...

 

I wonder if your WriteAtr tool could be used for some tests, too... hmmm...

[HiassofT]

how old are the fdutils? I still have a Redhat Linux 5.2 partition on the HDD of the Celeron computer where I was going to test the drive, don't know if they were included in the distribution or if they would work under it either...

They are already quite old, the current version (5.5) is from March 2005. But even older versions should be fine, too, I guess.

 

I wonder if your WriteAtr tool could be used for some tests, too... hmmm...

Testing standard disk access should be working fine with WriteAtr. Just be sure to configure the drive as "360k" in the BIOS.

 

You can also use MSDOS format.com to do a quick test.

 

With fdutils/Linux you could easily check if formatting more than 40 tracks works, WriteAtr can't do that. But, back in the good old days, I used some other programs (can't remember their name) to format MSDOS floppies in higher capacity (more sectors per track, more tracks). Maybe a simtel mirror still has them.

 

so long,

 

Hias

[machf]

Well, they didn't compile under that old version of Redhat... apparently some needed files are missing.

 

I tried the DOS format, but got a "track 0 bad" error with the drive. Also tried the old UTIL for Atari diskettes, it seems to format the tracks, but fails when attempting to write the VTOC and directory. Can't read a properly formatted diskette, either.

 

So, it seems it's something with the head(s), not just misalignment...

 

Among my old PC stuff I found a working Mitsumi/Toshiba mech that fits perfectly inside the XF551 's casing, but it's a 1.2MB drive. Attempting to use it with the 800XL will also give me an "ERROR- 163" when trying to read the directory.

 

Damn, long ago one of my cousins had an XT computer with the same Mitsumi mech as the XF551, only that it had a black front instead of a grey one, I remember I even exchanged them to test it back then. I wonder whatever happended to that one...

 

I guess if I can't get the drive to work again I may finally convert it into a 3.5" drive... I have the adapters from an old PC in a drawer, both for the data and the power cable. That still requires a new ROM, right?

 

UPDATE: tested the film cable going to the heads for continuity, apparently no problems there. Maybe it's the connector where the film cable connects to the board...?

Edited July 2, 2008 by machf

[ijor]

I guess if I can't get the drive to work again I may finally convert it into a 3.5" drive... I have the adapters from an old PC in a drawer, both for the data and the power cable. That still requires a new ROM, right?

 

I never tried, but I'm not sure you need a new ROM. Without a new ROM you are, of course, limited to 40 tracks (360K). But otherwise I don't see why it shouldn't work with the standard ROM.

 

Among my old PC stuff I found a working Mitsumi/Toshiba mech that fits perfectly inside the XF551 's casing, but it's a 1.2MB drive. Attempting to use it with the 800XL will also give me an "ERROR- 163" when trying to read the directory.

 

You probably can use a 1.2MB drive as well. But you'll need to change some jumpers. Do you have the jumper map of that model? (and again, try it before on the PC, to make sure it is in working condition).

[machf]

Among my old PC stuff I found a working Mitsumi/Toshiba mech that fits perfectly inside the XF551 's casing, but it's a 1.2MB drive. Attempting to use it with the 800XL will also give me an "ERROR- 163" when trying to read the directory.

 

You probably can use a 1.2MB drive as well. But you'll need to change some jumpers. Do you have the jumper map of that model? (and again, try it before on the PC, to make sure it is in working condition).

I don't have the jumper settings, but I suppose I can look them up. And yes, I've tested it on the PC before.

IIRC, the main problem is that the head of a HD FDD writes narrower tracks and that each step between tracks is also shorter. Not sure if there was also a problem with how much current they drain and how much the XF551's power supply can provide...

[HiassofT]

IIRC, the main problem is that the head of a HD FDD writes narrower tracks and that each step between tracks is also shorter.

This might be an issue, several people (including me) had no problems so far with a 5.25HD drive in a PC, other people reported troubles with disks that were already used in a 1050.

 

But there's another showstopper:

 

The 5.25" HD drives rotate at 360 RPM instead of 300RPM, so the FDC has to use a data rate of 300kbps instead ot 250kbps to read/write DD disks. The XF551 doesn't know about that (I'm not sure if the XF551 would even support the 300kbps rate) and therefore can't read/write other DD disks. Even formatting a DD disk in a HD drive would fail since the tracks are now 20% shorter (either the last sectors of a track would overwrite the first sectors or the FDC aborts formatting because it gets another index pulse).

 

so long,

 

Hias

[ijor]

I don't have the jumper settings, but I suppose I can look them up. And yes, I've tested it on the PC before.

IIRC, the main problem is that the head of a HD FDD writes narrower tracks and that each step between tracks is also shorter. Not sure if there was also a problem with how much current they drain and how much the XF551's power supply can provide...

 

That's not the main problem. The main problem is (as Hias pointed out) the rotational speed. That's why you need the jumper map, to change the rotational speed (and possibly other settings as well).

 

Just in case I wasn't clear: I didn't mean you could use a 1.2MB mechanism as a full compatible replacement for a 360K one. What I mean is that you could probably use the mechanism in a XF551, and without any ROM replacement. You won't get interoperability with a standard Atari drive. You won't be able to read "standard" Atari disks.

 

The 5.25" HD drives rotate at 360 RPM instead of 300RPM, so the FDC has to use a data rate of 300kbps instead ot 250kbps to read/write DD disks.

 

You can't use a drive rotating at 360 RPM in the XF551. But most 1.2MB drives allow the rotational speed to be changed by the jumpers.