Дисплей с мультиками.

[Первопечатник]

Ты собрался делать видеокарту сам, что безумие. Давай не будем ходить кругами.

@rkit, ну вообщето это никакое не безумие! ) Там ничего сложного и невозможного нет. STM32H747 (STM32F746 и многие другие) имеет на борту аппаратную видеокарту, так сказать и может выводить картинку на дисплей размером до 1280х720 пикс. Серьезно, без шуток! Это вполне себе большой дисплей. И даже более того, я это делал сам. Ничего сложного! Так что никакое это не безумие.
Вот, тут дисплей 800х480 на STM32H747, и микроконтроллер прекрасно справляется с ним без всяких внешних видеокарт:

@Первопечатник, Я ж ещё раз говорю, Z80 справлялся с обновлением видеопамяти за приемлемое время.

А размер этой видеопамяти? 640х480, 8 бит цвет? А теперь представьте, что картинка 1280х720, 24 бита цвет. Разница ровно в 9 раз по объему на кадр. А теперь добавьте еще частоту обновления не ниже 60 Гц и добавьте еще необходимость не только передавать на выход, но и формировать картинку, а это совсем не быстрая задача. Декодирование сжатого видео - это весьма непросто для вычислений. Там матричные преобразования. Это не битмапы выводить построчно.

 

[Wan-Derer]

@poty, многоногие Атмеги позволяют подключить ОЗУ с параллельным интерфейсом. Память включается в общее адресное пространство ядра и со скоростью всё будет в порядке.
Дальше смотреть: использовать двухпортовую память чтобы видеоконтроллер мог читать её независимо, либо использовать линии управления чтобы делить доступ к памяти между ядром и видеоконтроллером.

 

[poty]

@Wan-Derer, я знаю про параллельный интерфейс, однако без hardware-поддержки это в принципе ничем не лучше последовательного: для адресации хотя бы 64кбайт необходимо выставить на параллельный интерфейс 16 бит адреса + 8/16 бит данных + 2 бита готовности read/write. Даже если эти данные готовы и лежат в ОЗУ МК, выполнение этих действий довольно затратная операция, я уже не говорю, что должно хватать времени и на подготовку этих данных и память должна из успевать принимать. Фактически, при передаче одновременно 16 бит данных и обеспечении хотя бы 10 кадров/сек (минимальная частота, при которой ещё можно говорить о видео), эти данные нужно передавать со скоростью 655кГц, и это только в одном направлении. Слегка смягчить пилюлю может внешний обработчик по типу DMA, но это по стоимости и сложности - совсем неэффективный вариант.

 

[Эдуард Анисимов]

@Первопечатник, А проект не сохранился на этом МК?

 

[Wan-Derer]

@poty, Я могу ошибаться, но вроде там память интегрируется "прозрачно", т.е. вся аппаратная поддержка уже есть в МК. Память просто в "встаёт" в адресное пространство МК и работа с ней происходит аналогично внутренней ОЗУ, т.е. никакие ноги вручную дёргать не надо. Другой вопрос как организовать чтение этой памят видеоконтроллером: сделать что-то вроде wait-циклов или использовать двухпортовую память.
По поводу сложности, ну, это зависит от подготовки исполнителя: кому-то сложно, кому-то не очень. Но на вопрос "можно ли на атмеге сделать комп а-ля 80-е" ответ "да, можно и каких-то принципиальных ограничений тут нет".

 

[poty]

@Wan-Derer, тогда нужно уточнить, что за "многоногие атмеги" имеются в виду?
И вопрос ветки - не в компьютере а-ля Z80, а в воспроизведении видео.

 

[i3epg]

@poty, атмега 2560 вполне подойдёт.
И не надо, точнее не обязательно, слать данные в эту память с дикой скоростью, потому-что как правило перерисовывают только часть экрана, где произошли изменения. А выводом на экран, где уже требуются много МГц занимается видеоконтроллер.
ЗЫ есть вообще вариант прицепить к тойже меге восьмибитную видеокарту, которая с isa слотом. И вот уже из меги получаем комп а-ля спектрум с много видеопамяти и выводом графики на vga монитор.

 

[poty]

@i3epg, тогда ещё раз: речь идёт не об отрисовке экрана в коде. Речь - о выводе видео на экран. МК не знает, что конкретно изменилось на экране, не имеет ресурсов для определения этого и вынужден заполнять память полностью.
И это мы ещё не говорили о звуке.

 

[i3epg]

@poty, так вы перечитайте, что я писал выше. “Мультики” (именно в кавычках, т.е. вывод изображения на экран, а не те mp4 файлы, пожатые каким нибудь h.264 кодеком) выводить на дисплей ардуиной можно и ничего в этом сложного нет. Двигать и менять спрайты в памяти хоть 328, хоть 2560 сможет без проблем, с этим справлялись и i8080 и z80 с меньшей производительностью на порядок. И звук кстати выводили. В виде полифонии, но тем не менее.

 

[poty]

