Z80-чайник детектед
Серьезно, в чем смысл такого утверждения? Особенно в рамках ответа на мой предыдущий пост.
Я постарался во всех деталях описать все плюсы и минусы использования буферов, но вместо этого ты разглядел одно лишь предложение про LDIR и ответил в духе "ой-ты-ваще-чайник-рассмешил-меня, потому что вот в этом предложении описан не самый крутой способ, можно извращаться и получше".
Если тебя интересует мой опыт программирования на Z80, то в этой области я действительно не претендую на звание профи, и у меня нет в планах постоянно им заниматься. Оно мне понадобилось только для того, чтобы реализовать свою идею - написать годный DAC-драйвер.
К слову, Mega PCM - это вообще первое, что я написал на Z80. Когда приступал, был чайником, конечно, ведь опыта программирования конкретно на Z80 было ноль. В конце же работы над проектом я уже приобрел немало опыта. Моей задачей было написать серьезный и функциональный драйвер, с оптимальным кодом. И думаю, со своей задачей я справился, ведь то, что мой драйвер, с огромным количеством новых возможностей, работает быстрее оригинального драйвера Соник 1, в котором почти ничего нет, уже о чем-то говорит.
ощутимо быстрее будет в цикле подряд по несколько штук LDI
Ну, допустим, ты будешь использовать LDI, да. Ну быстрее, да. Ощутимо. К черту цикл, давай рассмотрим самый наилучший способ - 256 таких инструкций, идущих подряд. (Что кстати займет целых пол-кило памяти).
Ну получится в итоге, что исполнение занимает 7% от времени отображения NTSC-кадра. И все равно не выгодно.
а еще быстрее стеком типа
Ты уверен? Способ-то остроумный. Для переноса 6 байт прокатит (лучше не придумаешь), но нашем случае - сомневаюсь.
Скажем, как ты будешь оперировать оффсетами "куда" и "откуда"? Если оффсеты "куда" статичные и их можно каждый раз загружать как ld sp, xxxx, то в РОМе каждый раз приходится читать с разных мест. В таком случае, по когда ты получил 6 байт из буфера, лучшее, что ты можешь сделать - сохранить значение sp в память, потом записать буфер, заново загрузить sp из памяти. И так каждый раз. А это уже выливается в 40 циклов (20 на ld (xxxx),sp и 20 на ld sp, (xxxxx)). Ну в лучшем случае, это будет на 1-2% быстрее, но, думаю, очевидно, что пляски с сохранением и загрузкой значения стека сводят на нет всю гениальность этого метода + жирный размер кода.
Добавлено позже:ты видел демку BadApple!!!9 в соседней теме ? так там Z80 вполне себе играет 4bit 13kHz ADPCM
Ты хотя бы видел сам алгоритм ADPCM? Аддаптивная Диференциальная Импульсно Кодовая модуляция.
Алгоритм подразумевает изменение шага квантования (шаг квантования "аддаптируется" под изменения волны), причем для предсказания следующего положения волны требуется умножать значение разности волн на величину шага.
Я знаю одного человека, великолепного программиста и разработчика алгоритмов, который написал свою, упрощенную реализацию ADPCM на 68K. Насколько помню, частота звука была 22 kHz. И это на 68K!
Мало того, что Z80 в два раза медленнее, так там еще нет операции умножения, а работа с 16-битными числами предоставляет некоторые трудности (в стандартной реализации 4-bit ADPCM все расчеты идут в 16-битных числах, разрядность выходного сигнала - тоже 16 бит). Это сложно, очень сложно. На гране возможного.
У меня есть мечта. Может когда-нибудь, я попробую реализовать ADPCM на Z80. Может быть, использование большего количества таблиц для промежуточных рассчетов поможет с этим. В любом случае, реализовать такой алгоритм на приемлимой частоте дискретизации, а я хочу более 8 kHz, очень сложно в поем представлении. Если кто-то написал реализацию ADPCM на Z80, то я снимаю перед ним шляпу - это действительно верх мастерства.
