LCD monitor hacking "development" thread

[drugkito]

Finding LCD monitors that work with Amiga PAL/NTSC is pretty much a hit and miss game, with misses being much more common.
Sometimes there are even discrepancies between different revisions of a same model, where some revisions work while others don't.

BENQ BL912 and BL702A appear to be a sought after commodity since they support Amiga PAL/NTSC out of the box.
Unfortunately, aforementioned BENQ monitors are also no longer that easy to find, which motivated me to dig in a bit deeper into the subject.
A bit deeper turned into several weeks of studying, probing, hacking, cursing etc. Whoever tried to figure something out probably understands the feeling.

Anyway, I'm not going to go into a lot of details here, want to keep this one short and just give a preview of what's been done so far.
Might make an actual blog entry with lot more details, firmware programmer hw and sw and software for firmware editting later, who knows.

Here goes nothing......

So what makes e.g. BL912 so special compared to other monitors?
BL912 uses an AU Optronics LCD panel and a Realtek LCD controller.
There's 3 I2C EEPROMs and one SPI FLASH on board. 2 EEPROMs hold the EDID info, one is used to store user settings, while FLASH chip holds the firmware.
Firmware is read and executed by RTD controller which runs a customized Synopsys DW8051 (Intel 8051 compatible) MPU core.
It looks like rather standard RTD controller setup so all the magic is in the firmware. Hardware wise there's really nothing out of the ordinary.

Ok cool. There must be more RTD controller monitors based out there. And as it turns out there are and I got myself a few.
Desoldered the FLASH chips, glimpsed the content and compared it to the BENQ one. Not even similar... duh.

So anyway, even if I managed to make the appropriate changes to the firmware, it would be massively unpractical to desolder the flash chip, write the appropriate content and solder it back on for each of the modified monitors. Thare has got to be another way. After a lot of fidling around it turns out there indeed is another way.
Both VGA and DVI connectors have dedicated I2C lines which make communication with the controller chip possible. There's a series of commands which one can send to the controller in order to gain read/write access to the flash chip. Some days/weeks?/months? later I had an Arduino based device capable of reading and writing the firmware. Good, now we can fiddle with the firmware in a more convenient way.

After some more days/weeks of frustration and some major failures there seems to be light at the end of the tunnel. I've got some firmware modifications in place and software which can easily modify the firmware for testing purposes and got one of the Fujitsu B19 series monitors (which uses a different LCD panel and a bit different RTD controller than the BL912) up and running in PAL and NTSC without scaling artefacts etc. just by using the C= VGA adapter. It is now as capable as a BENQ BL912 but I'd like to fine tune it a bit more.

Some more work need to be done but this opens up the possibility of modifying/tuning most Realtek controller chip based LCD monitors for Amiga purposes.
The next thing is understanding all the delicacies of Amiga video signal and tuning the firmware accordingly. Any help in that regard is more than welcome so feel free to msg me if you have some insight and want to help.

 

[damiraga]

Great work and dedication!
This really sounds promising. Possibly, such tool could identify the controller and if it is the RTD one, allow you to update its firmware and make it Amiga compatible. If the communication is two way, maybe even the original firmware could be saved before the update, to allow simple firmware restore in case something goes wrong.
Unfortunately, this is all beyond my technical abilities, but if I can assist with any beta testing with some other monitor brands/models, I would be glad to help.

 

[drugkito]

Great work and dedication!
This really sounds promising. Possibly, such tool could identify the controller and if it is the RTD one, allow you to update its firmware and make it Amiga compatible. If the communication is two way, maybe even the original firmware could be saved before the update, to allow simple firmware restore in case something goes wrong.
Unfortunately, this is all beyond my technical abilities, but if I can assist with any beta testing with some other monitor brands/models, I would be glad to help.

You can download and restore the original firmware without issues.

If you find some Realtek based monitors I can provide the hardware schematics and software necessary to poke around, so just msg me.
Hardware is real simple. It's just an Arduino board with some wires going into the DVI/VGA port. Software on the other hand is mostly made by me and is extremely crude, borderline usable, where I just make stuff up directly in code as I go along. It does the job for now anyway.

As for the automatic detection of RTD chip and automatic update of firmware to make it Amiga compatible, it's just not really feasible. There's plenty of different Realtek controllers out there and while similar, they're all a bit different still. Even worse, there's no common enough line between firmwares of different manufacturers and monitor models to make the automated process possible. Some of the stuff also depends on the flash chip and the specific LCD panel being used as well.

In parallel, I'm also looking into MStar controllers (some Iiyama monitors at least) and while having figured some firmware stuff out, I have no way (yet) to read and write flash easily which makes it a massive pain and a no go.

 

[cloverskull]

Wow, super impressive work! I'm fortunate enough to own a Benq LCD that works with my retro gear, but if you're going to extend the capabilities beyond what the Benq monitors could do in the first place, I'd be super interested.

If only it was possible to make my CRT handle 15khz. That would be killer. Oh well.

 

[drugkito]

I haven't had much time today but I've managed to do some initial signal measurements and toy a bit with firmware to accommodate the measurements.
In effect, I've been able to get a distortion free image horizontally (ignore the vertical for now, haven't touched that part yet) stretched across the entire horizontal plane of the panel without any overscan area visible. On the image below just the 320 lowres / 640 hires horizontal pixels are displayed, without any overscan area:

However, this does raise some questions on how to proceed. Let me elaborate a bit. Back in the good old CRT days I'd typically position and size the picture so that it would be centered and stretched in a way that shell/wb window borders would be visible, with as little of surrounding area visible as possible. Some surrounding area would still be visible nonetheless. When working with WB for instance I would have border blank active so this area would have been black. However, there were some games and demos which used the overscan area, in which case I'd just fiddle a bit with CRT controls, make the entire game area visible and all was good.

Over here it's not so simple. One has to make a choice of what to show on the screen and once the choice is made it's more or less not adjustable by the user. What gets shown on the panel is essentially what gets digitized by the ADCs and transferred to the scaler before being transmitted over to the panel itself.

So, as seen on the image above, it is certainly possible to have a PAL image shown across the entire panel, which is nice for working with WB as the picture occupies the entire panel area and makes full use of it. However, this completely leaves the overscan area invisible and might cause problems with certain games/demos as part of the screen will never get displayed. So, the question arises what to do? Leave the overscan area out entirely or show (part of, some, how much?) the overscan area as well (picture in post #1) to accommodate such scenarios. Having (part of?) the overscan area visible doesn't make full use of the panel area on the other hand, which kind of sucks in WB. Make multiple firmwares available? lol

Anyway, I'm willing to take on some ideas and a list of games/demos making use of overscan would be appreciated as well. I know of Settlers and Pacmania for sure. OCS/ECS only, as I currently have no AGA machine available (donations welcome

 

[drugkito]

Some progress today...
Until I decide what to do with PAL and NTSC, I've fiddled a bit with other resolutions.
I've managed to get DblPAL, DblNTSC, Euro72 and Multiscan going, displaying full screen.

All artifacts on the images are due to camera. Anyway, happy with the result so far.
I've made these resolutions fullscreen for now. One other option is to make them a bit squashed vertically, to match the 4:3 aspect.
We used to look at these things on the 4:3 aspect monitors and this one has aspect of 5:4 which makes the image stretched 6.67% vertically when fullscreen.
Feedback on whether to keep these full screen or to match the 4:3 aspect very welcome.

 

[cloverskull]

My preference is to maintain the original aspect ratio. LCD monitors are so huge anyway that losing a bit of screen real estate to maintain being able to view content the way it was intended (i.e., correct aspect ratio) is, to me, a no brainer

 

[JHanna]

Very cool project!

 

[drugkito]

Very little progress meanwhile due to time restrictions + I got a bit distracted trying to gain access to Genesis LCD controllers (a lot of Dell and HP monitors use one). Got some initial things probed out and appears feasible but is going to take a long time to finish so probably gonna put it aside for now. Also managed to partially decipher flash content for a MStar controller (Iiyama monitor), but the question on how to access it without opening the monitor up and reading/writing the content without desoldering the chip remains. I've also been exploring monitor drivers from various OS versions etc etc. A lot of stuff still needs to be done. Meanwhile, I've got Super72 thing going on the test panel, which is not supported by BENQ BL912 for instance. Also been fiddling with some ideas on how to get deinterlacing going perhaps, without success so far.

I've also managed to obtain a small batch of Realtek based Fujitsu monitors where all have the same hardware but some have different firmware. Thinking about giving one or two away for a very reasonable price for beta testing to someone crazy enough to help out with this. AGA machine (as I don't have one), scope and Arduino Uno required. If you feel up to it, send me a PM.

 

[drugkito]

There's also one other very interesting option to explore in the future perhaps. There's a lot of generic LCD monitor driver boards on ebay and such, where almost all are Realtek based and support a bunch of panels. Since we can now mess around with firmware for Realtek chips, it's not unthinkable of just stuffing one of these RTD based replacement boards into any existing monitor and just run it as such.

 

[Dale423]

What about flicker fixing? Do interlace screens make you want to gouge your eyes out?

 

[drugkito]

Sure. They didn't initially but I fixed it to make our experience as original as possible

 

[drugkito]

To figure out what to do with PAL/NTSC I've now studied literally dozens, if not hundreds, of games and scene prods and how they setup their display.
My initial intention was to show 320x256(240) full screen with 4:3 aspect correction, with initial display window such to cover the default Shell/WB window. That works well for 90% of the games (especially older ones) and they look absolutely stunning when seen across the entire panel, with the note that some might display stuff a bit to the left or to the right of where the Shell/WB window is, which might require you to adjust horizontal position on the monitor a bit, depending on the game. 4:3 aspect corrected screen in that case still has 17 pixels leeway to accommodate for some vertical overscan, not full though, so there's still a chance some vertical lines might get cut.

However, there are a lot of games and especially scene prods that do display more than that. The fact is that Amiga can display a lot more than what my initial intention was. The two questions to address are how many horizontal pixels to display and how to center the display window.

