Реальная ОСь :-)
Удручает, что все новоделы печально безлики и бесталанны - все пишется на ассемблере эффективности ради (якобы), декларируются набившие оскомину трюизмы - как то микроядро, обмен сообщениями, журналируемая файловая система и тому подобные вещи, а на деле редко кто пробивается дальше выхода в защищенный режим на основе содранного где-то кода.
Ну да ладно. Не буду о грустном - сам такой :-)
Предлагаю на суд общественности очередной релиз своей idee fixe - операционки Idioma версии 0.0-01. Скачать ее можно по адресу:
http://www.sourceforge.net/projects/idioma
Там Вы найдете исходники системы, а также образ загрузочного диска - open source, естественно.
Данная версия компилится (а главное - работает) как из-под DOS (DJGPP), так и из под Linux (gcc), что я считаю большим достижением.
Кроме того, в ней появилась поддержка прерываний (пока таймер и клавиатура), операторы new и delete для объектно-ориентированного программирования, а тексты и каталоги стали более структурированными для большей ясности.
В-общем, параллельно я читаю "Just for Fun" (в третий раз :-) и изучаю исходники его ядра 0.01, надеюсь, что через полгодика-годик доберусь до этой функциональности.
Всем Успехов!
Смотрю, людей, жаждущих написать собственную ОСь, здесь становится все больше и больше. Нда, неоднозначное явление... Но "все к лучшему в этом лучшем из возможных миров" (c) :-)
Предлагаю свой вариант. Буду оригинальным --- пишеться OS на Delphi, есть загрузчик, переход в защищенный режим, таймер/клавиатура (в защищенном режиме), качать
здесь. Все планирую подкинуть менеджер памяти.
Предлагаю свой вариант.
Я бы сказал - в общем и целом - весьма неплохо, самое главное - ЭТО работает, в отличие от многих и многих сотрясений воздуха, которые я здесь периодически наблюдаю - а я могу с полной уверенностью заявить, что стал участвовать в работе форума практически с момента его основания.
Больше всего мне понравилось структурирование исходников - явно чувствуется стиль программирования. Правда, я не поклонник Паскаля и uppercase-листингов, так что не все однозначно ;-)
Ну что - удачи в работе, тем более что мы даже и не конкуренты - ты пишешь на Паскале, я на С++, твои исходники несколько догматичны, а я все дальше и дальше ухожу от академизма после защиты диссера в универе...
А я вот драйвер для IDE-жёстких дисков пишу.
Дело толковое, тем более, что с появлением Инета и огромного выбора книг это из неблагодарного корпения над исходниками все больше и больше превращается в удовольствие для "истинного" программера -> хакера -> жика, в зависимости от степени запущенности :-)
Таймер с клавиатурой в моей ОС вроде уже имеются. А появились они у меня где-то года 1,5 назад...
Ты не поверишь - у меня более двух лет назад. Но - в реальном режиме. Сейчас операционку приходится писать заново под PM и GCC - ориентируйся я на них в то время, я бы сэкономил много напрасного труда.
И что ты имеешь против журналируемых фаловых систем? Мне, между прочим, они нравяться отнюдь не своими High Perfomance качествами (хотя я, вообще-то, конкретно о ReiserFS говорил), а именно совершенством логики их алгоритмической реализации на основе балансируемых древовидных структур данных (я вообще фанатик алгоритмики и аппаратной части ПК, всё, что "по середине" меня меньше интересует)
Ничего против, я только - за :-)
Я против того, что здесь периодически появляются пустомели, которые заводят пустопорожние разговоры о том, что надо писать SuperPuperOS, которая не будет глючить, а работать будет с ошеломительной производительностью... а на деле выясняется, что новоявленные Торвальдсы не знают, чем компилятор от компоновщика отличается ;-)
P.S: Естественно, это не про тебя сказано. Ты создаешь впечатление человека, который знает, о чем говорит.
Правда, я не поклонник Паскаля и uppercase-листингов, так что не все однозначно ;-)
Фактически я начал работать над этим после многочисленных наездов, что на Delphi нельзя написать ОС. Дошел до того момента, когда стало ясно, что можно --- и остановился. Сомневаюсь, что когда-то продолжу --- есть работа, на хобби уходит все меньше и менбше времени... Так что проект стоит больше года.
Фактически я начал работать над этим после многочисленных наездов, что на Delphi нельзя написать ОС. Дошел до того момента, когда стало ясно, что можно --- и остановился. Сомневаюсь, что когда-то продолжу --- есть работа, на хобби уходит все меньше и менбше времени... Так что проект стоит больше года.
Delphi - это Object Pascal + IDE + VCL. То есть визуальная среда разработки, компилятор языка Object Pascal и библиотека классов для быстрого создания графического интерфейса пользователя. Из всего вышеуказанного ты использовал только компилятор, а это лишь малая часть, так что говорить "пишу на Delphi" - как-то некорректно :-)
Писать на Паскале, а тем более объектном, операционки - можно. Собственно, именно так и создана MacOS :-)
А то, что проект забрасывается после написания загрузчика, перехода в защищенный режим и обработки пары прерываний - это нормально. Потом появляется работа-семья-заботы, и вообще, интересы меняются - типичный путь развития программиста как личности :-)
1) Delphi - это Object Pascal + IDE + VCL.
2) А то, что проект забрасывается после написания загрузчика, перехода в защищенный режим и обработки пары прерываний - это нормально. Потом появляется работа-семья-заботы, и вообще, интересы меняются - типичный путь развития программиста как личности :-)
1) Delphi это уже и язык программирования (если верить Inprise). Они его переименовали из Object Pascal в Delphi
2) Если честно, то даже не проект (начинал, когда мне было уже 26). Просто было желание вспомнить молодость, и если не программировать в RING 0, то о чем потом рассказать детям?
дай асю и мыло.. + регся тута http://board.sysbin.com
прикольный тип.. раньше я о тебе не слыхал ;)
дай асю и мыло.. + регся тута http://board.sysbin.com
Фелиск, ну что ты всех агитируешь ходить на свой форум? Честно тебе говорю - даже если ты его раскрутишь, толка от этого не будет никакого. Знаю по собственному опыту, сам раньше старался на свои проекты людей заманивать ;-)
У тебя цель-то какая? Ось написать? Ну так и пиши ее - гораздо более благодарный труд, уверяю! Я сам за собой замечаю, что часто время трачу впустую, гуляя по группам в Гугле, или по интересным сайтам, или изучая исходники. Делать надо больше, а не в форумы писать!
P.S: Естественно, ты спросишь - а что же я здесь делаю? Заразно это - учить людей уму-разуму ;-)
я люблю понтоваться и скажу - у мя их дохера =)
-Я ща спаммерский тулкит пишу, именно граббер мыл...
-Также ось..
-И создал приватную группу по изучению сорцов винды,
-но и между тем ппытаюсь превратить сусбинскю борду в ресурс
гЫ..гЫ.. как то дохло звучит, но еще че нить придумаю ;)
>У тебя цель-то какая?
я люблю понтоваться и скажу - у мя их дохера =)
-Я ща спаммерский тулкит пишу, именно граббер мыл...
-Также ось..
-И создал приватную группу по изучению сорцов винды,
-но и между тем ппытаюсь превратить сусбинскю борду в ресурс
гЫ..гЫ.. как то дохло звучит, но еще че нить придумаю ;)
А что там с книгой по Ассемблеру? Ты бы наконец дописал хотя бы одну полную главу (какие-то они у тебя сейчас куцые уж больно), а я б тебе в плане коррекции орфографии и пунктуацией с оригинальных на правилами русского языка определяемые помог бы. Нет, серьёзно, а то у тебя её, эту книгу, даже за большие деньги не то что издательство - ни одна типография печатать не примет (а всё-таки твоё "тех. издание" в своём первом "окончательном варианте" на бумаге хотелось бы видеть, да не на самиздатовской туалетной, а на нормальной белёной, "не просохшей ещё" от свеженанесёной типографской краски) Идеалист я, понимаешь...
куцые..хыхы.. знаешь как характеризуется тех идание? поверь это не тоже смое что самоучитель - шде тебе суют свои мысли и рассуждения.. а это не более 90 листов формата А4, минимум примеров, тока объяснение главных механизмов, не своими рассуждениями а на уровне так есть, потому что так, и неподругому... а про издание.. я его продовать небуду, отправлю <<в радио и связь>>, а там глюнь да и бестселлером станет - как говорят мать науку надо нахуй слать, понял по каким правилпм играет x86, а дальше сам придумывай свои стратегии... Знаешь почему Финогенов стал бестселлором? там в 150 страницах мелкого формата объясняется весьмеханизм x86...
Гм, ну, предположим, та же книга М.Гука "Аппаратные интерфейсы PC" вполне "вписывается" в определение понятия тех. издания, данное тобой, но книгу Гука читать "легко и приятно", а твою брошюру - так через каждое слово спотыкаешься. То орфография какая-то экстраординарная, то пунктуация... отсутствует напрочь, то стилистика хромает (ну т.е предложения корявые, из-за, к примеру, несогласованности падежных окончаний). Так что, может, ещё и пригожусь тебе в качестве корректора... Как думаешь? ;)
Так что, может, ещё и пригожусь тебе в качестве корректора... Как думаешь? ;)
пригодишься то и не как корректор, тока вот аси твоей у мя нет :x
Послушай, SerGO, у тебя перекодировщик скан-кодов клавы по принципу конечного автомата построен? А то у меня перекодировщик какой-то уж больно заковыристый получился (тем паче, я раньше всё ж таки похуже опытом алгоритмического "совершенствования" обладал, поэтому как-то не подумал сразу всё по-человечески сделать), и сейчас уже просто задолбался его переписывать под все наборы скан-кодов (их ведь 3!). Может, посоветуешь чего-нибудь...
Конечно, посоветую ;-)
Зачем использовать конечные автоматы там, где они не нужны? У меня перекодировщик, наоборот - слишком пока примитивный, потому-что иной сейчас и не нужен, но кодируется все примерно так:
- создаются два массива ~100 членов по числу клавиш
- в зависимости от того, в каком регистре работаем (CapsLock) и состояния клавиши Shift, обращаемся к тому или иному массиву (строчные-прописные буквы)
- поддержка второго языка включается добавлением еще пары массивов по ~100 членов
Если утрировать, то: Char:=CharArray[Language][Caps][ScanCode] примерно так :-)
Конечно, посоветую ;-)
Зачем использовать конечные автоматы там, где они не нужны? У меня перекодировщик, наоборот - слишком пока примитивный, потому-что иной сейчас и не нужен, но кодируется все примерно так:
- создаются два массива ~100 членов по числу клавиш
- в зависимости от того, в каком регистре работаем (CapsLock) и состояния клавиши Shift, обращаемся к тому или иному массиву (строчные-прописные буквы)
- поддержка второго языка включается добавлением еще пары массивов по ~100 членов
Если утрировать, то: Char:=CharArray[Language][Caps][ScanCode] примерно так :-)
Если бы всё было столь просто и очевидно...
А как же быть со скан-последовательностями на E0h, принимая которые необходимо ещё и просеивать псевдо-нажатия Shift (коды 2Ah и AAh). Скан-последовательность, генерируемая клавишей PAUSE - вообще просто песня: одновременно генерируется и скан-код её нажатия, и код отпускания (признак такой "оригинальности" клавиши - байт 0E1h посылается перед обоими кодами (и нажатия, и отпускания)). Получается такая sequence: E1 1D 45 E1 9D C5. Скан последовательность нажатия PAUSE у меня как раз и отрабатывается конечным автоматом в чистом виде (я, правда, пока ещё не очень понимаю, надо ли reset'ить клавиатуру при обнаружении обрыва цепочки или можно просто вернуть драйвер в состояние приёма первого (возможно, и последнего, если это - не E0h и не E1h)байта скан-последовательности). Вообще для драйвера клавиатуры, обрабатывающего коды из набора ScanCodes1 (контроллер клавиатуры по умолчанию перекодирует последовательности ScanCodes2 и ScanCodes3, посылаемые всеми современными клавиатурами "на выход", в "переработанные и дополненные" XT-совместимые скан-коды ScanCodes1, но при желании трансляцию скан-кодов контроллером i8042 можно и отключить), достаточно простенького конечного автомата наподобие:
State0 - готовы к приёму 1-го байта последовательности
Дуги: Если первый байт - E0h -> State1
Иначе если первый байт - E1h -> State2
Иначе -> State0
(процедуры перекодировки "подвешиваются" непосредственно к дугам)
State1 - готовы к приёму 2-го байта E0-последовательности
Дуги: Если 2-й байт принадлежит к числу допустимых для E0-последовательностей -> State0 (при равенстве байта and 7Fh коду Shift'а 2Ah - nothing to do, сразу возвращаемся в State0, иначе - перекодируем полученное в собственый формат)
Иначе (либо сбой, либо клавиатура принадлежит к очередному "поколению next")... -> не знаю, что и предпринять-то, подскажете, может быть что-нибудь, буду оч. благодарен! Скорее всего из-за того, что сбой синхронизации в даннои случае менее вероятен, чем то, что мы имеем дело с какой-то бонус-супер-пупер мультимедийной клавишей, о существовании которой может подозревать только драйвер непосредственно от vendor'а (кстати, здесь как раз и встречаются случаи, когда драйвер работает в режиме отключенной трансляции в ScanCodes1), будет логичнее просто сформировать "Unknown key" с занесением "загадочного" кода в первый байт формируемого сообщения драйвера клавиатуры. -> State0
State2 Готовы к приёму 2-го байта E1-последовательности
Дуги: Если принят код 1Dh -> State3
Иначе -> State7 (сбой синхронизации, скорее всего)
State3 Готовы к приёму 3-го байта E1-последовательности
Дуги: Если принят код 45h -> State4
Иначе -> State7
State4 Готовы к приёму 4-го байта E1-последовательности
Дуги: Если принят код E1h -> State5
Иначе -> State7
State5 Готовы к приёму 5-го байта E1-последовательности
Дуги: Если принят код 9Dh -> State6
Иначе -> State7
State6 Готовы к приёму 6-го байта E1-последовательности
Дуги: Если принят код C5h -> State0
Иначе -> State7
Перекодировка полученных скан-последовательностей на различных дугах - вообще отдельная тема разговора. Но пока жду определённых советов и соображений по поводу вышеизложенного... Спасибо!
P.S. Какая может интересная дискуссия получится! (можно даже отдельный топик создать - я, правда, один раз уже пробовал тему "Драйвер мыши на основе конечного автомата" открыть - но никто там так и не объявился, к сожалению)
на форуме http://board.sysbin.com в ветке lowlevel coding вы найдете подробные статьи по работе с хардом, один из примеров работа с клавой ;)
Почему бы не использовать E0, и E1 как префиксы размера пакета, соответственно 1 и 2 байта. Ну а присловутая "Pause/Break" - отдыхает, драйвер будет разделять ее скан код на 2("Нажали", "Отпустили"), что очень удобно, унификация так сказать, а то что клава посылает их вместе - ее проблема. Кстати, данный алгоритм используется в NOXY OS с самого ее рождения.
Сия хитрозадость(с конечным автоматом) конечно имеет право на существование, но в данном случае с драйвером клавы существует более изящное решение, которое пришло мне в голову как только я увидел последовательности, генерируемые клавой.
Почему бы не использовать E0, и E1 как префиксы размера пакета, соответственно 1 и 2 байта. Ну а присловутая "Pause/Break" - отдыхает, драйвер будет разделять ее скан код на 2("Нажали", "Отпустили"), что очень удобно, унификация так сказать, а то что клава посылает их вместе - ее проблема. Кстати, данный алгоритм используется в NOXY OS с самого ее рождения.
Странный у тебя жаргон. Тут вроде кроме тебя никто не пользуется нецензурной лексикой. Это что, способ самовыражения такой? Ладно, "не извиняйся", тут уж все привыкли к твоему, с позволения сказать, стилю общения..., а если по существу, то:
>Почему бы не использовать E0, и E1 как префиксы размера >пакета, соответственно 1 и 2 байта.
Я не об этом, собственно, говорил. Проблема, по моему в том,
как вообще обработчик прерывания узнаёт о том, что в данный момент он должен принять очередной байт последовательности (ведь каждый код последовательности - это отдельный запрос прерывания). По-моему, самым логичным решением здесь и является использование конечного автомата, который "помнит" только своё состояние, в котором находился между двумя последовательными вызовами. Соответственно, не нужно хранить большое количество переменных со всякими флагами и указателями "головы" очереди, не нужно вставлять в код команды условного перехода в большом количестве - каждое состояние автомата изолировано от всех остальных и уже "нагружено" собственной логикой (собственно, и характеризующей данное конкретное состояние).
Насчёт NOXY OS ничего не знаю (где ты их только откапываешь?), а вот в IBM'овской OS/2 драйверы представляют собой один большой Switch конечного автомата - там в IBM не даром инженеры сидят за столами с табличками, призывающими "интенсивнее думать".
P.S. Заходите, кстати, почаще на сайт, пропагандирующий в массах идею "Россия - Родина слонов"
Практически мой дом родной... (А CodeNet - место службы :-)))
У меня в программе должны индикаторы на клаве мигать. Делаю это так.
cli
mov ecx,0f999h
ccc2:
in al,64h
test al,2h
loopnz ccc2
mov al,0edh
out 60h,al
mov ecx,0f999h
ccc:
in al,64h
test al,2h
loopnz ccc
mov al,bl
and al,7h
out 60h,al
sti
Но после выполнения этого участка кода у меня генерируется прерывание IRQ1. В обработчике прерывания in al,60h кажет 0FAh. Вроде даже два прерывания подряд. А почему? Может ошибка в коде? В каких случаях клавиатура генерирует прерывание?
Вообще то я так же имел ввиду что пакет начинается всегда с этого префикса(E0, E1) и имеет длину 1 или 2 байта соответственно. Вот и надо ждать префикса - это НАЧАЛО да и конец становится известен.
Но тебе, по видимому, приходиться организовывать буфер для временного хранения хотя бы одного промежуточного байта, а для того, чтобы клавиатурный handler не въезжал слишком долго в ситуацию, этот буфер должен быть длиной 2 байта (универсальный т.е) при чём к тому же не обойтись без счётчика, по обнулению которого можно судить о том, что вся последовательность принята, да ещё и количество ожидаемых байт должно сохраняться отдельно, чтобы при обнулённом счётчике можно было переключаться на код, идентифицирующий скан-последовательности той или иной длины
(т.е делать Switch SC_SequenceLength
0: Простые скан-коды
sub префикс-байт, E0h
cmp префикс-байт, 1
setbe ПризнакРасширенногоКода (ПРК=0/1)
Конвертим во внутренний формат...
1: Дополнительный код, длина ПРК SHL 0 (E0)
Конвертим во внутренний формат...
2: Дополнительный код, длина ПРК SHL 1 (E1)
Конвертим во внутренний формат...
)
У меня код, связанный непосредственно с переключением состояний конечного автомата буквально на 3-х строчках умещается...
Вопрос: получили мы скан-последовательность вот такую: E1 1D 45 1A 14 23 ... (к примеру :-) ), и что, мы её "проглотим" , посчитав, что нажатие одновременно Pause и ещё трёх букв - вполне нормальное явление? Мой конечный автомат подобные сбои отслеживает чётко (и не только связанные со сбоем приёма 6-ти байтовой последовательности идентификации клавиши Pause...) А как у тебя с этим дело обстоит?
Да и всё-таки, зачем проявлять чудеса универсального подхода к приёму последовательностей скан-кодов, если код на E1 всего один-единственный существует, являясь лишь досадным (вообще-то, я бы назвал такие причуды разработчиков контроллера i8042 маразмом) исключением из общего правила, заключающегося в том, что существуют лишь XT-совместимые однобайтовые скан-коды и расширенные двухбайтовые коды (без учёта мусора E0 2A и E0 AA, наличие/отсутствие которого в определённых последоваительностях, как я выяснил, зависит непосредственно от реализации микропрограммы клона i8042 на разных "матерях") для клавиш современных (> 84)-х клавишных клавиатур, нажатие на которые заменяет одновременное нажатие и удержание нескольких клавиш XT-keyboard'а.
;Формат кода клавиши, перекодируемого конечным автоматом из скан-последовательности,
;полученной от контроллера i8042.
;биты назначение
;
;0..7 Индекс клавиши внутри группы/код подгруппы
; Старшие биты этого байта могут использоваться как расширение
; идентификатора группы - т.е код подгруппы (очевидно, что во многих
; группах клавиш б`ольшая часть из 8 битов не будет использована
; под индекс клавиши внутри группы)
;8..A Индекс (идентификатор) группы, к которой принадлежит клавиша
;B Признак использования дополнительной (цифровой) клавиатуры.
;C..17 Флаги клавиш переключателей и модификаторов, нажатых одновременно с данной клавишей
;18..1D Сч„тчик автоповтора (накопительный сч„тчик) - соответственно, автоповторяться можно
; не более 64 раз-дальше коды нажатия этой клавиши будут игнорироваться.
; Проблемы с автоповтором возникают чаще всего из-за медлительности получателя
; клавиатурных сообщений - умная операционная система в случае переполнения
; счётчика автоповтора или буфера "промежуточного хранения" кодов клавиш
; должна временно повысить приоритет "задумчивого" потока до максимального
; уровня.
;1E Признак неопознанного (Unknown) scan-кода
;1F Признак кода отпускания клавиши (знаковый разряд двойного слова).
Есть возражения? Предложения? Что ещё в ассортименте? Всё сюда извольте выкладывать-не пытайтесь утаить шило в мешке, гм, у нас длинные руки... :-)) (что-то на меня сегодня лёгкое помешательство нашло...)
Проблемы с отображением буковки "ё" в cp1251? Интересно,почему?
А, всё понял: это ktextdecode букву почему-то игнорирует при перекодировке Unix->Windows. Н-да, промашка у Алексея Заволжского http://webua.net/zavolzhsky/russian/index.html вышла... небольшая.
Если бы всё было столь просто и очевидно...
...
Скан-последовательность, генерируемая клавишей PAUSE - вообще просто песня
...
P.S. Какая может интересная дискуссия получится!
А чего дискутировать? Драйвер клавиатуры реализован во всех абсолютно операционках, то есть если что-то непонятно, достаточно заглянуть в исходники.
Конечные автоматы - дело, конечно, интересное с академической точки зрения... и даже применимы неплохо к драйверу клавы, или мыши. Но не как панацея - это точно! По крайней мере в чистом виде теория конечных автоматов здесь не слишком хорошо ложится в канву написания быстрого, легкого и красивого кода, потому-что производители железа много маразматичных решений приняли во время реализации.
А если конечные состояния и переходы не детерминированы, как в случае различных новых девайсов, то при работе твой КА в итоге может пойти по совершенно фантастическим веткам.
Хотя идея стоит рассмотрения... надо будет подумать - может, я отдельные части своих драйверов тоже реализую в виде КА.