Video --> SPI

[Lavr]

Есть вот такой "микропроцессор" из игровых приставок Денди, точнее - это фактически микро-ЭВМ UM6561:



Чаще всего она всё же встречается вот в таком виде:

um6561.jpg

Но это не меняет сути, в одном чипе содержатся 6502-совместимый процессор,
с портами ввода-вывода, звуковым сопроцессором, контроллером ПДП, и видео-
контроллером.
В общем - полноценная микро-ЭВМ, функции которой задаются программой
из картриджа.

Недостаток в том, что видео-контроллер не гибкий и расточен сугубо под
телевизионные стандарты.
И есть в связи с этим у меня мысль слегка сыроватая... но мыслю я её довольно давно,
и, может быть, вместе доведем до ума: А что, если к этой микро-ЭВМ на чипе дендика
приделать LCD-дисплечик с интерфейсом SPI, скажем, типа Nokia 3310, но
сигнал SPI сформировать из видео-сигнала?

Я представляю это вот так: из полного видео-сигнала выделяем компаратором
строчные импульсы - они будут запускать одновибратор, формирующий строб
интерфейса SPI (SCK) посредине строки видео-изображения.
Содержимое строки видео-изображения нам доступно программно (хотя и очень
непрямым путём - через спрайты).
Для логической "1" программируем всю строку в уровень максимальной яркости,
а для логического "0" - вблизи уровня черного.

Zeilensignal_unmoduliert.gif

Получится, что каждая видео-строка отвечает за 1 бит по интерфейсу SPI, что
должно позволить формировать изображение на экране LCD типа Nokia 3310.

Упрощающие факторы для такого способа: LCD после задания начальных координат
может принимать все байты изображения подряд - собственно и видео-контроллер
так выдает информацию из видео-памяти.
И второе - LCD не реагирует на комбинации сигналов, которые он не понимает.

Отягчающее обстоятельство: видео-контроллер Денди формирует по 256 точек
в 240 строках - после чего идет импульс гашения по кадру, и я не знаю,
формируется ли он в соответствии с ТВ-стандартом.
И второе: если одна строка отвечает за 1 точку на LCD, то за 1 кадр прорисуем
только 240 точек, а у Nokia 3310 - их 84х48 = 4032.

Другое дело, что, может быть в течение строки менять уровни чаще - Денди
вроде способен на 16 градаций яркости... но тогда строб SCK не очень ясно
из чего делать...

Вот такая мысль, слегка сыроватая... но, возможно, у кого-либо появятся интересные
соображения? Хотелось бы обсудить.

[VituZz]

Если внутри микросхемы есть уже порты ввода-вывода, почему их не использовать для программного SPI? С Денди я вообще не знаком.

[Lavr]

Если внутри микросхемы есть уже порты ввода-вывода, почему их не использовать для программного SPI?

Они "расточены" под ввод с джойстиков и специфической клавиатуры.

Поскольку у 6502 нет отдельного пространства ввода-вывода, можно, конечно, влепить и свои
порты в пространстве памяти картриджа.
Но использовать видео-сигнал как SPI всё же соблазнительно - видеоконтроллер всё-равно
торчит ведь на кристалле, и отключить его, насколько помню, нет возможности.

[Lavr]

использовать видео-сигнал как SPI всё же соблазнительно - видеоконтроллер всё-равно
торчит ведь на кристалле, и отключить его, насколько помню, нет возможности.

Вобще говоря, если там внутри микро-ЭВМ полный аналог UM6538, то вроде как он отключается:
http://www.nedopc.org/nedopc/upload/6538.rar

[Lavr]

Джентльмены, подскажите простой пример программирования NES - вывести статичную картинку.
(кроме Рюмик С.М., КАК СОСТАВИТЬ ПРОГРАММУ ДЛЯ ГИТС НА БАЗЕ “DENDY” - это я читал, и
“Архитектура и программирование Dendy” от Migera - тоже читал)

Можно на английском...
Я пошарил и сам в Интернете, но ничего подходящего пока не нашел...


P.S. Вроде как зарубежные NES - кодописатели начинают вот отсюда: Nerdy Nights week 1...X

[Lavr]

С Денди я вообще не знаком.

Я хотя и немного познакомился с ними, всякий раз, возвращаясь к ним, забываю, как у них
там всё накручено, поэтому выложу тут документ, чтоб в другой раз не искать его самому.

Ну и тем, кто с Денди вообще не знаком, я думаю, он будет интересен.

Famicom.pdf

Ну и хелп-файл от MiGeRA пусть тоже на всякий случай рядом будет:

dendy.zip

[Lavr]

Не хотелось мне читать про муторное программирование видеоконтроллера NES,
всё надеялся, что найду что-то типа программы "Монитор" для этой платформы...

