| ??? 04/21/07 21:24 Read: times |
#137738 - I still think it's either/or and not both Responding to: ???'s previous message |
Phillip M Gallo said:
Not really interested in development of peer designs for IBM PC technologies MGA/CGA/EGA/VGA per se. I do like the wealth of commodity or PC castoff displays from small NTSC to VGA intended monitors. Yes, for onesies, they're a worth using rather than discarding. So from my purview, the conceptual leap from MGA/CGA to EGA/VGA was that of including Palette registers, allowing small bit depth frame buffer pixel values to index into wider bit depth color values. While the number of simultaneously colors was attributable to the smaller pixel value, the color displayed corresponded to the larger bit depth palette value.
The EGA to VGA leap being a digital to analog monitor interface. Having poked around on these quite a bit, I found that the NEC monitors, purported to be EGA types, that I had, were very much analog types. They had switches, etc, that suggested they had some digital or whatever features, but they used an analog interface and responded to variations in the voltage levels on the R, G, and B signals. I suppose they could have been thought of as digital in the sense that they had separate sync rather than composite. Matters not to me. I am just generating what displays i can on those monitors that come my way.
In practice, "VGA" has several timing standards attributable to various sync, pixel quantities and rates that a target monitor can be expected to conform to. CRT's with continuous time sweep capability, turned this into high art, LCD are a bit un-even in this regard due to the "quantized" nature of their pixel technology. As to doubt that a DS'4x0 can generate of 3.8us pulse at a 32kHz rate with enough precision to produce a stable well-framed display, i can only say a bit of calculation and lab work will indicate you, perhaps, underestimate the device. I've no doubt that it can generate the right sync timing, given an appropriate input oscillator, but it needs feed a RAMDAC, which has the shift register functon built in, in order to be complete. If it's got to have the support of an external FPGA, I'd say it's easier to do the job in the FPGA and omit the extra MCU. I see it as a one or the other situation. Those interested in Dr. Suding (thanks for the name correction) his site is:
The good doctor Oddly enough, this site doesn't show the boxes that most of us had. BTW, we generally referred to the system called the ByteMaster as the MasterByter, just as aside. Many of us had paid well in advance for those 32KB memory cards that were the last that DG produced, over a year in advance of their shipment. By the time they were ultimately shipped, some of us, myself included, had built a logical clone of the DG system, much simpler, however, that worked on boards much smaller and simpler than what DG had produced. By "we" I mean the Denver Area 6502 Users' Group. Most of us either switched to the smaller, simpler, hardware or bought an Apple-][. I never learned to like the Apple, though, and built my FDC and HDC for the DG clone which used a memory mapped video card rather than the port-mapped DG version. The software weenies in the group whipped up development tools that were pretty good for the time, including an assembler/editor package, a debugger, and one of the guy wrote a HLL compiler called XPL0 (ends in zero, not 'o') which he then used to write an OS called APEX. That stuff all worked pretty well. AFAIK, nobody every did much beyond that with the DG or DG clone hardware. RE |
