iMac G3 mod - Video Connector

[oshimai]

I don't know why but after a few reboots the control panel would just not work at 115200 bps anymore.
I changed nothing.

Then I tried the async version and that also didn't work anymore.

It still works fine at 9600 bps though, actually at anything that isn't 115200.

W T F... I'm lost.

Can you try lowering the serial port speed down to 9600 just for testing? I hope it's not too painful to update the sketch on your board. I made myself a one click batch file once I found out the Arduino IDE lets you save the Sketch as a hex file for direct flashing.

Try the latest code from the repo. You can open crtcpl.exe with /log and get a detailed debug log of everything it does with the serial port! The log shows up in your temp folder.

Something like this is whats written when it works:

15/05/2020 18:06:16    ------------- Main -------------
15/05/2020 18:06:16    Try to connect to serial port COM3 at rate 9600 from settings.
15/05/2020 18:06:16    ------------- Open -------------
15/05/2020 18:06:16    Create serial port. Port=COM3, Rate=9600
15/05/2020 18:06:16    Open the port now.
15/05/2020 18:06:16    Compatibility check now.
15/05/2020 18:06:16    ------------- SendCommandInternal -------------
15/05/2020 18:06:16    ------------- Checksum -------------
15/05/2020 18:06:16    The checksum was calculated to be 0xF3.
15/05/2020 18:06:16    Send this payload to microcontroller:
15/05/2020 18:06:16    { 0x07, 0x01, 0x01, 0x00, 0x00, 0x03, 0xF3, 0x04, 0x0A }
15/05/2020 18:06:16    Wait for response now.
15/05/2020 18:06:16    Iteration 0
15/05/2020 18:06:16    Read so far from serial port: 1 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 1
15/05/2020 18:06:16    Read so far from serial port: 3 bytes. In this round: 2 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 2
15/05/2020 18:06:16    Read so far from serial port: 4 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 3
15/05/2020 18:06:16    Read so far from serial port: 7 bytes. In this round: 3 bytes.
15/05/2020 18:06:16    Length from response: 1 bytes
15/05/2020 18:06:16    Read too little according to length. Read more.
15/05/2020 18:06:16    Iteration 4
15/05/2020 18:06:16    Read so far from serial port: 8 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Length from response: 1 bytes
15/05/2020 18:06:16    Got response OK!
15/05/2020 18:06:16    ------------- Checksum -------------
15/05/2020 18:06:16    The checksum was calculated to be 0xF1.
15/05/2020 18:06:16    The response from microcontroller was:
15/05/2020 18:06:16    { 0x06, 0x01, 0x01, 0x03, 0x03, 0xF1, 0x04, 0x0A }
15/05/2020 18:06:16    The command response is:
15/05/2020 18:06:16    { 0x03 }
15/05/2020 18:06:16    Serial port is open.
15/05/2020 18:06:16    Main window opening now.
15/05/2020 18:06:17    ------------- SendCommand -------------
15/05/2020 18:06:17    ------------- SendCommandInternal -------------
15/05/2020 18:06:17    ------------- Checksum -------------
15/05/2020 18:06:17    The checksum was calculated to be 0xF1.
15/05/2020 18:06:17    Send this payload to microcontroller:
15/05/2020 18:06:17    { 0x07, 0x02, 0x02, 0x00, 0x00, 0x03, 0xF1, 0x04, 0x0A }
15/05/2020 18:06:17    Wait for response now.
15/05/2020 18:06:17    Iteration 0
15/05/2020 18:06:17    Read so far from serial port: 1 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 1
15/05/2020 18:06:17    Read so far from serial port: 2 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 2
15/05/2020 18:06:17    Read so far from serial port: 5 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 3
15/05/2020 18:06:17    Read so far from serial port: 6 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 4
15/05/2020 18:06:17    Read so far from serial port: 9 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 5
15/05/2020 18:06:17    Read so far from serial port: 10 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 6
15/05/2020 18:06:17    Read so far from serial port: 13 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 7
15/05/2020 18:06:17    Read so far from serial port: 14 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 8
15/05/2020 18:06:17    Read so far from serial port: 17 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 9
15/05/2020 18:06:17    Read so far from serial port: 18 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 10
15/05/2020 18:06:17    Read so far from serial port: 21 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 11
15/05/2020 18:06:17    Read so far from serial port: 22 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 12
15/05/2020 18:06:17    Read so far from serial port: 25 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 13
15/05/2020 18:06:17    Read so far from serial port: 26 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 14
15/05/2020 18:06:17    Read so far from serial port: 27 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Got response OK!
15/05/2020 18:06:17    ------------- Checksum -------------
15/05/2020 18:06:17    The checksum was calculated to be 0xE1.
15/05/2020 18:06:17    The response from microcontroller was:
15/05/2020 18:06:17    { 0x06, 0x02, 0x14, 0xFE, 0x93, 0x93, 0x8F, 0x80, 0x80, 0x78, 0xB0, 0xF0, 0x4D, 0x9A, 0x9B, 0xCB, 0x19, 0x7B, 0xC6, 0x7B, 0x0A, 0x42, 0xC6, 0x03, 0xE1, 0x04, 0x0A }
15/05/2020 18:06:17    The command response is:
15/05/2020 18:06:17    { 0xFE, 0x93, 0x93, 0x8F, 0x80, 0x80, 0x78, 0xB0, 0xF0, 0x4D, 0x9A, 0x9B, 0xCB, 0x19, 0x7B, 0xC6, 0x7B, 0x0A, 0x42, 0xC6 }

 

[rockyhill]

I don't know why but after a few reboots the control panel would just not work at 115200 bps anymore.
I changed nothing.

Then I tried the async version and that also didn't work anymore.

It still works fine at 9600 bps though, actually at anything that isn't 115200.

W T F... I'm lost.

Can you try lowering the serial port speed down to 9600 just for testing? I hope it's not too painful to update the sketch on your board. I made myself a one click batch file once I found out the Arduino IDE lets you save the Sketch as a hex file for direct flashing.

Try the latest code from the repo. You can open crtcpl.exe with /log and get a detailed debug log of everything it does with the serial port! The log shows up in your temp folder.

Something like this is whats written when it works:

15/05/2020 18:06:16    ------------- Main -------------
15/05/2020 18:06:16    Try to connect to serial port COM3 at rate 9600 from settings.
15/05/2020 18:06:16    ------------- Open -------------
15/05/2020 18:06:16    Create serial port. Port=COM3, Rate=9600
15/05/2020 18:06:16    Open the port now.
15/05/2020 18:06:16    Compatibility check now.
15/05/2020 18:06:16    ------------- SendCommandInternal -------------
15/05/2020 18:06:16    ------------- Checksum -------------
15/05/2020 18:06:16    The checksum was calculated to be 0xF3.
15/05/2020 18:06:16    Send this payload to microcontroller:
15/05/2020 18:06:16    { 0x07, 0x01, 0x01, 0x00, 0x00, 0x03, 0xF3, 0x04, 0x0A }
15/05/2020 18:06:16    Wait for response now.
15/05/2020 18:06:16    Iteration 0
15/05/2020 18:06:16    Read so far from serial port: 1 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 1
15/05/2020 18:06:16    Read so far from serial port: 3 bytes. In this round: 2 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 2
15/05/2020 18:06:16    Read so far from serial port: 4 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Read too little to have valid response. Read more.
15/05/2020 18:06:16    Iteration 3
15/05/2020 18:06:16    Read so far from serial port: 7 bytes. In this round: 3 bytes.
15/05/2020 18:06:16    Length from response: 1 bytes
15/05/2020 18:06:16    Read too little according to length. Read more.
15/05/2020 18:06:16    Iteration 4
15/05/2020 18:06:16    Read so far from serial port: 8 bytes. In this round: 1 bytes.
15/05/2020 18:06:16    Length from response: 1 bytes
15/05/2020 18:06:16    Got response OK!
15/05/2020 18:06:16    ------------- Checksum -------------
15/05/2020 18:06:16    The checksum was calculated to be 0xF1.
15/05/2020 18:06:16    The response from microcontroller was:
15/05/2020 18:06:16    { 0x06, 0x01, 0x01, 0x03, 0x03, 0xF1, 0x04, 0x0A }
15/05/2020 18:06:16    The command response is:
15/05/2020 18:06:16    { 0x03 }
15/05/2020 18:06:16    Serial port is open.
15/05/2020 18:06:16    Main window opening now.
15/05/2020 18:06:17    ------------- SendCommand -------------
15/05/2020 18:06:17    ------------- SendCommandInternal -------------
15/05/2020 18:06:17    ------------- Checksum -------------
15/05/2020 18:06:17    The checksum was calculated to be 0xF1.
15/05/2020 18:06:17    Send this payload to microcontroller:
15/05/2020 18:06:17    { 0x07, 0x02, 0x02, 0x00, 0x00, 0x03, 0xF1, 0x04, 0x0A }
15/05/2020 18:06:17    Wait for response now.
15/05/2020 18:06:17    Iteration 0
15/05/2020 18:06:17    Read so far from serial port: 1 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 1
15/05/2020 18:06:17    Read so far from serial port: 2 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 2
15/05/2020 18:06:17    Read so far from serial port: 5 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 3
15/05/2020 18:06:17    Read so far from serial port: 6 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Read too little to have valid response. Read more.
15/05/2020 18:06:17    Iteration 4
15/05/2020 18:06:17    Read so far from serial port: 9 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 5
15/05/2020 18:06:17    Read so far from serial port: 10 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 6
15/05/2020 18:06:17    Read so far from serial port: 13 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 7
15/05/2020 18:06:17    Read so far from serial port: 14 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 8
15/05/2020 18:06:17    Read so far from serial port: 17 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 9
15/05/2020 18:06:17    Read so far from serial port: 18 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 10
15/05/2020 18:06:17    Read so far from serial port: 21 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 11
15/05/2020 18:06:17    Read so far from serial port: 22 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 12
15/05/2020 18:06:17    Read so far from serial port: 25 bytes. In this round: 3 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 13
15/05/2020 18:06:17    Read so far from serial port: 26 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Read too little according to length. Read more.
15/05/2020 18:06:17    Iteration 14
15/05/2020 18:06:17    Read so far from serial port: 27 bytes. In this round: 1 bytes.
15/05/2020 18:06:17    Length from response: 20 bytes
15/05/2020 18:06:17    Got response OK!
15/05/2020 18:06:17    ------------- Checksum -------------
15/05/2020 18:06:17    The checksum was calculated to be 0xE1.
15/05/2020 18:06:17    The response from microcontroller was:
15/05/2020 18:06:17    { 0x06, 0x02, 0x14, 0xFE, 0x93, 0x93, 0x8F, 0x80, 0x80, 0x78, 0xB0, 0xF0, 0x4D, 0x9A, 0x9B, 0xCB, 0x19, 0x7B, 0xC6, 0x7B, 0x0A, 0x42, 0xC6, 0x03, 0xE1, 0x04, 0x0A }
15/05/2020 18:06:17    The command response is:
15/05/2020 18:06:17    { 0xFE, 0x93, 0x93, 0x8F, 0x80, 0x80, 0x78, 0xB0, 0xF0, 0x4D, 0x9A, 0x9B, 0xCB, 0x19, 0x7B, 0xC6, 0x7B, 0x0A, 0x42, 0xC6 }

O.K. I'll lower the baud rate and do some testing and report back. The logging will definitely be useful.

 

[oshimai]

I pushed one more change

If you compile with

xbuild /p:Configuration=Mono /p:DefineConstants="ROCKYHILL" crtcpl.sln

you should get the old async UCCom back.

It might work better for you? The async version has no logging because I'm afraid that might break it again.

Something as simple as serial communication turned out to be so fiddly. :/

 

[rockyhill]

@oshimai

So very odd.........

Now I can't communicate at any baud rate! I'm not sure what is going now.
The worst part is that it gets stuck in a crash loop because it doesn't remember the last
serial port and baud rate since it didn't successfully connect.

By crash loop I mean it somehow crashes the atmega chip when it tries to communicate at the wrong baud rate.
I have to pull the power cord in order to get the mcu into a stable state. It's driving me nuts!

I'm going to try and checkout a previous commit to see If can get into a stable state.
[automerge]1589565842[/automerge]
@oshimai

Does the GUI send the EEPROM update command for every change?

 

[rockyhill]

@oshimai

If I replace UCComm.cs with the version that swallows the exception , I can communicate at all baud rates with the current version of the GUI.
That said, it isn't pretty, I think there are an excessive number of checks now. I can't seem to manipulate anything when it throws an error,
I can't even close the application if there is a communications error. I guess cancel also tries to confirm communications with the mcu?

How is it on your end?

 

[rockyhill]

@oshimai

I plan to work on my sketch and on the GUI until I have a working configuration. Once stable, I'll send you what I have so you can compare
when you have a chance.

I think I'm close.

 

[oshimai]

It's currently stable on my end with 9600 bps and the new UCCom that is not async.

The serial communications flow is like this:

(start crtcpl)

- Open serial port
- Check version byte

(Main window opens)

- Get SRAM values
- If you scroll a slider or set a button, send appropriate change setting command
- If you click Defaults, restore to defaults
- If you click Apply or OK, write to EEPROM
- If you click Cancel, restore from EEPROM
- If you open the settings analyzer and click Refresh, it gets the SRAM values to put them in the list view

That's how it works with my sketch.

The thing is that the serial communication should never fail. Both sides know the protocol and it is so simple there is little to no room for errors to creep in, so the only way it can fail is if there's a parsing error somewhere

I pushed another update that adds a /reset switch so the settings go away if you can't get the program to work anymore with whatever was saved last.

I think mono writes them to a folder under .config, which you can delete. Try "locate TAKEMURA" in your terminal. It uses whatever is entered as a company name for the .NET assembly as the folder name and I just put a random name there.
[automerge]1589572796[/automerge]

@oshimai

If I replace UCComm.cs with the version that swallows the exception , I can communicate at all baud rates with the current version of the GUI.

UCComRockyHill.cs should be doing (almost) exactly that.

Does the xbuild command from https://forums.macrumors.com/thread...r.1712095/page-15?post=28470564#post-28470564 not work?

 

[rockyhill]

@oshimai

UCComRockyHill.cs should be doing (almost) exactly that.

Does the xbuild command from https://forums.macrumors.com/thread...r.1712095/page-15?post=28470564#post-28470564 not work?

Yes it did improve things but I still have communications issues. at this point I think I need to revisit my implementation
of your protocol. I think it might have bugs.

Don't make any more changes because of my testing just yet. I want to verify some things because the changes you've made are sound
and at this point I believe you have ironed out the mono related wrinkles and the issues that are left are probably because of my sketch.

 

[rockyhill]

@oshimai

I finally found the bug! It turns out that the main issue was that I needed a do while loop instead of a while loop.
The detection logic was haphazard because the final byte was read after the check was made.
I confirmed that it works with both 115200 and 9600.

Sorry for driving you crazy!


Here is a video of it in action

 

[DrJekyll_XYZ]

What's the plan for implementing these controls into the internal boards?

 

[oshimai]

I finally found the bug! It turns out that the main issue was that I needed a do while loop instead of a while loop.

It's always the little bugs that take the longest time to find.

But awesome!!! Good to see that it finally works for you. I'll merge the PR for the translation in a little bit.

Here's mine finished and installed as a way to fill an awkward corner in the living room.

What's the plan for implementing these controls into the internal boards?

Do you mean making the control panel app usable? I think Rocky Hill has just done that. He updated his Arduino sketch and if you flash it onto the microcontroller of his PCB design, it will start working straight away. At least that's how I understood it.

 

[rockyhill]

What's the plan for implementing these controls into the internal boards?

Yes, the boards work the same except now they can communicate with oshimais GUI .
[automerge]1589631576[/automerge]

It's always the little bugs that take the longest time to find.

But awesome!!! Good to see that it finally works for you. I'll merge the PR for the translation in a little bit.

Here's mine finished and installed as a way to fill an awkward corner in the living room.

Do you mean making the control panel app usable? I think Rocky Hill has just done that. He updated his Arduino sketch and if you flash it onto the microcontroller of his PCB design, it will start working straight away. At least that's how I understood it.

It looks really nice, I can't wait to get mine setup in the house. I actually already have a wife-approved location
for it. Nice

 

[rockyhill]

@oshimai

Here is your GUI working perfectly on a raspberry pi 3.

 

[elvisa]

Many thanks for your doco Rocky. Watching your most recent video, it looks like the iMac you have might be the 33MHz model. I've only just realised the 333MHz model I'm attempting to use is radically different internally.

Rather than the J20 header, all that sticks out is an old style DB15 (two rows, rather than the 3 rows of a DE15 VGA cable) RGB cable.

You can see it in the iFixIt teardown here:

iMac G3 Model M4984 Logic Board Replacement

The iMac G3 (Tray-Loading) The iMac G3 was Apple's new G3 all-in-one. It had tons of new features, and removed all old interfaces. It was released...

www.ifixit.com

A better shot of where it connects to on the monitor's chassis is further down in this guide:

iMac G3 Model M4984 Power Supply Replacement

The iMac uses an incredibly hard to get to power supply. It has 24-Pins. This will require taking the iMac fully apart.

www.ifixit.com

iFixIt have some service manuals online. I'm going to dig through those and see if I can find anything that references the i2c pins (I suspect they're the "monitor sense" pins, but I just want to make sure):

iMac G3 Service Manual - iFixit

Repair your electronics yourself. iFixit is the repair manual you can edit. We sell tools, parts and upgrades for Apple Mac, iPod, iPhone, iPad, and MacBook as well as game consoles.

www.ifixit.com

I've finally gotten around to testing this on an iMac G3/333 (tray load model). Everymac says that this is identical to the original 266 models, merely with a processor speed bump.

There's no connector internally to connect I2C pins to. Best guess is that I2C goes in over the DB15 RGB connector (one row of 8, one row of 7, same signal as a DE15 VGA cable). All documentation I can find says the pins of interest are:

Pin 4: Monitor Sense 0
Pin 7: Monitor Sense 1
Pin 10: Monitor Sense 2

For init_avad.py to not error, I need at least SDA connectted to Pin 4. SLC attached to either of the remaining pins doesn't appear to make a difference.

When SDA is attached to Pin 4, running "i2cdetect -y 1" reports:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f  
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77

Which doesn't feel right (I should only get a couple of values, right?). At all other times there's no output.

I have the R, G, B, H, V and corresponding ground signals wired back up to my Linux laptop generating a signal, and xrandr reports:

$ xrandr
VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768      60.00*  
800x600 60.32 56.25
848x480 60.00
640x480 59.94

$ xrandr --verbose
VGA-1 connected 1024x768+0+0 (0x6a) normal (normal left inverted right x axis y axis) 0mm x 0mm
        Identifier: 0x43
Timestamp: 13487935
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 1
CRTCs: 0 1 2
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
link-status: Good
supported: Good, Bad
CONNECTOR_ID: 71
supported: 71
non-desktop: 0
range: (0, 1)
1024x768 (0x6a) 65.000MHz -HSync -VSync *current
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
v: height 768 start 771 end 777 total 806 clock 60.00Hz
800x600 (0x79) 40.000MHz +HSync +VSync
h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz
v: height 600 start 601 end 605 total 628 clock 60.32Hz
800x600 (0x7a) 36.000MHz +HSync +VSync
h: width 800 start 824 end 896 total 1024 skew 0 clock 35.16KHz
v: height 600 start 601 end 603 total 625 clock 56.25Hz
848x480 (0x32e) 33.750MHz +HSync +VSync
h: width 848 start 864 end 976 total 1088 skew 0 clock 31.02KHz
v: height 480 start 486 end 494 total 517 clock 60.00Hz
640x480 (0x88) 25.175MHz -HSync -VSync
h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz
v: height 480 start 490 end 492 total 525 clock 59.94Hz

They look like the accurate modes this monitor supports, so I feel like there's at least something working there. I assume those modes are being discovered by EDID, but I don't have pins 4/7/10 wired to the laptop, so I'm a bit confused how it knows about them.

Any tips on what to do next? I don't have a logic analyser, but if there's a way I can use the RPi to sniff the I2C bus from the original logic board, I'm willing to give that a go (sorry for my uselessness, I'm a dirty sysadmin, and logic level stuff is well beyond me).

 

[rockyhill]

@elvisa
Hi Dan,

I learned about the differences between our two models with you on this forum and since I've never opened your model
of iMac I had no idea how radically different they are and how much easier it is to mod yours.

Although I have no hands-on experience with your model I do have a suggestion and an idea to offer.

From previous posts I've learned that in your case there is no initialization needed which means that you actually don't need
to run the ivad.py script, it should just be ready to rock when powered on.

Of the three supported resolutions on your iMac, one is a standard vesa resolution so the raspberry pi supports it with an easy change
to the config.txt file.

Since you've wired the R, G, B, H, V and lines(you'll need at least one ground though), it should be as simple as adding the following lines to the /boot/config.txt to let the pi know how to ouput its video.

#iMac G3 settings
hdmi_group=2
hdmi_mode=18

However, If memory serves me, you were attempting to do this with a raspberry pi 4 which has two video ports.
This means that the above settings might need to be slightly modified in your case.

From
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

HDMI mode options
Note for Raspberry Pi4B users: Because the Raspberry Pi 4B has two HDMI ports, some HDMI commands can be applied to either port. You can use the syntax <command>:<port>, where port is 0 or 1, to specify which port the setting should apply to. If no port is specified, the default is 0. If you specify a port number on a command that does not require a port number, the port is ignored. Further details on the syntax and alternatives mechanisms can be found in the HDMI section on the conditionals page of the documentation.

Here is an example of the conditional you might need
From
https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md

[HDMI:0]
  hdmi_group=2
  hdmi_mode=18
[HDMI:1]
  hdmi_group=2
  hdmi_mode=18

Take a look at Stephen Ferris's web page where he describes what he did and although it wasn't with a raspberry pi
The concept is the same.

@WhatDoYouGuysWannaDo

Stephen do you have any wiring pointers?

I think you'll be up and running sooner than you think and I can't wait to see you mod up and running!

 

[elvisa]

Take a look at Stephen Ferris's web page where he describes what he did

Thanks Rocky. And if it was that easy all along and I was overcomplicating it, I'll be quite embarrassed!

 

[rockyhill]

Thanks Rocky. And if it was that easy all along and I was overcomplicating it, I'll be quite embarrassed!

No way, that's not over complicating it at all! We're doing stuff to these things that they were never meant for.
I don't think there's a better way to learn.

 

[rockyhill]

I finally purchased and received a Raspberry pi 4 for the iMac G3 monitor and I think I've found a bug
in Raspian for the raspberry pi4 . The image is shifted off screen after the udev kernel device manager
is loaded.

I've added an issue to the RPI4 repo on github with a description and videos. If anyone has a raspberry pi4
and can recreate this, please do and add a comment. There is evidence that it is indeed the operating system
and not the hardware because Ubuntu 20.04 for the raspberry pi4 boots correctly.

Here is the reported issue

https://github.com/RPi-Distro/repo/issues/173
https://github.com/raspberrypi/firmware/issues/1396

Below are the videos

 

[oshimai]

Could it be that you have something like /lib/udev/console-setup-tty and it's turning your console from whatever the default is to some sort of advanced high-res mode with unicode support?

Maybe the raspberry firmware notices this and squishes the screen to get it to fit while still maintaining the output settings you put in config.txt

It's just a wild guess, but I've seen that happen and it screwed up several older KVM/IPs at work. :/

I've settled for this SBC for future projects (eMac)

DFR0546 | Digi-Key Electronics

Order today, ships today. DFR0546 – m3-8100Y LattePanda Alpha 864s noWin10 Key - MPU Embedded Evaluation Board from DFRobot. Pricing and Availability on millions of electronic components from Digi-Key Electronics.

www.digikey.com

Costs about 10x as much though.

 

[rockyhill]

Could it be that you have something like /lib/udev/console-setup-tty and it's turning your console from whatever the default is to some sort of advanced high-res mode with unicode support?

Maybe the raspberry firmware notices this and squishes the screen to get it to fit while still maintaining the output settings you put in config.txt

It's just a wild guess, but I've seen that happen and it screwed up several older KVM/IPs at work. :/

I've settled for this SBC for future projects (eMac)

DFR0546 | Digi-Key Electronics

Order today, ships today. DFR0546 – m3-8100Y LattePanda Alpha 864s noWin10 Key - MPU Embedded Evaluation Board from DFRobot. Pricing and Availability on millions of electronic components from Digi-Key Electronics.

www.digikey.com

Costs about 10x as much though.

Interesting thought, I'll have to look into that and do some checking and testing.

Good choice for an SBC, I've seen some really good reviews on that one, unfortunately it's a little too
pricey for me at the moment. Are you planning on putting that in your eMac mod?

 

[oshimai]

Yes. Subject to certain conditions my wife has permitted me to do more hardware tinkering. I guess the privilege will be revoked again once she sees this month's credit card statement, so I have to hurry it up. If I stop posting you'll know why... There's an emac repo on my github that includes the EDID and some pinouts. More to come later.


Back to the topic at hand though, if you completely disable starting the udev service, does the screen still go weird? If not, you've found your culprit: it's definitely one of the udev rules. I'm just saying that since I looks like your issue on the rpi firmware tracker will probably just get ignored like most of the others.

 

[rockyhill]

Yes. Subject to certain conditions my wife has permitted me to do more hardware tinkering. I guess the privilege will be revoked again once she sees this month's credit card statement, so I have to hurry it up. If I stop posting you'll know why... There's an emac repo on my github that includes the EDID and some pinouts. More to come later.

I know the situation well! I'll check out the repo soon and maybe I can contribute some as well.

Back to the topic at hand though, if you completely disable starting the udev service, does the screen still go weird? If not, you've found your culprit: it's definitely one of the udev rules. I'm just saying that since I looks like your issue on the rpi firmware tracker will probably just get ignored like most of the others.

I haven't had time this week to tinker but I hope to run some tests this weekend. I'm pretty sure I'll be ignored in the FW tracker as well but you'll never know i you don't try.

Fingers crossed.

 

[christiann]

I finally purchased and received a Raspberry pi 4 for the iMac G3 monitor and I think I've found a bug
in Raspian for the raspberry pi4 . The image is shifted off screen after the udev kernel device manager
is loaded.

I've added an issue to the RPI4 repo on github with a description and videos. If anyone has a raspberry pi4
and can recreate this, please do and add a comment. There is evidence that it is indeed the operating system
and not the hardware because Ubuntu 20.04 for the raspberry pi4 boots correctly.

Here is the reported issue

https://github.com/RPi-Distro/repo/issues/173
https://github.com/raspberrypi/firmware/issues/1396

Below are the videos

Wow. Thats a cool mod. Now I’m interested.

 

[rockyhill]

I have had lots of questions on how to go about doing this to the iMac G3 so I'm putting together a wiki on github.
Once I'm done I'll make wikibook.
Wiki with explanation of how to do it.

 

[FrankClochard]

I have had lots of questions on how to go about doing this to the iMac G3 so I'm putting together a wiki on github.
Once I'm done I'll make wikibook.
Wiki with explanation of how to do it.

Lovely! So far it's very well written and easy to understand, even for a novice like me!