Last edit for this document Mar 26 2005 Other Documents, links

Old computer newsgroups often discuss converting old CP/M systems from 8-inch and 5.25-inch floppy drives, to 3.5" drives and media. Issues raised included support of FM or single density; finding old media; choices of formats. I decided these discusssions were worth preserving, as these issues come up over and over. For more technical information on floppy drives and floppy disks, go to our technical page on floppy drives and media. For specific discussions about converting from 8-inch, 5.25 inch, and 3.5 inch, look for links on this section of that page. This document is currently: http://retrotechnology.com/herbs_stuff/8inch_cctech.txt The following is an edited version of a Feb 2005 discussion from the "cctech" and "cctalk" maillists of classiccmp, on the subject of 3.5" drives as replacement for 5.25" and 8-inch drives. This document (c) 2005 by Herb Johnson, content from and edits with the permission of those posting. The original posters retain their rights to their original posts. Randy McLaughlin is continuing this discussion, and starting an effort to create some standards, on a "disk drives" page on his Web site. Herb Johnson Index ------ Randy and Herb debate issues HD convenient but not compatible FM, SD is OK for HD drives 300 RPM vs 360 RPM Reading SD/DD disks, interpreting formats Randy and Herb debate issues ---------------------------- Summary of exchanges Feb 1-6th From: "Randy McLaughlin" (not indented with >>'s) >> From: "Herb Johnson" >> I think Randy is looking for a CONSENSUS, not a "quorum", but in any >> event he is looking for an acceptable standard. He did not get a lot of >> responses because 1) it's only been a few days, and 2) it's a >> technically tough subject, and 3) it's an OLD subject over the years. In fact I am hoping to put togather a quorum, I want a select group of technically minded people to come together and have their own opinions and ideas. CP/M on 3.5" drives exist. 3.5" HD media has technical issues that are unique to it. If we can get a quorum then a consensus can be formed. > Randy suggested in his comp.os.cpm posts that it's basically OK to write > in single density FM format on 3.5" high-density (HD) media, as he says > the "flux changes in FM and MFM" are at the same rate. For the oldest > computers, FM is the ONLY format option you may have. I did not respond > to Randy's post. But I think the problem of that scheme for use at 3.5" > HD will be two-fold. First, the actual data rates of old single density > FM 8-inch FDC's are much slower than standard data rates for HD 3.5" > media; the same applies for the read/write electronics of the DRIVE. [Herb's note: this became a non-issue.] > Second, no "modern" computer which uses 3.5" 1.4M drives is likely > CAPABLE of reading an FM encoded (single density) data stream, except by > accident. This calls to mind a classic problem on IBM compatibles, > namely reading old 5.25" 360K SINGLE density diskettes (like Osborne > diskettes). The FDC chip and/or decoder does not "expect" an FM encoded > data stream. I agree that finding a PC that can handle FM is basically impossible for a new off the shelf system, which is why I keep an old PC that does handle FM. In this case it does not matter what drive and media is used if all you have is FM then 3.5" FM is accepatble While you won't be able to use it on most PC's that applies for any FM disk (3.5", 5.25", or 8"). Note I am not recomending anyone stop using 8" I just am recomending standardizing how we use 3.5" when we do use it. >> One personal note. This took a few hours to write. It takes time to make >> a good, technical "argument". It took time for me to complile all the >> info on my site, and time for THOSE people who wrote it to do their >> work. It does not take long to propose a popular idea, and it's fun; >> it's less popular (and more work) to say "here's why it may not happen". > [So,] Randy will have to wait for more than a few days to build > whatever "consensus" or "quorum" or "select group" will construct his > standards. And, a standard, or now standardS PLURAL (FM and MFM) will > take some time and technical care to construct and VERIFY. Already, it's > clear there would have to be at least two standards: one for > single-density/FM only systems, one for double density. Oh, those older > systems may need a single sided standard too... I appreciate your comments, I agree that no standard is in site and may never be agreed upon by enough people. I also agree we need Amardeep and other to pipe in. I expect a large base to fight using 3.5" media but I find that 3.5" media is so much easier to deal with on a variety of levels. - Randy McLaughlin > "Easy" does not make it possible. And explaining the technical limits is > not "fighting". But there are other reasons not to put 3.5" drives on > the oldest systems. One "reason" is more of a preference: to run systems > with all original hardware, including the original 8-inch disks. Another > reason, which I mentioned previously, is to make sure that your system's > disks can be read and written by ANOTHER IDENTICAL system of the same > brand and model. (You may get an offer of software from another owner of > your brand & model of system; too bad you can't read their disks...) > I think the problems of a set of "standards" for using 3.5" drives and > media fall into two categories. First, the technical limits of the > oldest systems. Already it appears that single density will need its own > standard - that's one example of technical limits. Reliability is a > technical issue also: if you use odd formats at odd data rates, you may > not get reliable results. Like, using HD disks at DD formats: it may > work, sort of. Second, the general issue of cross compatibility. When > you use new disks on old systems, you'll have "funny" formats that will > be very unique, to the point that NOBODY BUT YOU can read your disks. > Backups that can be read by only one computer are not backups, when that > computer dies. - Herb Johnson From: Herb Johnson Date: Feb 10? 2005 ... a classic issue of design differences, is the fact that HD and 80-track drives have heads which create thinner tracks. That's why a disk formattted for 40 tracks on an 80-track drive may be UNRELIABLE when read on a 40-track only drive. Thinner tracks means poor erase of old thick tracks; and less signal when the thin track is read by the "thick" head. What I've heard over the years about uses of HD drives and media for "earlier" formatting and controllers, suggests there may be problems at least in the long term, as well as in the short term. Specifics, when I come across them, I'll add to my site, and some of that information and discussion is already there. http://retrotechnology.com/herbs_stuff/drive.txt This is why I believe it is better to keep older systems with original drives and media whenever possible; or at least to make such drive changes that are CLOSEST to original drives and media. Old drives and old media are still available. New media and unused old stock are still available with some searching. USed stock, by my experience, is often in good shape if stored well and if bulk-erased. HOWEVER some of the oldest diskettes like 8-inch do fail or perform poorly - why is not clear to me. And old 8-inch drives can just wear out, or fail and destroy media. It's a bad feeling when a disk drive head SCRAPES UP A DISK to bare plastic. So the issue of replacment and upgrade is a reasonable one. - Herb Johnson HD convenient but not compatible ----------------------------------- Date: Sun, 06 Feb 2005 15:11:29 -0500 From: Herb Johnson I've recieved two comments to my [previous posts]. One [comment] suggested that 3.5" HD diskettes are convenient to find and buy. That may be true but 1) convenience does nothing if HD disks won't work; and 2) you can still find DD 3.5" diskettes for sale via the Web - just not at your local stores. Date: 10 Feb 2005 From: Herb Johnson A Google search for '3.5" 800K diskettes' provided many sources for unused old stock, and I think a few new stock. Prices ranged but some were quite low. But please note: I'm talking about whether HD media and drives will ACTUALLY WORK RELIABLY on the "non-modern" hardware I described. "Convenience" and "abundance" does not help if the disks don't work. As for buying DD 3.5" diskettes, I understand the issue, I sell such disks myself. But A Google search on 3.5" DSDD diskettes found a number of suppliers, here and now. In any event, people who use and maintain old hardware should not be surprised that there may be limits as to how far they can upgrade, yet maintain compatibility and reliability. Moving from 5.25" drives to 3.5" drives is less of an issue, almost all of those earlier systems supported double density (MFM). But not all, such as the original Osborne 1 with single density, singled sided 5.25 inch drives. There are still other issues with this change, but they can be mananged for the most part. A search of old comp.os.cpm archives will find prior discussions of all this. Some of those discussions are archived on my site as I noted, some data on drives and media are on my site. Date: Sun, 06 Feb 2005 02:12:00 -0600 From: Doc Shipley [It's] Not too bad [to find 3.5" DD media]. I troll ePay for them on and off, and have bought about 350 disks in the last year, averaging about $0.40 shipped. Tongue-in-cheek: I might argue that it's easier to find viable DD 3.5" media than viable HD media. All the new 3.5" floppies I've bought in the last couple of years have had an atrocious failure rate. All kidding aside, I don't see 3.5" HD floppies being "current" for much longer either. And since AOL started distributing CDs instead of floppies, the damn things are expensive. - Doc FM, SD is OK for HD drives -------------------------- Date: Sun, 6 Feb 2005 22:02:11 -0500 (EST) From: Dan Lanciani [Herb's note: Quotes of Dan Lanciani are as per his terms: quote: "Again, my permission extends only to complete unaltered copies of my comments. Anything else would have to be done on a case-by-case basis." end quote. I choose to leave his remarks unaltered.] |[Herb Johnson posted:] |Randy suggested in his comp.os.cpm posts that it's basically OK to write |in single density FM format on 3.5" high-density (HD) media, as he says |the "flux changes in FM and MFM" are at the same rate. More than that, a correct FM data stream is indistinguishable from a correct MFM data stream that happens to have no clock bits since every other "data" bit is "1". |For the oldest |computers, FM is the ONLY format option you may have. I did not respond |to Randy's post. But I think the problem of that scheme for use at 3.5" |HD will be two-fold. First, the actual data rates of old single density |FM 8-inch FDC's are much slower than standard data rates for HD 3.5" |media; the same applies for the read/write electronics of the DRIVE. No, the rates are the same. |Second, no "modern" computer which uses 3.5" 1.4M drives is likely |CAPABLE of reading an FM encoded (single density) data stream, except by |accident. This is certainly a problem, at least for modern PC-class machines. Not only do recent integrated Intel floppy controllers fail to support FM mode but they have never had a read-track command which can sometimes be useful to read FM data in MFM mode. When I wanted to back up a large number of old single-density 5.25" disks that use a non-standard format I had to employ a machine with a WD1797, reading the FM tracks in MFM mode and bit-banging the result. Even that wasn't reliable because there is no way to guarantee that the controller exposes the correct bit slots without data marks. (The 1797 has a 16-bit shift register but passes every other bit to the host.) I had to add a circuit to double-up the pulses in the raw read data stream so that either alignment of the shift register would be correct. Of course, if the disks used a standard format I would have been able to read them in FM mode without all the trouble. In general, I don't think it is possible to come up with a scheme that is wire-compatible with old FM controllers yet produces media that can be read by "modern" PCs with MFM-only controllers that lack a read-track command. Given that, I suggest that a SS/SD/77/26/128 format on 3.5" disks might be the most useful standard for those wishing to replace physical 8" drives. Beyond that you might as well use whatever non-standard format you used on 8" disks. Keep in mind that tracks/heads/sectors/size is still not enough information to fully specify a CP/M disk format because vendors set up the extent mappings differently. I think I even came across a DS/DD/77/26/256 8" format that was logically incompatible with my system (until I DDT'ed the BIOS) even though I had believed that everyone was in agreement about this "base" double density mode.- Dan Lanciani Date: Mon, 7 Feb 2005 13:10:28 -0600 From: "Randy McLaughlin" Another problem with older systems that have mixed FM & MFM where the system tracks may have the 1st track always FM or both system tracks always FM. For me being able to read or write the disks from a PC would be a plus but not the only reason to go with 3.5". The biggest plus are for those people that need a drive, if they have no working 8" drive they are able to use their systems. Another point is that if they only have one 8" drive and are unsure about it using 3.5" drives can be useful for testing. SS/SD/77/26/128 format is non-standard for 3.5" drives which use 300 RPM. The slower RPM means that most formatting programs do not work. Teac states that for 128 byte FM sectors the track should be formatted with 32 sectors. Of course the disk can be formatted physically as DS/SD/80/32/128 and just ignore the second side and the last 6 sectors per disk. I highly recommend staying with physical formatting schemes published by the manufacturers of the drives. I agree that while I've only been talking about the physical formatting scheme that is simply a starting point, if no one can agree on how many bytes per sector there is no reason to go further. I personally slightly prefer two physical formats for 3.5" HD media: 32 128 byte FM sectors for each track and 18 512 byte MFM sectors. This just keeps the PC standard formatting for MFM and specifies the simplest formatting scheme for FM. I also recommend starting the data area on the third track even on systems like the Imsai Series Two's SuperIO that does not boot from the boot tracks. So far one person with an extremely strong CP/M back-ground has strongly suggested 1K sectors for MFM. - Randy Date: Wed, 9 Feb 2005 16:31:08 -0500 (EST) From: Dan Lanciani [Herb's note: Quotes of Dan Lanciani are as per his terms: quote: "Again, my permission extends only to complete unaltered copies of my comments. Anything else would have to be done on a case-by-case basis." end quote. I choose to leave his remarks unaltered.] |[Herb posted:] You mentioned HD media, the thread subject is "HD drives", so I thought |that was your proposed "standard". But it is more likely that 3.5" DD |media and drive settings will work for FM/single density/8-inch systems, |than HD. No, a DD 3.5" disk uses a 250kb/s data rate just like a 5.25" DD disk. An HD 3.5" disk uses a 500kb/s data rate just like all 8" disks. FM vs. MFM is transparent to the drive (except of course that MFM requires twice the temporal resolution of the flux transitions). An HD 3.5" disk will look to an 8" controller much like an 8" disk with tracks that are 1.2 times longer than normal. I expect it should be possible in many cases to use existing formatting software unchanged to produce 8" formats on 3.5" HD disks. It was suggested that formatters would fail in attempting to produce 77/26/128 FM formats on 3.5" HD drives, but I'd like to know the details of the failure modes. All the formatters that I'm familiar with check (if at all) only that the index hole does not come around again before they finish. They do not attempt to time the track to make sure that the index hole comes "soon enough." I suppose it would be possible that some formatters give up on padding too soon and note some sort of data underrun error. For such systems it might be easier to use 5.25" HD drives which exactly mirror 8" track timing. It might also be possible to get very unlucky and have garbage in the unwritten area of the track look like valid sector headers, but this could probably be avoided by bulk erasing before formatting. |I think the problems of a set of "standards" for using 3.5" drives and |media fall into two categories. First, the technical limits of the |oldest systems. Already it appears that single density will need its own |standard - that's one example of technical limits. Reliability is a |technical issue also: if you use odd formats at odd data rates, you may |not get reliable results. Like, using HD disks at DD formats: it may |work, sort of. Happily, there really are no "odd data rates" involved. Ignoring 2.88M drives and the special 300kb/s rate used to read 5.25" DD disks in HD drives without altering the motor speed, the controller technology has remained largely unchanged. The 250kb/s and 500kb/s rates persist from the earliest floppy controllers to the present. The drives themselves have no notion of the higher-level aspects of the format, so track layouts suggested by drive manufacturers can generally be taken as safe _maximums_ rather than required formats. |Second, the general issue of cross compatibility. When |you use new disks on old systems, you'll have "funny" formats that will |be very unique, to the point that NOBODY BUT YOU can read your disks. |Backups that can be read by only one computer are not backups, when that |computer dies. This is a problem, but it isn't really a function of the new drives. I've had problems with 8" MFM/77/26/256 formats being incompatible between CP/M systems even though I had thought that everybody agreed on the extent parameters for such disks. As far as I can tell, FM/77/26/128 is the only format for which most everybody agrees on the logical parameters (and I'll bet there are exceptions even to that). I would think that if you were going to do an 8" on 3.5" format, FM/77/26/128 would give you the best compatibility bang for the buck. In the meantime, I'm not about to dump my 8" drives. :) - Dan lanciani Date: Thu, 10 Feb 2005 12:59:05 +0100 From: Bjorn Vermo >> [Herb Johnson posted on 06 Feb:] Briefly, I posted that I doubt that >> a single density (FM) only system, such as the earliest CP/M systems, >> could read and write successfully AND reliably to HD diskettes. Also, I >> suggested the consequences of an old system owner who converted to this >> "standard" and then found that noone else could read his disks. In >> short, for the oldest of systems, there may be good reasons to continue >> to use old, but well-known, formats, drives and disk media. My Web site >> has pages of technical info and articles compiled from previous postings >> on these technical issues. I had some experiences of this when early HD disks arrived. They could not be reliably written on older drives because the write heads did not create a sufficiently strong magnetic field. Reading was never aproblem. Bulk erasing the HD disk, then formatting and writing was workable. While the old drives were not able to erase something written by a HD drive, they were able to write sufficiently strong bit patterns that they could be read reliably. Actually, I think the flux in the read heads would be just as strong as from an old diskette. Different brands of diskettes will behave differently. I was doing my tests back then with Rhone-Poulenc diskettes, which are probably not on the market anywhere today. Modern diskettes also seem to be of lower quality (and a lot cheaper) than in the eighties. -- BjA,rn 300 RPM vs 360 RPM ----------------- From: "Sellam Ismail" Sent: Sunday, February 06, 2005 12:21 PM >> Here's a suggestion... >> >> The Epson PX-8 had 3.5" drives available as an add-on. The PX-8 was of >> course a CP/M machine. Why don't you start by investigating what Epson >> did? Date: Sun, 6 Feb 2005 13:30:50 -0600 From: "Randy McLaughlin" This is an example of missing the primary assumption: The 3.5" drives used on most CP/M systems are driven at 250K MFM. 3.5" DD (125K FM, 250K MFM) are simple extensions of 5.25" 48tpi drives. I am concerned about 3.5" HD (250K FM, 500K MFM). This environment has the same transfer rate as standard 8" drives but it uses a different rotational speed. This means that you can not simply extend an existing format. One other point that keeps coming up is using 3.5" DD exclusively. Many systems can not handle this data rate other systems would require hardware modifications, another point is the storage would be 1/2 of HD. For systems running 250K FM (8" single density) would normally use 26 sectors at 360 RPM, 32 sectors at 300RPM. This is the issue, given that new formats are required. The question is can enough people agree what formats are appropriate? To me 250K FM would obviously be best to use 32 128 byte sectors even though going by Teacs FD235HF manual you can use 18 256 byte sectors or 10 512 byte sectors. This is the closest to the 8" SSSD standard available. - Randy Date: Sun, 6 Feb 2005 From: Fred Cisin NO. NO. NO. [to Sellam's suggestion of the Epson's PX-8 drive] A very good idea, except,... The Epson Geneva PX-8 disks that I have seen used a 67.5 tpi 3.5" drive (40 tracks per side). THOSE drives are VERY hard to find. "Normal" 3.5" drives are 135 tpi. YES, you could "double-track" it, and introduce track width problems. But, to use that otherwise good idea, consider other 3.5" CP/M formats: CPT Digitech HP CP/M (77 track, but still 135tpi) Jonos Mountain Side MSC-ICO NEC 8201 Netway 1500 Olivetti ETV-250 Sony M35 CP/M Sony SMC70 XScribe Reading SD/DD disks, interpreting formats ----------------------------------------- [note: Dave Dunfield describes his work on reading SD(FM) and DD (MFM) Osborne 1 and Cromemco CDOS 5.25" diskettes. His descriptions, and the replies from participants, suggest the kinds of problems you may have when you try to read "foreign" diskettes. - Herb Johnson] subject: Osborne-1 SD format From: Dave Dunfield Sat Feb 19 09:37:22 CST 2005 Hi Guys, Here's a question for the diskette gurus - I'm using my Osborne-1 Single-Density disks as an example, however I have observed this with a number of different machines. I would like to backup images of these disks - as they are soft- sector disks, I was hoping I could use Teledisk. Teledisk does read the disks, however it reports them as 5 sectors/ track, 1024 byte sectors, which doesn't seem right to me - if you attempt to recreate a disk from the image, it is unreadable. I thought Teledisk must be out to lunch, and not really likeing the fact that it uses an undocumented image format, I've been meaning to write my own replacement for some time. This morning I wrote some simple test routines to check it out, basically, just selecting the drive and data rate, recalibrating and seeking the head, and issuing the READ-ID command to identity the sectors and type on a track - with "pc" disks, the results are correct, and exactly what I expected. With my Osborne-1 single density disks, I can only read Id's with MDM (ie: DoubleDensity) selected, and ... I read 5 sectors/track (numbered 1-5), and they are reported as 1024 byte sectors - exactly the same results that TeleDisk has been reporting. In a HD drive, I must select a data rate of 300kbps, and in a DD drive I must select a data rate of 250kbps in order to be able to read them at all... I've tried several systems, two of which have 37C65 controllers with the dual (9.6 & 16Mhz) crystals, which are believed to properly support single-density operation. Can anyone tell me what is going on? Can anyone confirm the actual diskette format of an Osborne-1 single-density diskette? Why do they "appear" to read at [M]FM 1024 byte sectors (with correct 1-5 sector numbers/ordering)? Regards, Dave subject: Osborne-1 SD format from: Dave Dunfield date: Sun Feb 20 10:08:09 CST 2005 "fred" posted: >It would appear that your "single density" Osborne diskette is >really a "double density" Osborne diskette. > >But there are a few other possibilities. I have seen quite a few >single sided format diskettes that were reformatted from other >double sided formats, leaving a readily readable different format >on the back side. Hi Fred, Thanks for the info - It's interesting that a DD O1 disk would match what I am seeing - I grabbed this disk from the faceplate bin of my single-density O1, and I'm pretty sure that it was last formatted on that machine - however evidence would suggest that I may be seeing a DD disk - so I'll double check that I got it out of the right Osborne (my other ones have the DD option), and that it does read on that machine... Perhaps I have been engaging in the persuit of an un- domesticated ornithoid! In the meantime, I have been looking at a Cromemco CDOS disk (5.25"), another disk that Teledisk cannot copy, and it is equally perplexing... This disk has track-0 at single-density (both sides) and the remainder of the disk in double-density. It reads fine in my System-3, and I *CAN* read all of the sectors from it on various PC's, however not reliably at all. They do always show correctly that they are single-density on track 0 and double- density on the remaining tracks (some PC's can't detect the single- density sectors at all), however repeated read-id's on a track fail to turn up all of the sector numbers, unless I let it go for a long time. Even 50 revolutions of the disk will not always turn up all the sector numbers (but they are there and will sometimes reveal themselves - often different sectors are better on different PC's). With a PC format disk, and most other DD disks, I can simply issue a "read id" with the wrong data type - this times out at the index hole after two revolutions, at which point I set the right data type and perform repeated "read id"s until I see the same id again - on most disks, this quite reliably gives me the sector interleave pattern on the track. With the Cromemco disk, this does not work, as often I won't see all of the sector id's until I have reissued the "read id" many times, often seeing some sectors 30-40 times before seeing one occurance of the "tough" sectors. Clearly even if I do eventually get all the sector Id's, I cannot determine what the interleave is at all..., not to mention that this makes the "analysis stage" a but lengthy. Repeated attempts to read all id's on a track will often/usually turn up different sectors (but not all of them in one go). Attempt to read these sectors will usually fail, but will sometimes work - again, very unreliable. Read-track appears to work, however I have not yet determined if it is simply "missing" some sectors or not - since I don't know the sector interleave, and read-track does not provide any information about the order in which it ecountered the sectors (read-track seems pretty useless on the 765 series). This most interesting about all this (at least to me) is that the symptoms occur on the double-density portion of the disk, as well as the fact that it is intermittant (ie: not a complete incompatibility) - Again, it looks like there might be something slightly non-standard about the CDOS disk format... (anyone know?) Regards, Dave from: Dave Dunfield date: Mon Feb 21 12:38:57 CST 2005 subject: Osborne-1 SD format It's interesting with the Cromemco CDOS disk - the DD area is formatted to 10 512 byte sectors/track, and in the DD(360k) drive, I can't read them at all - For this test, I pulled the actual Teac drive that I have been using on the System-3 (which reads it fine) - it looks like the PC controller has touble with the tightly spaced sectors. It (the DD drive) can however read all of the SD sectors in track-0 just fine! The HD drive reads the entire disk perfectly, EXCEPT for Sector-1 of Track-0 (the SD track) - it quite reliably refuses to read the first sector of the SD track. The remaining sectors of the SD track and all of the DD tracks read OK. So - I can read the entire disk, however I have to do it on two separate drives - Unless I can reliably resolve these problems, I think I will make an option in my disk imager to merge images read of different drives - In some cases (like this one), it may allow a complete image to be constructed where it otherwise might not be. The :-( for the day is that it appears that NONE of the PC controllers that I have will format a single-density track - I can recreate the DD tracks just fine (Even with 10 sectors/track), but so far no joy on formatting and writing that SD system track. Regards, Dave subject: Osborne-1 SD format from: Steve Thatcher Mon Feb 21 15:33:24 CST 2005 At 01:38 PM 02/21/2005, Dave Dunfield wrote: >... it looks like the PC controller has touble with the >tightly spaced sectors [of the Cromemco CDOS disk]. a technical note... This comment regarding tightly spaced sectors twinged my memory. Anything based on the 8272/765 (in other words, all normal PC [FDC chip] controllers) was not able to keep the "spacing" between sectors as small as the Intel [bit] slice [based floppy controller] board did. Even the 1793 series was not able to handle this. I had started work on a DD Intel ISIS controller back then and did a fair amount of research on this back issue. The only controller chip I found that was capable of doing both SD and Intel DD was a TI TMX99XX chip (the actual # escapes me at this time). The chip had very good control of the bytes between sectors and would have been able to handle the small spacing in the Intel DD format. Not that this helps Dave's problem, but I figured I would throw out the comment because it related in a way. best regards, Steve Thatcher Message: 5 Date: Mon, 21 Feb 2005 02:02:46 -0800 (PST) From: Mike Stein Subject: Cromemco CDOS format (was Osborne-1 SD format) A little more about Cromemco disk formats, from my limited knowledge: In case it isn't obvious, the reason for the "non-standard" format (was there a "standard" format in those days?) is to be able to read/write all four formats interchangeably. Track 0, side 0 is formatted to the lowest common denominator, SS/SD, so all systems can read it no matter what the format of the rest of the disk may be. At the end of sector 1 (78-7Fh) it finds the format information for that disk (5" or 8", single/double sided,single/double density, and CDOS or Cromix, conveniently in ASCII, e.g. SMDSDD=SMall (5 1/4", CS if it's Cromix) DS,DD. Then it can read/write the rest of the disk accordingly. Hard disks are handled similarly, although density is irrelevant: The system finds the hard disk id at the same offset as on the floppy, and the hard disk configuration (cylinders, surfaces, sectors per track, bytes per sector and location of the alternate track table) immediately preceding it; thus you can plug in any hard disk with a compatible interface and the system can read the geometry etc. off the disk by reading the first sector regardless of the disk layout, since no hard disk will have < 128 bytes in the first sector. mike Date: Mon, 21 Feb 2005 16:56:02 -0600 From: "Randy McLaughlin" Subject: Re: Cromemco CDOS format (was Osborne-1 SD format) Cromemco kept a text string in the first sector to specify what the disk format was. If it was missing it was assumed to be 8" SSSD. I was always disappointed that they used such a crude method. It is simple enough to determine what the format is. All they ended up doing was create disks with two different formats on one disk. I [should also] mention something very important about Cromemco systems: They are very very picky about disk rotational speed. I sent Gaby a shareware PC-DOS program I use (RPM), she posted it here: http://www.gaby.de/edownl.htm I use it for 3.5", 5.25", and 8" drives. It makes it a snap to adjust drives. - Randy Message: 8 Date: Mon, 21 Feb 2005 18:55:40 -0500 (EST) From: Dan Lanciani Subject: Re: Osborne-1 SD format |Dave Dunfield: |With a PC format disk, and most other DD disks, I can simply issue |a "read id" with the wrong data type - this times out at the index |hole after two revolutions, at which point I set the right data type |and perform repeated "read id"s until I see the same id again - on |most disks, this quite reliably gives me the sector interleave pattern |on the track. | |With the Cromemco disk, this does not work, as often I won't see all |of the sector id's until I have reissued the "read id" many times, |often seeing some sectors 30-40 times before seeing one occurance of |the "tough" sectors. Clearly even if I do eventually get all the |sector Id's, I cannot determine what the interleave is at all..., not |to mention that this makes the "analysis stage" a but lengthy. [Dan Lanciani:] Try adding an increasing small delay after the read id you use to synchronize with the index hole. | Yeah, I tried that earlier on with mixed results, and didn't seem to | really get anywhere - but I've cleaned up a few other things now, so |I'll revisit it. |(read-track seems |pretty useless on the 765 series). It is. Your best bet would be to get a 1797 family controller. |Believe me, I've thought of that - problem is that I want to be able to |send this to people to make disks - but it looks like the pee-cee controller |(or the design) is just not up to snuff, and all I see a people having |problems - single-density on a pc is very problematic. | |I've also toyed with the idea of building a very small embedded controller |with a 1797, few tracks worth of buffer storage, and a reasonably fast serial |link to the PC. This is basically what I am doing now to archive/restore North- |Star disks (which are hard-sectored), except that since the N* controller |is well defined, I can just put my code into any N* system (user supplied his |uart routines). | |(or if you wanted to be super-flexible, have just a DSP - but thats a tad more | software work than I feel like undertaking right now...) |It's interesting with the Cromemco CDOS disk - the DD area is formatted |to 10 512 byte sectors/track, and in the DD(360k) drive, I can't read |them at all - For this test, I pulled the actual Teac drive that I have |been using on the System-3 (which reads it fine) - it looks like the PC |controller has touble with the tightly spaced sectors. !Date: Mon, 21 Feb 2005 18:20:04 -0800 (PST) !From: mhscc@canada.com ! !mhscc@canada.com: Well, I've usually had no trouble copying files back and forth !PC<>CDOS using Uniform with various standard PC controllers !WD, Compaq, no-name). ! !Of course I can't format track 0 side 0 on the PC (although the !Compaticard might solve that problem) but if it's initially formatted !in CDOS, no problems. If you subsequently ask Uniform to format the !disk it skips track 0 side 0 and just formats the DS tracks. - mike [Dan Lanciani:] It has trouble with various kinds of back-to-back operations, but I wouldn't expect that to make the tracks totally unreadable. Something else is going on. Is it possible that the BIOS thinks you have an 80 track drive and is double-stepping? That would let you read track 0 but no other. |[Dave:] I'm not using BIOS at all - I'm communcating directly with the FDC and |DMA controller. It simply does not see Sector-1 on the SD track, almost |all the time! |It (the DD drive) can however read all of the SD sectors in track-0 |just fine! | |The HD drive reads the entire disk perfectly, EXCEPT for Sector-1 of |Track-0 (the SD track) - it quite reliably refuses to read the first |sector of the SD track. The remaining sectors of the SD track and all |of the DD tracks read OK. [dan:] Try covering the index hole cutout on the disk or otherwise blocking the drive's index sensor. The controller does not like to start a read too close to the index hole, but it will mostly work without any index pulses. (It won't format or timeout of course.) - Dan Lanciani |Interesting idea - I'll give that a try, at least it might shed some more |light on what exactly is going on. -Dave Dunfield Message: 9 Date: Mon, 21 Feb 2005 16:18:30 -0800 (PST) From: "Dwight K. Elvey" Subject: Re: Osborne-1 SD format Hi Steve As I recall, the M2FM also had a different sector header. Unless you could program the header format, just the spacing problem was only half the issue. Dwight Message: 18 Date: Mon, 21 Feb 2005 17:42:48 -0800 (PST) From: "Dwight K. Elvey" Subject: Re: Osborne-1 SD format Hi Dave Here is another idea. Most of these machines are designed to have multiple drives. One disconnects one of the drives and runs the wires to a simple board on the parallel port. That board has maybe 5 or 6 TTL's. All it does is pass serial data from the parallel port to the read data and possibly the read clock of the controller on the old computer. In the PC, you configure the port to be in the DMA mode so that it can do high speed transfers. The board has a simple clocking from a Xtal can oscillator. Things like single and double density are simply the bit stream information. This is all premade in the buffer that you are doint the DMA transfer from. I'm not saying I've worked out all the possible problems but I think it can be done. Things like the data rate for 5-1/4 and 8 inch can be jumper selects on the board or maybe even encoded in the data sent. Anyway, it needs more thought Dwight From: "Eric Smith" Subject: Re: Osborne-1 SD format Steve Thatcher wrote: >> all Intel did was to use the same basic 3270 format and double the number >> of sectors to make the OS changes easy. The gaps between real data did not >> get as big from SD to Intel's DD. Intel made more changes than that. In addition to the use of M2FM and and different gap sizes, the index mark, ID address mark, data mark, and deleted data mark don't match standard FM or MFM. The gap and PLO sync bytes are different as well. It's documented in the disk controller manuals. For instance, see pages 4-25 through 4-31 of the iSBC 202 manual: http://bitsavers.org/pdf/intel/iSBC/9800420A_SBC202hwRef_Sep77.pdf Or pages 1-4 through 1-11 of the Intellec Double Density Diskette Operating System Harndware Reference Manual: http://bitsavers.org/pdf/intel/MDS2/9800422_M2FMdskCtl_Jun79.pdf DEC, on the other hand, really did just subsitute a slightly modified MFM data field for the FM data field on their RX02 disk system. The details are in the RX02 Floppy Disk System Tecnical Manual, pages 1-10 through 1-14: http://www.chd.dyndns.org/rx02/ek-0rx02-tm-001.pdf Eric Message: 19 Date: Mon, 21 Feb 2005 18:10:56 -0800 (PST) From: "Dwight K. Elvey" Subject: Re: Osborne-1 SD format Hi Eric I'm almost sure that the headers of the sectors have something different in them as well. I recall looking at it and thinking that it was just something else that needed special handling. Dwight Message: 30 Date: Tue, 22 Feb 2005 06:34:14 -0500 (GMT-05:00) From: Steve Thatcher Subject: Intel DD format differences make that 3740 format... as for the marks, yes they are different and I don't recall that being a problem with the TI controller I was looking at (I have one of them, but my data sheet to go with it has been lost...). the headers (other than the ID address mark being different in value) contain the same number of bytes in the same order. Intel's format had 0 in the byte location (third byte) that said which side it was supposed to be (in other words side 0) and they had 0 in the location that defined the sector length (fifth byte - 1 for 128 byte sectors). Unless Intel did the CRC different, these should be the only differences. Eric, the gap and PLO sync bytes are in the DD system 34 format. They are not in the 3740 format that I was talking about. best regards, Steve Thatcher