Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.sys.amiga Subject: Re: Rumours Message-ID: <2904@cbmvax.UUCP> Date: Sat, 5-Dec-87 21:57:16 EST Article-I.D.: cbmvax.2904 Posted: Sat Dec 5 21:57:16 1987 Date-Received: Fri, 11-Dec-87 04:42:56 EST References: <8712041550.AA01428@jade.berkeley.edu> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 29 In article <8712041550.AA01428@jade.berkeley.edu> U613042@HNYKUN11.BITNET (Olaf Seibert) writes: > > Our local user group spreaded some, quite unlikely, rumours in their > newsletter. I don't believe them, but if they are true, that would be > very nice. > > They wrote, that during some phase in the development of the trackdisk. > device, it was necessary to type in a hexdump, from paper, that was > developed on another kind of machine. During this re-typing, someone > made a typing error, which noone noted since everything works. > > The result of this single incorrect byte would be, that the disk speed > now is only one fifth of what it could (and should) be. Stuff and nonsense. The disk performance is slow because the disk organization inherited from Tripos wasn't designed for speed or even simplicity, rather they were exploring allocation, reliability and recoverability strategies. If you take out all the silly stuff, assume that diskettes (or hard drives) are inherently reliable and decide that simple allocation scheme may not be that bad, you get performance comperable to a PC or the like. BTW, all the code is in C, BCPL or Assembler, so what bugs exist are a little more involved than some bad hex errors. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)