Persci floppy drives & Processor Tech

This page last updated Aug 11 2004.

Summary:: In June-July 2004 there was a number of discussions of Persci floppy drive adjustments, and of Processor Technology Inc. (an early S-100 company which used the drives) in the comp.os.cpm Usenet newsgroup or discussion group. The notes below are a summary of that discussion, responses by others, and exerpts from S-100 manuals and other documents on bus termination issues and products. I've also added comments on this page's contents, from Lee Felsenstein in August 2005.

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.

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.]

comp.os.cpm discussion of Persci drives and Processor Tech

 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

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.

Persci drive read/write density: FM, MFM

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.

Differences between Persci drives vs. documentation

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.

Persci drive diagnosis

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

Processor Tech's rise and demise:

Editor's notes: Processor Tech was an S-100 manufacturer in California from 1975 to about 1981. See Lee Felsenstein's comments about its history. Here's what was discussed in this comp.os.cpm thread. - Herb

Randy McLaughlin: I loved my SOL-20 and all of their software. I hated the Helios. I never understood some things about the Helios: No boot ROM; they shipped long after the 1771 dominated, yet they went hard-sectored; [and] they went with their own DOS long after CP/M was available (Lifeboat had a CP/M available). PTDOS was interesting but to my knowledge had no real advantage over CP/M.

Other than the SOL-20 I was always fairly underwhelmed by their hardware in general. I do agree with others that a better SOL would have been nice. As I remember the SOL-20 came out before the Z80 and when everyone thought 64 by 16 was fine for video out.

Imsai did deliver "a better SOL", I made a few myself using an Imsai VIO, and a Cromemco ZPU & 4FDC inside of a TEI chassis with a built in monitor.

Thomas "Todd" Fischer: I firmly beieve that the reliability failures, coupled with the high initial cost, sunk both Processor Tech with their Helios, as well as IMSAI with the VDP 80, both being cumbersome and heavy to ship, and prohibitedly expensive to have to deal with under warranty.

Barry Watzman:I'm not sure that the Persci was what sunk PT, but I think that the Helios and PTDOS did. If PT had used CP/M with a WD based controller, it would have made all of the difference in the world. The other thing that they needed to do was a "SOL-II", with a 4 MHz Z-80, 80x24 video and the system firmware and video in high memory (F000 instead of C000). It's interesting, PT did not go bankrupt, they simply shut down while still solvent.

Randy McLaughlin:How they released their software at the end was strange. They sold copies and rights of the original sources to individuals & groups non-exclusively.

I agree that the Helios/PTDOS was one of the big killers. The buzz at the time (dealers in Houston, TX) was that the extended basic that was supposed to go with the Helios was NorthStar basic and when they didn't come up with a controller & DOS NorthStar developed their own.

They were at least a year and a half behind promised scheduled deliver of the Helios. I am not sure of the sales of the SOL-20 at the end. The Helios controller was a piece of crap.

They had a large hard drive (I believe that it was 75mb) interfaced to a SOL-20 running PTDOS but never even advertised it as something they were going to sell.

Thomas "Todd" Fischer: I beg to differ... Marsh and Ingram moved their growing operation from Berkeley to Pleasanton (the former Johnson-Pacific Volkswagen distribution building) in about 1978-79 that rented for $30,000-$35,000 per month. Add to that oppulance the cost of utilities, additional overhead, and payroll. Suddenly, you have a MAJOR nut to crack before you can turn a profit.

In all honesty, not one of Lee Felsenstein's designs were exactly "production friendly". With major warranty and customer service loads, the camel wouldn't take another straw, even WITH compensation!

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. It was kind of sad and lonely when we left [the auction]. Just as the doors were about to be locked forever, Bob Marsh gave my wife Nancy a poster that she particularly liked that formerly adorned the wall of one of the offices. There wasn't even loose change to be found among the remainder.

Barry, in private correspondence: There is disagreement as to whether Processor Technology simply shut down while still solvent or was actually bankrupt. John Dvorak (who, like me, was active in the industry when this happened) just printed in a recent column (dealing with the concept of Microsoft simply shutting down and liquidating), and in that column he stated that PT was not bankrupt when it shut down. And that was my understanding from the time, also, and I have original contemporary (1979) published reports which state that they were solvent, although perhaps headed for insolvency, when they shut down. I know that Todd Fisher's account differs with this, so I'll just postulate that this is a somewhat open question. The fact that the assets were auctioned off does not, in and of itself, imply that they were bankrupt.

