mdj wrote:
Michael J. Mahon wrote:The problem is speed. The video needs to be translated at 3.58 megapixels per second (if you assume the 140 horizontal pixel model) or even faster if you want higher resolution. 14MHz would be my choice with a shift register running at the same rate. Most ROMs and microcontrollers are out of gas at those rates.Ah, you're right. The fastest 8 bit PICs run at 48Mhz and pull 12 MIPS, which is enough to handle colour modes, but will fall short of faithfully tracking the 14Mhz dot clock rate. 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... ;-) 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. -michael NadaNet networking for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."