Talk:History of the floppy disk

Floppy disk internal diagram

File:Floppy disk internal diagram.svg
The basic internal components:
1. Write-protect tab
2. Hub
3. Shutter
4. Plastic housing
5. Paper ring
6. Magnetic disk
7. Disk sector.

File:Floppy disk internal diagram corrected.svg
The basic components:
1. Write-protect tab
2.Capacity indicator
3. Hub
4. Shutter
5. Plastic housing
6. Paper ring
7. Magnetic disk
8. Disk sector.

←The File:Floppy disk internal diagram.svg has the density-detect tab mislabeled as the write-protect tab. SalineBrain (talk) 22:19, 11 February 2010 (UTC)

It's not only labeled incorrectly, it's drawn incorrectly. The hole that #1 is pointing at clearly appears to be blocked - as if the write protect slide had been closed (although that should be at the upper left corner when looking at the bottom of a 3.5" floppy in that orientation. I'd take a shot at fixing it, but Gimp doesn't appear to edit SVGs... Rwessel (talk) 05:35, 12 February 2010 (UTC)

I can and have edited it in PaintShop Pro but I can't save into SVG - JPG, PNG, whatever, but not SVG Tom94022 (talk) 20:49, 12 February 2010 (UTC)

I found an online converter from PNG to SVG. What next - should I just go ahead and replace the image in the Commons, update the labels (limited to English) or is there a better way to update? Tom94022 (talk) 20:52, 12 February 2010 (UTC)

I'm pretty sure you really don't want to do that. An SVG is a vector graphics format, and converting it to a bitmap, editing that, and then converting it back will result in a really bad SVG. One of the features of an SVG is that they scale, since what it contains is drawing commands (in fact SVG is XML, so you can actually edit wit as text), rather than a bitmap. Converting a bitmap (like a PNG) to an SVG will likely result in something that displays, but will scale very badly. What needs to happen is someone needs to edit the SVG directly, or use an editor that explicitly understands vector graphics and keeps the file as such for the whole edit process - *not* like what GIMP or Paintshop Pro (presumably) do, which is render the SVG into a bitmap, and then let you edit that. Rwessel (talk) 00:29, 13 February 2010 (UTC)

Actually it looks pretty good in my browser :-). I'd upload a copy, but right now Wiki file upload seems to not be working. Tom94022 (talk) 05:02, 13 February 2010 (UTC)

So here it is, now what?→

Tom94022 (talk) 05:12, 13 February 2010 (UTC)

If you go to the image page, and scale each to "2000px" you'll see the differences pretty clearly. Anyway, it seems the original artist is no longer very active on Wikipedia (I was going to ask them to do the change). From reading some of their stuff, it seems Inkscape (http://www.inkscape.org/) is a useful open source editor for SVGs. I download a copy and it seems to let me poke at the SVG in vector format, but really haven't had time to get into it. I'm also unclear about the policy for editing a featured image, but there's been at least one edit of this image by a different user in the past. Rwessel (talk) 08:19, 13 February 2010 (UTC)

All i see is a little banding in the grey areas. I think I will link the article to the corrected figure while we figure out how to update the original. Maybe we don't have too - just put a warning on it. Tom94022 (talk) 22:18, 13 February 2010 (UTC)

---

There is nothing wrong with the current version of the original Wikimedia commons image (File:Floppy disk internal diagram.svg), which was last edited on 24 April 2011—Improved fine detailing; correct oxide coating colour; open shutter on second image to show where the disc is read; switched to a nominal 10 tracks instead of 11 and cleaned it up to use act. Here is the image as it looked in Feb. 2010[1]—the issues described above have been corrected. This image showing details of the 3.5 in. floppy internals is in the floppy disk article, and really belongs there, rather than in history of the floppy disk. Since the image is redundant here, and since the edit of 13:02, 30 November 2011 added yet another image to the article which had a side effect of making the internal diagram image stomp on the references text in Google Chrome widescreen window displays, I am deleting the image from this article. The "corrected" file adds a pointer to the write protect tab, but the image detail is not as accurate. Wbm1058 (talk) 05:41, 26 January 2012 (UTC) Wbm1058 (talk) 15:45, 26 January 2012 (UTC)

