[Coco] CC-Five (was Re: Pseudo CoCo4???) (LONG)

[Joel Ewy]

Mark McDougall wrote:
> Joel Ewy wrote:
>
>   
>> Another thought is that if a new
>> CoCo integrated hardware that was available, but optional, on previous
>> CoCos, it could provide a larger (than current) installed user base for
>> those hardware features, which provides more motivation for programmers
>> to support them, while still retaining compatibility and not leaving
>> late adopters completely out in the cold.  
>>     
>
> Oh, I think it goes without saying that implementing as many pieces of 
> legacy add-on equipment as possible is a smart move, for the reasons you 
> point out, and then some. Obviously each would have to be considered on a 
> case-by-case basis, but some peripherals are going to be relatively 
> straight-forward without using too many FPGA resources. Others may best be 
> left as optional inclusions for software or "high-end" FPGA implementations.
>
> I'm not familiar with the technical specs of the Orchestra-90, but I'm 
> assuming it has some commonly-available (at the time) FM synthesizer chip in 
> it?!? 
Actually, it's much simpler than that, and now that I think about it,
probably not a good example in terms of FPGA implementation.  It's just
an 8-bit stereo audio out card with some ROM-based software.  The
schematic is included in the manual.  It consists essentially of a pair
of 8-bit latches, an address decoder made of a 13-input NAND and an
ls138, a 2764, a pair of DACs made from resistor networks, and an audio
output section made from a dual op-amp.  The analog portion won't go in
the FPGA in any case, and the rest is trivial.  Still, the audio quality
for digitized samples is much better than the CoCo's built-in audio, and
I think some people have already come up with some nice software for it,
which I haven't yet tried out.

I think the Speech/Sound Pak is a more sophisticated device, which I
don't have and don't know much about.  But including that in an enhanced
CoCo design would likely be valuable.  Also, why not put in a helper
processor or two to offload some of the I/O effort?  PIC compatible
cores are available.

What about including a controller that would look to the CoCo like a WD
FDC, but which actually works with CoCo disk images on removable flash
media, such as MMC or CF?  The hardware could include a way to select
from multiple disk images via an external 3.5" form factor control
panel, perhaps with a 3-digit 7-segment display, and also an extra
internal register that new software could use to do the same
programmatically.  This would work with existing DECB and all other
current software, but could provide a much more reliable, convenient,
and compact removable mass-storage system.  Also, if the embedded
microcontroller can manage its CoCo image files on a FAT filesystem on
the flash drive, it also becomes a very convenient way to transfer files
between the PC and CoCo.  If the microcontroller core was sufficiently
similar to a real controller, these things could also be made as
stand-alone units for older CoCos, and they'd remain compatible.
> Whether that would be considered as 'adequate' for the Coco 4/5, I 
> can't say. But there would also be the option of including, say, the Apple 
> IIe "Mocking Board", which uses two sound chips found in plenty of arcade 
> games of the era.
>
> Regards,
>