[Coco] Multi-Processor 6809 Computer System

Bill Gunshannon billg999 at cs.uofs.edu
Tue Apr 30 16:44:52 EDT 2013


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

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

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.

bill


>
> John
> --
> John W. Linville		Someday the world will need a hero, and you
> linville at tuxdriver.com			might be all we have.  Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


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





More information about the Coco mailing list