The image discussed here was added to the floppy disk article with this edit of 21:47, 8 October 2010. Wbm1058 (talk) 17:13, 26 January 2012 (UTC)

Dispute claims on provenance of writable control store

The 360/25 and the 360/85 had writable control store before the System/370, although only the 360/85 used semiconductor memory for it. Both the 370/155 and the 370/165 had read only storage. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 22 June 2010 (UTC)

So my footnote should have fixed the dispute. May I suggest rather than just putting disputes about you try and change the articles to make them better? Tom94022 (talk) 00:17, 22 June 2010 (UTC)

There's still a dispute; the 360/25 had a writable control store and both the 370/155 and 370/165 stored microcode in ROS.

I did change the article to make it better; you reverted my change. May I suggest that you do some research before reverting changes? Even the Functional Specifications would have told you that two out of the three initial System/370 processors used ROS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:38, 22 June 2010 (UTC)

I did not revert your change, I made further changes to make it clear that the FDD was developed for the S/370 product line. The term writable control store does not appear in the article so the M25 is irrelevant. The M155 and M165 are an interesting exception to the S/370 family usage of volatile read/write semiconductor for microcode so I can fix that with a minor word change. I am not the first editor to suggest you don't throw around dispute tags, don't shoot the messenger. Tom94022 (talk) 01:36, 22 June 2010 (UTC)

You didn't use undo to remove my change, but you did remove it. However, {{Disputed}} was the wrong tag to use; I should have used {{Disputed-section}}. IAC, your last change appears to answer my objection.

Did you deliberately drop the comma before so whenever the power was turned?

I tend to not use a lot of commas so if u want one there go ahead. Tom94022 (talk) 13:52, 22 June 2010 (UTC)

Also, do you have any problem with adding a footnote citing the models where that does not apply? If you have no problem with a footnote, would it be better to just mention the models, cite the functional specifications or cite a CE manual? Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:48, 22 June 2010 (UTC)

No objection (and you didn't have to ask). Tom94022 (talk) 13:52, 22 June 2010 (UTC)

Okay, I added a footnote just listing the models. I'll add the Functional Specifications manuals if someone believes that to be necessary; the CE manuals would probably be TMI. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:56, 22 June 2010 (UTC)

Citation for term ICPL?

The manuals that I have use the term Initial Micorprogram Load (IML); does anybody have a citation of ICPL being used? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:56, 22 June 2010 (UTC)

Its used in both Pugh, "IBM's 360 ..." and Daniel, "Magnetic Recording ...". BTW, Daniel makes the point that the intent was for all System 370 to use WCS, so the 155 and 165 really are anomalies. Tom94022 (talk) 01:32, 23 June 2010 (UTC)

ICPL vs. IML

This is a continuation of the above, based on a couple of recent edits. While ICPL seems to have a few uses, the Pugh reference in particular, most of the rest of the Google hits ("icpl microcode" yields only 1450 hits), that I checked seems to either be copying Pugh or the Wikipedia article. Googling "iml microcode" yields 200K hits. In addition, the term IML is still the one IBM uses. For example, here are S/370 (~1975), ESA (~1988), and zArch (current) P-of-O's, each using IML (there's an IMPL in the earliest), but no ICPLs. And "control program" is used repeatedly to mean "operating system":

http://bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf http://bitsavers.trailing-edge.com/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf

Also this early IBM "An Introduction to Microprogramming" uses IMPL:

http://bitsavers.trailing-edge.com/pdf/ibm/370/GF20-0385-0_An_Introduction_to_Microprogramming_Dec71.pdf

And the current "IBM zEnterprise EC12 Technical Guide" uses IML exclusively:

http://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf

As near as I can tell, ICPL is used, but fairly rarely, and IML is much more common. Rwessel (talk) 04:56, 8 April 2014 (UTC)

Google searches are not a particularly good basis for ranking. As near as I can tell at the time of the 370 announcement IBM described the feature as "reloadable control storage" so I tend to like "control program" and ICPL as opposed to "microcode" and "IMPL." So I made it consistent. Pugh of course had access to internal IBM documentation so that is one more reason to favor ICPL. But it could go the other way since IMPL and microcode are used in the S/370 135 and 145 manuals. Tom94022 (talk) 06:16, 8 April 2014 (UTC)

