Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
The pull request I made adds much finer control over the settings. And it updates the default setting values. I got those settings by adjusting my monitor until I liked it and then using the new 'p' serial command to print out the setting value indexes. Then I updated the Arduino script's default indexes. A cheap way to save the settings.
Next up. Have the Arduino save the settings itself.


Also @oshimai I got much better color and brightness with your EDID #3 than I do with the default one for this project. It's still not perfect though. I can't use the full width of the monitor and I can't use 1024x768. Even with those limitations I'm going to stick with that EDID until I get a better one. Thank you!
[automerge]1586690499[/automerge]
@oshimai where in the file system did you find the files containing the EDID for the iMac display?
 
The pull request I made adds much finer control over the settings. And it updates the default setting values. I got those settings by adjusting my monitor until I liked it and then using the new 'p' serial command to print out the setting value indexes. Then I updated the Arduino script's default indexes. A cheap way to save the settings.
Next up. Have the Arduino save the settings itself.


Also @oshimai I got much better color and brightness with your EDID #3 than I do with the default one for this project. It's still not perfect though. I can't use the full width of the monitor and I can't use 1024x768. Even with those limitations I'm going to stick with that EDID until I get a better one. Thank you!
[automerge]1586690499[/automerge]
@oshimai where in the file system did you find the files containing the EDID for the iMac display?


This is really good, great work!

The fact that your settings are different for every video source could be that we are missing a little something here and there in the code
or it could just be the fact that we're using the iMac CRT in a way that was never intended. Either way we're still doing a lot
and having fun.

What do you think about creating a number of presets sort of like on a car radio. We can save the setting for every
source we hook it into. 0 could be factory reset and so on?
 
  • Like
Reactions: anotherelise
Here's my "Factory Settings" i2c traffic. This is from the Mac OS 9 monitors control panel. Geometry section. In the bottom right corner of that screen there is a "Factory Settings" button.

g

A lot less data than I expected. Another interesting thing is that the values given for things like width/height are not values that I found when going through the full range of width/height settings during my earlier capture. So clearly the values I captured then aren't the only valid values.

And that reminds me of the video @rockyhill posted using the serial interface for the monitor settings. There were a few values that caused your monitor to black out. But all of those values work fine on mine. I dunno if it's that there are different CRT's in some of these iMac models and not all settings are valid for all models. Or maybe it's certain combinations of settings that are invalid and I haven't gotten the right combination of conflicting values yet.

I think I'm gonna get another IDC-20 breakout and more jumper wires so I can keep my sniffer and vga input setup intact. Like right now I want to try that new EDID data posted by @oshimai , but I'd have to rewire everything again first :(

I'm going to do another capture of the full range of values for each setting again. To see if I get different values this time.
[automerge]1586675052[/automerge]
@oshimai While you're looking through OS 9 monitor files over there: it'd be nice to get the ColorSync profile. I'd like to get that into a format that'll work in OS X and other OS's.
[automerge]1586675424[/automerge]
The number of values capture after restoring to factory defaults are way different than they are during my first capture. For example in that first capture I got 20 different width settings. This time I got over a hundred. I'm going to go through this again for all the settings. Restoring to factory defaults before each. And capture all these new values and update the Arduino sketch.
[automerge]1586675590[/automerge]
I think I see what's going on. The delta of the change for each setting is affected by the way I click the buttons in the control panel. clicking rapidly between the thinnest and thickest width settings gave me 20 values again. A quick click followed by a pause to let the change happen resulted in over 100 values.


This is really good, I think this is what a settings-save on the atmega chip should look like.
Here are the register offset names you posted with the values for these settings respectively

HORIZONTAL_POS @ 0xad
WIDTH @ 0x27
PINCUSHION @ 0xc4
VERTICAL_POS @ 0x3d
HEIGHT @ 0xe4
PARALLELOGRAM @ 0xc0
KEYSTONE @ 0xb4
ROTATION @ 0x46


This should be easy to save and load as single byte for each property but instead of having an actual value saved,
we can save the index for that value.
 
I'm in the middle of make a front end for the monitor controls in java only because I would like to only write it once and run it everywhere.
I know these days C# is platform independent but how does the serial library work across the different platforms?

I was able to draw my own images to mimic the panel but I'm trying to mimic 10.2 not OS9.
Not because I prefer 10.2 but because it's what I have.

That said, if you have something already or are planning on something soon, I would love to use your front end as long as it can
work on linux, specifically on the raspberry pi.

We might be going in two different directions in this case. The reason I want to use C# is so I can make a Win7 control panel icon for the iMac monitor settings. It'll be WinForms based so threre's no sane way it will run on anything else than Windows. :( C# itself will run on Linux with Mono but compatibility is hit or miss. The SerialPort class isn't reliable. Google for "If you must use .NET System.IO.Ports.SerialPort" if you're interested in the ugly details. Every time I post a link here my post ends up waiting for a moderator to approve it.

Your best bet for anything cross-platform will definitely be to write a small Java program.

@oshimai While you're looking through OS 9 monitor files over there: it'd be nice to get the ColorSync profile. I'd like to get that into a format that'll work in OS X and other OS's.

I've just turned the iMac back on with MacOS 9.0.4 and will take a look if there's anything interesting regarding color calibration. ResEdit is as far as I can dig at the moment. Anyone here able to make sense of POWER architecture assembly code? I could maybe remote in to work and run some binaries through IDA Pro.

(@moderators: Please don't ban me. If reversing classic MacOS binaries is not allowed to be discussed here I will speak no more of it. Just let me know. )

Also @oshimai I got much better color and brightness with your EDID #3 than I do with the default one for this project. It's still not perfect though. I can't use the full width of the monitor and I can't use 1024x768. Even with those limitations I'm going to stick with that EDID until I get a better one. Thank you!

@oshimai where in the file system did you find the files containing the EDID for the iMac display?

Here's how I did it:

- Plug in a USB drive to the iMac once OS9 is booted up and ready
- Have OS9 format it
- Drag USB drive into trash can to unmount it, then plug it into a OS X machine
- Go to www dot mac dot org/utilities/resedit/ (trying to bypass the URL moderation censor thing here, sorry) and put it on the USB drive
- Plug USB drive back into iMac
- Open ResEdit and have it open HD/System Folder/System Extensions/Apple Monitor Plug-Ins
- Open the "edid" resource table

I got three resource entries as posted before that I could inspect and copy/paste into SimpleText to save to the USB drive.
[automerge]1586713321[/automerge]
For the sake of completion all three of those edid hex dumps through edid-decode. Maybe someone googling for something contained in the code will stumple upon this post and share further details.

20005
Code:
root@devuan:~# edid-decode 20005.dat
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 52 03 01 01 01 01 01 06
version:         01 01
basic params:    28 26 1d 86 e8
chroma info:     01 c9 a0 57 49 98 27 12 48 4c
established:     3f ff 80
standard:        01 01 31 59 45 59 81 59 61 59 a9 4f 01 01 01 01
descriptor 1:    10 0e 80 c0 20 e0 1d 10 38 38 13 00 7c 22 11 00 00 1e
descriptor 2:    f9 15 20 f8 30 58 1f 20 20 40 13 00 7c 22 11 00 00 1e
descriptor 3:    00 00 00 fd 00 30 78 1e 5e ff 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 41 70 6c 56 69 73 69 6f 6e 38 35 30 0a
extensions:      00
checksum:        a4

Manufacturer: APP Model 352 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.714/0.286 V
Sync: Separate
Maximum image size: 38 cm x 29 cm
Gamma: 2.34
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  640x480@60Hz
  640x480@67Hz
  640x480@72Hz
  640x480@75Hz
  800x600@56Hz
  800x600@60Hz
  800x600@72Hz
  800x600@75Hz
  832x624@75Hz
  1280x768@87Hz
  1024x768@60Hz
  1024x768@70Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
  640x480@85Hz
  800x600@85Hz
  1280x960@85Hz
  1024x768@85Hz
  1600x1200@75Hz
Detailed mode: Clock 36.000 MHz, 380 mm x 290 mm
                640  696  752  832 hborder 0
                480  481  484  509 vborder 0
               +hsync +vsync
Detailed mode: Clock 56.250 MHz, 380 mm x 290 mm
                800  832  896 1048 hborder 0
                600  601  604  631 vborder 0
               +hsync +vsync
Monitor ranges (GTF): 48-120Hz V, 30-94kHz H, max dotclock 2550MHz
Monitor name: AplVision850
Checksum: 0xa4 (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#

20004

Code:
root@devuan:~# edid-decode 20004.dat
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 ee 02 01 01 01 01 01 01
version:         01 01
basic params:    28 20 18 86 e8
chroma info:     01 c9 a0 57 49 98 27 12 48 4c
established:     35 6b 80
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    10 0e 80 c0 20 e0 1d 10 38 38 13 00 7c 22 11 00 00 1e
descriptor 2:    10 0e 80 c0 20 e0 1d 10 38 38 13 00 7c 22 11 00 00 1e
descriptor 3:    00 00 00 fd 00 30 78 1e 53 ff 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 41 70 6c 56 69 73 69 6f 6e 37 35 30 20
extensions:      00
checksum:        a9

Manufacturer: APP Model 2ee Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.714/0.286 V
Sync: Separate
Maximum image size: 32 cm x 24 cm
Gamma: 2.34
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  640x480@60Hz
  640x480@67Hz
  640x480@75Hz
  800x600@60Hz
  800x600@75Hz
  832x624@75Hz
  1024x768@60Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
Detailed mode: Clock 36.000 MHz, 380 mm x 290 mm
                640  696  752  832 hborder 0
                480  481  484  509 vborder 0
               +hsync +vsync
Detailed mode: Clock 36.000 MHz, 380 mm x 290 mm
                640  696  752  832 hborder 0
                480  481  484  509 vborder 0
               +hsync +vsync
Monitor ranges (GTF): 48-120Hz V, 30-83kHz H, max dotclock 2550MHz
Checksum: 0xa9 (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#

20002

Code:
root@devuan:~# edid-decode 20002.dat
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 10 92 01 01 01 01 00 08
version:         01 01
basic params:    68 27 1d 86 e8
chroma info:     0d c9 a0 57 47 98 27 12 48 4c
established:     35 ef 80
standard:        31 59 45 59 61 59 81 80 81 99 a9 40 a9 4f a9 59
descriptor 1:    01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 03
descriptor 2:    01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 03
descriptor 3:    00 00 00 fd 00 30 78 1e 6b 17 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 53 74 75 64 69 6f 44 73 70 6c 79 32 31
extensions:      00
checksum:        0f

Manufacturer: APP Model 9210 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.7 V
Sync: Separate
Maximum image size: 39 cm x 29 cm
Gamma: 2.34
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  640x480@60Hz
  640x480@67Hz
  640x480@75Hz
  800x600@60Hz
  800x600@72Hz
  800x600@75Hz
  832x624@75Hz
  1024x768@60Hz
  1024x768@70Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
  640x480@85Hz
  800x600@85Hz
  1024x768@85Hz
  1280x1024@60Hz
  1280x1024@85Hz
  1600x1200@60Hz
  1600x1200@75Hz
  1600x1200@85Hz
Detailed mode: Clock 2.570 MHz, 1 mm x 257 mm
                  1    2    3  258 hborder 1
                  1    1   18  258 vborder 1
               +hsync -vsync analog composite
Detailed mode: Clock 2.570 MHz, 1 mm x 257 mm
                  1    2    3  258 hborder 1
                  1    1   18  258 vborder 1
               +hsync -vsync analog composite
Monitor ranges (GTF): 48-120Hz V, 30-107kHz H, max dotclock 230MHz
Checksum: 0xf (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#
 
Last edited:
Two more edids. Same ResEdit procedure as described, but these are from a file called Mac OS ROM in the system folder

ID=20001

00FFFFFFFFFFFF000610029D01010101000801016820188CE80489A0574A9B2612484C312B80315945596159A94001010101010101016016404031702B202040230038EA10000018483F403262B0324040C2130038EA10000018000000FD0030A01E5510000A202020202020000000FC0053747564696F4473706C79313700BE

ID=20002

00FFFFFFFFFFFF0006105203010101010106010128261D28E801C9A05749982712484C3FFF8001013159455981596159A94F01010101100E80C020E01D10383813007C221100001EF91520F830581F20204013007C221100001E000000FD0030781E5EFF000A202020202020000000FC0041706C566973696F6E3835300A0002



Code:
root@devuan:~# edid-decode 20001.dat
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 02 9d 01 01 01 01 00 08
version:         01 01
basic params:    68 20 18 8c e8
chroma info:     04 89 a0 57 4a 9b 26 12 48 4c
established:     31 2b 80
standard:        31 59 45 59 61 59 a9 40 01 01 01 01 01 01 01 01
descriptor 1:    60 16 40 40 31 70 2b 20 20 40 23 00 38 ea 10 00 00 18
descriptor 2:    48 3f 40 32 62 b0 32 40 40 c2 13 00 38 ea 10 00 00 18
descriptor 3:    00 00 00 fd 00 30 a0 1e 55 10 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 53 74 75 64 69 6f 44 73 70 6c 79 31 37
extensions:      00
checksum:        be

Manufacturer: APP Model 9d02 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.7 V
Sync: Separate
Maximum image size: 32 cm x 24 cm
Gamma: 2.40
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  640x480@60Hz
  640x480@67Hz
  800x600@60Hz
  832x624@75Hz
  1024x768@60Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
  640x480@85Hz
  800x600@85Hz
  1024x768@85Hz
  1600x1200@60Hz
Detailed mode: Clock 57.280 MHz, 312 mm x 234 mm
                832  864  928 1152 hborder 0
                624  626  629  667 vborder 0
               -hsync -vsync
Detailed mode: Clock 162.000 MHz, 312 mm x 234 mm
               1600 1664 1858 2162 hborder 0
               1200 1201 1204 1250 vborder 0
               -hsync -vsync
Monitor ranges (GTF): 48-160Hz V, 30-85kHz H, max dotclock 160MHz
Checksum: 0xbe (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~# edid-decode 20002.dat
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 02 9d 01 01 01 01 00 08
version:         01 01
basic params:    68 20 18 8c e8
chroma info:     04 89 a0 57 4a 9b 26 12 48 4c
established:     31 2b 80
standard:        31 59 45 59 61 59 a9 40 01 01 01 01 01 01 01 01
descriptor 1:    60 16 40 40 31 70 2b 20 20 40 23 00 38 ea 10 00 00 18
descriptor 2:    48 3f 40 32 62 b0 32 40 40 c2 13 00 38 ea 10 00 00 18
descriptor 3:    00 00 00 fd 00 30 a0 1e 55 10 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 53 74 75 64 69 6f 44 73 70 6c 79 31 37
extensions:      00
checksum:        be

Manufacturer: APP Model 9d02 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.7 V
Sync: Separate
Maximum image size: 32 cm x 24 cm
Gamma: 2.40
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  640x480@60Hz
  640x480@67Hz
  800x600@60Hz
  832x624@75Hz
  1024x768@60Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
  640x480@85Hz
  800x600@85Hz
  1024x768@85Hz
  1600x1200@60Hz
Detailed mode: Clock 57.280 MHz, 312 mm x 234 mm
                832  864  928 1152 hborder 0
                624  626  629  667 vborder 0
               -hsync -vsync
Detailed mode: Clock 162.000 MHz, 312 mm x 234 mm
               1600 1664 1858 2162 hborder 0
               1200 1201 1204 1250 vborder 0
               -hsync -vsync
Monitor ranges (GTF): 48-160Hz V, 30-85kHz H, max dotclock 160MHz
Checksum: 0xbe (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
 
We might be going in two different directions in this case. The reason I want to use C# is so I can make a Win7 control panel icon for the iMac monitor settings. It'll be WinForms based so threre's no sane way it will run on anything else than Windows. :( C# itself will run on Linux with Mono but compatibility is hit or miss. The SerialPort class isn't reliable. Google for "If you must use .NET System.IO.Ports.SerialPort" if you're interested in the ugly details. Every time I post a link here my post ends up waiting for a moderator to approve it.

Your best bet for anything cross-platform will definitely be to write a small Java program.

@oshimai
Understood, hopefully I'll have something soon to test.


Two more edids. Same ResEdit procedure as described, but these are from a file called Mac OS ROM in the system folder

ID=20001

00FFFFFFFFFFFF000610029D01010101000801016820188CE80489A0574A9B2612484C312B80315945596159A94001010101010101016016404031702B202040230038EA10000018483F403262B0324040C2130038EA10000018000000FD0030A01E5510000A202020202020000000FC0053747564696F4473706C79313700BE

ID=20002

00FFFFFFFFFFFF0006105203010101010106010128261D28E801C9A05749982712484C3FFF8001013159455981596159A94F01010101100E80C020E01D10383813007C221100001EF91520F830581F20204013007C221100001E000000FD0030781E5EFF000A202020202020000000FC0041706C566973696F6E3835300A0002

@oshimai

I'l reformat these and add them to the repo as well.

The three you provided earlier are in a folder named raw_data formatted as c byte arrays and converted to binary
https://github.com/qbancoffee/imac_g3_ivad_board_init/tree/master/raw_data

edid1, edid2, and edid3

@oshimai While you're looking through OS 9 monitor files over there: it'd be nice to get the ColorSync profile. I'd like to get that into a format that'll work in OS X and other OS's.

@anotherelise

Have you tried fiddling with the RGB values int the init sequence? I played with these to improve my display.

I loaded a grey-scale image and kept changing the RGB values until I got what I deemed and nice grey-scale image.
If your image is kind of dim , you can "brighten" the image by increasing the green value but then you'll have to add in red and
blue until you have the right mix of the three.

C-like:
  writeToIvad( PROPERTY, 0x04, 0x80);//red x-30
  writeToIvad( PROPERTY, 0x05, 0xB0);// green x
  writeToIvad( PROPERTY, 0x06, 0x78); //blue x-38
 
I'm installing Debian Jessie PPC on my iMac at the moment.
... onto a USB HDD via USB1.1. It'll finish some time tomorrow.
Hopefully this way we'll get the correct edid information out of this damn screen once and for all.
 
  • Like
Reactions: Raging Dufus
I'm installing Debian Jessie PPC on my iMac at the moment.
... onto a USB HDD via USB1.1. It'll finish some time tomorrow.
Hopefully this way we'll get the correct edid information out of this damn screen once and for all.

@oshimai

That will be fantastic, although this was attempted by DrJekyll_XYZ check it out.


The info generated was mostly nonsense but it did serve as a guide to help me put together an edid for the sketch.

I don't think the ivad board responds to requests on 0x50 like a traditional monitor would so the standard tools
to request edid info might need some tweaking. Good luck though.

By the way I added your extracted edid's to the repo. I'll try to try them out tonight.
 
I remember that post now that you point to it. 😓

There are two other ways that I know of
One is running read-edid directly instead of xrandr

It can also be read from somewhere in /sys IIRC
(Of course thats knowledge for PCs. PowerPC architecture is crazy.)

Not sure if those were attempted as well?
 
I remember that post now that you point to it. 😓

There are two other ways that I know of
One is running read-edid directly instead of xrandr

It can also be read from somewhere in /sys IIRC
(Of course thats knowledge for PCs. PowerPC architecture is crazy.)

Not sure if those were attempted as well?

Yes, he used read-edid directly and even modified it and tried to request on different addresses with no success.

Hopefully you can dig something out of /sys.

Good luck!
 
Well, here it is. Raw data as the kernel sees it, not interpreted by any program or anything else.

IMG_0128.jpg


I gathered up all the contents shown in the photo and attached them to this post.
There are a few more tidbits in there that I haven't looked at further.

Code:
unsigned char EDID[] = {
  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
  0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
  0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
  0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
  0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
  0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
  0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
  0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
  0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
  0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
};
unsigned int EDID_len = 128;

Code:
root@devuan:~# edid-decode EDID
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 05 9d 01 01 01 01 00 08
version:         01 01
basic params:    08 1b 14 96 e8
chroma info:     66 e9 9c 57 4c 96 26 10 48 4c
established:     00 02 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    88 13 80 c0 20 e0 22 10 10 40 13 00 0e c8 10 00 00 1e
descriptor 2:    60 18 20 f0 30 58 20 20 10 50 13 00 0e c8 10 00 00 1e
descriptor 3:    00 00 00 fd 00 4b 75 3c 3c 08 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 69 4d 61 63 0a 20 20 20 20 20 20 20 20
extensions:      00
checksum:        c9

Manufacturer: APP Model 9d05 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.3 V
Sync: Separate
Maximum image size: 27 cm x 20 cm
Gamma: 2.50
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  1024x768@75Hz
Standard timings supported:
Detailed mode: Clock 50.000 MHz, 270 mm x 200 mm
                640  656  720  832 hborder 0
                480  481  484  514 vborder 0
               +hsync +vsync
Detailed mode: Clock 62.400 MHz, 270 mm x 200 mm
                800  816  896 1040 hborder 0
                600  601  604  632 vborder 0
               +hsync +vsync
Monitor ranges (GTF): 75-117Hz V, 60-60kHz H, max dotclock 80MHz
Monitor name: iMac
Checksum: 0xc9 (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#

Hope this helps someone...
 

Attachments

  • sys_2.zip
    1.7 KB · Views: 124
Well, here it is. Raw data as the kernel sees it, not interpreted by any program or anything else.

View attachment 905542

I gathered up all the contents shown in the photo and attached them to this post.
There are a few more tidbits in there that I haven't looked at further.

Code:
unsigned char EDID[] = {
  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
  0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
  0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
  0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
  0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
  0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
  0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
  0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
  0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
  0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
};
unsigned int EDID_len = 128;

Code:
root@devuan:~# edid-decode EDID
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 05 9d 01 01 01 01 00 08
version:         01 01
basic params:    08 1b 14 96 e8
chroma info:     66 e9 9c 57 4c 96 26 10 48 4c
established:     00 02 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    88 13 80 c0 20 e0 22 10 10 40 13 00 0e c8 10 00 00 1e
descriptor 2:    60 18 20 f0 30 58 20 20 10 50 13 00 0e c8 10 00 00 1e
descriptor 3:    00 00 00 fd 00 4b 75 3c 3c 08 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 69 4d 61 63 0a 20 20 20 20 20 20 20 20
extensions:      00
checksum:        c9

Manufacturer: APP Model 9d05 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.3 V
Sync: Separate
Maximum image size: 27 cm x 20 cm
Gamma: 2.50
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  1024x768@75Hz
Standard timings supported:
Detailed mode: Clock 50.000 MHz, 270 mm x 200 mm
                640  656  720  832 hborder 0
                480  481  484  514 vborder 0
               +hsync +vsync
Detailed mode: Clock 62.400 MHz, 270 mm x 200 mm
                800  816  896 1040 hborder 0
                600  601  604  632 vborder 0
               +hsync +vsync
Monitor ranges (GTF): 75-117Hz V, 60-60kHz H, max dotclock 80MHz
Monitor name: iMac
Checksum: 0xc9 (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#

Hope this helps someone...


Wow, that's really nice! I'll convert it and test it and report back.
 
Well, here it is. Raw data as the kernel sees it, not interpreted by any program or anything else.

View attachment 905542

I gathered up all the contents shown in the photo and attached them to this post.
There are a few more tidbits in there that I haven't looked at further.

Code:
unsigned char EDID[] = {
  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
  0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
  0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
  0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
  0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
  0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
  0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
  0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
  0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
  0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
};
unsigned int EDID_len = 128;

Code:
root@devuan:~# edid-decode EDID
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 10 05 9d 01 01 01 01 00 08
version:         01 01
basic params:    08 1b 14 96 e8
chroma info:     66 e9 9c 57 4c 96 26 10 48 4c
established:     00 02 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    88 13 80 c0 20 e0 22 10 10 40 13 00 0e c8 10 00 00 1e
descriptor 2:    60 18 20 f0 30 58 20 20 10 50 13 00 0e c8 10 00 00 1e
descriptor 3:    00 00 00 fd 00 4b 75 3c 3c 08 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 69 4d 61 63 0a 20 20 20 20 20 20 20 20
extensions:      00
checksum:        c9

Manufacturer: APP Model 9d05 Serial Number 16843009
EDID version: 1.1
Analog display, Input voltage level: 0.7/0.3 V
Sync: Separate
Maximum image size: 27 cm x 20 cm
Gamma: 2.50
DPMS levels: Standby Suspend Off
RGB color display
Established timings supported:
  1024x768@75Hz
Standard timings supported:
Detailed mode: Clock 50.000 MHz, 270 mm x 200 mm
                640  656  720  832 hborder 0
                480  481  484  514 vborder 0
               +hsync +vsync
Detailed mode: Clock 62.400 MHz, 270 mm x 200 mm
                800  816  896 1040 hborder 0
                600  601  604  632 vborder 0
               +hsync +vsync
Monitor ranges (GTF): 75-117Hz V, 60-60kHz H, max dotclock 80MHz
Monitor name: iMac
Checksum: 0xc9 (valid)
EDID block does NOT conform to EDID 1.0!
        Has descriptor blocks other than detailed timings
EDID block does not conform at all!
        Bad year of manufacture
root@devuan:~#

Hope this helps someone...

Your hard work paid off, that EDID worked flawlessly! I've made it the default EDID in the sketch.

@anotherelise
Can you test the new edid on your side when you get a chance?

Also, I uploaded the new byte arrays to the atmega but with many complaints from the compiler. It seems that the byte arrays are a
little too big for the amount of memory available. I think now that we know the extremes for each array and that they are being incremented and decremented by 1 we could just keep track of a variable and compute the value rather than get it from
the array.

What do you think?
 
Your hard work paid off, that EDID worked flawlessly! I've made it the default EDID in the sketch.
Thanks!

@anotherelise
Can you test the new edid on your side when you get a chance?

Also, I uploaded the new byte arrays to the atmega but with many complaints from the compiler. It seems that the byte arrays are a
little too big for the amount of memory available. I think now that we know the extremes for each array and that they are being incremented and decremented by 1 we could just keep track of a variable and compute the value rather than get it from
the array.

What do you think?
 
I just included the source along with a compiled version in the repo.
Anyone who wants to test it , you have to have rxtx installed so that java can access the serial ports
and if you're on linux you have to be part of the dialout group

It's a netbeans 8.1 project.
 
@rockyhill Would you do an i2c capture of your iMac booting up? I want to start getting into what the values that we read back from the ivad are and it'd help to have more than just my capture.
 
@rockyhill Would you do an i2c capture of your iMac booting up? I want to start getting into what the values that we read back from the ivad are and it'd help to have more than just my capture.

The commented init sequence, "Init sequence 1" is from one of my iMac's the one that initializes the IVAD board but doesn't boot.
The default one is the one provided by sparpet and for some reason the other capture I made isn't commented
in the sketch, I think I accidentally removed it. I'll dig it up and put it in there. Either way you have two other init sequences already
in the sketch that should give you a good starting point.
 
@anotherelise

I've been experimenting with two iMacs to get all this working and a lot of the data I've included have been gathered from these two.
I do have another iMac that is in pristine condition and I was holding off taking it apart because I don't want to destroy
any parts of the housing, particularly the inner bezel.
That said, I've been formulating a plan for the past week and after watching several videos I'm going to bite the bullet and crack it open to get another init sequence among other things.

Instead of cutting into the IVAD wires, I'm just going to remove the bottom cover/shield and remove the logic board.
Afterwards I'll solder a pair of wires to i2c lines and replace the logic board and sniff from there. This way I don't need
to remove the outer bezel or the translucent cover.

I'll get you another init sequence to you sometime this week but for now you have three, I'm looking for the fourth one and I'll get a fifth one.

What would be really good to figure out is what the register at 0x53 is for. I bet this is where the IVAD MCU receives commands to
actually power things on like CRT filament and things like that.

Good luck,
[automerge]1586873740[/automerge]
@rockyhill Would you do an i2c capture of your iMac booting up? I want to start getting into what the values that we read back from the ivad are and it'd help to have more than just my capture.

I just realized you wanted the raw capture not the massaged capture.

I just included one of my raw captures and I included sparpets raw capture in the raw data folder
in the repo

"i2c_capture_rocky_hill.ods"
"imac_data_sparpet.txt"
 
Last edited:
Parts arrived. Still waiting for a relay board though.

I soldered together a VGA breakout cable, and pulseIn even sort of works, but the VSYNC idea has a flaw in that apart from not working with the current revision of the connector board rockyhill designed out of the box, I would also have to create a Y cable to sniff VSYNC while passing it on to the screen.

The following also seems to do the trick but I'm not 100% confident about it yet since I tested it a grand total of 15 minutes. If no data received over I2C for more than 8 seconds, turn off, otherwise turn on. Testing with a LED at the moment since I want to have this stuff right before I hook up the CRT.

Code:
#include <Wire.h>

#define LED 22

unsigned long LAST_I2C_RECEIVE = -1; // wrap around to max value
int ONLINE = -1;

void setup() {
  pinMode(LED, OUTPUT); // digital, just a LED

  Wire.begin(0x50);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveData);
}

void requestEvent() {
  const byte edid[128] = {
    0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
    0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
    0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
    0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
    0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
    0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
    0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
  };

  Wire.write(edid, 128);
}

void receiveData(int byteCount) {
  while (Wire.available())
    Wire.read();
    
  LAST_I2C_RECEIVE = millis();
  ONLINE = 1;
}

void loop() {
  if (ONLINE == 1 && millis() - LAST_I2C_RECEIVE > 8000) {
    ONLINE = 0;
    digitalWrite(LED, LOW);
  }
  else if (ONLINE == 0 && millis() - LAST_I2C_RECEIVE < 8000)
  {
    ONLINE = 1;
    digitalWrite(LED, HIGH);
  }
}
[automerge]1586890340[/automerge]
 
Last edited:
Parts arrived. Still waiting for a relay board though.

I soldered together a VGA breakout cable, and pulseIn even sort of works, but the VSYNC idea has a flaw in that apart from not working with the current revision of the connector board rockyhill designed out of the box, I would also have to create a Y cable to sniff VSYNC while passing it on to the screen.

The following also seems to do the trick but I'm not 100% confident about it yet since I tested it a grand total of 15 minutes. If no data received over I2C for more than 8 seconds, turn off, otherwise turn on. Testing with a LED at the moment since I want to have this stuff right before I hook up the CRT.

Code:
#include <Wire.h>

#define LED 22

unsigned long LAST_I2C_RECEIVE = -1; // wrap around to max value
int ONLINE = -1;

void setup() {
  pinMode(LED, OUTPUT); // digital, just a LED

  Wire.begin(0x50);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveData);
}

void requestEvent() {
  const byte edid[128] = {
    0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
    0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
    0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
    0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
    0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
    0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
    0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
  };

  Wire.write(edid, 128);
}

void receiveData(int byteCount) {
  while (Wire.available())
    Wire.read();
   
  LAST_I2C_RECEIVE = millis();
  ONLINE = 1;
}

void loop() {
  if (ONLINE == 1 && millis() - LAST_I2C_RECEIVE > 8000) {
    ONLINE = 0;
    digitalWrite(LED, LOW);
  }
  else if (ONLINE == 0 && millis() - LAST_I2C_RECEIVE < 8000)
  {
    ONLINE = 1;
    digitalWrite(LED, HIGH);
  }
}
[automerge]1586890340[/automerge]


I think this is definitely still a good idea and I'm anxious to see it work. I could jumper the current board and put out a new revision
once it works.
So here's a thought...

VSYNC will have a continuous pulse and the levels are just regular TTL levels or 0 and +5 volts(need to confirm) so this could be directly connected to an input pin on the arduino and monitored inside the main loop.

There is a lot of code out there to make frequency counters with arduinos so in theory you can measure the VSYNC frequency
directly. Even if the value obtained is way off, it's still a value greater than zero. In that case it becomes a matter of monitoring the
value.

Pins PB0 and PB1 pins 8 and 9 on the arduino uno respectively are pulled out to a header on the current revision
of the j20 board. It would be very easy to solder a jumper from here to VSYNC.

What do you think?
 
Parts arrived. Still waiting for a relay board though.

I soldered together a VGA breakout cable, and pulseIn even sort of works, but the VSYNC idea has a flaw in that apart from not working with the current revision of the connector board rockyhill designed out of the box, I would also have to create a Y cable to sniff VSYNC while passing it on to the screen.

The following also seems to do the trick but I'm not 100% confident about it yet since I tested it a grand total of 15 minutes. If no data received over I2C for more than 8 seconds, turn off, otherwise turn on. Testing with a LED at the moment since I want to have this stuff right before I hook up the CRT.

Code:
#include <Wire.h>

#define LED 22

unsigned long LAST_I2C_RECEIVE = -1; // wrap around to max value
int ONLINE = -1;

void setup() {
  pinMode(LED, OUTPUT); // digital, just a LED

  Wire.begin(0x50);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveData);
}

void requestEvent() {
  const byte edid[128] = {
    0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
    0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
    0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
    0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
    0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
    0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
    0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
  };

  Wire.write(edid, 128);
}

void receiveData(int byteCount) {
  while (Wire.available())
    Wire.read();
   
  LAST_I2C_RECEIVE = millis();
  ONLINE = 1;
}

void loop() {
  if (ONLINE == 1 && millis() - LAST_I2C_RECEIVE > 8000) {
    ONLINE = 0;
    digitalWrite(LED, LOW);
  }
  else if (ONLINE == 0 && millis() - LAST_I2C_RECEIVE < 8000)
  {
    ONLINE = 1;
    digitalWrite(LED, HIGH);
  }
}
[automerge]1586890340[/automerge]

I think monitoring the i2c lines for EDID requests from the source like you have posted above can work as well but what if
there was a source that didn't request EDID info?

Maybe we could have the option of using the two methods depending on what your setup is like.
 
with pulseIn

Note how pulseIn behaves with VSYNC by watching the serial monitor. On my system I get a rapid fire of pulses and then nothing for 1 second, a rapid fire and nothing for 1 second. VSYNC is not a clean 5V signal that stays HIGH and then goes to LOW every so often.

So yes, pulseIn will work for this, but I feel it's just a coincidence that it works out.

Are you okay with having a approx. 1 sec delay in your main loop while VSYNC is LOW? The alternative would be to use interrupts. I have a version of that as well, but it is slightly more complicated and it will limit which pins can be used to watch the VSYNC signal.

The code is still missing a turn off delay. You probably don't want to shut off the screen every time when you e.g. reboot your computer. The iMac does this when you reboot, but I don't think that's very healthy for the CRT.

Code:
#include <Wire.h>

#define LED 22
#define VSYNC 2

int TMP = 0;

// boilerplate stuff
void requestEvent() {
  const byte edid[128] = {
    0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
    0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
    0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
    0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
    0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
    0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
    0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
  };

  Wire.write(edid, 128);
}

void receiveData(int byteCount) {
  while (Wire.available())
    Wire.read();
}
// end boilerplate

void setup() {
  Wire.begin(0x50);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveData);
  Serial.begin(9600);
  pinMode(LED, OUTPUT);
  pinMode(VSYNC, INPUT_PULLUP);
}

void loop() {
  int a = pulseIn(VSYNC, LOW);
  Serial.println(a);
  if (a != 0 && TMP == 0)
  {
    Serial.println("SCREEN ON");
    digitalWrite(LED, HIGH);
    TMP = 1;
  }
  else if (a == 0 && TMP != 0)
  {
    Serial.println("SCREEN OFF");
    digitalWrite(LED, LOW);
    TMP = 0;
  }
}
 
with pulseIn

Note how pulseIn behaves with VSYNC by watching the serial monitor. On my system I get a rapid fire of pulses and then nothing for 1 second, a rapid fire and nothing for 1 second. VSYNC is not a clean 5V signal that stays HIGH and then goes to LOW every so often.

So yes, pulseIn will work for this, but I feel it's just a coincidence that it works out.

Are you okay with having a approx. 1 sec delay in your main loop while VSYNC is LOW? The alternative would be to use interrupts. I have a version of that as well, but it is slightly more complicated and it will limit which pins can be used to watch the VSYNC signal.

The code is still missing a turn off delay. You probably don't want to shut off the screen every time when you e.g. reboot your computer. The iMac does this when you reboot, but I don't think that's very healthy for the CRT.

Code:
#include <Wire.h>

#define LED 22
#define VSYNC 2

int TMP = 0;

// boilerplate stuff
void requestEvent() {
  const byte edid[128] = {
    0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x06, 0x10, 0x05, 0x9d,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x08, 0x01, 0x01, 0x08, 0x1b, 0x14, 0x96,
    0xe8, 0x66, 0xe9, 0x9c, 0x57, 0x4c, 0x96, 0x26, 0x10, 0x48, 0x4c, 0x00,
    0x02, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88, 0x13, 0x80, 0xc0, 0x20, 0xe0,
    0x22, 0x10, 0x10, 0x40, 0x13, 0x00, 0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e,
    0x60, 0x18, 0x20, 0xf0, 0x30, 0x58, 0x20, 0x20, 0x10, 0x50, 0x13, 0x00,
    0x0e, 0xc8, 0x10, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x4b,
    0x75, 0x3c, 0x3c, 0x08, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x00, 0x00, 0x00, 0xfc, 0x00, 0x69, 0x4d, 0x61, 0x63, 0x0a, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0xc9
  };

  Wire.write(edid, 128);
}

void receiveData(int byteCount) {
  while (Wire.available())
    Wire.read();
}
// end boilerplate

void setup() {
  Wire.begin(0x50);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveData);
  Serial.begin(9600);
  pinMode(LED, OUTPUT);
  pinMode(VSYNC, INPUT_PULLUP);
}

void loop() {
  int a = pulseIn(VSYNC, LOW);
  Serial.println(a);
  if (a != 0 && TMP == 0)
  {
    Serial.println("SCREEN ON");
    digitalWrite(LED, HIGH);
    TMP = 1;
  }
  else if (a == 0 && TMP != 0)
  {
    Serial.println("SCREEN OFF");
    digitalWrite(LED, LOW);
    TMP = 0;
  }
}

@oshimai

Hmm one second is a bit too long especially if the fine monitor adjustments depend on the loop but
pulsein has a third parameter which is a timeout value given in microseconds. The loop currently
has a delay of 10 millseconds so maybe the timeout for pulsein can be 10000 microseconds.
This will give it the dual purpose of detecting VSYNC pulses and serve as the loops timeout.

If there are no changes for say 5 seconds the monitor shuts off.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.