Board.KolibriOS.org

Как из Колибри реализуется обработка IRQ от внешних устройст(например от com порта) ?

Я смотрел исходники PPP звонилки от Майка Хаббета и непонял как он обрабатывает IRQ от COM порта.
Нужно ли для работы с COM портом сконфигурировать сетевой стек ?

IRQ обрабатывается с помощью его резервирования и затем установки соотвествующего бита 40 функцией. После этого приложению будут приходить IRQ-события.

Это я знаю.А вот как происходит его обработка(IRQ) - я непонял.

andrew_programmer wrote:Как из Колибри реализуется обработка IRQ от внешних устройст(например от com порта) ?

Я смотрел исходники PPP звонилки от Майка Хаббета и непонял как он обрабатывает IRQ от COM порта.
Нужно ли для работы с COM портом сконфигурировать сетевой стек ?

Немного прокомментирую по сути железячной работы.
1. Речь идет, как я понимаю, о драйверной работе некого кода (классически называемым драйвером) непостредственно с устройством, посредством известных аппаратных вещей: порты, DMA,IRQ
2. COM порты - давно устоявшиеся в своей аппаратной реализации и развитию не подлежат. Существует лишь эволюционный ряд чипов у которых рост версии = росту FIFO буферов Rx и Tx и максимальных скоростей (существуют UART чипы(это контроллер любого СОМ порта) c потолочными скоростями плоть до 60 Мб/с!!!). У них имеем следующие аппаратные вещи: диапазон портов, линия IRQ, FIFO буферы.
3. Для любого режима работы COM порта изначально инициализируется определенным образом UART контроллер. Примитивную инициализацию наблюдал в исходниках Menuet OS, но она неполная, т.к. использовать именно АППАРАТНЫЕ вещи заложенные в UART для РАЗГРУЗКИ CPU от рутинной и тупой работы не удастся! ЭТО ПРЕЖДЕ ВСЕГО програмирование Rx и Tx прерываний, что дают свободу СИСТЕМЕ, от постоянных опросов приложением (ядром) порта статуса!
4. Сетевой стек непосредственно для работы COM порта не представляет принципиального значения.

andrew_programmer wrote:Это я знаю.А вот как происходит его обработка(IRQ) - я непонял.

Во всяком случае а ранее я видел (последние какие нибудь исходники не смотрел, обрадуете если есть позитивные сдвиги теперь) работу с IRQ со стороны ядра, как ПЕРИОДИЧЕСКИЙ опрос порта. Это меня насторожило, но я длительно пытался (месяца 3) реализовать ИМЕННО COM дряйвер оси, измерить его реальные скоростные возможности, реализовать скоростную(115200) и ОДНОВРЕМЕННУЮ работу с двумя м более последовательными устройствами... Но все кончилось крахом в плане оси и её возможностей, а вот с аппаратурой и её освоением и пониманием были одни плюсы...
Потолок РЕАЛЬНОЙ скорости COM портов у меня был около 56000-59000бит/c нагрузка CPU очень высока и неоправдана(!), а поднятие выше неизбежно приводила к полному блокированию ядра... и лишь с трудом инигда удавалось "срывать" эту мою прогу сделанную по канонам создания прог MenuetOS. Очень большой недостаток именно по приему скоростного потока, т.к. возможны выпадения приемной информации...

Вастани, ты хочешь сказать что меос плохая система для устройств передающие в ком порт данные?

andrew_programmer
Вроде бы там не используется IRQ вообще - идет просто PIO опрос портов.
Раньше и мышь была тупо сделана, по этому же принципу, но в следующем выпуске Колибри мыши будут сделаны как нужно. Обработка данных без потерь.

camper
Он просто опять же изложил идею, что система была написана не оптимально, по принципу лишь бы хоть как-то работало. Потому и глюки, потому и задержки и потеря информации.

В Колибри есть PPP звонилка.Она обрабатывает IRQ от COM порта(принимает данные посланнные модемом на COM порт) и наоборот - посылает на COM порт данные.
Вот часть кода из исходников PPP звонилки:

apploop:
mov eax, 23 ; wait here for event
mov ebx, 20
int 0x40

