OSDev

для всех
Текущее время: 22 окт 2017, 14:54

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.
Автор Сообщение
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 22 июл 2012, 00:18 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
grindars писал(а):
Кстати, а почему бы не писать этот процессор на HDL и не испытывать его в симуляторе? В той же Xilinx-овой ISE есть ISIM, который вполне подходит для такого.
Говорю же
Цитата:
Напрямую в VHDL открыть проект не могу: Установлен OrCAD 10, где неизвестно как с ПЛИС работать. А всякие новые WebPack'и не стоят: Скачал с оффициального сайта гиговый архив, а он - битый (несколько важных файлов не извлекаются). :evil:
Да ещё человек, что обещал купить мне Terasic демо-плату, что-то молчит. :?


Кстати, исправил баг один. Можете проверить.

Сегодня попытался в Си с помощью классов реализовать симулятор (там же легко перехватывать смену уровня clock оператором = имитации тактирования. Так что-то не получается пока разобраться с локальными переменными. :D

P.S.: В своё время скачал Visual Studio 6 мини-сборку - 90Мб установщика. И очень доволен!
Вообще, есть ли компактные пакеты VHDL/Verilog разработки?
Могу обойтись и без опций проверки на железе, а лишь в программной симуляции. Спрашиваю на форумах - молчат.
Нужен пакет умеренного размера - 50-120Мб.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 22 июл 2012, 19:27 

Зарегистрирован: 26 мар 2012, 17:32
Сообщения: 208
> Си
> классов
you're doing it wrong. В общем, прошу не смешивать в кучу C и плюсы.

> Нужен пакет умеренного размера - 50-120Мб.
gtkwave + verilator или gdhl даже на порядок меньше занимают, насколько понимаю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 01 авг 2012, 19:00 
Аватара пользователя

Зарегистрирован: 20 апр 2011, 10:54
Сообщения: 145
AlikberOFF писал(а):
Нужен пакет умеренного размера - 50-120Мб.

http://bleyer.org/icarus/

_________________
Found a CPU. LAPIC ID: 00


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 31 авг 2012, 23:41 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
418ImATeapot писал(а):
AlikberOFF писал(а):
Нужен пакет умеренного размера - 50-120Мб.

http://bleyer.org/icarus/
Спасибо. Разобрался.
Правда, на дворе - XXI! И "я крут, т.к. сижу в консоли" уже не актуально.
Лично у меня уже сложился устойчивый стереотип: Если скачанная программа - консольная, значит разработчики - серъёзные люди. НО!
Повторяю, на дворе - XXI! Графическое разрешение дисплея и камеры у сотовых телефонов скоро на порядок превзойдут рядовой ПК (у одной сотки камера - 40Мп! а у меня и 640x480 с тормозами захватывается). А в сети всё ещё актуальны темы "подключить к LPT дисплей 128x64 - офигительная круть!".
Достало спартанство!

Короче, есть ли пакеты со свистелками-перделками? Т.е. полноценный редактор и отладчик в рамках Windows интерфейса. Чтобы вообще забыть про консоль...
Имею ввиду симуляции работы ПЛИС до уровня внедрения в аппаратную часть моего ПК. Т.е. после запуска симуляции становится доступен виртуальный порт (LPT или COM), а также область в памяти и т.п.
Короче, если я написал простенький видео девайс, то из любой программы на Си можно было бы запросить доступ к его видео памяти.
Т.е. полная симуляция на общем уровне.
Помнится лет 13 тому назад была актуальна тема софт-модема.


P.S.: Чтобы облегчить себе задачу, все листинги пишу как bat-файлы с шапкой
Код:
/*****************************************************************************
@mode con lines=64
@cls
@iverilog -o %~n0 %~nx0
@vvp %~n0
@pause
@exit
*****************************************************************************/
и запускаю через F9 не выходя из редактора BrEd.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 21 мар 2013, 23:31 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
В общем, сел снова изучать сорсы KlbrInWin и совсем запутался. Нашёл процедуру обеспечения доступа к видео памяти десктопа (gs:[pixel]). Однако не выделю никак предпосылки на этот механизм.
Где там настраивается среда Винды, чтобы обращение через gs передавало управление в нужную точку...
В сорсах слишком мало комментов.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 22 мар 2013, 07:44 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1056
Я вроде писал что нужных механизмов нету.
Есть только несколько:
1) Прерывание вызванное при обращением к несуществующей странице, неправильной и тп. Оно вам по определению не подходит так как не даёт увеличения объема.
2) прерывание вызванное при обращение к несуществующему сегменту, неправельный дескриптор и тп.. Вот тут можно играться. Но насколько помню это вас не устраивает из-за того что вам 24 ГБайта мало.
3) Эмуляция каждой команды.

Что касается эмулятора колибри, то исходника нет под рукой. Но скорее всего 99,99% gs:[pixel] - работает так. Есть единое линейное пространство. В котором для видео буфера отведён диапазон адресов к примеру 80000000h-80100000h один мегабайт. А в эмуляторе стоит таймер который периодически останавливает процесса эмулируемой среды читает из него через ReadProcessMemory и делает blitbit для вывода картинке. Запускает эмуляцию дальше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 24 мар 2013, 04:26 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
Хм. Какие 24Гб?

Кстати, за это время концепция немного созрела:
Цитата:
Всем приложениям средой выделяется все 8192 селектора сегментов по 4Гб памяти.
Адресация сегмента свёрнута в 1048576 зеркал на общие 4Кб с защитой от ошибок.
Полное пространство приложения со всеми селекторами достигает размера до 32Тб.
Все селекторы сегментов имеют несколько уровней для управления их контекстами.
Правкой контекста сегмента его зеркала отрывают от глухих 4Кб переназначением.

Поясню. Создаём процесс и выделяем ему минимум:
Шаг №1:
  • На код - страницу "//usr/code" 4кб;
  • На стек - страницу "//usr/dump" 4кб;
  • На данные - страницу "//usr/data" 4кб;
  • На остальное - страницу "//usr/dumb" 4кб.
"//..." - условная ссылка на локальное пространство текущего процесса
Далее, так как в LDT допускается до 8192 сегментов, назначаем их все.
Все 8189 сегментов, исключая #6655, #6143 и # 7176 направляем на "//usr/dumb". Оставшиеся 3 распределяем следующим образом:
  • CS:0xCFFF="//usr/code";
  • SS:0xBFFF="//usr/dump";
  • DS:0xDFFF="//usr/data";
  • ES:0xDFFF="//usr/data";
  • FS:0xFFFF="//usr/dumb";
  • GS:0xEFFF="//usr/dumb".
Тут программа имеет в своём распоряжении все 8192 сегмента, но они предоставляют всего 16кб виртуальной памяти в нижних адресах [0x00000000..0x00000FFF] по любому сегменту.

Шаг №2:
Теперь делаем так, чтобы обращение по адресам за пределом 4кб ( > 0x00000FFF) на убивало программу. Так как страниц может быть 1048576, а по нижним 4кб лежит страница #0, все страницы [1..1048575] зеркалим на #0. Т.е. программа, обращаясь по остальным адреса (0x00001000..0xFFFFFFFF) будет иметь дело с отражением основной (на 0x00000000..0x00000FFF). Тем самым, имея 8192 сегмента по 4Гб каждый, программа получит все 32Тб пространства (но не памяти). И всего 16кб реальной виртуальной памяти.
Тем самым, программа сможет работать в этом "лабиринте зеркал" и никогда не получит ошибки обращения к несуществующей странице памяти.

Шаг №3:
Тут наступает самое интересное.
Нужно всем этим 8192 сегментам памяти создать другие формальные 8192 сегмента контекста.
Т.е. получается так:
  • 0xCFFF - сегмент ресурса "//usr/code", 0xCFF8 - сегмент контекста "//usr/code".
  • 0xDFFF - сегмент данных "//usr/data", 0xDFF8 - сегмент контекста "//usr/data".
  • 0xBFFF - сегмент стека "//usr/dump", 0xBFF8 - сегмент контекста "//usr/dump".