@i3epg, ну, то есть по теме ветки - невозможно. Первоначальный вопрос в том и был, чтобы выводить видео, пусть и в плохом качестве. "Спрайты" здесь не помогут.
i8080 я программировал в своё время огромное количество и однозначно могу сказать, что самостоятельно они не могли выводить никакое видео, более-менее пригодное для просмотра, не говоря уже о звуке. Отрисовка из кода мелких объектов - да, но это не видео и не мультики.
Впрочем, со звуком - были эксперименты, но внешняя обвязка была если не больше системной платы тогдашних компов.

 

[i3epg]

@poty, я кодил на спектруме под z80 соответственно, в том числе и игры писал, но так, для себя. В продакшн ни одна не ушла. Сначала на дельте с 48Кб, потом разжился скорпионом с 256Кб не турбо, но с двумя дисководами.
Анимация ему вполне подвластна, при родном разрешении конечно. И параллельно звук выводить через ay8912 вроде. Посмотрите теже игры медноногова, cooperfeet который. Он игру написал чёрный ворон, по мотивам варкрафта2.
А уж на турбовом скорпе действительно было где разгуляться. У спекка вообще с анимацией были бОльшие проблемы из-за клэшинга, а не из-за недостатка производительности.

 

[Первопечатник]

А как связано декодирование видеофайла и спрайты от игрушек из 90-х?

 

[i3epg]

@Первопечатник, а какая разница конечному зрителю, как устроено оформление “мультика” внутри? Ему важно только лишь то, что видно на экране. Крутите зрителю хоть гифку, хоть спрайты, хоть кучу упорядоченных битмапов, для него это всё одно: “мультик”, анимация, фильм.
Вы просто сильно рьяно прицепились к декодированию мпегов, но на них свет клином не сошёлся и тоже хранение “мультиков” можно реализовать тысячей и ещё одной способами.

 

[Первопечатник]

Я просто исхожу из того, что было первоначально написано в первом мессаге этой темы. Автор подразумевал конечно же готовые видеофайлы с мультиками, скачанные из инета. Типа "Маша и медведь". Но вы ж не будете спрайтами рисовать этого медведя с Машей? )) А нарезать битмапами без сжатия хотябы 10-минутный мультик - это ж... 1280 пикс *720 пикс *3 байта *25 fps *60 с *10 мин = 38 ГигаБайт! ))) Вы верно очень сильно посмеяться решили.

 

[i3epg]

@Первопечатник, да уже всё равно, что написано в первом сообщении. Уже и ТС понял, что с дуней фильмы из интернетов не посмотреть, да и тема находится во флудилке, а не на бирже, либо в помощи.
Ну и собственно все мои посты подразумевают мультики не из интернета, закодированных всякими н264, а реализуемые посредством МК. Будь то раскадрованные БМПэшки или перемещаемые спрайты с гифками. ))

 

[PiratFox]

я кодил на спектруме под z80 соответственно, в том числе и игры писал, но так, для себя

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

 

[i3epg]

@PiratFox, ну так в институте то вряд ли спектрумы стояли, а на нём без ассемблера никуда. Да и не в ассемблере дело, больший гемор был отлаживать написанное, понять где именно косяк. С этим на скорпе было проще, с его теневым монитором. А на писюке я начал с борланд паскаля, затем Делфи. Вот там отладка на высоте, после Спектрума. Запуск по шагам, точки останова, значения переменных в реалтайме. Кайф, а не программирование.
ЗЫ первым писюком был 386й с 40Мб винтом. На нем был установлен Doom2TNT и паскаль, места больше ни под что не оставалось.

 

[kDn]

Запуск по шагам, точки останова, значения переменных в реалтайме. Кайф, а не программирование.

Для STM и ESP есть отладчики, может и под AVR что-то есть, я хз - не в курсе. По выводу на экран на примере синклера - надобно помнить, что этим вообще-то ULA занималась, которая суть та же ПЛИС вид сбоку. В текущих же реалиях имеет смысл использовать отдельные экраны с контроллерами заточенными под вывод изображения (ER-TFTM035-6 / ILI9488) либо аналоги. Они не супер-быстрые, особенно в SPI, но как бы лучше чем ничего.

 

[i3epg]

@kDn, я в курсе про ULA. И писал об этом. Это не ПЛИС, это БМК - базовый матричный кристалл, целиком и полностью изготавливаемый на заводе. С клиента только маска нужна. Эту БМК в первых советских клонах заменяла рассыпуха на логических элементах, потом рассыпуху стали менять на БМК Т34 и прочие.

 

[Эдуард Анисимов]

@kDn, AVR пошаговую отладку должен сейчас MPLABX поддерживать.
Но я не проверял.

 

[kDn]

@i3epg, вы реально считаете что ПЛИС не может заменить рассыпуху логики? Предлагаю подумать над фразой "те же яйцы, вид сбоку"

Так-то я вполне могу перевести Uncommited Logic Array как заготовку логического массива - будет ЗЛМ и ниипет. Но ПЛИС понятна всем и каждому, а БМК у меня только с ДВК ассоциируется, да и то по созвучию. Может про ЕС, СМ поговорим, что там нового в мейнфреймостроении, ы?

Ладно, шучу, мне не интересно вспоминать прошлую жизнь.

 

[Первопечатник]

Вообще-то, на ПЛИСах (FPGA) делаются правоверные осциллографы. И я не очень представляю размер вот такого осцилла на логике рассыпухой