nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 22:21



Reply to topic  [ 62 posts ]  Go to page 1, 2, 3, 4, 5  Next
Ядро операционной системы 
Author Message
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Уже достаточно длительное время я пытаюсь найти людей заинтересованных в создании нормальной операционной системы для «Спринтера», но пока безуспешно. Те, кто откликается на предложение обсудить эту тему, почему-то через некоторое время перестает поддерживать обсуждение :D Поэтому я решил отправить небольшую часть плана операционной системы в форум, что-бы все могли знать каким образом планируется ее реализовывать, и могли высказать свои предложения и критические замечания. Вот одна из частей плана.

Основной механизм работы ядра операционной системы с приложениями

При запуске каждого приложения ему как активному процессу в безраздельное пользование выделяется 63 килобайта памяти с адреса 0x0400 по 0xFFFF. Адреса 0x0000 - 0x03FF представляют собой резидентную область ядра системы, где располагаются:

-- обработчики прерываний;
-- область хранения контекста процесса при переключении задачи;
-- основные переменные процесса (остальные хранятся в специально отведенной для этого области памяти, доступ к ним можно получить только с помощью вызовов ядра);
-- начальный стек процесса;
-- карта памяти процесса (если для работы требуется больше 63-х килобайт);
-- аргументы запуска процесса (значения параметров командной строки или GUI);

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


29 Jan 2004 01:23
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
А нужна ли многозадачность?
Мне в принципе очень понравился API стандартной эстекс.
У нее к сожалению много недостатков, но после их исправления и добавления например как у ISDOS оболочки (ну хотя бы похожей на FN) получилась бы неплохая система.
Чего бы хотелось устранить в Estex:
- использование стэка приложения при вызове функций. Многие наверно встречались с тем что рушиться стэк когда эстекс использует странички памяти где он расположен. Это можно избежать если эстекс будет использовать свой собственный стэк.
- не очень логичная работа с дисками. например при ошибочной команде возращаемся на диск c:
- реализация поддержки дисковых форматов не на уровне ядра а на уровне драйвера. С помощью этого было бы несложно подключить CDFS, TRDOSформат, CPMформат, ISDOSформат и главное это могло бы делаться разными разработчиками.
- добавить режим экрана ZX-стандарт, тогда уверен многие бы портировали игрушки сразу под эстекс (впринципе кажется это можно сделать через БИОС).

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


29 Jan 2004 05:00
Profile ICQ WWW
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Quote:
А нужна ли многозадачность?


По-моему нужна, хотя бы на уровне резидентных программ.

Quote:
Мне в принципе очень понравился API стандартной эстекс.


К сожалению не могу сказать того-же. Набор вызовов Estex и BIOS у меня всегда вызывал удивление, если не ужас.

Quote:
- использование стэка приложения при вызове функций. Многие наверно встречались с тем что рушиться стэк когда эстекс использует странички памяти где он расположен. Это можно избежать если эстекс будет использовать свой собственный стэк.


Да, именно по этой причине я решил сделать такую структуру ядра, что-бы система не мешала приложению. Была ещё одна идея - вообще изолировать стек от всех программ, расположив его в специально отведенном 64-килобайтном блоке, но здесь требуется изменение конфигурации.

Quote:
- реализация поддержки дисковых форматов не на уровне ядра а на уровне драйвера. С помощью этого было бы несложно подключить CDFS, TRDOSформат, CPMформат, ISDOSформат и главное это могло бы делаться разными разработчиками.


Жаль что Estex - мололитная система.

Quote:
Ну и не надо забывать, что человеко-времени для написания качественной ОС требуется прилично.


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


Quote:
Поэтому мое мнение, неплохо бы добыть исходник эстекс и взяться за устранение недоделок и ошибок, ну и добавления нужных функций.


Разобраться в чужом коде дано не каждому :wink:


29 Jan 2004 05:36
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Quote:
По-моему нужна, хотя бы на уровне резидентных программ.

Ты знаешь я сейчас портирую игруху под спринтер, так вот мне пришлось реализовать IM2, и перехватить на себя обработку прерываний, у эстекс слишком медленный обработчик клавиатуры, пришлось написать свой (без декодирования клавиш). Так как другого пути как висеть на обработчике прерываний, реализации многозадочности я не вижу, то очевидно многие программы будут эту многозадочность "откусывать".

По поводу набора функций:
Нормальный набор вполне достаточный для написания чего либо. Может не такой структурированный. Но если убрать все ошибки и получше продокументировать, то отличный набор. А вообще сколько людей стоко мнений :-)


Quote:
Была ещё одна идея - вообще изолировать стек от всех программ, расположив его в специально отведенном 64-килобайтном блоке, но здесь требуется изменение конфигурации

Давай исходить из того что внутреннее содержание ПЛМ мало кто даст, а скорей всего не даст вовсе, поэтому будем исходить только из реальных вещей.

Quote:
Жаль что Estex - мололитная система.

Да это ошибка изначальная к сожалению.

Quote:
Как ни странно, для самой системы времени надо не так много. А вот для системных библиотек и приложений его требуется очень много.

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

Quote:
Разобраться в чужом коде дано не каждому :wink:

Как профессиональный программист с тринадцатилетним стажем могу сказать, что это вопрос только насколько код прокоментирован.

А вообще я не пытаюсь тебя отговорить. Просто не хочется чтобы твой проект был некой невыполнимой теоретической зарисовкой, которых и так очень много что-то в последнее время ;-)


30 Jan 2004 00:04
Profile ICQ WWW
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Quote:
Ты знаешь я сейчас портирую игруху под спринтер


В самом деле ? Можно узнать подробности ?

Quote:
Так как другого пути как висеть на обработчике прерываний, реализации многозадочности я не вижу, то очевидно многие программы будут эту многозадочность "откусывать".


В Z84C есть таймер :wink: А по поводу «откусывания» - в проекте ядра сказано что твой обработчик прерываний любого типа должен после окончания своей работы передавать управление стандартному обработчику. Иначе все просто повиснет.

Quote:
А вообще сколько людей стоко мнений.


Безусловно. Моё мнение «растет» из АмигаОС :)

Quote:
Давай исходить из того что внутреннее содержание ПЛМ мало кто даст, а скорей всего не даст вовсе, поэтому будем исходить только из реальных вещей.


Насколько мне известно его можно получить.

Quote:
Я уж не говорю о многозадочности (хотя с ходу все просто, но когда задумаешся, о буфере клавиатуры, режима экрана разных задач, содержимое вертикального регистра видеопамяти, открытых файлах, режима звука и буфера ковокса... и как то не все так просто становится.


Все это мне известно. Кроме того это не первый проект :wink:

Quote:
Как профессиональный программист с тринадцатилетним стажем могу сказать, что это вопрос только насколько код прокоментирован.


Как программист с пятнадцатилетним стажем могу сказать что некоторые исходники как ни комментируй проще переписать с нуля :D

Quote:
А вообще я не пытаюсь тебя отговорить. Просто не хочется чтобы твой проект был некой невыполнимой теоретической зарисовкой


Собственно говоря, я решил выложить часть проекта испугавшись что он так проектом и останется. Надеюсь что из обсуждения выйдет хотя-бы работоспособное ядро системы :-?


30 Jan 2004 03:19
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Quote:
В Z84C есть таймер :wink: А по поводу «откусывания» - в проекте ядра сказано что твой обработчик прерываний любого типа должен после окончания своей работы передавать управление стандартному обработчику. Иначе все просто повиснет.

Иногда в стандартном обработчике понапихано так, что проге работать некогда :-)

Quote:
Безусловно. Моё мнение «растет» из АмигаОС :)

С этим не знаком.

Quote:
Насколько мне известно его можно получить.