BTW, that's IMPL not IML Tom94022 (talk) 06:22, 8 April 2014 (UTC)

Yes, IBM called the microcode storage "control storage", but "control program" in IBMs mainframe usage has never meant the microcode, or the stuff loaded off the (microcode) floppy, but rather the OS, which was loaded during the IPL process, which happened after the IML. In fact an IPL (usually off a hard disk, but sometime off other media, but never from the microcode load floppy*) could happen many times after the IML process, which was necessary only when you powered the machine on (you could reboot - aka IPL - the OS many times thereafter without reloading the microcode). IMPL, FWIW, was used in early S/370 documentation, but was dropped in favor of IML before too long. In my copy of GA22-7000-5 (circa 1976 P-of-O) is was still IMPL, the -7 version of the same manual (circa 1981) changed to IML, with the comment "Note: the name IMPL controls was used in earlier descriptions." I don't have a -6 available to verify, but I know we were already calling it IML before 1980. While Pugh may have had access to internal IBM documents, AFAIK IBM never used the term ICPL in any externally available S/370 documents, rather using IM(P)L exclusively. Actually there is one exception: in a VSE message (0P54), referring to a I/O device (not the S/370) not having been fully brought up.

*Theoretically, you could have IPL'd off a 3540 diskette drive (and who knows, perhaps someone actually did that), but that was not where the microcode was loaded from, which was a floppy dedicated to just that purpose, and not available as a general use peripheral (which the 3540 was). Rwessel (talk) 08:10, 8 April 2014 (UTC)

I'm not sure that in the IBM world of the early 1970s that either CP only meant OS or that CP "never" meant microcode but I will research it. We have two reliable sources, both historians, with access to original sources who after research say ICPL; other people later say I(M)PL but I suggest they are not as reliable as the two historians. Personally my recollections from that time period favor ICPL as an IBM term. But maybe the solution is to drop all acronyms and just say what IBM said, something like, "... loading microcode into the the writeable control storage of soon to be announced their System/370 mainframes."

FWIW the first public availability of the FD was not in a S/370 mainframe but instead the 2835 Storage Control Unit for the 2305 Fixed Head Disk File. It maybe that ICPL comes from writable control storage usage in other than mainframes. IBM San Jose did both the FD and the many SCUs. Tom94022 (talk) 17:41, 9 April 2014 (UTC)

Floppy Disk Patent Dispute

I found this document which looks to be an excellent resource but I don't know when I'll have time to give it much attention so if anyone wants to take a look at it here is a link. It will download as a Word document and is an official government document published by United States International Trade Commission [2] David Condrey (talk) 08:57, 13 July 2014 (UTC)

Internal IBM 33FD Name "IGAR" Clarification

In Note 14:Oral History Panel on 8 inch Floppy Disk Drives., , Ed. Jim Porter, 2005 - pg 9 "IBM did introduce what they called the IGAR, the model 33FD, along with their 3740 data entry system."

The name IGAR was the IBM San Jose internal identification code for the newly invented (Patent US3846840 A) & developed ferrite (plus Barium Titanate Ceramic, aka BTC) R/W & tunnel erase transducer. Porter's recollection that IGAR refers to the 33FD drive is incorrect. The IGAR head was specifically invented and intended as a plug-compatible replacement for the original laminated Mu-Metal head in the 33FD (and prior 23FD) floppy disk drive. The name IGAR was discussed and decided by the co-inventors of the R/W head (William Childers, Karl Elser, & Phil Peterson) in Karl's office upon deciding to build a feasibility / proof of concept prototype.

The intended advantage of the invention was two-fold:

1. Dramatically reduce the IBM internal manufacturing costs of the then current Mu-Metal R/enwiki/w/tunnel erase transducer used in IBM's 23FD previously and the then currently planned shipment of the 33FD, from upwards of $300/R/W head to less than $20/R/W head. With the PC development IBM sold licenses to other manufacturers, principally in Japan & Taiwan, so that by April 1984 the head was selling in lot quantities of 1000 for $5 or $6 per unit (prices based on my recollection of vendor tables at the IEEE Magnetics Conference in Hamburg Germany).

