Воспроизведение озвученной анимации с ROM-Дисков

[shiny]

Предлагаемый Вашему вниманию проигрыватель позволяет воспроизводить звуковой видеоряд непосредственно с ROM-Диска по схеме Апогея с поддержкой до 256 страниц.

Качество воспроизведения примерно такое:


Перемотка клавишами организована крайне примитивно, так как фактически она не нужна.

На реале бы погонять эту демо

[Alikberov]

Может тогда пока откатить "презентацию", если там звук фейковый?

Нет - я не знал, что надо

И не надо!
Я могу оставить эти две строчки, но сделать их немыми:
Если мы сейчас формируем некий формат представления видеоряда под РК, важно не накосячить.
А я, похоже, накосячил с этими "caption"/"status"!

Их можно оставить, но выводить только по запросу - при старте и во время нажатия клавиш "перемотки".

Но всё равно оно же будет играться один раз на страницу - раз в секунду с хвостиком?
Тогда сложнее будет fps видео и samplerate звука считать - лучше бы пусть всё одинаково и равномерно...

Вот именно!
Я переработаю код.
(Придётся хорошенко покумекать.)

А ты длину пакета ПДП уменьшал? Можно попробовать без F1 сделать

да, нужно всё переделывать!

чтобы весь экран был - без дырок, но менять только средние 64x50 (кстати можно наверное предусмотреть режим когда у каждой строки вначале идёт адрес куда её писать - тогда можно частично меняющиеся кадры передавать меньшим количеством срок)...

И об этом думал. Передавать адрес строки - хардкор, но позволило бы имитировать компрессию.
Однако, проблемы с перемоткой возникнут и со звуком уже не так понятно. Это всё усложнит!

Но, пока мы обсуждаем лишь проигрывание потока на пределе возможностей РК. Оптимизация с компрессией - уже другое.

У меня возникла гениальная мысль! А что если не сдвигать символы туда-сюда для вытаскивания бита звука, а прямо как есть код символа сувать в #8002? т.е. младший бит кода символа будет задавать звук, что сэкономит аж 12 тактов на отсчёт!

Не поверите! Я тоже об этом думал.
Но это исказит частично картинку.
И усложнит код самого конвертора - нужно будет подбирать визуально схожие символы с чётными/нечётными кодами.

С другой стороны, эти 12 тактов можно будет использовать под ещё одну STA 8002h и улучшить качество звука!
(Просто мне любопытно также узнать, на сколько качественный звук можно извлечь!)
То есть, в принципе, можно в каждом символе кодировать звук, а в самом плеера добавить опцию с заданием шага вставки STA.

Вот примерно так можно сделать постпроцессинг с учётом бита звука S:

То есть, Вы уже нашли решение!
Тогда звук можно кодировать с максимальной дескретизацией в каждом байте, а на стороне плеера - уже выбирать качество.

Прежде всего, сейчас попробую заняться темой конверсии видео не через HTML5/JavaScript с захватом экрана (да, такой вот костыль!), а с ffmpeg и пайпом в Си или Питон (я ж под Raspberry Pi сижу - в TwisterOS).
А то, как "сапожник без сапог" сижу.

P.S.: Оказывается, вся работа над кодом ещё только началась!

[Shaos]

> И об этом думал. Передавать адрес строки - хардкор, но позволило бы имитировать компрессию.
> Однако, проблемы с перемоткой возникнут и со звуком уже не так понятно. Это всё усложнит!

Да вроде не усложнит - при перемотке всё также скачем по страницам и начинаем играть сначала страницы (можно сделать так, что первым кадром каждой страницы идёт "ключевой" кадр, в котором есть все строки от первой до последней) и со звуком тоже всё просто - звук пишется плавно и последовательно в те строки что идут в ромдиск, но это всё потом

> То есть, в принципе, можно в каждом символе кодировать звук, а в самом плеера добавить опцию с заданием шага вставки STA.

Я не хочу частить со звуком - во-первых это портит FPS, во-вторых некоторый пары (особенно яркие) будут искажаться в тёмную сторону - т.е. желательно иметь их реже, ну и в-третьих я тут позаписывал звук с эмулятора подавая прямоугольный сигнал с максимально возможной скоростью в вариантах звуковой отсчёт на пару и звуковой отсчёт на 4 символа - там где оно более высокочастотное, там оно сильнее искажается, а высокочастотные искажения это шум, поэтому я думаю надо ограничиться 7-8 кГц

> Прежде всего, сейчас попробую заняться темой конверсии видео не через HTML5/JavaScript с захватом экрана (да, такой вот костыль!), а с ffmpeg и пайпом в Си или Питон...

