This page last updated Jan 06 2010.
Summary:: In June-July 2004 in the comp.os.cpm Usenet newsgroup, there were a number of discussions of Persci floppy drive adjustments, the Cromemco 16FDC floppy controller, and of Processor Technology Inc. (an early S-100 company which used the drives). The notes below are about the Persci drive portion of those discussions. Originally, this Web page contained all the discussions, but in Jan 2010 I moved the Processor Tech portions to this linked Web page; and I moved moved the Cromemco 16FDC portions to this linked Web page.
I've recieved permission from the correspondents to exerpt their posted correspondence. If I recieve private technical correspondence, I'll publish it here as well. I'll be glad to add links and make corrections to this document when requested. See Google.com or other archives, to access Usenet comp.os.cpm archives.
My thanks to the participants: Amardeep S Chana, Barry Watzman, Randy McLaughlin, Thomas "Todd" Fischer, Axel Berger. Thanks to Lee Felsenstein for his comments on Processor Tech; and additional work on the 16FDC done by Emil Sarlija, and discussion from Mike Stein.
If you don't know what "S-100" means (or means to me), start with my S-100 Web page. My email address is @ another page.- Herb Johnson.]
Amardeep S Chana:I finally got around to cleaning the heads and setting the jumpers on a dual 8" drive unit so it could be hooked up to my Z-2. The drives are Qume 842 DSDD units. As it turns out, much to my dismay, the [Cromemco] 16FDC 8" disk connector is wired for Persci disk drives and will not work properly with standard Shugart type drives without some board mods. Here is the list of connector pin functions of the 16FDC (standard Shugart function in parenthesis):
2 Side Select (Low Current/TG43) 4 DS3 (NC) 6 NC 8 NC 10 Seek Complete (Two Sided) 12 Restore (Disk Change) 14 Eject (Side Select) 16 NC (In Use) 18 DS4 (Head Load) 20 Index 22 Ready 24 Motor On 26 DS1 28 DS2 30 NC (DS3) 32 NC (DS4) 34 Direction 36 Step 38 Write Data 40 Write Gate 42 Track 00 44 Write Prot 46 Read Data 48 Sep Data 50 Sep Clock
I was able to get them to read single sided without mods since the Qume's were set up to use select instead of head load to pull in the solenoid. Double sided didn't work for obvious reasons. I'm pretty sure they won't record reliably on the inner tracks due to the write current not being reduced. Pin 12 is driven from both sides. The drive side is open collector but he 16FDC is using an 8T96 driver so the line really should be cut. There are no outputs for TG43 or Head Load. I think you might be able to use Motor On for Head Load but the 1793's TG43 output will have to be routed through a driver stage. I'm off to do some cuts and jumpers...
Barry Watzman: The 16FDC works just fine with dual Shugart SA-860's "as-is" with no modifications at all. I guess that I should add that I have not been using double-sided disks in the SA-860's, which might be an issue if I tried to use them. The SA-860, although a conventional separate drive, like the Persci supports a buffered, very fast seek and has a "seek complete" line (not sure which pin it's on).
Amardeep: Exactly as expected. If you tried more than two drives or double sided operation you'd be facing the same problems I did. In addition, tracks 44 to 76 are not being recorded at the correct write current due to the 16FDC's lack of a TG43 output. This might not manifest itself as an immediate problem. But at double density it becomes difficult to recover data when the bit shifts are amplified by the higher write current.
Barry Watzman: Later this summer, I will have at least one, possibly two, Processor Technology "SOL-20" and "Helios" combinations (I'm currently rebuilding a stash of Processor Technology equipment that I recently purchased). The SOLs will be (already are) tested and working, I'm not yet sure of the condition of the Helios' (Helii ??). The Helios box was just a very sexy Persci drive case & power supply. Since the Persci drive was indifferent to hard vs. soft sector, the Helios drive box can run CP/M as well as PTDOS if you use a different controller (the PT controller used for PTDOS was hard-sectored). Any controller that supported the Persci drive can be used, which is just about any Western Digital based controller at all (Tarbell, Cromemco, etc.).
Randy McLaughlin: Actually the jumpers for the Persci's included in the Helios were hugely different than the Persci's shipped by Cromemco. As memory serves the Helios version worked fine in a Cromemco but to use a "Cromemco" Persci in a Helios you had to re-jumper it. I no longer own a Persci but.. could you post the jumper settings for the Helios and maybe someone that has one of Cromemco's oak Persci's can do the same with theirs. Also as I remember Persci shipped the drives jumpered as in the Cromemco version when you bought direct. I still have my original Persci manual and a PDF of it is available on my Web site.
I only dealt with a couple of Helios systems. PT shipped the boot loader on cassette and I was never able to get the first one to boot (no help from PT either). I ended up putting a 4FDC on the first one. I had to translate RDOS to 8080 code and make my own CBIOS to support CP/M since getting CDOS to run on an 8080 was too big a job. Much later PT came out with different SOLOS ROMs to boot directly.
Barry Watzman: First, it seems from my experiments that the PT Persci (Helios) will not work with the Cromemco disk controllers. Drive select is all screwed up, the head won't load.
Now for some better news: Actually, the jumpers are present in the Persci documentation that I scanned and posted on Howard's site at: Harte's Web site. They are really, really burried, and really, really obscure, but they are there. You will find (in an obscure form that you won't obviously recognized even when looking right at it) on pages 37 through 54 of the document labeled "Logic and Schematics" (the page numbering is per the Acrobat PDF fi les, not the printed page numbers, if there are any). Each page is the "bill of materials" for a different configuration. There are a LOT of different configurations, and some configurations have two pages for use with "early" and "late" revisions of the Persci drive's main logic board. I believe that the "standard" configuration, which I called "-001", was used by Tarbell and Cromemco. The Helios used the "-007" configuration, I THINK; it was set up for 32-sector hard sector, but there were a lot of diff erences in how drive select was handled as well.
Also, FWIW, in the Tarbell manual on using the Tarbell SINGLE density drive with a Persci drive, there is a page devoted to the configuration of the Persci drive. That page, also, is in the material that I submitted to Howard's site, and can be found with the instructions for jumpering the controller for the Persci drive, towards the back of the Tarbell manual.
I have five [Persci drives] here right now that don't appear to be working and that I need to try and fix. Helios configuration (problem could be the PT controller board set, I have 4 of those). There is a PT Cassette tape program that testst the system and emulates all of the functions of the Persci exerciser. Someone is sending me a copy.
Randy McLaughlin: I remembered that there were lots of jumpering changes [to the Persci drives] and yes the Helios like the Altair is hard sectored. When I changed the jumpers I generally used wire-wrapping pins and wire-wrapping wire to make changing back easier. Obviously my memory wasn't perfect on re-jumpering the Helios drive (and the memory was only 30 years old).
Another thing to note is that the 277 as used in the Helios is only rated FM (single density). The 299 was the MFM (double denisity) version. I never had any errors running 277's double density (both Tarbell & Cromemco).
Thomas "Todd" Fischer: The Helios was single-density, hard sectored, and was available with either one or two Persci 270 drives. I don't believe that Lee Felsenstein ever specified or re-designed for the dual-density 277, or "quad-density" 299.
I, at an earlier time, had probably worked on more Persci's than anyone else, having them shipped to us at Fischer-Freitas in Oakland, CA from as far away as Australia. The Persci 270 was the single density, dual drive (in a single full-height form factor); the 277 was double density, and the 299 was dual drive, dual density.
It required a Persci 499 disk exercisor to align and test the drives. Scale lamps, rabbit hair head pads, voice coils, and glass positioning scales were the most common replacement parts. Persci was sold to another group in late 1980, with the result that parts became VERY expensive.
My wife Nancy and I bought out a portion of the Processor Technology inventory when they went bankrupt in 1981, primarily for the Helios/Persci inventory. The Persci had about 27 documented jumper configurations for various OEM applications. I disposed of my exerciser and documentation in 1989, so don't have any of my original notes and documentation. I still have two of the 277's available for anyone who has a keen interest. Both were working when last used, and they are jumpered for soft-sector, double density operation with the IMSAI disk controllers. This should be the same as Morrow Disk Jockey, CompuPro, and other similar controllers that used the Shugart 851-style interface.
I always related the Persci as a kind of exotic European sports car; incredibly fast for the short term, but prone to regular service and adjustment. An innovative, but unreliable and complicated design.
Randy McLaughlin:My experience is tiny compared to [Fischer's] but my experience says they are fast, I loved mine when I had one.
It was from memory that I stated that the 277 was rated for FM. After reading your post I opened my 16FDC manual (available on Howards site) and Cromemco recomended not using the 277 for MFM (page 61 of the 16FDC manual "Note that the PerSci Model 277 is not specified for for double density operation"). My Persci manual doesn't say anything about density at all. My experience with the 277 agrees with you in that I never had any problems with MFM.
I only dealt with two Helios systems, both came with 277's but the Helios controllers were FM. On one I ended up setting up the drive to work with a 4FDC. Both systems were a pain to get running. The PerSci drives worked fine.
I had trouble with PerSci drives mainly in getting them DOA. Once running they seemed to be fine. I had one customer destroy one himself when he moved without the cardboard restrainer (he though just putting a diskette in it would be the same).
Most drives come with a square piece of cardboard to protect the heads, the PerSci needs one with a "tongue" to hold the voice coil motor.
Personally I never touched a 270. [But] I definitely ran the 277 & 299's double density with no problems. I never remember seeing any docs from PerSci on what drives ran what densities. I never remember using a drive that didn't run MFM. Since the only things that I know of that should effect single vs. double density is on-board data separators and rotational speed variance I am not sure why anyone would claim a drive is single density only. In this case density is just a matter of encoding (we are not talking about changing TPI.
When Cromemco came out with the 16FDC's I got one very early and was heart broken when they said I should now turn around and buy and expensive 299. I never bought a 299 for myself I used my 277 from the beginning with no problems (luckily). I talked to Cromemco and they reiterated that I shouldn't use a 277 with the 16FDC, I ignored their advice.
Thomas "Todd" Fischer: [Regarding the drives, the specs were:]
Persci 270: dual drive, single density, single sided ONLY
Persci 277: (replacement for the 270): dual drive, double density,
single-sided
Persci 299: dual drive, double density, double sided, very expensive!
Drive density was/is primarily mandated by read/write and erase head precision (The Persci used a "tunnel" erase head (like most hard drives of the era). The 277 had an improved head design, but was otherwise similar in positioner and electronics, but not "identical". Other factors including media characteristics (with regard to magnetic properties) deal in as well. I've studied the mysteries of magnetics for 40 years... and still no visible results ;)
Randy McLaughlin: I am extremely interested in understanding this. As I understand it the only factor is flux density. The media has a granularity that defines the maximum flux density. FM and MFM use the same flux density, the difference is how the fluxes are encoded. FM uses half of the fluxes for clocking MFM doesn't.
As I understand it different head designs allow for energizing the iron particles from different heights and differnt speeds. On hard drives the head is able to fly much closer to the media and as such effects a smaller area which allows for a larger flux density,
I am not an expert in it but what little I know makes me wonder exactly how a drive could only handle FM and not MFM.
Barry Watzman:I don't know the answer to your question ("how a drive could only handle FM and not MFM"), but there are several examples. The Persci 270 was apparently not well suited to MFM, and the Calcomp 140 (used in the IMSAI original 8" system) was not supposed to do double density, but was replaced by the almost identical 142, which would do MFM. The differences were real. I was told that issues in the data channels (both the analog & digital parts) made some of the early designs unsuited for MFM.
Thomas "Todd" Fischer: I've always attributed (in my Neanderthal fashion) the limitation to rise time discrimination [to be] in the analogue sections of the drive which include the head, lead length and reactance, differential amplifier and detector circuitry, and one-shot rise time. I may have had an incorrect or overly simple approach to acceptance of the limitations, but always though of it as a bandwidth limitation due to the sum of the above influences. As head gap and coating thickness were able to be more closely and precisely controlled, performance increased. I saw (at the time) the Persci as [the] embodiment of hard drive technology ported onto the floppy drive platform.
Randy: As I stated in the past if the drive doesn't spin smoothly then FM would work when MFM does not. But this failure seems unlikely especially in a 270. As I said I never touched a 270 nor any other drive that only works FM. I may try and see if I can tell the difference in the above mentioned drive manuals. I am not disagreeing, I just can't grasp what the difference could be. As always it turns out that Todd was right about the 277 being rated double density (they specifiy the entire 270 series as double density)
[After reading the Persci manuals,] it turns out I have a good description of FM vs. MFM on my website (mirror of Howard's site) thanks to Barry Watzman. Under the PerSci manuals there is a small document called "Persci 270 277 double density". [On Howard's site it is at this link.] Please read it for yourselves but below is my interpretation of at least part of it.
It refers to the shape of the signals and explains that the difference in radius from Track 00 to 76 makes the signal shape different. As such the quality of the amplifier and converting to a digital signal can pick up false signals from "shoulder" peaks around the real data bit. FM [enoding] is better able to handle it since the clock bit creates a window for the "real" data bit and only the center of the window is looked at.
If there is a combination of poor quality electronics on the drive and a disk controller that looks at every data bit without noticing that the data bits are too close together to be real, you end up with errors for MFM. But that is an unequal test since the FM is only looking at the "real" data bits in a specific window and for MFM reasonable data bit windows must be ignored to have an error.
Axel Berger: [Randy's question is]" how a drive could only handle FM and not MFM" Isn't that a rather an easy one? FM gives you clock and data with every single bit and thus has no problem whatever with varying frequency from bit to bit. MFM (which could be called RLL 1.3, normal "RLL" is RLL 2.7, "ARLL" is RLL 3.9) requires the speed to be constant enough to distinguish between 3 and four time slices without flux change. This sounds a lot, but if you rember, that adjacent magnetic areas influence each other and lead to slight place shifts (-> vide precompensation) this may just be slightly outside the capability of some equipment.
Randy:[Again] a good technical description of the problems with MFM over FM originally from PerSci available at [the document I mentioned before]. It shows that it is not the rotational speed changes that causes the problem.
The problem comes is the circumference difference between track 00 and 76. That difference meant that the shape of the pulses from one track to another changes. The shoulders on the pulses can be misread as data, FM has a rigid structure where data is only looked for in specific windows. MFM also has a rigid structure but if the controller gets an extra pulse it may assume it is real data. This can be compensated for with better heads and better quality read amps. It can also be handled by looking for pulses when the pulses should be there and not when there should not be data.
The older drives usually had huge powerful motors that had no trouble turning smoothly.
As far as bit shift is concerned that was well known and understood, it effected all forms of magnetic "digital" (NRZ or NRZI) recording. The problem was that many controller manufacturers didn't do it right.
Barry Watzman:If there's a difference [between the 270 and the 277] it has to be in the heads [as the manuals and PC boards are the same]. From what I can tell, there is no documented difference between the 270 and 277 other than some options. I've examined the data sheets very carefully, and the manuals (which are, literally, the same) and I can't find ANY documented difference other than for some optional features that were available on the 277 but not the 270.
randy: Like you [Barry] so far I have not found out what the difference is between the 270, 272, 277. It may even be as simple as what options the drive was shipped with (data separator etc.), Shugart noted options with a dash followed by a number, how did PerSci show what options were included?
I pointed out [earlier] that one of the manuals to scanned and sent to Howard's site has a good (and fairly technical) description of the technical problems related to FM vs. MFM or M(2)FM. In short it was in the quality of the read amplifier (coupled with MFM controller that allows illegal timing of data bits).
The entire 270 series used the same frame & PCB's. It makes no sense to me that anyone would have multiple heads for the same PCB. I would expect the electronics to be different for different technology heads. The same goes for the motors. The only thing that makes sense to me is that different model numbers referered to different options.
Thomas "Todd" Fischer: Don't believe everything you see in documents. Not everything was DOCUMENTED! I spent two days at the Persci facility in early 1977 to resolve DOA problems that IMSAI Manufacturing was having. At that time, the 270 manual was a separate document. When Persci started using an improved read/write head assembly and corrected some borderline design values in the head read/write circuitry, the drive was rev'ed and assigned the 277 model number to distinguish between the older single-density spec and the improved 277 which was DD certiified. I was never able to use a 270 circuit board in a 277, much as I would have liked to in diagnosing some multi-level problems at the time. The 270 and 277 boards, while similar, were NOT identical, despite the later schematics that are marked 270/277. I WAS able to use newer heads and the 277 circuit board in 270 drive assemblies, though.
Barry:Changing the topic slightly (but still dealing with Persci drives), I have 5 drives here that don't appear to be working (they are part of/in Helios systems). They do run and seek, but attempts to boot multiple suspected good PTDOS disks do nothing (the computer is a SOL-20 with a PT 48KRA memory board, the computer and memory are known good, and REV E (Rev. D and earlier Sols did not work with the Helios unless brought up to the Rev. E level). I have, in addition to the 5 drives, 4 Helios controller sets. All of this stuff is known to have been working at one time (a decade ago).
Anyone have any suggestions? I do not have the PT Cassette-based Helios Diagnostic software at this time (although Bob Stek was going to dupe the cassette and send it to me). PT also had a program that totally emulated the Persci "exerciser" on the Helios controller, I'm not sure if that was on the Disk System Diagnostic CASSETTE, or on the PTDOS disk, or separate in a "service personnel only" release.
What is the alignment procedure for a Persci like? I do have an alignment disk and a scope, and even the documentation, but I've never been through it on a Persci, is it difficult?
The drives all run and seek more or less ok. I also have a working system with a Cromemco 16FDC controller. It was designed for a Persci, but the drive configuration is all wrong for the Cromemco controller, and if I reconfigure the drives (quite a bit of work), they will be wrong for the Helios. Other things being equal, I'd like to get the Helios/PTDOS working first, although I might reconfigure one or more drives for a CP/M configuration later.
Comments from anyone who's worked on these?
Randy:PerSci's do not travel well and may have been damaged when they were shipped to you (Todd Fischer may be kind enough to pipe in and tell of shipping problems). If you intend to end up with one running on the 16FDC I would suggest picking a drive at random and changing it to what Cromemco wanted. I would put wire-wrapping pins through the holes and wire-wrapping wire to connect it (so it is easier to put back). Trying it on the 16FDC is easy especially if it is setup as C&D so that you can run CDOS on A and check out each side individually. If it doesn't work swap the PCB with a different frame and see if you can get one working. Once you have it working go through each frame trying the working PCB in each and find out which frames have problems.
Basically what I am saying is that the Helios system was a bitch to get running so instead get the PerSci's running on a Cromemco which is easy. You only need to change one PCB (unless it doesn't work with any frame where I'd start with another PCB).
Once you have a known good frame and assume you also have a good PCB setup for the Helios you have eliminated the drive as a problem.
Barry: Interestingly, I don't have CDOS (Cromemco's OS). What I have -- by pure luck -- is a totally unknown version of CP/M that runs on a Cromemco system.
I've been trying (without success, so far) to write a CP/M system for the Cromemco hardware (16FDC, ZPU, 3 16KZ's and another 16K memory card). I just found out this week that the Cromemco nnFDC controllers load their boot code at 80H, not 00H (a small little detail, well Duh!). Then I was playing around with 100+ random disks that I'd picked up over the years, I put one into the system, and, lo and behold, out of the blue, up comes "64K CP/M 2.2".
I have no idea who's CP/M it is (it's NOT Micah, however -- I have a Micah CP/M disk that does NOT work). There is a bios and boot code source on that disk, but I don't know if they "agree" with the system tracks (my guess is that they probably do, which I will investigate later). I THINK that they were written for a Persci (that was the standard for Cromemco 8" systems), and I'm using non-Persci 8" drives. There is a lot of stange seeking going on (which is understanable in such a case), and actual us e with 2 drives is "flakey" (again, understandable if it's a Persci bios working with non-Persci drives) (the drives are Shugart SA-860's, which just happen to be very late half-height 8" drives that do support "buffered seeks", just like the Persci, "seek complete" line and all). I don't have a full complement of utilities, in fact I don't even have a format program, but I also do have a working Zenith Z-100 system with a hard drive, 5" drives and 8" drives, so I am at a point where I can do more or less whatever I need, one way or another (some of it's very awkward and inconvenient, but it works).
I dragged out a Cromemco Bytesaver that has not been used in over 20 years this morning, and I was able to successfully burn new SOLOS proms for the SOLs. That the Bytesaver worked, after 20+ years, was in itself was a pleasant surprise. Another surprise is that almost all of my 25+ year old 8" diskettes are still good and readable and work. In fact, my success rate with them is well over 90%, in fact I think I've only had one bad one out of more than 100 disks. I have all of my 8" stuff backed up on my PC, and on CD-ROM and DVD media, but transfer between a modern PC and an S-100 CP/M system with the tools that I have, while possible (in both directions), is not convenient or easy.
Barry later reports, in private correspondence:I managed to get 3 of the 5 Persci drives working, and a 4th drive, maybe even the 5th drive (sold on E-Bay) might be repairable with as little as a complete alignment. I also got all 4 Helios controllers working.
There are two distinct Processor Technology software packages, "DISKT" and "SIMU". Diskt is a test program for the Helios system to be run as a precursor to running PTDOS. SIMU (full name "simu-cisor") is a software simulation of the Persci hardware exerciser using the Helios controller. While there is some overlap, SIMU is more Persci-specific and lower-level than DISKT. A copy of DISKT was located, Bob Stek had it, and I used it and was essential to getting any of the drives working. We have, so far, been unable to find a copy of SIMU. Both programs were distributed on SOL cassette tape, not on disks. If anyone has a copy of SIMU, please contact me .
We have built a tremendous archive of Processor Technology documentation at Howard Harte's site. If you combine this with the archive at Jim Battles site, you have most of the documentation that ever existed on the Processor Technology hardware, and also most of the documentation on Persci 270 series drives.
Editor's note: my site also has a lot of Processor Tech manuals.
There is one item missing that we would really like to find. About 3 years after PT went out of business, Stan Sokolow published "Encyclopedia Processor Technica", a 12-volume compendium of almost every technical document that existed covering Processor Technology products, including user group documents and internal engineering and support documents not previously available to the public. [We are talking something like 4,000 pages here]. So far, we have only been able to locate a copy of volume 9 (one of the two volumes devoted to the Helios disk system & Persci drives]. This has been scanned and is on Howard's site. We'd love to get the other volumes, but even Stan Sokolow, who was "Mr. Processor Technology" for the better part of a decade, who compiled/wrote the "EPT" and published it, no longer has a copy (forced to dispose of them and all of his PT hardware during a move). Again, if anyone has these, please contact me.
Aside from the documentation, I've been converting the Processor Tech cassette tape software to audio tracks on a CD. So far, this is all in "CDA" format (that is, true audio CDs). Experimental testing with converting these to MP3's has, surprisingly, been successful (to the amazement of quite a few people who insisted that it would not work). However, while the MP3's that I have made do work (on a "just and perfectly aligned" SOL, anyway), I'm very, very hesitant to use the MP3 format to any great degree. After all, if this stuff is lost, it's lost forever, and once you go to MP3, there is no way to recover the loss that the MP3 format imposes in exchange for the reduced file size.
So far, the Audio CD (one CD with 12 or 13 tracks and 2 to 3 dozen programs) is not posted anywhere, it's just something that I have myself (I did send a copy to Bob Stek, also). Posting it is a problem, because the "wave" file sizes are very large.
If anyone has copies of the missing items, I'd love to hear from them. [Editor's note: so would I - Herb Johnson] Also, I can make up DVDs or CDs (data and/or audio) with any or all of this documentation on it, for people who don't want to or can't download it (All of the stuff is several gigabytes, so while it's available for free download, there's argument for getting it on a single DVD). I won't do it for "free", but it will cost less than the set of 4 CDs being sold on E-Bay, and you will both a lot more, and a lot better quality.
Sincerely, Barry Watzman
[To see that discussion, go to this Web page on Processor Tech history. - Herb]
[To see that discussion, go to this Web page on Cromemco 16FDC. - Herb]
This document copyright © 2010 Herb Johnson. Other people may exercise copyright on their authored materials as they see fit.