Посмотри как на вектор портировали, там есть компиляторЦитата:
Сообщение от 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 битных случайных чисел.
ivagor, ага, спасибо. поторопился. :)
Качество рандомайзера можно проверить выводом точек по случайным координатам. Или хотя бы прямо рандомные числа писать подряд в экран. И смотреть, не получился ли на экране паттерн.Цитата:
Сообщение от parallelno
nzeemin, ага. Так и проверяю. :)
Кстати, нашёл, вот тут я тестировал два рандомайзера:
https://zx-pk.ru/threads/32499-porti...=1#post1091958
покумекав для себя вывел вот такой псевдо рандом для байтоых значений
рандомайзит вполне пригодно для меня. ну и побыстрее чем то что нашел.Код:Random:
@mainCodeAddr:
lxi h, $100
@rnd:
sbi 1
rrc
xra m
cma
inr l
sbb m
shld @mainCodeAddr+1
sta @rnd+1 ; 84
ret
https://pic.maxiol.com/images2/16600...747235.rnd.png
- - - Добавлено - - -
lxi h, адресс кода основной программы используется как сид. используются только 256 байт
- - - Добавлено - - -
nzeemin, проверь если сможешь в своих проектах насколько универсальная или не универсальная штука получилась. :)
Вспомнил что ещё недавно разбирал код на Z80 имеющий 16-битный рандом.
Это из Scuba Dive для ZX Spectrum:
Код:NextRandom
LD HL,(RANDOM) ; get current Random
LD D,H
LD E,L
ADD HL,HL ; x2
ADD HL,HL ; x4
ADD HL,HL ; x8
ADD HL,HL ; x16
PUSH HL
ADD HL,HL ; x32
EX (SP),HL
OR A
SBC HL,DE ; HL = x15
POP BC ; BC = x32
ADD HL,BC ; x47
ADD HL,HL ; x94
ADD HL,HL ; x188
ADD HL,HL ; x376
ADD HL,DE ; x377
ADD HL,HL ; x754
ADD HL,HL ; x1508
ADD HL,DE ; x1509
LD DE,$0029
ADD HL,DE
LD (RANDOM),HL ; (RANDOM) := (RANDOM) * 1509 + 41
RET
___
И ещё один вариант рандомайзера, на этот раз 8-битный, из Highway Encounter, с виду довольно быстрый:
Код:; Псевдослучайное 8-битное число с периодом 256 по отношению: X[1] = X[0] * 5 + 7
; I: -
; O: A=RND
; M: HL, AF
Rand: lxi h,RndVal
mov a,m
add a
add a
add m
adi 7
mov m,a
ret
nzeemin, Хороший результат.
https://pic.maxiol.com/thumbs2/16600...40750.rndn.png
Частично сдам назад. Для 8-битных обеспечивается заявленный период и в таком варианте, как пишет автор, генератор почти прошел статистические тесты. Но если обеспечение заявленных характеристик не обязательно и надо просто сгенерировать "что-то псевдослучайное 16-битное", то можно взять HL, только для этого нужно вызывать rnd8 по два раза для получения нового значения HL! На мой взгляд все же лучше брать генератор нужной разрядности с предсказуемыми характеристиками.Цитата:
Сообщение от ivagor
нашел еще парочку интересных псевдо рандомайзеров
Код:; 16-bit xorshift pseudorandom number generator
; returns hl = pseudorandom number
; corrupts a
; http://www.retroprogramming.com/2017/07/xorshift-pseudorandom-numbers-in-z80.html?m=1
Random:
lxi h, 1 ; seed must not be 0
mov a,h
rar
mov a,l
rar
xra h
mov h,a
mov a,l
rar
mov a,h
rar
xra l
mov l,a
xra h
mov h,a
shld Random+1 ; 116
ret
Код:; Fast RND
;
; An 8-bit pseudo-random number generator,
; using a similar method to the Spectrum ROM,
; - without the overhead of the Spectrum ROM.
;
; R = random number seed
; an integer in the range [1, 256]
;
; R -> (33*R) mod 257
;
; S = R - 1
; an 8-bit unsigned integer. 256 period
; http://www.z80.info/pseudo-random.txt
Random:
mvi a, 34
mov l, a
rrc
rrc
rrc
xri $1f
add l
sbi 255
sta Random+1 ; 64
ret
Код:; returns pseudo random 8 bit number in A. Only affects A.
; By Lee Davison. 256 period
; https://philpem.me.uk/leeedavison/z80/prng/index.html
Random:
mvi a, 1 ; get seed. must not be zero
ani $B8 ; mask non feedback bits
stc ; set carry
jpo no_clr ; skip clear if odd
cmc ; complement carry (clear it)
no_clr:
lda Random+1 ; get seed back
ral ; rotate carry into byte
sta Random+1 ; save back for next prn ; 72
ret
255Цитата:
Сообщение от parallelno
sta Random+1Цитата:
Сообщение от parallelno
Но вобще эта процедура в основном является иллюстрацией, что если неэффективно реализовать неэффективный вариант конфигурации LFSR, то получится неэффективно.
ivagor, спасибо поправил
чуть ускорил одну из предыдущих процедур. все тф же последовательность в 256 байт, но на 4 такта быстрее :)
Код:RndVal .byte 34
Random:
lxi h, RndVal
mov a, m
rrc
rrc
rrc
xri $1f
add m
sbi 255
mov m, a ; 60
ret
обновил первый пост про палитры и добавил раздел про музыку
- - - Добавлено - - -
Скачал Arkos Tracker2 отсюда https://www.julien-nevo.com/arkostra....php/download/Цитата:
Сообщение от svofski
но что-то он не понимает форматы pt3, pt2, и STC
Подскажи в каком формате ты ему скормил музыку?
Arkos умеет читать .vt2, это текстовый формат Vortex Tracker II. А Vortex Tracker может читать pt3. Но тут получается, что Arkos не очень нужен, потому что если у тебя есть VT и AyEmul, вот уже и полный комплект, который умеет больше форматов. Польза Arkos в кроссплатформенности и наверное в нем есть какие-то привлекательные фичи, но я их пока для себя не открыл. Для себя я в итоге делал так -- искал музон, допустим нашел что-то на zxart.ee. Открыл его в Vortex Tracker-е. Может быть отредактировал -- убрал задержку в конце или отрезал какой-нибудь паттерн, в общем ремикс по месту. Сохранил и превратил в .ym через AyEmul. Дальше уже заправил в gigachad16 и готово.Цитата:
Сообщение от parallelno
Сталкнулся с интересным багом. Virtual Vector 7.03 и Emu80 4.0.420/qt по разному эмулируют мою игру. В Emu80 игра зависает, в VV играет. В игре явно баг, но вот такое разное поведение эмуляторов пока в диковинку. :)
Если кто-то из решит посмотреть в чем дело, то вот ром
https://github.com/parallelno/Vector...GameNoname.rom
там на странице нужно нажать кнопочку Download чтобы скачать rom.
parallelno, проверь ещё в эмуляторе v06x - https://github.com/svofski/vector06sdl/releases
Под словом "играет" я имел ввиду что не зависает. :D
Только рисуются тайлы уровня для отливки бага.
В v06x на глаз идентично emu80v4. Судя по Базырю идет какая-то работа с квазом -- если это расширения Баркаря, то в v06x они пока не поддержаны.
Должен использоваться только стек доступ к квазу. Но что-то идет не так. Непонятно :)
Ну что ж, в emu80 замечательный отладчик. Должно быть относительно нетрудно вычислить момент, когда действительное начинает расходиться с ожидаемым.
Если включать код полностью, монстров, героя, музыку, то зависает и в VV тоже.
- - - Добавлено - - -
Ага, нужно дебажить. Классно было бы иметь дополнительные фичи для отладки например брейк проиты на доступ к памяти, call stack, проигрывание до следующего halt, перемотку назад. Это бы сильно облегчило отладку :)
- - - Добавлено - - -
А и ещё иметь возможность видеть что в видео памяти нарисовано.
Можно побороть симптом - записать С9 вместо C3 по адресу 0000.
Проблема в том, что emu80 на третий раз странно выполняет
0259 CALL 023A
Вместо 23A почему-то вызывает 0000
У меня тоже есть программка, которая виснет в emu80, но с ней пока не разбирался.
Это все есть в v06x через gdb, но разбираться с тем, как этим пользоваться, особенно если ты не настоящий сварщик, довольно хардкорно. Я сам предпочитаю или почереповать, или, когда череп сдает, в теплом ламповом emu80.Цитата:
Сообщение от parallelno
Я дебажил немного через консоль когда-то давно, это тот ещё экспириенс. Не скажу что мне это доставляло удавольствие. :) поэтому настоящим сварщиком не стал.Цитата:
Сообщение от svofski
Но то что ты сделал это для эмулятора, круто! Вот бы это прикрутить к vs code! :) Чтобы прям с него визуального дебажить... Круто было бы! :)
gdb-z80, который у меня прикручен, основан на допотопной версии gdb, которую сейчас даже собрать не получается современными компиляторами. Ну и мнемоники z80 для отладки 8080 -- это не мое. А вообще идея интеграции с vscode интересная. Кстати IDA вроде умеет цепляться к ремотному gdb серверу.Цитата:
Сообщение от parallelno
IDA вроде платная или я что-то путаю?
Да, и я ей не пользуюсь.Цитата:
Сообщение от parallelno
Попробовал так сделать. Теперь вместо call 23a PC убегает аж в FD00. Потом возвращается по RET в нулевом адресе. Дикость какая. :)Цитата:
Сообщение от ivagor
Вероятно зависит от того, как именно реализовать правку. Я грубо хакнул и игрушка запустилась в emu80, но т.к. это было всего лишь лечение симптома, то при отличающейся правке тот call может начать чудить иначе.Цитата:
Сообщение от parallelno
А с моей программкой проблема вероятно в работе с диском. Причем с диском работаю не напрямую, через дос, но в emu80 виснет.