Но "Монитор" я не нашел, и пришлось прочитать и вникнуть в программирование
этого видеоконтроллера.
Несколько муторно там всё, что обусловлено маленькой видеопамятью в 1 Кбайт,
но идея моя вполне осуществима!
И самой положительной новостью оказалось, что видеоконтроллер NES позволяет
выставить цвет "чернее черного"!

NES_Palette.gif

Это позволяет управлять выводом просто записывая такие элементы изображения
в видео-ОЗУ (блокировать вывод) без лишних аппаратных средств.

Единственное, что пока смущает, это цветовая вспышка...

TV_2.gif

Она как раз - на уровне "чернее черного", и может помешать компаратору.
Я так понимаю - она всё-равно присутствует, даже если выводится изображение BW.

Жалко, никто не сделал модель NES в Proteus, а то можно было бы логику предварительно
попробовать... а так - городить видеосигнал как-то придется...

[Lavr]

Джентльмены, подскажите простой пример программирования NES ...
...зарубежные NES - кодописатели начинают вот отсюда: Nerdy Nights week 1...X

Хороший обзор "с чего начать" программировать NES - здесь: Пишем для NES.
Жаль мне этот обзор поздно попался... но, тем не менее с кое-каким софтом помог!


P.S. Также могут быть полезны следующие ссылки:
http://nesdev.com/archive.html;
https://www.zophar.net/utilities/nesgraph.html

[Lavr]

Ну вот и мой первый опыт самостоятельного программирования NES!
Так сказать, "Hello, world!" в среде NES...

Wellcome.gif

Честно говоря, все, кто программировал на "Микроше" или "Радио-86РК", справятся с такой задачей
без особых проблем.
Там надо настроить один раз ВГ75, а затем помещать коды символов в видеобуфер.

В NES - очень похоже: настраивается видео-контроллер, а затем коды символов также помещаются
в его видеобуфер.
Ну разве что видео-контроллер у NES чуть посложнее...

Ну и программирование 6502 очень похоже на программирование начинающего изучать i8080...
Он знает, что есть аккумулятор А и пара регистров H, L (есть и другие - но пока не дочитал, и фиг с ними...)
Вот и у 6502 есть аккумулятор А и пара регистров X, Y, а больше ничего и нету!

В общем-то для тех целей, что обозначены в топике, достигнутого уровня фактически достаточно.
А то меня всё смущало: ну как я буду делать что-то из NES, когда я её программировать не умею!
Теперь немножко умею...


P.S. Пока программировал, просто подмывало меня заменить все эти BEQ и BNE от 6502 макросами на привычные
JZ, JNZ тем более, что в описании на ассемблер NESASM3 пример макроса был просто очень провокационный!

Code: Select all

            add    .macro       ; add a value to register A
                    clc         ; (handle carry flag)
                    adc   \1+1
                   .endm

P.P.S. А больше всего мешало при программировании, что LDA $2E - это не то, к чему привыкли люди,
начинавшие с КР580ВМ80А... У 6502 это: A<--[002E], а то что надо - это LDA #$2E ...

[Lavr]

Какая-то несостыковка получается при "соединении теории с практикой"...

На всех теоретических картинках уровни белого и черного в видеосигнале идут без цветовых вспышек.
Это я, собственно, и хочу использовать для преобразования Video в SPI...

Но цветовая синхро-вспышка в теории всегда на заднем плече строчного гасящего на уровне "чернее черного".

TV_img_big8.gif

На всех же реальных осциллограммах уровни белого и черного в видеосигнале действительно идут без
цветовых вспышек, а вот цветовая синхро-вспышка, насколько я вижу - просто на уровне черного.
Хотя разница между черным и уровнем "чернее черного" по теории должна быть порядка 7%, т.е. заметна.

cea-pattern.gif

iwatsu_screen_05.gif

Получается, что уровень "чернее черного" понятие довольно условное (что черный, что
"чернее черного" - видеосигнал на обратном ходе гасят) и разделять видеосигнал, видимо,
лучше всё же по уровню синхоимпульсов...

[Lavr]

По идее, привязка строба SPI очень простая - примерно на середине строки выдавать его фронт.
Вся строка целиком отвечает за один бит - это либо "0", либо "1".
Просто думал запускать формирователь строба по строчному гасящему, но чужие картинки
убедили меня, что лучше - по сточному синхро запускать формирование строба.
На время обратного хода по кадру - не выводить ничего, ибо это будут все "0".

А формирователь строба - скорее всего обыденный одновибратор типа АГ3 - попасть в середину
строки особая точность не нужна.


P.S. И, кстати, раскопал очень полезную вещь: цвет с его вспышками у видеоконтроллера можно
и вовсе отключить:

