XF551 compatibility question

[+bob1200xl]

The drive in an XF551 does spin 4% faster than other Atari drives, but they compensate for this by running the master clock 4% faster. Are there disks that will not load because of the rotation speed? Hard to believe any s/w could see the 4%... Lots of other problems, maybe - but, rotational speed?

 

Bob

 

 

 

 

I admit I never liked the XF551, but I can understand there is a strong matter of personal preferences and usage here.

 

The "PC standard" mechanism is a mixed blessing. It has some benefits, but is also brings to the XF551 an incompatibility issue that it is almost unsolvable. It is the different rotation speed. Many people would not care, I guess, this affects only some copy protected disks.

[31336haxx0r]

At a constant SIO speed of 19200 baud which equals 2400 byte/second, from the perspective of data transfer the XF's CPU doesn't need to worry if it the drive is spinning 288 or 300 rpm. Let's assume you have a DD disk with 18 sectors of 256 bytes each per track. That makes 4608 bytes per track. At 288 rpm, a whole track passes 4.8 times a second or needs 0.2083 seconds to pass the head once. That's equal to 22118.4 bytes per second. At 300 rpm the track passes the head 5 times a second, equaling 23040 bytes/second. Even at 288 rpm the SIO speed is more than 9 times slower than the disk speed.

[ijor]

The drive in an XF551 does spin 4% faster than other Atari drives, but they compensate for this by running the master clock 4% faster.

 

That's not enough. The main clock at 8.333 MHz (instead of the nominal 8 HMz) compensates only from the FDC point of view. It can't compensate from the the main computer point of view, which (obviously) still runs at the same old frequency.

 

Are there disks that will not load because of the rotation speed? Hard to believe any s/w could see the 4%... Lots of other problems, maybe - but, rotational speed?

 

Why do you think it's hard to believe? 4% is not that small, it is pretty significant. Of course that software can see the difference. A simple utility that measures RMP could easily tell the difference (see my reply below).

 

I agree that rotational speed is not the main compatibility issue of a stock XF551. Probably the differences in the firmware are much more relevant. But the firmware issue can (could) be easily (in relative terms) fixed. Rotational speed is way much harder.

 

At a constant SIO speed of 19200 baud which equals 2400 byte/second, from the perspective of data transfer the XF's CPU doesn't need to worry if it the drive is spinning 288 or 300 rpm... Even at 288 rpm the SIO speed is more than 9 times slower than the disk speed.

 

It doesn't matter how much slower the SIO speed is. It is not relevant to the issue.

 

I assume you are familiar with those utilities that measure drive's RPM speed, right?

Do you agree that those utilites can reliably report the difference between a 288 RPM and a 300 RPM drive?

Do you agree, then, that software could easily tell which kind of drive it is?

Do you agree, then, that it would be almost trivial to develop a software that would refuse to run on a 300 RPM drive?

 

That just proofs my point. As long as it is possible to intentionally code something that would detect certain hardware, it means that some software could (unintentionally) break with that hardware. Some time ago I elaborated on some copy protected disks that don't run on certain 1050 upgrades. The reason was a very minute timing difference in the firmware code. Way much smaller than the difference here.

 

Note that measuring RPM speed was just an example. There many other ways, without explicity measuring RPM, that could lead to code behaving differently depending (indirectly) on the drive RPM.

[+CharlieChaplin]

Well,

 

