Monitor Sense Lines

[joevt]

I was doing some research on DingusPPC and found this: https://68kmla.org/bb/index.php?threads/monitor-identification-over-the-built-in-video-port-on-beige-g3.38344/ Did you ever find an answer to your questions?

I looked for related source code and found this: https://github.com/dingusdev/dingusppc/blob/fff597075dcba6febb59f4a6cd18e49be7dab675/devices/video/displayid.cpp#L34 It seems strange that some of the codes have ext_sense_code = 0xff. Is that intentional? ext_sense_code can only be 6 bits so they shouldn't be more than 0x3f. And I think 0x3f is only possible in the NotConnected case.

Apple has a list of sense code values in IOMacOSVideo.h There's a list of raw sense codes (eg. kRSCZero) and extended sense codes (eg. kESCZero21Inch). Besides defining extended sense codes for raw sense code 7 and 6, there's also some extended sense codes defined for raw sense code 3 (a couple of Radius displays).

Combining your list with Apple's, I get this:

√   kESCZero21Inch            = 0x00, # 21" RGB                           "MacColor21in"    , 0x00FF                 
√   kESCOnePortraitMono       = 0x14, # Portrait Monochrome               "PortraitGS"      , 0x01FF   
√   kESCTwo12Inch             = 0x21, # 12" RGB                           "MacRGB12in"      , 0x02FF            
 -  kESCThree21InchRadius     = 0x31, # 21" RGB (Radius)                                
 -  kESCThree21InchMonoRadius = 0x34, # 21" Monochrome (Radius)                            
√   kESCThree21InchMono       = 0x35, # 21" Monochrome                    "TwoPageGS"       , 0x03FF              
√   kESCFourNTSC              = 0x0A, # NTSC                              "NTSC"            , 0x04FF          
√   kESCFivePortrait          = 0x1E, # Portrait RGB                      "MacRGB15in"      , 0x05FF           
√   kESCSixMSB1               = 0x03, # MultiScan Band-1 (12" thru 1Six") "Multiscan15in"   , 0x0603                    
√   kESCSixMSB2               = 0x0B, # MultiScan Band-2 (13" thru 19")   "Multiscan17in"   , 0x060B                       
√   kESCSixMSB3               = 0x23, # MultiScan Band-3 (13" thru 21")   "Multiscan20in"   , 0x0623                       
√   kESCSixStandard           = 0x2B, # 13"/14" RGB or 12" Monochrome     "AppleVision1710" , 0x062B // this code is assigned to several different monitors!
 ?                                    #                                   "HiRes12-14in"    , 0x06FF
√   kESCSevenPAL              = 0x00, # PAL                               "PALEncoder"      , 0x0700 // no clue what it means
√   kESCSevenNTSC             = 0x14, # NTSC                              "NTSCEncoder"     , 0x0714 // no clue what it means          
√   kESCSevenVGA              = 0x17, # VGA                               "VGA-SVGA"        , 0x0717            
√   kESCSeven16Inch           = 0x2D, # 16" RGB (GoldFish)                "MacRGB16in"      , 0x072D                  
√   kESCSevenPALAlternate     = 0x30, # PAL (Alternate)                   "PAL"             , 0x0730                
√   kESCSeven19Inch           = 0x3A, # Third-Party 19"                   "MacRGB19in"      , 0x073A                 
 -  kESCSevenDDC              = 0x3E, # DDC display                                    
√   kESCSevenNoDisplay        = 0x3F  # No display connected              "NotConnected"    , 0x07FF               

The strange values are 0x00FF, 0x01FF, 0x02FF, 0x03FF, 0x04FF, 0x05FF, 0x06FF, 0x07FF They probably should be 0x0000, 0x0114, 0x0221, 0x0335, 0x040A, 0x051E, 0x062B, 0x73F

There's 512 different circuits you can make with the 3 sense lines: (ground/floating)^3 x (wire/left-diode/right-diode/nothing)^3 = 2^3 x 4^3 = 512. Only 45 unique results can be read from them. Raw sense codes 0, 1, 2, 4 have only 1 possible extended sense code each. Raw sense codes 3, 5, 6 can have 4 possible extended sense codes each. Raw sense code 7 has 29 possible extended sense codes.

I wrote a Think Pascal project in Nov 1996 to show the possibilities:

[maximumspatium]

Did you ever find an answer to your questions?

Yes, I did. The built-in video port of a Macintosh G3 Beige Desktop does support DDC. I figured it out by playing with a real computer.

It seems strange that some of the codes have ext_sense_code = 0xff. Is that intentional?

Well, the guest software I analyzed so far performs dynamic polling only for standard codes 6 and 7. Setting the extended code for all other standard codes to 0xFF looked okay for me so yes, that's intentional. We could change them to reflect the behavior of the circuitry but doing so wouldn't probably be a huge gain - the code will work the same way.

I agree on the objection that the value combination 0x06FF isn't electrically possible and should be removed.

The program responsible for transmitting the extended codes only picks the lower 6 bits. Therefore, there is no big difference whether we put 0x7FF or 0x73F into the table.

To summarize the above, I'm open to the idea of using the extended monitor codes that precisely reflect the behavior of the underlying circuitry. I'm also fine with the current solution because it's more readable (0xFF is quickly identified as a placeholder) plus it works for all video drivers I tested so far.

In my view, it's much more important to have a good human-readable documentation on Apple monitor identification in one place. For the time being, everything we know about it is scattered across various blog posts while the original article Technical Note HW 30 seems to have disappeared.

Could you take on this task?

[joevt]

HW_30 is at https://developer.apple.com/library/archive/technotes/hw/hw_30.html You can search for old documents at https://developer.apple.com/library/archive/navigation/ There's stuff Apple put on Developer CDs that aren't on the website... For example, there's sample graphics and SCSI ndrv driver code.

[maximumspatium]

For example, there's sample graphics and SCSI ndrv driver code.

Which CD is that? Side question: it looks like there is some old Apple sample code for native video drivers. I'm specially interested in particular gamma tables like Page white gamma, Macintosh standard gamma etc. I saw a couple of drivers from different manufacturers (ATI, IXMICRO) containing the same gamma code so I think it comes from Apple...

[joevt]

I think PCI Driver Development Kit from "Dev.CD Jan 96 SDK1" or "Dev.CD Jul 97 SDK1". The folder name is "GDX 950717" (GDX "Graphics Driver for External Use", Version 1.0.1, July 17, 1995)

The code does mention multiple gamma tables in a file called GraphicsCoreStatus.c:

• Standard
• PageWhite
• Gray
• Rubik
• NTSCPAL
• CSCTFT

They all have an ID, text name, and hex data, and a function that defines what display each is applicable to. The applicable list might be different in actual drivers. I have mostly decompiled (disassembled and manually converted to C) the driver for the "control" video output (as used by Power Mac 8600 and some other Power Macs). That driver mentions displays with DDC while the Apple sample code does not.

The gamma table is applied to a CLUT.

[maximumspatium]

I think PCI Driver Development Kit from "Dev.CD Jan 96 SDK1"

Got that CD. Many thanks!

I hoped to find the precise equations for the gamma correction tables there. Unfortunately, the source contains raw tables without any explanation how the values were calculated.

I have mostly decompiled (disassembled and manually converted to C) the driver for the "control" video output (as used by Power Mac 8600 and some other Power Macs).

Could you share it with me? I disassembled and commented Mac OS drivers for two ATI video cards. You can have it if you want...

[joevt]

I guess you could plot the data and try some curve fitting methods. First, you need to know what kind of curves can be used for gamma tables. The wikipedia gamma correction article says it's a power function Vout = A Vin^gamma https://en.wikipedia.org/wiki/Gamma_correction but the table format could be using any kind of curve...

Do you have an account at macrumors.com?

[joevt]

Sense Lines information has been corrected and expanded. If there's any remaining issues with a specific graphics controller in DPPC, then they can be addressed separately.

EDID from sense lines is a separate issue that needs further development and testing. Currently, only the ATI graphics controllers in DPPC could possibly do something with EDID since Apple graphics controllers support only specific timings. However, some Apple graphics controllers may have code to read the EDID to get the display name or maximum resolution.