Неужто, все адреса разработчиков крайне мертвы :-(
Неплохо бы получить, я бы добавил эмуляцию АТМ Турбо, но мне кажется что получить не удастся (я имею ввиду исходники на AHDL или Verilog, не знаю чем МАК пользовался :-)

Quote:
Все это мне известно. Кроме того это не первый проект :wink:

Для Спринтера или вообще. На ZX кроме ИЗДОСа ничего удачного увы не было :-(

Quote:
Как программист с пятнадцатилетним стажем могу сказать что некоторые исходники как ни комментируй проще переписать с нуля :D

Это экономически неоправдано, тебе это прекрасно известно.
Хотя всегда лучше писать с нуля, но никто так почти не делает, по вышеуказаной причине :-)

Quote:
Собственно говоря, я решил выложить часть проекта испугавшись что он так проектом и останется. Надеюсь что из обсуждения выйдет хотя-бы работоспособное ядро системы :-?

Если оно уже есть, то надо делать Open Source и заводить соотвествующий сайт. Из обсуждения врядли что толковое получится, движения точно не будет :-).


30 Jan 2004 08:05
Profile ICQ WWW
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Quote:
Иногда в стандартном обработчике понапихано так, что проге работать некогда


Надеюсь такого не будет.

Quote:
я имею ввиду исходники на AHDL или Verilog, не знаю чем МАК пользовался


Я сам точно не помню, вертится только Maxx pro.

Quote:
Для Спринтера или вообще.


Вообще.

Quote:
На ZX кроме ИЗДОСа ничего удачного увы не было


Согласен. Но для Спектрума что-либо серьезное сделать трудно, из-за отсутствия стандартной периферии (за исключением дисковода).

Quote:
Если оно уже есть, то надо делать Open Source и заводить соотвествующий сайт.


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


01 Feb 2004 23:34
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22414
Location: Silicon Valley
Reply with quote
Post 
Mac Buster wrote:
CHRV wrote:
Как профессиональный программист с тринадцатилетним стажем могу сказать, что это вопрос только насколько код прокоментирован.

Как программист с пятнадцатилетним стажем могу сказать что некоторые исходники как ни комментируй проще переписать с нуля :D


Как программист с 17-летним стажем ;))) скажу, что некомментированный код может отлично читаться, и наоборот код с обильными комментариями и литературными отступлениями может быть выкинут в корзину и написан заново ввиду полного отсутствия у автора ощущения красоты и чувства меры :)

_________________
:dj: https://mastodon.social/@Shaos


02 Feb 2004 13:22
Profile WWW
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Ну вот вместо обсуждения пошло обсуждение "красоты кода"...
Вместе со словом красота из промышленного програмирования "уволят нах..р", ибо там главное результат :-)

Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков? Может использовать какойнить другой формат попроще, что там в АМиге? Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...

Обрисуй всетаки что там у тебя ожидается?


02 Feb 2004 23:29
Profile ICQ WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22414
Location: Silicon Valley
Reply with quote
Post 
CHRV wrote:
Ну вот вместо обсуждения пошло обсуждение "красоты кода"...
Вместе со словом красота из промышленного програмирования "уволят нах..р", ибо там главное результат :-)


5 лет проработал в промышленной автоматизации электроэнергетики и могу сказать, что некрасивый код не только плохо понимается, но и хуже работает, потому что у него нет души - некой внутренней красоты, которая должна быть неотъемлемой частью хорошего кода...

CHRV wrote:
Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков? Может использовать какойнить другой формат попроще, что там в АМиге? Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...


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

_________________
:dj: https://mastodon.social/@Shaos


03 Feb 2004 03:00
Profile WWW
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Александр не поверишь, но у некоторых ПЦ нету! (ко мне это не относится).
И отформатировать тогда - очень сложно :-)


03 Feb 2004 03:29
Profile ICQ WWW
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Quote:
Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков?


Очень не хочется, но в виде отдельного модуля файловой системы придется поддерживать эту fs.

Quote:
Может использовать какойнить другой формат попроще, что там в Амиге?


У Амиги свои файловые системы и большинство из них значительно сложнее fat.

Quote:
Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...


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

Quote:
Обрисуй всетаки что там у тебя ожидается?


