Board.KolibriOS.org

Я здесь только что зарегился, потому просьба сильно не пинать Пока вникаю в суть вопросов.

Собственно, идея такова:
Ищу ОС для реализации нескольких встроенных систем, как коммерческих, так и не очень. Основные требования - удобство кодинга на асме (критично, так как я сам, кроме асма, ни на чем толком не кодирую), прямая быстрая работа юзерского софта с железом (необходимо в случае втыкания карт расширения собственной разработки); поддержка файловой системы (FAT достаточно); поддержка работы в текстовом и графическом режиме (1024*768 достаточно); поддержка RS232, и, желательно USB; работа с большими массивами данных в памяти (десятки Мб), поддержка SB16, AC97. Быть может, возникнут и еще некие потребности, но это пока основное.
В общем случае нужна "дубовая" система, из которой легко вырезать все ненужное, оставить только то, что необходимо.

Учитывая, что я сам кодирую только на асме (для платформы x86 любимый - FASM), - думаю попробовать приспособить для решения этих задачек именно колибри. Во всяком случае, разобраться с ней мне будет намного проще, нежели с линуксом тем же.

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

Ранее, года полтора назад, для аналогичных целей я написал с нуля свой экстендер защищенного режима. Однозадачный, целевая задача крутилась в 0-кольце. Теперь, с возникновением необходимости реализации какого-никакого юзеринтерфейса думаю, таки имеет смысл под ОС перелезть, чтоб не изобретать велосипед...

Саму колибри я пока не ковырял, лишь просто несколько раз позапускал для интереса на старых машинках (Р1,Р2), все Ок.
Конкретные вопросы по системе пока не оформились, но, по мере "ковыряния", думаю вылезут

Я всего лишь дизайнер и немножечко программер, потому просьба не пинать

1) На асме кодить под Колибри должно быть очень удобно.
2) Проги могут работать с железом напрямую.
3) Чтение и запись: FAT16, FAT32 (поддержка длинных имён), только чтение: NTFS, CD/DVD-диски (с мультисессией), это, я думаю, всем известно.
4) Поддержка видеорежимов разных, в т.ч. 1024x768 (сколько видеокарточка вытянет - у меня 1280х1024 стоит, хотя можно и 1600х1200). У меня начало складываться мнение, что Вы ни разу не запускали Колибри.
5) USB - начальная поддержка. Подробнее в этой теме: viewtopic.php?f=3&t=1033&start=30 Чтение и запись на флешки работает через V86, USB-мышь когда-как через этот драйвер, остальное не знаю.
6) SB16, AC97 - должны работать. Можно почитать этот пост: viewtopic.php?p=21889#p21889 и почитать эту тему: viewtopic.php?f=3&t=317&start=540
7) И что - Колибри пошла на Pentium'e I и II? Можно подробнее о параметрах этих компьютеров?
8 ) Надеюсь, наработки, если таковые окажутся, будут доступны пользователям Колибри

Удачи.

_________________
Через тернии к звездам

Leency, запускал я ее
Я лишь общие требования к ОС написал, безотносительно конкретно Колибри. То, что это в большинстве своем в ней реализовано - просто замечательно!

Насчет компов: запускал на 2-м пне, 350МГц, 128Мб, видюха NVidia какая-то (не охота залезать под стол и разглядывать),
и на 1-м пне 233МГц, 64Мб, -видюшка там х.з. какая, но линейную адресацию поддерживает.

Наработки, если будут, скрывать не планирую.

Линси, с 1600*1200 лично у меня не работает, как и прочее больше чем 1280*1024.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Gluk
Если монитор не держит, то и не будет.
Я лично, когда у меня был CRT (электронно-лучевая трубка) монитор запускал в качестве эксперимента. Еще когда Mike.dld выкладывал свое ядро с доработанной видеоподсистемой. Так что работа с такими разрешениями возможна при соблюдении двух условий:
1) Поддержка со стороны видеокарты.
2) Поддержка со стороны монитора.
Большинство приложений не нуждаются в доработке - они работают нормально при любом разрешении.

Anton
Ты попал абсолютно по адресу.. перед тобой простая, надёжная, гибкая система, с поддержкой всего, чего тебе надо... писать на Асме под неё исключительно удобно, и просто... к тому же она - одна из самых быстрых в мире!... возможно, даже самая быстрая... удачи в работе...

_________________
*****:
;дух машины, мой бубен сильнее твоей тупости

*****:

Если под этим понимается тот режим в котором работает DOS, то такого нет.

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

Система изначально делалась под графику.
Но если очень хочется ядро всегда можно подправить.

2 Serge
Меня тоже интересовал вопрос 3-го видережима. Как реализовать переход в него? (пусть даже исходный видеорежим не восстановится) И как будет выглядеть приложение, правильно (с точки зрения системы, изначально разработанной для оконного интерфейса) работающее в этом режиме?

Albom
Реализовать переход можно, но вот приложение никак не будет выглядеть - вообще система может перестать функционировать, если не отключить вызов всех обращений к видеопамяти.
Дело в том что сервисов нету для такого режима. И вообще если приложение расчитывалось на GUI то оно не сможет функционировать. А вот такие вещи как Launcher и ему подобные приложения не использующие GUI вполне будут работать, разумеется если принудительно отключить работу GUI и везде поставить заглушки (по крайней мере на первое время).

Приложения Колибри не расчитаны на работу в текстовом режиме и ядро не расчитано. Вывода на экран в текстовом режиме в ядре нет, так что его надо делать.

Но если подправить ядро вполне можно запускать одно приложение в текстовом режиме и дать ему доступ к текстовой видеопамяти. Для всяких экпериментов вполне сгодится.

Переход из загруженного графического режима можно сделать через v86 (при небольшой доработке) но проще открыть bootcode.inc, найти в самом конце
; SET GRAPHICS и удалить всё что не нужно или поставить там jmp gmok2.
После этого ядро будет работать в текстовом режиме

Есть и другой вариант - использовать эмуляцию при помощи console.obj

Serge
Ты забываешь, что MAIN LOOP тоже надо править.

Mario

Не обязательно. Достаточно чтобы были установлены параметры экрана. Пусть ядро думает что оно работает в графическом режиме.

Serge
Угу, и будет как в "Брпилиатовой руке":

Одно неверное движение и..