Я могу свой конвертер выложить, чтобы любой мог видосики сжимать
Ему надо скармливать последовательность PNG 128x50 в градациях серого без прозрачности
Как минимум будет от чего плясать

P.S. При переносе сообщений пришлось создать новую тему с другим номером - так что если где-то вовне давалась ссылка на топик, то её надо поменять...

[Alikberov]

> И об этом думал. Передавать адрес строки - хардкор, но позволило бы имитировать компрессию.
> Однако, проблемы с перемоткой возникнут и со звуком уже не так понятно. Это всё усложнит!

Да вроде не усложнит - при перемотке всё также скачем по страницам и начинаем играть сначала страницы (можно сделать так, что первым кадром каждой страницы идёт "ключевой" кадр, в котором есть все строки от первой до последней) и со звуком тоже всё просто - звук пишется плавно и последовательно в те строки что идут в ромдиск, но это всё потом

Тут возникает парадоксальное противоречие!
С одной стороны, на каждой странице - ключевой кадр: Можно хоть сотню кадров туда дифференциально впихнуть построкам. Хорошо!
С другой стороны - звук. Нельзя так со звуком!

Этот метод для длинной GIF-анимации подойдёт.
А в видео - важно соблюдать стабильность.

Я не хочу частить со звуком - во-первых это портит FPS, во-вторых некоторый пары (особенно яркие) будут искажаться в тёмную сторону - т.е. желательно иметь их реже, ну и в-третьих я тут позаписывал звук с эмулятора подавая прямоугольный сигнал с максимально возможной скоростью в вариантах звуковой отсчёт на пару и звуковой отсчёт на 4 символа - там где оно более высокочастотное, там оно сильнее искажается, а высокочастотные искажения это шум, поэтому я думаю надо ограничиться 7-8 кГц

Думаю, можно сначала закодировать звук в каждом байте знакоместа, а в плеере - выбирать частоту выборки STA. Это - чисто для экспериментов.

Но вот нюансы!
От частоты выборки звука в STA сильно варьируется и fps, сами знаете.

Есть компромисс: В рамках "симулятора РАДИО-86РК" можно написать самостоятельный плеер, который будет воспроизводить ROM-Диск. Там и с цветом можно экспериментировать без самого эмулятора, чтобы подобрать наилучшие значения. Вот для этого и нужен бит звука в каждом байте.
(Думаю, в Bash под вывод в консоль сделать не так сложно - попробую на досуге.)

То есть, можно подготовить несколько ROM-образов под разные fps и дискретность звука. Но под реальным кодом i8080 использовать конкретный алгоритм звука.

Думаю, нужно как-то обозначить заголовок ROM-страниц, чтобы плеер на старте генерировал конкретный код.
Так будет универсальнее!

Я могу свой конвертер выложить, чтобы любой мог видосики сжимать
Ему надо скармливать последовательность PNG 128x50 в градациях серого без прозрачности
Как минимум будет от чего плясать

Спасибо!
Надеюсь под wine в моём Raspberry он заработает.

P.S.: С другой стороны, как программист - я обязан разрабатывать собственный код чисто для поддержания "спортивной формы серых клеток"! Чем займусь позже.
P.P.S.: Сейчас часа два потратил на скачивание двух клипов (причина) - можно считать, весь день ушёл на свистопляску с добычей двух файлов клипа для конверсии!

[Shaos]

Мой код конвертеров обычно «бублик домен» - берешь его себе, называешь своим и надеваешь солнечные очки

И потом я в линухе всё делаю - Вайн ненужен

По заголовку формата - имхо ненужен ибо заголовком является код плеера, который будет воткнут в начало каждой страницы

По поводу частого звука - я же говорю, некоторые пары псевдопикселов будут сильно искажаться - в особенности полностью белые, т.е. белый фон превратится в серый снег - уж лучше пусть «снежить» будет каждый четвертый символ нежели все…

[Alikberov]

По поводу частого звука - я же говорю, некоторые пары псевдопикселов будут сильно искажаться - в особенности полностью белые, т.е. белый фон превратится в серый снег - уж лучше пусть «снежить» будет каждый четвертый символ нежели все…

Да, коду 17h тяжело подобрать замену.
А если использовать атрибут инверсии на всю строку? Хотя, там тоже будут наводки.

Хотя, может быть просто предусмотреть в алгоритме подобные ситуации и добавить ключ?
Типа, оптимизация звука в ущерб картинке или оптимизация картинки в ущерб звуку.
Тогда на экране и артефактов не будем иметь, а искажения звука практически не заметим.

