nedoPC.org

Однако, получилось!

Данный вариант проигрывателя воспроизводит ролик 64x50@10 + 2 строки (0280-02BF / 02C0-02FF) под "титул" и "статус" на каждые 10 кадров.

Теперь буду ждать новый образ ROM-Диска по 10 кадров на страницу с выравниванием 0300-7FFF.

Осталось поработать с перемоткой…
И откроем новую тему с чистого листа с презентацией клипа, не рвушего в клочья уши.

А чего со звуком? Надобно каждые 4 символа наверное (16 раз на строку) и может быть даже ещё один отсчет звука записать в последний символ, чтобы покрыть перенастройку стека, что между строками (т.е. всего 17 отсчётов звука в каждой строке)?

P.S. Похоже звук всё также в каждом втором символе?

Вот 10 кадров на страницу со смещением #300 в каждой странице - плеер VHS-64X50-ALIGN#0300.RKR с бегунком вроде играет (хоть и 7.2 FPS) и VHS-64X50_2@10.RKR чего-то тоже играет, но только 7.74 FPS - может статус и титул слишком много времени жрут (знакогенератор всё равно обрезанный и им толком ничего не напишешь - ну разве что прогресс-бар снизу нарисовать) и 32 отсчёта звука на строку это наверное многовато?...

> ну разве что прогресс-бар снизу нарисовать

Вот с прогрессбаром (архив получился на 90 кило больше):

В последнем плеере каждая пара символов обрабатывается вот так:

7.74 FPS это 129 мс на кадр и при 1.78 МГц и 44% ПДП оно примерно даст 128427 тактов на кадр, в котором у нас 1600 пар символов, что даст 1600*80=128000 тактов на саму картинку и 427 тактов на оверхед (0.33%) или 8 тактов на строку, хотя должно быть как минимум 20 (JNZ+LXI SP) - будем считать это ошибкой округления тормозов от ПДП. Если делать звук не отсчёт на пару символов, а отсчёт на 4 символа, то в каждой второй паре выкинется 25 тактов, т.е. 2 пары теперь дадут 55+80=135 или в среднем 67.5 тактов на каждую пару символов, что даст 67.5*1600=108000 тактов на картинку плюс всё те же 427 оверхеда (примерно), что даст 108427 тактов на кадр, что должно дать 9.18 FPS и это сильно веселее

P.S. Если я доделаю свой Ethernet+RTC, то там всё будет ещё веселее т.к. WizNet предоставляет режим с автоинкрементом адреса - получается нам надо лишь данные вычитывать не заботясь о постоянном увеличении адресов, поэтому 10-тактовые INR M будут больше ненужны, а вместо 12-тактовой связки LDAX D + MOV reg,A можно задействовать 7-тактовую MOV reg,M (адрес источника теперь может быть в HL вместо DE), что даст экономию в 15 тактов на каждый символ или 30 тактов на пару, что даст 37.5 тактов или 60000 тактов на кадр, что с оверхедом (предположим, что он останется таким же) даст в пределе 16.5 FPS

P.P.S. Ксати можно сделать свой собственный квазидиск с автоинкрементом адреса для пущей весёлости...

Почему вариант с INTE был быстрее? Попробуем это выяснить - 1 бит звука вместо 25 тактов в случае использования INTE выполняется за:
Но это делалось один раз на каждые 4 пары символов или 55*4+29.5=249.5 делим на 4 и получаем примерно 62.4 такта на пару, что даст 1600*62.4=99800 на картинку плюс оверхед (предположим, что те же 427), что выльется в 9.93 FPS (а в реальности было 9.75 FPS, что близко, но чуть меньше т.к. там кадр не разворачивался - только строка). Если сделать 1 отсчёт на 4 символа, а не на 8, то это будет 55*2+29.5=139.5 делим на 2 и получаем примерно 69.8 тактов на пару, что даст 1600*69.8=111600 и при разворачивании кадра (оверхед 427) это будет 9.05 FPS, но скорость будет плавать в зависимости от наличия-отсутствия озвучки...

Мне кажется или звук стал более качественным?

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

Вариант с INTE, как Вы заметили выше, на Апогее будет мерцать знакогенераторами.
Тем более, на большинстве РК звук - пьезоизлучателе. тогда как порт магнитофона позволяет играться ручками тембра на внешнем усилителе.

Апогей имеет свой знакогенератор и можно в кодере использовать более сложный эвристический подход, заменяя контурные границы на соответствующие символы псевдографики 6x4.
Там и частота кадров выше будет.
Но, под Апогей я пока не разрабатываю ничего.

Вы предлагаете ухудшить качество звука и повысить FPS?
Или это просто размышления?

Думаю, код уже граничит и балансирует на уровне "приемлемый fps с приемлемым звуком".
Т.е. не вижу большого смысла ухудшать звук ради долевого выигрыша в кадрах.

