Почему вроде бы, простейший код приводит к зависанию таймера? Ведь по докам всё сходится - я всего-то перепрограммирую канал 0, чтобы IRQ0 генерировалось с частотой 1193180 герц! Причем результат не зависит от делителя - даже если писать 65535, всё равно зависнет! Код (Text): org 100h mov al,30h out 43h,al mov al,1 out 40h,al mov al,0 out 40h,al retn
Вы ставите счетчику режим 0, чтобы счётчик сам перезагружался, т.е. работал как генератор меандра, что и необходимо для вызова IRQ0, надо поставить его в режим 3. Не забудьте, что после перепрограмирования нарушится работа флоппиков и скорость хода часов, а может быть и с хардами возникнут пробл деелитель чаемы, то есть перепрограмируют его только на время работы программы, а потом опять ставят коэф. счёта =0 (то есть 65536). Зы могу запостить подробную доку по таймеру
10110111 приветик! Ну вот тебе код из моей ос... вылизано и тестено вдоль и поперек Код (Text): SetAXdelayTimer: pushf push ax mov al, 0x34 ; выбрать счетчик 0, шестнадцатеричный счет, загрузить младший байт, затем старший cli ; запрет прерывания на время настройки таймера out 0x43, al pop ax out 0x40, al ; младший байт mov al, ah out 0x40, al ; старший байт popf RET
VaStaNi Да, спс, я это уже нашёл. Моя ошибка была, как и указал Vov4ick, в режиме таймера. Vov4ick Работа устройств типа флоппика ведется с использованием данных из BIOS Data Area, а не сигналов таймера как таковых, правильно я понял?
Правильно, но там они берутся практически из таймера - обработчик int8 каждый раз (55 мсек) делает инкремент DWORD'а на 40h:6ch и декремент времени работы мотора дисковода на 40h:40h. Cчётчик тиков 40h:6ch используется и при работе с НЖМД для ожидания готовности, для формирования задержек, короче очень много где используется.
Насчет этого не знал, спасибо, учту... То есть достаточно с необходимой частотой вызывать старый ISR, и всё будет работать по-прежнему верно, независимо от частоты таймера?
Да. Это про нулевой его канал, выход которого заведён на IRQ0. А зачем перепрограммировать таймер надолго? По-моему вызов IRQ0 с частотой ~1,2 МГц приведёт к очень заметным тормозам системы.Если его обработчик будет выполнятся больше 2000 тактов, то 2,4 ГГц система зависнет тут же от переполнения стека, не говоря уж о более медленных машинах.
Мне не особо понравится, если частота смены контекста будет 18.206481 раза в секунду... Неужели все оси используют эту частоту? По-моему, сменяется контекст гораздо чаще... похоже, я ошибаюсь?
А зачем нужна смена чего-либо со столь стабильной частотой? Все "многозадачные" ОС (окна, пингвины и др.) меняют так часто, как могут, либо ограничивают частоту обновления выделением процессорного времени. по-моему так. А такое постоянство возможно только в DOS.
10110111 да, ты совершенно прав 18 раз в сек это игрушки и для игрушечно-демонстративного написания и как пример пойдет, но... НО для действительно продуманных многозадачных систем, да еще и вытеснения по приоритетам, да еще если проектирование позиционируется на(как) RTOS, то тут масса методов, идей, решений и лучше изучить их перед тем как... Рекомендую твоему вниманию UzhOS: статьи и посты его генерала - Сергея Семанина, как лучшее отечественное решение(направление) в этом вопросе. Проштудируй это: http://board.sysbin.com/viewtopic.php?t=319 http://board.sysbin.com/viewtopic.php?t=249 http://www.uzhos.tk/ А вообще не дури все равно ведь придешь к тому, что сообща в этом(таких) деле больше толку. Разве что хорошая лабораторная работа это твой максимум в devOS и всё.
С одной стороны это так, если иметь ввиду скорость разработки... но мне надо знать точно, что делает и как работает моя ОСь, а это будет затруднено при работе сообща(в смысле, если код будет писан многими людьми). Ну почему же максимум На свете столько ОСей, что изучая их, можно компоновать самые лучшие решения и интегрировать в свою ОСь... правда решений этих столько, что одному с ними надо будет долго возиться . Тем более, если будет включена поддержка Win32 API и подобных прослоек, такая ОСь может быть намного большим, чем лабораторной работой. P.S. А за ссылки THX