Можно ли использовать псевдографический знакогенератор Апогея?
На сколько сложно подбирать символы не только по уровню яркости, но и по геометрии?

[Shaos]

В апогеевской псевдографике же 4 строки на символ - минимум 60 Гц будет и ПДП сожрет всю производительность ибо по максимуму 64 текстовых строки придётся делать и потом мы ведь про классический РК

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

[Alikberov]

По заголовку формата - имхо ненужен ибо заголовком является код плеера, который будет воткнут в начало каждой страницы

Уж не предлагаете ли под каждый формат звука разрабатывать новый код?
Думаю, следует в коде предусмотреть магическую ячейку, которая будет реконфигурировать код без всяких точечных правок.

Так, сейчас по адресу 0000 (как можете заметить директивой «L,3F») размещена команда «MOV D,M» с кодом 56h для визуального символа «V» («VIDEO»).
Можно, типа, эту ячейку и использовать под ключи:

• «MOV D,M»/«VIDEO» - Оптимизация картинки / Звук в 1/8
• «MOV C,D»/«MEDIA» - Средняя оптимизация / Звук в 1/4
• «MOV D,B»/«PAINT» - Оптимизация с учётом атрибутов цвета / Звук в 1/2
• «MOV B,C»/«AUDIO» - Оптимизация звука / Звук в каждом байте (минимум или отсутствие атрибутов)
• «MOV D,E»/«SOUND» - Только звук (изображение имеется, но ПДП отключён, а код искусственно замедлен)
• «MOV B,H»/«COVOX» - Только звук (изображение в ROM-Диске отсутствует: «STA 8002h; RRC; RRC; RRC; RRC; STA 8002h»)

В апогеевской псевдографике же 4 строки на символ - минимум 60 Гц будет и ПДП сожрет всю производительность ибо по максимуму 64 текстовых строки придётся делать и потом мы ведь про классический РК

В эмуляторе можно попробовать подменить знакогенератор и посмотреть!

P.S.: Кстати, ничто не мешает организовать ROM-Диск не на 256 страниц, а на все 32768, задействовав все 15 битов под регистр страниц.
При грамотном программном переключении получим до 1 Гб данных - можно целую полнометражку впихнуть!

[Shaos]

Не - порнометражку ненадо

Со старшими битами адреса идущими вместе со стробом защёлки адреса есть проблема - может не захватить (либо придётся дважды посылать - сначала без строба, а потом уже со стробом), так что лучше ограничиться 8 мегабайтами (это пока, а потом появится моя сетевушка с автоникрементом адреса и там можно хоть лайвстримы слать)

[Shaos]

Хотя, это и сейчас можно - директивой M:

• Ячейка 00EB содержит число PUSH'ей на заполнение строки (у меня - 32)
• Ячейка 00ED содержит длину одной PUSH-цепочки (у меня - 13)
• С адреса 01B8 начинается шаблон инструкций

Соответственно, сейчас у меня:

Code: Select all

        ORG     001B8H
        ;;;;;;;;;;;;;;;;;
        LDAX    D       ;  7
        RLC             ;  4
        STA     08002H  ; 13
        ORA     A       ;  4
        RAR             ;  4
        MOV     B,A     ;  5
        INR     M       ; 10
        LDAX    D       ;  7
        MOV     C,A     ;  5
        INR     M       ; 10
        PUSH    B       ; 11#80.13

Вам можно попробовать подправить:

• Ячейка 00EB содержит число PUSH'ей на заполнение строки (запишите 16)
• Ячейка 00ED содержит длину одной PUSH-цепочки (запишите 20)

Под код:

Code: Select all

        ORG     001B8H
        ;;;;;;;;;;;;;;;;;
        LDAX    D       ;  7
        RLC             ;  4
        STA     08002H  ; 13
        ORA     A       ;  4
        RAR             ;  4
        MOV     B,A     ;  5
        INR     M       ; 10
        LDAX    D       ;  7
        MOV     C,A     ;  5
        INR     M       ; 10
        PUSH    B       ; 11#80.13
        LDAX    D       ;  7
        MOV     B,A     ;  5
        INR     M       ; 10
        LDAX    D       ;  7
        MOV     C,A     ;  5
        INR     M       ; 10
        PUSH    B       ; 11#135.20

Должно сработать.
Но синхронизацию сорвёт, так как старшие биты уже начнут из звука попадать в атрибуты.

Не - чото не выходит
Видимо надо что-то ещё поменять...

P.S. А не - всё пучком
9.92 FPS получилось вот с этим кодом