More comments and feedback

Lee Felsenstein and Processor Tech

> Herb,
>
> My periodic Google search on my name turned up the
> Retrotechnology page on "Persci Floppy Drives and
> Processor Tech" in which my name is mentioned a few
> times. I'd like to make a few clarifications.
>
> I was never a founder or a principal of Proc Tech (as
> we called it - sometimes I would call it "Proctology"
> when I answered the phone for them). Bob Marsh talked
> me into going in with him on the rental of a garage in
> industrial Berkeley in late 1974 so we could both set
> up our fledgling electronics firms. Mine was a
> sole-proprietorship doing contract electronic designs,
> mostly for former supervisors and co-workers laid off
> from Ampex Corporation (where I had worked 1968-1971).
>
> Bob was looking for a product to manufacture -
> especially one which could make use of center-cut
> walnut pieces he could get from a friend who had moved
> to Wisconsin and was in the wood business. He
> considered a digital clock but his attention was soon
> drawn to the Altair in January of 1975. He convinced
> me to drive him to the first meeting of the Homebrew
> Computer Club in March. Soon Processor Technology
> Corporation was born, but I was an outsider who
> contracted to them to do design and documentation
> jobs.
> My major works for them were the VDM-1 and the Sol-20.
> Unfortunately, I was not allowed to do the PC board
> layout for the VDM-1, and it went to a totally
> inexperienced guy as his first job. It shows. I would
> hate to have to defend that piece of work, which was
> laid out without a pencil preliminary layout and has a
> ribbon cable conducting the data bus across the board
> as an admission of failure. I could have done it much
> better.
>
> And of course, my contract included a royalty, which
> was the best money I ever made. Not the most, but the
> least encumbered.
>
> Still, at one point in 1976 I was asked, entreated,
> nay required to come in and serve as acting interim
> engineering manager. Management thought that there
> were only a few tasks remaining to be done. I
> interviewed all the engineers and came back with a
> list of at least twenty major tasks. When Gary Ingram,
> the President and co-founder heard this he cringed and
> waved me away, shouting OK! OK!.
> It was at that time that the Helios design was being
> completed for manufacture. I deny any responsibility
> for that, the memory boards, or nearly anything. When
> I got free of that entanglement and the company moved
> to Pleasanton (Gary's home base) I would journey
> weeklyi down there from Berkeley to talk with them
> about new designs. Eventually I took on other
> contracts and when finally I asked them "what the hell
> do you guys want?" they replied, "we don't know, we
> were waiting to see what you came up with." During
> that time (several months in 1978) I could have done a
> lot - like a Z-80 Sol capable of CP/M, for example.
> Bob Marsh has told me that one of many stupid things
> Proc Tech did was to get adversarial with North Star
> and get into a lawsuit with them (over a disputed
> version of BASIC). He says now it's clear that they
> should have cooperated in integrating the North Star
> disc system into a new version of the Sol. Sigh.
>
> Proc Tech closed its doors in 1979, just before the
> National Computer Conference in New York. I know
> because I was there with my VDM-2 almost-working
> prototype looking for their booth, which never
> appeared. I have also heard stories recently that
> indicate that they closed down not out of necessity,
> but out of choice. I will not repeat those stories
> because they reflect well on nobody. It's over.
>
> Using the Persci disc drive was one of many small
> disasters that compounded to bring them to that point.
> I can't take responsibility for the design
> misdecisions - I had nothing to do with them. It was a
> clear case of amateur management and growth beyond the
> level which will tolerate such management.
>
> Of course, it's always tempting to wonder how I might
> have integrated the North Star controller onto the
> main Sol board and maybe included some of the VDM-2
> features (smooth scrolling, writeable font) in the
> design as well, using chips that were available at the
> time. That would have been a killer!
>
> Lee

This document copyright © 2005 Herb Johnson. Other people may exercise copyright on their authored materials as they see fit.