jer@peora.UUCP (J. Eric Roskos) (01/06/86)
In response to my comments on Apple's "Integrated Woz Machine" (IWM), stubbs@ncr-sd.UUCP writes: > According to several articles I read on the Mac, Steve Wozniak takes > credit for this, it saved the price of a disk controller, and allowed > different rotation speeds controlled by software depending on whether the > track being accessed was inside or outside. This was to equalize the > density of information.They called this technique the "Wos Machine". Well, I'd like to expand on my puzzlement about this a little. A lot of publicity and user-enthusiasm has been generated over the years as a result of the "simplicity" of Apple's floppy disk controllers. "Look at this Apple II disk card," people say, "it just has a couple of gates and a ROM on it! Why are the cards in machines like the IBM PC so complicated?" But this doesn't make that much sense to me. It has been my impression (though I have never seen any concrete evidence of it) that most of the VLSI floppy disk controllers you buy from people like Intel are really just these 1-chip microcomputers that have been programmed to work a floppy disk drive. In any case, they are dedicated processors that spend all their time generating the control signals for the floppy disk, so the CPU can work on other things. Now, it is fairly obvious that you can also do all that with timing loops on the CPU; you can even go so far as Sinclair did with their ZX-81, and even generate the video signals in the CPU, for example. But it's not a matter of "here this engineer has designed this new floppy disk controller, see, it only has 3 chips!" It's a matter of eliminating some of the parallelism in the machine. Thus you get the reduction in chip count at a (sometimes considerable) cost in terms of performance of the machine, because now your CPU has to sit spinning around in timing loops whenever you do disk I/O, whereas before you had a dedicated processor to do that. Furthermore, it may be that a fully general CPU can't execute as fast as the one in the disk controller, so you lose even more performance that way. That seems to be a large part of the speed problem with the Macintosh; when you use more intelligent disk drives with it, or use a RAM disk, you get a considerable performance improvement, which *seems* to be due to the elimination of the overhead of the CPU doing all the low-level I/O. The improvement seems disproportionate to a similar improvement made by changing from floppy disk to RAM disk on an IBM PC, for example. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 "Oh, is he your friend? Ask him his name!"
john@ektools.UUCP (John H. Hall) (01/10/86)
In article <1894@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > (discussion of Apple's IWM 'disk controller' that uses the CPU for > timing and control vs dedicated controllers such as in the IBM PC ) > >some of the parallelism in the machine. Thus you get the reduction in >chip count at a (sometimes considerable) cost in terms of performance of >the machine, because now your CPU has to sit spinning around in timing >loops whenever you do disk I/O, whereas before you had a dedicated >processor to do that. In a single-user, single-task environment, (such as the Apple II and the Mac) the ability to compute and do disk I/O concurrently is not nearly the big win it is in a multi-user, multi-tasking system. For a low-end system such as the Apple ][ it is entirely appropriate. >Furthermore, it may be that a fully general CPU >can't execute as fast as the one in the disk controller, so you lose even >more performance that way. I agree. I doubt IWM could handle the data rates from anything faster than a floppy. -- ------------------------------------------------------------------------- John Hall Supervisor, Software Tools Laboratory Product Software Engineering USPS: EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650 VOICE: 716 726-9345 UUCP: {allegra, seismo}!rochester!kodak!ektools!john ARPA: kodak!ektools!john@rochester.ARPA
ac4@pucc-j (Tom Putnam) (01/16/86)
In article <364@ektools.UUCP> {allegra,seismo}!rochester!kodak!ektools!john (John H. Hall) writes: > >In a single-user, single-task environment, (such as the Apple II and the >Mac) the ability to compute and do disk I/O concurrently is not nearly >the big win it is in a multi-user, multi-tasking system. For a low-end >system such as the Apple ][ it is entirely appropriate. > While I don't completely disagree with his point, I think people tend to forget that a single user on a "low-end" system may want to try to use more than one peripheral device at a time. Consider, for example, the terminal emulator which is trying to capture information to disk. If the system has an intelligent disk controller, DMA transfer, and interrupt driven communication, then it doesn't have to stop/suspend the (slow) communications I/O in order to rev up the (slow) disk and write a sector. DMA, interrrupts, and intelligent controllers are all available on well integrated chip sets... even the 4-year old IBM PCs and clones have them. The fact that low-end systems (particularly Apple ][) do not have these capabilities often means that quality software is not available to do functions that might require concurrent I/O. I think that's a shame. -- Tom Putnam, Manager of User Services Purdue University Computing Center ARPANET: ac4@asc.Purdue.EDU or ac4@purdue-asc.ARPA BITNET: PUTNAMT@PURCCVM CSNET: ac4@purdue-asc-tn USENET: ac4@pucc-j.UUCP USMAIL: Mathematical Sciences Bldg. West Lafayette, IN 47907 PHONE: 317/494-1787
ark@alice.UucP (Andrew Koenig) (01/18/86)
> >In a single-user, single-task environment, (such as the Apple II and the >Mac) the ability to compute and do disk I/O concurrently is not nearly >the big win it is in a multi-user, multi-tasking system. For a low-end >system such as the Apple ][ it is entirely appropriate. > Even a program that reads a file sequentially and does something to the data on it can benefit from the ability to overlap I/O and processing, as long as the run-time environment provides some kind of buffering.
dr@ski.UUCP (David Robins) (01/22/86)
> If the > system has an intelligent disk controller, DMA transfer, and interrupt > driven communication, then it doesn't have to stop/suspend the (slow) > communications I/O in order to rev up the (slow) disk and write a sector. > > DMA, interrrupts, and intelligent controllers are all available on well > integrated chip sets... even the 4-year old IBM PCs and clones have them. > The fact that low-end systems (particularly Apple ][) do not have these > capabilities often means that quality software is not available to do > functions that might require concurrent I/O. I think that's a shame. While the Apple is being used in scientific laboratories world-wide, I find the lack of concurrent disk I/O painful. I would like to be able to stream incoming data directly to disk, as is possible on the IBM PC. Instead, I have to use a RAM card as a psuedo-disk, stop collecting data for a few seconds, save the data as a file, and then continue. Since I collect 400 two-byte values per second, the RAM files up rather quickly. Except for this, the Apple is a good laboratory system! -- ==================================================================== David Robins, M.D. Smith-Kettlewell Institute of Visual Sciences 2232 Webster St; San Francisco CA 94115 415/561-1705 {ihnp4,qantel,dual}!ptsfa!ski!dr The opinions expressed herein do not reflect the opinion of the Institute!