What is the lowest vertical refresh for your monitor, can it do much less than 50Hz? That's where my monitors (both analogue and digital ones) seem to die, around 49Hz or so.
@rogloh said:
What is the lowest vertical refresh for your monitor, can it do much less than 50Hz? That's where my monitors (both analogue and digital ones) seem to die, around 49Hz or so.
Yes, 49 to 61 Hz. But both the TV and newer monitor are happy with 24 to 75 Hz. Basically, displays that are newer than something like 2013 are much more flexible.
I have 2 Philips monitors at the university, both from 2020. One 27" which doesn't complain and displays 40 Hz, the second one, 24" doesn't like anything less than 49 Hz.
At home I have a cheap Chinese 15" TV and AOC 32" monitor which i didn't test for low vsync yet, but the TV doesn't like any non-standard VGA modes, including 50 Hz, while it accepts 50 Hz on HDMI input.
@pik33 said:
I have 2 Philips monitors at the university, both from 2020. One 27" which doesn't complain and displays 40 Hz, the second one, 24" doesn't like anything less than 49 Hz.
At home I have a cheap Chinese 15" TV and AOC 32" monitor which i didn't test for low vsync yet, but the TV doesn't like any non-standard VGA modes, including 50 Hz, while it accepts 50 Hz on HDMI input.
I'm only talking about behaviour with digital links, namely DVI and HDMI. Analogue VGA inputs are another story altogether.
Cool, ticked that one off. I've converted all my EDID code over to C so then I could make familiar use of standard C file handling in FlexC using an SD card.
All went pretty smoothly. Would still like to add date stamping from a RTC but don't have the hardware on hand so have used a separate text file to specific the date instead.
I've tested it wandering around the house plugging into the remaining other displays. Discovered that pin9 of VGA connector, like pin18 of HDMI connector, can activate the EDID of attached display without any display power. Although, like everything about EDID, this don't always work.
PS: Gotta say that that edid-decode program is pretty cool the way it handles many encodings of the EDID data dump.
EDIT: Attached the source code. What I do is put the compiled binary, named as _BOOT_P2.BIX, on a uSD card and also create a DATE.TXT with a date string that then is added to each dump within the report file. Pop the uSD card into the uSD slot of the Eval Board and connect the HDMI or VGA accessory - needs the SCL/SDA wires added as per above. And finally I plug in a USB battery pack to the AUX power input.
Good effort. Could be handy to know a little more about a monitor this way by just connecting it directly to a P2 system, although that benefit is obviously going to be completely dependent on how accurate and comprehensive the vendors are when providing the monitor's EDID details.
The interest is partly to see how varied they are ... and partly to check out supposedly more modern monitors to see what the date of each EDID actually is. Looking at you, Pik, and that fussy Philips monitor!
If the C is compatible with flexC you could port that EDID decoding code I posted earlier onto to the P2 as well and have the monitor display its own EDID information on screen for a full standalone thing. LOL, it could even use its own decoded information to build a timing for displaying of resulting data on screen, or just default to bog standard 60Hz VGA which is most likely going to be supported by the majority of monitors I would expect. Some P2 pins could be used as up/down switches to scroll through the data on screen if it takes up more than one screen's worth.
It did cross my mind, and I've not actually checked, but I'm quite happy with how it is. It's doing a little more than just the decoding too, not to mention the mode timings getting listed aren't a lot of use. They're just the boring known ones. The hex dump I collect can still be further decoded with that edid-decode program of course.
One extra feature is the report includes a list of all responding device/bus addresses outside of EDID spec. This is a spill-over of example code of Jon's even. All bar one display, so far, has had multiple address ping responses. The old Dell DVI monitor is on its own in that respect. And that includes a couple of even older VGA-only monitors as well. I still have one working CRT, and an LCD from someone else's discarded fluorescent backlighting days.
The older Spin code I had, at one stage, also dumped blocks from those other device/bus addresses but the C code doesn't have that as yet.
Okay, a stumble later ... updated to also dump a block from each non-EDID ping.
EDIT: That's weird, I still had a bunch of Spin hexadecimals in the source code. I'm surprised they didn't cause compile errors ... okay, bug fixed those now.
EDIT2: And one @ address-of too. Also didn't cause a compile error or even a bug for that matter. It's almost like Eric has allowed both syntaxes in FlexC.
Comments
What is the lowest vertical refresh for your monitor, can it do much less than 50Hz? That's where my monitors (both analogue and digital ones) seem to die, around 49Hz or so.
Yes, 49 to 61 Hz. But both the TV and newer monitor are happy with 24 to 75 Hz. Basically, displays that are newer than something like 2013 are much more flexible.
I have 2 Philips monitors at the university, both from 2020. One 27" which doesn't complain and displays 40 Hz, the second one, 24" doesn't like anything less than 49 Hz.
At home I have a cheap Chinese 15" TV and AOC 32" monitor which i didn't test for low vsync yet, but the TV doesn't like any non-standard VGA modes, including 50 Hz, while it accepts 50 Hz on HDMI input.
I'm only talking about behaviour with digital links, namely DVI and HDMI. Analogue VGA inputs are another story altogether.
This 24" Philips doesn't like <49 Hz on any input.
It'll be interesting to see its EDID data.
That's an idea. Package an Eval Board to extract EDID data from any HDMI display it's plugged into ...
For that you'd need to wire in the DDC wires and run some i2c over them. I think the breakout board exposes them on pads SDA and SCL.
Yup, that's how I've been gathering my data so far. I haven't used any Linux tools for extraction.
Just have to add Flash storage code now.
EDIT: Here's the EDID block read and emit to terminal - making use of Jonny Mac's low level I2C routines -
jm_i2c.spin2PUB emitblock( daddr, bnum ) : cksum | col, row longfill( @edid, 0, 128/4 ) ddc.start() ddc.write( $60 ) ddc.write( bnum >> 1 ) ddc.start() if not ddc.write( daddr & $fe ) if not ddc.write( (bnum & 1) << 7 ) ' 0 or 128 ddc.start() if not ddc.write( daddr | 1 ) ddc.rd_block( @edid, 128 ) ddc.stop() ser.str( string(" Device ") ) ser.hex( daddr, 2 ) ser.str( string(" Block ") ) ser.hex( bnum, 2 ) repeat row from 0 to 7 ser.nl() repeat col from 0 to 15 ser.tx(" ") ser.hex( edid[col + row*16], 2 ) cksum := 0 repeat col from 0 to 127 cksum += edid[col] cksum &= $ff ser.str( string(" Checksum ") ) ser.hex( cksum, 2 ) if cksum or bnum == 0 and (edid[0] or edid[1] <> $ff) ser.str( string(" failed",13,10) ) cksum := 1 else ser.str( string(" passed",13,10) )Cool, ticked that one off. I've converted all my EDID code over to C so then I could make familiar use of standard C file handling in FlexC using an SD card.
All went pretty smoothly. Would still like to add date stamping from a RTC but don't have the hardware on hand so have used a separate text file to specific the date instead.
I've tested it wandering around the house plugging into the remaining other displays. Discovered that pin9 of VGA connector, like pin18 of HDMI connector, can activate the EDID of attached display without any display power. Although, like everything about EDID, this don't always work.
PS: Gotta say that that
edid-decodeprogram is pretty cool the way it handles many encodings of the EDID data dump.EDIT: Attached the source code. What I do is put the compiled binary, named as
_BOOT_P2.BIX, on a uSD card and also create aDATE.TXTwith a date string that then is added to each dump within the report file. Pop the uSD card into the uSD slot of the Eval Board and connect the HDMI or VGA accessory - needs the SCL/SDA wires added as per above. And finally I plug in a USB battery pack to the AUX power input.[Updated source code attached]
Good effort. Could be handy to know a little more about a monitor this way by just connecting it directly to a P2 system, although that benefit is obviously going to be completely dependent on how accurate and comprehensive the vendors are when providing the monitor's EDID details.
Yeah, can't rely on the data.
The interest is partly to see how varied they are ... and partly to check out supposedly more modern monitors to see what the date of each EDID actually is. Looking at you, Pik, and that fussy Philips monitor!
Here's an update to the program using RCFAST for lower power running on battery.
[out-of-date, see below]
If the C is compatible with flexC you could port that EDID decoding code I posted earlier onto to the P2 as well and have the monitor display its own EDID information on screen for a full standalone thing. LOL, it could even use its own decoded information to build a timing for displaying of resulting data on screen, or just default to bog standard 60Hz VGA which is most likely going to be supported by the majority of monitors I would expect. Some P2 pins could be used as up/down switches to scroll through the data on screen if it takes up more than one screen's worth.
It did cross my mind, and I've not actually checked, but I'm quite happy with how it is. It's doing a little more than just the decoding too, not to mention the mode timings getting listed aren't a lot of use. They're just the boring known ones. The hex dump I collect can still be further decoded with that
edid-decodeprogram of course.One extra feature is the report includes a list of all responding device/bus addresses outside of EDID spec. This is a spill-over of example code of Jon's even. All bar one display, so far, has had multiple address ping responses. The old Dell DVI monitor is on its own in that respect. And that includes a couple of even older VGA-only monitors as well. I still have one working CRT, and an LCD from someone else's discarded fluorescent backlighting days.
The older Spin code I had, at one stage, also dumped blocks from those other device/bus addresses but the C code doesn't have that as yet.
Okay, a stumble later ... updated to also dump a block from each non-EDID ping.
EDIT: That's weird, I still had a bunch of Spin hexadecimals in the source code. I'm surprised they didn't cause compile errors ... okay, bug fixed those now.
EDIT2: And one
@address-of too. Also didn't cause a compile error or even a bug for that matter. It's almost like Eric has allowed both syntaxes in FlexC.