2. Increase the extendibility of the R/W head's bit and track densities for future floppy disk drives at virtually no increase in the manufacturing cost /unit (due to ferrite/glass R/W gap's resistance to tribological erosion in direct contact with the floppy disk media, and the nearly infinitely sizing of the magnetic core widths).

The licensed "IGAR" patent was used by most, if not all major (and minor) floppy drive vendors in PC compatible computers providing a very low cost R/W disk drive, making the home computer (PC market) volumes possible in that time-frame. Do not confuse the R/W Head (transducer) with the suspension or arm assembly that carries the R/W head. The extremely small size of the IGAR head (by virtue of ferrite's magnetic properties) made it possible to package the these transducers in the subsequent 5.25" and 3.5" floppy drives on gimbeled suspensions (for double sided recording).

71.84.13.113 (talk) 06:46, 6 October 2014 (UTC) William W. Childers, co-inventor of the IGAR Head

Can you provide a source for the above? Rwessel (talk) 07:16, 6 October 2014 (UTC)

Note that Pugh in "IBM's 360 And Early 370 Systems" p.515 states, "..the first floppy disk for read-write operation, the Igar (IBM 33FD), shipped to customers beginning in 1973." Pugh (p.517) also noted that IBM started development of a R/W FDD under the code name Figaro and it was renamed Igar - fIGARo, without the fAT and oVERHEAD (p517). Pugh also details the many changes as the 23FD evolved into the 33FD without explicit mention of the head technologies of the above patent (P517-521). FWIW, most veterans of that era use "Igar" to describe the drive which no doubt included an "Igar head." Tom94022 (talk) 16:50, 6 October 2014 (UTC)

Early 3.5 inch FDD Differences

I reverted a paragraph "early" 3.5-inch FDDs based upon a 2002 article focused on Macintosh usage since a source dated 2002 is untimely with regard to early 1980 events and I know that the article's statement that Sony invented the Microfloppy is incorrect. The Microfloppy Industry Consortium (MIC) defined the "Microfloppy" and one of the changes required to the original Sony design was a self closing shutter. AFAIK the original Sony design did not require the shutter to be manually opened. I think most of what the 2002 article describes is just the differences between the original Sony design, used by very few, e.g. HP, and the design promulgated by the MIC and then adopted by everyone including Sony. I'm traveling so I won't have much to to research this until April so I'd appreciate any help from other editors and some forbearance until I get back to my source documents. Tom94022 (talk) 22:45, 1 March 2015 (UTC)

That's absolutely fair enough... I just remembered that I had used a kind of 3.5-inch diskette that shipped with an Apricot system I inherited (ca. 1994) that had been purchased in 1984 and it had been the only time I'd ever seen these unusual latching-shutter disks... I figured since there was no other mention of them in the various Wikipedia entries that they'd been overlooked... I don't believe I still have these examples (although mathematically the probability is non-zero) so I spent half an hour trying to find references and examples on the web. Certainly, the Apricot systems the disks came with were happy using non-latching disks bought in the early nineties, and didn't latch them in the open position themselves. I felt that this early, rarely seen version of the medium warranted a mention here, although I'm happy to accept your reversion. I would like to see it mentioned in some form though as it is an interesting curiosity. Happy to collaborate on this.Shalroth (talk) 20:42, 6 March 2015 (UTC)

Great, I agree that the article should have something about early variants. As soon as I get back to my files I will update this talk and perhaps the article. U might want to see what is available from the MIC and from ANSI sources. As I recall the Sony FDD was opposed by the American manufacturers who organized the MIC as a way to slow the Sony penetration of their then dominant 5.25 inch market. The MIC spec was then presented to ANSI (X3B6 as I recall) who adopted it forcing Sony to redesign to meet what became the defacto requirement. The shutter change was one of several required; as I recall the original Sony drive opened and close the shutter, it just wasn't spring loaded so if the drive failed to close or a user opened it in curiosity it remained open. Finding reliable sources will be a challenge - good hunting Tom94022 (talk) 02:07, 7 March 2015 (UTC)