nedoPC.org

Пронумеровал кадры и вот как выглядит кадр 0077 в ромдиске и в эмуляторе:


Как можно видеть квадратная скобка и решётка двоятся только на экране, а в файле они были только один раз - так что похоже это косяк плеера...

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

(тут очертания символов несколько иные т.к. присутствует сдвиг знаков на 1 пиксел по вертикали)

P.S. Я тут с секундомером прикинул, что предпоследний плеер 64x50 даёт порядка 5.31 FPS на эмуляторе, а последний - 9.62 FPS, что я считаю вполе приемлимо

P.P.S. Поправил плеер, чтобы устанавливался режим 78x61x5@50.01Hz и в этом случае оно стало выдавать скорость 9.75 FPS

Занулите ячейки 0058/0059/005A/005B в коде плеера!
Сорри за глюк (вот что делает Copy-Paste из версии в версию).

Ну вот - совсем другое дело

Вот спасибо!

Теперь очевидно, что:

• Либо нужно поднять частоту звука в ущерб производительности
• Либо как-то особым образом обрабатывать звуковую дорожку перед кодированием

Конечно, можно поиграться с разными трюками и кодировать бит звука не на 1/8 знакомест, а 1/7 или 1/6.

Хм, нужно в код плеера добавить опцию с чтением формата звука (допустим, из ячейки 000C7F).

Кстати, сейчас придумал один способ, который повысит и общую производительность, и качество звука повысит.
Это не так легко в коде описать. Но я попробую.

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

Опробовал несколько вариантов и еле разобрался с отладкой.

В общем, получается так, что вывод в порт магнитофона - самый оптимальный по производительности.
Однако, это заметно сказалось на частоте кадров.
Все чётные байты старшим битом выводятся непосредственно в порт 8002.
Соответственно, 32x50 - порядка 1600 семплов на кадр.
На заполнение строки непосредственно затрачивается порядка 2560 тактов - 128000 тактов на кадр.
Из этого следует, что 1,7 МГц / 128000 - получаем не более 13 кадров в секунду, не учитывая затраты на управление указателем SP и переключение страниц.
Тем самым, в идеальных условиях могли бы иметь 13 кадров по 1600 семплов - менее 20,800 Гц звука, без учёта пауз при переходах через строки и прерывание ПДП.
Но, даже в идеальных условиях те мифические 20 кГц - слишком много. Потому можно будет под семплирование использовать не каждый чётный байт, а каждый кратный четырём.

Надеюсь, Вам удастся под этим вариантом плеера добиться более-менее кристалльной чистоты звука!

Кстати, для тестирования цветности лучше всего подходит вот этот клип:


P.S.: При повторной загрузке директивой R в ОЗУ грузится содержимое кадра, так как страница ROM-Диска не в НУЛЕ.
Думаю, следует выравнивать кадры так, чтобы первый блок всегда содержал код плеера (потом обсудим этот момент).

Не - пусть будет в нулевой странице. Монитор РК всё равно после каждого применения директивы R (и при инициализации) засылает в старший байт адреса FF, что заставляет квазидиск имени vinxru переключать страницу в произвольный номер, который лежал в тот момент в младшем байте адреса (при инициализации там по-видимому 0, поэтому сразу после ребута выбрана нулевая страница), поэтому на РК при таком квазидиске всё равно надо бы страницу выбирать перед каждой директивой R (если это не первое применение) - даже той же R типа R8000 и т.д. поэтому норм как сейчас. И потом просмотр кино это дело одноразовое - если надо поглядеть ещё раз, то пусть ребутают машину!

P.S. С другой стороны наверное было бы удобно (например для перемотки), чтобы в одну страницу влезало целое число кадров - в случае 3200 это 10 и соответственно остаются неиспользованными 768 байт (в начале) где можно держать плеер (в каждой странице), загружаемый через R,2FF в независимости от того какая страница сейчас выбрана (это может быть супер-плеер с детектом платформы, возможностью перемоток и т.д.)

P.P.S. Только сейчас увидел, что ты это уже сделал
> Вариант с выравниванием по 10 кадров с 0300 до 7FFF на каждой странице

Магнитофонный выход кстати может быть универсальным решением для того, чтобы один и тот же плеер заставить работать на РК, Микроше и Апогее (детект машины можно делать тупо по имени компа в ПЗУ - если имя неизвестное, то выбираем РК) т.к. в Апогее INTE переключает шрифты, а вот магнитофон у них везде магнитофон. И потом я тут выдумал сначала 2-битный, а потом 3-битный "ковокс", для которого используются младшие 2 или 3 бита ВВ55 (включая магнитофонный выход) - такой звук тоже можно поддержать в специальной версии плеера для моего RK-SRAM128K, собирая биты по отдельности из трёх идущих друг за другом символов (и оставив 4й на возможное переключение цвета)...

P.S. Попробовал TAPE версию и она у меня на Emu80 показывает порядка 7.3 FPS
Надо сделать версию где звук не в каждом втором символе, а в каждом четвёртом - возможно будет чуть быстрее...

P.P.S. Я тут попробовал по новому звук цифровать - сначала в Audacity разделил оригинал на 2 канала - низкочастотный и высокочастотный, затем оба оцифровал в 1-бит, а потом загейтал высокочастотный поток низкочастотным:

А кстати ведь можно попробовать низкочастотный 1-битный поток заслать на INTE, а высокочастотный 1-битный - на TAPE-OUT, т.е. как бы независимо друг от друга

Вот примерно так оно будет звучать:


(тут частота оцифровки 7800 Гц для обоих каналов, но на самом деле можно сделать НЧ пореже, а ВЧ почаще)

жостко...

На самом деле я использовал свой старый скрипт "Спектрумизации", слегка переделав его под конкретно данную задачу. Потому всё так из рук прям вон!


Думаю, вариант на 50 строк с знакоместом высотой в 5 линий больше подходит для разового отображения полноэкранного статического изображения.
Для динамических сцен оптимальнее будет 35 строк с высотой знакоместа в 7 линий: И циклы ПДП реже, и объём записываемых байтов меньше.

Прикинем:

• 64x50=3200=C80h
• 64x35=2240=8C0h

Как программист, замечаю, что можно округлить в меньшую сторону:

• 64x48=3072=C00h лучше, чем D00h
• 64x32=2048=800h лучше, чем 900h

Так как мой код проигрывателя расчитывается под РК и с ОЗУ 16 Кб, буфер экрана не может пересекать границу в 4000h в принципе.
Тем самым, под код имеем менее 13 Кб.
В моём варианте, как можно заметить, используется предварительное заполнение памяти шаблонным кодом, чтобы исключить ветвления - разворачивается цикл.
Так, если на 2 знакоместа сейчас отводится 13 байтов кода, соответственно на 64 знакоместа - 416 байтов.
Если оптимизировать глубже и развернуть цикл кадра - получаем 20950 байтов (учитывая предустановки SP), что совсем не подходит для ОЗУ на 16 Кб.

• 64x50: 419*50=20950
• 64x48: 419*48=20119
• 64x35: 419*35=14665
• 64x32: 419*32=13408

Для машин с 16 Кб ОЗУ оптимальнее 33 строки: Буфер экрана 2112=840h и буфер кода 13827 (примерно 84810 тактов на кадр / до 20 fps) - получаем примерно 445 байтов под весь код плеера.

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

Кадры размещаются с адреса 0800, соответственно на одну страницу умещается по 15 кадров высотой в 32 строки.
Ниже - архив с вариантом 32+1 (32 строки + ещё служебная информация 07F8-07FF строкой ниже).

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

Мне лично вариант 9.75 FPS понравился
Надо только со звуком разобраться...

А так по идее надо выбирать - либо частота кадров побольше, либо вертикальное разрешение побольше - я за большое вертикальное разрешение