cmp eax, 1 ; redraw request ?
je red
cmp eax, 2 ; key in buffer ?
je key
cmp eax, 3 ; button in buffer ?
je button
mov ebx, [comirq]
add ebx, 16
cmp eax, ebx
je flush_input ; Dont want serial data yet
jmp apploop

red: ; redraw
call draw_window
jmp apploop

key: ; key - ignore
mov eax, 2 ; just read it
int 0x40
jmp apploop

button: ; button
mov eax, 17 ; get id
int 0x40

cmp ah, 1 ; close program ?
jne noclose

mov esi, hangupWait
mov edi, hangupSend
mov edx, 1000 ; Allow sendwait 10s
call sendwait

call disable_port

mov eax, -1 ; close this program
int 0x40
jmp apploop

noclose:
cmp ah, 2 ; Dial Button pressed?
jne apploop

mov eax, conp
mov [prompt], eax ; set up prompt to display
mov al,[conp_len]
mov [prompt_len], al
call draw_window

jmp dialloop ; connect to the host


; Data received, so get it, and throw it away at this point
flush_input:
mov eax,42
mov ebx, [comirq]
int 0x40

mov eax,11 ; This will return 0 most of the time
int 0x40
mov ebx, [comirq]
add ebx, 16
cmp eax, ebx
je flush_input
jmp apploop



Нифига непонятно,каким образом и куда считываются данные принятые по IRQ.

Для чтения данных по-видимому используются 42 и 43 функции.

camper wrote:Вастани, ты хочешь сказать что меос плохая система для устройств передающие в ком порт данные?

Я хочу сказать то, что уже сказал! Меньше сказать не счел нужным и полным (правильным), больше - не вижу надобности, т.к. "глубокие разборы вопросов" и конструктивный диспут (а не споры!) не популярны, видимо...

Mario79 wrote:andrew_programmer
Вроде бы там не используется IRQ вообще - идет просто PIO опрос портов.

Совершенно верно, Марат, но меня гложут сомненья, что многие не увидят в этом принципиальной сущности, а так хотелось бы.
А ведь если прикинуть, даже глазами начинающего радиолюбителя, то все очень даже просто выглядит. Ведь посмотрите, ЛЮБОЙ IRQ выход устройства, по сути не что иное,как простейший RS триггер, у которого вход SET идет в устройство и "ловит" (защелкивает) первое появление того или иного "событийного факта" этого устройства, а его вход RESET - получает от CPU сброс при обработке данного прерывания устройства... Вот и получается, то он "помнит" запрос IRQ предназначенный CPU (драйверу, системе...)

Mario79 wrote: Он просто опять же изложил идею, что система была написана не оптимально, по принципу лишь бы хоть как-то работало.

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

andrew_programmer wrote:В Колибри есть PPP звонилка.Она обрабатывает IRQ от COM порта(принимает данные посланнные модемом на COM порт) и наоборот - посылает на COM порт данные.
Вот часть кода из исходников PPP звонилки:

apploop:
mov eax, 23 ; wait here for event
mov ebx, 20
int 0x40

cmp eax, 1 ; redraw request ?
je red
cmp eax, 2 ; key in buffer ?
je key
cmp eax, 3 ; button in buffer ?
je button
mov ebx, [comirq]
add ebx, 16
cmp eax, ebx
je flush_input ; Dont want serial data yet
jmp apploop

red: ; redraw
call draw_window
jmp apploop

key: ; key - ignore
mov eax, 2 ; just read it
int 0x40
jmp apploop

button: ; button
mov eax, 17 ; get id
int 0x40

cmp ah, 1 ; close program ?
jne noclose

mov esi, hangupWait
mov edi, hangupSend
mov edx, 1000 ; Allow sendwait 10s
call sendwait

call disable_port

mov eax, -1 ; close this program
int 0x40
jmp apploop

noclose:
cmp ah, 2 ; Dial Button pressed?
jne apploop

mov eax, conp
mov [prompt], eax ; set up prompt to display
mov al,[conp_len]
mov [prompt_len], al
call draw_window

jmp dialloop ; connect to the host


; Data received, so get it, and throw it away at this point
flush_input:
mov eax,42
mov ebx, [comirq]
int 0x40

mov eax,11 ; This will return 0 most of the time
int 0x40
mov ebx, [comirq]
add ebx, 16
cmp eax, ebx
je flush_input
jmp apploop

Нифига непонятно,каким образом и куда считываются данные принятые по IRQ.

Советую почитать назначение, принцип и работу IRQ в машине, могу поискать ссылки если книг нет... вот хоть поройся в хламовнике, что давал всем http://meos.sysbin.com/viewtopic.php?t=35
Пожалуй ты путаешь понятие ПОРТ и IRQ линия! Т.е. IRQ - это ВЫХОДНОЙ СИГНАЛ данного устройства на специальный вход CPU (но через тот самый многовходовой контроллер прерываний).
Еще можно запомнить так. IRQ - это флаг железяки, который выставляет железка самостоятельно, а гасить(сбрасывать) его надо обязательно, но уже софтом... ГЛАВНОЕ ДЛЯ СИСТЕМЩИКА (и бедному надрывающемуся CPU:), так это то, что IRQ "ЗОВЁТ" CPU у себе "с просьбой" заняться ЕГО ПОРТАМИ и пр. , возможно даже "бросив все другие дела", т.е. вне очереди! НО, при этом, механизмы IRQ - НЕ РАСХОДУЮТ ПОНАПРАСНУ ВРЕМЯ CPU!!!
Работаем с портами, скажем COM, только тогда(!), когда оно позовёт к себе, даже если это приём символа... после 48часов "молчания"!
Вещь АСИНХРОННАЯ, это еще один плюс!
В примере выше, куча времени тратится, ДАЖЕ ЕСЛИ ПРИЕМНИК ПУСТ и НЕ НУЖДАЕТСЯ во внимании CPU, т.к. опрос крутится все время в петле: jmp apploop
Важно! Любая РЕАЛтаймтвая система, не должна так работать с устройствами... она не должна ТЕРЯТЬ инфу ПОСТУПАЮЩУЮ С УСТРОЙСТВ, иначе её место на свалке + время "РЕАКЦИИ ОСИ" на подобные вещи является ИХ ВАЖНЕЙШИМ ПАСПОРТНЫМ параметром!
Представьте себе, что графитовый стержень ядерного реактора, чуть чуть запаздывает, изза того, что CPU пропускает моменты, когда это экстренно надо НАЧИНАТЬ делать, виду того, что он выгребает в PIO статусные регистры сотен портов... манипуляторов, например! Жуть! Я бу такой стране не завидовал... (P.S. к реал тайму всегда надо стремиться и стремятся ВСЕ...)
Для архитектурного постоения MenuetOS свойственно, что с открыванием десятков портов, мы можем весомо подгружать систему даже "на холостых вещах", вплоть до убиения "временной свободы CPU"... а ведь в данной системе есть и другие устройства, которые работают через этот механизм! :[
Вспомнить хоть бы PIO для HDD, но это другая параллельная тема.

VaStaNi
1) Кроме того, обработка порта сделана через функцию, а не через команду IN и OUT, что уже само по себе является диким тормозом. На тот момент Велик Придуркович, запретил обращение к портам через данные команды из Ring3.
2) Я и говорю в следующем выпуске Колибри (который почти готов) по крайней мере, мышки будут обрабатываться, так как надо, а не когда до них дойдет очередь. (Кстати у тебя есть, надежный алгоритм определения подключена ли любая PS2 мышь? То, что придумал я для определения, хоть и использует стандартную фичу, но не всеми производителями хочет поддерживаться, хоть и работает на большинстве PS2 мышей)
3) На советских реакторах (по крайней мере, изначально) использовались сверхнадежные аналоговые компьютеры.
Достигалось это тройным дублированием систем и простой системой электрических цепей. Проблемы 2000 и или вирусов им до фонаря.
4) PIO для многозадачной системы это вообще тяжко, попробуйте снять галки использовать DMA в Винде и скопируйте 1 Гб или хотя бы один DivX фильм с одного раздела винта на другой раздел этого же винта (когда 2 винта, то ситуация полегче) и как говорится почувствуйте разницу на своей шкуре.

VaStaNi,спасибо за советы.

Значит IRQ сообщает системе,что получены данные,а программа через in читает данные,которые пришли в порт.

andrew_programmer
Не совсем верная формулировка, хотя суть для программиста приблизительно такая. Но в случае с реализацией в МеОС и Колибри дело обстоит не так, а как описал VaStaNi - производится постоянный опрос порта, что явно неоптимально и торомзит всю систему (ситуацию можно сравнить с Win модемом на слабом компе).

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

