Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!ihwpt!knudsen
From: knudsen@ihwpt.UUCP (mike knudsen)
Newsgroups: net.micro.6809
Subject: Re: CoCo III, 1.8 Mhz, Slow Peripherals
Message-ID: <1184@ihwpt.UUCP>
Date: Mon, 27-Oct-86 14:54:39 EST
Article-I.D.: ihwpt.1184
Posted: Mon Oct 27 14:54:39 1986
Date-Received: Tue, 28-Oct-86 02:23:01 EST
References: <2676@milano.UUCP> <1181@ihwpt.UUCP> <474@vaxb.calgary.UUCP>
Organization: AT&T Bell Labs, Naperville, IL
Lines: 68

> 
> 
> 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?

I'm a hardware pro with 4 years Coco experience, and I
agree with you that the speed-poke problem is probably
slow ROM reading from the controller.  However, the culprit
is most likely not the ROM itself, but rather the RC
lowpass filter circuit in the CTS* line from the Coco to
the external ROM cartridge.  This series-R shunt-C made
the square CTS* pulse look like the lower half of
a sine wave before I ripped it out.  Actually I think my
old disk controller ran old my Coco at speed poke before
I ripped out the above and a couple other "smog control" caps
on the E and Q lines -- but I was just lucky I guess.
Tandy's mask ROMs have always handle speed poke fine for me.

> 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)?
> 
> Terry Ingoldsby

Again, my bus always looked good on a 'scope, but
bus drivers would be nice, if only to provide some
protection for your big $$ chips in case of static,
inserting cart with juice on, etc.

I have had problems when Y-cabling three carts (non-ROM)
at once, tho.  I think the Shack wants us to use MuliPak
toaster for that sort of thing!

Of course, if you ever used DMA (as some hard disks are
said to do), even the address drivers would have to
be reversable (ls245s instead of ls244s), and a control
signal developed to reverse them.
Given the rockbottom price of the III, I doubt it has any
of this good stuff.

In 80 days I'll pop the lid on my III and see for sure...mike k
-- 
Mike J Knudsen    ...ihnp4!ihwpt!knudsen
Bell Labs (AT&T)   (312)-979-4132 (work)
Nobody pays for my opinions, which are mine alone.
"A mind is a terrible thing to waste, but the pay is good."