Michael J. Mahon wrote:
The 16bit units can surely handle the job, but then you're dealing with
QFP's and .5mm lead spacing which is a bit hobbyist unfriendly, but
still quite affordable.
It depends on what you think the pixel rate is and how much
computation the microcontroller is doing for each one. It's
hard to do any stimulus/response action without taking a few
instructions per pixel. Pretty soon, you're in >80MHz territory
for the microcontroller! I just heard the "cheap" and most of
the "simple" falling off the table... ;-)
Well, in terms of converting the digital RGB signal from an existing
RGB adapter to analog (with colour correction) a 40 MIP PIC should do
the job. These are around $5-$10, but as noted are in inconvenient
packaging.
You'd still need to add op-amps to buffer the analog output.
Actually, a very fine conversion could be done with a shift
register for the video bits running at 14MHz (easy) and then
using 12 bits (parallel out) from the shift register to address
a couple of fast SRAMs (or one if wide) to get at least 12
and as many as 15/16 bits out per 14MHz cycle.
These bits would go to D/A converters (or resistors) whose
output would be buffered by video op amps to drive 75 Ohm
RGB monitor loads. (Of course, sync from the Apple would
need to be added appropriately.)
The SRAM(s) would have to have logic around them to allow
them to be loaded at "boot" time with the desired color
table that could easily handle:
1) a beautiful NTSC composite simulation,
2) a sharp RGB rendering,
3) whatever other mode(s) you find interesting.
Sure you could do that, but that's a different problem - creating a new
RGB adapter from scratch vs modify the output of an existing one.
Of course the approach you outline could be used for the original case
as well, but wouldn't fit convenentily into a cable like my resistor
solution does now - too many parts.