TS Forum

Недавно встретил в одном коде следующие грабли: использовались строчные прерывания и плеер от PT3, который дергает SP для своих нужд. Что при этом происходит, лучше не думать, ибо несложно догадаться, что инт приходит прямо в плеере.
Выводы:
- не использовать хитрые плееры с SP,
- вызывать плеер только в том месте растра, где гарантированно не припрется инт, даже на пике потребления тактов плеером.

в общем, в рубиконе строчными интами выводится цифра в ковокс.
под АУ, естественно. и на описанные выше грабли я уже наступил.
в граблях:
1. плеер занимает несколько (не чёткое количество) строк.
2. плеер от PT3 постоянно использует SP для снятия данных из памяти.
3. плеер без подобных проблем не знаком.

решением оказалось: не менять плеер, оставить воспроизведение во фреймовом инте;
строчные инты делают всё что и должны;
а в основном цикле пересчёт адреса, с которого продолжаем вывод в ковокс.

Знаю, что не всегда это возможно, но проще запрещать новые прерывания в ISR.

Ну ковокс же прерывать нельзя иначе хрип. Значит будем переделать плеер под без SP, все равно в скорость не упирается.

В аттаче плеер PT3, где убрано использование SP. Фикс быстрый и неоптимальный. Оптимизации приветствуются.

TS-Labs, заметь насчёт хрипа в рубиконе.
технологию я описал.
а вот уплощённый плеер действительно нужен.

Ну, так а собсно - поменять пару строк в плеере, убрать б-гмерзъкъ SP, сколько там тех нещасных тактов.
Еще одна вещь, которую я никогда не понимал в плеерах под АУ. Почему сброс новых значений в АУ происходит В КОНЦЕ плеера, а не в начале? Его ж колбасит вверх/вниз. Не, ну я понимаю, что человеческое ухо вроде как не слышит, но это же не труЪ! Первыми командами на обработке прерывания с плеером обязан стоять дамп в порты, который будет вызываться в детерминированно постоянной фазе относительно чего-угодно, лишь бы не плавал. Там же должна стоять обновлялка ковоксного хрипера, причем АТОМАРНАЯ, это значит, что 16 бит значения должны записываться через ld (player_addr), reg_pair, а если нужно еще и указывать пагу, то делать обязательно DI: HALT перед записью всех 24 бит, а то может выйти что одно записалось, пришел инт, тогда только записалось другое, и поплыли в адЪ...

TS-Labs wrote:Ну, так а собсно - поменять пару строк в плеере, убрать б-гмерзъкъ SP, сколько там тех нещасных тактов.

Vortex player и так медленный. Будет вообще слоупок.

Sergey78, там не так много обращений. что-то в духе ld sp,hl pop hl и дальше, но хватает

Господа хорошие, возьмите PSG плейер и не парьтесь.
Развёрнуто: сидят, понимаешь, на машине с 4мб памяти и экономят на колбасных обрезках :)

Спек, да тут скорости хватает на все на свете, да еще при аппаратной графике. Байка - такты.
...
Замерял чо ухучшилось:
+230 тактов в основном цикле плея (1480 против 1710)
+295 тактов в пике (1899 против 2194).
(Замеряно при работе на 14МГц. "Такты" = такты 3.5 МГц как показывает анрыл. 1899 тактов 3.5 это 8.5 строки видео. Сколько это в тактах 14 я не обращаю внимания.)

TSL, ты реально не понимаешь. Мой плейер тратит 1.35к тактов МАКСИМУМ. При этом все регистры вылетают за первые 600 тактов, т.е. почти максимально быстро. Вариант плейера psndcj тратит 1.1к тактов МАКСИМУМ. Записи регистров там не так компактны, но уж точно не как в вортексе и т.п. И никакого маньячества со стеком.

Да понимаю я все Я к тому, что нет необходимости экономить на плеере.
Ну ок, а как ты генеришь дамп? Это ж ждать несколько секунд. Или сразу грузить? Тогда 100500 килобайт.

TS-Labs wrote:Спек, да тут скорости хватает на все на свете, да еще при аппаратной графике. Байка - такты.

Чоткий ответ

Так и памяти хватает. Поэтому аргумент не вполне канает имхо...