Code: Select all

        ORG     001B8H
        ;;;;;;;;;;;;;;;;;
        LDAX    D       ;  +7=7
        STA     08002H  ; +13=20
        MOV     B,A     ;  +5=25
        INR     M       ; +10=35
        LDAX    D       ;  +7=42
        MOV     C,A     ;  +5=47
        INR     M       ; +10=57
        PUSH    B       ; +11=68
        LDAX    D       ;  +7=75
        MOV     B,A     ;  +5=80
        INR     M       ; +10=90
        LDAX    D       ;  +7=97
        MOV     C,A     ;  +5=102
        INR     M       ; +10=112
        PUSH    B       ; +11=123

Теперь надо избавиться от F1 и F3 в видеопамяти и переконфигурировать ПДП (с некоторой потерей FPS, но зато с более чистым звуком)

[Shaos]

Не - с подменой символов слишком мусорно выходит

[Alikberov]

Со старшими битами адреса идущими вместе со стробом защёлки адреса есть проблема - может не захватить (либо придётся дважды посылать - сначала без строба, а потом уже со стробом), так что лучше ограничиться 8 мегабайтами (это пока, а потом появится моя сетевушка с автоникрементом адреса и там можно хоть лайвстримы слать)

Теоретически, добавив второй ИР23 и переключая страницы двойной записью ([A001] <= PAGE & 7FFF; [A002] <= PAGE | 8000) можно заиметь 32768 страниц.
В Emu80, как подтверждает разработчик, вполне может работать.
На программном уровне - ещё не проверял (нужды нет с таким массивом работать).

Сейчас взялся за звук отдельно и попытаюсь добиться сносного результата.

Не - с подменой символов слишком мусорно выходит

А приоритеты выставили в кодере?

[Hammer]

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

Вброшу немного инфы, вдруг поможет:

1. Примитивный ЦАП - это конденсатор, заряжающийся через резистор. Чем дольше импульс, тем больше зарядится конденсатор. Я так делал на ардуино, получал синус и пилу звуковых частот. Убрал этот ЦАП - всё равно получил приемлемый звук из-за наличия ёмкостей в усилителе. Возможно с таким алгоритмом звук улучшится.

2. ВИ53 можно использовать, как ЦАП, если у него три канала через резисторы собраны в кучу, это Апогей. Фактически это трёхбитный ковокс, если на каналы выдавать не частоту, а стробы. Так же работал один из трекеров на Спектруме.

3. Где-то писали, что загрузка с магнитофона возможна без гашения экрана, если уменьшить длину пакетов ПДП, вроде до 8-ми байт, точно не помню. Тогда INTE тупит равномернее и звук получается хороший.

[Alikberov]

Вброшу немного инфы, вдруг поможет:

1. Примитивный ЦАП - это конденсатор, заряжающийся через резистор. Чем дольше импульс, тем больше зарядится конденсатор. Я так делал на ардуино, получал синус и пилу звуковых частот. Убрал этот ЦАП - всё равно получил приемлемый звук из-за наличия ёмкостей в усилителе. Возможно с таким алгоритмом звук улучшится.

Ещё играет роль размер диффузора динамика. По сути, динамик - та же LC-цепь.

2. ВИ53 можно использовать, как ЦАП, если у него три канала через резисторы собраны в кучу, это Апогей. Фактически это трёхбитный ковокс, если на каналы выдавать не частоту, а стробы. Так же работал один из трекеров на Спектруме.

В основном я разрабатываю в рамках исходной схемы РК. А таймеры - добавились позднее.

3. Где-то писали, что загрузка с магнитофона возможна без гашения экрана, если уменьшить длину пакетов ПДП, вроде до 8-ми байт, точно не помню. Тогда INTE тупит равномернее и звук получается хороший.

Эти настройки в ВГ75 я учёл.
Но здесь имеется нюанс: Звук всё равно получается "бинарным" - как модем.
То есть, для обмена данными - он подходит. А для "меломана" - никак нет.

Но, всё равно: Спасибо!

[Hammer]

Но здесь имеется нюанс: Звук всё равно получается "бинарным" - как модем.

Имеет смысл попробовать заряжать конденсатор через резистор, сразу звук станет не бинарным. На ардуино у меня получился резистор 1к, конденсатор 0.01-0.1 мкФ. Тогда записывать звук надо в виде продолжительности сигнала INTE. Чем выше амплитуда, тем дольше продолжительность. Выбрать, например, 4 дискретных значения для продолжительности - два бита. В этом случае звук можно будет хорошо сжимать или удобно упаковывать. Даже без конденсатора должно получиться, если подстроиться под запаздывание диффузора.