Посмотри как на вектор портировали, там есть компиляторЦитата:
Сообщение от svofski
Вид для печати
Посмотри как на вектор портировали, там есть компиляторЦитата:
Сообщение от svofski
Насколько я понял, компилятором там называется программа, которая из текстового файла делает бинарник для плеера.Цитата:
Сообщение от ivagor
Примерно так, если грубо. Спектрумовские редакторы сохраняют музыку в двух вариантах: "исходник" (нечто вроде текста с нотами, плюс данные орнаментов и сэмплов), всё это запаковано своими встроенными паковщиками в подобие архива, а второй вариант - компилировпнный модуль с плеером/без плеера, где данные уже идут в максимально оптимизированном для вывода формате. И вот разработка этого компиленного формата, а также плеера - самая ответственная задача для кодера. Каждый лепил, на что хватало мозгов, ну и с течением времени оптимизировались сами плееры компиленных модулей. Компилеры, как правило, были встроены прямо в редактор.Цитата:
Сообщение от svofski
Мой формат модуля (для STPro) не был оптимален по размеру компилируемых модулей, но в плане быстродействия и формат, и плеер близки к идеалу. В нём один "поток данных" для нот всех каналов, плюс своя процедура обработки каждого канала, что прилично раздуло код, но по итогу плеер вышел довольно быстрым и относительно компактным, 1868 байт, насколько помню. Вот архив с редактором на vtrd https://vtrd.in/system/STPROFIX.ZIP
Если не изменяет память, внутри трдшника есть отдельно демонстрационный Бейсик-плеер с замером на бордюре, и видно, что времянки почти не дергаются, настолько ровно подогнан код. Пардон за неВекторную тематику, но кому-то, возможно, будет интересно.
Кстати, раз уж вектор, то задачу выравнивания (если не нужна точность до такта) можно решить с использованием таймера.
reddie, очень даже интересно. И приблизительно понятно. Мое предложение делать дополнительное промежуточное пережовывание общепринятых трекерных форматов для удобства плеера по-моему совпадает по духу с этой идеей.
Я не закапывался глубоко в форматы трекерных модулей, но чуть чуть удивлялся тому, как там все высокоуровнево для такой низкоуровневой штуки. Имеющиеся плееры выходит совсем неплохо справляются с такой сложной задачей. А ведь по идее на целевой платформе нам не нужны ни паттерны, ни ноты и даже не частоты, а нужны уже просчитанные значения регистров. Орнаменты итд это для музыканта, а для плеера-чипа это все просто меняющиеся параметры. Но так легко дойти до того, что выходит, что регистровый дамп -- это лучшее, что можно придумать.
В общем вывод такой: для того, чтобы получить плеер лучше тех, что уже есть, придется включить голову и найти в ней мозг.
да. вопрос лишь в степени пережеванности =) тут прямая зависимость: чем сильнее пережевать, тем, по идее, быстрее плеер.Цитата:
Сообщение от svofski
именно, однако в те далекие времена кодерские технологии не дошли до PSG, вернее, до упакованного в разумные размеры формата. Отдельные кусочки дампа регистров использовались в критичных местах (одновременная загрузка с дискеты, например), но чтоб весь трек в PSG загнать, понадобилось много лет. Так-то да, дамп по скорости воспроизведения - лучший вариант. Но упаковать его в те годы подобным образом не представлялось возможным, особенно сразу на целевых платформах. Поэтому треки компилировались в некую смесь из дампа паттернов и сэмплов-орнаментов по отдельности, а на плеер возлагалась задача все это выкидывать в регистры чипа, и желательно побыстрее. Тут уже решала квалификация кодера, суметь провести оптимизацию по скорости (или, что намного реже, размеру). В ход шли всякие трюки и учет особенностей AY. Например, слайд сэмпла вверх-вниз в редакторе изображен как в плюс, так и в минус, но плеер делает только сложение регистровых пар, старшие незначащие биты высоты звука при этом игнорируются чипом, и т.д.Цитата:
Сообщение от svofski
Абсолютно верно. И лучше писать с нуля сразу под 8080 - в теории это даст наилучший результат, если программист хорошо разбирается в своем деле.Цитата:
Сообщение от svofski
Подскажите пожалуйста быстрый RND. я пока использую байтовый счетчик в прерывании, но хочется иметь чтото получше. Может можно читать из какогото порта какойнить мусор или часто меняющиеся данные?
Я использовал вот такой: https://github.com/nzeemin/vector06c...lcoda.asm#L797Цитата:
Сообщение от parallelno
На порты полагаться сложно, тем более в эмуляторах.
Можно инкрементировать seed, пока игрок не нажмёт Старт в меню - даст хорошее начальное значение.
Спасибо, nzeemin!
Покопавщись в интернетах нашел чуть более быстрый. но конечно не факт что качественее. Но для моих нужд самое то.
Код:; 8-bit Xor-Shift random number generator.
; Created by Patrik Rak in 2008 and revised in 2011/2012.
; See http://www.worldofspectrum.org/forums/showthread.php?t=23070
; period 2^32-1.
; out:
; a - 8-bit pseudo-random number
Rnd8:
push h
push d
@rnd:
lxi h, 0xA280 ; seed must not be 0
lxi d, 0xC0DE ; xz -> yw
shld @rnd+4 ; x = y, z = w
mov a, l ; w = w ^ ( w << 3 )
add a
add a
add a
xra l
mov l, a
mov a, d ; t = x ^ (x << 1)
add a
xra d
mov h,a
rar ; t = t ^ (t >> 1) ^ w
xra h
xra l
mov h, e ; y = z
mov l, a ; w = t
shld @rnd+1
pop d
pop h ; 204
ret
push b ... pop b - может push d ... pop d?
- - - Добавлено - - -
И, кстати, если оставить push h ... pop h, то не будет hl - 16-bit pseudo-random number
- - - Добавлено - - -
Хотя лучше убрать комментарий про "hl - 16-bit pseudo-random number", эта процедура рассчитана на генерацию 8 битных случайных чисел.