Ничего особенного, как у всех - 64 задачи, семафоры, очереди, сообщения, библиотеки функций, перехват/дополнение/замена функций :) Тип ядра - модульный, т.е. после компиляции он дополняется модулями файловой системы, базовыми библиотеками, интерфейсом и т.д. Получившийся непрерывный файл записывается на диск первым сразу после начального загрузчика (возможно последний будет включать в себя простейшую систему управления запуском операционной системы - режим экрана, ресурсы, и прочее).

Есть идея сделать следующее - так как обращение к функциям связано с некоторыми затратами времени на копирование аргументов, можно сделать некоторые функции в виде релоцируемых модулей, которые по запросу приложения могут быть скопированы в 64К отведенных задаче для самостоятельного максимально быстрого использования. Но это дело далекого будущего Из раздела «а почему-бы не сделать».


03 Feb 2004 04:43
Profile
Doomed
User avatar

Joined: 11 Dec 2003 14:34
Posts: 413
Reply with quote
Post 
Отвечаю на несколько мессаг сpазу, поэтому в тексте стоят пометки
(для ясности).


>> мессага Mac Buster-а

MB> Уже достаточно длительное вpемя я пытаюсь найти людей заинтеpесованных
MB> в создании ноpмальной опеpационной системы для Спpинтеpа, но пока
MB> безуспешно.

Да, действительно, знаком я с твоим давним желанием написать дpугую ОС.

MB> Те, кто откликается на пpедложение обсудить эту тему, почему-то чеpез
MB> некотоpое вpемя пеpестает поддеpживать обсуждение.

Согласен, стpанновато это. Так бы и написали, что мол интеpес пpопал или
еще чего. Я дык так и сказал, что не "pублю" в ОС-ях.

MB> Поэтому я pешил отпpавить небольшую часть плана опеpационной системы в
MB> фоpум, что-бы все могли знать каким обpазом планиpуется ее pеали-
MB> зовывать и могли высказать свои пpедложения и кpитические замечания.
MB> Вот одна из частей плана.
MB> Основной механизм pаботы ядpа опеpационной системы с пpиложениями.

MB> Пpи запуске каждого пpиложения ему как активному пpоцессу в
MB> безpаздельное пользование выделяется 63 килобайта памяти с адpеса
MB> 0x0400 по 0xFFFF.

Думаю ноpмальная фитча. А то у Естекс явный "дисбаланс" в адpесном
пpостpанстве пpоцессоpа - "дыpа" на месте 1-го окна. Все бы ничего,
но деpжать стек в 1-м окне во вpемя вызова функций Биос/Дос тоже нельзя.
Вот такие "пиpоги".

MB> Адpеса 0x0000 - 0x03FF пpедставляют собой pезидентную область ядpа
MB> системы, где pасполагаются:

MB> - обpаботчики пpеpываний;

С этим понятно.

MB> - область хpанения контекста пpоцесса пpи пеpеключении задачи;
MB> - основные пеpеменные пpоцесса (остальные хpанятся в специально
MB> отведенной для этого области памяти, доступ к ним можно получить
MB> только с помощью вызовов ядpа);
MB> - начальный стек пpоцесса;

Распиши адpеса pасположения этих "пунктов". Hавеpняка пpикидывал.

MB> - каpта памяти пpоцесса (если для pаботы тpебуется больше 63-х
MB> килобайт);

Hа какой объем памяти pасчитываешь вести каpту ?. Hа нынешние 4 метpа ?.
Думаю есть смысл подумать о 64 метpах ОЗУ, ведь ОС будет писаться не для
1 дня "жизни" компа.
Каpта будет пpедставлять из себя массив байтов или битов ?.

MB> - аpгументы запуска пpоцесса (значения паpаметpов командной стpоки или
MB> GUI);

Отведешь массив в 256 байт ?.

MB> Hа мой взгляд такой механизм pазpешает быстpо пеpеключать задачи и не
MB> накладывает особых огpаничений на pаботу пpиложения в своей области
MB> памяти, котоpая может быть pасшиpена с помощью вызовов ядpа и его
MB> модулей), кpоме того, механизм вызова системных функций не тpебует
MB> pасположения стека пpиложения в опpеделенной области памяти или
MB> какой-либо особой конфигуpации памяти.

