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: <1181@ihwpt.UUCP>
Date: Fri, 24-Oct-86 12:52:27 EDT
Article-I.D.: ihwpt.1181
Posted: Fri Oct 24 12:52:27 1986
Date-Received: Sat, 25-Oct-86 06:01:06 EDT
References: <2676@milano.UUCP>
Organization: AT&T Bell Labs, Naperville, IL
Lines: 70

> Those of you having CoCo IIIs and some understanding of the hardware
> can do a great service for those of us who don't.  CoCo III promises
> compatibility of peripherals with CoCo II peripherals, presumably
> including floppy disk controllers and modem cards.  It also promises
> 1.8 Mhz operation.  Usually faster processors won't work with
> controllers designed for slower machines controllers (Motorola
> supplies different versions of it 6809 family for different clock
> rates); can someone explain why the CoCo III should be an exception?

It isn't, except that all the PIA and other chips INSIDE the III are
spec'ed for 1.8, so the speed-poke is OK as far as the box is concerned.
   Anything you plug into the side is another matter.  In my case,
the A-to-D converter chip in the CocoMax mouse pak won't hack the
extra speed (it's spec'ed at 1.26 MHz max), so the cursor really
jumps around.  Symphony 12 will probably play music one octave
higher (Walter -> Wendy mode) if it still works at all.
   Paks with their own crystals should be OK, if their bus
interface can hack it.  Most Coconuts already know which of their
stuff will tolerate high speeds.

> For BASIC, I suppose that the following strategem might work: run at
> 1.8Mhz until I/O is necessary, slow down to .8Mhz, do the I/O, speed
> back up again.  If this was done consistently, I don't understand the
> CoCo III is delivered running at .8Mhz as the default (excuse my
> ignorance if that's not the case... data on the CoCo III is really
> hard to find right now).

Yes, I've done that for years; run the half-fast speed poke till
you do some I/O, then speed back up.  Disk I/O was always flakey
under the speed poke, and of course cassette and RS232 were off.
   Yes, would be nice if BASIC automatically  switched to slow clock
during I/O, then back up.  However, for compatibility with 6 years of
peripherals, I can see why Tandy sets the old clock speed at powerup
(yes you are right).

No kidding data are hard to find ... keep those postings coming, folks!
And check out CompuServe, etc.
> Under OS-9, the strategem wouldn't work as well, especially if several
> devices were busy at once.  Reducing OS-9 to running at .8Mhz as the
> least common denominator would make a joke of the 1.8Mhz ability.
> Anybody sane would automatically WANT the 1.8Mhz as the default, so I
> presume that it is under OS-9... so there must be a different
> strategy.

Right again.  However, you don't really have I/O processes running
as randomly as you might think (see below).
You want default fast clock?  Put this in your STARTUP:
	debug
	. ffd9
	=0
	q
	
Conceivably, Level II, being specifically for the Coco-III, may
have its device drivers switch to low speed on entry and
restore on exit.  Of course, we can add that mod ourselves.

> An aside: was the typeahead problem with OS-9 ever solved (i.e.,
> I can't typeahead while the disks are spinning?
Nope.  Fixing this would require true DMA disk interface,
which would be terrific.
Because disk I/O locks out everything else,
multitasking is still a joke even under Level II (when it comes).
Thus your tasks can play the "slow to I/O" games as in BASIC.

"Third one's the charm" -- 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."