[Coco] Multi-Processor 6809 Computer System

[John W. Linville]

On Tue, Apr 30, 2013 at 04:44:52PM -0400, Bill Gunshannon wrote:
> 
> > On Tue, Apr 30, 2013 at 11:44:44AM -0400, Bill Gunshannon wrote:
> >>
> >> > A muti-processor setup, if it could be made for the CoCo, wouldn't
> >> offer
> >> > any benefits unless code is written specifically to utilize this extra
> >> > processor... so I would have thought.
> >>
> >> In a well designed SMP system different tasks would run on different
> >> processors so there would certainly be a gain in performance.
> >
> > This is only true if you have multiple processes to run in the first
> > place, and if the tasks being run don't serialize due to any inherent
> > dependencies.
> 
> Aren't most of us running NitrOS9?  I always have the console and at
> least one remote terminal running on my RS232 PAK.  That's at least
> two right there.

I don't know about "most", but FWIW I generally don't.

Anyway, we could theorize over what workloads might benefit from
SMP versus faster UP setups.  But I was merely pointing-out that
simply adding processors would not necessarily lead to a faster box.
Yielding a box that was "faster" enough to be worth the design cost
is an even bigger doubt.

> >> > That's why I suggested the idea of a faster 6809 made from an FPGA
> >> that
> >> > maintained the timing required by the GIME chip for video
> >> syncronization.
> >>
> >> The faster processors paradigm does not necessarily scale as well as
> >> SMP and it can have bad effects on programs that rely on the speed of
> >> the CPU for timing.
> >
> > This would seem to be contrary to Amdahl's Law:
> >
> > 	http://en.wikipedia.org/wiki/Amdahl%27s_law
> >
> > 	http://www.youtube.com/watch?v=WdRiZEwBhsM
> >
> >> >
> >> > This would benafit ALL existing software... if it could be done.
> >>
> >> As would SMP.  All changes are done at the OS level applications need
> >> not even know they are running on a multi-processor machine.
> >
> > Not all software runs under OS-9.
> 
> Well, the only other option I was aware of people using was DECB which
> isn't an OS at all.  If you are looking at this for use with DECB games
> and BASIC, I see no advantage at all in multi-processors so go for the
> faster CPU.  But what I said about timeing still applies.

I'm not really interested in arguments about what constitutes an OS.
The point in this case is merely that the CoCo world is bigger than
OS-9, and that hiding an SMP implementation from applications is even
harder outside the OS-9 domain -- not that implementing SMP support
for an OS is particularly easy either...

> I have never been interstd in games and actually the only ones I have
> I was using as donors for their cartridge bodies, if I can find boards
> to put inside them as the ones they come with are not particularly
> re-usable.
> 
> >
> >> > Something along the lines of Sock Master's 4Mhz mod but reliable if
> >> > created with an FPGA to replace the stock 6809.
> >> >
> >> > Anyone with FPGA experience confirm this possibility?
> >> >
> >> > If possible, anyone in a position to try this? It could be the single
> >> > greatest expansion option for the CoCo3.
> >>
> >> I think the single greatest expansion option would be a plug in Video
> >> Cartridge with better graphics and the ability to connect to modern
> >> technology displays.
> >
> > Which would require new software to run any "better graphics" stuff --
> 
> Anything wer do requires new software.  Isn't that part of the fun?

> > software that will have more work to do in order to push that graphics
> > data around the screen.
> 
> Not necesarily.  You could use a graphics processor in the cartridge
> and move most of the actual graphics generation off the COCO entirely.
> Anything that improves on the original functionality of the COCO will
> require new hardware and/or new software.  But, again, isn't that why
> we are doing it?  An FPG implementation of the COCO would be a lot of
> horsepower to accomplish what the bare bones COCO does now.  And at a
> rather large cost.  If it adds any functionality it would require the
> same new software you complained about above and it would not be COCO
> compatable.

No complaints about software here.  Earlier you seemed to suggest
that SMP would speed-up everything for free.  When you suggested a
graphics update, I presumed that you had the same misconception there.

> I guess what needs to be done is for people to decide what they
> want and then let those capable of doing it who are itnerested
> head in those directions.

Sure, fine.  Even better would be for someone to show-up at
a CoCoFEST! with at least some of their fine ideas already
implemented... :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.