Просмотр полной версии : Подключение Вектора к фоторамке...
Была мысля подключить к Вектору дисплей от фоторамки.
Вроде вход для дисплея фоторамки очень простой, синхра и RGB. Но рамка зараза требует определённое кол-во строк и точек в строке, и оно конечно не совпадает с тем, что предлагает Вектор. Соответственно картинка не формируется, рвётся...
Как вариант преобразования рассматривалось аппаратное на ПЛИС...
Но с ПЛИС не сталкивался, и беглый просмотр инфы не дал представления о том, какой сложности схему можно запихать в ПЛИС...
Понятно, что на ПЛИС есть и сам Вектор и Combodevice.
Но раздобыть удалось некую Альтеру, а её "вместимость" понять не могу...
По расчету на преобразование нужно организовать память в 128КБ с обвязкой в виде счетчиков и дешифраторов адресов...
Чей-то там у ПЛИСов есть в характеристиках макроячейки, как по ним понять схемную (корпусов/элементов) вместимость?
Ох, легко не будет! Зато интересно будет очень.
Я подключал Вектор к ЭЛТ монитору с помощью адаптера, который цифровал его, Векторовский, сигнал, врезал нормальную синхру и полочки и выдавал наружу. Но времянки все при этом оставались разумеется Векторовские.
С ПЛИС я бы попробовал сначала сделать сигнал, который удовлетворит фоторамку. Это влезет в любую ПЛИС. И потом, зная его характеристики, уже думал бы о том, что нужно сделать, чтобы адаптировать к ней Векторовский сигнал.
Микросхема в виде микросхемы, или в виде платы с питанием, загрузчиком, программатором или адаптером для программатора и еще чем-нибудь? Голые ПЛИС-ы, на мой вкус, это слишком хардкор чтобы вот так прямо начинать с нуля.
Есть еще микросхемы, которые умеют кушать в себя самые невообразимые видеосигналы и выдавать на выходе данные в удобоваримом виде. Пример проекта для VGA на TVP7002: http://www.rpg.fi/desaster/blog/2013/04/19/vga-framegrabbing-with-tvp7002/
Еще можно цифровать и микроконтроллером. Я так делал для БК, но там однобитное видео фактически. Для Вектора надо придумывать что-то хитрее.
Входы дисплея фоторамки очень просты, для эксперимента формировал для неё сигнал макетной платой. RGB, кси, сси, WR больше ничего не нужно. Из экспериментов выяснил, что количество точек в строке и кол-во сси в кадре строго регламентировано.
Выяснил, что имеющаяся EPM3064 очень маловместительна (она на плате устройства, на ней ещё и АТмега есть).
А нужно 128КБ только на рабочую область и плюс бордюр, получается, что в ПЛИС нужно втолкнуть чуть меньше 200КБ памяти.
Цифровать видеовыход Вектора не обязательно, можно взять байт RGB до резисторов смесителя. Мне ведь не массовое производство налаживать...
Конечно проще взять сразу цифру. Тем более, что видео синхросмесь в Векторе все равно безнадежная.
А как получились 200кБ памяти?
...
А как получились 200кБ памяти?
Сейчас точно не помню количество строк в кадре у Вектора. Но это 256 плюс бордюр, чуть больше 300.
Количество точек по горизонтали сразу постоянно выводить 512 + бордюр это около 600 (чуть больше).
RGB 8Бит.
Получается минимум 180КБ. Чуток накинул...
Понятно. А как все-таки отличаются параметры развертки у рамки? Если кадровая частота не совпадает, то нужно делать конверсию. Например, если у нас 50, а там 60, надо пять кадров выдать как есть и шестой повторить. Или будет как-то рваться буфер. В принципе ничего страшного нет в том, чтобы рвать буфер, учитывая обстоятельства.
У Вектора 312 строк в каждом полукадре. В стандарте 312.5: у него кадр на одну строку хромает, как у всех. В одной строке 192 такта процессора на 3 МГц, что соответствует стандартной строчной 15625 Гц. Строки я бы цифровал целиком вместе с обратным ходом, так проще все рассчитывать и потом манипулировать. Получится 768 точек в строке (12e6/15625 = 768).
312*768 = 239616 на полукадр целиком без купюр.
Фоторамка 800х600 точек, на счет синхронизации выхода Вектора и инфы для рамки не задумывался. Поскольку нужно формировать другой по размерам кадр, и повторять для рамки одну строку два раза вподряд.
Частота кадров рамки позволяет вольность, можно и 50 кадров.
По вертикали получится немного потери бордюра Вектора, а по горизонтали нужно будет добавлять "пустоты".
К сожалению, скорее всего может получится квадратное изображение, а не соотношение 3:4 как привычное изображение экрана Вектора.
Но как ни как цветное...
- - - Добавлено - - -
Хм, конкретные цифры частот, наглядно наводят на мысль, что в ПЛИС можно запоминать только две строки Вектора. И синхронизировать кадры. Пока Вектор выводит одну строку, за это время ПЛИС может загонять в рамку две (одинаковые) предыдущих строки Вектора.
Главное что-бы ПЛИС справился с частотами...
А это уже не 200КБ а всего менее 800 Байт...
Да, примерно так делает vector06cc чтобы выводить картинку на VGA. Но ему внутри себя просто, потому что он весь плисный.
По горизонтали можно растянуть в 1.5 раза и даже останется чуть чуть на бордюр. Конечно удвоенные через две точки смотрятся буэ когда об этом знаешь, но если об этом не думать и смотреть издалека, то ничего страшного. На плисине потолще или микроконтроллере можно было бы сделать линейную фильтрацию.
/me поглядывает в сторону tnt23, который был замечен за обладанием одновременно маленьким LCD экраном в совокупности с каким-то stm32 и Вектором
С частотами она справится, но EPM3064 это же даже как бы не совсем FPGA, это CPLD.. Не уверен, что понимаю, как ее к этому делу прицепить. Я привык думать мазками пожирнее. И вообще я бы наверное посмотрел сначала не получится ли употребить в дело микроконтроллер, потому что они стали последнее время адски быстрые и мощные, а обращаться с ними можно в общем понаглее.
C Новым годом!
Всех с Наступившим!!!
Когда начинал писать про использование двух строк, думал реально за два буфера, один заполняется, другой выводится. Потом меняются местами.
А когда заканчивал писать сообщение, думал уже как синхронизировать запись с чтением и использовать один буфер. И написал что нужно 800 Байт (один буфер).
По идее если по векторовски (на грани фола), то можно и один буфер использовать. Т.К. скорость чтения в 2 раза выше скорости записи (нужно прочитать строку дважды, пока Вектор запишет одну), то читать можно начинать когда Вектор заполнил половину буфера. К концу записи буфера он будет считан один раз полностью. Если сразу начать считывать буфер второй раз, то считывание закончится когда Вектор заполнит половину буфера следующей строкой. Ну и по кругу...
По Поводу EPM3064, я ведь говорю, совсем не сталкивался с ПЛИС, не имею представления, о них. Вот попалась плата, на ней, что-то ALTERA, думал что-то "вкусное".
По поводу использования процессора для перекодировки... На макетке ARM, но при частотах 60МГц, удаётся осмысленно читать порт на частоте только 1МГц, а это в 6 раз медленнее, чем нужно только читать, а ещё нужно обработать и выводить. Тут другой проц нужен.
Буду таки подумать дальше...
LeoN65816
01.01.2018, 13:17
С Новым Годом, комрады!
Позвольте подкинуть идейку по поводу формата выхода на VGA с сохранением пропорции 4:3 - http://zx-pk.ru/threads/26944-mechta-agat-na-plis.html?p=906882&viewfull=1#post906882
При 256х256 каждую точку по горизонтали выводим 4 раза, по вертикали 3 раза (при 512х256 - 2 и 3) - получаем Aspect Ratio 4:3 результирующих 1024x768. В моем проекте за счет уменьшенного в 2 раза PixelClock, соответственно, и по горизонтали в 2 раза меньше масштабирование.
312 строк полного растра Вектора (телевизионный стандарт) преобразуем (утроением) в 936 полных строк (заднее гашение x3 + верхний бордюр x3 + 256 полезных x3 + нижний бордюр x3 + переднее гашение x3 + ССИ x3) выхлопа на VGA.
NEC Multisync мониторы прекрасно "проглотят" это, и даже 50 Гц кадровой.
60МГц это немного. STM32F405 бывают до 168, удобно будет завести его на 120 - 10х пиксельклок. Это Cortex-M4, у него нету полноценного NEON, но есть FPU и какое-то подмножество SIMD инструкций, которые наверняка можно употребить для линейной фильтрации. Уж удвоить каждый третий пиксель он точно справится.
Чтобы цифровать видео с пиксельклоком 12 МГц достаточно иметь микроконтроллер с периферийным клоком 12МГц. Например, настраивается канал DMA на копирование из порта в память и автоматической перезагрузкой процесса. Примерно так же будет устроено и выдавливание данных наружу. Использование DMA обеспечивает регулярность процесса. Если бы не растягивание по горизонтали, можно было бы настроить все периферийные устройства так, что процессору буквально нечем было б заняться.
Если на плате уже стоит какой-то ARM, есть шанс, что ему можно настроить PLL на 48 МГц, это даст кратную частоту. Вопрос в том, насколько гибкая у него периферия и сколько палок в колеса вставит имеющаяся на плате разводка.
Независимо от выбранной элементной базы, писать и читать одновременно один и тот же буфер я бы все же не советовал. По крайней мере начинать с этого точно не стоит.
- - - Добавлено - - -
Линейная фильтрация будет что-то типа:
out_pixel[x] = (in_pixel[0.66 * x - 1] + 2 * in_pixel[0.66 * x] + in_pixel[0.66 * x + 1]) / 4
Про фильтрацию это я прогнал, это бы пригодилось может быть в другой какой ситуации, но не в этой.
Попробовал смоделировать масштабирование разными способами. Исходные картинки брал из своего эмулятора.
http://sensi.org/~svo/image-scaling/
Nearest:
out_pixel[x] = in_pixel[floor(x * scale + 0.5)]
Linear:
mix(x,y,a): return x * (1 - a) + y * a
x1 = floor(x * scale)
a = x * scale - floor(x*scale)
out_pixel[x] = mix(in_pixel[x1], in_pixel[x1+1], a)
LeoN65816
02.01.2018, 11:41
Уважаемый Вячеслав.
Бесспорно, ты - авторитет в вопросах Вектора, FPGA и т.д. Однако, позволь немного советов/подсказок/"мыслей вслух":
1. Масштабирование/интерполяция микроконтроллером требует охрененной вычмощности. Чтобы рассчитать характеристики каждого пиксела нужно произвести кучу вычислений по значениям соседних пикселов, причем алгоритм этих рассчетов - последовательный (все пикселы экрана друг за дружкой последовательно - это разумеется, но именно по каждому пикселу нужно последовательно обработать значения соседних пикселов [причем не только предыдущего, но и следующего за текущим, и, по-хорошему, еще и сверху и снизу...]). И все это надо делать с темпом, как минимум, пиксельрэйта выхлопа на VGA. Я сомневаюсь, что даже какой-нибудь навороченный ARM на это способен... Да, можно это возложить на FPGA, но повторюсь, алгоритм-то последовательный, что плохо "укладывается" в FPGA...
2. Интерполяция (нецелочисленное масштабирование) вносит искажения по определению, и глаз это очень хорошо замечает, и это очень быстро доставляет дискомфорт...
3. А вот целочисленное масштабирование как раз и не вносит искажений, и в FPGA прекрасно "укладывается".
4. По Вектору уже показывал: родные Векторовские (с соотношением 4:3) 256х256 с коэффициентами 4:3 (или 512х256 с кэффициентами 2:3) тянем до 1024х768 (сохраняя Aspect Ratio 4:3). Раз для Вектора важен бордюр, то добавляем его и получаем 1280х1024 - на мониторах 17" и 19" (5:4, 1280x1024) получаем идеальное изображение!
Отдельный "подводный камушек" - это частота кадровой... NEC Multisync LCD2080UX+ прекрасно "хавает" 50 Гц кадровой. У многих ViewSonic-ов также заявлен нижний предел кадровой от 50 Гц. И у некоторых SONY.
Что скажете?
PS. Еще взгляните сюда - http://zx-pk.com/forum/viewtopic.php?f=7&t=8907&sid=8a81d75506f7f70f24c0be13dcadffd0
PPS. Форум для того и служит, чтобы обмениваться/делиться мнениями и идеями.
родные Векторовские (с соотношением 4:3) 256х256
Это спорно. Все же для бытовых ПК, у которых изображение не растягивалось на весь экран, более важен пиксельклок, чем соотношение сторон монитора или ТВ.
Если верить этому (http://codebase64.org/doku.php?id=base:pixel_aspect_ratio) источнику, у всех клонов вектора (кроме кристы-2) ширина точки в 7.375/6=14.75/12=1.2292 раз шире квадратной. Т.е. это фактическое соотношение сторон и 1.2292 < 4/3=1.3333.
Убрал злостный оффтоп, про aspect ratio оставил, хотя от учета соотношения сторон в случае нехватки вычислительных ресурсов можно легко отказаться.
Я никогда не обсуждаю свои собственные проекты на страницах этого форума до того, как они мне надоели и я не хочу больше ими заниматься. Причина этому: всегда найдется кто-нибудь, кто докажет мне, что это а) уже сделано б) невозможно сделать в) только дураки такое делают.
LeoN65816, 256x256 и 512x256 это только растровые части экрана. Мой размер 588х288 — это растр + респектабельная часть бордюра без которого Векторовская неполноценна.
То, что я привел, это просто моделирование. Прикидка как оно выглядит. Можно взять и поменять параметры, подсунуть картинку другого размера, можно добавить другой алгоритм и посмотреть как оно будет —*это бесплатно пока не в железе. При определенном подборе размеров, для частного случая формулу можно аппроксимировать изменением шага. Например, взяли по горизонтали 533 точки и растягиваем их на 800, получается масштаб 1.5. Вместо умножения на 1.5 мы просто пропускаем 1 шаг через два когда считаем входную координату. Но формула-то остается той же самой, это то же самое масштабирование выбором ближайшего пикселя. Никаких бешеных вычислительных мощностей тут не требуется.
Интерполяция так же оптимизируется для частных случаев. Справится ARM или нет вопрос десятый, полезно знать как это выглядит и иметь код, на основе которого можно начинать делать приближенную версию для частного случая. На мой взгляд, например, это выглядит принципиально лучше, чем без интерполяции. Почему раскормленному ARM-у не справиться с этим, не сделав я тоже сказать не могу, вычисления не невесть какие, делений нет. Не на 60 МГц, конечно! Но если на FPGA, так только лучше, они для этого предназначены.
Если сделать по-вашему, то все эти процессы будут происходить внутри монитора. Результат все равно будет интерполированым. Монитор внутри себя упихает эти 1024, 1152 или сколько получится точек в 800.Хороший монитор будет наверное уметь интерполировать хорошо. Про фоторамку у меня есть сомнения.
Я понимаю, что у вас уже есть готовое решение, но мы-то тут фантазируем на тему того, что KTSerg хочет сделать. 50 Гц она умеет, это мы уже знаем.
Блин я поражаюсь...
У меня не получается из Cortex-ов выдавить поток для формирования картинки, а тут наткнулся (цитата):
"...Современный, компактный вариант легендарного ZX Spectrum на базе AVR. ..."
http://good-kits.ru/nabory-bloki-i-moduli/zx-spectrum/radiokonstruktor-avr-zx-spectrum-v2/
это не реклама, просто если бы они написали "на базе Altera" я бы понял... а тут на базе AVR...
чё там AVR забыла, SD-карту читает?
чё там AVR забыла, SD-карту читает?
В свободное от карты время ещё эмулирует Z80 и всю периферию. Это же http://zx-pk.ru/threads/13747-zx-spectrum-apparatnaya-realizatsiya-na-vosmi-mikroskhemakh.html
Ну как же, это наш Lisitsin наверняка?
http://zx-pk.ru/threads/19442-polnyj-proekt-avr-zx-spectrum-s-iskhodnikami.html
- - - Добавлено - - -
Eltaron, хехе.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot