P.S. Каждый четвёртый символ это 16 отсчётов звука на строку - может не мудрствовать лукаво, а просто тупо в 2 байта их упаковать и записывать в начало каждой строки побитно двигая в порт по ходу отрисовки символов этой строки?
P.P.S. Тогда уже и адрес строки можно туда же присовокупить до кучи (адрес с конца для LXI SP) - будет 68 байт на строку или 9.6 полных кадров на страницу (коих может быть больше, если от кадра к кадру будет много повторяющихся строк)
P.P.P.S. В этом случае даже прогрессбар можно сделать опциональным (и со звуком), правда оно не будет кратно 256 и придётся либо химичить, либо укорачивать видимую область строки до 60 символов...
Я тут прикинул - теперешний плеер декодирует около 377 строк в секунду, т.е. если строки будут иметь адреса (предположим, что в скорости оно не сильно потеряет), то для пущей эстетики можно делать видео не в полный рост, а скажем letterbox (16:9 с чёрными полосками сверху и снизу) - это будет примерно 37 строк, что должно дать 10 FPS...
кстаааааати - если биты звука скомкать в кучу, то можно несколько упростить (?) вывод в INTE - т.е. вместо первоначального варианта со сдвигами:
Code:
RAL ; +4=4 JC CPI_DI+1 ; +10=14 EI ; +4=18 CPI_DI: CPI 0F3h ; +7=25 or +4=18 ORA A ; +4=29 or +4=22 RAR ; +4=33 or +4=26 (avg=29.5)
сделать И по маске (и заодно вычитку значения для SP в начале строки наряду с битами звука) примерно так:
Code:
INR M ; от предыдущей строки ; начало следующей строки JNZ L0 ; +10 INX H ; 5 \ INR M ; 10 (инкремент старшего байта адреса один раз на каждые 4 строки - это в среднем +20/4=5 тактов на строку) DCX H ; 5 / L0: ; тут будет усреднённо 15 тактов LDAX D ; +7=22 INR M ; +10=32 STA SND1 ; +13=45 RLC ; +4=49 (играем первый бит звука в преамбуле) JNC LD+1 ; +10=59 EI ; +4=63 LD: CPI 0F3h ; +7=70 или +4=63 (DI) LDAX D ; +7=77 или 70 - в среднем 73.5 INR M ; +10=83.5 STA SND2 ; +13=96.5 ; далее вычитываем значение для SP этой строки LDAX D ; +7=103.5 INR M ; +10=113.5 MOV C,A ; +5=118.5 LDAX D ; +7=125.5 INR M ; +10=135.5 MOV H,A ; +5=140.5 MOV L,C ; +5=145.5 SPHL ; +5=150.5 (SP=HL) LHLD ADRVAR ; +16=166.5 (восстанавливаем адрес) <<<< преамбула около 167 тактов на строку ; далее повторяющаяся часть для каждых 4 пикселов (повторяется 15 раз) LDA SND1 ; +13 ANI 40H ; +7=20 (играем второй бит звука) JZ L3 ; +10=30 EI ; +4=34 JMP L4 ; +10=44 L3: DI ; +4=34 MOV A,A ; +5=39 (для равномерности) MOV A,A ; +5=44 (для равномерности) L4: LDAX D ; +7=51 INR M ; +10=61 MOV B,A ; +5=66 LDAX D ; +7=73 INR M ; +10=83 MOV C,A ; +5=88 PUSH B ; +11=99 LDAX D ; +7=106 INR M ; +10=116 MOV B,A ; +5=121 LDAX D ; +7=128 INR M ; +10=138 MOV C,A ; +5=143 PUSH B ; +11=154 <<<<<< повторяющаяся часть ; следующая четвёрка пикселов LDA SND1 ANI 20H ; (следующий бит звука) JZ L5 ; и т.д.
т.е. имеем 154*15+167=2477 тактов на строку, что даст 330.1 строк в секунду (с учётом того, что ПДП сожрёт 54% процессорного времени) или 6.6 FPS при 50 строках в кадре или 9.17 FPS при 36 строках (letterbox с чёрными полосками сверху и снизу) или ещё больший FPS, если от кадра к кадру будут меняться лишь некоторые строки.
P.S. Если в ромдиске будет автоинкремент адреса, то можно сэкономить порядка 660 тактов, убрав все INR M, что выльется в 1816 тактов на строку или 450.3 строки в секунду, что даёт почти ровно 9 FPS при 50 строках и 7205 Гц для звука!
P.P.S. Для пущей плавности звука можно преамбулу ещё пооптимизировать, чтобы она стала ближе к длительности сегмента...
В принципе, так как подгружаемый SP - это универсально, можно обойтись штатным компактным кодом прогрывания. То есть, оставить оптимизированный шаблон, но при переключении страницы проверять некий флаг, чем её проигрывать (сжато / не сжато). Тогда на одной странице можно больше кадров поместить.
Но вот со звуком как? Быстро сменить картинку, а потом весь период потратить на более качественный звук? Не слишком ли сложно получится для кода обработки исходного файла? (Разработчики DivX позавидуют! ) Так и до страницы со "словарём" дойти можно для пущего сжатия.
P.S.: Кстати, пока не забыл. Думаю, в перспективе, желательно при обработке кадров задействовать хотя бы простую нейросеть для распознания текста, чтобы явно помечать регионы кадра и при перекодировке там более качественнее, с использованием псевдографики, выводить исходные надписи. (Последний ролик прямо на эту идею и наталкивает.)
16 Apr 2024 04:47
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22735 Location: Silicon Valley
Но вот со звуком как? Быстро сменить картинку, а потом весь период потратить на более качественный звук? Не слишком ли сложно получится для кода обработки исходного файла?
Не - не очень сложно. Звук будет идти всегда по строкам имеющимся в наличии, надо просто адаптивный алгоритм выбора следующего кадра сделать - если мы из текущего кадра взяли меньше строк, то и следующий кадр надо брать поближе на оси времени (а если совсем ничего не поменялось между кадрами, то всё равно надо перекодировать 22% кадра для сохранения 30 FPS) - как то так короче...
P.S. Ютюб практически перестал показывать бэдаппл и стал активно крутить рикролл:
Attachments:
Screenshot from 2024-04-16 08-09-22.png [ 31.4 KiB | Viewed 873 times ]
P.S. Если в ромдиске будет автоинкремент адреса, то можно сэкономить порядка 660 тактов, убрав все INR M, что выльется в 1816 тактов на строку или 450.3 строки в секунду, что даёт почти ровно 9 FPS при 50 строках и 7205 Гц для звука!
Автоинкремент - уже не Православно! Придётся ещё проводочки кидать внутрь всей схемы РК конкретно.
16 Apr 2024 09:33
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22735 Location: Silicon Valley
Не - просто эту платку надо будет ставить вместо ВВ55, чтобы непосредственно ловить /RD В моей версии срам86рк на разъём уже подаётся без ВВ55, причём 2 раза
Не - просто эту платку надо будет ставить вместо ВВ55, чтобы непосредственно ловить /RD В моей версии срам86рк на разъём уже подаётся без ВВ55, причём 2 раза
А, ну это да, тоже верно. На D14 можно было всегда экономить.
Тем временем, попрактиковался в ковертации музыки. (К сожалению, без ffmpeg не обходится.)
Не - просто эту платку надо будет ставить вместо ВВ55, чтобы непосредственно ловить /RD В моей версии срам86рк на разъём уже подаётся без ВВ55, причём 2 раза
А, ну это да, тоже верно. На D14 можно было всегда экономить.
Кстати интерфейс IDE тоже как бы с автоинкрементом уже
Можно взять "классический" RK86-SRAM32K, вставить в корпус ITX/DTX, приладив туда же IDE CD-ROM, к которому написать новый конвертер видео и плеер с учётом автоинкремента
Берите мой девайс: https://zx-pk.ru/threads/35692-internet-dali!.html - там синхронизация одним младшим битом адреса делается. И не надо готовить образ для РОМ диска. Просто файл загрузил и всё. Проигрыватель можно к файлу приклеить.
18 Apr 2024 23:04
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22735 Location: Silicon Valley
Берите мой девайс: https://zx-pk.ru/threads/35692-internet-dali!.html - там синхронизация одним младшим битом адреса делается. И не надо готовить образ для РОМ диска. Просто файл загрузил и всё. Проигрыватель можно к файлу приклеить.
Тут идеологическая проблема имеется - если есть ESP32, то РК уже ненужен
Users browsing this forum: No registered users and 7 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum