On Mar 1, 2018, at 20:40, Luke Kenneth Casson Leighton <l...@lkcl.net> wrote: > > On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur > <richard.wil...@gmail.com> wrote: > >> Luke, have you tested the D/A circuit on the micro-desktop board? > > yep it works great up to 1024x768. i haven't yet been able to get it > to sync at anything greater than that, because you have to manually > convert the signals into A20 timings... and of course if you can't > read the EDID data you don't know *exactly* what the settings are in > the first place for any given monitor. > > 1024x768, being a common VESA standard, has worked consistently on > every monitor i've tried.
So if we could read the EDID the driver would figure out the A20 timings? Does the A20 already have a graphics driver capable of that? (In which case the bit-banging VESA DDC driver becomes very important.) How much of this infrastructure already exists? I'm bringing my tools, where do we start building? I have a collection of VGA monitors with different aspect ratios and sizes (3 CRT and 3 LCD). I'd be happy to test resolutions above and below 1024x768. >> Only thing I would worry about is the hold time on the data lines. If >> the A20 sets up the data quickly (relative to the pixel time) and >> holds it until the next setup, we should be in good shape. > > sigh yeah i thought about that... using buffer ICs with a "hold", and > linking up the clock line to it.... never got round to it. i'd prefer > to just skip the entire circuit and use a TFP410 (or maybe it's a > TFP401a), or a Chrontel RGB/TTL to VGA converter IC. CH7036 i think > it is. Are you thinking of octal D flip-flops? I'll have to look up those datasheets. What do those chips offer over the flip-flops? How do the prices compare? […] > yyup. exactly. remember, you can't do more than one interface on > any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI > or eDP), that then means you have to have a conversion IC in-place on > the Card if a particular SoC doesn't *have* that interface... and many > of the lower-cost SoCs don't because they're not part of the MIPI or > DisplayPort cartel(s).... Yes, that's the awful thing about so many industry standards: you can't get the text without signing documents and paying a handsome price, you can't use them without paying royalties to the patent owners. > ... and even if you had LVDS, the cost on the other side (Housing > side) of having an LVDS-to-RGB/TTL converter is so high relative to > the cost of the LCD itself that companies would rebel and not bother > with the standard at all. > > so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by > patents *and* by being lowest-common-denominator, wins out on all > fronts. except for the fact that you need a 125mhz clock-rate for > 1920x1080@60fps, which is a bit... high. but hey. Will the A20 clock the RGBTTL interface that high? _______________________________________________ arm-netbook mailing list firstname.lastname@example.org http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk