Roland V-synth GT2: возможности замены LCD Kyocera 5.7" на больший (7.5")

[Vladistone]

задумал поменять стоковый дисплей TCG057QV1AC-G10 5.7" на что-то подобное, но c большей диагональю 7.5" и с учетом того, что LCD-контроллер EPSON S1D113742 останется прежним, т.к. находится на материнской плате...
Суть моего приглашения к обсуждению в следующем:

1. меня смущает что в спецификации на железо указана совсем другая модель монитора KCG057QV1DB-G00 у которого 20-pinout (ну да бог с ним!), плюс в specs указана инфа на одно разрешение экрана QVGA = 320x240;
2. в спецификации на рабочий LCD контроллер пишут о VGA = 640x480 и до WVGA = 800x480 (это все LCD контроллер умеет делать, но нет инфы про QVGA) и пока все отлично работает! значит где есть пробел в информации на устройства...
3. в тех списках Kyocera вариантов с 7.5" с QVGA нет вообще... поэтому пытаюсь выяснить способность к адаптации OS между QVGA и VGA - продумали инженеры Roland эту способность или нет?

я предварительно подобрал 2х кандидатов на замену:

1. TCG075VGLEAANN-GN00-SA (подходит по FPC-pinout. но из-за его габаритов (толщины) - могут быть проблемы с установкой в стесненное пространство коробки синта)
2. TCG075VGLDA-G20 (подходит по механическим характеристика как slim-девайс, но есть ньюансы со 40-pin шлейфом (+LED-supply), которые придется решать путем JST/FPC переходника и попыткой впихнуть 2 шлейфа в 1 сокет)

но оба варианта не имеют QVGA/VGA switch-pin #32 (т.е. жестко "прибытый к пустоте" режим VGA)
поэтому вопрос:
- а как вычислить способность OS менять режим работы QVGA/VGA? что бы зря не питать иллюзий, в поиске нового LCD? т.к. меня смутила информация в SM про FPC-сокет pin #32 (скрин стр.44 SM с осликом ИА - подчеркнуто красным) о имеющем место переключениии VGA/QVGA ч/з H/L-импульс... (вроде бы как may be!)
- или всетаки можно учитывать тот факт, что без взлома OS - контроллер самостоятельно не справися с разрешением VGA (640x480) или как указано у него в дата шите "up ot WVGA (800x480)"?

- может кто даст свои рекомендации при выборе TFT LCD, на что обратить внимание?

 

[Vladistone]

Я нашел в data sheets на используемый в моем железе LCD controller S1D13742 упоминание об REG[36h] Special Effects Register, который по умолчанию 00h.
И если его его найти в входящем информационном потоке контроллера, и переписать на 01h - то фактически можно заставить контроллер работать в dubbing режиме QVGA (320x240) для передачи на экран с VGA (640x480) полноценной картинки...
Если я правильно понимаю подход к сборке "костыля"-ретранслятора? и уже на базе какого нибудь Arduino - спроектировать и внедрить, без грандиозного реинжиниринга операционки...
После вчитывание в буквари (data sheets):
Судя по host-параметрам указанным в SM (и если я ничего не перепутал с табличными данными, согласно битности (16bit) и глубины цветовой палитры RGB565 = 64K
)
вычислил вот эту таблицу кодировки сигнала для RGB(565):


в которой я не совсем понял суть маппинга между управляющими/control и Picture DATA (указано в красной рамке), поправьте меня если я ошибаюсь в следующем выводе:
управляющие биты данных находятся в первом импульсе для Windows на канале
control MSB - MD15 (PIN #131)
LSB - MD0 (PIN #101) - которые нам нужно отловить и исправить... (выделено желтым) при появлении адрессации [36h]
а picture DATA внутри остального массива дампа с передачей каждого окна/Windows-картинки:

А ловить адрессацию к REG[36h] Special Effects Register), надо на IC22 после управляющего сигнала на транзит от IC23A PIN#6

Только я так и не понял следующие решения по SM (снимок выше):
- почему Address и data RGB-bus подтянуты через RA30-31-36-37-38-39 10k к 3V3 ?
- каким образом работает IC38 LCD controller c xWR16-сигналом от IC25A (в крсном квадрате)
- ОУ IC22; 24; 26 HD74LV245ATELL могут работать как двунаправленные 8-bus ключи, то не следует из этого двустороняя связь хоста с LCD контроллером при первоначальном boot-запуске и обходе для согласования "правил игры" и возможными параметрами типа QVGA/VGA/WVGA поддерживаемой панели монитора? возможен ли этот опрос?

 

[Vladistone]

Пока вырисовывается вот такой "план захвата Англии":

распутывал печатную плату материнки V-synth согласно эл. схеме SM - куда мне цепляться для снятия показаний RBG-data для REG[36h] и control data [00h] (я полагаю до 8-bus буферов с IC22 и IC26) и с точки зрения удобства прерывания дорожек для установки hack-транслятора...

из моих собственных соображений:
Необходимо снимать полностью все MD-данные RGB (мета данные IMHO) на параллельной шине CD (0~15) + CA(0~7) т.к. иначе можем развалить протокол из-за рассинхронизации при обработке control LSB [00h] --> [01h] при появлении REG-адреса [36h]
Но там мусора ненужного перед LCD бустерами IC22; 24; 26 - мама не горюй!
а цепляться на выходе бустеров IC22; 24; 26 (уже на входе LCD-контроллера) - надо еще постараться втиснуться паяльником в эти SMD-элементы или шины log-анализатором с последующим перехватом RGB-потока данных...
нужен 32-канальный анализатор по хорошему, пока в распоряжении только 8-ch.
И еще в итоге надо планировать MK с 24~25-pin для входящего потока данных
- address (8 bit или 1 bit/ch) = 8ch
- MD или CD(0-15) - 16bit = 16ch
- плюс 1 для XBRD (в качестве триггера для считывания)
и 16-pinout для исходящего потока с исправленным LSB CD[0] на [01h]
итого выходит необходимо искать МК с 40-42 data pins
- многовато получается...
? какой МК потянет такой обьем для обработки параллельной шины RGB(565)? ХЗ

- или пойти по пути реализации прерывания сигнала XBRD на IC22; 24; 26 пока идет обработка данных в Arduino? (выделено синим цветом)
- или координально поставить вопрос: там ли я собираюсь прерывать RGB-шину?

Есть другие мнения? предложения?