[net.micro.6809] CoCo III, 1.8 Mhz, Slow Peripherals

baxter@milano.UUCP (10/23/86)

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?

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).

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.

An aside: was the typeahead problem with OS-9 ever solved (i.e.,
I can't typeahead while the disks are spinning?

Replies should be to the net.  If I get personal replies, I will
summarize.

Sorry about the bungled message preceding.
-- 
Ira Baxter            arpanet: baxter@mcc.com
MCC Corporation       usenet:  ut-sally!im4u!milano!baxter

rsanders@watdcsu.UUCP (Roger K. Sanderson P.Eng.) (10/24/86)

In article <2676@milano.UUCP> baxter@milano.UUCP writes:
>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?

The CPU chip in the CoCo 3 is a 68B09E,  the B part means it will run
at 2 mhz. Yes in theory the peripheral parts should also be B's to run
at that speed. (ie 68B21 68B50 ). In practice however, most parts will
run at the higher speed, but , they are not garanteed by the manufacturer
to run at that speed under all temperature extremes. For critical aplications
it would probably be best to slow down the I/O on the CoCo 3.

>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).

The CoCo 3 defaults to 0.8 mhz to be completely compatible with the CoCo 2.
This is in case software was timing via instruction loops, etc.
In a BASIC program you can POKE it into high speed mode. You should POKE it
back for disk I/O though. Reports are that disk I/O will work at fast speed
but it is not reliable.

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

I understand that OS9 Level II does run in fast mode, but slows down for
disk I/O ( the driver automatically does this )


>An aside: was the typeahead problem with OS-9 ever solved (i.e.,
>I can't typeahead while the disks are spinning?

You always could type ahead while the disks were spinning, it was when the
actual data was being transfered that the disk controller HALTS the CPU
on a byte by byte basis, also the interupts are turned off here of necessity.
Since you use the same disk controllers on a CoCo 3, this problem will still
exist. It however, should be MUCH better (if they wrote the code right )
since the keyboard now will generate an interupt! Even if the machine is
HALTed the interupt should get seviced eventually. We will have to wait
for Level II OS9 to find out.


>Ira Baxter            arpanet: baxter@mcc.com
>MCC Corporation       usenet:  ut-sally!im4u!milano!baxter


-- 

               Roger Sanderson
               Electrical Engineering Dept.
               University of Waterloo
	       Waterloo Ontario Canada
               N2L 5E6
   
               {decvax,allegra,ihnp4}!watmath!watdcsu!rsanders
   
 

knudsen@ihwpt.UUCP (mike knudsen) (10/24/86)

> 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."

ingoldsby@calgary.UUCP (10/26/86)

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

knudsen@ihwpt.UUCP (mike knudsen) (10/27/86)

> 
> 
> 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."

jimomura@lsuc.UUCP (10/28/86)

     Actually, typeahead wouldn't necessarily require a DMA.  A cheaper
solution might simply be a keyboard processor with a bit of onboard RAM.
Such dedicated processors can be done for little cost.  I have a computer
case with a smart keyboard which is controlled by a Z-80 and the whole thing
costed about $100.00 (Cdn).
-- 
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880