[Coco] Multi-Processor 6809 Computer System

[Bill Gunshannon]

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

All true.  But the origin of this thread was the suggestion that we
have a multi-processor 6809 box.  That would defintely mean something
running a real OS because otherwise you could never make use of it.

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

I would say impossible.

>                                -- not that implementing SMP support
> for an OS is particularly easy either...

Well, there are even options there.  SMP not being the only one.
The Amoeba model could also be used.  But the big thing about all
of this is that long before you got to that stage you would no
longer be working with a COCO.

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

Well, SMP would speed up anything that required more than one task,
like multi-tasking.  :-)

>                                              When you suggested a
> graphics update, I presumed that you had the same misconception there.

No, what I see in the graphics realm is really no different than
what we already have in the sound realm.  Someone said that having
a graphics processor would actually require more work and memory
for the CPU and thus would be a loss.  I would compare it to the
Speech & Sound Cartridge or the Stereo Music Cartridge.  Try doing
either of them in DECB and tell me they are not a major win.  I see
the same thing with a graphics cartridge.  Witht eh biggest win
being the ability to use modern monitors and get clear video.

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

A nice idea, but a verry limited audience.  I doubt that 10% of
the people interested in the COCO could afford or are likely to
make a trip for someting like that.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>