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!

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

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), I switched the something like 10 Ohm resistor which pin 22 was grounded with (R726), to a 10K, so it acts as a proper pulldown. After doing this, we could see that we could blank. 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 got black screen.

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). 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 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!

RGB Modding a JVC DT-V100CG

February 14th, 2019

TL;DR Some monitors don’t treat the registers regarding RGB picture of the TA1276AN jungle IC correct (as was the case with the JVC DT-V100CG), so when RGB modding these, the picture is dark or non-existent. I made some code for an Arduino that make it act as a bridge between the monitors MCU and the TA1276AN, for when RGB modding sets that use this jungle IC. Find code here:

Tell me more!

So I bought this small 10″ JVC monitor, that included the IF-C151HDG SDI card, and the manuals stating that an RGB card, the IF-C101CMG, should exist (no, not a IF-C01COMG, it’s not a typo). This card seems to be elusive, and I cannot find anyone who has actually seen one in real life, so I have doubts that it was ever released, also given how late in the CRT era this monitor was made.

The JVC DT-V100CG with a US Super Nintendo on top.

As I use my CRTs for retro gaming, I wanted analog RGB inputs, just like on my larger JVC sets, where I also cloned the IF-C01COMG card. Anyways, I started looking at the schematics (it’s on and how the IF-C151HDG worked, to get an idea of how the IF-C101CMG card might’ve been expected to work. It quickly became obvious that the DT-V100CG would never natively take RGB in, at least without modding the mainboard, as the RGB lines were unconnected (the schematics show them being coupled to GND through some capacitors, but they’re not mounted), and the pin that selects RGB on the jungle IC, YS2/pin 32, was directly tied to GND. The IF-C151HDG card converts the SDI signal to RGB, which is then “transcoded” to YPbPr through an analog circuit, which is then thrown into the jungle IC. Since the jungle IC converts back to RGB for the CRT, I started to feel this was a long way for an analog signal to run.

Anyways, the monitor uses the quite common (at least for JVC sets) Toshiba TA1276AN jungle IC, and many guides exist for RGB modding sets that use the same jungle, so I thought that that was the way to go. Looking at the schematics and PCB layouts, it seemed that I first needed to release the YS2 from GND to be able to control RGB. After severing the trace around the pad, I could measure that it was *still* connected to GND.

The severed pin 32

Looking closer at the PCB, I could now see that there were more than 2 layers of copper, but the other layers aren’t shown on the layout in the service manual, so the pin was most likely attached to GND also on a deeper layer. So the only thing left, was to lift the pin. So I did that, and attached the pin to a DPDT switch, that switched between 0V and 5V. According to the datasheet of the TA1276AN when YS2 is above 0.75V it switches to the RGB lines. You can find 5V on pin 15, at least on the DT-V100CG.

After attaching the switch, I tested that I could activate the RGB pins by connecting a composite video signal to one of the input ports, and then flip the switch to see the image become black (because I hadn’t attached RGB yet).

The lifted pin 32
Cable attached to pin 32 (I added some hot glue to ease strain later)
GND and 5V for the switch
RGB blanking switch

The RGB video signal should then be connected, which are pin 35/red, pin 34/green and pin 33/blue. Sync goes to Y1/pin 15, but instead of wiring to that pin, I simply wired to one of the composite inputs, as they also end up being routed to Y1.

Sync attached to composite input A

Now the RGB lines are shown to be 0.5 Vpp levels in the datasheet, which is a tad lower than the usual 0.7 Vpp. As it is desired to terminate the signals with 75 Ohm resistors to keep signal integrity, attenuating the signal to 0.5 Vpp requires a resistor around 30 Ohm in series with the signal. The 30 Ohm resistor is somewhat optional, since the jungle IC does accept the 0.7 Vpp signal, however this might cause a too bright image. I actually decided to put 15 Ohm in 😛

The circuit to attach to each RGB line (meaning 3x this)

So after making this, I attached a SCART plug, and fired everything up, aaaaaand black screen… Nothing was coming through. Now I had just heard a similar story from another user modding a JVC monitor with the same jungle IC, so I got curious. The other user had gotten a faint image, by removing all the resistors (the caps are necessary as the TA1276AN has a DC offset on the inputs) so I tried the same, and voila, there was a faint image, unusable, but still there. So the signal *was* coming through the chip, but it was *really* dark. OK, so I tried measuring it all through, to see if there was some short circuits or whatever to ground, I measured with an oscilloscope that the signal levels coming in were the right voltage, and so on and so on, but all was good.

I noticed that the brightness and other settings I could tamper with through the OSD, did absolutely nothing to the image. I then started to read the datasheet of the TA1276AN more thoroughly, to understand how this worked, and found out that all these settings, brightness and so on, are controlled by the monitors microcontroller (MCU) through an I2C line. I then saw that there were separate registers for brightness and contrast, depending on if it was external RGB (pin 33/34/35), or the internal signal generated by the chip itself from the composite video, S-Video or YPbPr. I then attached a logic analyzer to the I2C line and could see that brightness and so on wasn’t written to the RGB registers. But the two registers should be predefined to 80h, so unless the MCU actually reset them, they should still be good (except the most significant bit of the RGB contrast register, HI BRT, more on that later).

There is a lot of communication with different chips on the line, so I decided to sniff what was coming to this exact chip only, so I wrote a small program on an Arduino that acted as a I2C slave on the same address as the TA1276AN, that would write the data it received out to the serial debug. The I2C address of the TA1276AN is 44h, although stated as 88h in the datasheet, but this is because the datasheet specifies the address along with the I2C read/write bit, which is the least significant bit in the address byte. When writing, this bit is 0, so 44h shifted one bit left plus 0, is 88h. For the same reason they specify that the read address is 89h, because when reading, the least significant bit is 1, so 44h shifted one bit left is 88h plus 1, 89h. Anyways, since having two units with the same address on an I2C line is bad, because they’ll both acknowledge the data, I inserted a buffer between the Arduino and the I2C line (made by serial coupling two 74HCT04 inverting buffers per line), so the ack from my Arduino would go unnoticed. I could then read all data coming to the jungle IC, and noticed that register 05h (RGB brightness) and 06h (RGB contrast), were forcibly set to 0 by the system! Fuck a duck!

So to remedy this, there is only one solution (as rewriting the software for the MCU seemed a bit far reached), namely to intercept and tamper with the I2C communication. So I continued my Arduino program, and wrote a program that by using a secondary bit-banging I2C master, could act as a bridge between the monitors’ system and the TA1276AN, but where I could control what was being written, and to which register it would be written. At the same time the program had to deal with the constant status readouts the monitor does, because if something goes wrong, and something doesn’t respond, the monitor shuts off. The program now copies brightness and contrast writes to the RGB registers also, so the OSD actually also function on the RGB line. At the same time, it clears the HI BRT bit (High Brightness Colors) of the RGB contrast register, which apparently make the picture quite dull if enabled (maybe its because it expects the input to have high brightness colors, which it then attenuates a bit) which it is by default. The code was tested on an Arduino ATmega2560 clone, which is rather bulky, but I haven’t gotten the smaller Nano V3 yet, that should be possible to simply integrate somewhere inside the chassis.

Arduino Mega 2560 clone

I will update when I get the Nano, because the code most likely needs some tweaking also. You can find the code here:

To insert the bridge, it is needed to isolate the TA1276AN without disconnecting the other I2C units. On the DT-V100CG there are two 100 Ohm resistors (R6612 and R6613, you can see them to the left of the TA1276AN on the opposite side of the lifted pin 32) going to the I2C pins, which I desoldered, and then attached the Arduino to the bus, by using the pins on another I2C device (which was on the same bus, note that there are/could be multiple I2C busses) and then attached the “local” I2C bus from the Arduino to the TA1276AN. Since I2C requires pull-up resistors, and the internal pull-ups on the ATmega apparently can make the I2C bus slow, I decided to use some 2.7K external pull-ups connected like this:

If needed, 100 Ohm resistors can be placed in series on the line to avoid ringing

So I fired everything up, aaaand presto! Pristine RGB image! Note that this monitor has quite low TVL, and all images are shot with a phone. None give it proper credit.

Mega Man X
Contra III (duh)
The current setup 🙂

I now need to tidy everything up, get the Nano in, to contain everything inside the chassis. Although this was made for the DT-V100CG, any monitor that uses TA1276AN, but isn’t RGB aware, should be able to use this.


After getting the Arduino Nano clones, I basically just needed to find new ports for the secondary I2C bus, and that was it. I soldered the pullups directly to the board, and mounted it in the bottom.

The pullups mounted
The mainboard with I2C and RGB (and sync to input B)
The cable harness with the small board with the clamping diodes, 75 Ohm terminations and 15 Ohm attenuators.

I decided to use SCART and thus also have 5V blanking, so the blanking pin from the jungle was pulled low by a 51K resistor, and then the blanking attached to pin 16 on the SCART plug. I pulled all cables out the back and 3D printed a bracket to attach it all to, including 2 RCA for the audio out. At the same time I am going to build a small speaker (magnetically shielded) to allow for sound. That’s what the switch is for, select internal sound or pass to speaker.

The bracket. Yeah, it’s orange…

The speaker is going to sit in the corner, dunno how it’s gonna sound, as I haven’t received it yet. 3D files here:


Converting a T64 file to D64 in Linux (Ubuntu)

December 30th, 2018

So I had a lot of Commodore 64 games saved as T64 “images” which is very space conserving. I however had to use these on a SD2IEC which does not support T64, so the obvious choice was to convert them to D64, although it takes more space (as each D64 is a disk image, whatever remaining space there will be, will be “slack” space). Anyways, who cares about space in the age of 100’s of GB SD cards costing $20. The “best” option I guess would be to directly extract the PRGs but I haven’t gotten to that, and this page is more or less a reminder to myself… Anyways, I started to go through the internet to find a quick solution to convert all these games, and I found a lot of different options, mainly Windows stuff that would need to run in wine and most likely be non-scriptable to extract. Some mentioned c1541 which is a part of the VICE project, which is included in many Linux distros. As I use Ubuntu, this was also the case, so apt-get install vice, and it’s in. c1541 starts a “shell” to take commands in, but they can also be given directly from the command line. So without further ado, the one-liner that converts a .T64 file to a .D64 is:

c1541 -format <DISKLABEL>,00 d64 <DSTFILENAME>.D64 8 -tape <SRCFILENAME>.T64

<DISKLABEL> should be replaced with the desired label name of the disk.

<DSTFILENAME> is the D64 filename (without the .D64 suffix).

<SRCFILENAME> is the source filename of the T64 (without the .T64 suffix).

Example (for Blue Max):

c1541 -format BLUEMAX,00 d64 BLUEMAX.D64 8 -tape BLUEMAX1.T64

This yields:

Unit: 0
Formatting in unit 8...
Writing `blue max+' ($0801 - $5618) to drive 8.
Writing `blue max spic' ($0801 - $1A1A) to drive 8.
Writing `blue max+ crazy' ($0801 - $6324) to drive 8.

3 files copied.

And we’re good! Gonna look into the direct to PRG stuff….

Fixing Samsung 2493HM not turning screen on, blue LED blinking

December 15th, 2018

So I have a somewhat old Samsung 2493HM LCD monitor, which stopped turning on. The blue indicator LED would start blinking really short with a 1 second interval or so, but not turn solid on, and screen show an image. Sometimes if it stood blinking, it would suddenly turn on and screen would work fine, until powered off, and it would do the same again. This in my head sounded like a bad capacitor, so I disassembled the screen to investigate.

This is quite easy: Remove the 4 screws in the back on the bottom.

Remove these 4 screws

Then there’s a small notch in the bottom where you can insert something flat, and then simply pull the back cover off, use some force, it’ll be fine (hopefully).

Disconnect the CCFL headers to the left by pushing the gray small connectors’ tabs and pull backwards.

Remember! This is CCFL, so high voltage shit! Disconnect the power connector to the CCFL voltage board at the metal housing to the left.

Then the two cables at the lower right. Note the one I’ve marked here is quite fragile, I broke one of the wires, so the front buttons didn’t work until I rewired it.

Turn the whole block upwards. Theres a LVDS cable going from the A/D controller board to the right, disconnect that either by the screen or by the board. You can now move the whole block freely.

I didn’t take pictures of this, apparently, but most likely you can find a disassembly guide otherwise.

The power board has 4 screws, remove those, and the pull the ESD/grounding tape at the top to be able to remove the board. Note, again there are some high voltage capacitors here, especially a 450V/82uF sucker. Now inspecting the capacitors I found that this 2200uF/10V electrolytical capacitor (marked in red) had bulged and also it looks like it has leaked in the top.

Position of the leaked 2200uF cap.
That is one broken e-cap…

Anyways, I replaced this with a new, and presto, screen works a charm again 🙂

MFO, Multiple Frequency Oscillator

December 14th, 2018

When one is modding old gaming consoles to run both PAL 50Hz and NTSC 60Hz, often it is also required to switch oscillators to have 100% correct frequencies. This goes for machines like SNES, Master System, Genesis/Mega Drive and so on. A guy called micro made a DFO, Dual Frequency Oscillator, based on Texas Instruments’ programmable clock IC’s.

The DFO is really cool, and I’ve been using them a lot when modding. However I noticed on certain consoles, mainly the later PSX, like SCPH-750x and PSone, there are actually more than one frequency that is different from region to region. There is a Video DAC clock that needs to be changed to have proper vertical frequency and a carrier frequency for the composite video signals. Thus if running composite video on a PAL unit, in NTSC/60Hz mode, it would often be black and white, not due to missing NTSC decoding, but because the carrier frequency is 4.43MHz instead of the correct 3.58MHz. Although one could just use RGB and be done with it, but I like tinkering with this stuff, and make it _really_ working in both modes, so I decided that I wanted to take the DFO one step further, so I created the MFO. The MFO, a short for Multiple Frequency Oscillator, is more or less a copy of the DFO, but with the CDCE913 changed to a CDCE925 so I could create BOTH the 53.20/53.69MHz GPU clock _AND_ the 4.43/3.58MHz carrier frequency for the Video DAC at the same time. So the result was this:

The MFO. Multiple Frequency Oscillator

Here it is, installed into a PSone, SCPH-102, along with a onechip modchip. The two large THT resistors, was because I was out of the proper SMD resistors for the oscillator signals.

The MFO in a PSone, still missing the final connections.
The completed install.

The OSHPark design can be found here and here. The latter is a Rev. B, which is functionally identical, but with a more tiny design (space is often sparse).

Update! More details 😀

Download the hex file for the MFO for the PSX here (zip). I programmed it to the MFO by using cdceprog on a Raspberry Pi. CLK1 is the GPU clock while CLK2 is the sub-carrier.

Now injection of the signals will depend on your model, so easiest is to find the service manual and find the PLL that creates the frequencies for the system. On PSOne (and the others also AFAIK) it’s IC204. It creates 3 frequencies: One for the CPU, which is the same for NTSC and PAL, one for the GPU, (53.693175 MHz on NTSC and 53.203425 MHz on PAL), and one for the sub-carrier (3.58 MHz on NTSC, 4.43 MHz on PAL). The GPU clock goes to R205, which is a 220 Ohm resistor, close to IC203 (the GPU) pin 99. Remove R205, and inject on the pad going to the GPU by connecting CLK1 pad here. Alternatively inject on pad CL201 (still with the resistor removed of course). Replace R3 on the MFO with a 220 Ohm resistor (or use the one you just lifted). The sub carrier goes to R501 that connects to IC502 which is the Video DAC. R501 is a 2200 Ohm (2.2K) resistor, so remove that, and then on the MFO, change R4 from 18 Ohm to a 2.2K and then solder the CLK2 pad to the pad connecting to pin 15 on the DAC. The MFO’s S0 pin, which selects the frequency is then connected to pin 13 of the DAC/IC502.

RGB A/V Amp for PCEngine and friends

September 26th, 2018

So I bought a Core Grafx machine, and it’s really nice. It has composite output which is of course better than the RF-only white PC-Engine, however they all have that big expansion port on the back, which has both audio AND RGB signals in it, so somehow getting that turned into a SCART plug seemed a no-brainer. There are many boards on eBay and the likes, that do something with this port, giving composite video, giving RGB and so on, in different packages. Most of them are quite big, expensive and/or complex. I thought it would make sense to try to make a simplified version that was as small as possible, so I came up with this:

This is a 3D render of KiCad project. It is based on the popular THS7374 4-channel video amp, which amplifies RGB and composite, while sync goes through a 75Ohm resistor. The audio which is rather low, is amplified by a TS922A opamp. All this is then collected in a SEGA MegaDrive/Genesis 2 compatible 9-pin Mini-DIN plug, for which RGB SCART cables can be bought cheap on eBay. The cable should contain at least some 75Ohm resistors on the video lines (which the cables *should* have as the MD2/Genesis2 requires it) and 220uF or higher caps are also recommended, again they should be there. There’s a jumper behind the DIN plug to enable the filters of the THS7374, for a softer image if that is preferred. The large 69 pin plug is a Samtec SSQ-123-02-T-T-RA connector (which is quite hard to come by) and that can be substituted for whatever 2.54mm pitch 3-row female socket you can find, its only the left 6 pins (2×3) and right 9 pins that are used, rest are all kinds of unused stuff for this. The finished assembled unit looks like this:

And attached to the Core Grafx:

Here’s some pics of the unit attached to a JVC TM-H1950CG, but to be honest, my shitty phone camera does not do it justice, the colors are *really* nice, really much more vibrant than this shows…

Board with parts list here on OSH Park.

KiCAD project here.


Since the board just sits by the pins, it is rather poorly mechanically attached. I therefore designed this small 3D printable bracket to insert into the PC Engine expansion port to relieve the mechanical strain on the unit, and secure the PCB better.

The bracket inserted
Bracket and board

Download 3D files here (Thingiverse)

Cloning the JVC IF-C01COMG card, Through-hole version!

July 5th, 2018

So, after I posted the previous board around the internet, some people were “frightened” by the small SMD components as it takes some skill and also some more precise soldering irons to deal with these. I thus decided to make a through-hole version which is much easier to solder by hand. OSHPark page here:

Compatible with the same input boards as the SMD version. Enjoy!

KiCad project here:

Cloning the JVC IF-C01COMG card

May 2nd, 2018

Update: Through hole (THT) version here.

So I bought a couple of the JVC TM-H1950CG monitors, and they are crazy awesome, BUT only have composite and S-Video inputs by default.

As I was going to use these monitors for retro gaming I really wanted RGB(S) input and preferably with SCART.

I saw in the manual that a card existed to supply RGB input through BNC, the IF-C01COMG card. This card is rather rare and cost a fortune.
So while I searched for it, I found people RGB modding the monitor directly, by inputting the RGB signal directly to the “jungle” IC, which of course would work, however interfacing directly to the IC like this, seemed a bad idea ESD wise and so on.
So searching on, I stumbled upon this. This guy had looked into the original card and found that it was quite simple, and basically is some input protection, signal conditioning and so on, with rather simple components (roughly some transistors, resistors and capacitors). He (and many others I’ve found out) has built the circuit onto perf-board with excellent results. I prefer “real” PCBs so I put it all into KiCad (so awesome application) and made a PCB for it. The result is this.

Since I prefer SCART, and others might prefer BNC, some RCA, I thought that instead of making different boards, I would design it as a base board with the actual functionality of IF-C01COMG, but with the input connectors moved to a separate “daughter” board. This would also save PCB space which is expensive. I decided to use SMD components to save space, but decided on 0805 size as they’re possible to solder with “normal” equipment.
The SCART input board can be found here.


In order to fix the input board to the chassis, I designed a bracket to hold the SCART board, which can be 3D printed. The bracket can be found here.

I also have an untested BNC input board, check it out here.

KiCad project here:

So if you’re having trouble getting the real deal, here’s an option to fix your JVC monitor up with *real* RGB 🙂