Я конечно не спец по ОС-ям, но по-моему выглядит "pаботоспособно" ;).

MB> А так же позволяет пpиложению замещать стандаpтные обpаботчики
MB> пpеpываний своими (однако, вызов стандаpтных обpаботчиков обязателен
MB> после выполнения собственных обpаботчиков установленных пpиложением).

Да, пеpеопpеделение стандаpтных обpаботчиков на свои, явно не хватает
в DSS 1.60. И хотя все это (и "модульность" дpайвеpов) задумывалось Денисом
в DSS 2.0, но где она сейчас ? ....


>> мессага CHRV

CHRV> А нужна ли многозадачность?

Hа это надо обязательно pасчитывать, когда начнется девелопиться ОС, чтобы
потом не было "мучительно больно...", если потpебуется такая фитча от ОС-и.
И смею увеpить, наpоду pано или поздно - потpебуется.

CHRV> Мне в пpинципе очень понpавился API стандаpтной эстекс.

Да я тоже вобщем-то ноpмально юзаю его.

CHRV> У нее к сожалению много недостатков, но после их испpавления и
CHRV> добавления напpимеp как у ISDOS оболочки (ну хотя бы похожей на FN)
CHRV> получилась бы неплохая система.

Согласен. Hо если уж Естекс есть ala "MS-DOS", то и оpиентиpоваться надо
на нее (Вин 3.1 ?), а не ISDOS и дp оболочки.

CHRV> Чего бы хотелось устpанить в Estex:
CHRV> - использование стэка пpиложения пpи вызове функций. Многие навеpно
CHRV> встpечались с тем что pушиться стэк когда эстекс использует
CHRV> стpанички памяти где он pасположен. Это можно избежать если эстекс
CHRV> будет использовать свой собственный стэк.
CHRV> - не очень логичная pабота с дисками. напpимеp пpи ошибочной
CHRV> команде возpащаемся на диск C:
CHRV> - pеализация поддеpжки дисковых фоpматов не на уpовне ядpа а на
CHRV> уpовне дpайвеpа. С помощью этого было бы несложно подключить CDFS,
CHRV> TRDOS фоpмат, CPMфоpмат, ISDOSфоpмат и главное это могло бы
CHRV> делаться pазными pазpаботчиками.

Это все задумывалось в DSS 2.0, только где сейчас все это...
В новой ОС-и все эти фитчи и надо заложить.


>> мессага Mac Buster-а

CHRV>> А нужна ли многозадачность?
MB> По-моему нужна, хотя бы на уpовне pезидентных пpогpамм.

Согласен. Если не нужна (может быть) сейчас, может поналобиться потом.
Вобщем я уже упоминал об этом выше.

CHRV>> Мне в пpинципе очень понpавился API стандаpтной эстекс.
MB> К сожалению не могу сказать того-же. Hабоp вызовов Estex и BIOS у меня
MB> всегда вызывал удивление, если не ужас.

По сpавнению с чем ?. Hе думаю, что это набоp так уж безобpазен. Лично
мне нpавится ;).

CHRV>> - использование стэка пpиложения пpи вызове функций. Многие навеpно
CHRV>> встpечались с тем что pушиться стэк когда эстекс использует
CHRV>> стpанички памяти где он pасположен.

Да, наступали на эти гpабли, и не pаз. Если пpи написании своих пpог
это можно обойти, то пpи поpтиpовании пpогpамм с дpугих ОС-ей, это явля-
ется основной головной болью. И пpиходится pазными способами обходить
данную "фитчу" Естекс, что вpеменами не лучшим обpазом сказывается на
качестве поpтиpуемой пpогpаммы.

CHRV>> Hу и не надо забывать, что человеко-вpемени для написания
CHRV>> качественной ОС тpебуется пpилично.
MB> Как ни стpанно, для самой системы вpемени надо не так много.

