Просмотр полной версии : Апогей - воспроизведение видео
hitomi2500
07.10.2018, 17:16
Всем добрый день.
----------
Последние рабочие сборки:
Исходники кодера и декодера (плеера): https://github.com/hitomi2500/avi2pseudo
Сборка кодера с видеофайлами : https://yadi.sk/d/n4C5_N8vzHGMnA
Как это выглядит:
Видео 1:https://www.youtube.com/watch?v=jTkKTztZx_I
Видео 2:https://www.youtube.com/watch?v=CLyV-c9ORko
Видео 3: (со знакогенератором РК) https://www.youtube.com/watch?v=qH7zHXyE41g
----------
Вздумалось мне попробовать прикрутить к Апогею видеоплеер. В качестве носителя выбрана карта через SD-интерфейс Алексея Морозова (vinxru), потому как альтернатив попросту нет (либо я про них не знаю). Конвертер набросан на коленке в Qt, он формирует полные видеобуферы и записывает их в файл подряд, а программа на КР580 попросту копирует сразу в видеопамять. Используется штатный режим Алексея 3A с разрешением 75(64)х51, с дополнительным апогеевским знакогенератором получается 192х102. Размер видеобуфера 3840 байт. Для отображения "обычного" видео разрешения конечно маловато, но специфическое видео с малым количеством деталей и/или с силуэтами выглядит нормально.
https://www.youtube.com/watch?v=vIcsYGBrFI4
Основной проблемой, как и ожидалось, оказалась производительность. Скорость следования кадров порядка 1.5 Гц, т.е. средняя скорость приёма данных порядка 6 килобайт в секунду. Судя по моему беглому анализу кода, биос Алексея использует какие-то хендшейки с микроконтроллером. Для сравнения, скорость работы мониторовской "R" около 9 килобайт в секунду, в целом немногим больше.
Вопрос в том, есть ли какие-то пути оптимизации.
Судя по исходникам "R", она выставляет адрес, теоретически на этом можно сэкономить, но немного. Также можно многократно продублировать группу команд чтение порта - запись в память - инкремент, на этом можно ещё сэкономить. Возможно при этом рассинхронизируется микроконтроллер, пока непонятно.
Может кто-нибудь сталкивался с задачей ускорения ввода в Апогей или другую машину из семейства?
программа на КР580 попросту копирует сразу в видеопамять
При воспроизведении видео давно уже используется разница с предыдущим кадром. Ключевые кадры (полные) записываются, когда изменений много. Я думаю, тут можно раз в 10 ускорить, не меняя SD-интерфейс.
hitomi2500
08.10.2018, 10:51
При воспроизведении видео давно уже используется разница с предыдущим кадром. Ключевые кадры (полные) записываются, когда изменений много. Я думаю, тут можно раз в 10 ускорить, не меняя SD-интерфейс.
Про ключевые кадры я как-то даже не подумал, спасибо. Конечно на ключевых кадрах будет тормозить, но если сделать буферизацию, то есть шансы выйти на более-менее равномерный поток.
Вопрос только в том, как кодировать дельту. Решения от взрослых кодеков не подойдут, каждый такт на счету. Первое что мне приходит в голову это проверять дельту по строкам и по столбцам, и передавать только нужные строки/столбцы с битовой картой, для столбцов это всего 8 байт, для строк 7. Надо будет попробовать.
Вопрос только в том, как кодировать дельту.
Самое простое - смещение,длина,данные. Полный кадр также укладывается в эту схему. Можно ещё точное время (timestamp) указать. Время можно синхронизировать с одним из каналов таймера (если запрограммировать на режим делитель частоты, а частоту самую низкую выбрать, думаю слышно не будет).
hitomi2500
08.10.2018, 13:26
Самое простое - смещение,длина,данные. .
Это будет хорошо работать при относительно малом числе изменений, но если их много, и они по 1-2 символа, на обрамление больше уйдёт, чем на данные. Хотя вариант со строками не лучше себя поведёт. Думаю что все указанные подходы можно объединить, и при кодировании совмещать их так, чтобы получить минимальный размер кадра (и неплохо бы ещё оптимизацию по тактам КР580 сделать, если получится).
Время можно синхронизировать с одним из каналов таймера (если запрограммировать на режим делитель частоты, а частоту самую низкую выбрать, думаю слышно не будет).
За идею спасибо, если получится поток разогнать до приемлемого, видимо так и сделаю.
Самое простое - смещение,длина,данные.
Если всего два цвета, то достаточно смещения и длины.
Если всего два цвета, то достаточно смещения и длины.
Вряд ли целесообразно заморачиваться побитными изменениями, а на уровне байтов данные все же нужны.
если их много, и они по 1-2 символа, на обрамление больше уйдёт, чем на данные
А как тебе такой вариант для дельты:
- перед каждой группой теоретически изменённых 512 байт идёт один байт, показывающий, было ли изменение в подгруппе из 64 байт (т.е. один байт на 512 байт данных)
- если изменений в подгруппе нет, то её и в потоке нет, а если есть, то перед подгруппой опять байт, показывающий, было ли изменение в подподгруппе из 8 байт (один байт на 64 байта данных), ну и наконец перед самими байтами данных (один байт на 8 байт данных)
То есть такая 3х уровневая битовая карта наличия данных. Ключевой кадр, конечно же, без карты, только данные. Можно ограничиться 2х уровневой картой для дельты, но тогда на весь кадр будет минимум 60 байт, даже если ничего не изменилось, а с 3х уровневой всего 8.
- - - Добавлено - - -
Блин, сейчас прикинул, вертикальная линия - полторы сотни байт. Но зато она может быть кривая-косая-шершавая :) На 50 изменённых в произвольном месте байт - по-моему меньше по любому не будет.
- - - Добавлено - - -
Кстати, плюс этого метода ещё в том, что можно поделить видео на чётные и нечётные кадры, и формировать поток отдельно для чётных и нечётных кадров. "Битрейт" упадёт в 2 раза.
- - - Добавлено - - -
Не то хотел сказать: для чётных и нечётных байт!
- - - Добавлено - - -
Вобщем в чётном кадре чётные байты, и наоборот. Тогда и служебных байт будет в 2 раза меньше.
hitomi2500
08.10.2018, 16:19
Если всего два цвета, то достаточно смещения и длины.
Даже если исходное видео было бы оптимизировано под такой подход, для трансформации в псевдографику пришлось бы сильно напрягать КР580.
- перед каждой группой теоретически изменённых 512 байт идёт один байт, показывающий, было ли изменение в подгруппе из 64 байт...
Бинарное дерево это дельная мысль. Оптимальней конечно бы разбить кадр на двумерные кусочки, но сколько это сожрёт на декодировании боюсь представить. Проще работать с одномерным представлением.
Кстати, плюс этого метода ещё в том, что можно поделить видео на чётные и нечётные кадры, и формировать поток отдельно для чётных и нечётных кадров. "Битрейт" упадёт в 2 раза.
А интерлейсинг это ещё более дельная мысль. Правда артефакты будут видны, минимальный блок всё-таки 3х2, но экономия налицо. Опять же, на стадии упаковки можно задать порог, и если артефакты интерлейсинга сильно выпирают, давать прогрессивный кадр.
Ещё около 15% можно (и нужно) сэкономить на бордерах, которые пока для простоты были встроены в поток.
Может получиться весьма неплохое ускорение, если всё посчитать. Вечером доберусь до железа, поэкспериментирую.
hitomi2500
08.10.2018, 20:20
Ради статистики решил проверить размер дельты в Bad Apple (видео так называется), средняя дельта равна примерно половине кадра (1964 байта), если считать по псевдографике. Это многовато, особенно учитывая что на представление такой большой дельты уйдёт ещё куча обрамления. Видимо на предобработке надо добавить какие-то пространственные и временные сглаживающие фильтры, чтобы сузить спектр сигнала, тогда потеряются мелкие детали, но дельта должна сильно уменьшиться.
66519
средняя дельта равна примерно половине кадра
Мда... Тогда остаётся только упаковка, раз уж у нас узкое место - SD-карта. Распаковщик MegaLZ для КР580 я писал, где-то тут выкладывал. Будем надеяться, выигрыш от уменьшения считываемого объёма будет больше, чем проигрыш от алгоритма распаковки.
hitomi2500
09.10.2018, 06:49
Мда... Тогда остаётся только упаковка, раз уж у нас узкое место - SD-карта. Распаковщик MegaLZ для КР580 я писал, где-то тут выкладывал. Будем надеяться, выигрыш от уменьшения считываемого объёма будет больше, чем проигрыш от алгоритма распаковки.
Увы, нет. Этот распаковщик я проверял, именно для декомпрессии изображений, и там всё сильно хуже, распаковка одной картинки идёт единицы секунд. Картинки правда были пошумнее, чем текущее видео, но погоды это не сделает. Я всё-таки попробую поколдовать с исходником и порезать дельту насколько получится.
Вчера времени хватило только убрать бордер из потока. Долго не мог понять что не так, оказывается обращение к SD биосу портит не только BC, но и DE. Без бордера замерил скорость - ровно 1.5 Гц, но при этом я запрашиваю у биоса по 64 байта, из-за этого поток мог слегка упасть. Надо будет глянуть на логическом анализаторе, как ведёт себя шина при разных размерах блока.
6Кб в секунду это почти 300 тактов на байт. Не многовато? Может как-то в обход биоса читать байты из контроллера? Если биос ждёт готовности от контроллера, может быть можно использовать это время для алгоритма распаковки.
А вообще, есть другой интерфейс от HardWareMan-а на основе сдвигового регистра и счётчика бит, он раз в 5 быстрее может работать. С файловой системой придётся самому разбираться, но и это не проблема. Я писал читалку для SD-карт, а PVV успешно её дорабатывает.
hitomi2500
09.10.2018, 10:55
Я всех обманул! У меня неправильно считалась дельта! Средняя получается около 300 с размыванием и 230 если использовать тупой порог. С более серьёзной фильтрацией думаю можно уйти ниже 200.
66524
Так что хоронить SD пока рано, может я всё-таки в него впишусь.
И сколько кадров в секунду будет?
hitomi2500
09.10.2018, 16:13
И сколько кадров в секунду будет?
Всё зависит от того, насколько хорошо получится упаковать дельту, и сколько времени уйдёт на её декодирование на КР580. Если оценивать грубо, предположим дельта с упаковкой будет в среднем 500 байт, и распаковка дельты займёт столько же, сколько её получение. Тогда скорость будет примерно 5 кадров в секунду. Если добавить интерлейс, то 10 кадров. Но по факту может получиться как в 3 раза быстрее, так и медленнее.
hitomi2500
09.10.2018, 23:43
Нет, всё-таки никого я не обманул, а вернее обманул дважды. Сел писать бинарные деревья, оказалось что в моём подсчёте дельты куда больше чем одна ошибка. Среднее значение для дельты пока получается 1400 байт (1350 с порогом), а размер с бинарным деревом вообще швах - 2290 байт в среднем. Прости-прощай 5 герц, 3 бы выжать с таким раскладом. Только прежде чем делать выводы я сначала реконструирую изображение по дельте (и отдельно по дереву) на большой машине, а то вдруг ещё ошибки найдутся.
Прицепил ЛА к случайным ногам, видно что у контроллера есть какой-то период "раскачки", видимо когда он читает с SD, а потом он шлёт всю пачку то ли на неравномерной частоте, то ли с паузами. Минимальный период порядка 20 мкс, но 64 байта передаются явно больше чем за положенные 1.3мс. Вечером копну детальнее.
hitomi2500
11.10.2018, 00:05
Покрутил ещё немного ЛА. Команда R перебирает адреса в портах B и C, время загрузки одного байта - 73.2 мкс (122 такта), но периодически врывается ВТ57 и всё затягивает на 30-250мкс, среднее
время получается примерно 100 мкс (167 условных тактов), скорость приёма - 10000 байт/с.
У Алексея (vinxru) нашёл в биосе расчёты, он насчитал 54 такта (может мкс?) на байт. Мои замеры показывают 52.9 мкс в пике, но пики чередуются с пустотами. Иногда пробегают пачки стробов по 70-80 байт за 4 мс,
то есть на максимальной скорости, а иногда тишина по 700-800 мкс.
Если запрашивать у биоса по 64 байта, период равен 12-15мс, примерно четверть времени шина "живёт" на максимальной скорости, а остальное время обмен не такой интенсивный. При этом по моей оценке сквозь шину проходит примерно 200-250 байт. И если среди 70 байт быстрого режима лишние можно отнести к прогрузке конвейера, то остальное - это видимо хэндшейки, синхронизация и статусы. Пиковая скорость получается 18900 байт/с, а реальная - примерно в 4 раза меньше, 4300-5300 байт/с.
Ради интереса увеличил запрашиваемый у биоса блок до 4096, он считывается за 360-400 мс, т.е скорость возросла до 10200-11400 байт/с. Но столько времени тратить на чтение уже нельзя - 400 мс это уже 2.5 Гц, в ещё надо успеть кадр нарисовать. Если оставлять текущее SD решение, то блоки надо уменьшать до 1500-2000 байт, где-то там оптимум. Если не оставлять, а поставить снаружи микроконтроллер или ПЛИС с предвыборкой и большим SRAM, можно разгоняться минимум до 18900, а то и выше.
До деревьев я сегодня не дошёл :(
hitomi2500
12.10.2018, 13:27
Так оно и оказалось, пока результаты реконструкции на экране не появились, все ошибки устранить не получилось. Дельта оказалась меньше, чем у меня получалось, средняя около 200 байт, но бинарное дерево пакует её слишком уж неоптимально, без малого в килобайт. В любом случае это уже неплохо, но я ещё не замерял производительность её распаковки. Если там сюрпризов не будет, даже с таким жирным деревом герц на 8 есть шансы выйти.
Возможно следует нижний квант дерева сделать не 8 байт (24х2), а 4 байта (12х2), а то много лишнего лезет.
На картинке зелёным - дельта, красным - дерево.
https://image.ibb.co/nF55M9/deltas2.png (https://imgbb.com/)
Возможно следует нижний квант дерева сделать не 8 байт (24х2), а 4 байта (12х2), а то много лишнего лезет.
Э.. у тебя минимальный блок 8 байт что-ли? Я-то думал вообще на каждый байт по биту в дереве предусмотреть.
hitomi2500
14.10.2018, 14:22
Э.. у тебя минимальный блок 8 байт что-ли? Я-то думал вообще на каждый байт по биту в дереве предусмотреть.
Каюсь, погорячился. Действительно дерево с минимальным блоком в байт работает лучше всего, менее 400 байт на кадр в среднем получается. Мне почему-то казалось, что деревья с большими размерами блоков будут быстрее декодироваться, но видимо это не так.
https://preview.ibb.co/jtfejU/image.png (https://ibb.co/gZmKjU)
hitomi2500
17.10.2018, 23:46
Лучше! Заметно лучше. Ещё дёргано и медленно, но уже смотрится как видео, а не как слайдшоу. Дешифровщик отлаживал на эмуляторе с одним кадром, а вот буферизацию пришлось писать вслепую. Заработало с первого раза, но в конце буфера в 16К виснет, какие-то условия перехлёста с ошибками написаны. Скорость кадров пока не измерял, на вид около 4. Интерлейса тоже пока нет, он по идее может ещё раза в 2 разогнать в ущерб картинке. Ассемблерный код написан тоже абы как, может оптимизация ещё немного даст скорости.
Видео : https://youtu.be/PMeIMVL_Vw4
Вопрос к b2m, твой эмулятор поддерживает эмуляцию SD-карты? Я в общем-то и вслепую добью, но на эмуляторе было бы в разы проще.
Твой вариант (с контроллером от vinxru/alemorf) нет, а простые варианты (типа nv8em) - да.
hitomi2500
21.10.2018, 01:03
Короче программист под КР580 из меня никакой. Кое-как склепал декодер, видео Bad Apple он воспроизводит до конца, а вот на втором видео грохается посередине, пока не разобрался почему. Если кому интересно посмотреть, исходники и сборку декодера, а также видеофайлы прикреплю к сообщению. На эмуляторе b2m интерфейс SD от vinxru не работает, на остальных видимо тоже, так что пока только реал. Имя файла пока задаётся жёстко в исходнике, в данном случае это "VIDEO\APPLE.APV"
Видео 1:https://www.youtube.com/watch?v=jTkKTztZx_I
Видео 2: (падает на 3-й минуте) https://www.youtube.com/watch?v=CLyV-c9ORko
Декодер с исходниками: 66616
Видеофайлы: https://yadi.sk/d/bbc42Q-FPQ2J0Q
Кодировщик видео написан на Qt, выложу его позже, там вечная головная боль с библиотеками.
На эмуляторе b2m интерфейс SD от vinxru не работает, на остальных видимо тоже, так что пока только реал.
В эмулятор Pyk-а можно и самому встроить ;)
https://github.com/vpyk/emu80v4
В моем эмуляторе SD от vinxru есть :)
В эмулятор Pyk-а можно и самому встроить ;)
https://github.com/vpyk/emu80v4
Более того, я уже начинал делать поддержку этого контроллера, но до конца так и не довел, переключился на другое.
Могу вернуться к нему и доделать, раз уж стало актуально.
hitomi2500
21.10.2018, 20:31
В эмулятор Pyk-а можно и самому встроить ;)
https://github.com/vpyk/emu80v4
Я подумаю, спасибо. Я не очень-то пока представляю протокол интерфейса, просто использую функции SD-биоса. Чтобы добавить его поддержку, нужно и в эмуляторе разобраться, и в коде для микроконтроллера.
Красота!
Спасибо :) Теперь в играх для Апогея можно делать видео-заставки.
В моем эмуляторе SD от vinxru есть :)
Это здорово. У меня правда нет машины с OSX, поэтому проверить, заработает ли декодер на нём, я не могу.
Выкладываю текущий вариант кодера, на случай если кого-то появилось желание поконвертировать видео.
Сборка : https://yadi.sk/d/SHjlf2r0JUPftg
Если будет ругаться на отсутствующие библиотеки или файлы платформы, скажите, попробую починить. Вроде проверил все зависимости, но с Qt никогда нельзя быть уверенным.
Исходники : https://yadi.sk/d/_cx3VpQVv6739Q
Если захотите собрать кодер из исходников, вам ещё понадобится девелоперская сборка библиотек ffmpeg для вашей архитектуры. И скорее всего придётся обновить заголовки ffmpeg в проекте, а заодно поменять пару вызовов функций, которые устарели в ffmpeg за последний месяц.
Если будет ругаться на отсутствующие библиотеки или файлы платформы, скажите, попробую починить.
plugins/platmorms/qtwindows.dll как минимум не хватает
У меня Qt 5.11 нет под рукой, проверить не смог.
- - - Добавлено - - -
Запустился. Нужно создать директорию platforms и положить туда qtwindows.dll от Qt 5.11.2:
http://rgho.st/8VtjQzxvm
hitomi2500
21.10.2018, 22:13
Запустился. Нужно создать директорию platforms и положить туда qtwindows.dll от Qt 5.11.2
Спасибо, добавил.
Ещё один нюанс с кодером - ему нужно видео в конверте avi с разрешением 192х102. Если будет больше - он симметрично обрежет края. Если меньше - наверное грохнется.
Вопрос к b2m, твой эмулятор поддерживает эмуляцию SD-карты?
Теперь - да! Реализовано, правда, не 100% протокола, но твою демку запустить уже можно.
Просто хотелось посмотреть в своём эмуляторе :)
b2m, оперативно :) А протокол там довольно мудреный, насколько я помню...
Более того, я уже начинал делать поддержку этого контроллера, но до конца так и не довел, переключился на другое.
Могу вернуться к нему и доделать, раз уж стало актуально.
Что ж, придется все-таки доделать - тоже видео посмотреть хочется ;)
hitomi2500
22.10.2018, 09:53
Ох как я всех резко сподвигнул интерфейс реализовывать:)
b2m, спасибо, шустро работает, вот бы так же быстро оно на реале крутилось :)
Pyk, насколько я понял, протокол эмулировать совсем не обязательно, достаточно перехватить единую точку входа SD bios, а там интерфейс простой - всё расписано в sdbios.asm в JmpTbl.
Вроде проверил все зависимости, но с Qt никогда нельзя быть уверенным
Если MinGW, то
objdump -p | grep -i dll
Если стоит студия, то (https://docs.microsoft.com/en-us/cpp/build/reference/dumpbin-options?view=vs-2017)
dumpbin /dependents program.exe
svofski, dll плагинов (в т. ч. тот самый пропущенный qtwindows.dll) Qt5 подгружает динамически, так что эти dll в данном случае не попадут в список...
hitomi2500
23.10.2018, 07:07
Надоело баловаться с архивами, положил кодер на github, туда же переедет скоро и декодер. Ссылка в стартовом сообщении.
Заодно сделал поддержку режима 128х60 с родным знакогенератором Радио-86РК, но пока не добавил её в декодер.
Оффтоп конечно, но я доделал эмуляцию протокола SD-контроллера Морозова. Файлы копируются, каталоги создаются/удаляются.
Мне вот интересно, редактор и просмотрщик файлов реально существуют, или он на будущее оставил? На гитхабе нету.
hitomi2500
25.10.2018, 10:13
Мне вот интересно, редактор и просмотрщик файлов реально существуют, или он на будущее оставил? На гитхабе нету.
Я упоминаний нигде не встречал. Думаю что оставил заглушки на будущее. А почему бы его самого не спросить? Он конечно в бане, но не все же мосты сожжены?
Я добавил к видео заголовок 256 байт, правда там пока всего 3 байта используется - число кадров и формат. Ещё добавил режим родного знакогенератора 86РК, плеер сейчас распознаёт формат автоматически, но фреймбуфферы у Алексея в нужных видеорежимах настраиваются слегка по-разному, поэтому пока плеер не умеет работать сразу с двумя форматами корректно. Но это временно. Кому не терпится - скачать РК-сборку плеера и видео можно тут : https://yadi.sk/d/2LIP2bp_y1Y71Q
Уточняю, речь идёт о воспроизведении видео на Апогее, но с родным знакогенератором РК. О запуске плеера на РК речи пока не идёт, нужно менять распределение памяти. И вообще, кто-нибудь цеплял интерфейс Морозова не к Апогею?
кто-нибудь цеплял интерфейс Морозова не к Апогею?
Как минимум, сам Морозов цеплял к Радио-86РК, раз уж у него на гитхабе есть реализация boot.rk,sdbois.rk и shell.rk для Радио-86РК. Чтобы подцепить интерфейс к другим компам, нужно дорабатывать эти три файла (как минимум адреса портов и экранной области). А для компов с нетекстовым экраном shell.rk нужно вообще заново писать...
hitomi2500
26.10.2018, 13:27
Ещё есть вариант для Специалиста, причём он судя по всему оригинальный, потому что в биосе для Апогея и РК в комментариях специалистовские адреса. Впрочем у меня вживую из этих машин только Апогей, и проверить работоспособность портированной версии я не смогу.
Ещё есть вариант для Специалиста, причём он судя по всему оригинальный, потому что в биосе для Апогея и РК в комментариях специалистовские адреса.
Я не нашёл намёка на Специалист в исходниках на гитхабе. Где брать этот вариант?
hitomi2500
26.10.2018, 19:30
Я не нашёл намёка на Специалист в исходниках на гитхабе. Где брать этот вариант?
https://github.com/alemorf/retro/tree/master/specialist-sd_controller
Просмотрел. Я думал у него про SD контроллер всё в одном месте, раз уж там и Апогей, и Радио-86РК.
Но это просто адаптированная версия, для какого компа было сначала - знает только Алексей :)
Походу действительно, для Специалиста была начальная версия. Протокол несколько отличается от Апогей/Радио-86РК, так что подключить не получилось. Другую (более ранюю) версию делать не буду.
Если кто-то будет делать железо, нужно иметь ввиду, что для Специалиста прошивка меги другая. Схему не смотрел, но полагаю она такая-же.
Для реализации в эмуляторе версия для Специалиста не сильно отличается. Насколько я помню все команды такие-же, только низкий уровень отличается.
hitomi2500
28.10.2018, 00:27
Я сделал в плеере поддержку режима РК, теперь он сам определяет какой ему попался видеофайл (по заголовку), и включает соответствующий режим. Запустил режим РК на реале - смотрится очень даже неплохо, по скорости сопоставимо с эмулятором, видео в стартовом посте есть.
Ещё научил плеер определять что он запущен не на Апогее, а на РК (по строчке с названием в биосе). Правда он ещё пока не перестраивает распределения памяти, и проверять пока не на чем.
Обещал еще недели 2 назад, но из-за занятости только сейчас добавил поддержку SD-карты в эмулятор, да и то пока в режиме read-only.
Исходники в репозитории, но полноценный релиз эмулятора пока сделать некогда, подготовил сборку специально для тестирования SD-контроллера:
http://emu80.org/v4beta/Emu80qt_40305_sd_test.7z
В сборке всего 2 платформы - Апогей и РК-86 с поддержкой SD. Также включено типовое содержимое SD-карты, последний avplay и apv-файлы.
Надеюсь, что в следующем релизе эмулятора SD уже будет "из коробки".
Я не особо вникал в исходники плеера, но на РК-86 avplay не работает, несмотря на то, что какой-то анализ типа компьютера там присутствует.
hitomi2500
05.11.2018, 01:26
Я не особо вникал в исходники плеера, но на РК-86 avplay не работает, несмотря на то, что какой-то анализ типа компьютера там присутствует.
И не должен пока работать. Потому что Апогей меня избаловал кучей свободной памяти, а на РК фифо придётся ужимать или передвигать, я ещё не решил. За неимением железа буду мучить ваш эмулятор.
За неимением железа буду мучить ваш эмулятор.
Ну или мой :) Я тоже добавил конфиг РК86 + SD на меге. Мне всё-же стало интересно реализовать протокол для Специалиста (для полной коллекции), поэтому описание протокола я вынес в конфиг. Пришлось изобретать псевдо-язык для описания машины состояний протокола. Зато теперь видны отличия в протоколах.
Решил подключить sd-card reader по схеме Алексея. Не тут то было, протестил интерфейс пользователя тестовой программой ПКР с родной кассеты, пишет ошибка. Что может быть? Все тесты эвм проходит, а этот не хочет. Заглушку с длинным номером вставил до пуска. ЭВМ под пломбами.
hitomi2500
07.11.2018, 15:03
Не тут то было, протестил интерфейс пользователя тестовой программой ПКР с родной кассеты, пишет ошибка. Что может быть?
Может у самой заглушки одна из перемычек отвалилась, или пайка холодная. Попробуйте все провода слегка подёргать на предмет надёжности контакта, а лучше тестером прозвонить. Вероятность того, что заржавел разъем или какая-то беда на плате мне кажется ниже.
И кстати до пуска - это как, вплотную, без щели? Разъём тугой был ещё в те года, а сейчас если окислился, и молотком не всегда забьешь.
У меня картридж отказался читать.
Вместо загрузчика выводит одно значение
http://img.radiokot.ru/files/30570/thumbnail/1qapbu8gpo.jpg (http://img.radiokot.ru/files/30570/medium/1qapbu8gpo.jpg)
Поэтому и полез дальше. Склоняюсь все таки вскрыть из под пломб.
Процессор считывает 82 если вообще никто не выбран (а шина данных не притянута куда-либо). Походу ВВ55 отсутствует :)
HardWareMan
07.11.2018, 18:32
Какую из?
Заменил вв55. Сейчас при считывании загрузчика. Одни нолики.
- - - Добавлено - - -
ПКР пишет ошибок нет!
- - - Добавлено - - -
Потом сделал как у него на видео. воткнул кард ридер на работающей эвм.
Кое что загрузилось но пока с ошибками, но некоторые коды совпадают и самое главное размер загрузчика
http://img.radiokot.ru/files/30570/thumbnail/1qg5t8yeju.jpg (http://img.radiokot.ru/files/30570/medium/1qg5t8yeju.jpg)
hitomi2500
08.11.2018, 17:24
Кое что загрузилось но пока с ошибками, но некоторые коды совпадают и самое главное размер загрузчика
Линия PC5 (нога Б6 на разъёме) то ли оторвана, то ли замкнута на соседа (скорее всего на PC4, нога A6).
Привет. А как ты ее вычислил? Я ее вчера тоже вычислил, но методом прозвонки, нога на меге отошла. Но все равно нолики загружались. Сегодня купил вторую флешку, с ней тоже нолики. Ну думаю пропаяю все ноги меги, если не пойдет возьму схему.
Но нет пошла!
http://img.radiokot.ru/files/30570/thumbnail/1qh5t2fb0p.jpg (http://img.radiokot.ru/files/30570/medium/1qh5t2fb0p.jpg)
Теперь расказывайте как видосы посмотреть на реале?
- - - Добавлено - - -
Все запустил видос! Крутяк!
hitomi2500
08.11.2018, 23:34
Ратмир, поздравляю! Ногу я вычислил просто, сравнил дамп с эмулятором, везде где были отличия, они были только в 5-м бите.
Я в очередной раз обновил avplay, теперь он работает на РК. Плеер сам определяет, на какой машине запущен (по фрагменту имени в биосе), и использует соответствующие адреса. Из машин пока поддерживается только 32К версия РК и Апогей. Видео с апогеевским "высоким" разрешением (192х104) запустится естественно только на апогее, впрочем проверки пока нет, и на РК плеер его тоже запустит, но ничего конструктивного на экране не ждите.
Воспроизведение на РК работает пока только на эмуляторе, если у кого есть или планируется РК с интерфейсом им. Морозова, не сочтите за труд проверить на реале.
Все ссылки как всегда в первом сообщении.
hitomi2500, обратил внимание, что картинка на экране сильно смещена влево, особенно в режиме РК. Чтобы центрировать видео на экране ТВ в соответствии с параметрами видеосигнала я бы изменил адреса начала экрана 76DA/E1DA на 76DE/E1DE, а C113 - на C115.
hitomi2500
09.11.2018, 23:33
Pyk, отцентрировал. Значения правда пришлось поставить ещё на 1 больше. Заодно исправил парсинг видео 192х102, который конечно же оказался сломан в процессе параметризации кода.
Проверил на Апогее, оба разрешения теперь с почти симетричными краями, плюс-минус знакоместо. На эмуляторе совсем ровно.
hitomi2500, да, отлично.
У вас Апогей как подключен к телевизору? Напрямую? Интересно было бы сравнить картинку на экране с эмулятором в плане смещения.
Попробую также прикинуть, каким теоретически должно быть значение aspect ratio для точки псевдографики двух режимов, чтобы изображение не было растянутым на реале. У меня эмулятор может это считать и учитывать, но пока только в расчете на ТВ 4:3.
hitomi2500
10.11.2018, 12:09
Pyk, у меня телевизор переходного поколения, уже цифровой, но ещё со скартом (Mystery MTV-2214LW). Он при смене видеорежимов как-то подстраивается под сигнал (картинка дёргается влево-вправо, потом выравнивается), поэтому думаю что его края не показательны. Но на всякий случай вот вам несколько примеров : https://yadi.sk/d/QKc2mXQ2pG_72A (на видео телефон пришлось опускать, иначе автовыравнивание яркости в камере всё затемняет, и краёв экрана не видно).
hitomi2500, спасибо, интересно было посмотреть. Картинка обрезана очень сильно, причем как сверху-снизу, так и с боков.
Похоже, телевизор просто берет 270 центральных строк растра и повторяет каждую 4 раза (270*4 = 1080). Соответственно, по горизонтали для соблюдения пропорций строки также подрезаются больше, чем того требует снандарт.
Посчитал также необходимое соотношение сторон исходной картинки для получения нерастянутой картинки в реале.
В зависимости от режима и наличия в ТВ подстройки частоты строк (в Апогее длительность строки чуть меньше номинальной) получились значения в диапазоне 1:1.424-1.473 для ТВ 4:3.
Можно наверное для простоты взять среднее значение 1,45.
А для ТВ 16:9 получится 1,45 * 4/3 = 1,93
Надо будет my_img = my_img_raw.copy(CropRect); заменить на scale, чтобы учитывался aspect ratio и вырезалась нужная область видео.
Хотел попробовать, но некогда уже, может быть завтра доберусь...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot