Кодерский уголок

Спасибо, я посмотрю.

Насчет VBL я ошибся - это не из TB Multisound SDK, а прямо-таки код MIDI-драйвера AIL для TB Multisound Classic. Придется переписывать, наверное, раз это так ненадежно. Игры-то в разных разрешениях бывают.

Впрочем, в самом SDK еще и похлеще написаны задержки. Например, for(int i = 1; i < 20000; i++).

 

Geryon, Да там же нет особо разницы, подождать X миллисекунд, или подождать X*1.2 миллисекунд, так что не сильно важно.

Все равно, от нечего делать написал реализацию:

Код:

sysex_wait      PROC Delay             ;Delay after System Exclusive message
                USES ds, ax, cx, bx    ;transmissions
                ; will only work with standard IRQ 0 handler, when interrupts are NOT disabled

                mov ax, 40h             
                mov ds, ax              
                mov bx, 6Ch            ; Load BIOS Timer pointer

                mov ax, [Delay]        ; Load 14 ms delay factor
                mov cx, ax             ; Get count = (3 * x + 1)/4 
                add ax, ax
                inc ax
                add cx, ax
                shr cx, 2

                jcxz __exit            ; Exit immediately if Delay was 0
                inc cx                 ; First period may be < 18.2, so add 1
__sync_1:       mov al, [bx]
__sync_2:       cmp [bx], al
                jz __sync_2            ; Wait for next 18.2 period
                loop __sync_1
__exit:         ret
                ENDP

Только у меня сомнения, что код, играющий MIDI, не трогает таймер, или что этого не делает любая игра, использующая драйвер.

 

Есть ещё забавный способ - вешаться на прерывание от COM-порта по готовности данных, программировать его на передачу и из обработчика прерывания передавать следующий байт. Был описан в журнале "Index PRO". Я на этом способе сделал замедлитель компьютера, выжимал частоту прерываний около 8 килогерц и, соответственно, получал вполне себе плавную работу при более-менее 200-кратном замедлении.

 

Рыжий Тигра, Отличная идея, уж COM-порт-то можно свободный найти! Но богатство выбора задержек не ахти

 

Пхе, элементарно, Ватсон! Минимальная - чуть больше сотни мкс; можно играть скоростью порта, кол-вом битиков (чётность и стоп-биты) - этим меняешь частоту IRQ и задержка немного растёт; а ещё ж можно маневрировать кратностью срабатывания - реагировать на каждое N-е прерывание.
Наконец, можно использовать furrball (или fuzzball, точно не помню) - порт на каждом тике перепрограммировать: давать то такие параметры, то этакие. В результате средняя частота IRQ может меняться вообще плавно.
В оригинале статьи от порта синхронизировался то ли ковокс, то ли вообще спикер, там была проблема задрать частоту ещё выше. Не помню чем кончилось. :-(

PS. Кстати, эту же фишку можно применить ещё для двух вещей - профилирования и анализа покрытия кода. Обработчик прерывания должен фиксировать место в проге, которую прервал, а после прогона останется только обработать накопленную статистику.

 

Это уже многовато. PIT позволяет от 2-3 сделать, по-моему(теоретически, если процессор позволит). Я лично делал около 50-60 на 386 без проблем и вроде оставался запас. Кроме того, можно ли, имея необходимость, создать точную произвольную задержку в пределах 5..1000000 мкс не городя огорода? Это ведь именно то, что нужно в "правильном" сидплеере и тому подобных вещах. Конечно, на практике выше крыши хватит меньшей точности, но всё таки!

 

Круто! Только я думаю, что трогает

Как быть в этом случае?

 

Geryon, Оставить тот, что был, я ж написал Подумаешь, в режиме 640x480 задержки в 7/6 удлинятся, или без видюшки повиснет...
Но вообще, по досом всё зависит от того, с каким другим кодом этому придется делить ресурсы.
Если это драйвер, играющий MIDI, то он в любом случае должен быть завязан на какой-то надежный таймер, для проигрывания нот вовремя. Может, это обычный системный, но временно установленный на другую частоту, может, это таймер, предоставляемый звуковой картой. Вот к нему-то и надо привязаться.

 

Я проверил: там ужас-ужас-ужас! Библиотека поддерживает до 16 драйверов одновременно, и каждому может быть назначен отдельный таймер, а стандартный обработчик заменяется целым менеджером таймеров.

Код:

hook_timer_process PROC                 ;Take over default BIOS INT 8 handler
                USES ds,si,di

                pushf
                cli
                
                mov ax,0                ;get current INT 8 vector and save it
                mov es,ax               ;as reserved timer function (stopped)
                mov bx,es:[(8*4)]
                mov es,es:[(8*4)+2]

                mov WORD PTR bios_callback,bx
                mov WORD PTR bios_callback+2,es

                mov bx,OFFSET bios_caller
                mov WORD PTR timer_callback[BIOS_H*4],bx
                mov WORD PTR timer_callback[BIOS_H*4]+2,cs

                IF USE_INT8

                mov ax,cs
                mov ds,ax
                mov dx,OFFSET API_timer

                mov ax,0                ;replace default handler with API task
                mov es,ax               ;manager
                mov es:[(8*4)],dx
                mov es:[(8*4)+2],ds

                ELSE

                call RTC_set_freq C,RTC_FREQ_BITS
                call RTC_enable
                call RTC_install

                ENDIF

                POP_F
                ret
                ENDP

 

1.19 МГц (точнее частоту не помню), но задолбательская процедура его программирования. :-(

Увы: регенерация памяти будет путаться под ногами, от неё многие десятки микросекунд (а по писимисиським данным - и под миллисекунду) недоступности шины. :-(
Вторая фишка - время на открытие аппаратной страницы памяти, тоже ЕМНИП сколько-то сотен микросекунд от обращения до результата. Исходники тестера видел у Мыщъха в, если не ошибаюсь, "Тайнах оптимизации программ".
Впрочем, можно навскидку померять руками: прицепить обычный аналоговый джойстик (а ещё - вместо него пару постоянных резюков по 50 кОм), запустить простенькую программку с циклом опроса джойстика и посмотреть, как будут трепыхаться счётчики. Последний раз мерял на своём Celeron Northwood, когда покупал, - наблюдал болтанку в 10-15%. :-(

---------- Сообщение добавлено в 00:06 ---------- Предыдущее сообщение размещено в 00:04 ----------

Кстати, в таких условиях чем COM-порт лучше таймера - не будет потери прерываний. Стабильность частоты-то подплывёт хоть так хоть этак... :-(

 

Geryon, Да все ок. Частота вызова обработчика ведь константная, как я вижу. 14318180/12/RTC_FREQ_BITS. Может он даже пытается тот счетчик по адресу 0040:006C все равно инкрементировать, или свой крутит. Вот его и проверяем для задержки. Или добавляем свой код для того же.

---------- Сообщение добавлено в 01:25 ---------- Предыдущее сообщение размещено в 01:20 ----------

Бывает и хуже Нормально еще.

Ну COM-порт хуже уже хотя бы тем, что никто не обязан его для тебя разрешать в биосе, или оставлять неиспользуемым .
И, кстати, любое аппаратное прерывание - ж вроде ожидает в очереди, пока не обработано, нет?

Ну, это наверное только в защищенном режиме, да еще и под виндовсом, ИМХО. Не должно быть столько для доступа к физической памяти. Сотни наносекунд - поверю. А если и будет, то это разовая ситуация, потом главное - в кэше.

 

Тем не менее. :-( Там какая-то байда с перепрограммированием коммутатора старших-младших адресных линий, насколько помню. А чипсет i845PE позволяет держать одновременно открытыми где-то аж 32 физ-страницы (это по 32 и ли 64 КБ, точнее не скажу).
Я на эти грабли напарывался, когда отлаживал БПФ: при увеличении размера обрабатываетмого массива от мега до 16 мег время обработки растёт не в 64 раза, как по O( N * log(N) ), а в десятки тысяч раз, а порог, за которым начинается резкий рост, как раз 2 то ли 4 МБ, т.е. на порядок больше размера кэша.

(фыркает) А самостоятельно, руками и головой! Жопоподтирательные машинки в сельпо почему-то не завезли... :-(
А с другой стороны, порт нужен кому или нет - легко выяснить, а наточить зубы на таймер желающие всегда найдутся. В том же WC1 таймер перепрограммируется на 60 тик/с, int 9 напрямую забирается игрой, ещё какие-то трюки в том же духе...

Насколько помню - пока не взято на обслуживание; если приходит больше одного по одному IRQ - остальные теряются. А от COM-порта в описанной схеме больше одного прерывания одновременно быть не может в принципе.

ЗЫ. Кстати, вот эта книга: http://rutracker.org/forum/viewtopic.php?t=4515536 Крис Касперски "Техника оптимизации программ".

 

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

 

Угу, особенно если нужно нестандартное поверх чужого не менее нестандартного. :-(

 

Рыжий Тигра, ну, когда то такая фишка была использована в небезызвестном в узких кругах FreeGame. А винда и вообще сплошняком по этому принципу работает, используя механизм предсказания следующей ошибки по причине гениальности очередного изобретателя велосипедов (а что ж тут поделаешь то ?! Изобретать велосипед и дарить его людям - любимое занятие гениальных программистов, которым нравится пользовать хаки и фичи вместо RTFM). И, что интересно - работает прям таки отлично в отличии от линукса, который упорно не понимает как в системе может быть 1E99 компортов, которые постоянно посылают друг в друга данные, все живут с одной иркой и при этом она ещё и успевает их всех обслужить !

 

:-))))))))))))))))))))))))))))

 

Тут у тебя очень темное дело на самом деле. Что я точно знаю, у обычной DRAM время случайного доступа должно быть ну в разы, но не на порядки хуже, то есть по прежнему в области наносекунд. Проблема с доступом к огромным массивам - это скорее всего cache-line aliasing - патологически неэффективное использование кэша, если совпадает какое-то количество младших битов у одновременно используемых адресов. Сходные проблемы на уровне материнки - это что-то новое для меня, пока не уверен, что отфильтрованы уже известные проблемы с кэш-подсистемой и TLB процессора, сходу верить не стану
А КрЫс - товарищ, конечно, интересный и достаточно компетентный, но я бы не стал верить его измышлениям на 100%.
Кстати, а где саму книгу-то скачать?


---------- Сообщение добавлено в 13:21 ---------- Предыдущее сообщение размещено в 13:18 ----------

Ну-ка поподробнее про этот волшебный метод! Как он делается, и чего позволяет добиться?

 

и правильно сделаешь. Ибо по каким то маркетинговым соображениям он всегда начинает "за здравие", а уже к середине уползает именно в "измышления" и "мыслью по древу", после чего заканчивает всё ... хм. Не заканчивает ничем по сути.

я бы и рад, но, учитывая нехилый объём сего экскурса, не умнее ли будет погуглить документацию, благо всё отлично уже описано ? А кратко - всё. Полный контроль.

Да и тема таймера себя не исчерпала ещё ибо, если его оставить как его BIOS установил - он будет вызывать прерывание раз в 55ms.
Но это канал 0. А нафига нам канал 0 трогать ? Пусть тикает себе часами для системы. Есть же ещё каналы 1 и 2. Ну второй задействован под пищалку. А вот 1 на AT совершенно свободен (на XT использовался для регенерации RAM). Можно его использовать для своих целей.
А кварц таймера тикает примерно с длительностью одного периода в 0.840336 мкс. Что как бэ является самым высоким разрешением для таймера вообще.

В общем тоже смотрите доки по 8254 ибо тоже нехило инфы.

 

Ё-пс, я не всмотрелся и выдал первое нагугленное.
Текст книги в HTML навскидку нагуглился на ситфоруме http://citforum.ru/book/optimize/ - не знаю, насколько полный. Я пользовался .djvu - года два или три назад нарыл, лови во вложении.
Но сам я его тесты не гонял - некогда было, "гнали продукт" и дедлайн поджимал. :-( А потом руки так и не дошли.

 

Первое попавшееся подтвердилось и нам крупно помогло. Так что. :-