Перво-наперво, спасибо за понимание!

Mario79 wrote:VaStaNi
1) Кроме того, обработка порта сделана через функцию, а не через команду IN и OUT, что уже само по себе является диким тормозом. На тот момент Велик Придуркович, запретил обращение к портам через данные команды из Ring3.

Конечно, ты ОЧЕНЬ прав! Но более Важно (для активистов проекта) понимать и я бы сказал, "чувствовать" на этом уровне, это фундамент творческого единения усилий и понимания важности, первоочередности задач и перспектив...

Mario79 wrote:VaStaNi
2) Я и говорю в следующем выпуске Колибри (который почти готов) по крайней мере, мышки будут обрабатываться, так как надо, а не когда до них дойдет очередь. (Кстати у тебя есть, надежный алгоритм определения подключена ли любая PS2 мышь? То, что придумал я для определения, хоть и использует стандартную фичу, но не всеми производителями хочет поддерживаться, хоть и работает на большинстве PS2 мышей)

Марат, обдумай вопрос, обобщи, заводи тему в драйверах, поговорим. Заодно хотелось бы понять еще кого то это интересует? Еще есть мыслящие так и в этой стезе? Ну неужели раз два, три... и все.
Я бы советовал достичь универсальности COM "стыка" сразу (т.е. для всех последовательных устройств вводв-вывода), хотя как первый шаг - "обуздать правильно мышь" по классическим канонам, тоже весьма позитивное дело и прогресс... Но! Но тут есть, возможно, минус направленный в сторону вопроса о совместимости версий вниз! Хотя кому надо радоваться совместимостью со старым и быть может, далеко не лучшим... Ведь надо (комуто:)) закладывать(хотя бы пытаться) лучшее, более нужное и передовое, даже если единожды резать пуповину отмирающего "старого груза"

Mario79 wrote:VaStaNi
3) На советских реакторах (по крайней мере, изначально) использовались сверхнадежные аналоговые компьютеры.
Достигалось это тройным дублированием систем и простой системой электрических цепей. Проблемы 2000 и или вирусов им до фонаря.

Ехал домой, вчера и думал скажет кто либо про этот пункт и то, что это дескать совсем не так! А после недолгих размышлений, понял, что все же будет реплика ) Но это не беда. Любой пример или даже притча, чему нибудь да учит или наводит на размышления, анализ, ЭТО ВАЖНО, я считаю. А по поводу буквального... Так, между прочим, кто сказал, что сейчас НИКТО НЕ НУЖДАЕТСЯ в новых ОСях, для управления тем или иным обьектом, процессами!? Я давно считаю и "на каждом углу" пытаюсь молвить, что НАША цель! (рускоговорящих разработчиков различных проектов и направлений) - НАУЧИТЬСЯ строить ОСи! Разбираться в них и их составных частях, принципах, а еще научиться помогать ДРУГ ДРУГУ, отучиться спорить, обижаться, научиться слушать коллегу и понимать его ХОД мысли, несмотря на недостатки в...!
Тут недавно был на интересном RU сайте, посвященном ОТЕЧЕСТВЕННОМУ РОБОТОСТРОЕНИЮ! Вы думаете ребятам не нужна маленькая, бесплатная, многозадачная....ОСь для управления самодельным роботом!?
Убежден - ОБЯЗАТЕЛЬНО НУЖНА!!! Но они и не предполагают о том (почти уверен), что быть может всего в несколькиз километрах от них, кто то живёт и делает свою ОСь..., но не догадывается тоже, что быть может его доведенный проект поможет совсем не "!!!всему миру...!!!", а такому же пытливому братухе-фанатику, но немного другого профиля хобби, дела, профессии... и он тоже профессионал СВОЕГО ДЕЛА! А ведь ЭТО ОЧЕНЬ было бы здоровою ребята! Дай Бог чтобы ВСЕ учились стоить сообща, а не ломать. Лично мне очень хочется, чтобы перестало звучать в НАШИХ делах (даже государственных) фраза песни "...до основанья мы разрушим, а потом...". Либо "потом" очень затянулось либо мы еще на стадии разрушения, либо мы циклим, глючим в глухом JMP на начало фразы...
Да, мы без капиталов творим, без фирменного бантика и кофе с булочкой, без офиса, без... но пусть в этом несправедливом мире будет хоть островки правды, товарищества не за деньги, альтернативное созидание на благо... и во имя...
Прорвало, меня опять, на многословие, простите, это больное...

Mario79 wrote:VaStaNi
4) PIO для многозадачной системы это вообще тяжко, попробуйте снять галки использовать DMA в Винде и скопируйте 1 Гб или хотя бы один DivX фильм с одного раздела винта на другой раздел этого же винта (когда 2 винта, то ситуация полегче) и как говорится почувствуйте разницу на своей шкуре.

Ты опять прав и я полностью согласен, однако, думаю что если ты посмотришь на себя немного раньше .... ну вспомнишь сам себя + характер своей личности ... Думаю, скажи тебе самому эти слова год, два, три тому НАЗАД... быть может было бы "море крови на форуме", особенно если кто то, расказал бы это применительно к MenuetOS ))))
Не обижайся не бери буквально, я не хочу обидеть и ворушить, что то старое, просто ты сегодня вполне можешь быть назван "старожилом и именно РЕВНИТЕЛЕМ" проекта... Как правило так и бывает и почти со всеми, я не исключение..., но пожалуй прав поэт: "...опыт - сын ошибок трудных...". Я это к чему. Бывает есть человеку, что сказать многим и исключить неправильное решение, если его поймут или попытаются разобраться в том, что сказано им, но он не говорит в силу ряда причин: лени, высокомерия, гордыни, отсутствия времени, плохого изложения мыслей, воспоминания о "помидорах, когда то в него брошенных"... Полезно иногда поразмыслить и об этом, правда? Жизнь, однако, штука весьма прелюбопытная и витиеватая. Философия такова, что каждому свой срок и момент созревания и понимания, но часто встречаем так, что каждый считает себя правым именно "со своей колокольни" и именно сейчас.

andrew_programmer wrote:VaStaNi,спасибо за советы.
Значит IRQ сообщает системе,что получены данные,а программа через in читает данные,которые пришли в порт.

