ivagor,
Я имел ввиду разрешение экрана. Или я что-то упустил и оно устанавливается?
Вид для печати
ivagor,
Я имел ввиду разрешение экрана. Или я что-то упустил и оно устанавливается?
Если я ни чего не путаю, то разрешение экрана устанавливается одновременно с установкой цвета бордюра...Цитата:
Сообщение от parallelno
Да, четыре младших бита - цвет бордюра/номер цвета палитры, следующий бит - видеорежим. svofski только недавно навыкладывал много примеров в теме про 512 точек, вот один из них.
Я вот смотрел его, хотел на него указать, но не нашел там команд "OUT" , кроме "out 10".Цитата:
Сообщение от ivagor
Код:; включить режим 512 точек
mvi a, $10
out 2
А оффсет по вертикали тоже нужно каждый кадр устанавливать?
Да, потому что при записи любого управляющего слова в 8255, его выходы сбрасываются в 0. Точно то же самое, что было с бордюром.Цитата:
Сообщение от parallelno
svofski, интересно почему оффсет для не сдвинутого положения экрана 255, а дефолт 0. :)
parallelno, дефолтное значение на выходе порта 0 -- это особенность 8255. А дефолтное значение для несдвинутого экрана 255 -- это особенность схемы Вектора.
у нас примерно 60К тактов между прерываниями. как я помню после HLT формирование экрана закончено и начинается рисоватся новый. Сколько времени тратиться на отрисовку бордюров сверху и сниху и на сам кадр?
59904 такта, 312 строк по 192 такта. VV показывает счетчик тактов в кадре, а emu80 -- еще и строку и пиксель в строке.
У меня где-то записано так: 22 строки vsync, 18 строк верхний бордюр, 256 строк растровой развертки, 16 строк нижний бордюр.
- - - Добавлено - - -
Кстати по касетельной. Не случилось ли со времен 8-битной улитки нового плеера pt2/pt3 адаптированного для Вектора? Вчера провел больше времени, чем рассчитывал, перелопачивая абсолютные ссылки в плеере из улитки с целью сделать его релоцируемым. В принципе получилось, но все равно осталась куча непонятных мест, которые портят память в более-менее случайных местах. Ничего такого, чего нельзя поправить еще парой усидчивых часов, надеюсь. И все равно это меньше труда, чем выдирать очередной плеер из других демок. Но все же..
К слову, жутчайший код, не знаю отчего он такой. На полторы тыщи строк ассемблерного кода там наверное сотни три переменных. Как вообще такое можно было написать? Может это последствия рекомпиляции с z80?
Если очень надо pt3, то можно перевести в psg и упаковать, но для компактной демы это не подойдет.
По крайней мере можно попробовать. К слову сказать, этот чудо-плеер занимает 3068 байт, что наводит на мысли о том, что большинство регистровых дампов будут покомпактней, чем pt2+этот плеер. К тому же, насколько я понимаю, он ограничен pt2. Кстати, если любопытно, можно по быстрому собрать мой пример из предыдущего сообщения и глянуть на него в Базыре. Он там весь просто сияет всеми своими килобайтами. Жуткий код.Цитата:
Сообщение от ivagor
А есть примеры как pt3 переводится в psg и потом проигрывается?
Сам пользовался AY_Emul, там в списке проигрывания (playlist) правый клик на файле и "Конвертировать в ..." выбираем psg. Размер psg будет больше раз в 8. Если упаковать psg, то размер будет больше оригинала в 2-4 раза (смотря чем паковать). Формат psg очень простой, я даже без описания как-то проигрывал (если кто-то подскажет где описание - я только за). Но возможно до проигрывания не дойдет и все закончится на первом этапе, когда станет понятен размер.Цитата:
Сообщение от svofski
Чего-то мне не везет с AY_Emul, все ссылки в какой-то мрак, антивирусы ругаются, собрать самому из того фарша что там в исходниках не светит. Ладно, будем искать...
Когда-то давно похоже я здесь качалЦитата:
Сообщение от svofski
https://bulba.untergrund.net/emulator.htm
..........
А невнимательно я - поспешил, вижу ivagor уже дал эту ссылку.
Сейчас malwarebytes говорит, что помойный сайт. Может это false positive, но осадочек остался. Нашел некий aylet-0.5. В нем фичи дампа нет, но прикрутить ее на первый взгляд несложно. Правда, если действительно прогнозируемый объем 8х, прям не знаю..
Описание формата psg есть в help к AY_Emul, но с учетом проблем вероятно стоит поискать в другом месте
Я нашел некий Arkos Tracker, который может сохранять файлы .ym, которые насколько я могу судить суть ровно то же самое -- дамп всех регистров (он может их группировать по фреймам и по регистрам, на выбор). Размер разумеется получается совершенно слонопотамский, но на вид сжимаемо. Вот думаю, для zpu8080 я делал поддержку dezx7 в виде потока. Может быть можно сделать плеер из ym-дампа с поточной распаковкой на лету?
- - - Добавлено - - -
Просто для лулзов, 61кб пофреймовый .ym файл zx0 ужался в 4.5кб. Прикидываю себе размер распаковщика + регистропихателя еще байт 100-200 и результат может случиться более компактным и кто знает, может быть более быстрым, чем оригинальный файл + адский плеер.
Привет всем...Цитата:
Сообщение от svofski
Ay Emulator v2.9 на vtrd.in...
https://vtrd.in/pcutilz/AYEM2932.zip
Правильно я понимаю, что прерывание возникает в момент начала обратного хода луча?Цитата:
Сообщение от svofski
И тогда получается, что после начала прерывания есть 40 строк * 192 = 7680 такта до начала рисования первой видимой строки.
nzeemin, вроде бы так, да. Если что-то вверху экрана без теринга надо нарисовать, лучше это делать за этот промежуток времени. Или уж наоборот, ближе к концу кадра.
Удобно добавлять в основной цикл чего-нибудь типа mvi a, 1 \ out 2 ... <длинный код 1> mvi a, 2 \ out 2 ... <длинный код 2> ... mvi a, 0 \ out 2 -- и по бордюру смотреть, если что-то съедает больше времени, чем планировалось.
Копался в инете и нашел книгу некого американского металурга по I8080 / z80. Понравилось что он рассматриваем оба проца и показывает какие-есть альтернативы для I8080 чтобы заменить недостающую часть.
https://worldofspectrum.net/pub/sinc...rogramming.pdf
(это не имеет даже косвенного отношения к сжатию данных, поэтому я продолжаю тут)
parallelno, видео квазидиск не видит, поэтому можно какую угодно программу исполнять прямо в квазидиске. Но в стандартном квазе отображается только 8кб на адреса 0xa000-0xbfff, если не изменяет память. Остальное доступно только через стек.Цитата:
Сообщение от parallelno
Этим пользуется "улиточный" плеер, он сидит в адресах 0xa000. Он прячется в квазидиске и именно по этой нелепой причине улитке для звука требуется кваз несмотря на то, что памяти свободной там вагон. Сейчас я его частично от этой беды вылечил, но только частично.
16 (A000-DFFF)Цитата:
Сообщение от svofski
Посмотрел описание к квази-диску. Н-да.
Если подключать в адреса A000-DFFF - это значит, ограничить себя одной цветовой плоскостью (E000-FFFF) или двумя (плюс ещё 8000-9FFF). Но и использовать из квази-диска получится только 4 x 16K = 64K.
Так что по любому нужно писать процедуру перекидывания данных с квази-диска через стековые операции.
Плюс ещё нужно будет его как-то наполнять - видимо, чтением с диска?
Не обязательно так. Можно вынести процедуры обработки изображения в область 0000-7FFF, а всё остальное держать на КД в подэкранной области, и при этом иметь все 32 кб на экран. Ну а ко всему остальному объёму кваза обращаться через стек, как это делают МДОСы.Цитата:
Сообщение от nzeemin
Пусть меня поправят реальщики, но у меня сложилось впечатление, что у большинства сейчас квазы поддерживающие доработку Баркаря (номер журнала с описанием здесь). Он позволяет перекрывать до 4х экранных плоскостей и, соответственно, использовать до 128 Кб без стека. В эмуляторах (не помню насчет v06x) это конечно поддерживается. Ну и недавно неожиданно получило популярность подключение к реалам двух квазов. Для emu есть такой конфиг.
- - - Добавлено - - -
Есть несколько примеров, когда кваз (частично) заполняется при старте игрушки/демонстрашки. Туда или распаковываются данные или "предсдвигаются" спрайты и т.п.Цитата:
Сообщение от nzeemin
v06x в Баркаря умеет, но я скептически отношусь к "реальности" этой модификации. Хотя конечно вся реальность сейчас немного размытая.
Необязательно так строго. Их можно включать для моментального использования и выключать обратно. На содержимом экрана это никак не отразится. Например, туда можно выгрузить плеер и песенку. Или держать там какие-то алгоритмы, которые нужны, но не обязательно связаны с непосредственной модификацией параллельных областей экранной памяти.Цитата:
Сообщение от nzeemin
Все новодельные квазы поддерживают. И даже есть "старые" которые поддерживают. Поэтому я считаю, что сейчас проще найти работающий кваз с поддержкой расширений Баркаря, чем без них.Цитата:
Сообщение от svofski
Выколупывание все-таки не самое мое любимое занятие, но вот плеер из "Полета навигатора".
Компактненький, 1400 байт примерно. По времени 37-50 строк. Осталось разобраться, что за формат файла он играет.
- - - Добавлено - - -
Ага, методом перебора нашел, что это формат STC. Попробовал другой музон в этом формате, работает. Не самый популярный формат. Не знаю, как обстоят дела с конвертацией pt3 -> stc, но подозреваю, что никак.
Upd: ссылка на оригинальный музон DOCZak1 by DOC'NEONSOFT. Интересно, что в polet4k имя автора затерто.
Спасибо за инфу! Очень полезно.
Если что, в Emu80 тоже уже поддерживается...Цитата:
Сообщение от ivagor
Ну где ж ды был с этими ссылками до этого? =)
В общем это все плееры STC, то есть более-менее то же самое.
- - - Добавлено - - -
Вообще удивительно как много усилий требуется для проигрывания музыки. У нас сейчас есть две противоположности -- модуль + плеер, где вся обработка делается в плеере vs полностью декодированный модуль в виде регистрового дампа. Оба варианта далеки от идеала. Плеер требует вычислений в 2+ раза больше, чем распаковка 14 потоков регистровых дампов в условиях, приближенных к RTOS, а распаковщик регистровых дампов требует вагон памяти. Ну и тоже не совсем бесплатный по времени.
Плеер я не изучал детально, но видно, что там выполняется много движений для доступа к неудобно расположенным данным в таблицах типа чего-нибудь со смещением 7, лукапы по 16-битным ссылкам и тому подобное. Такие вещи как нарочно придуманы чтобы обидеть 8080, которому все это дается со скрежетом зубовным.
Может быть можно сделать иначе -- пережевывать модуль заранее во что-то промежуточное, что и не модуль удобный для редактирования, но еще не совсем регистровые дампы? Или они и так уже достаточно низкоуровневые и ничего принципиально изменить тут нельзя? Или там в принципе все и так норм, просто надо написать плеер думая как 8080, а не как z80, и все будет хорошо?
- - - Добавлено - - -
Проверил плеер DemonID7 - тут. (Upd: убрал "эквалайзер"). Большинство фреймов ~ 30 строк, периодически проседает до 45, а один раз поймал на 58.
А сколько максимально строк или тактов для плеера допустимо?
Многопоточный распаковщик на мой взгляд отличная штука, но в текущем виде не особо удобная для использования. Я пытался улучшить инициализацию, но в идеале надо еще дожать.
ivagor, у меня сейчас в проекте, который я пока не хочу показывать, инициализация улучшена -- не обязательно с точки зрения числа тактов, но проще для использования -- песня загружается из массива указателей на потоки и их легко переключать.
Сами данные подготавливаются скриптом, так что на самом деле проблем в настройке и использовании минимум. Ну разве что приходится конвертить музыку в ym, что может быть немного занудно.Код:lxi h, song_0
call gigachad_init
...
; песенка
song_0:
dw song_00, song_01, song_02, song_03, song_04, song_05, song_06
dw song_07, song_08, song_09, song_10, song_11, song_12, song_13
Сколько строк допустимо -- это зависит от ситуации. У меня сейчас так удачно сложилось, что с моим многопоточным плеером получилось засунуть звук туда, где я был уверен, что его вообще не будет. Вообще немного детерминизма плеерам не помешало бы, а то ты думаешь, что он отрабатывает за 35, а тут врдуг бах 58. Это конечно существенно только в случае, когда нужна жесткая привязка к развертке. Если ее нет, то в общем все это не так уж важно.
Простая инициализация - это приятно.
Насчет плеера я не совсем понял - не хватает времени на него в худшем случае или хватает, но проблема в плавании длительности? Если второе, то делим на "вычисление" очередной порции и выдачу в порты. Вычисление ставим в конец фрейма, в оставшееся время, а выдачу в порты (фиксированной длительности) где-то в начале.
Можно и так, но настолько большой размах, чтобы было заметно на слух, вряд ли достижим. Небольшое плавание есть у любого плеера в компиленном формате редактора (stc, pt и так далее), но даже у древнего плеера от st на Спектруме, где размах был довольно заметен (при визуализации на бордюр), это не ощущалось "ушами". Если по теме, наибольший эффект даст именно переделка плеера конкретно под 8080 с учётом отличий от Z80 ( если речь о переделке), ну или написание с нуля, подразумевающее свой, новый, оптимизированный формат модуля, где "размах" будет сведён к минимуму. В своё время писал компилер и плеер для STPro (Спектрум), и пришлось вдумчиво расставлять переходы и процедуры в плеере, зато размах в итоге был максимум в две строки бордюра, насколько помню, и то это теоретически достижимый потолок, на деле вряд ли встречающийся. А когда новая нота (позиция в паттерне) не извлекалась, стояла искусственная задержка для минимизации "плавания".Цитата:
Сообщение от ivagor
Короче, много слов, по итогу - написание грамотного плеера есть наилучший вариант.
Так и сделано в polet4k, например. Но это не решает проблему примерно никак особенно. Если основная логика и плеер вместе не помещаются в кадр, значит уже нет кадровости и приходится делать полукадровость. Причем плеером жертвовать нельзя, потому что ему обязательно быть вызванным 50 раз в секунду и все тут. А если делать что-то такое сложное, то хорошо знать заранее, когда на что сколько времени потребуется. Типа вот плееру надо 60 строк один раз в 50 кадров -- ок, не проблема, если это известно заранее -- можно спланировать дему-игру так, что это пройдет незаметно. А если это неизвестно, то либо приходится резервировать время всегда по худшей планке, а его столько просто нет, или нарываться на срывы периодически.
Про разбиение на вычисление и вывод -- в чем смысл, если и то и другое обязательно делать каждый кадр и все равно мы не знаем, сколько суммарно времени на это уйдет? Максимум что это дает -- убрать джиттер в примерно 1мс (считаю как примерно 1/20 экрана в 1/50 секунды) от того, что плеер вызывается чуть раньше или позже. Это правда слышно?
В моем конкретном случае сейчас -- времени на все хватает, потому что я пользуюсь gigachad16 :) Я изучаю что бывает и рассуждаю больше за вообще, на будущее.
- - - Добавлено - - -
Вот, я именно об этом. Наверняка есть какие-то особенные случаи, когда можно услышать этот размах, но не всегда требуется идеал. Иногда надо средненькое, но стабильное.Цитата:
Сообщение от reddie
- - - Добавлено - - -
А что значит "компилер и плеер". Я понимаю плеер, а что в данном случае подразумевается под компиляцией?Цитата:
Сообщение от reddie