Не - просто эту платку надо будет ставить вместо ВВ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: 23398 Location: Silicon Valley
Берите мой девайс: https://zx-pk.ru/threads/35692-internet-dali!.html - там синхронизация одним младшим битом адреса делается. И не надо готовить образ для РОМ диска. Просто файл загрузил и всё. Проигрыватель можно к файлу приклеить.
Тут идеологическая проблема имеется - если есть ESP32, то РК уже ненужен
В истории моего канала было только 2 момента, когда пики дневных просмотров поднимались выше, чем сейчас - и оба раза это была самодельная электроника, распиаренная на Hackaday.io (2 видео про цветного Мандельброта на микроконтроллере PIC32 в 2015 году и 1 короткое видео про самодельную софткорку RISC-V на FPGA в 2019 году, причём этот видеоролик внезапно "выстрелил" почти через год после загрузки) ... Хотя "ещё не вечер" - завтра нынешний пик уже будет выше второго (2019), а вот будет ли он выше первого (2015) - это ещё большой вопрос и самое главное - никакого хакадея в этот раз я не привлекал
Ну вот теперь практически "вечер" - нынешний пик стал вторым по высоте за всё время существования моего канала, но до первого пика 2015 года так и не добрался:
Attachment:
Screenshot from 2024-04-20 08-12-19.png
Теперешние цифры просмотров, комментов и лайков следующие:
Attachment:
Youtube-emuvideos.png
У рикрола даже пару дизлайков пролетело
You do not have the required permissions to view the files attached to this post.
Не - просто эту платку надо будет ставить вместо ВВ55, чтобы непосредственно ловить /RD В моей версии срам86рк на разъём уже подаётся без ВВ55, причём 2 раза
А, ну это да, тоже верно. На D14 можно было всегда экономить.
Кстати интерфейс IDE тоже как бы с автоинкрементом уже
Можно взять "классический" RK86-SRAM32K, вставить в корпус ITX/DTX, приладив туда же IDE CD-ROM, к которому написать новый конвертер видео и плеер с учётом автоинкремента
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. Для пущей плавности звука можно преамбулу ещё пооптимизировать, чтобы она стала ближе к длительности сегмента...
Я тут чего подумал - если будет автоинкремент, то код не будет отслеживать вычитываемый адрес и нам нужен будет какой-то маркер в самих данных, сигнализирующий о том, что страница подошла к концу и пора "листать", а если будет маркер, то и длину строки данных можно не обязательно выдерживать равным 64-м байтам (чтобы в 256 байт влезало ровное количество строк - в данном случае 4 т.к. инкремент старшего байта адреса происходит лишь между строками) - т.е. можно сделать строку длиной 64 байта "графики" плюс 2 байта SP плюс 2 байта звука (а в будущем даже 4 или 6 байтов для 2 или 3-битного звука) - т.е. строка станет длиной как минимум 68 байт, а автоинкремент сам будет инкрементировать старший байт когда надо, даже если перескок попал на середину строки. По звуку у нас тогда потребуется 17 битов звука вместо 16 (для равномерности звучания) - можно сначала вычитывать SP, а потом 2 байта звука, причём 17й бит звука (точнее в данном случае 0й) кодировать скажем в младшем бите SP, а маркер команды - в старшем бите SP (перед использованием SP будет обнулять и старший, и младший биты). Если после вычитки мы выяснили, что это не SP, а команда, то: 0C0NNh - далее играем только звук (на экране ничего не меняется) - в младшем байте вычитанного слова записано кол-во далее идущих звуковых байт (всегда кратно 2, т.е. звук будет идти построчно) 0C1NNh - команда перелистывания на страницу NN (можно использовать в том числе и для зацикливания видео) 0C2NNh - ждём NN кадров ничего не играя (на экране остаётся последнее отрисованное изображение без звука) 0C3XXh - конец фильма (вернуться в плеер, который сам будет решать, что делать в этом случае)
P.S. По идее можно спец.плееры делать, которые будут предоставлять типа меню аля DVD, при выборе разных пунктов которого будут играться разные последовательности страниц квазидиска
P.P.S. В будущем можно ещё команд надобавлять типа записывающие в регистры ВИ53 к примеру...
Users browsing this forum: Claude AI [Bot] and 0 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