КОНЕЧНО! Но самое замечательное ЕЩЁ впереди, andrew_programmer!
А это то, что оказывается "железке" можно приказать сообщать именно то, что тебе надо! Или динамически изменять по ходу(!), что надо именно так, но при определенном условии! Попытаюсь пояснить всю "вкусность" и изложить конкретно к твоей теме.
Итак COM порт - это белее чем 90% собственно тот самый UART контроллер. Если внимательно вчитаться в доку на него, или даже наши книжки, то видно, что есть регистр ответственный ИМЕННО за тип выдачи IRQ этого контретного COM порта. Есть прерывания по приему буфера FIFO (а не байта, сегодня, байт был на старых чипах времен XT или первых АТ машин), хотя если очень надо можно настроить объём Rx FIFO = 1 байт! Все очень гибко сегодня и это общая эволюционная тенденция чипостроения. Далее. Есть прерывание по освобождению буфера передатчика (Tx FIFO), есть по ошибке, есть по изменению в служебных ВХОДНЫХ линиях COM порта. Все эти режимы вполне охватывают все целевые потребности системы. Если делать драйвер мыши, например, у которой нет смысла ловить опустошение буфера передатчика UART с целью его дозагрузки, очередной порцией из софтового буфера драйверного кода, то тут пожалуй обязателен тип прерывания по заполнению приемного буфера UART. Как правило, после сброса и отработки BIOS`а он имеет на сегодня 16 байт, если не в курсе кто. Однако для мышенка, 16 байт излишек(!) и рывки перемешения на экране неизбежны, ввиду того, что в буфере "элементарные, квантовые, шаговые" посылки перемещения будут прессоваться в пачку 16 байтного предела, а лишь потом(!) сигналит системе. Так что тут есть нюанс, который надо понять и... перенастроить буфер на ближайшее меньшее по отношению мышонку.
Реакция по вх.линиям COM порта, очень демонстративна в случае поступления, скажем, на ваш COM модем сигнала RING (входящее соединение). Для этого имеем обалденную линию(провод) + бит в соотв.порту + сделали соотв. инит типа IRQ. ТОгда, даже ОСь в спячке и энергосбережении, как пример экономии, не только времени CPU но и батрейки , непременно "разбужена и поднята" на активные, немедленные действия оси! = "Рота подъём!!!!" )))
Дальше. Передатчик, всеже нужон, но как и когда?
Прерывание по ЕГО опустошению НЕ НУЖНО раз и навсегда программировать!!!? (C) VaStaNi. Почему? Как это понять? Открываю секреты оптимального драйверного решения в данном аспекте.
Нетрудно заметить, да и измерить(!), большую, как ни странно, ХОЛОСТУЮ работу (в большинстве случаев или среднестатистически в течение всего "сеанса" работы системы) ИМЕННО В ЭТОМ РЕЖИМЕ ПРЕРЫВАНИЯ!??????
КАк это??? Прерывания, ведь призваны лишь разгружать CPU от рутины!? Да не так в этом случае...
Опустошение буфера, говоришь? А, как часто именно буфер передатчика UART пуст? Да, почти, скажем, 99% суток!!!
Ну передал в модем я, скажем, несколько команд, запросов на просматриваемый сайт... и принял, получил, гораздо больше, чем послал этих самих байт. Скажем 200 байт запрос по Tx и прием 40Мб с сайта как ответ, т.е. это Rx. И дальше мне несколько часов нет надобности передавать..., а ведь этот тип прерывания (буфер передатчика пуст) ВСЕ ВРЕМЯ!!! ДЕРГАЕТ IRQ и !тормошит сознание процессора"!!!! Он, извиняюсь за сравнение, задрачивает CPU вопросами :

COM1: "Эй, начальник! У тебя есть данные передачи для меня?"

CPU: "Нет, отстань, приказываю сбросить запрос IRQ!"

СИТЕМА: "Есть, запрос сброшен!"

прошло время текущего аппаратного цикла UART COM1, наступил момент нового (пусть несколько мкс)....

COM1: "Эй, начальник! У тебя есть данные передачи для меня?"

CPU: "Задолбал он меня, хоть бы этот порт закрыл кто! Дармоед моего времени, расточитель! Вредитель! Приказываю сбросить запрос IRQ!!!"

СИТЕМА: "Есть, запрос сброшен!"
.....
.....

ВЫВОД. Когда в системе имеется, что передавать, надо добавить к текущим режимам IRQ данного COM порта (логическое ИЛИ) режим реакции на буфер передатчика UART пуст.
НО!
Как только буфер софта системы (не путать с буфером UART! это собственно должен быть отдельный зарезервленный, за данным открытым COM портом диапазон памяти, защищенный от сторонних посягательств!), как только ИСЧЕРПАН - НЕМЕДЛЕННО ГАСИТЬ этот режим конкретно!
Такая вот COM поэма... , а как Вам такие железячности? Нравится ли? Дело в том, что есть мысли излагать знания в виде статей, интересуюсь вот, "местами", нужно ли это делать или рассчитывать на помидоры надо заранеее... :O)

[offtop]Читаешь все это, и не знаю откуда берется желание изучать, читать, пробовать, ошибаться, опять изучать, возвращаться, опять пробовать.........работать в общем! )) Вастани, ты почаще заглядывай, может общее дело быстрее двигаться начнет.
А на вопрос, нужно ли писать статьи, думаю ты сам знаешь ответ: конечно нужно! Возможно больше появится "пытливых братух-фанатиков" . А то устал уже от непонимания: все знакомые крутят у виска пальцем, мол нафига тебе это надо? Вот у меня есть виндовс, так он все умеет: и фильмы показывать, и игры новейшие запускать, и по инету лазить а недавно P4 3.2 с 2 гб оперативы поставил, так все вапще летать стало . Это я, конечно, немного утрирую, но суть примерно та же... Меня всегда при этом мучает вопрос: а что если мне не интересно "гонять бибиков" по экрану монитора сутки напролет, или мне не нравятся тупые американские комедии про обкуренных нигеров...что тогда? А может мне гораздо интереснее разбираться во внутренностях железок, или пробовать самому сделать не так, как мне навязывают гиганты ИТ... Это значит я не от мира сего? Думаю вряд ли... В общем у тебя, наверное, лучше получилось выразить мысли, за что тебе огромный респект [offtop]