Reverse engineering the Sony BKM-129X

January 26th, 2020

So I got a couple of PVM-9L2’s, both coming with the BKM-120D SDI card, but no analogue RGB inputs are present by default. They can be had by changing the BKM-120D with a BKM-129X card, which supplies standard RGBS/YPbPr in/out BNC sockets. The board is rather expensive, going in the $150’s range on eBay, although not that rare as such. The same board is used in other BVMs and some other PVMs can also use them, if not to add even more RGB inputs.

An original Sony BKM-129X RGB/YPbPr input card

Anyway, looked into if it was possible to make a clone of it, so I looked at the service manual, and could see that it was more complex than for instance the JVC card (IF-C01COMG) I cloned some time ago.

Here’s the MCU setup on the BKM-129X (from the service manual which can be downloaded on and most likely other places, it is shared with BKM-142HD, 120D and 127W).

It actually has a microcontroller/MCU on board, coupled to the monitor through the 64-pin socket, seemingly communicating on a SPI channel. SPI usually has 4 wires: a clock (SCLK), data master->slave (MOSI, master out, slave in), data slave->master (MISO, master in, slave out), and a slave-select (SS, meaning “selecting” the slave for communication, usually active low). So two data channels in each “direction” means SPI is “full duplex” which again means that data is flowing in both directions simultaneously (look up SPI on Wikipedia if you don’t know it). Slave-select is not present by default, but there is a SLOT ID pin going from the socket and into the MCU at two places, one called INT0, which is an interrupt pin, and another also called SLOT ID, so I guessed this to be functioning as slave select.

This data channel is then used by the monitor to verify the board is there and read some information from it and so on, thus activating RGB/YPbPr on said monitor, when the card is present (and selected). If the card supplies YPbPr or RGB is then setup in the monitor itself through the OSD, and there is also a serial number readout. At the same time, the microcontroller also has two “digital” outputs, one actually enabling the video output of the card (BX_OE, active low), and one (de)selecting external sync (EXT_SYNC_OE, active low).

To get anywhere I needed to get a card, so I bought one on eBay at too much money (the one shown in the beginning), which further fueled my desire to reverse engineer it, both for myself and the community.

The MCU of the board is some 8 MHz proprietary thing, and it has an EEPROM next to it, most likely with the program of the MCU on it, but since the MCU is not something easily bought, I didn’t try to read it out.

I expected the initialization sequence to be something like:
1. Monitor selects the card by setting SLOT ID to LOW.
2. Monitor reads some info including serial number.
3. Monitor decides card is there depending on response.
4. Monitor starts using card, sends commands commands to turn on and off the output and the external sync depending on button selection.

And then following commands for external sync and whatnot being something like:
1. Monitor selects the card by setting SLOT ID to LOW.
2. Monitor issues some “simple” command.
3. Monitor deselects card.

So to figure out the what commands look like, what response to give, and timings, I attached a logic analyzer to the RESET pin, MOSI, MISO, SCLK, SLOT ID, BX_OE and EXT_SYNC_OE pins. I have a DreamsourceLab DSLogic Plus USB logic analyzer, which can capture for a long period of time which is great, as I need to capture during the whole startup and initialization of the monitor to catch the information (which is around 5 seconds). At the same time, the software for it (DSView) also has built-in SPI decoding, so it can show me the byte representation of the data being transmitted over the wires. The connector is a DIN-41612 style a+b connector, where the bottom row is the a row, and the top is b. Pin numbers are counted from left to right. When the connector is vertical like it is positioned in the monitor, the leftmost column is then a row and rightmost is b, and pin numbers are counted from top to bottom.

So I set up the logic analyzer to capture for 5 seconds, and at 10 MHz (as SPI is often in the 1 MHz range this should be plenty oversampling). So doing this yielded a datastream like this CSV shows:

Complete CSV file of power-up sequence, card selected, external sync on.

Now SPI actually has 4 possible modes, which will influence how data is interpreted: clock polarity (CPOL) and when to sample the data (CPHA), both can be 0 or 1, thus 4 possible configurations. So to figure out if the representation of the data is correct, these need to be setup properly. First of all, it can be seen that the SCLK is high when nothing is happening/idling, meaning CPOL should be 1. To decide if CPHA should be 0 or 1, you need to look at the transitions of SCLK and the data lines in relation to each other. I decided CPHA should be 1 based on the waveform, meaning data is sampled on the rising clock edge. I then did this multiple times, with different sample speeds also, to confirm I got the same readings again and again.

The output shows that SLOT ID seemingly *is* used as a slave select, the monitor then issues a 0x9E command, the slave responds with the same, while the master seems to clock in an address byte, which then is responded to from the card with whatever that address contains. This is a “classic” memory read pattern. There also seems to be a 0xBE request, which also throws out some data, so I expect that it’s another memory region that is requested or something like that. It then has some 0xF7, 0xF6 and 0xF4 requests, which seems to be depending on if it is selected, and if external sync is enabled or not.

My current idea of the protocol is then like this:
0x9E – Memory read (followed by an address to read).
Example: 0x9E, 0x02, 0x00 reads memory address 0x02 (the last 0x00, is where the master clocks out the response), so response would be 0x9E, 0x39.
0xBE – Memory read of “another” region (followed by an address to read).
The next here are preceded by 0x00, 0x00:
0xF7 – Deselect (turn off outputs).
0xF6 – Selected, output enable (BX_OE=LOW/0), external sync disabled (EXT_SYNC_OE=HIGH/1).
0xF5 – Also some deselect, see it rarely.
0xF4 – Selected, output enable (BX_OE=LOW/0), external sync enabled (EXT_SYNC_OE=LOW/0).

Upon startup, the card always gets two deselect (0xF7) and then a one of the select commands, depending on the external sync state.

So my first attempt was simply implementing all this in an Arduino Nano, putting the protocol into a request/response state machine, that each time the monitor asked for a specific byte, would return the same as the original BKM-129X did. This proved not to work. I got the request, 0x9E, and it was sent back, but then SLOT ID goes HIGH, and never LOW again to read the response. Hot damn…

So I looked some more at the waveforms, and noticed that the same happens for the original card, however SLOT ID goes LOW again some time after the 0x9E response, and then stays LOW for quite some time, until SCLK suddenly starts clocking in the response data. Since this was not happening on my setup, I thought that maybe this was some part of a handshake, because of the SLOT ID labeled pin on the MCU itself. So my guess was that the MCU should slave-select itself when the actual response was required, sounds somewhat strange, but hey, it’s Sony. And whaddayaknow, it worked!

A single byte read. The first CS low is the monitor sinking SLOT ID, the second is the card.
Here’s a closeup of the initial part (representing the first CS low in the previous picture).
And here the second part, where CS is driven low by the cards SLOT ID pin. Look at the time in the top, around 10 ms has passed since the command was issued.

Doing this, I could now, having only the Arduino Nano connected, select RGB (no picture of course), read out a serial (that was identical to my original card) and select and deselect external sync. So to do it, SLOT ID pin is first configured as input, and when the actual response is needed, it waits for the SLOT ID from the monitor to go HIGH, then the pin is configured as an output, output is set LOW (thus slave selecting itself), waits for the response to be read out over SPI, and then it sets SLOT ID as HIGH, and back to an input.

