Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!sri-unix!hplabs!tektronix!uw-beaver!ubc-vision!alberta!calgary!ingoldsby
From: ingoldsby@calgary.UUCP
Newsgroups: net.micro.6809
Subject: Re: CoCo III, 1.8 Mhz, Slow Peripherals
Message-ID: <474@vaxb.calgary.UUCP>
Date: Sat, 25-Oct-86 22:53:59 EST
Article-I.D.: vaxb.474
Posted: Sat Oct 25 22:53:59 1986
Date-Received: Mon, 27-Oct-86 01:36:55 EST
References: <2676@milano.UUCP> <1181@ihwpt.UUCP>
Organization: U. of Calgary, Calgary, Ab.
Lines: 36
Summary: Re: CoCo Disk Controller Speed



I'm a bit of a hardware hacker, and consider my self
of reasonable competence (having designed and
built computers from scratch).  Nothwithstanding, I've
never understood exactly why the disk controller can't
run at 1.8Mhz.  I can easily understand why things
might not work out during an actual disk access, but
why does a CoCo ( <> III ) hang when the high
speed poke is given if a disk controller is plugged
in (without disk I/O)??  I had always presumed that the ROMs inside it
were just too slow, and since the BASIC interpreter
loops through them quite frequently, the machine
was just going into neverland.  I saw a CoCo III
with a disk controller plugged in that did NOT
hang after the high speed poke.  Was this just
because the newer disk controllers (mine is an
ancient model for the CoCo I) have better ROMs?
Note that there is, in my opinion, a design
defect in the Coco I (and I presume II).  Although the
6809 and SAM  guarantee drive TTL levels on
the bus.  My experimentation has shown that the
drive current is barely marginal, and any additional
capacitance, load, etc. is enough to foul things
up.  They should have put bus drivers on the 
external port.  Is it possible that the CoCo III
has such drivers, and that this is what allows
it to use the disk controller at 1.8Mhz (or at
least the ROMS)?

Any help is appreciated, since this has baffled
me for a long time.

...!ihnp4!alberta!calgary!ingoldsby

Terry Ingoldsby