USB device to control CRT geometry

[silmalik]

Hi,
This topic to share my work on a USB device that can be used to control of TV image geometry from a PC.
The result is pretty hacky and have some limitations but it’s usable.

It can only work on TV/Monitors whose geometry is adjustable by a Service Menu. Maybe some of them, I suppose most of them.

Proof of concept demo:

Sources: https://github.com/silmalik/USB4CRT

Target :

Target is image vertical size auto-adjustement upon running mame game.

How does it work ?

Most recent CRT TV/Monitors use « I2C » bus for communication between chips. One of the chip,  the Jungle IC, is responsible of resultant geometry.

The basic idea is to send specific I2C messages on the bus to adjust the image geometry on the fly.

So, using a programmed SoC to act like a USB to I2C brigde that allows some kind of I2C bus spoofing can do the job.

Side effects :

Some messages travel on the I2C bus very frequently, most messages are just *useless* repetitions but other are required for some functions.

The bad news is that it’s not possible to send once an order for adjustment because after few time, the default value will be sent again upon the I2C bus and cancel customization.

A solution is to lock the bus once a custom message is sent (i.e. send an unstopped message).

Then, there are some side effects :
 - NO MORE SOUND ! Argh ! --> Fixed using external speakers. 
 - The TV apears locked, no remote control, no front panel control

Sending a « stop » I2C message on the I2C bus and TV is back 100% responsive

The good effect is, of course, that the geometry can be adjusted in real time with same precision than with the Service Mode. Multiple variables can even be tweaked by sending adequat I2C messages to the TV.

Hardware employed:

 - Cypress 5LP PSoc Prototyping Kit (15-20€) http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and
 - A pair of 300 Ohms resistors and some wires.
 - Optionally : a cheap (10-15€) USB Logic Analyzer, to sniff I2C bus (see below).

Required knowledge :
This could be the fun part ! 

Well, there is no standart for I2C message used to control image geometry, it depends on the Jungle IC employed.

So, to know about this, 2 solutions :
1 – The easy way
 -  Explore TV Service Manual or directly the TV PCB to identify the jungle I2C chip (often Philips TDAxxxx).
 -  Then, with some luck, Google can find the chip specification document and all required informations should be
  there (I2C address, registers and value ranges).

2 – The « have-a-guess » way :
 -  Use a USB Logic Analyzer to take some I2C bus traces and then analyze messages to learn how the TV chips  speak. I had to follow this way, it's easier than it sounds.

Implementation :

-  Program the PSOC with the "USB4CRT" code (https://github.com/silmalik/USB4CRT).
-  Wire the PSOC to the TV PCB, only 3 wires are required.

    The Sony, and probably most of TVs, has a kind of service connector, so, using « female jumper wires », no need to solder on the PCB.   
   One wire can be plugged directly on PCB, the 2 others need a resistor between the PSOC and the PCB.
   Plug the micro USB to the PC, the device is seen as a COM port.

Usage :

From PC, send I2C messages to COM port, with « [ » and « ] » for start/stop signals.

Example : « ECHO [8A1211][8A1309 > COM4 » adjusts vertical size and centering on a KV-29FX30

In this example, 2 messages are sent, the second is « unstopped » which has effect to keep the I2C bus in the busy state (Bus locked = IR remote down, etc.).
 -  8A is the I2C Slave address
 -  12 the Vertical Position register, 13 the Vertical Zoom
 -  11 is the value. Increase/decrease this value makes the image goes up or down.

Sorry this massive message, thank you for reading.
If there is some interest, I have a bit more to share about integration in a Groovymame setup.

[Zebidee]

Wow   

That's pretty amazing. At first I thought "ygtbfkm!", but I get it yeah wow. I'm going to have to go and digest this for a bit... "Wow" will have to do for now... 

[buttersoft]

There's a vid on youtbe with someone using a bus pirate to intercept i2C comms in a CRT TV, but he completely fails to describe how he implements his solution to control the ongoing traffic on the bus. And before that Eviltim came up with his TV bus manipulator to enable RGB input on certain jungle ICs. That said, this is something i want to attempt on a particular TV of mine, so i'll be going over anything posted in great detail

The idea of integration with GM is the really astonishing part though, it will be awesome to see what comes of that!

[silmalik]

Hi,
Thank you for your interest and sorry for the black out, not too much free time these days.

I've searched for any similar experiences but didn't find some... if you still have links, I'm interested, it may help to improve things.

I've played with Bus Pirate too at start, a great tool. the thing is it is not "Multi-Master" compliant and can easily mess up the TV. A lesson is that a TV can crash! 

BTW, I've put online required sources, so, anyone can give a try now. 

There is the "USB4CRT Agent", the powershell script (!) that sends I2C commands for each Mame/Groovymame running game.
The script run in background, waiting for a resolution change, and send the right commands if any.

Another tool will be provided to adjust and save video mode settings, in live, while game is running, from a remote computer.

Feel free to ask any question, of course.

[buttersoft]

https://etim.net.au/tv-bus/

That's Tim's bus manipulator.



And that's the other guy. Bascailly he's watching the bus via the bus pirate, and figured out which bit he had to flip to turn on RGB on his jungle chip, and then discovered the micom was simply spamming the same parameter data at the jungle chip over and over - which last a few of us could have told him ahead of time He uses a workaround later int he vid, obviously one involving intercepting the i2c comms using an MSP430 PIC because his arduino fails (interesting in itself) but the details aren't all there. Tim's method uses a mask over the i2c bus...

I thought that was one of the functions of a bus pirate. It's not acting as multimaster that way, just sitting in the middle reading and passing comms - it looks like the master to the slave, and vice versa. Only it doesn't have to be transparent, you can use it to block and retransmit data if you want, based on parameters you specify?

[silmalik]

Thanks for the links, I will look at them.

From my understanding, altering messages on the fly seems not possible since every chips receive I2C data in the same time. But I can be wrong, I'm just amateur.

A solution would be to cut off the I2C bus, physically, and interconnect both part with Bus Pirate or Cypress PSOC. A kind of man-in-the-middle attack, as you suggest.

Another option would be to write custom settings in the EEPROM, but it's not sure that values are read in real time and there would be some risks to brick the TV.

I have very limited knowledge on electronics, but I'm interested if there are other leads.

[buttersoft]

Another option would be to write custom settings in the EEPROM, but it's not sure that values are read in real time and there would be some risks to brick the TV.

You're right in that it might not happen in real time. I would guess that you can read the EEPROM data and find settings like vertical size, but to do that you'd need the remote to get into the service menu first and change a value, then run a comparison. The layout of EEPROM data normally bears no resemblance to the data table you'll see in the datasheet for any jungle chip. The micom feeds the right information to the jungle, but it can store those values in completely different ways on the EEPROM, and add other bits of its own or info like logos and menu text. And in the case of the sets MarkOZLAD and i brought to Tim's attention, the RGB-disable bit wasn't stored in the EEPROM at all, but built into a mask on the micom (we presumed). So it wasn't possible to get RGB into the jungle chips without hijacking the i2c bus. Tim figured most of this out, of course, and then decided to play around and find a fix one day. His is a man-in-the-middle attack, to borrow your term.

Iwouldn't talk yourself down though, you got a lot further into this kind of thing than MarkOZLAD and I did

[silmalik]

I don't get complete understanding of Tim's work to be honest, I will have a better look at his code.

I still have the feeling that there may a way to tweak geometry in a clean way. As it is done from Service Menu.

I've noticed on I2C traces that when I change a setting in Service Mode with remote, a single command with the according value is sent to the EEPROM.
Manually sending messages to this address do nothing. Maybe this message must be synchronized with a disabling of EEPROM write protection.

I would like to dump this EEPROM, but it's surface mounted on my TV, I need to find a way to do it through I2C bus.

[Paradroid]

This is the coolest thing I've seen in a while. Well done!

The concept has existed for a while but I've never seen someone actually implement it.

Will definitely be following your progress and would even like to try myself one day.

[Paradroid]

It can only work on TV/Monitors whose geometry is adjustable by a Service Menu. Maybe some of them, I suppose most of them.

As you probably know, older TVs and arcade chassis tend to use internal trimpots for geometry adjustment. You can see my own attempt at a solution for that here.

I've been working on something similar to you but for these older analog controlled TVs. My concept is based around the use of Arduino controlled relays to build a digitally controlled voltage divider (since pre-packaged digital pots have many limitations). Then, I have an AutoHotkey script that monitors for resolution changes and recalls saved settings (i.e. per game and for the desktop) accordingly (the script identifies the application that has focus). I set two hotkeys to control the vertical size (i.e. bigger/smaller) and save the value to an .ini for each game. If a game doesn't have a setting yet, it defaults to the average setting for all games with the same number of lines (e.g. 224, 240, 256, etc.)

Your work has inspired me to get back to this project and package it all up. I'll start a new thread on the GroovyMAME forum soon.

[silmalik]

Wow... swapping tubes, really?  Impressive job. I just can't image the nightmare to make all the required yoke adjustments to get the nice result you have.

Yes, I've already read something about digital control on analog chassis... I guess you were not too far    I thought this lead didn't go to an end.
All Mame cabinet should have something like this!

Like you did with Autohotkey, I wrote Powershell scripts for auto-adjustment (but without hotkeys): USB4CRT_Windows_tools/USB4CRT_Agent/README.txt

And yes, please, share your work!

[Zebidee]

Paradroid, your work with the yolk swapping and geometry controls inspires me.


I searched yoke swap on Youtube and found this excellent and informative video:


I've been perusing the shmups forum RGB modding thread recently and noted some people successfully using jungle chip inputs to allow adjustments to width etc via potentiometer to adjust voltage. Maybe you could find ways to take advantage of this in more modern TVs too?