Разряд 0 регистра 2001h, при установке в 1, запрещает вывод цветного изображения.
Остаются только градации яркости.

[Lavr]

думал запускать формирователь строба по строчному гасящему, но чужие картинки
убедили меня, что лучше - по строчному синхро запускать формирование строба SCK.

Но ещё раз всё обдумав, я решил и вовсе отказаться от привязки к строчным гасящим и синхро-
импульсам, поскольку без дополнительной аппаратной поддержки трудно их запретить, к примеру,
в 10 последних строчках кадра, если возникнет такая необходимость, а по моим предварительным
прикидкам она возникнуть может, если изображение уже передано, но осталась еще часть кадра.

Поэтому я решил в начале каждой строки вводить в изображение свой синхроимпульс. Это легко
делать программно, без аппаратной поддержки, да и отделять только видео-сигнал проще:
компаратор настроить на примерно 0,6..0,7V - это может быть просто закрытый транзистор.

Всё остальное в преобразователе Video --> SPI привязано теперь к первому синхроимпульсу,
если он есть - преобразование запускается, в пустой "черной" строке преобразование не
происходит.
Все остальные сигналы в привязке к первому синхроимпульсу формируются ориентировочно согласно
следующей диаграмме:



Я реализовал весь этот механизм всего на двух микросхемах: К155ТМ2 и К155АГ3.

В качестве прототипа NES/FAMICOM/Dendi я решил использовать "Кроху". Есть некоторые
различия, конечно же, не в пользу КР580ВМ80А и "Крохи", но они непринципиальны...
Ну и программирую я на ассемблере КР580ВМ80А всё же пока лучше, нежели в мнемониках 65хх.

В общем, как только "Кроха" подала признаки жизни, мне оставался всего один шаг - прицепить
схему преобразования Video --> SPI вместе с всеми любимым LCD NOKIA 3310, немного колдунства... и...
ОНО ЗАРАБОТАЛО!!!


Впрочем, колдунство и некрасивые подпорки программно и аппаратно больше касались модели
"Крохи" и КР580ВМ80А.
Схема интерфейса Video --> SPI была уже предварительно проверена, правда, не с таким феерическим
визуальным рядом...

Электрическую принципиальную схему выкладываю здесь:

 Схема электрическая принципиальная: "Кроха" + интерфейс "Video --> SPI"

Еще раз повторюсь: "Кроха" всё же не NES/FAMICOM/Dendi, поэтому в схеме есть костыли,
компенсирующие отсутствие второго видео-буфера: приходится выключать видео-сигнал, пока
идет заполнение данными единственного видео-ОЗУ.

Кстати, если кому интересно, видео-изображение при работе интерфейса Video --> SPI вот такое:


Я также выкладываю файлы проекта с библиотеками dll - AS IS, с которыми все у меня работало.
В схеме и коде есть некоторые несуразности, сделанные по принципу: так оно работает, а вот
как надо - почему-то нет. Меня больше волновало увидеть вживую воплощение своей весьма
нетривиальной идеи.

И, кстати, идея эта вполне реализуема на любом отжившем своё "Спектруме" или любом другом
любительском недо-ПЦ. Интерфейс SPI чем и хорош, что не очень требователен к выбору частот
и стабильности...


P.S. Огромное спасибо коллеге PVV, без помощи которого всё это сделать так быстро было бы
в принципе крайне затруднительно!

[jdigreze]

Поздравляю! Вот это шаманство!

[Lavr]

Поздравляю! Вот это шаманство!

Спасибо! Сам, как ни странно, был доволен, хотя и был уверен в успехе на 99%...
Но всегда остаётся 1% на шаманство, колдунство и танцы с бубнами...

В этой связи одно замечание по поводу протокола SPI для LCD Nokia 3310.
Протокол SPI нам чаще всего рисуют вот так:

LAN_SPI.gif

Т.е. по заднему фронту SCK как бы происходит смена бита на линии данных.

На самом деле есть одна тонкость, по крайней мере для LCD Nokia 3310.
Я это прочитал в мануале, когда тестировал проект, и как ни странно, модель LCD Nokia 3310
в Proteus эту "фичу" поддерживает!

На момент снятия сигнала SCK сигнал на линии данных должен быть устойчив. Т.е. сначала -
"падает" задний фронт SCK, а потом уже - смена бита данных.
Это кажется странным, но это так. В документации конкретно написано: по переднему фронту
сигнала SCK бит данных "защелкивается", по заднему фронту - "сдвигается".
Так вот: на момент сдвига сигнал на линии данных должен быть устойчив.

[jdigreze]

Так вот: на момент сдвига сигнал на линии данных должен быть устойчив.

Меня это не удивляет, потому что, как я много годиков тому разбирался с SD/MMC по последовательному протоколу.