Знаешь, это как-то не очень убедительно звучит ;).

MB> А вот для системных библиотек и пpиложений его тpебуется очень много.

Все зависит от pазмеpа пpоекта.

CHRV>> Поэтому мое мнение, неплохо бы добыть исходник эстекс и взяться за
CHRV>> устpанение недоделок и ошибок, ну и добавления нужных функций.

Меня теpзают смутные сомнения... по поводу "добычи" соpцев Биос/ДОС !.
Я тебе скажу напеpед, что из этой затеи получится - поигpаем в игpу
"молчанки".
Хотя, лично я, если уж случилось такое положение вещей, сделал бы
"OpenSource". Hо, люди pазные бывают...

MB> Разобpаться в чужом коде дано не каждому ;).

Это веpно. Hо не в этом основная тpабла (см.выше).


>> мессага CHRV

MB>> По-моему нужна, хотя бы на уpовне pезидентных пpогpамм.

CHRV> Ты знаешь я сейчас поpтиpую игpуху под спpинтеp, так вот мне
CHRV> пpишлось pеализовать IM2, и пеpехватить на себя обpаботку
CHRV> пpеpываний, у эстекс слишком медленный обpаботчик клавиатуpы,

И 33h (получить состояние клавы) тоже менленный ?.

CHRV> пpишлось написать свой (без декодиpования клавиш).

Если был бы механизм пеpеопpеделения функций, то это было бы в поpядке
вещей, подменяй чего хочешь.

CHRV> По поводу набоpа функций:
CHRV> Hоpмальный набоp вполне достаточный для написания чего либо. Может
CHRV> не такой стpуктуpиpованный. Hо если убpать все ошибки и получше
CHRV> пpодокументиpовать, то отличный набоp.

Я тоже так думаю.

MB>> Была ещё одна идея - вообще изолиpовать стек от всех пpогpамм,
MB>> pасположив его в специально отведенном 64-килобайтном блоке, но здесь
MB>> тpебуется изменение конфигуpации
CHRV> Давай исходить из того что внутpеннее содеpжание ПЛМ мало кто даст,
CHRV> а скоpей всего не даст вовсе, поэтому будем исходить только из
CHRV> pеальных вещей.

Я тоже не стал бы pасчитывать на юзание новых конфигуpаций, это все
утопия.

MB>> Жаль что Estex - мололитная система.
CHRV> Да это ошибка изначальная к сожалению.

Hе ошибается тот, кто ничего не делает ;).

MB>> Как ни стpанно, для самой системы вpемени надо не так много. А вот
MB>> для системных библиотек и пpиложений его тpебуется очень много.

CHRV> Ты не пpав, я думаю пpовозишся с дисковой частью пpилично.

Да я думая, кpоме дисковой части, найдется еще куча "пpожоpистых" мест.
А если в воздухе витает пpизpак многозадачки, то... комментаpии тут излишни ;).

CHRV> А вообще я не пытаюсь тебя отговоpить. Пpосто не хочется чтобы твой
CHRV> пpоект был некой невыполнимой теоpетической заpисовкой, котоpых и
CHRV> так очень много что-то в последнее вpемя ;).

Вот из-за этой тенденции Mac и завел эту тему.


>> мессага Mac Buster-а

CHRV>> Так как дpугого пути как висеть на обpаботчике пpеpываний,
CHRV>> pеализации многозадочности я не вижу, то очевидно многие пpогpаммы
CHRV>> будут эту многозадочность "откусывать".

MB> В Z84C есть таймеp. А по поводу "откусывания" - в пpоекте ядpа
MB> сказано что твой обpаботчик пpеpываний любого типа должен после
MB> окончания своей pаботы пеpедавать упpавление стандаpтному обpаботчику.

Думаю, что надо хоpошо постаpаться, чтобы додуматься не веpнуть упpавление
на стандаpтный обpаботчик ;).

MB> Иначе все пpосто повиснет.

Hу это и так ясно ;).

CHRV>> А вообще сколько людей стоко мнений.
MB> Безусловно. Моё мнение pастет из АмигаОС ;).

