Covox на БК-0010.01

[konst_st]

Это очень круто! Надеюсь, проигрыватель не затерялся. Было бы здорово портировать его на СОЮЗ-НЕОН.
А для громкостей использовал DIV или как-нибудь по таблицам?

Давно это было. С тех пор ничего не осталось. Для громкости кажется использовал MUL. Хотя могу и ошибаться. Кстати я там еще и осциллогамму в реальном времени на экран выводил.

[konst_st]

Исходник или экзешник в студию.

Как я уже написал, это было лет 25 назад. С тех пор ничего не осталось. УКНЦ была не моя (дали на время). Потом я перешел на IBM PC. Перекинуть данные было проблематично т.к. УКНЦ была с 40-дорожечными дисководами. Диски со временем тоже пропали.

[Titus]

Как я уже написал, это было лет 25 назад. С тех пор ничего не осталось. УКНЦ была не моя (дали на время). Потом я перешел на IBM PC. Перекинуть данные было проблематично т.к. УКНЦ была с 40-дорожечными дисководами. Диски со временем тоже пропали.

Тогда хотелось бы узнать хотя бы общие черты, как удалось играть MOD используя сразу два процессора. Очень примерно можно рассказать, что делал один ВМ2, а что другой.

[konst_st]

Тогда хотелось бы узнать хотя бы общие черты, как удалось играть MOD используя сразу два процессора. Очень примерно можно рассказать, что делал один ВМ2, а что другой.

Смутно помню. Но что помню расскажу.
1. Проигрывались MOD и STM 4-х канальная трекерная музыка.
2. Графика переключалась в двухцветный режим для увеличения ОЗУ под сэмплы.
3. Если ОЗУ все же не хватало сэмплы прощипывались (бралcя каждый второй отсчет)
4. Оба процессора проссчитывали определенные каналы, закрепленные за ними. Точно не помню, но что то типа основной процессор считал 3 канала и периферийный проссчитывал один канал. Один из процессоров так же отправлял сумму всех четырех каналов на Covox и на дисплей в виде осциллограммы.
Точно как было организовано межпроцессорное взаимодействие не помню. Все же 25 лет прошло.

Кстати помню еще делал просмоторщик картинок, позволяющий отображать больше цветов за счет переключения кадров. Т.е. попеременно отображались два разных кадра и цвета из двух кадров визуально смешивались. Правда цвета должны были быть близкими, иначе было заметно мерцание. Плюс к этому конечно манипуляции палитрой.

[MM]

Разрешите проконсультироваться у Гуру звука на БКшке.
Предположим, есть такие аппаратные средства :
1 млн рег-рег
аппаратные целочисленные умножение и деление ( MUL and DIV ), примерно более 50 т. в 1 сек.
56 кбайт ПЗУ с адреса 000000
001000 байт СОЗУ в адресах 170000-170777
4 бит ЦАП на адресе Х.
Регистр клавиатуры - сканы Х и Y, примерно по ~6 сканов.
Можно ли соорудить ЭМИ с хотя бы 4 голосами моно - барабанчик ( TR-707 ), бас ( слэп ), ритм-гитара электро, соло - клавесин какой-нибуть ( ??? ).
По каждому звуку желательно регулировка уровня , не менее 8 значений.
Семплрейт - хотелось бы в районе 20 кгц, но не критично. Точное попадание звуков в частоту нот - не требуется, но хотя бы ~3%....

[Manwe]

аппаратные целочисленные умножение и деление ( MUL and DIV ), примерно более 50 т. в 1 сек.

50 КГц если использовать на одном канале, 25 КГц если использовать на двух каналах. Это прям впритык, высокие частоты на тарелочках TR-707 будут уже придавлены. Придётся мудрить - если нужна не дефолтная громкость ноты, воспроизводить её на специально отведённом канале. А все остальные каналы будут без регулировки громкости.

001000 байт СОЗУ в адресах 170000-170777

ОЗУ - самый больной вопрос. Можно достичь неплохого качества, но тогда память вычерпывается моментально.

4 бит ЦАП на адресе Х.

Это прям lo-fi такой...

Можно ли соорудить ЭМИ с хотя бы 4 голосами моно

Если бы 4 отдельных ЦАПа было и побольше памяти, то можно.

По каждому звуку желательно регулировка уровня, не менее 8 значений.

8 уровней на 4-битном ЦАПе - переизбыток

Точное попадание звуков в частоту нот

Это как раз не проблема, если точно известна частота процессора.

[blackmirror]

А можно узнать в каком виде хранятся звуки и что с ними делает команда умножения?

[konst_st]

А можно узнать в каком виде хранятся звуки и что с ними делает команда умножения?

Звуки хранятся в виде оцифрованной с помощью АЦП с определенной частотой последовательности дискретных отсчетов записываемого звука. Умножение - эквивалент усиления аналогового сигнала. Т.е. умножая отсчеты сэмпла на некоторое число (громкость) можно манипулировать громкостью воспроизведения звука.

- - - Добавлено - - -

Кстати, в некоторых аппаратных FM синтезаторах, что бы не использовать умножения, звуки хранятся в виде нелинейных, экспоненциальных отсчетов. В таком случае умножение можно заменить на сложение - чем больше прибавляемое значение (громкость), тем больше громкость. Но нужна таблица итогового преобразования экспоненциальных отсчетов в линейные.

[blackmirror]

звуки хранятся в виде нелинейных, экспоненциальных отсчетов

так это первая мысль от капитана-очевидность, поэтому и возник вопрос нафига там умножение?!

[konst_st]

так это первая мысль от капитана-очевидность, поэтому и возник вопрос нафига там умножение?!

Думаю, что не все так просто. Во первых, в FM синтезаторах, о которых я упоминал, из звуков хранится только синус. Если же, например в звуке присутствует гармоника (небольшая по амплитуде, то при максимальном уровне основной частоты погрешность в гармонике будет увеличиваться. Этого можно было бы избежать если хранить не отсчеты, а разницу между соседними отсчетами (т.е. первую производную). Кажется ADPCM использовал подобный подход - первая производная в экспоненциальном виде, но могу и ошибаться. В таком виде можно хранить 4-битные отсчеты без значительного ухудшения качества, т.е. прилично сэкономить на памяти. Но здесь возникает проблема если шаг выборки отсчетов при воспроизведении больше 1 - в этом случае нужно все равно последовательно обработать все отсчеты. Так же на таблицу нужна память, на выборку из таблицы тоже уходит время. Не исключаю что в итоге выигрыша может и не быть. Но как вариант рассматривать можно.