[Coco] What about the double speed upgrade?

[Joel Ewy]

Roger Merchberger wrote:
> Rumor has it that Joel Ewy may have mentioned these words:
>   
>> [snippage]
>>
>> <digression>...FPGA board...extra...like caches
>>     
> Nuthin' wrong with that...
>   
Didn't mean to imply there was!
>> extra CPU cores,
>>     
>
> I've always wanted to build a Multi-6809 board... just not smart enuf.
> This could be a "Multiprocessor CoCo for Dummies!" ;-)
>   
I've often thought that OS-9 would lend itself nicely to multiple
processors -- not for symmetric multiprocessing, but asymmetric.  Have
one processor do the I/O work and another run user programs.  On the
user processor, the file managers and device drivers would be stripped
down to little more than stubs that pass the real work along to the I/O
processor.  The biggest problem would likely be communication between
the two.
>> ... the fabled 256 color mode for the GIME
>>     
>
> IMHO, that would be pointless; here's why:
>
> 1) No actual software exists for that mode
> 2) there are now even higher color/resolution modes that are standard.
>     (SVGA, etc.)
>
> Wouldn't it be easier to ditch the 256-color idea and add a standard 
> VGA/SVGA controller on the FPGA?
>
>   
The System09 on Opencores.org does implement a (16-color?) display that
can drive a VGA monitor.  One reason to stick with something relatively
simple is just that -- to avoid unnecessary complexity.  Even a "Super
CoCo" should remain comparatively simple if it wants to retain its
CoCo-ness.  But of course, since nobody knows exactly what the 256-color
mode on the GIME was like (if it really exist[s|ed]) there's plenty of
room for a new interpretation.  It would make sense to make it similar
to the existing modes in some significant way, just to ease the
upgrading of existing source code.  It might make sense to make it
similar to MM/1 modes, as you hint at below.  That would promote porting
MM/1 programs.

But you're right that there's no reason to limit it to 256 colors.  What
about a true 12-bit display with 4096 real colors?  That certainly
wouldn't preclude getting tricky to fudge more.  It would take 460800
bytes at 640x400.  If you are computing with FPGAs, you can make JPEG
decoders (or compute-intensive portions thereof) in hardware, then
delete them and replace them with FPUs, or graphics blitters.
> By then, you're a lot closer into "MM/1" territory. ;-)
>
>   
Nuthin' wrong with that!  :)
> Laterz,
> Roger "Merch" Merchberger
>
> --
> Roger "Merch" Merchberger   | "Profile, don't speculate."
> SysAdmin, Iceberg Computers |     Daniel J. Bernstein
> zmerch at 30below.com          |
>