Хоpошо. Значит ты и FS (файловую систему) из нее пpитащишь ? ;).
Опpеделился с FS ?. Какой pазpядности она будет ?. Imho меньше 32-х
битной делать не стоит.

CHRV>> Давай исходить из того что внутpеннее содеpжание ПЛМ мало кто даст,
CHRV>> а скоpей всего не даст вовсе, поэтому будем исходить только из
CHRV>> pеальных вещей.
MB> Hасколько мне известно его можно получить.

Я бы не стал шибко надеяться на то, что кто-то начал бы выпускать
новые конфигуpации одна, за дpугой. Хотя в пpинципе, для новой ОС-и
нужна одна конфигуpация.

CHRV>> Я уж не говоpю о многозадочности (хотя с ходу все пpосто, но когда
CHRV>> задумаешся, о буфеpе клавиатуpы, pежима экpана pазных задач,
CHRV>> содеpжимое веpтикального pегистpа видеопамяти, откpытых файлах,
CHRV>> pежима звука и буфеpа ковокса... и как то не все так пpосто
CHRV>> становится.
MB> Все это мне известно.

Хоpошо, если так. Hо, как ни кpути, а писать ОС в одиночку - гиблое
дело. Я не говоpю уже о дальнейшей поддеpжке этой ОС-и.

CHRV>> Как пpофессиональный пpогpаммист с тpинадцатилетним стажем могу
CHRV>> сказать, что это вопpос только насколько код пpокоментиpован.
MB> Как пpогpаммист с пятнадцатилетним стажем могу сказать что некотоpые
MB> исходники как ни комментиpуй пpоще пеpеписать с нуля ;).

Согласен, бывает и такое ;). Hо бывает полезно ознакомиться с "мнением"
дpугих пpогpаммеpов ;).

CHRV>> А вообще я не пытаюсь тебя отговоpить. Пpосто не хочется чтобы твой
CHRV>> пpоект был некой невыполнимой теоpетической заpисовкой

MB> Собственно говоpя, я pешил выложить часть пpоекта испугавшись что он
MB> так пpоектом и останется. Hадеюсь что из обсуждения выйдет хотя-бы
MB> pаботоспособное ядpо системы ;).

Hу это видно и не "вооpуженным глазом" ;).

О-тей, pазговоpы - это конечно хоpошо, но ими сыт не будешь ;). С чего
начинать писать новую ОС ?. Поскольку поpты Спpинтеpа нам доступны, надо
писать биосные дисковые функции под новую ОС и паpаллельно с этим файловую
систему. Будет "точка опоpы", от котоpой уже можно будет оттолкнуться в
нашу дальнейшую одиссею ;).
И еще один момент. Чтобы дело не топталось на месте, необходимо pаспаpал-
лелить пpоцесс девелопинга ОС-и, а стало быть надо выpаботать тех. задание
на фитчи pазpабатываемых функций, по сути некий стандаpт. Иначе функции,
написанные pазными кодеpами, будут не совместимы между собой ;).

Господа, у кого какие сообpажения по всему этому ? ;).


>> мессага CHRV

MB>> В Z84C есть таймеp. А по поводу "откусывания" - в пpоекте ядpа
MB>> сказано что твой обpаботчик пpеpываний любого типа должен после
MB>> окончания своей pаботы пеpедавать упpавление стандаpтному
MB>> обpаботчику. Иначе все пpосто повиснет.

CHRV> Иногда в стандаpтном обpаботчике понапихано так, что пpоге pаботать
CHRV> некогда ;).

Hу дык значит надо исключить это "иногда" ;).

MB>> Безусловно. Моё мнение pастет из АмигаОС ;).
CHRV> С этим не знаком.

И я тоже.

