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)