BEEP (freq, ms) для бипера, AY и даже Windows

[Oleg N. Cher]

Sergey, очень странный код. А что делает ex (sp),hl после pop af : pop bc? Как по мне, она просто портит значение на стеке, которое располагается до аргументов и адреса возврата. Вы уверены, что так можно? Кстати, а зачем первой же командой во флаговый регистр посылается младший байт адреса возврата? Я слышал краем уха, что так можно, но боялся включить какие-то не те флаги. Только не смейтесь.

---------- Post added at 23:45 ---------- Previous post was at 23:35 ----------

Я к тому, что вот: сделали ex (sp),hl - положили значение hl в стек, а тут прерывание приходит и его портит. Потом мы его восстанавливаем уже некорректным... Я согласен, такое бывает редко. Но метко. Криво как-то написано. Нет? Я что-то не так понял?

[Oleg N. Cher]

Alex Rider, да, благодарю за предложенную помощь, я ограничусь подпрограммой ПЗУ #3B5, в задаче просто хотелось бы избежать расчётов - умножений, делений (они занимают много тактов), но, видимо, не получится. Таблицу тонов не вижу смысла делать - на вход snd подаются абсолютно произвольные значения частоты, а вовсе не частоты нот. К тому же частота на вход snd подаётся не в герцах. Герцы перед подачей в порт #42 спикера ПЦ подвергаются длинному делению: OUT(#42, 1193181 / Hz), а в snd значение fr множится на 6 и пихается в порт. Кстати, в процедуре, которую я привёл выше, есть ошибка, угадайте, какая.

Пока же мои продвижки в этом деле таковы:

PB = порт спикера 42H на IBM PC
Hz = частота звука в Герцах
fr = частота, подаваемая в функцию snd() Bolder Dash
HL = частота, подаваемая на вход подпрограммы ПЗУ #3B5

Расчёт для ПЦ
----------------

PB = 1193181 / Hz
PB = fr * 6
1193181 / Hz = fr * 6
fr * 6 * Hz = 1193181
fr * Hz = 198863.5
Hz = 198863.5 / fr

Расчёт для ZX
----------------

HL = 437500 / Hz - 30.125
HL + 30.125 = 437500 / Hz
Hz * (HL + 30.125) = 437500
Hz = 437500 / (HL + 30.125)

Вывод
-------

437500 / (HL + 30.125) = 198863.5 / fr
437500 * fr = 198863.5 * (HL + 30.125)
HL + 30.125 = (437500 * fr) / 198863.5
HL = (437500 * fr) / 198863.5 - 30.125

Осталось решить ещё вопрос с длительностью, её тоже нужно рассчитывать через умножение, как минимум. Проверьте, пожалуйста, расчёты, если не лень.

[jerri]

Я к тому, что вот: сделали ex (sp),hl - положили значение hl в стек, а тут прерывание приходит и его портит. Потом мы его восстанавливаем уже некорректным... Я согласен, такое бывает редко. Но метко. Криво как-то написано. Нет? Я что-то не так понял?

void beep(char semitone, char len) __naked
{ semitone, len;
__asm
	pop  af
	pop  bc
;	ex  (sp),hl
	push bc
	push af
	push ix
   ld a,b
   ld b,#0
	push bc
;	ld   a,l
	call 11560
	ld   a,#100
	call 11560
	rst 40
	.db 5, 56
	pop bc
	ld  a,c
	and a
	jp  m,1$
	call 11560
	jp 1016
1$:	neg
	call 11560
	rst 40
	.db  27,56
	call  1016
	pop  ix
	ret
__endasm;
}

выделенные ЖЫРНЫМ строки имеют вначале символ ;
что означает комментарий

[Sergey]

выделенные ЖЫРНЫМ строки имеют вначале символ ;
что означает комментарий

Извини, Jerri, - это я позже изменил. Но дело не в том, что было непраильно, - правильно, только под HiTech C.
EX (SP),HL на 2 такта быстрее POP/PUSH.
В данном случае хранить аргументы бессмысленно.
Да и сама команда не нужна: SDCC смежные однобайтные аргументы пакует в слово: 2 аргумента - 1 слово. Хайтек передаёт однобайтный аргумент только словом: 2 аргумента - 2 слова,



---------- Post added at 13:59 ---------- Previous post was at 13:51 ----------

Йо-майо! Если в игре будут использоваться несколько заданных звуков, избежать вычислений ЛЕГКО!
Посчитайте на калькуляторе константы! Далее условная компиляция. Проффит!

[Sergey]

Обновил пост с процедурой. Работа под SDCC протестирована.

Sergey, очень странный код.

Код был заточен под интерфейс Hitech C.

А что делает ex (sp),hl после pop af : pop bc? Как по мне, она просто портит значение на стеке, которое располагается до аргументов и адреса возврата.

