what a great movie tho!
and was before early Intel time!
Last edited:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What have you done with an early Intel recently?
- Thread starter Project Alice
- Start date
- Sort by reaction score
and was before early Intel time!
"I'm what you call a repeat offender! I repeat, I will offend again!"
Yes, among my favourites. A post-modernist retelling of the life of Christ, wrapped around an increasingly prescient satire that draws on pastiches of Network, Dirty Harry, The Terminator and Judge Dredd.
Here's my Criterion Collection DVD:
It's my default means for enjoying the film as it contains an exclusive (and superior) audio commentary track and presents Verhoeven's masterpiece in his preferred aspect ratio of 1.66:1 - which has never been repeated by any other home video release.
Unfortunately being an early DVD release, it's non-anamorphic widescreen which means there are black bars surrounding the entire image when it's viewed on a 16:9 TV so the best option is to use an iBook due to their 4:3 displays.
Before early Intel Macs. It was a time of early Intel PCs though.
Infinitely quotable and hilariously so too. It's often misunderstood that the film is a terrific black comedy.
When I thought it over, that description actually makes a lot of sense. I had no idea it got a Criterion Release; I'd love to have a copy myself (used copies are actually decently priced, if I ignore the insane $141 listing Amazon puts at the top of its search results). Needless to say, it's well deserved. I'm not into them as much now, but I recall watching a Red Letter Media discussion on one of their Best of the Worst episodes where Rich, Jay and Mike talk about how Robocop is a rare example of a "perfect movie": It knows exactly what it is, what it's trying to do, and executes on it brilliantly. (By this criteria, I'd argue Wakaliwood's movies could easily qualify too.
)It's often misunderstood that the film is a terrific black comedy.
I think this is was what was lost on later attempts to extend and revive RoboCop, notably RoboCop 3, the CTV series, the animated series, the 2014 remake, and the Prime Directives miniseries (well, okay, so I guess everything with the exception of RoboCop 2, which in my mind at least captured some of the verve of the original). They either tried to santize everything to a one-dimensional family-friendly sci-fi action-adventure plot, or went all-in on the corporate dystopia with no regard for the levity or the over-the-top satire that made the first movie so magical.
Last edited:
I recently inherited a 4,1 Core Duo iMac, 17 inch screen. Initially I installed Snow Leopard on it and gave it to my kids. They didn't really need it, so I repurposed it as a Plan9 Display Terminal. I'm running a 9P server on my home network, that acts as both a file and authentication server. The iMac is net booting off the file server and using its own internal CPU. It's similar to running X11 on a thin client over NFS.
I'm using a VM under Parallels Desktop under OS X 10.6 to make this happen. I'd eventually like to boot Plan9 directly on the hard drive in a tiny partition (just kernel and some config files) to net boot it. But haven't found a good way to do install it yet. When I try to boot the installer CD, I get the message "Select CD-ROM Boot Type:" I may try using Parallels to install to an empty partition. But for now it works nicely under Parallels.
I'm using a VM under Parallels Desktop under OS X 10.6 to make this happen. I'd eventually like to boot Plan9 directly on the hard drive in a tiny partition (just kernel and some config files) to net boot it. But haven't found a good way to do install it yet. When I try to boot the installer CD, I get the message "Select CD-ROM Boot Type:" I may try using Parallels to install to an empty partition. But for now it works nicely under Parallels.
Take a look at this. It might help you with your EFI-32 boot issue- Linux DVD images (and how-to) for 32-bit EFI Macs (late 2006 models). Scroll down to the section "Option 2".
EDIT: Just read that your iMac is a Core Duo, so his info may not apply. Still... it's good reading and may give some clues. Perhaps the program that he wrote could modify your ISO, but I never tried this with a 32-bit distro...
Last edited:
This one always got me…just the callousness that somehow borders on humorous.Of course!
Probably NSFW...
"Lose the arm!"
July 1987. I was 16, had a car and some cash. First movie I saw just by myself.Before early Intel Macs. It was a time of early Intel PCs though.
I'd been posting quotes for a few months before the release on my BBS. Commodore 64 running AABBS on two 1541 drives with a Hayes 1200bps modem.
July 1987... I was 0.
I've been playing with my 2010 MBA (GeForce 320M) running Snow Leopard hooked up to my MateView. A straight DisplayPort connection constrains it to 216 MHz pixel clock (RBR link rate) even though the GPU can do 360 MHz (HBR) so I've turned to an active DisplayPort-to-HDMI 1.4 adapter. I'm currently running 3840×2560 at 29 Hz CVT-RB, which is 301.06 MHz pixel clock. Higher refresh rates (and thus pixel clocks) have resulted in dropouts (rarely at 30 Hz, much more frequently at 31 or 32 Hz). CVT-RB v2 results in flashing vertical red lines all over the screen.
Last edited:
Slightly off topic here so sorry in advance, but have you been having any strange, unexplainable freezes on Snow Leopard? I've been having them on multiple SL machines for a few weeks now, cannot point to any issues.
What's the oldest machine that can do 60Hz at 3840x2560?
No need to apologise. I've seen your thread but am at a complete loss as to what's going on. I have no issues with 10.6.8 on the 2010 MBA and 2011 MBP (gonna check my 2007 MBP) with the correct date. The machines aren't connected to the internet and have network time sync disabled, however.
This mode requires a 631.75 MHz pixel clock, and the oldest GPUs that can do this are Intel Skylake iGPUs which have a limit of 675 MHz AFAICS, AMD Polaris (Radeon RX 460/470/480), which have a limit of 1080 MHz) or NVIDIA Maxwell 2 (GeForce GTX 9x0, which have a limit of 1045 MHz). So in terms of Macs, we're looking at 2016 or later models basically.
Interestingly, on my iMac which has a Broadwell iGPU, SwitchResX reports a 640 MHz pixel clock limit for the internal display and 540 MHz for the external(s). So if it were possible to remove that pixel clock limit for the external(s), the iGPU would theoretically be able to pull it off... theoretically, because macOS additionally limits it to a height of 2400 lines so unless that limit were to be removed too, it still wouldn't work. Which is why I use a Radeon RX 460 as a Thunderbolt 2 eGPU to run the monitor.
Last edited:
Dug out my 2010 iMac with the Radeon HD 4850. Much better results using a straight DisplayPort connection. Curiously, 3000×2000 at 60 Hz CVT-RB (390 MHz pixel clock) works but at 3840×2560, 36.7 Hz CVT-RB (382.06 MHz) is the best it can do. Higher refresh rates/pixel clocks result in the monitor reporting "invalid frequency". Since this is higher than HBR's 360 MHz for 8 bpc limit, I assume I'm only getting 6 bpc but there's no way to confirm that on Snow Leopard AFAIK (@joevt: or is there?).
Last edited:
I'm not sure. I don't think macOS would ever choose 6bpc. What does AllRez show? You may need to try OCLP with my Lilu and WhateverGreen fork to get AllRez to dump the bpc setting. I don't remember if I tried them on Snow Leopard.
Also with my Lilu/WhateverGreen/AllRez, I was able to choose 6bpc with Nvidia Kepler GTX780M in my iMac14,2 but I haven't figured out yet how to increase max pixel clock to take advantage of the 6bpc. The 6bpc hack didn't seem to work on my MacPro3,1 with GTX 680 even though it is also Kepler, so that will also require more work.
"Illegal instruction" on Snow Leopard and Lion and a CoreDisplay-related error message on Mavericks. Shall I try it on Yosemite and El Capitan as well and report back with its results? I can supply its output on High Sierra and Catalina but it's probably 8 bpc given the 360 MHz pixel clock limit (see below).
I also did some more testing:
- 10.7.5: tries to display 3840×2560 at 30 Hz (406.5 MHz) but fails; 3000×2000 at 60 Hz (390 MHz) works; SwitchResX reports
450540 MHz pixel clock limit (same behaviour as on 10.6.8.) - 10.8.5, 10.10.5, 10.11.6: 2560×1440 at 60 Hz (241.5 MHz) is highest available mode OOTB; image displays OK; SwitchResX reports 360 MHz pixel clock limit
- 10.9.5: 2560×1440 at 60 Hz (241.5 MHz) is highest available mode but screen is black regardless of mode
- 10.12.6, 10.13.6, 10.15.7: 3840×2160 at 30 Hz (297 MHz) is highest available mode OOTB; image displays OK; SwitchResX reports 360 MHz pixel clock limit
How do you choose that on macOS?
Edit: Corrected typos and mistakes, added info on 10.8.5’s behaviour.
Last edited:
I'll do some debugging of AllRez on earlier macOS versions.
I suppose if you can reproduce the same 382.06 MHz result in a later macOS version that can run AllRez without error, then the output from AllRez in that case should be almost as useful.
It's done programatically using patches installed by WhateverGreen to the i2c methods of the IOFrameBuffer drivers. The IOUserClient used by IOKit/i2c/IOI2CInterface.h is enough to send and get info to/from an IOFrameBuffer (with the WhateverGreen patches) and I didn't want to create a separate IOUserClient.
The patches inspects the i2c parameters and will perform special functions if they are not normal.
https://github.com/joevt/WhateverGr...798175/WhateverGreen/kern_iofbdebug.cpp#L1677
There's code in AllRez (currently commented out) to invoke those.
https://github.com/joevt/AllRez/blo...d9574da8c0209dd/AllRez/iofbdebuguser.cpp#L130
'atfc' is for the setAttributeForConnection method of IOFrameBuffer. The attributes used for setting bpc are kConnectionControllerColorDepth, and kConnectionColorMode.If you have the WhateverGreen patches installed correctly, then AllRez will report latest attribute calls like this:
Code:
IOFBAttributes = [
setAttribute { kIOPowerStateAttribute 'pwrs' = 0x00000002 : 2 }
setAttributeForConnection(0) { kConnectionControllerDitherControl 'øgdc' = 0x00000080 : RGB Default,444 Disabled,422 Disabled, }
getAttributeForConnection(0) { kConnectionChanged 'chng' = 0xaaaaaaaaaaaaaaaa : n/a }
getAttributeForConnection(0) { kConnectionCheckEnable 'cena' = 0x00000001 : true }
getAttributeForConnection(0) { kConnectionSupportsHLDDCSense 'hddc' = n/a }
getAttributeForConnection(0) { kConnectionSupportsAppleSense 'asns' = n/a }
getAttributeForConnection(0) { kConnectionFlags 'flgs' = 0x00004984 : BuiltIn,?0x4184, }
setAttributeForConnection(0) { kConnectionFlags 'flgs' = 0x00000000 : }
getAttributeForConnection(0) { kConnectionControllerDepthsSupported 'øgrd' = 0x0002070f : RGB 6,RGB 8,RGB 10,RGB 12,444 6,444 8,444 10,422 8, }
setAttributeForConnection(0) { kConnectionColorDepthsSupported ' bpc' = 0x00000006 : RGB 8,RGB 10, }
getAttributeForConnection(0) { kConnectionControllerColorDepth 'ødpd' = 0x00000004 : RGB 10, }
getAttributeForConnection(0) { kConnectionControllerDitherControl 'øgdc' = 0x00000080 : RGB Default,444 Disabled,422 Disabled, }
setAttributeForConnection(0) { kConnectionDisplayFlags 'dflg' = 0x00000000 : }
getAttribute { kIOWindowServerActiveAttribute 'wsrv' = 0x00000000 : 0x0 } result:kIOReturnUnsupported
setAttribute { kIOFBLimitHDCPStateAttribute 'sHDC' = 0x00000000 : false }
setAttribute { kIOFBLimitHDCPAttribute 'hdcp' = 0x00000000 : false } result:kIOReturnUnsupported
getAttributeForConnection(0) { kConnectionDisplayParameterCount 'pcnt' = 0x0000000b : 11 }
getAttributeForConnection(0) { kConnectionDisplayParameters 'parm' = 'ølda' , 'thrm' kTempAttribute, 'dith' , 'cyuv' kConnectionColorMode, ' bpc' kConnectionColorDepthsSupported, 'colr' kConnectionColorModesSupported, 'dpir' kConnectionHandleDisplayPortEvent, 'rgsc' kConnectionRedGammaScale, 'ggsc' kConnectionGreenGammaScale, 'bgsc' kConnectionBlueGammaScale, 'vblm' kConnectionVBLMultiplier }
getAttributeForConnection(0) { kTempAttribute 'thrm' = 0x0000002c : 44 }
getAttributeForConnection(0) { 'dith' = 0x00000000 : false }
getAttributeForConnection(0) { kConnectionColorMode 'cyuv' = 0x00000001 : RGB, }
getAttributeForConnection(0) { kConnectionColorModesSupported 'colr' = 0x10001001 : RGB,RGBLimited,Auto, }
getAttributeForConnection(0) { kConnectionHandleDisplayPortEvent 'dpir' = 000000000000000000000000000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa }
getAttributeForConnection(0) { kConnectionRedGammaScale 'rgsc' = 0x00010000 : 0x10000 }
getAttributeForConnection(0) { kConnectionGreenGammaScale 'ggsc' = 0x00010000 : 0x10000 }
getAttributeForConnection(0) { kConnectionBlueGammaScale 'bgsc' = 0x00010000 : 0x10000 }
getAttributeForConnection(0) { kConnectionVBLMultiplier 'vblm' = 0x00010000 : 0x10000 }
getAttribute { kIOHardwareCursorAttribute 'crsr' = 0x00000001 : true }
getAttributeForConnection(0) { kConnectionEnable 'enab' = 0x00000001 : true }
getAttribute { kIOMirrorAttribute 'mirr' = 0x4000009f : kIOMirrorHWClipped,?0x9f, }
getAttribute { kIOVRAMSaveAttribute 'vrsv' = 0x00000001 : true }
getAttribute { 'hdcs' = 0x00000000 : 0x0 } result:kIOReturnUnsupported
getAttribute { kIOClamshellStateAttribute 'clam' = 0x00000000 : false }
getAttribute { kIOMirrorDefaultAttribute 'mrdf' = 0x00000000 : }
setAttribute { kIOCapturedAttribute 'capd' = 0x00000000 : false }
setAttribute { kIOFBSpeedAttribute ' dgs' = 0x0000001b : 27 }
setAttributeForConnection(0) { kConnectionRedGammaScale 'rgsc' = 0x00010000 : 0x10000 }
setAttributeForConnection(0) { kConnectionGreenGammaScale 'ggsc' = 0x00010000 : 0x10000 }
setAttributeForConnection(0) { kConnectionBlueGammaScale 'bgsc' = 0x00010000 : 0x10000 }
setAttributeForConnection(0) { kConnectionVBLMultiplier 'vblm' = 0x00010000 : 0x10000 }
setAttributeForConnection(0) { kConnectionHandleDisplayPortEvent 'dpir' = 0x00000000 : ?0x0 }
setAttributeForConnection(0) { kConnectionColorMode 'cyuv' = 0x00000001 : RGB, }
setAttributeForConnection(0) { kConnectionColorModesSupported 'colr' = 0x10001001 : RGB,RGBLimited,Auto, }
setAttributeForConnection(0) { kTempAttribute 'thrm' = 0x0000002c : 44 }
setAttributeForConnection(0) { kIODisplaySelectedColorModeKey 'cmod' = 0x00000001 : 1 } result:kIOReturnUnsupported
setAttributeForConnection(0) { 'dith' = 0x00000000 : false }
setAttributeForConnection(0) { kConnectionFlushParameters 'flus' = 0x00000001 : true }
]; // IOFBAttributesOld IOFrameBuffer drivers such as for Kepler use attributes for setting bpc. The DetailedTimingInformation for the display modes shown by AllRez won't specify a bpc.
Newer IOFrameBuffer drivers don't use attributes for setting bpc. They'll specify a bpc in the DetailedTimingInformation plus other info that describes the pixel:
encodings(RGB,) bpc(8,) colorimetry(NativeRGB,) dynamicrange(SDR,) dsc(1920x2160 12bpp)So for these GPUs, if you wanted 6 bpc, then a patch to add a timing containing 6 bpc would need to be added.
There may be other generations of IOFramebuffer with other behaviours. For example Power Macs could be set to a 8 bit indexed mode (256 colors) or a 5bpc mode (Thousands of colors) but those are framebuffer modes.
Apple Silicon Macs don't use IOFramebuffer.
SwitchResX reports a 540 MHz pixel clock limit (not 450 — that was a typo) only on 10.6.8 and 10.7.5. On 10.8.5 and later versions, it reports 360 MHz. I haven't tried >360 MHz modes on 10.8.5 or later versions yet.
I've done some more testing. On 10.6.8, 400 MHz pixel clock works... but only at 3000×2000. For instance, 3240×2160 at 53.066 Hz, 3480×2320 at 46.348 Hz, 3600×2400 at ≈43.5 Hz or 3840×2560 at ≈38 Hz all result in a black screen. Does that make any sense?
I can set Thousands of colours in SwitchResX in OS X 10.9.5 and earlier versions (on the iMac with the 4850 at least), but not in 10.10.5 and later versions.
Last edited:
I'm working on 10.6 compatibility for AllRez. Hopefully that might give some info (don't know yet if it can read DPCD).
Needs more info. Do those exact modes work on a newer Mac/GPU? Can you get modes > 3000x2000 by using lower pixel clock?
Interesting. My GTX 680 works from Mac OS X 10.4 but it doesn't have a driver until 10.8 or 10.9 so there's no resolution or color changing until the driver. I'd like to see AllRez output from that when it's updated to work on older macOS versions. While I'm working on that, you could try installing OCLP to a EFI or FAT partition and see if it can be used to boot old macOS versions on your old Mac. Install without spoofing, unless you want to try installing a new macOS. In that case, I would have one OCLP partition without spoofing and one with spoofing (if spoofing is required for newer macOS versions). OCLP is required to inject Lilu and WhateverGreen earlier in the boot process - early enough to make patches to IOFramebuffer and WindowServer before they get used. Once you get that working, then you can replace Lilu and WhateverGreen with my forks and try that. Of course, using my Lilu means you need to recompile any other kext that uses Lilu.
I can set 256 colours on my
MacBookPro3,1 running Tiger:Yes, they all work fine on an Intel Iris Pro 6200 apart from 3840×2560 which exceeds its 2400-line height limit in macOS.
Yes. I've done some more testing with the 4850 on 10.6.8. Basically, the higher the resolution, the lower the maximum pixel clock it will do.
- 3240×2160 52.6 Hz (395.75 MHz): works
- 3240×2160 52.7 Hz (396.51 MHz): doesn't work
- 3480×2320 45.3 Hz (391.06 MHz): works
- 3480×2320 45.4 Hz (391.81 MHz): doesn't work
- 3600×2400 42.1 Hz (388.06 MHz): works
- 3600×2400 42.2 Hz (389.06 MHz): doesn't work
- 3840×2560 36.7 Hz (382.06 MHz): works
- 3840×2560 36.8 Hz (383.31 MHz): doesn't work
Last edited:
Yup, I can see the 256 color dithering in your screenshot. I think Power Macs can still do 1 bit (B&W), 2 bit (4 color), 4 bit color (16 color) as well in Mac OS X, but I need to get 10.4 working properly on my Power Mac 8600 to be sure.
That's on your iMac 3.1 21.5" (4K, Late 2015).
Strange. One would think that only the pixel clock matters. The Intel Iris Pro 6200 can do the "doesn't work" modes?
I wonder if the 4850 has a minimum requirement for horizontal or vertical blanking time. Take the number of blanking pixels and divide by the pixel clock.
Code:
calctiming () {
w=$1
h=$2
f=$3
timinginfo=$(edid-decode --cvt w=$w,h=$h,fps=$f,rb=1)
#echo $timinginfo
eval $(
perl -nE '
if (/(\w+): +(\d+)x(\d+) +(\d+.\d+) Hz +(\d+:\d+) +(\d+.\d+) kHz +(\d+.\d+) MHz/) {
printf ("pixelclock=%s\nhrefresh=%s\nvrefresh=%s\n", $7, $6, $4)
}
if (/ +Hfront +(\d+) +Hsync +(\d+) +Hback +(\d+)/) { printf ("hblank=%s\n", $1 + $2 + $3) }
if (/ +Vfront +(\d+) +Vsync +(\d+) +Vback +(\d+)/) { printf ("vblank=%s\n", $1 + $2 + $3) }
' <<< "$timinginfo"
)
printf "%dx%d %7.3fHz %8.3fkHz %8.3fMHz hblank:(%3d pixels = %.3fns) vblank:(%2d lines = %.3fµs) %.3fms\n" \
${w} ${h} ${vrefresh} ${hrefresh} ${pixelclock} \
${hblank} $(bc -l <<< "$hblank / $pixelclock * 1000") \
${vblank} $(bc -l <<< "$vblank / $hrefresh * 1000") \
$(bc -l <<< "($hblank + $w) * ($vblank + $h) / $pixelclock / 1000")
}
calctiming 3240 2160 52.6
calctiming 3240 2160 52.7
calctiming 3480 2320 45.3
calctiming 3480 2320 45.4
calctiming 3600 2400 42.1
calctiming 3600 2400 42.2
calctiming 3840 2560 36.7
calctiming 3840 2560 36.8
3240x2160 52.573Hz 116.397kHz 395.750MHz hblank:(160 pixels = 404.296ns) vblank:(54 lines = 463.929µs) 19.021ms
3240x2160 52.673Hz 116.618kHz 396.500MHz hblank:(160 pixels = 403.531ns) vblank:(54 lines = 463.050µs) 18.985ms
3480x2320 45.295Hz 107.349kHz 390.750MHz hblank:(160 pixels = 409.469ns) vblank:(50 lines = 465.771µs) 22.078ms
3480x2320 45.382Hz 107.555kHz 391.500MHz hblank:(160 pixels = 408.685ns) vblank:(50 lines = 464.878µs) 22.035ms
3600x2400 42.099Hz 103.059kHz 387.500MHz hblank:(160 pixels = 412.903ns) vblank:(48 lines = 465.753µs) 23.753ms
3600x2400 42.181Hz 103.258kHz 388.250MHz hblank:(160 pixels = 412.106ns) vblank:(48 lines = 464.855µs) 23.708ms
3840x2560 36.698Hz 95.562kHz 382.250MHz hblank:(160 pixels = 418.574ns) vblank:(44 lines = 460.434µs) 27.249ms
3840x2560 36.780Hz 95.812kHz 383.250MHz hblank:(160 pixels = 417.482ns) vblank:(45 lines = 469.670µs) 27.189msNo, the problem doesn't seem to be with blanking times.
For horizontal blanking, the horizontal blanking time decreases as pixel clock increases which might be a problem except we see that 404.296ns is good while 417.482ns (for the higher resolution) is bad even though it has more time.
For vertical blanking, the number of blanking lines decreases with higher pixel clocks so that the vertical blanking time remains roughly constant. In the case of 3840x2560, the vertical blanking time is greater for the "doesn't work" mode since the higher pixel clock causes an extra vertical blanking line.
I've never seen greyscale or less than 256 colour options being available on any of my PowerPC Macs in Mac OS X 10.0…10.5. Developer Preview 3 has a greyscale option but it's greyed out (no pun intended; 0 Hz refresh is due to running in QEMU). Rhapsody (Mac OS X Server 1.x) has an accessible greyscale option (at least on a Lombard).
Yup.
It can do the "doesn't work" modes from my previous post, yup. I've done some more testing. These modes have not been confirmed on the Iris Pro 6200 yet.
2560×1440 100.002Hz 411.000MHz works:
1920×1080 174.597Hz 418.000MHz works:
1280×720 372.243Hz 424.000MHz works:
960×690 500.000Hz 425.600MHz works:
In any of these cases, increasing the pixel clock by 1 MHz (and letting SwitchResX increase the scan rates accordingly) breaks things. Modes with a refresh rate of 502 Hz or higher are rejected by SwitchResX regardless of resolution and pixel clock, so testing whether higher pixel clocks can be achieved at even lower resolutions would need more blanking I guess.
Last edited:
I could be remembering wrong. < 8bit color is possible from my Power Mac 8600 built-in video in Mac OS 9, but I think newer PCI cards start at 8 bit?
So the trend of lower resolutions allowing higher pixel clocks continues until 502 Hz (though you didn't list anything beyond 425).
You've been testing CVT-RB modes. Did you try CVT or GTF modes? Those are for CRT and have much larger horizontal or vertical blanking areas.
I have AllRez working on 10.5.8 Power Mac and 10.6.8 Intel Mac. I need to check 10.4.11 and later Mac OS versions.
There's not a lot of info there but maybe there would be more for 10.6 if I had a GPU supported by 10.6 installed. One think I want to see is if DisplayPort info can be retrieved in 10.6.
On 10.5.8 Power Mac, it reports modes with 16bpp as having 5bpc as expected for a PowerMac GPU (it's a GTX 7800 in a Quad G5). It also has 32bpp 8bpc modes like Intel Macs use. For 8bpp it reports 2bpc which would only be 64 colors (4 levels per component). A normal 8bit color table has 256 colors (16 levels of red, green, blue, and gray; and 6 levels per component using these 4bpc levels {0,3,6,9,12,15}). I don't know if Mac OS X is using a 2bpc color table or a normal 8 bit color table. The 4 levels used by a 2bpc color table would translate to these 4bpc levels {0,5,10,15} which doesn't match the normal 8bit color table.
Not yet, but I will do that.
I have four Macs that can run 10.6 and have native DisplayPort, using ATI (Mobility) Radeon HD 4850, Intel HD Graphics 3000, NVIDIA GeForce 9400M and NVIDIA GeForce 320M GPUs. I'd be happy to test your version of AllRez on them.
Another — totally unrelated — question since you have a NVIDIA Maxwell GPU: can it do 5K60 6bpc RGB via DisplayPort 1.2 HBR2 (in Windows)?
Last edited:
Decided to mess around with Adium for it's IRC plugin, which is about the only thing left that works AFAIK. Installed the InLine plugin (too enable viewing images from links posted in chat), NickColor (to colorize nicknames in chat for easier viewing), and the Messages dock icon. Works really well for Discord (bitlbee-discord) on Snow Leopard.