why is there an A8 FAQ if nobody ever reads it...?!? Alright, let`s quote a bit from subject 3.4.4 - What is the Atari XF551 disk drive...

 

" - Rotation rate: 300 RPM Virtually all other Atari-specific drives spin at 288 RPM. This results in rare compatibility issues. Specifically, these commercial disks do not load in, and can possibly be damaged (!) by the XF551:

 

- Flight Simulator II (subLOGIC)

- Blue Max (Synapse) (I have personally destroyed multiple Blue Max disks with the XF551 drive! -mc)

- Bank Street Writer (Broderbund). Conflicting reports about this one.

- Boulder Dash II (Databyte release?)

- the original Polish version of Inside (Spektra, 1990 release?) "

 

Hmm, back in the nineties I did have a Floppy 2000 drive, which a) does use Mitsubishi PC drives and b) does rotate with 300 RPM and c) has a Speedy upgrade. Even when the Speedy was disabled (drive was slow with 19,200 Baud) some copy-protected original disks did not work. Afaik, one of the two releases by Digital Integration either Fighter Pilot or Thomahawk did not work and a few others. Since the Speedy was disabled, I guess this had to do with the rotation speed (but I am not sure). If so, all disks that did not run on the Floppy 2000 -due to rotation speed- will also not work with an XF551 drive, since both work with 300 RPM...

 

-Andreas Koch.

[31336haxx0r]

What mechanisms are involved in the XF destroying certain disks?

[ijor]

What mechanisms are involved in the XF destroying certain disks?

 

That is, IMHO, an overstatement on the FAQ. There is some truth on that, but only some. See http://www.atariage....ost__p__2370728

 

Also, I'm not sure that FAQ list is accurate. It is known that some of those titles, indeed, fail to load on a XF551 drive. But I didn't check, and I I'm not sure anybody did, that the reason is indeed the faster RPM. It is very possible that some of them fail because of differences in the firmware behaviour.

Edited October 3, 2011 by ijor

[31336haxx0r]

Well, looks like it isn't the XF's fault after all, then (except for having 2 heads)?

[Bryan]

I think most protected games that break on the XF551 are using track alignment techniques. Basically, if the 1st sector you read is on one track and the 2nd sector you read is on another track, then you can use the elapsed time between the two reads to determine the relative skews of the tracks (of course, there needs to be time for a step-settle before you hit the 2nd sector). So, if sector 1 is at 0 deg. and sector 2 is also at 0 deg. then the time between them should be a multiple of 0.208sec. A 300RPM drive will instead have an elapsed time of 0.200sec (remember that even a poorly adjusted 1050 will generally fall between 285-292 RPM).

 

This is effective because most Atari drives have no true reference for track alignment while formatting (index hole detector) so even with custom firmware alignment from track to track cannot be guaranteed. The copier must have an index detector, and it must be able to write raw track data at an arbitrary position relative to the index pulse. This makes these time-based protections hard to defeat. It won't see the XF551 as a faster drive; It'll see the original disk as a copy with inaccurate track alignment.

 

EDIT: I wonder if a Happy 1050 would be a bit more effective with a real index pulse.

[+Larry]

I have a couple of "war stories" about good features of the XF551. I've had several disks, including some from CSS that just could not be read on several different "known good" 1050's. On at least some of those disks, the XF551 was the only drive that could read them. I presumed that the data separation of the WD 1772 was superior to the earlier systems (2793/95?), but it could have been several things. Score one for the XF551!

 

I really have not used any software-based Atari to PC transfer programs for many years. I don't count APE since it is hardware-based. But once upon a time, I frequently tried to use Charles Marslett's UTIL (and later MyUtil) to read/write DD disks back and forth to the Atari, especially when the PC XFormer was released. Formatting disks for this on a 1050 seldom worked, and IIRC, formatting an Atari disk on a PC was also difficult. But the XF551 with it's index hole formatting made a huge difference in the reliability of the transfer process. Of course, Happy's transfer worked well, and so did the CSS IBM Reader that was included with the XF Upgrade.

 

Anyway, some "pluses" I think.

 

-Larry

[ijor]

I think most protected games that break on the XF551 are using track alignment techniques.

 

Possibly. But protections that depend very strictly on timing would probably fail as well, even when they don't care about the track skew align.

 

And OTOH, not every skew align protection would fail. Probably the most (in)famous of this type of protection is the one present in earlier ECA releases, such as MULE. But they implemented the protection the right way in this sense. They first measure the actual RPM by reading the very same sector several times, and only then they compare the reading across skew aligned tracks. So in theory, it should work fine on a XF551. It still has other issues that makes it sometimes fail even on a stock 810 or 1050.

 

EDIT: I wonder if a Happy 1050 would be a bit more effective with a real index pulse.

 

Sure. No doubts that the presence of a physical index pulse is useful and it's one of the XF-551 good points. The bad thing is that it doesn't have a "soft" index. Ideally you should have both.

[fibrewire]

XF551 drives are fast and quiet. There are a couple of them on ebay right now...

[+kheller2]

Resurrecting an old thread. How does increasing the clock rate into the FDC (and thus overclocking it) adjust for the 300RPM speed [Not enough coffee yet to figure it out myself]? How did other 3rd party drive manufactures handle that? I'm asking because the 1053 used a 1MHz clock into the 2797 but connected to the standard (at that time) SA-400 interface.

[ijor]

How does increasing the clock rate into the FDC (and thus overclocking it) adjust for the 300RPM speed [Not enough coffee yet to figure it out myself]?

It achieves the same radial density. The disk rotates (approx) 4% faster than previous Atari drives. The FDC, as a consequence of the faster clock, writes also 4% faster, then the period for a full bit is (again, approx) 4% shorter. Ergo, during the time it takes to write a bit, the disk rotates by the same angle as an 810 or a 1050. This is just a consequence that the relation between the disk rotation and the FDC clock is the same in both drives.

 

Note again, as we discussed earlier in this thread, this obviously doesn't compensate everything, that is not possible.

 

How did other 3rd party drive manufactures handle that?

I'll let others answer this, not so familiar with 3rd party drives.

I'm asking because the 1053 used a 1MHz clock into the 2797 but connected to the standard (at that time) SA-400 interface.

AFAIK, that was just a prototype. If it would have been released like that it would have some incompatibilities, including a higher error rate when reading disks written by a 1050, especially those recorded at MFM.

[+kheller2]

It achieves the same radial density. The disk rotates (approx) 4% faster than previous Atari drives. The FDC, as a consequence of the faster clock, writes also 4% faster, then the period for a full bit is (again, approx) 4% shorter. Ergo, during the time it takes to write a bit, the disk rotates by the same angle as an 810 or a 1050. This is just a consequence that the relation between the disk rotation and the FDC clock is the same in both drives.

 

AFAIK, that was just a prototype. If it would have been released like that it would have some incompatibilities, including a higher error rate when reading disks written by a 1050, especially those recorded at MFM.

 

So shoving a 1.04MHz clock into the 2797 would accomplish the same feat?

[ijor]

So shoving a 1.04MHz clock into the 2797 would accomplish the same feat?

 

Mostly yes. But it's a little bit more complicated than the FDC on the XF-551. The XF-551 uses a 1772 FDC that has no analog logic. Both the PLL and the write pre compensation are fully digital and synchronous. So any change on the frequently automatically translates to both the PLL and the write precompensation. OTOH, the 2797 has some analog logic and also depends on a few external analog components that won't be automatically adjusted by changing the frequency. But considering that we are talking about a relatively small change, and if you would calibrate the external logic accordingly, you probably would have the same effect.

[+Nezgar]

I still wonder why Atari chose 288 RPM in the first place when 300 seemed to be standard already... Maybe something specific to CPU/controller timing in the 810?

[+kheller2]

I still wonder why Atari chose 288 RPM in the first place when 300 seemed to be standard already... Maybe something specific to CPU/controller timing in the 810?

I was wondering the same thing and figured it was some sort of reliability issue with FM encoding when the 810 was designed. I also didn’t think 300 was a standard until the SA400.

[ijor]

I still wonder why Atari chose 288 RPM in the first place when 300 seemed to be standard already... Maybe something specific to CPU/controller timing in the 810?

 

I am guessing the main reason was to be able to format 18 sectors comfortably without a hard index hole pulse. Without the index pulse you have to format with a considerable overlap between the start and the end of the format to allow for RPM variations. The overlap means less effective usable data. So a slower nominal RPM might have been conceived as a method to compensate for that ... Just a guess of course.