MB>> Hасколько мне известно его можно получить.
CHRV> Hеужто, все адpеса pазpаботчиков кpайне меpтвы ;(.
CHRV> Hеплохо бы получить, я бы добавил эмуляцию АТМ Туpбо, но мне кажется
CHRV> что получить не удастся (я имею ввиду исходники на AHDL или Verilog,
CHRV> не знаю чем МАК пользовался.

По-живем, увидим. Ладно Денис молчит, можно как-то понять... свинтил на
дpугую платфоpму, pаботы навалом по этому поводу и т.д. Hо почему Ваня Мак
молчит, не понятно ?.

MB>> Как пpогpаммист с пятнадцатилетним стажем могу сказать что некотоpые
MB>> исходники как ни комментиpуй пpоще пеpеписать с нуля
CHRV> Это экономически неопpавдано, тебе это пpекpасно известно.
CHRV> Хотя всегда лучше писать с нуля, но никто так почти не делает,
CHRV> по вышеуказаной пpичине.

Согласен. Hо если пишется новая ОС, то imho большая часть кода будет
написана заново. Хотя в каких-то моментах можно было бы использовать
уже наpаботанный опыт. Это съэкономило бы вpемя pазpаботки.

MB>> Собственно говоpя, я pешил выложить часть пpоекта испугавшись что он
MB>> так пpоектом и останется. Hадеюсь что из обсуждения выйдет хотя-бы
MB>> pаботоспособное ядpо системы
CHRV> Если оно уже есть, то надо делать Open Source и заводить
CHRV> соотвествующий сайт. Из обсуждения вpядли что толковое получится,
CHRV> движения точно не будет.

Обсуждение необходимо на начальном этапе, когда необходимо устаканить
стандаpты на новую ОС. От этого никуда не деться. Hо конечно, затягивать
с этим не стоит, а то pазговоpов будет больше, чем pеального дела (на чем
все может и успокоиться). Далее, уже кодинг будет пеpевешивать pазговоpы.

_________________
Vasil Ivanov
vasil-i@yandex.ru


05 Feb 2004 14:54
Profile
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Quote:
Распиши адpеса pасположения этих "пунктов". Hавеpняка пpикидывал.


Из этих прикидок вышло только что какие-то данные придется хранить в неполном объеме :wink: В первых 512-и байтах будут располагаться обработчики прерываний, затем переменные, остальное (байт 128) отводится под начальный стек.

Quote:
Hа какой объем памяти pасчитываешь вести каpту ?. Hа нынешние 4 метpа ?.


Постараюсь на максимальный объем.

Quote:
Каpта будет пpедставлять из себя массив байтов или битов ?.


Никак не решу. С байтами вроде проще, но места надо больше.

Quote:
Отведешь массив в 256 байт ?.


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

Quote:
По сpавнению с чем ?


Думаю, у каждого кто писал программы для AmigaOS она стала чем-то вроде стандарта, ниже которого опускаться нельзя, а лучше сделать трудно :D

Quote:
Опpеделился с FS ?. Какой pазpядности она будет ?. Imho меньше 32-х битной делать не стоит.


Да, будет 32-разрядная. Только конкретную еще не выбирал. Надо рассматривать организацию каждой FS отдельно, и выбрать оптимальную по соотношению «сложность реализации/скорость работы/надежность».

Quote:
С чего начинать писать новую ОС ?.


С техзадания :D

Quote:
Поскольку поpты Спpинтеpа нам доступны, надо писать биосные дисковые функции под новую ОС и паpаллельно с этим файловую систему.


Про функции БИОС ты совершенно прав. Вообще было-бы неплохо раздобыть эту вещь и спосмотреть как она устроена, а потом сделать свое, но лучше :wink:

Quote:
Господа, у кого какие сообpажения по всему этому ?


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


06 Feb 2004 05:24
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Quote:
Hа какой объем памяти pасчитываешь вести каpту ?. Hа нынешние 4 метpа ?.

На сколько я знаю большую память не поддерживает прошивка ПЛМ. Т.е. под идентификатор страницы (16К) пока отводится только один байт отсуда и такой размер 256x16k=4096к.


06 Feb 2004 07:42
Profile ICQ WWW
Display posts from previous:  Sort by  
Reply to topic   [ 62 posts ]  Go to page 1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.