Making a new BKM-11R cable

April 6th, 2021

So I bought a Sony BVM-D9H1E to be able to test my BKM-129X boards at 31kHz (480p) and above. Being a *1 unit and not a *5 (like D9H5E) it has no integrated controls, and thus need an external controller. This can be either a *5 unit, a BKM-10R, or in this case the BKM-11R which connects to the front mini-DIN 8-pin option plug.

BKM-11R remote controller
The 8-pin mini DIN “OPTION” plug of the D9H1E.

Now the controller has a DE-9 port (and another mini-DIN 8-pin plug to daisy chain further to units like the BKM-14R probe) which therefore requires an adapter cable to the mini-DIN.

The DE-9 port to the right that connects to the monitor, and the 8-pin mini-DIN to the left.

The cable didn’t come with my remote, so I needed to make a new one. Searching the internet brought me to the shmups forum where this picture exists:

The top picture is the DE-9 port of the BKM-10R and the bottom is the mini-DIN. Unfortunately the BKM-11R does *not* use the same pinout as the BKM-10R seemingly, because making a cable from the above doesn’t work. I opened up the remote and could see that ground and 5V were definitely not the same, so I started searching for answers. Although 5V and GND are easy to measure out, the TX/RX pairs are not so easy as they’re seemingly buffered by the remote for the mini-DIN port.

I was unable to find a service manual documenting the the remote, so I was kinda lost. The next step was of course to disassemble the remote further to see if I could decipher further, but then awesome guy Steve Nutter of Retro Tech (he does a lot of informative CRT related videos on YouTube, check it out if you don’t know him measured a working cable out, which then made it easy to make a replacement. The pinout is as follows (pin numbers are as a normal DE-9 plug):
1 – NC
2 – RXD
3 – TXD
4 – NC
5 – GND
6 – 5V
7 – ~TXD
8 – ~RXD
9 – NC

Thus to make a cable, using this pinout, along with the information fromt the shmups post by xga, the connection needs to be like this:

Signalmini-DIN (monitor)DE-9 (controller)
Mini-DIN female pinout (taken from Schurter 4850.2810 datasheet)

For cable, I simply used an normal unshielded Cat5E ethernet cable, and then use a twisted pair for TXD/~TXD and other pair for RXD/~RXD.

BAM! Cheap BKM-11R cable! Thanks again, Steve!

Improving 720p performance of my BKM-129X compatible designs

April 4th, 2021

So I’ve found out I’ve made a huge mistake on my BKM-129X designs (all of them): The low pass filter of the THS7374 is *not* disabled as was intended. As I myself have no hardware to test 480p and above, so I never noticed the issue, but Bob from noticed when running 720p sources through it, there is a softness to the picture which shouldn’t be there. This is because I erroneously connected the BYPASS pin of the THS7374 to GND instead of VCC. This means that instead of disabling it, it is enforced. Nobody likes this filter, and it should never have been enabled! For 240p/480i/480p the filter makes no difference so if this is what you’re using the board for, don’t bother, but for 720p/1080i it makes a huge difference. Luckily the fix is rather easy, and can be carried out on already assembled boards.

Disconnecting BYPASS from GND

First thing to do is get the BYPASS pin (pin 9 of U2) disconnected from the GND plane.

The THS7374 (U2) chip. BYPASS/Pin 9 is the bottom second pin from the left, right above the via (the black dot).
Picture courtesy of

Pin 9 is connected to the GND plane through a small trace right in front of it. We need to cut this trace (or lift the pin). I prefer cutting the trace.

This small trace marked with red should be cut/removed.

Use a scalpel or boxcutter blade to gently cut it. Its not very thick but its important to ensure the connection is completely gone, and at the same time ensure the via is not destroyed. The pin to the farthest left is not connected to anything, the other is VCC. Measure that connection to GND is gone by using a multimeter set to measure resistance.

Connecting BYPASS to VCC

After severing the pin, we need to connect it to VCC to force the low pass filter off. Luckily the pin right next to it, to the right, is VCC. The easiest is simply adding a small blob of solder to the two pins.

The BYPASS pin bridged to VCC pin (pin 10).

That’s it. Enjoy 720p, and sorry for the inconvenience.

De-mystifying the BKM-68X

March 11th, 2021

– or “How my love for logic analyzers is re-affirmed”

This is both a documentation project as much as a reference for myself. I will update this as I figure stuff out, so this article is in no way “final” (yet). I’ve decided to release it as openly as possible, mostly to maybe get feedback and ideas, but also to show the world that reverse engineering projects of the BKM-68X *is* being done. Please send me any ideas or thoughts about the project ( but please no “When is it done?” and alike. It might come “soon”, it might come never.

In the current world of CRT enthusiasts working with professional monitors, there are few input cards that has a more elusive status than Sony’s BKM-68X, the analog RGB/YPbPr input card for Sony’s BVM-A series. This card is the only way to get analog component signals into the BVM-A series, at least without any converters. The BVM-A series came very late in the CRT era, and thus lot of production had already shifted to digital formats and utilized digital formats like (HD)SDI as the transport, instead of analog formats. This seemingly means that there are very few BKM-68X in existence (the talks are around 1000 units) in comparison to the number of available BVM-A’s, which then usually sports the (HD)SDI card BKM-62HS and maybe the BKM-61D (SDI and composite/S-Video). The scarcity of the BKM-68X means that they often sell for more than $2000 a piece, if they are even available. Given that the A-series are young monitors, they are desirable given that their tube-time is often quite low.

So, in the world of retro-gaming, digital formats, especially not SDI are usually not desired, while young tubes, high TVL and RGB is are. Shelling out $2000+ for a input card is however insane for many, which often leaves BVM-A monitors undesired (there are some other issues with the 68X/BVM-A, especially sync wise, but forget about that for now). In general increasing the availability and decreasing the costs of the BKM-68X, would be helpful for the retro-gaming community, which makes it a good candidate for reverse-engineering.

When I released the reverse engineered BKM-129X card, a lot of people asked me about the BKM-68X, to which I normally replied “Forget it”. This was because the design is *massive*. The card has so many components that it looks like the surface of the Death Star, and if some X-Wings appeared trying to find an exhaust pipe to bomb, nobody would really find it weird. At the component level, Sony has also blessed us with black-box units like a FPGA plus a CPLD at the same time, so yay!

The BKM-68X. Picture is courtesy of
The Lattice CPLD and Xilinx Spartan FPGA. Picture is courtesy of,

One night however, my life was apparently going so slow, that I ended up looking at the service manual for the card (most likely to avoid watching Dora the Explorer, Bob the Builder or alike), which sports the full block diagram and schematics to the card. By looking at the signal names for what is seemingly thrown around on the IO connectors (of which there are two 100-pins) and by looking at the signal paths, it made me believe that the card is seriously over-engineered, at least in the context of retro gaming, and that many features can be simply omitted, if the goal is not a replica but a basic “alternative” which supplies RGB/YPbPr to the A-series, and that’s it. It’s my belief that this would be beneficial to 95% of the A-series owners, of which I suspect very few are professional video editors, and many retro-gaming enthusiasts.

What really made me interested was this part of the block diagram:

The block diagram for the interface between the BKM-68X’s CPLD and the monitor.

Plus the part of the video signals:

The video signal portions of the BKM-68X card.

Now the CPLD interface suggests a quite standard parallel interface of a shared address/data bus, plus the video signals seemingly are normal analog RGB/YPbPr along with separate horizontal and vertical sync signals.

All around the board are signals which are generally in the same “vicinity” to the ones of the BKM-129X, namely: VIDEO_OE_X (video output enable, active low), INT/EXT_X (internal/external sync, active low), HD/SD_X (high definition/standard, active low) and so on. There is some circuitry that seemingly seems able to do some “magic” to the input, like an aperture generator (I have no idea what that should be doing) but in the end, I this seems to be non-vital. In general though, looking at the signal paths for the RGB signal paths, they basically do through some filtering and buffering, with some different paths (filtering orders, delay lines) selectable by the HD/SD_X signal. It all ends up in the IC486, which is a AD8075ARUZ which is a 500MHz 6dB video buffer, that is still easily obtainable (and should most likely also be replacable by something like the THS7374).

As the address/data bus should be able to be “eavesdropped” on, exactly like the SPI-like bus for the BKM-129X, it is my firm belief, that a viable alternative can be created.

Of course reading the contents of the EEPROM for at least the FPGA could be possible, but using the data would be against the law in many countries, and in the end also still require the same FPGA unless the bitstream was then reverse-engineered.

Accessing the hardware

To be able to actually do such a project, the original hardware is strictly necessary. Fortunately I was gifted a BVM-A20F1M with a BKM-15R for the project. The BVM didn’t have the BKM-68X, but it did have the BKM-62HS, so it was a start, even because the 62HS’s digital signals still end up as analog video coming into the monitor. Technically, this would mean that even just ending up being able to impersonate a 62HS might give a “workaround” card. However seemingly the card supplies YPbPr to the monitor, plus there are some horizontal scan rate “issues”. Jumping a bit in time, I was lucky to get an original BKM-68X donated to the project, which opened up the possibilities to make a board much closer to “what we want”.

To eavesdrop on the communication, I developed a small “breakout” board that could be inserted between the monitor and the card, which breaks out each 100-pin connector:

BVM-A card breakout.

The connector is a JAE TX24-100R-LT-H1E (mating with TX25-100P-LT-H1E). This card allows me to easily attach the probes of my logic analyzer and listen in on how the card and monitor speaks to each other, exactly how I also dealt with the BKM-129X card. I still need to solder a couple of wires onto miscellaneous spots of the board, as to find the command sequences for the different “options” (internal/external sync, RGB/YPbPr etc.). This is kinda fear inducing when you start to solder onto a $2000+ card. Luckily though, there are some resistors at all points of interest that can be used:

INT/EXT_X @ R885
HD/SD_X @ R838

Also to be sure how the data exchange works I needed to figure out when the data bus is driven by the CPLD and when it is driven by the monitor. As can be seen in the service manual, the CPLD has 8 address/data (A/D) lines in and 8 A/D lines out, both “buffered”, but the A/D out lines, has an “output enable” signal (AD_OE_X) attached to it. The same goes for the IRQ_X signal which is tied to the IRQ_X/SLOT_X signal, through a buffer, which is enabled by IRQ_OE_X signal. These signals can be observed at:

IRQ_X @ R914
IRQ_OE_X @ R915
AD_OE_X @ R916

The address/data bus and relevant control signals.

The signals of interest are thus:

AD[0:7] (8 bits/1 byte) – The address or data byte being transmitted
A_X/D – A/D byte is address when this is low, or data when it is high
R/W_X – Data is read when this is high or written when low
CLK_RW – Data is latched on the this, seemingly on positive edge
AD_OE_X – Address/data bus is controlled by CPLD when this is low
IRQ_X/SLOT_X – Seemingly when this is low, the monitor interrupts the card *OR* when IRQ_OE_X and IRQ_X is low, the card interrupts the monitor
RESET_X – Reset the card on low

So 15 signals, plus the 4 internal-card signals (VIDEO_OE_X etc.) meaning 19 signals. To do all this at once, I had to upgrade my logic analyzer to more channels, so I bought one of DreamSourceLabs DSLogic U3Pro32 and srsly, it’s awesome. If you need a cross platform logic analyzer, I can recommend this (I use Ubuntu/Linux as my primary OS).

As with the BVM-D9 and D14, the monitor starts speaking with the card already at standby-power (when the mains-switch on the back of the monitor is flicked), so I set the logic analyzer to sample at 20 MHz for 50 seconds from when I flicked the switch, and ho-lee-phuck, these monitors speak, jesus christ.

Analyzing the data

So here’s a screenshot of DSView of the data:

Initialization, settings are RGB with External sync (no signal input)

So first, again, there’s a lot of data, and at first, I noticed that CLK_RW pulses were 50 ns (20 MHz) in width, which means when I sample at 20 MHz, I’m not upholding Nyquists Sampling Theorem, which says that to properly sample something at frequency X, you need to sample at 2*X. This means that I needed to redo my measurements at 50 MHz (next available sample speed on my analyzer) at least if I wanted accuracy in the timing between edges. Doing this showed that clock pulse widths are 40 ns so 25 MHz(!).
At first I was unsure of what to make of all this data, because according to the service manual of the monitor, each slot has a separate SLOT_X_INT_X signal *and* CLK_RW signal. This would indicate that it would only clock data to the card (with CLK_RW signal) when it was speaking to the specific card. Seemingly all these data points are clocked in, which would, at first glance, mean that all this data was bound for the card. Luckily after “working” through the data, I got an “epiphany”: The card “changes” which commands it reacts to depending on which slot it is in, and this is actually somewhat of a kicker, because it narrows the amount of data to react to considerably down. The idea can be seen here:

One of the first command sequences, here card is in OPT1, so first slot.
Same sequence, but a “block” later, when card is in OPT2, so second slot.

So first the monitor issues a 02h command, followed by 01h which asserts IRQ_OE_X (interrupt output enable, active low). Then comes FFh (which denotes a start and end of command sequences, as will be seen later). Then it issues a of 10h 03h XX (XX = 01h-07h), FFh then 02h 00h which de-asserts IRQ_OE_X again (thus seemingly allowing interrupts from the card again). Now in the first picture, it can be seen that SLOT_X_INT_X goes low in the 10h 03h 02h (where the card is in OPT1 slot), but in the second picture, it goes low during 10h 03h 03h (where the card is placed in OPT2, so the second slot). As the first slot is actually the network card (or whatever we call it), where the remote and such is placed, it makes sense that OPT1 is actually slot 2 (in the monitors sense), OPT2 is slot 3, OPT3 is then slot 4, then comes whatever the other “cards” are in 5 and so forth.

EDIT: Using my eyes, the monitor even says so 😀

The monitors label explaining the slots.

When the card is in OPT1 as the only one, it reacts to commands in the 2Xh, while in OPT2, it reacts to 3Xh. The monitor does try to read 3Xh and 4Xh addresses, from time to time, but when there is no card there, nothing responds.

Blank read from 30h 00h when card is in OPT1.
Blank read from 20h 00h when card is in OPT2.
Succesful read from 20h 00h (returning 88h) when card is in OPT1.

So all in all, we can now assume that only commands starting with 2Xh is actually intended for the card, when sifting through the data recorded when the card was in OPT1. I will generally show 2Xh commands as I’ve got most data from the card in the first slot, so in all those cases, practically the first byte could be 3Xh or 4Xh if the card was in OPT2 or OPT3 respectively.

Command format

From this it can be deduced that the general command format is like this:

First the monitor issues a FFh with AX_D low and R_WX high.
Then it writes a “command/register byte”, then an “offset” byte, and then the actual value (either read from, or written to, denoted by R_WX), and then a FFh more.

So an example as above is FFh 20h 00h 88h FFh, where R_WX is high on the last byte, meaning the monitor is reading byte 00h from register 20h, in the above example, this returns 88h.

For the two “special” commands, 02h (IRQ) and 10h (setup/init) it starts with the command, and ends with FFh.

Here is an example of a write:

A write sequence

So here it writes A0h to 32h 25h, so FFh 32h 25h A0h FFh.

Card identification

So first part is figuring out where the card is actually being identified. Analyzing the data from the BKM-68X, BKM-61D and the BKM-62HS shows that the first difference lies in the response of the read from 20h 00h, which responds 88h on BKM-68X, 81h on the BKM-61D and 82h on BKM-62HS. This also the first command issued to the card, before all the serial stuff and whatnot begins.

Serial number readout

Command 23h seems to read the serial. The serial must be read out from some PROM by the card internally somewhere, as I suspect the Xilinx FPGA actually contains a softcore CPU or something, because there are some “wait-states” where the monitor issues some command, then repeatedly reads some register until it turns to some value (00h), then reads another register, seemingly verifying its contents, and then repeats the process if not “accepted”. One of those registers is the serial, first byte, 23h 00h. Initially the monitor issues some commands, reads a register until it turns 00h, then reads 23h 00h, which returns 88h (like the identification register). If this is the case, the monitor re-issues the command sequence, reads the register, repeats until this register returns at least 32h, which is the first byte of the serial (just as with the BKM-129X, this is ASCII coded digits, so 32h is 2). The complete serial is then located in registers 23h 01h, 23h 02h etc. until 23h 06h as there are 7 bytes in the serial (eg. “2 0 0 1 3 3 7” would be represented by 32h 30h 30h 31h 33h 33h 37h), so:
23h 00h 32h
23h 01h 30h
23h 02h 30h
23h 03h 31h
23h 04h 33h
23h 05h 33h
23h 06h 37h

Video format settings

Command 21h seems to work on the video settings.

Register 10h (21h 10h) works on (at least) VIDEO_OE_X (video output enable, active low), INT_EXT_X (internal/external sync, low = external) and APA_ON (Aperture). The bits of the data byte I’ve identified are:
Bit 3 is VIDEO_OE_X (0 = VIDEO_OE_X -> HIGH, 1 = VIDEO_OE_X -> LOW).
Bit 2 is aperture (1 = APA_ON -> HIGH, 0 = APA_ON -> LOW)
Bit 0 is INT_EXT_X (1 = INT_EXT_X -> HIGH, 0 = INT_EXT_X -> LOW).

Register 31h (21h 31h) is the detected video format. This detection is seemingly done by the card itself. When the card detects video, it de-asserts the SLOT_X_INT_X signal, thus interrupting the monitor, which then issues some commands, including reading this register. I’ve identified the following data byte meanings (21h 31h XXh):

00h – No video input
01h – 576i / 50 Hz (verified with EU Wii/EU PS3)
02h – 480i / 60 Hz (verified with US SNES)
03h – 576p / 50Hz (verified with EU PS3)
04h – 480p / 60 Hz (verified with EU Wii)
0Ch – 1080i / 60Hz (verified with EU PS3)
13h – 720p / 60 Hz (verified with EU PS3)

I need further units to know the values for other supported, however my guess is that some of the others are:
0Bh 1080i / 50 Hz
12h – 720p / 50 Hz

Given the supported formats here:

Supported formats from the BVM-A20F1M manual

So when the card detects an input (change) it de-asserts INT_X (which de-asserts SLOT_X_INT_X), and waits for the monitor to issue a sequence of commands.

Impersonating the BKM-68X

So to make a “clone”, there are some hardware requirements we need to meet, which does go out-of-spec compared to normal microcontroller options, namely the 25MHz I/O capability. Given that the 68X *and* the A-series are pumped full of FPGA and CPLD technology, the obvious choice is to use a FPGA.

… To be continued

Sony PVM-20L1 RGB mod

January 12th, 2021

This should also work for PVM-9L1, PVM-14L1, SSM-20L1 (confirmed) and in the end also other monitors using TDA9394H jungle, at least if you can get to the service menu. Note that capacitor numbers will be different for others. Check the service manuals and verify according to the jungle pins.

So a guy approached me because he had a PVM-20L1 without RGB, and asked if it was possible to mod it for RGB SCART. The unit uses a TDA9394H jungle which is very sparsely documented on the web. There are some mentions of it on the RGB mod thread on shmups and some different documents at least showing the pinout. These pinouts show that it has a separate RGB/YUV input on pin 50 (INSSW2/blanking), 51 (R2/Y), 52 (G2/U), 53 (B2/V), so that is our point of interest. Now the jungle is one of Philips’ which are known to have bits to disable/enable these kinds of inputs through I2C, usually the bit is called IE1 or IE2 (for Interrupt Enable), and this is no exception.

Enabling RGB

Looking in the service manual for the PVM-20L1 there is a walkthrough of the service menu, where the IE2 bit is shown/mentioned, and that relates to this external input. Thus we need to enable this bit.

TLDR; Open the service menu (Menu then Menu+Enter for 5 sec), SYS->Maintenance ID=111, DES->CONTROL0->IE2=1, ENG->Comb filter=Forced, save by Menu+Enter for 5 sec.

The service menu is accessed by pressing Menu once (so the “normal” menu comes up) and then pressing Menu and Enter simultaneously for 5 seconds.

The service menu.

Using + and – keys and “Enter” (“Menu” goes back), go to SYS and change Maintenance ID to “111”, press “Enter” to accept.

“System” menu
Setting “Maintenance ID” to “111” unlocks the settings we want to change.

Then go to DES (Design) and into CONTROL0 (on “page 2”). Here the IE2 bit is found so set it to 1. Press “Enter” to accept the setting.

Enable IE2 bit.

Right now, if we had everything hooked up, we’d see a nice RGB signal, BUT IT WOULD BE IN BLACK AND WHITE!!!1

So after going nuts about this, I talked to MarkOZLAD whom many might know from shmups and the RGB mod scene in general, and he hinted that he’d heard that the TDA93xx units needed CVBS for sync to have colors… Aha, so I tried this, and whaddyaknow, it worked.

Ok, but I have CSYNC cables for many consoles, so the suggestion was to create a board that encoded RGBS to CVBS and use that as sync source, to be able to support all RGBS inputs. This can be done “pretty” by using an RGB amplifier like THS7374 along with an AD724/725 RGB to CVBS encoder, and then feed the CVBS to sync, and RGBS to the TDA9394H. I actually begun a board for that, until I stumbled upon some people discussing the same jungle on the CRT Discord. Here a guy, “nut” had apparently fixed this (on a similar PVM I think) by changing “Comb filter” setting from “Auto” to “Forced”. Now this setting I had not seen, and I had been through them all (I thought) so I went back to the service manual, and goddamn, it was there, but NOT under the DES, but instead under ENG (and still needs “Maintenance ID” set to “111”). Flipping that, and glorious color was back! Thanks Mr. “nut”!

The “Comb filter” option

Now the “Comb filter” option is apparently since software 1.2, I don’t know what it looks like on earlier.

Hooking up RGB

So now to actually hooking up the wires. I will be using the SCART board which I’ve used several times, and I will be injecting 0.7Vpp directly through a couple of 0.1uF resistors, after 75 Ohm terminating it. The SCART board can be found here:

The TDA9394H is situated underneath the main board, so in order to get to it, you need to more or less remove it from the monitor. Pull off the metal case and plastic back, by removing the screws. Pull it backwards a bit, then up. There are a lot of wires to disconnect, find what works for you best. Tip: The small grounding “clip” which there are two of on the tubes lower left back, has a small “release” that needs to be pushed backwards to remove it.

Remember to discharge everything (there seems to be bleeder resistors, so if you have left it unplugged after some time, seemingly there is no charge, but warning warning)!

The TDA9394H jungle.

So locate the jungle that looks like above, and locate the 4 capacitors, C065, C066, C067 and C068.

The capacitors of interest

We need to remove them all, at least C065/66/67, but I took them all. For future reference changing C068 to a 1K resistor here might make sense, but I placed it elsewhere (and didn’t wanna take it all apart again).

Caps removed

Now injecting can be done on either the cap pad or on the small test/solder pads on the traces. I chose the test pads. Now C065 was blue/B2, C066 was green/G2, C067 was red/R2 and C068 was blanking/INSSW2.

The pads I used. Purple is blanking.
Wired up. You also need GND of course. White is blanking.

Now bend the cables onto the other side, from the front, as the sides are not accessible due to the “rails” that the board slides into.

Cables, cables, cables!

Attach the RGB to a circuit like this:

As stated, I have this on the SCART breakout board, but if you use other connectors like BNC, do your thing. Note that when IE2 bit is on, INSSW2 is weakly pulled to 5V. Thus if you need to switch to composite, you should add a 1K resistor between blanking and GND, and switch that, or add the resistor and blank with 5V (I use RGB blanking/pin 16 from SCART).

Add sync directly to the BNC inputs (on the PCB) and the same for mono-mixed audio to RCA input. I used input B.

Yellow is sync, white is audio.

So with that, turn on, select input B, and RGB input on 20L1 and friends is now possible! Then comes the fun of physically putting the SCART or BNCs or whatever somewhere…

Attaching SCART

So the back plastic part is attached to the metal casing by some plastic rivets. Now these can be removed by simply putting a flathead screwdriver in and they pop out. It is however not a very durable solution in my experience, and I have no idea how easy it is getting spares, so I spent some time contemplating on how to attach the SCART to the back while still being able to remove the whole thing and not tear everything apart. The solution I came up with was soldering connectors to the SCART PCB thus making the wires detachable from the PCB.

The SCART PCB with connectors on. You can see the small 1K resistor between blanking and GND if you look closely. The split connector is simply because I didn’t have any 10 pin angled ones.

Now as can be seen, I needed to make an opening in the side of my normal SCART bracket and then I designed a small detachable cover for it. To get the wires out, I clipped a little of the grille out. The designs including FreeCAD source can be found here:

The small “lid” for the bracket
The grille clipped out

The finished system then looks like this:

The disconnected wires.
…and attached

And of course some pictures

Sonic 4, best SNES game ever.
The “That guy with the brown jacket” game!

RGB modding the JVC TM-H140PN

October 18th, 2020

This is somewhat of a “short” post as I haven’t done the mod myself, but it has been verified that my software also works on this monitor. It’s mainly to index that it is possible to RGB mod it, using the I2C interception method as I’ve described for several other JVC monitors. Pictures and schematics should be credited to Victor Clausson.

The mod is somewhat closer to the DT-V100CG mod than the TM-A140PN one, as the jungle of the TM-H140PN is a TA1276AN and not a TB1226EN as the TM-A140PN uses. This means the software for the Arduino to be used, should be this:

Update regarding the Arduino software

Some time ago, an user told me he had a problem with the RGB dropping out every 4-5 seconds, being worse with some consoles, and others showed rare dropouts. We never solved it at the time. Another user contacted me with the same problem recently and we seemingly successfully fixed the issue, and version 1.2 of the software was made. If you’ve already done this mod with 1.1 of the software, and experience this issue, try upgrading to version 1.2.

Now just as with the other mods, the jungle needs to be isolated, and the Arduino put in-between the monitors microcontroller and the jungle (refer to some of the other articles if you want to know more). To isolate the jungle we need to remove resistor R540 (SCL) and R541 (SDA). The pads connecting to the jungle should then be connected to the Arduino on pin D5 (SCL) from R540 and D4 (SDA) from R541. The pads going to the MCU (so the other “side” of the footprint) should then be connected to the Arduino A5 pin (SCL) from R540, and A4 (SDA) from R541. On all 4 lines, a 100 Ohm in-line resistors should be added. On the jungle from pin 27 (SDA) and pin 28 (SCL) a pull-up resistor to 5V should be added to each. Usually I’d use 2.7K for these. Power to the Arduino can be taken from CN002 pin 8 and 9, which should be fed to VIN/RAW of the Arduino. Using a 5V rail connected to the 5V pin on the Arduino, can result in a monitor that won’t start. My guess is this depends on how fast the 5V rail comes up.

An example of the hookup. Power supply to the Arduino is still missing. Credit Victor Clausson.

To add RGB, we need to connect to TA1276AN pin 35 (R), 34 (G), 33 (B). Capacitor C519, C518, C517 needs to be removed, and each color line should include the “standard” 0.1 uF in-line capacitor and a voltage divider, like this:

RGB input line attenuation and DC bias circuit.

Now the above picture is actually not the best circuit, as it attenuates the signals more than necessary, and the resulting termination resistance for the lines is 105 Ohm (30+75) instead of the correct value of 75 Ohm. The thing is that the TA1276AN takes 0.5Vpp signals instead of the normal 0.7Vpp, so the voltage divider accounts for this. Many suggest (including myself on earlier posts) using R1 = 24 Ohm and R2 = 51 Ohm, as that creates ~0.5Vpp from 0.7Vpp and 75 Ohm termination, however I’ve begun using R1 = 10 Ohm and R2 = 64.9 Ohm, as this gives ~0.6Vpp which is stated as the maximum input for TA1276AN (I’ve tried direct 0.7Vpp also which works fine, but better go by the specs). This results in a brighter picture, but I’d rather turn down brightness on the monitor, than not being able to turn it up. Your milage and wishes may vary.

Sync should be connected directly to the input pin on either input A or B (on the PCB side of the BNC plug). Which you select will then decide which input should be selected for RGB.

To be able to blank (switch to RGB) you need to lift pin 32 of the jungle, and add a pull-down resistor from this to GND. I usually use 10K here, but the schematics from Victor says 51K. Use whatever 10K+ resistor you got. Now on pin 32, when ~0.75V or higher is applied it switches to RGB. You can use a switch for this, or use pin 16 from SCART, whatever you fancy.

That’s basically it. Check the full schematics from Victor here:

Credit to Victor Clausson

JVC IF-C01COMG Clone Full-size THT Edition

August 27th, 2020

So since I released the IF-C01COMG designs some years ago, several people asked me to make a full-sized card, I decided to finally do so. The result is this:

The IF-C01COMG THT clone

So this is basically my original THT base board thrown onto a full size PCB. The original was divided into two parts, mainly because of PCB pricing, which has now been reduced significantly by manufacturers like JLCPCB and so on. To use the available space, the complete BOM is written directly on the silkscreen along with various assembly instructions.

The board supports having either SCART or BNC connectors mounted, and has different audio options: When using SCART, the switch between the two RCAs select either passing the stereo from SCART to the RCAs or send it through a mono-mixing circuit to the internal speaker of the monitor, selected through SW1 switch. When using BNCs, the RCAs can be used as an input instead, running through the same mixing circuit. In that case SW1 should not be mounted, and needs bridging of a couple of pads (explained on the board).

I chose to use THT as I know some people find using SMD components a daunting task, so this should be possible to solder for most people.

You can find the complete Kicad project here, including the gerber files (found in the plot directory). The fil can be directly uploaded to PCB manufacturers that don’t support direct kicad_pcb files (like JLCPCB).

BKM-129X compatible, full size version

June 17th, 2020

So, latest addition to the family of BKM-129X compatibles, is a full size BNC version.

BKM-129X compatible, full size version

This is functionally quite close to the original, as it now has BNC outputs also. Since I couldn’t find BNC plugs featuring auto-termination (at a reasonable cost at least), I decided to add a switch to each signal which will either terminate to 75 Ohm, or enable passthrough of the signal to the OUT port.

Top view

It is then possible to set the switches to OFF (down) and use external terminators, or simply skip mounting the switches altogether, and add a jumper/0 Ohm resistor to the lower left two pins of each switch footprint, and then use external terminators.

The board requires the same Arduino with the BKM-129X-MCU code, directly programmed to the Arduino with a programmer (read some of my previous posts regarding this).

The MCU code is here:

The Kicad project for the board here:

The 3D printable bracket here:

Card inserted to PVM-9L2
Two 9L2s connected, bottom is the full size card (before bracket)
SNES with passthrough

Please copy, share, produce and become rich, of this 🙂

BKM-129X compatible SCART Edition

June 15th, 2020

So now after having most of the BKM-129X compatible monitors tested out properly, and some minor hardware adjustments fixed, I’ve made a spin-off of the BKM-129X compatible board, a direct SCART version with audio passthrough, and selectable mono mixing circuit.

The BKM-129X compatible SCART edition

Now there’s really not much difference to this board and the BNC version; the BNC plugs have been replaced with a SCART plug (I’ve used a Ninigi SCART, and then the two RCAs are added which feature the stereo audio passthrough from SCART. Along is a selectable mono mixing circuit, which is activated by the push button switch between the RCAs. The switch is supposed to be added between the RCAs. When pushed in, the stereo sound from the SCART is mixed to mono, when out, it is direct stereo. The mono mode is meant for monitors with audio inputs (which is always mono afaik) so a short RCA cable should be connected between the black connector and the monitor.

I’ve created a 3D printable bracket to fit in the slots for these cards, which will make everything sit flush with the monitor. The files can be found here:

Inserted into a PVM-9L2 with the bracket

So not much to it, the Kicad project along with gerber files can be found here:

Boot time difference on Arduino Nano v3.0 (clone) with and without bootloader

February 29th, 2020

So I wanted to see what kind of delay the built-in bootloader of the Nano v3.0 clones I have was causing, so I created a small sketch which basically sets up a pin as output and turns it on. I then attached my logic analyzer and measured the time from reset is released until the pin goes high.

Here is the measurement of the sketch, uploaded through the serial port, meaning through the bootloader, meaning bootloader is active:

Nano v3 clone with bootloader active

So here, from I release the reset, until the test pin goes high, is a delay of ~1,46 seconds.

And now, with the sketch uploaded through ISP/ICSP, meaning bootloader is now destroyed (and board cannot be programmed through serial port unless a new bootloader is added):

Nano v3 clone without bootloader

So now, from I release reset, until the test pin goes high, is a delay of 70 ms. Purrty big diffewence!

You can verify that the bootloader is now gone by checking the red LED on the board. When power is applied, it will blink once during startup (that’s the bootloader) and then do whatever your program does afterwards, so if it doesn’t, the bootloader is gone.

Now there are other bootloaders available, much faster ones also, but this is the one built into all clone Nanos I’ve worked with.

Turning the Arduino Nano clone into a programmer

So in case you don’t have a programmer (ISP) you can turn one of those Arduinos you have in the drawer into one! The Arduino IDE has a sketch that can be uploaded to any Arduino basically and make it act like a programmer, which you can then use to program sketches directly into other Arduinos, thus removing the bootloader, and reducing boot time dramatically. Here’s how to do it for a Nano:

Start the IDE, press “File“, press “Examples“, choose “11. ArduinoISP” and then “ArduinoISP“. It will then load that sketch. Press “Tools“, press “Board“, select “Arduino Nano“. Press “Tools“, press “Processor“, select “ATmega328P (Old bootloader)“. The “Old bootloader” versions have been the ones I needed to select for all clones I’ve used. You also need to select the serial port it is attached to in “Tools“. Press “Upload” to put the sketch in. You should now have an Arduino ISP. To get a stable connection, it is necessary to add a ~10uF capacitor between the RST and GND pins (negative on GND, positive on RST) on the Arduino ISP. Like this:

10uF cap between GND and RST on the ISP Nano

This is a hardware-hack to circumvent the Arduino from resetting when the serial data from the computer arrives. It is important that this is done after the ArduinoISP sketch has been uploaded.

Now to use your new programmer, open the sketch you want to write, select the correct board of your target (in this case no difference), and in “Tools“, press “Programmer“, select “Arduino as ISP” (note: NOT “ArduinoISP”, as that is a separate piece of hardware). The serial port should be the same as your Arduino programmer is connected to. You then need to connect the following with jumper cables (programmer -> target):

D10 -> RST
D11 -> D11
D12 -> D12
D13 -> D13
5V -> 5V

So quite easy for Nano -> Nano.

ISP Nano to the left and the target Nano to the right (and a Mini Pro top left, disregard that)

Then write the sketch by pressing “Sketch“, select Upload using programmer“. It should upload the sketch to the target, which now has zero bootloader, thus boots close to immediately. To reclaim the bootloader (or change it to another), simply press the “Burn bootloader” in “Tools“.

Creating a BKM-129X compatible board

February 18th, 2020

TL;DR Gerber files here

So in continuation of my previous post about reverse engineering the Sony BKM-129X the next logical step would be to actually create a functional card that is compatible with monitors that use the BKM-129X card. The first step I took was making a “clone” of the input circuit of the original card, but there are a lot of components, and especially one of them I had trouble finding a suitable replacement for (the 2SA1462 transistor). I am still unsure if the extremely fast switching speed (1.8GHz!) is needed, so I finished the design, with the intention of trying to build it at some point. The Kicad project can be found on Github, here’s Kicads 3D render.

3D render from Kicad of the BKM-129X “clone”

Now the design is 100% untested, but I am sure I’ll get around to actually building one at some point, even just to verify the design. If anyone actually builds one, please let me know how it went.

Making it cheap

When I was reverse engineering the card I ended up having a close to complete “harness” wired into the monitor, except for the video signals. While designing the clone card above, I came up with the thought of simply wiring buffered signals straight into the inputs, as this is really the only thing the board does besides some on/off switching of the signals. So an obvious buffer system nowadays is the quite common THS7374 IC I had lying around anyways for other retro projects, so I hooked up the signals from that into the monitor, and it actually looked quite good. The only thing then missing would be the switches to disable all the outputs, and toggling external sync on and off. Since the THS7374 buffers all 4 channels, the obvious choice would be to insert a simple quad SPST analog switch IC after the THS7374, with three of the switches’ enable signals coupled together to the ~BX_OE signal from the MCU (for the RGB lines), and the last to ~EXT_SYNC_OE coupled to the sync line output. This would then make the whole card require only 2 IC’s (and a couple of capacitors and resistors) to form the complete video signal path circuit. The switch IC I ended up with is the ADG1611, which is a rather expensive chip (~$6) however it has a very low on resistance (1 Ohm) on each channel, and although I add current limiting resistors afterwards, when I designed it, I preferred having to add resistance than being unable to reduce it (had I chosen a switch IC with a higher on resistance). The switch can be powered up to +/- 8V, to be able to carry negative signals also, which is perfect as the BKM-129X is fed +/- 6V from the monitor. The THS7374 can run off 3-5V, so I put a cheap 3.3V LDO in, fed from the +6V so only a single regulator is needed. I ended up “cloning” most of the circuit between the monitor and the MCU, as some monitors allow multiple cards, and I wanted to be sure the load would match the original cards. It’s mostly some resistors and then the 74VHC125 chip which is cheap anyway. Thus the finished prototype card ended up looking like this:

The cheap BKM-129X compatible (prototype)
Note the MIC3940-3.3 listing is wrong, it’s MIC3490-3.3, and 74LVC125 is a 75VHC125 in a TSSOP14 package

The connections (from top) are Y/G, B/B-Y, R/R-Y, sync.

The complete price then basically consists of:
THS7374 – $1
ADG1611 – $6
74VHC125 (TSSOP14) – $0.5
Arduino Nano v3 clone (5V/16MHz) – $3
MIC3490-3.3 – $0.5
DTC144EKA – $0.2
64-pin connector – $1.5
BNC plugs – $5
Passive components (resistors/capacitors) – ~$3
PCB at JLCPCB – $3

All the resistors and capacitors are 0805 size except for the large 100uF/16V aluminium electrolytical which are 6.3×5.3mm.

So roughly $25 for the complete board… Beats $150 for the BKM-129X on eBay 🙂

The Kicad project can be found on Github.

I made a 3D printed bracket, which at the moment only fits my prototypes, as they’re a bit too deep (that is fixed in the Kicad project). I will redo it for the current one soon. The prototype when mounted in my PVM-9L2 then looks like this:

The card mounted in my PVM-9L2, only the prototype protrudes like this.

The bracket “grabs” the board and keeps it in place both from being pulled out when plugs are unmounted but also from moving side to side.

How the bracket holds the card

I have, for now, only tested on the PVM-9L2. The MCU code has been verified to work on a BVM-D14H5 also, so I am pretty sure it will work on the rest also. UPDATE Please read the part in the reverse engineering post regarding this (essentially you need to remove the bootloader).

Here are some photos from the card running in my PVM-9L2. Note they’re taken with my phone, and doesn’t represent how good it actually looks, but you’ll get the idea.

Streets of Rage 2 on SEGA Mega Drive 2 (60Hz modded)
Mega Man X on SNES
Gee what game is that?
Component/YPbPr with internal sync works fine also

You are welcome to copy, produce, sell the boards based on my work, actually please do!

The bracket kan be found here: (thanks to Nick Carney for the version which has signal designators on).


Preliminary results with the BVM-D9H series is that it’s not sync’ing. To make it work, R9 should be removed and a jumper inserted (most likely smaller 10-33 Ohms will be good also). Doing this should not affect other monitors.

Remember to refer to the previous posts about how to program the Arduino for maximum compatibility.

If you have any experiences with the project you want to share, feel free to contact me on Facebook (Martin Hejnfelt), Discord (skum), shmups (skum), email to or whereever you might find me. Please no more “Do the BKM-68X” though 😛