P.S. Pyk на "соседнем форуме" выкладывал питоновский конвертер видосиков в псевдографике - можешь его попробовать для знакомест 6x8: https://zx-pk.ru/threads/33936-pishem-igry-pod-rk-podobnye.html?p=1196668&viewfull=1#post1196668

может, отделить тему разработки демо от начальной?

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

Даже делал эскиз текста открытия новой темы, чтобы новички в самом начале имели и описание, и код рабочий.
(Эх, кто бы научил программировать! А то всё приходится методом тыка делать, на что всё время уходит!)При жёсткой оптимизации крайне важно замкнуть всё в один развёрнутый цикл, а там требование одно - чтобы последняя строка экрана завершилась на адресе 7FFFh в ППА D14.

Делаем простой расчёт: 8000h - 64x50@10 = 8000h - 32000 = 768 = 0300h.
То есть, на каждой странице ROM-Диска первые 768 байтов таки придётся под код плеера отводить, а размещение кадров выровнять именно с 0300h.
Получаем на все 256 страниц до 2560 кадров.

768 байтов под код плеера на каждой странице - это очень хорошо и довольно много!
Можно использовать различные трюки. Например, чересстрочное заполнение буфера кадра, что визуально удвоит их частоту.
Соответственно, на опрос клавиатуры с перемоткой на ±10 кадров хватит.

Ещё ячейки 02C0h-02FFh можно использовать под служебную 51 строку, которая обновляется раз в 10 кадров - при переключении страниц.
Соответственно, выводить там позицию или заголовок, бегущую строку с рекламой и т.п.
То есть, если даже строка не будет видна из-за особенностей отображающего устройства - не важно.
Естественно, звук в ней должен также присутствовать.
(Выше вариант +1 я и выложил, но он - кривой и сейчас всё начну переделывать.)

На одну строко в 64 символа получаем 2570 тактов.
На все 50 строк - ровно 128500 тактов.
Соответственно, на 10 кадров - ровно 1285000 тактов при частоте в 1,777 мГц!
Короче, за 1 секунду программа таки успеет отобразить даже все 13 кадров!
(Естественно, в идеальных условиях.)

Думаю, следует заточить код проигрывателя ровно под 10 FPS!

Что предстоит сделать: Расчитать скорость для равномерного заполнения одной строки, чтобы обеспечить стабильность звуку.

P.S.: Сейчас установлю режим под 64x52, где 0380-03BFh и 03C0h-03FFh будут считываться раз в 10 кадров в самую верхнюю и самую нижнюю строки соответственно.
(Там и ползунок перемотки можно разместить, и субтитры, и приветы Якубовичу!)

В общем, практически весь день провёл в отладке и ничего не добился.

Будь у меня хорошее математическое образование, я бы с ходу понял, что высота в 50 строк никак не кратна четырём!
Оптимизированный код уже на 10 кадре лезет в ROM-Диске за 32 Кб, что приводит к сильному сбою.
Сократив число кадров до 9, сбой устранился, но основная проблема никак не решилась: Заполнение четырёх строк по 64 символа в каждой считывает 256 байтов. Соответственно, на 48 строках считывается 12 блоков по 256 байтов. А оставшиеся две строки считывают 128 байтов и попросту сбивают счётчик адреса.
(В линейном развёрнутом цикле это никак не устранить!)

Нужно либо делать 52 строки, что негативно скажется на FPS, о чём я выше уже размышлял.
Либо сделать 48 строк + 4 служебные (две вверху и две внизу).
(Эти служебные строки могут обрамлять видеоряд из десяти кадров совокупным содержимым этих кадров, например.)

Либо никак не оптимизировать и пользоваться прошлым кодом.
(Сами понимаете: Оптимизация имеет свою цену.)

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

P.S.: Однако, завтра попробую применить один трюк, который вдруг надумался.
На общей производительности скажется минимально, но код сможет кушать видеоряд любой высоты!