Now I have no idea what most of the data reads represent, except it seems (at least) the first byte read, address 0x00, returns 0xC8 for the BKM-129X and 0xC0 for the BKM-120D, so I expect this is what the monitor uses to identify the card. The next addresses read, 0x02-0x09, represents the serial number, written in ASCII bytes (so 0x30 for 0, 0x31 for 1, 0x32 for 2 and so on, Looking at the CSV from earlier, it can be seen that my original card has the serial number 2001911 (0x32, 0x30, 0x30, 0x31, 0x39, 0x31, 0x31).

The PVM-9L2 with just the Arduino attached.
I changed the serial number to 5001337, and it reads fine.
The Arduino connected in the back, including the 100 Ohm and the 100K resistor for at the SLOT ID pin and including a BC550 to allow the monitor to reset the MCU.

I’ve put the code, which works on an Arduino Nano v3, on my github:


So since the code now has been refactored and changed a bit, and tested on more monitors, at least newer monitors like the BVM-D9H and D14H seem to require that the bootloader is removed and the application is running as the only piece of software (seemingly to boot faster). This can be accomplished by programming the software directly to the Arduino, without using the USB. This means a “real” programmer (ISP) is needed, and the ICSP header (or the corresponding pins) are used for programming. A cheap ISP can be made with another Arduino Nano, check out how to do that here: (scroll down a bit)

Any feedback is appreciated, please email to or reach me on shmups (username: skum), on the CRT discord (username: skum) or on Facebook (Martin Hejnfelt).

Next up is designing the rest of the board to have a true compatible card. I am in the last stages of this, and will release here and github when done.

SEGA Mega Drive 2 50/60 Hz and language mod (single switch)

January 3rd, 2020

By default, the European Mega Drive (2) has a vertical refresh rate of 50 Hz, meaning the games play slower than its Japanese and American counterparts which play in 60 Hz. We don’t like that, so that needs to be fixed! So getting a Mega Drive 2 to play games in the original 60 Hz speed plus being able to switch the language on games that support it is somewhat easy, but there are some caveats, especially if you’re a purist. This guide relates to a PAL Mega Drive 2 with a VA1 board. Note that I’m still a sucker for hardwired switches, but a lot of this can also be done with a MegaDrive++ setup.

Getting 60 Hz out of the MD2

First of all, what vertical frequency the Mega Drive generates is depending on the voltage on pin 46 of the main CPU. When pin 46 is tied to 0 V/GND, it generates 50 Hz, while when it is logic high/5 V, it generates 60 Hz. On this board pin 46 is tied to GND not far from the main chip. This small bridge as can be seen below, needs to be cut.

Where to cut when isolating pin 46
The connection to the GND plane is now cut

When the trace is cut like this, we isolate the pin. It is supposed to have a pull-up and if you measure between 5 V and the pin, you’ll be able to measure around 25 kOhm, so indeed it seems there is something here. At the same time, the trace is also connected to the MB3514 video encoder, which generates composite video and amplifies RGB. It is connected to pin 7 which (lucky for us) is also the pin that selects if the MB3514 should produce NTSC or PAL composite signal (and chroma in S-Video), 0 V for PAL, 5 V for NTSC. We’ll get back to this later.

Close to the power regulator (the heat sink thing) are 4 holes, which denotes two jumper points, JP3 and JP4. The left side is connected to the above trace, meaning to pin 46 and MB3514 pin 7. The right side is connected to GND for JP3 and 5V for JP4. Since the holes are through holes (most likely filled with solder) these are some good points to connect to. Now connecting 5 V to the left side will make the MD2 create 60 Hz video, and MB3514 create NTSC, while connecting 0 V will give 50 Hz video encoded to PAL. So connecting a switch here that selects between the two by connecting 0 V or 5 V from the right side makes it easy to switch between the two modes.

The jumper pads that makes connection easier

Now if we try to connect 5 V to one of the pads om the left side, we will see that the video is now full screen and running noticeably faster. However, if we are using composite, we might be getting a black and white image!

Dafuqs up with my black and white picture?

Usually people will attribute this to being because the TV or monitor the machine is connected to, cannot decode NTSC, and then switch to RGB. The decision is good (composite sucks), but for the wrong reasons (especially if we know the set to be NTSC compatible). So why are we seeing black and white composite video? The MB3514 is properly set to generate NTSC, however the chip also has a carrier frequency input (pin 6) which need to match the specifications the receiver expects.

The MB3514 and the two pins for NTSC/PAL and carrier frequency

For PAL this frequency is ~4.43 MHz and for NTSC it is ~3.58 MHz. Since these subcarrier frequencies are used to encode only the colors of the video signal, and we are getting black and white, something is off. If we try to measure the frequency going to pin 6 we see this when in PAL mode:

MB3514 carrier frequency in PAL mode
The average frequency, 4.434 MHz

Note the Measurement in the bottom where it says “Average” and “4.434 MHz”, so here the carrier frequency is correct.

If we switch to 60 Hz / NTSC mode, we get this:

MB3514 carrier frequency in NTSC mode on PAL console

So we can see we have a carrier frequency of average 3.547 MHz, which is somewhat off the intended ~3.58 MHz, so this is why we are seeing a B/W picture; the receiver cannot lock onto the carrier frequency to decode color.

We can then deduce that the carrier frequency is created wrong, and since the frequency is created by the main CPU, the answer to why, can be found in the differences of the main oscillator which supplies the clock signal for the system. On PAL consoles this is ~53.20 MHz (which is equal to roughly 12 x 4.43 MHz), while on US and Jap consoles it’s ~53.69 MHz (which is equal to 15 x 3.58 MHz). Now what happens is, that when pin 46 is low (for 50 Hz PAL), it divides the clock by 12, and when driven high (for 60 Hz NTSC), it divides by 15 (53.20 MHz / 15 is roughly 3.55 MHz, which matches what we saw above). Now how to fix this?

Bring in the Dual Frequency Oscillator (DFO)

The Dual Frequency Oscillator is a small device based on Texas Instruments CDCE family of clock generators. It can be programmed to generate different clock signals depending on an input. A guy called micro has made a design that is a drop in replacement of the main oscillator ( so building one of these, replace the original oscillator on the board, take the same signal as we send to pin 46, and insert at the DFO, we can now switch the main oscillator frequency to match the selected mode!

So we need to desolder the main oscillator and dump the DFO in. We can then take the signal to the DFO from the other unused through hole at either JP3 or JP4 and route that to S0.

The DFO installed

Doing this, we can then measure that the subcarrier frequency is now correct when in 60 Hz mode:

The white wire goes to S0 of DFO, the green to the switch, red/black to switch poles.
Fixed MB3514 carrier frequency

At the same time, this also fixes that the output frequency in fact was not 60 Hz, but more 59,2 MHz, which can help when connecting to some flatscreen TVs an converters like Framemeister. Note that much of this actually relates to many other 50 Hz PAL to 60 Hz NTSC conversions on Master System, PlayStation and so on.

So what about that Japanese language?

Pin 107 of the main chip selects if the machine should report as being an English machine or a Japanese machine. This “helps” some dual language games to show either Japanese or English text. An example is Quackshot. When pin 107 is connected to logic high (5 V), the machine reports English, when 0 V it reports Japanese. On this board, pin 107 is connected to 5 V through a via to a 5 V plane. This somewhat sucks, as we then either have to lift the pin, cut the trace, or cut around the via in the plane. I selected the second option: Cut the trace at the via and then scratch some of the solder mask off to be able to solder to the trace.

The trace to pin 107 is cut
The yellow wire soldered to the trace to pin 107

Bringing it all together

Now we have two places to insert information, the 50 / 60 Hz and the language. Some use two switches for this, one for each, however we can deduce that only 3 sane options exist:

50 Hz / English / Pin 46: 0 V, Pin 107: 5 V
60 Hz / Japanese / Pin 46: 5 V, Pin 107: 0 V
60 Hz / English / Pin 46: 5 V, Pin 107: 5 V

This can be done by a simple DP3T switch, so instead of having two switches, which techically gives the 4th “invalid” option of 50 Hz / Japanese, we hook up to one with 3 positions. The hookups look like this:

R1 is to prevent shorting the supply when switching while machine is on. It can be 1K-10K but it needs to be less than the internal pull-ups (which seems to be in the 25K range as mentioned earlier).

The DP3T, still missing language wire here

So I like to conceal the switch as much as possible which I do by using the left side facing the switch downwards.

The installed switch

Of course some mechanical holes needs to be drilled and filed in. How big this is depends on your switch.

The holes for the switch
The switch seen from the bottom

So now, by switching we can select all three regions with correct corresponding frequencies. All good!

RGB modding JVC TM-1700PN

September 30th, 2019

Update: I’ve been told that this also works for TM-2100PN.

I got a hold of a JVC TM-1700PN, which is a 550TVL composite/S-Video monitor. As always this baby needs RGB modding! So let’s get to it.

It uses a TDA8366 as the jungle IC, which has direct linear RGB input. OSD is mixed in after the jungle, so there is no need for muxing. The monitor exists in an already RGB capable version, the TM-1750PN, and actually most of the circuit is already there, but not populated. Anyways, looking at the service manual, the RGB inputs are pin 21-23 and blanking at pin 24. The pins are connected to three capacitors, C131-C133, however in the TM-1700PN they are not capacitors but simple jumpers that end up at some 22K resistors to GND. So we remove these jumpers, and this is where we inject our RGB. C131 is the blue line, C133 is the red, and C132 is the green.

RGB lines

Note that the RGB should be normal 0.7Vpp but 75 Ohm terminated, and with a 0.1uF capacitor before injection. I have this circuit on the SCART breakout that I use (check some of my other posts), but in general the input circuit for each line looks like this:

Input circuit for RGB lines

Sync should be added directly (no circuit) to one of the inputs, I chose directly at Input A on the PCB side of the BNC plug.

Sync input

Now the next thing is getting it to blank RGB input. The TDA8633 has blanking on pin 24, however this is tied to the already present circuit of the MCU, as the pin is also used to blank the RGB output of the jungle, because OSD is added after it. This is a bit different than the other JVCs I’ve worked on, so off to the datasheet. It seems that the RGB blanking happens when pin 24 is between 0.9V and 3V. Above 4V is OSD blanking, so we need to stay within the 0.9V-3V. The monitor does this in itself by having a voltage divider between a 1.2K Ohm resistor (R725) to GND and a 1.8K Ohm resistor (R726) connected to a switch to 5V. This gives a signal around 2V, which will blank it. So to force this, we could inject 5V at that 1.8K resistor, but that is placed on the mainboard, so requires more disassembly of the monitor. Instead there is an unpopulated resistor R130 connected to the “top” of the 1.2K Ohm, so we can create a “new” voltage divider here, by added a 1.8K (I used a 2K) and inject the blanking signal through that. I at the same time added a Schottky diode as this point is where the MCU then also connects 5V for OSD blanking, and I wanted to avoid backfeeding voltage to my console. You can use more or less any diode, I choose Schottky for the low voltage drop, and of course the higher the voltage drop over the diode, the lower voltage ends up at the jungle, increasing the risk of hitting the low threshold for blanking. The circuit equivalent is something like this:

The circuit for blanking. We add D1 and R1. R2 represents R725 in the monitor.

And here’s real life:

Blanking circuit, 2K resistor and a Schottky diode, heat shrink or something should be added.

So when around 3-5V is added at the diode, it will blank to RGB. Hooray!

So all this is connected to the SCART breakout I’ve mentioned earlier, and presto, a fine RGB picture 🙂

All the connections as of yet

Audio using the SCART board, audio is mixed to mono and injected at the RCA pin for input A.

Audio injection point

So everything is connected to the SCART breakout board I’ve designed (OSHPark) and a case that fits the grille. This monitor has a slightly different pitch of the holes, so I had to modify the case a bit. Will put the 3D model it along with the original one (70mm between holes) on Thingiverse (it’s gonna be postfixed with 72mm).

The SCART connector with audio passthrough

So here are the finished connections:

The finished wiring incl. some hot-glue strain relief
Super Mario All-stars
Here ist roughly the same picture in composite. Notice the dotcrawl…
Super Mario 3
Turtles in Time
More tortoise action
More original composite, more dotcrawl.

Linux: Empty /sys/firmware/efi/efivars

September 24th, 2019

When applying the preempt_rt patch to the Linux kernel, EFI variables at runtime are disabled by default, seemingly due to high latencies ( If you still need EFI variables accessible for userspace applications like efibootmgr, add “efi=runtime” to the kernel parameters/arguments. This will re-enable the possibility to mount efivarfs with “mount -t efivarfs none /sys/firmware/efi/efivars”. This will of course not magically make the above mentioned latencies disappear, so use this at your own discretion.

RGB modding JVC TM-A101G

August 18th, 2019

So next in the line of small JVC monitors I’ve worked on is the JVC TM-A101G.

As the TM-1011G and DT-V100CG this is a 10″/9″V CRT pro monitor, but only has composite video inputs. I guess it’s the older version of the TM-1011G but I’m not sure, and it doesn’t matter anyways… Looking at the service manual which is available on teh webz, this uses a TB1226EN which is the same as the TM-A140PN I wrote about here, so I know this jungle a bit. I wondered if it needed I2C interception and mangling like the TM-A140PN, but already before I got my TM-A101G monitors, I helped a guy mod his, where we found out it *did* need this. Luckily the software I wrote for the TM-A140PN worked out-of-the-box here, so with that information, I started modding my own.

Opening up the monitor, the signal PCB is sorta small:

The TM-A101G signal board, with IC201, the TB1226EN in the top

There are only two larger ICs, of which the top is the TB1226EN (IC201), which is the one we’re interested in. According to the datasheet of the TB1226EN the RGB inputs are pin 23 (R), 24 (G) and 25 (B), and according to the service manual these are “grounded” with capacitors, these being C716, C717 and C718, which can be seen roughly in the lower middle here:

The TB1226EN and the RGB grounding caps

So these are THT/through hole caps, which sucks, because then we need to remove the shielding that is on the other side, or disconnect the tracks, by cutting them. I chose the former. There are 4 points which needs to be desoldered for that, which requires a lot of heat because it’s connected to the GND plane, and in itself is a large GND plane. So after doing that, removing the caps with a needle-nose pliers, and either a desoldering gun, or simply by heating the solder and pulling the component, they’re quite easy to remove.

The caps removed and holes covered with solder blobs

After removal, the RGB signals can then be attached to the open pads, R to the pad of C716 (the one not on GND plane), G to C717 and B to C718. The signals needs to be run through a circuit like this:

Input attenuation and DC block (here from TA1276AN jungle, but it’s the same). A more correct termination wise scheme would be 24 Ohm for R1 and 54 Ohm for R2, although it seems not particularly important

Notice the R726 just below the “VIDEO/CHROMA” text in the top right of the above picture. This is a 10K resistor, and connects to the YS pin, which is the pin needed to switch to RGB. Usually, on similar displays, there are quite low Ohmic resistors here, because it’s pulled to GND, as RGB is “disabled” anyway. To switch to RGB we need to put something higher than 0.85V at the YS pin, I usually use the 3-5V RGB blanking voltage from SCART, however if the pulldown resistor is small, it will draw a lot of current, for no reason. I therefore usually switch these pulldown resistors to 10K resistors, but here, that is then not needed. We can therefore inject RGB blanking, either from SCART or another source (a switch for example) directly at the pin, or at the side closest to the pin row of the TB1226EN (I chose this).

I inject sync directly at the BNC input of Input A to avoid sync problems, and utilize the built-in sync extraction circuitry. GND is then just whereever it’s most appropriate to obtain. Here are my connections (yellow is sync, white is blanking and black for GND):

RGB, blanking and sync connections

If we don’t do anything else, the picture is really low contrast, washed out and doesn’t look any good at all. Here is where we need to mess with the I2C communication from the monitors MCU to the jungle IC. Basically the monitor doesn’t treat the jungle I2C registers correct so RGB is not properly set up, just as with the TM-A140PN. Since it was verified that the previous software I wrote for the TB1226EN works for this monitor, it was simply getting an Arduino in. Download the software here and program the Arduino with Arduino IDE (remember to install SoftI2CMaster library). I’ve begun using the Mini Pro because it’s even smaller than the Nano, with otherwise the same feature set. Mind that it should be the 5V version. So we need to isolate the jungle from the I2C bus, which is done at R291 (SCL) and R292 (SDA):

The two resistors where we intercept and mangle I2C communication

Desolder these two, and attach the Arduino here, with the wires from R291 going to A5 (SCL) and R292 going to A4 (SDA), use the pads that are “away” from the jungle. Attach the other pads from R291 to D5 and R292 to D4. If you use another Arduino than Mini Pro or Nano v3, you might need to change accordingly. Remember to solder a 2.7-4.7K resistor from D4 and D5 to VCC/5V. I do this on the back of the Arduino (which is why you can see a solder blob on VCC to the right on the Arduino, but its better to use the bottom VCC instead, as now the programming “header” sorta blocked, although not needed). Here’s a picture of the same deal:

Pull-up resistors on the back of the Arduino

I then use a load of hot glue to stick it to the board.

The Arduino Mini Pro attached on the board and to the R291/R292 solder pads
Close up of the solder pads

It’s important that the Arduino powers up early, to avoid the monitor not initializing, so I attach it to 9V which I found at the top of the unmounted C509 (there is 9V many places). Attach this to the “RAW” input of the Mini Pro or VIN of Nano v3. Find GND somewhere and attach to GND of Arduino.

Stereo to mono mixed audio is then routed to the audio input of Input A.

The complete mod

All the signals are routed to the RGB SCART breakout board I’ve made, which can be found here and a bracket that fits the ventilation grille here.


Lo and behold, RGB in all its wonders:

RGB modding a JVC TM-A170G

June 16th, 2019

A friend of mine got a JVC TM-A170G which is a nice 17″ pro monitor with 750TVL. Unfortunately the monitor “only” has composite and S-Video inputs, so we talked about RGB modding it, which I took on as a task 🙂 Opening it up, it is apparent that is very close to being identical to the TM-H1750CG and its siblings.

The mainboard of the TM-A170G. Note that the capacitor with the hot-melt was apparently factory added, not by me.

The IC of interest is IC501, the big 56 pin IC almost at the middle, a then little to the left in the above picture. This is the jungle IC, the JVC common TA1276AN, and as always there are pin numbers marked on the boards, so it’s rather easy to find the pins we need to deal with. We need to get YS2 (pin 32) switchable to 5V, however it is pulled to GND by R554 (it sits to the right of the leg, along with C551-C553), a 0 Ohm resistor (which forces internal RGB mode, meaning deduced from composite, S-Video or YUV). So replacing this with a 10K Ohm or alike resistor makes a proper pulldown so composite is still available. The capacitors C551-C553 also needs to be removed as they are connected to the RGB pins (R/35, G/34, B/33) and would otherwise filter the video signals to GND.

The resistor and capacitors
All removed
10K resistor added at R554s place

Now we need to attach cables to the appropriate pads (or directly to the pins). For RGB switching, the rightmost pad of R510 (which is not mounted) is a good place to solder a wire to. The three empty pads right next to the pins are good for the RGB lines.

RGB lines and blanking connected to the pads.
GND was also attached to whatever suitable point

These lines cannot be directly attached to the input connectors. They need to be attenuated, DC biased and terminated properly. Here comes the same drawing as I’ve used in most of my other posts.

RGB line circuit. The R1 and R2 values can differ depending on the need. I usually go with 75R for R2, and something like 10R or 15R for R1…

I attach the RGB select/blanking pin to SCARTs blanking pin, which is 3-5V for RGB sources (pin just has to be more than 0.75V to select RGB). If SCART is not used, one could attach a switch somewhere to select it, use the voltage from the switch that selects inputs or something else.

We need to have sync getting in also. Most guides say that this should be inserted (as CSYNC) to pin 15, which is also possible, but I prefer to use one of the BNC input pins so it is properly routed (and saves some components, as we then don’t need the circuit from above on the sync line also).

Sync added to input As pin.

This monitor also has audio. This is injected (as mono) to input A pin. I forgot to take a picture of this, but with a multimeter, it’s easy to find the pin (it’s a bit further south of this pin, and somewhat covered by the case, but not unreachable in any way. Mono should be mixed properly from stereo if needed, this can be done with a circuit like this (if from SCART, otherwise insert left and right channels instead).

All the wiring in its glory. I use hot glue for “strain relief”.

Now all the circuits can be dangling components, small boards or whatever, and you might notice no components are on the picture above. I’ve started to use a small board that breaks out SCART to the appropriate signals, AND carry the circuits for the signal attenuation (or passthrough for sync) and for stereo-to-mono. At the same time it has RCA out for audio passthrough, and a switch to select the audio coming to the monitor or to the RCAs. You can find the board here on OSHPark.

The SCART breakout

At the same time I designed a 3D printable bracket for the board which can be attaced the the monitors top ventilation without drilling. You can find the STL file and original FreeCAD files here.

The board in the bracket (purple print is not mandatory)
Bracket attached.
The back

And voila, RGB modded TM-A170G. Here are some pictures (taken with phone, so real life is *much* better):

Scanlines ahoy!

RGB Modding a JVC TM-1011G

June 15th, 2019

Having worked with the DT-V100CG, I stumbled upon this JVC TM-1011G that looked at lot like it, but without the option for the add-on card, thus only two composite inputs. Instead of the add-on, it had a 12V DC option installed, but also integrated audio, which I thought was cool, given I had to add this to the DT-V100CG. Now I thought the RGB mod would be similar to the DT-V100CG, and hey! It was. The board is somewhat different, but still sports the same TA1276AN jungle IC. So with the experiences from the DT-V100CG I started to RGB mod this.

The TM-1011G is a cool little 10″ (9″ viewable) pro monitor

First of all, I didn’t want to lose composite availability, so we need to get a pulldown resistor in between pin 32 (YS2) and GND. On both this and the DT-V100CG pin 32 is connected straight to GND, so this needs to be lifted. Unfortunately it’s connected to a bigass GND plane, so it takes some heat and patience to get up. When it is up, I inserted a 10 KOhm resistor in the original hole and tied it to the pin. Now when 5V is inserted to the pin, it changes to RGB, and when 5V is off, it’s composite.

The resistor added to the lifted pin
“Blanking” wire added to the pin

RGB lines are connected to the RGB pins (35/RED, 34/GREEN, 33/BLUE), through the “normal” circuitry consisting of an attenuating resistor and then a 75 Ohm termination, along with a 100nF capacitor for DC bias (the RGB pins have a DC offset). Some (correctly) mention the ensuring that the attenuation resistor and the termination resistor should amount to 75 Ohm, instead of adding an attenuation resistor to 75 Ohm. Sync is injected at one of the composite BNC pins, so it is routed appropriately into the jungle. Since this monitor also has (mono)audio this is injected directly at the RCA pin for the same channel as the video (I chose input A for both).

One of the common found RGB attenuation circuits. R1 can be changed to 24 Ohm, and R2 to 51 Ohm for “proper” 75 Ohm termination

Since I’ve modded a few sets, always use SCART, instead of always hacking some wires directly on to the “naked” SCART socket, I made a small PCB to attach to. This is because the circuit mentioned above is needed, and because I also always add some RCAs and a switch to route to audio out from SCART, instead of into the often rather mediocre, at best, speakers inside these monitors, and found it easier to gather all this on a single PCB. The board has space for resistors, capacitors, the SCART, stereo-to-mono mixing circuit, and the audio switch. It then has a row of through holes to add the wires to going into the monitor. The board can be found on OSHPark here.

The RGB SCART breakout

Now, just as with the DT-V100CG, the monitors’ software kills RGB video by completely darkening RGB registers and so on. To fix this, the I2C communication from the monitors microcontroller to the TA1276AN must be intercepted and “tampered”. I do this with an Arduino board, which in this case ended up being an Arduino Mini Pro (5V version!). Now the deal is to isolate the TA1276ANs from the monitors I2C bus, and add in the Arduino listening on the same address as the TA1276AN, instead, thus getting the Arduino to act as the TA1276AN at least to the monitor MCU. The software library SoftI2CMaster then creates a new I2C bus, which then is routed to the TA1276AN. When the Arduino gets read and write requests, it forwards those to the TA1276AN, except for the ones that kills RGB. Also it will send contrast and brightness settings to appropriate RGB registers so this can be controlled from the panels buttons.

To isolate the TA1276AN, two resistors must be removed, R6612 and R6613. They are small SMD resistors next to the TA1276AN.

The resistors R6612 and R6613 are in the top left corner.
Here they’re removed. R6613 connects SCL line and R6612 connects SDA.

The “native” hardware I2C bus (also called TWI for Two Wire Interface) on the Arduino Pro (and Nano 3.0) are on pins A4 (SDA) and A5 (SCL). We need to connect these two pins to the system, either on the pads we removed the resistors from, on the ones away from the jungle, or on any of the other ICs also connected to the same bus. I chose the latter, and connected to IC6101. Pin 9 is SDA and Pin 10 is SCL. I then create the new I2C bus on D4 (SDA) and D5 (SCL), and connect them to the TA1276AN pin 27 (SDA) and pin 28 (SCL). On the Arduino I connect two pull-up resistors of 2.7K Ohm to VCC for pullups, one on D4 and one on D5.

The I2C circuit

The Arduino is then glued to the PCB with hotglue. Powering the Arduino is done with by taking 12V from the PCB and connecting that to the “raw” pin. The 12V is taken from the “T” connector pin 7. If I used a 5V from another source as direct VCC, it seemed it didn’t boot fast enough, and the monitor shuts off due to not being able to communicate to what it thinks is the TA1276AN. GND is of course also connected. I simply chose the nearest easily accessible point. The software for the Arduino can be found here.

The finished install. The large cap on the TA1276AN and the other hot glued components were not installed by me, but the factory. The big capacitor on the jungle needs to be lifted to solder to the RGB pins. Alternatively the pads on the other side could also have been used.

All the wires are then connected to the SCART breakout board, for which I still need to find a place for, most likely some small 3D printed bracket thing…

Current connection to the SCART board.

With all connected, presto! RGB on this nice little monitor 🙂

Click for larger picture to make this look less crappy… Still taken with phone, it sucks…


So I finished the bracket for the SCART breakout and besides the small mess with the print in one corner, I think it turned out pretty good. Find the 3D model here.

Fixing a PSone not reading discs (bad cap)

April 30th, 2019

So I have this PSone (PM-41 mainboard) that I modded with a onechip modchip and a multi frequency oscillator (I have another post on that) some time ago. It had always (at least since I got the unit) read discs rather slow, but I never thought of it, because I am not used to PSX (I generally dislike CD/DVD based consoles). Suddenly, not long ago, I couldn’t get it to read any discs. The console would recognize the disc, and go past the “menu”, but it would then sound strange, like it was retrying reads, until it would ultimately stop and hang. I tried trimming the laser pot with no real changes (except I could get it to not accepting discs at all), so I immediately blamed the laser. I then sourced another, working, PSone, and swapped the whole drive assembly, same results. I then blamed my modchip, and set the project aside. I then stumbled on a Facebook post regarding PSones not reading discs, where a guy suggested to replace capacitor C705, which is a 0.47uF/50V electrolytic SMD capacitor. Underneath it was some brown gook, that I usually find on leaked SMD caps on SNES and alike. Since I didn’t have a direct replacement cap, I found a 0.47uF/35V tantalum cap. Although voltage rating was off, I tried it anyway (I guess there would be no 50V in the PSone :P) and lo and behold, the unit now works again. It even read discs faster, I guess because re-reads are now eliminated or at least minimized.

The tantalum capacitor soldered in
The whole shebang

Building an arcade stick for PC Engine from scratch

March 13th, 2019

So since I like my NEC PC Engine / Core Grafx, I decided I wanted an arcade stick for it. Sure I could buy one on eBay or whatever, but I wanted to check how to build one myself. Since I’m not a fan of pad hacking, where I would destroy an otherwise perfectly functioning pad (and I didn’t seem to find many cheap 3’rd party NEC pads) I looked around to find the schematics of the pad circuitry itself. Lo and behold, some italian guy has made the schematics! (The site seems to be down, so I’ve uploaded the schematic here, and Avenue 3 button here, 6 button here. If the author sees this and does not approve, please contact me).

So with this, I first made a crude veroboard version to see if the circuit worked (it did, here’s half a picture of it, somewhat later in the process)

The veroboard version

So I then put it into Kicad to make a *real* PCB. This became this:

The PCB version (Kicad render)
The real deal

Because of my limited handcrafting skills, I decided to 3D print the whole chassis in several smaller parts (due to the build volume of my printer).

Here the joystick part
The button part coming along
The completed unit with an orange bottom, colors baby!

So I decided to put three buttons on top, so the red is parallel with the yellow, both acting as SELECT. Green is RUN, black is Button II, white is Button I. The two small switches are turbo for I and II.

I’ll put the project on thingverse and Github. For now the controller board is on OSH Park here:

Next job is doing the 6 button controller!

RGB modding a JVC TM-A140PN

February 28th, 2019

In case you’re looking for TM-H140PN look here:

Note: This guide works for TM-A140PN, TM-A14PN, TM-A13SU and TM-A130SU.

So, a friend of mine got a hold of some JVC TM-A140PNs (and TM-A14PN which is the same, but in plastic casing) which only takes composite and S-Video. So since nobody likes that, we wanted to RGB mod it. Open the sucker up, desolder the large metal shield in the middle of the board, and behold, a TB1226EN jungle IC. Since I now had some experience with the newer TA1276AN, I was somewhat prepared that shit might hit the fan. And of course, it did.

TB1226EN and where the capacitors were, and the I2C lines. All components mentioned can be seen here.

So blanking occurs with pin 22, Analog YS, and since I chose to blank on 5V (from SCART), we need proper pull-down, in order to avoid excessive current drain. So I switched the something like 10 Ohm resistor that pin 22 was grounded with (R726), to a 10K, so when 5V is applied, current draw is minimal, and when not, we still have 0V to allow composite/S-Video as before. After doing this, we could see that we could blank by attaching 5V to the pin and see the screen turns black. After removing C718, C717 and C716 which were the capacitors decoupling RGB pins to ground (as there is a DC offset voltage on these pins, just like the TA1276AN) and then injecting RGB to pin 23 (R), 24 (G) and 25 (B) through the same circuit as with the TA1276AN, we still got black screen when applying video.

The per line input circuit

So, with previous experience in mind (check the DT-V100CG RGB modding post), I hooked up the Arduino circuit to the I2C lines, by removing R292 and R291 and using that as entry point. R292 is the SDA line (yellow cable in the pictures), and R291 is SCL (green cable). On each line there’s also 100 Ohm resistors in-line (as in series), both on the incoming I2C and on the “new” I2C bus (they’re the resistors inside the black shrink tube). The side closest to the jungle IC was connected to the “new” I2C bus created with the SoftI2CMaster library, and the other to the hardware I2C/TWI. Firing up the screen, it didn’t boot at all. I could see it was communicating, but it never initialized properly. It seems that it is really sensitive to timing, and at the same time, the monitor software is *constantly* refreshing *every* single goddamn register in the jungle IC. So I had to rearrange the code which was somewhat trial and error, until I had something that could start.

Anyway, after doing that, I could see that the monitor software wrote 0h to register 06h, which is the RGB contrast register. Yay! Thanks for killing the RGB image! Anyway, some I2C packet mangling, and were good again. Basically, when the monitor writes to register 06h we ignore it, and when it writes to 00h we replicate that to 06h.

Glorious Mega Man X

At the same time, I ensured that it would never mute RGB in register 1Bh, if for some reason it would think of doing that. Contrast setting on the OSD will now also work, as data is replicated to RGB contrast register. Sync was attached to line B at the board on the pin, so it is properly routed to the sync and Y pins of the jungle. Audio from SCART was merged to mono, by the below circuit and then soldered to the RCA input pin inside the monitor.

Merging stereo to mono at line level. I found it somewhere on the internet, can’t remember where….

I then 3D printed a small “case” to put SCART on the back of the monitor, with RCAs to send audio out, and then a switch to switch between the RCAs and sending audio to internal mono shitty speaker.

Find the code for the Arduino here:

RGB wiring and sync. The Arduino was moved later.
The input circuit (the in-line resistors are directly in the cable)
The Arduinos final place
Kirby Superstar
SCART input block

So there you have it!