For non PAL/NTSC resolutions I've decided to not care about the overscan area as no productions use such screens so they're useable only in WB. Firmware is set up in such a way to pick up the base resolution of such monitor drivers and setting the monitor up for them is rather straightforwad in WB 2.1+. Seting the monitor up for PAL/NTSC is not as straightforward, especially on KS 1.2/1.3 and I'm working on providing the setup disk/program.

 

[drugkito]

I've been toying with what's possible regarding the PAL/NTSC output today. Ten kilometer long post could follow, but I'll keep it a bit under.
Note that below I'm mixing lowres and hires pixels when talking about width, so 640px==320px. There's no strict notion of horizontal pixels really in analog video as such, there's just color signal per line, from when it starts until it ends. That's why Amiga can output e.g. 320 or 640 or 1280 pixels per line (more actually), by just clocking out the pixels faster between color signal start and the end. Was your analog CRT TV/monitor capable of following up with the signal and what was the aperture size on the thing, to allow for a clear picture, is a whole another discussion.

As I mentioned earlier, 640px wide screen looks great for most of the productions, both fully stretched across the screen or with aspect correction applied.
When fully stretched, 320x256 / 320x240 is all you get. If a game/demo draws outside that area, some of the screen stuff will get clipped.
With aspect correction in place you get some more pixels available vertically, not to the full extent of what the Amiga is capable of though.

So the sensible thing to do would be to support some overscan area, even though that will leave some horizontal black space for productions designed to run at default resolution (most). Therefore I checked what does the BENQ BL912 do, modified it as well to explore the limits, which turned out to be exactly the same as for this Fujitsu monitor.

In practice, both the BENQ BL912 and this Fujitsu one are capable of 720 px wide display when stretched full screen vertically. Also, none are capable of displaying a 720 px wide screen when aspect correction is applied. Technically, they are, but it's on the very limit of what they can do and user can no longer properly center the picture vertically, making it semi useable.
The next sensible lower horizontal value is 704 px, which incidentally due to some other reasons is also the width a lot of Amiga productions which go into horizontal overscan use.
Having 704px wide display also allows for visibility of all the lines Amiga is capable of outputing (286 PAL, 241 NTSC), making full vertical overscan visible at all times. Of course, since the display is aspect corrected for 640x256 size (and aspect correct multiples of course), if a game outputs 320px horizontally but say 280 vertically, you'll get a slight vertical stretching on the LCD. On analog monitor you might compensate by dialing down the VSIZE knob. I've yet to see an LCD monitor with VSIZE adjustment so this is just how it is.

Horizontally, 704px works great for most things. However, since Amiga can output even more (more than 750) even if production is displaying 704px it's a question where does it center them. Typically they do center around the area where Shell/WB window is drawn by default so that's good but is not so in every single case, so you might have to adjust HPOS a bit. This is what we'd do on CRT monitors as well, adjust HSIZE and HPOS all the time. Over here it's a bit more inconvenient though, as one must go through the menu system instead of just turning a knob.
For productions using more than 704px you can still dial down "Clock" through the menus, which gives you some more horizontal size, but you'll get scaling artefacts in form of vertical bars. I've obtained some VGA adapters with filter (VLR) over here on AmiBay to see if they actually do anything, especially in such a situtation, although I doubt.

So for now, I think this is how this thing is going to roll out. All supported default OS monitor drivers adjusted for use without overscan. All supported resolutions aspect corrected. PAL/NTSC 704px wide.
I've also created a PAL/NTSC setup disk, to make the correct PAL/NTSC setup easier, especially for pre KS2.1 users. On KS2.1+ machine, for all the suported resolutions, setup can be done from WB. I haven't coded anything on Amiga in decades so the setup progs are a complete hack and crap but should do the trick. If there's someone reading this who wants to help and can code asm please send me a message.

Another upside of this Fujitsu monitor as compared to the BL912 is a nice height adjustable stand and built in speakers.

Some pics (weird colors and artefacts due to camera and light conditions):

 

[Elmo Putney]

I have been on eab.abime.net since coming back to amiga a couple of years ago, just signed up to amibay: This is properly impressive work, it must have taken many hours.

 

[QuarXky]

Incredible work,
I love the world of electronic mods, I take my hat off to so much knowledge.

Thank you!!!

 

[drugkito]

Not much to say recently. Spent some time to reaffirm this entire story makes some sense, before investing more time into the tooling etc.
Obtained another Realtek based monitor, this time an Acer B196L (which should be the same as V196L) and made it go from this:

To this:

So, the thing does make sense, it's doable.

 

[highpuff]

Absolutely awesome work. Looking forward updates on this

 

[drugkito]

I'm giving one Fujitsu monitor away, for testing purposes, EU only, for just the shipping cost. It's yellowed and has a scratch on the screen but otherwise works just fine. To owner of both AGA and OCS/ECS machines as I was unable to test on AGA. First come, first serve.

 

[highpuff]

I can test it Have a few Amigas that I can test it with.