Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!udel!rochester!uhura.cc.rochester.edu!ub!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!lehi3b15!batman!halkoD
From: halkoD@batman.moravian.EDU (David Halko)
Newsgroups: comp.sys.m6809
Subject: Re: TC9
Summary: TC-9 Speculation
Message-ID: <2752@batman.moravian.EDU>
Date: 20 Feb 91 21:25:11 GMT
References: <22@sandv.UUCP> <2567@batman.moravian.EDU> <4996@mcrware.UUCP>
Organization: Moravian College, Bethlehem, PA
Lines: 68

In article <4996@mcrware.UUCP>, jejones@mcrware.UUCP (James Jones) writes:
> In article <2567@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes:
> >I'm a little disappointed with Frank on only a couple of points with the
> >TC9... I was hoping for more than 2MHz on that 6809 box... I was wishing
> >for 3MHz, but Oh Well.... that is about my only disappointment...
> 
> I'm disappointed by that, too.  That means that the only respect in
> which a TC09 as such will run OS-9 faster than a CoCo 3 is that some of
> the device drivers won't have to go through bogosity such as the CoCo
> high-res mouse adapter (but there are already ways to hook up a serial
> mouse to a CoCo 3) or the keyboard matrix scan. 
> 
> >If a 68K board was dropped in, existing OS9 would get a boost without the 
> >need for 68K OS9...
> 
> Has FHL written the software needed for that?

He should have... I would imagine routines requiring block moves on the 6809
would be the first thing to be replaced (instead of doing loops, pop through
a 68K instruction) and minor stuff like that. Not very difficult, just needs
to patch some video drivers, I would imagine....

> >That, my friend, is the key.. 6809 OS9 software is becoming available... GOOD
> >6809 RSDos software is becoming available monthly now... with 1Meg, packages
> >already written in 6809 assembler which will never be ported (like Studio
> >Works, Sound Trax, etc) will gain a little speed, double the memory, and
> >be clear winners...
> 
> How will non-OS-9 software gain speed? It's the software that will have
> to go through the I/O emulation rigamarole--each instruction that peeks
> and pokes at what are memory-mapped I/O addresses will be trapped and
> disassembled, and what the results would have been on a CoCo 3 figured
> out and emulated, so that, unless non-OS-9 software is converted, it
> will slow down when it does I/O, to some extent that I don't know, not
> having seen a running TC09.  

Programs, like StudioWorks, should have little or no problems since it
would need little modification to use the 8 bit D/A- it has the ability of
using an 8 bit D/A converter, now, as an add on pak. If the 1 Meg is
appealing enough (and he decides to purchase one for his CoCo3, soon) then 
I am sure the support for the 1 Meg would come almost immediately afterwards.
Since it handles the extra memory very similarly to the way the Disto
handles it (I assume), then there should be little compatability problem there,
also.

The extra CPU boost should make any program at least as fast as it was
originally. If the RSDos routines were merely patched to work properly,
with the new hardware, I don't see too much of a problem, except with
specific packages which use the bit banger, keyboard, and cassette port
(if even supported.)

> itself, and would have to be individually converted to avoid the I/O
> emulation, aside from a couple of routines like POLCAT--is FHL going to
> supply patches for all those applications, or will CoCo software houses
> sell two versions of everything?

I have seen the old AT Keyboards which were compatable with RSDos programs
before... they were very nice and worked well. I actually played with one
at an old RainbowFest... I am confident things will work fine.

> (I wonder just how fast non-OS-9 CoCo terminal programs will run, with 
> I/O emulation of the bit-banger pseudo-serial port.)

So do I... would be neat...
> 
> 	James Jones

	Dave Halko