Для РК вроде уже всё замечательно и годится для презентаций или заставок к играм:
Можно делать те же рогалики с анимированными вставками, что само по себе уже уникально!
Или тот же "Морской Бой" со сценами потопления кораблей (сохранять статус игры, заполнять память кодом плеера, проигрывать, восстанавливать код игры с ROM-Диска и продолжать дальше).

Как Вы верно заметили, бит звука выводится командой RLC с целым кодом в PC0-3 - код знакоместа попадает в порт.
Если кодер видео адаптировать и подбирать символы соответствующим образом, чтобы и знакоместо не искажать, и все четыре бита в COVOX выводить, можем получить звук более мягче?

P.S.: Спасибо за участие!
На досуге займусь своим кодером видео.

P.P.S. Кстати, отключив ПДП (код 80 в ячейку B1) можно прослушать реальное звучание на полной производительности.
(44% времени на ПДП - не шутки! )
То есть, как-то особенно обработать звук - никак не получится!
ПДП диктует свои правила!

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

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


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

P.S.: Особая благодарность Shaos, за конвертацию видео и предоставление образа ROM-Диска!

P.P.S. Shaos перенёс текст этого сообщения в первый пост топика

Думаю, тему можно почистить и перенести ключевые сообщения в новую тему.
Специально там не выкладывал архив ROM-Диска: Всё-таки, не я его сгенерировал.

Да выкладывай что уж там - всё равно Bad Apple не нами изначально создан

И плеер не забудь вписать в начало каждой страницы

Да, я предлагаю попробовать чуть ухудшить звук и соответственно улучшить FPS (и убрать титул и статус - на них ПДП ведь тоже тратится, а так там было бы F1 и минус 1% от ПДП) - прогрессбар можно сделать опционально полностью программно (как было в одном из предыдущих плееров)...

Отключив ПДП и методом тыка потратив пару часов на замедление воспроизведения потока, я в конце-концов услышал, как могло бы звучать в реальности, если бы ПДП не путался под ногами процессора.

На видео я тупо запускаю два эмулятора: Один без звука воспроизводит изображения, а второй - с отключенным ПДП параллельно проигрывает звук. Мнимый двухпроцессорный комп
То есть там чётко слышно, как могло бы звучать.

Ухудшение звука - тоже имеет свои нюансы и это не так легко сделать.
Придётся снова генерировать очередной ROM (пф-ффф) с новыми fps.
А у меня пока нормального кода для этого нет.

А так, позже я займусь вопросом ухудшением звука и попробую сделать экспериментальный плеер с указанием параметров, если это будет актуально.

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

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

Соответственно, сейчас у меня:Вам можно попробовать подправить:

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

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

> Придётся снова генерировать очередной ROM (пф-ффф) с новыми fps.

У меня автоматически генерится меньше чем за минуту

Кстати, а у Вас на "титуле" и "статусе" звук присутствует?
Там - тот же код и ожидает звук.

Мне говорили, что для качественного воспроизведения звука необходимо обеспечить равномерность циклов ПДП.
То есть, получается, нужно не убирать "титул" и "статус", а заполнить все 60 строк.

Однако, Вы - правы: Только сейчас понял, что "титул" и "статус", хоть и раз в 10 кадров отображаются, но могут вносить свои искажения в звук, если их игнорировать или учитывать.
(Ещё хорошо проверить, как будет воспроизводиться звук в режиме 78x50 строк "узкий экран", когда циклы ПДП будут равномерными - завтра проверю.)

Попробуйте ухудшить звук по скриншоту (синхронизацию сорвёт, если образ видео не адаптирован: Напоминает мятую VHS-плёнку чем-то).

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

> Кстати, а у Вас на "титуле" и "статусе" звук присутствует?
> Там - тот же код и ожидает звук.

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

> Мне говорили, что для качественного воспроизведения звука необходимо обеспечить равномерность циклов ПДП.

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

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

Как? Может спросить любопытный читатель - а вот как: если внимательно посмотреть на таблицу соответствия пар яркостей и символов для 5-строчного варианта псевдографики РК:
то можно увидеть, что для многих пар есть символы как с нулём в самом младшем бите, так и с единицей (помечены звёздочкой), а там где альтернативного кода нет можно выбрать соседний, где оно есть - получается звуком можно управлять младшим битом (в каждом четвёртом символе), а старший бит в ЛЮБОМ символе может быть полностью отдан под возможный цвет и не потребует танцев с бубнами вокруг звуковых отсчётов, когда мы таки сделаем цветные видосики, т.е. теперь будет так:
123 такта на 2 пары символов или в среднем 61.5 на одну пару, что даст 1600*61.5=98400 и с оверхедом 427 выльется ровно в 10 FPS

P.S. На самом деле если убрать #F1 в начале кадра и #F3 в конце кадра (для равномерности тормозов) ПДП станет жрать больше чем 44% процессорного времени и FPS в итоге будет несколько меньше - наверное порядка 8.9 FPS (что даст звуковой samplerate 7120 Hz)