обменивает содержимое HL и ячейки по указателю в SP. На 2 такта быстрее (19), чем брать значение через POP, а потом восстанавливать указатель стэка через PUSH (10+11).

Кстати, а зачем первой же командой во флаговый регистр посылается младший байт адреса возврата?

привычка. AF неудобен для снятия и хранения аргументов. Поэтому в него лучше всего сохранять адрес возврата, а аргументы снимать в "нормальные" регистровые пары.

Я к тому, что вот: сделали ex (sp),hl - положили значение hl в стек, а тут прерывание приходит и его портит.

Нам это значение здесь не нужно, тем более, что оно случайно. - нам нужен был аргумент со стэка, - мы его получили.

Я согласен, такое бывает редко. Но метко.

Приходя, прерывание сохранит адрес возврата в следующей ячейке а не в этой. Сначала уменьшается значение SP, а только потом записывается содержимое PC. LD -(SP),PC

[shurik-ua]

Посчитайте на калькуляторе константы! Далее условная компиляция. Проффит!

тоже об этом подумал - ведь все тона какие издаёт программа известны на этапе компиляции - поэтому компилятор и должен чтото там умножать и делить.
Оставьте уже просто вызов бейсиковой подпрограммы и всё.

[Advertiser]

[Oleg N. Cher]

Гм, господа Если бы всё было так просто - я бы и не спрашивал у вас. Ну да ладно. Просто звуки делаются целой серией вызовов snd(), т.е. нужно просчитать не просто два числа, а целую функцию вывести на основе таблиц, притом даже две - одну для частоты, другую для длительности - у #3B5 с этим тоже дела обстоят непросто. Но в общем, думаю, справлюсь.

По тому, что Sergey сказал про Hitech C, добавлю: я разочарован. Здесь его превозносили как идеальный по коду компилятор. Ну да, конечно. SDCC оптимизирует довольно важную вещь - однобайтовые параметры сливает в слово. А Hitech, получается, это не делает. Ай-яй-яй.

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

fn1(2); fn2(2);

ld hl,#2
push hl
call _fn1
call _fn2
pop af

Важно. Не буду утверждать, что такое поведение вообще типично для SDCC, но оно ему иногда свойственно. SDCC может полагаться на эти значения повторно. Если не верите, давайте уточним у Филиппа Краузе. Но я точно помню, что по граблям прыгал.

[Sergey]

По тому, что Sergey сказал про Hitech C, добавлю: я разочарован. Здесь его превозносили как идеальный по коду компилятор. Ну да, конечно. SDCC оптимизирует довольно важную вещь - однобайтовые параметры сливает в слово. А Hitech, получается, это не делает. Ай-яй-яй.

Я бы так не расстраивался Выковыривание аргументов со стека по сравнению с выполнением самой подпрограммы по времени ничтожно. Так что такая передача аргументов на скорострельности процедур не сказывается. Кстати, так делают ВСЕ Си-компиляторы для CP/M или ZX.
Хайтек, не идеален, - но это единственный нативный ANSI-совместимый компилятор. При этом он генерит код существенно плотнее, чем SDCC 3.5.

[Barmaley_m]

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

В каком виде задается высота тона? В виде частоты (Гц) или номера полутона (дробного, в общем случае)?

Преобразование номера полутона в частоту:

f = 440*2^(n/12)

где n - номер полутона, 0 соответствует ля первой октавы (440Гц).

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

Если итоговое выражение будет содержать "неприятные" операции (умножение, деление, возведение в дробную степень) - то можно будет попытаться применить хитрые алгоритмы, например - разложение в ряд, полиномиальная аппроксимация, итерационное деление по Ньютону, умножение путем возведения в квадрат по таблице и т.д.

[Oleg N. Cher]

Высота звука задаётся в виде значения, подаваемого на порт спикера 42H (на IBM PC-железе), перед запихиванием в порт умножаемого на 6. Точнее я вам не скажу.

void snd (unsigned fr, unsigned ln)
{{
 unsigned timing = get_timer ();
 long LN = ln;

 LN *= fr *= 6; // вот тут частота умножается на 6
 // а длительность, заметьте, умножается на частоту, умноженную на 6
 outportb (0x43, 0xB6);
 outportb (0x42, ((unsigned char *)&fr)[0]);
 outportb (0x42, ((unsigned char *)&fr)[1]);

Частоту я почти расколол, формула для первого звука, которая переводит частоту fr в значение HL для процедуры #3B5 выглядит очень просто: (fr+1)*35

С длительностью всё гораздо сложнее. Не пойму зачем Мутель варьирует длительность звука в зависимости от его частоты (умножает на fr*6). Впрочем, может так устроена генерация звука в БК-0010, с которого был перенесён болдердаш? Вот тут я уступлю своим принципам и сделаю на Спеке длительность звуков другую. Упрощу. Впрочем, на слух это не очень заметно, даже, я бы сказал, вообще незаметно.