Иначе говоря, если программа хочет узнать имя контекста сегмента 0xCFFF, ей нужно попытаться считать данные из глобального сегмента 0xCFF8, где и будет лежать сама строка "//usr/code". Т.е. при попытке загрузить в регистр сегмента (FS/GS) значение 0xCFF8 сгенерируется исключение. Процесс застынет, мой "демон" получит управление для отладки ситуации. Он "поймёт", что раз нижние три бита обнулены в 0xCFF8, значит программа "стучится" в нижний уровень (демона) с вопросом "дай имя контекста"...
Получается некий API-вызов, но без традиционных call/int. А через "диалог" с памятью.

Например.
Мы хотим, чтобы программа открыла файл по сегменту 0x1237. И мы теперь знаем, что доступ к контексту сегмента будет в 0x1230. Нам нужно прямо в контекст сегмента вписать имя файла, чтобы оторвать все 1048576 зеркал сегмента 0x1237 от 4кб страницы "//usr/dumb" и переключить их на проекцию всего файла.
Делаем это так:
Код:
// Попросим "демона" назначить сегмент 0x1237 на проекцию файла со звуком
    lea     edx,[szFileName]    // Грузим в EDX адрес строки с именем файла
    mov     [hfile],edx         // Дублируем адрес - операция fopen...
    lfs     edx,[hFile]         // Генерируем исключение #1, просим внимания
    mov     al,fs:[0]           // читать ли будем или писать. Читаем (#2) и
    ...                         // поясняем "демону", что открываем на чтение
;  Если хотим открыть на запись, поступаем так же:
;   mov     fs:[0],al           // Ничего в файл не пишется. Но "демон" понял
;; Если хотим открыть на чтени-запись, поступим вот так:
;;  xchg    fs:[0],al           // Тоже холостой ход, но "демон" понял
;;;Если хотим иметь сегмент библиотек, делаем такой ход:
;;; call    dword ptr fs:[0]    // Вызова не будет. Но "демону" поясняем - код
    ...
// Спросим "демона" напомнить, какой ресурс лежит в сегменте 0x1237
    lea     edx,[szInfo]        // Грузим в EDX адрес строки-приёмника
    mov     [hFile],edx         // Дублируем адрес, чтобы указать буфер приёма
    mov     edx,sizeof szInfo   // Грузим размер приёмного буфера
    lfs     edx,[hFile]         // Здесь "демон" прочтёт адрес буфера и
    ...                         // обнаружит нули. Проверит EDX и вернёт имя
// Просим "демона" закрыть файл по сегменту 0x1237
    lea     edx,[szInfo]        // Грузим в EDX адрес строки с именем файла
    mov     byte ptr[edx],0     // Чистим её, чтобы отказаться от файла
    mov     [hFile],edx         // Дублируем адрес - операция fclose...
    lfs     edx,[hFile]         // Здесь "демон" обнаружит пустую строку и
    ...                         // закроет файл. Сегмент станет "//usr/dumb"
    ...
szInfo      db      256 dup(0)
szFileName  db      "C:/Windows/Media/Tada.wav",0
hFile       dd      ?
            dw      0x1230
Как видно, операции fopen..fclose вызываются не напрямую, а диалогом с памятью.
Замечу, что при открытии файла тут генерируется два исключения. Первое - при записи в fs значения 0x1230. Где файл не открывается, а лишь проверяется его наличие и он ставится на очередь. Второе - при чтении (записи, обмена, вызова и т.д.) из сегмента. Где уже становится ясно, для чего сегмент нужен.
Хорошо.
Скажете в очередной раз.
Более-менее, но понятно.
Но зачем организовывать такой чудовищный API!?
Отвечу так:
  1. API-интерфейс становится абстрактным, эфемерным. Сама OS уходит на более далёкий план;
  2. API-интерфейс такого вида легко переключить на аппаратный уровень, где сам чипсет сможет играть роль "демона";
  3. API-интерфейс с псевдо-аппаратным демоном по-сути уже кроссплатформенен.
На счёт пункта №3 Вы начнёте жёстко возражать. Поясню...
Все процессоры имеют операции чтения-записи - кроссплатформенность.
Если реализовать мою задумку, можно подобным кодом написать десятки нормальных программ.
Т.е. изначально все прикладные программы жёстко привязаны к своей операционной системе набором библиотек, функций и их особенностью (скажем, нужен cygwin для запуска *nix-приложений под Windows с адаптацией).
А если все операции будут производиться только с памятью, оболочку для таких приложений можно перенести на плечи виртуальной машины и вообще легче воспроизвести аппаратно (чтобы понять этот момент, нужно забыть весь свой опыт работы со всеми операционными системами и компьютерами).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 22 июн 2014, 21:28 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
Космическая Одиссея 2001 - позиция 111 минут 55 секунд.
Оператор ЭВМ отключает модули физическим извлечением и отключением.
Так как фильм я видел ещё в детстве, то идея идеальной операционки стала базироваться на желании, чтобы дома на столе создавалось нечто большое и похожее на ту супер-ЭВМ. Так, ради забавы и даже в ущерб производительности.

Позиция сегодняшнего дня
Пересмотрев фильм, я понял, что концепцию сильно перекрутил.
Политика некоторых механизмов стала несколько твёрже...
Итак:
  • Адресное пространство: 8192 сегмента по 4Гб каждый, свёрнутые в единый дамп 4Кб;
  • Программа не имеет никакого доступа к файлам, т.к. файловая система для приложения отсутствует;
  • Все ресурсы (от bmp до mp3 и avi) подобны картриджам (NES/Sega) и появляются в памяти приложения как новые сегменты;
  • Все библиотеки с API - также подключаются физически (виртуально) как картриджи как новые сегменты (горячий Plug'n'Play);
  • ...
Иными словами, нет никакой многозадачности (формально). Приложение запускается в полном вакууме.
Имеется формальная таблица и 256 векторов прерываний. Когда пользователь тащет свой mp3-файл на проигрыватель, OS иницирует свободный сегмент под зеркало на этот mp3-файл, а затем генерирует прерыванию по нужному вектору (типо, авария: внедрение в память). Приложение должно само просканировать все 8192 сегмента и обнаружить изменения (вторжение инородного устройства в шину дешифратора адреса).
Т.е. никаких путей к файлу, а также его имя, расширение и атрибуты, приложение не видит. Тупо, эдакий сегмент памяти занялся под эдакий бинарный ресурс. Этот ресурс нужно проанализировать, распознать и отработать...

P.S.: Один мой знакомый из сферы IT, выслушав мою идею операционки, задумался и сказал, что очень напоминает зачаточное состояник ИИ. Где система - не просто набор нужных папок и файлов. А неизвестно что неизвестно где. С одной стороны, шаг назад, к хаосу. Но, если задуматься и копнуть глубже, напоминает нейронную сеть. Где клетки соединяются друг с другом вслепую, хаотически и без всяких формальностей. Что моя операционка напоминает некий организм. Вот только найти надо единомышленников...
Да, легко сказать. Найти, в обществе, где подавляющее большинство - думают по-шаблону, работают с шаблонами и шаблонят везде, где можно...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 23 июн 2014, 10:47 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1056
Мой разум открыт для нового. Интересная идея. Только я вижу это не как искусственную НС. А как экосистему. В которой существует несколько экземпляров программ. И которые конкурируют между собой. Всё таки это ближе к генетическим алгоритмам.
Что касается ИИ, то он с одной стороны достаточно сложен с другой до безобразия прост. Скажу что существе генетическая память. Из-за неё как раз интеллект и мыслит шаблонами. Причем этих шаблонов несколько уровней. По этому принципу строятся говорилки. Стоит сказать это самое передовое направление в ИИ области.

Хочу подкинуть вам идею. Тут была передача научно познавательная про ВИЧ. У человека существуют беки которые атакуют всё неизвестное. Атаковать начинают по команде, для просто ты пусть некоторое прерывание. А есть другие белки которые по этой команде начинают анализировать это неизвестное и выробатывают стратегию тактику для борьбы с этим неизвестным.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 07 июл 2014, 03:44 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
Я - человек необразованный, премудростям терминов необученный.
Если говорите экосистема...

Так как на этом форуме все темы про ОС, смею продолжить тему свою.
Сейчас сидел и вспомнил старую идею, про которую я упоминал вскольз.

Полимерная память
У меня это не физический термин, а сугубо виртуальный.
Суть моей полимерной памяти заключается в том, что она просто имеет дополнительное измерение.
Когда приложением запрашивается у ОС объявить некоторый регион памяти полимерным, этот регион, всего навсего, резервируется. Любое обращение к нему провоцирует исключение.
Однако, позвольте! Я не такой дурак, чтобы тупо объявить в своей идее ОС полимерностью флажок MEM_RESERVE функции VirtualAlloc Win-API, так как суть несколько в ином.

Дело в том, что в среде ОС предусматривается возможность объявления региона служебных ячеек. Всякий доступ к которым всегда генерирует исключение, чтобы ОС знала, что программа хочет считать текущее состояние операционной среды, либо внести свои коррективы. Но, с одной маленькой особенностью...

Каждая ячейка региона полимерной памяти имеет совершенно независимое собственное измерение.
Т.е. когда мы запрашиваем у ОС минимальный полимерный регион размером в 4Кб, это вовсе не значит, что его размер - 4Кб...
Да, в памяти приложения он займёт ровно 4096 ячеек от 4Гб. Но это не 4096 байта.
Каждая из 4096 ячеек является неким хэндлом в "иное измерение".
Код:
    mov edi,PolyDump ; Указатель на "полимерный" регион
    lea edi,[edi+56] ; Позиционируем указатель на "портал" №56
    stosd            ; Пишем туда данные в "проекцию D - Data", регистр edi не изменяется, так как это не обычная логическая память
    stosw            ; Пишем туда код режима в "проекцию W - Workspace", не изменяя регистр edi
    stosb            ; Пишем туда информацию в "проекцию B - Bus", не изменяя регистр edi
    rep movsd        ; Отправляем туда пакет в "проекцию D", регистры edi esi ecx не изменяются
    rep scasw        ; Сканируем "проекцию W", регистры edi ecx не изменяются
    rep cmpsb        ; Сверяемся с "проекцией B", регистры edi esi ecx не изменяются

Как видно, организуется некий API взаимодействия с ОС. Таким образом, в одну полимерную ячейку можно отправить:
  • До 4 гигов байт;
  • До 4 гигов слов;
  • До 4 гигов двойных слов.
Полимерные ячейки напоминают "чёрные дыры", "проколы" в пространстве памяти приложения, некие сетевые "порталы", потоковые каналы и т.д.

Как я уже сказал, если Windows выделяет одному приложению до 2Гб памяти (или до 3Гб, не важно), а верхние 2Гб занимает сама. То в идеологии концепции моей ОС лежит принцип полностью скрытого API.

Допустим, приложению нужен "картридж" с mp3-файлом. Говоря "русским" языком, нужно открыть файл с музыкой через диалог с пользователем.
Код:
    mov edi,PolyDump ; Указатель на "полимерный" регион
    lea edi,[edi+77] ; Позиционируем указатель на "портал" №77: 77 - код буквы 'M' (4D)
    mov esi,Mp3Files ; Указатель на описатель режима
    rep movsw        ; Записываем в "проекцию Workspace" "магическое заклинание"
    jo  No_devices   ; Если ОС установила флаг переполнения OF, значит "устройство не готово"
    mov esi,Mp3Stream; Указатель на строку управления
    rep movsb        ; Отсылаем в "проекцию Bus" команды подготовки потока к воспроизведению
    jo  No_streams   ; Если ОС установила флаг переполнения, значит поток не готов
    ...
Mp3Files  db "/dev/media/*.mp3",0
Mp3Stream db "mode:MP3_OPEN | MP3_STOP",0

Тем самым, если изначально полимерная ячейка №77 была пуста, то после приклепления её к "/dev/media/*.mp3" любой доступ к ячейке будет контролироваться mp3-библиотекой.
А установка режима ячейки "mode:MP3_OPEN | MP3_STOP" (подобно специфической командной строке) пошлёт библиотеке команду на вызов диалога с выбором файла и подготовку потока к воспроизведению.
Тем самым, как видим, никаких явных инкладов, никаких call и ничего привычного.
Просто, постоянно генерируем исключения, а ОС сама "угадывает", что мы хотим от неё...

Если мы полимерную ячейку объявим OpenGL-средой, то туда загрузится соответствующая библиотека. Причём, в памяти приложения библиотека уместится ровно в 1 ячейку, отнимет 1 байт пространства (можно запросить миллиард хэндлов на различные нужды. это займёт всего миллиард байт). И работать с этой библиотекой нельзя через обычные call...
(Хотя, если очень "приспичит", можно в описатель режима ячейки добавить указатель на проекцию в память, где библиотека будет доступна как в "традиционных операционках". Но тогда 4Гб общей памяти может приложению не хватить, если оно будет запрашивать проекции на тысячи библиотек. Но, это отдельная тема.)

Потому что ОС так и задумывается мною: Не быть простым нагромождением библиотек и кучей функций, а имитировать виртуальную ЭВМ с "аппаратно" вставляемыми картриджами определённого назначения. Вписал в "полимерную ячейку" нужное "магическое" слово, в неё воткнулся картридж (виртуально-аппаратный) и будет в ней "торчать", пока ячейку не обнулим...

Эту мысль всюду критиковали за то, что такие ячейки, генерирующие исключения при каждом доступе, предстанут самым медленным API в мире!
Потому, хочу снова повторить: Эта операцинная система придумывалась концептуально не как очередная операционка, и не как эмулятор некоей ЭВМ.
Операционная система с самого начала задумывалась как эмулятор супер-ЭВМ. (почему "супер"? с самого начала концепция ОС предполагала, что клавиатура может быть в Канаде, мышь - в Австралии, а принтер - на Луне. т.е. любая программа в данной ОС может даже изначально не подозревать, где находятся её оборудование. тупо "втыкаем" в программу "шнур" клавиатуры с любой точки планеты и всё. включая и зеркала проекции файла для одновременного доступа. сама ОС напоминает "облако")
Т.е. если в Windows в кольце 3 инструкции CLI/STI/IN/OUT/INS/OUTS запрещены и вызывают крах приложения, то в задуманной ОС они доступны для обращения к устройствам этой виртуальной ЭВМ. Причём, in/out команды никак не дадут доступа к реальным портам IBM-PC или к симуляции портов IBM-PC (DMA, SoundBlaster, Keyboard etc.). Здесь in/out будут работать как ещё один уровень взаимодействия с аппаратурой (наряду с полимерными ячейками). Т.е. можно объявить порт №54 (EDX=54) IRC-протоколом и отправлять туда сообщения или команды (REP OUTSD).
Можно построить совершенно любую ЭВМ со своими портами и своими девайсами.

А главное: Не смотря на то, что полимерные ячейки и порты в таком случае - крайне медленный API, концепция ОС базируется на том, что (идеализируя) можно пойти к "Китайцу" и заказать материнскую плату на базе x86, но с чипсетом "моей разработки". Т.е. сам чипсет будет контролировать аппаратно ширину слова при доступе к памяти (B, W или D) и "полимерно" воспринимать доступ к ней.
И если программно ОС будет жутко тормозить с моей "полимерностью". То, имея такой "чудо-чипсет", машина будет просто летать (конечно, распаковка mp3-файла - аппаратная, OpenGL - аппаратный)!

Вы скажете, я отстал от жизни, так как OpenGL и DirectX - давно аппаратные.
Но, доступны же из приложения не напрямую, а сквозь уйму программных "костылей": Библиотеки - HEL - HAL...
Как ни крути, без API никак не обойтись.

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

(раньше в Windows'XP если в программе открыт захват с карты аналогового ТВ-тюнера, в других приложениях доступа к нему уже не было. а вот в Vista и в последующих - можно открыть кучу сеансов работы с тюнером. если где-то переключить канал, во всех программах канал тоже переключится: нет конфликта единоличного управления тюнером. т.е. частично реализована концепция моей ОС. напоминаю, я её задумал в 1996-1998, ещё до знакомства с DOS 3.11, сидя за РАДИО-86РК)..
[code]
mov edi,PolyDump ; Указатель на


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB