[quote="Mac Buster"]
VI>> Распиши адpеса pасположения этих "пунктов". Hавеpняка пpикидывал.
MB> Из этих прикидок вышло только что какие-то данные придется хранить
MB> в неполном объеме. В первых 512-и байтах будут располагаться обработ-
MB> чики прерываний, затем переменные, остальное (байт 128) отводится под
MB> начальный стек.
0000 ----------
Рестарты обработки прерываний
512 байт
01FF ----------
0200 ----------
?? байт
???
0xxx ----------
0xxx ----------
Указатели на аргументы ком-строки консоли
массив ?? байт
037F ----------
0380 ----------
Стек
128 байт
03FF ----------
VI>> Hа какой объем памяти pасчитываешь вести каpту?. Hа нынешние 4 метpа?.
MB> Постараюсь на максимальный объем.
Надо расчитывать на 64 метра. Ваня Мак планировал поддерживать такой
объем блоками по 4 метра нынешнего распределения памяти. При такой
поддержке памяти, не исчезнет совместимость с уже существующими програм-
мами (т.е. работающими со "старым" распределением памяти).
VI>> Каpта будет пpедставлять из себя массив байтов или битов ?.
MB> Никак не решу. С байтами вроде проще, но места надо больше.
Делай как массив битов. Иначе тебе данную карту придется раздувать в 8
раз, что не есть хорошо, сам прекрасно знаешь. Imho это будет не самым
слабым звеном, в плане скорости работы FS.
VI>> Отведешь массив в 256 байт ?.
MB> Планирую сразу разбирать командную строку терминала и хранить только
MB> указатели на слова, отделенные пробелами.
А где же тогда будешь хранить сами слова ?, тем более в многозадачке,
где могут запускаться еще куча программ. Может лучше ком-строку каждого
запущенного приложения хранить в "префиксе" 0x0000...0x3FFF своего прило-
жения ?. И не надо для этого занимать место в служ. буферах ОС.
В качестве разделителей аргументов, нужно предусмотреть не только одни
пробелы, но и как минимум ",", возможно еще "=". Если в ком. строке будут
табуляции, то обрабатывать и табуляции.
MB> Думаю, у каждого кто писал программы для AmigaOS она стала чем-то
MB> вроде стандарта, ниже которого опускаться нельзя, а лучше сделать
MB> трудно
.
А лучше делать и не надо
. Все хорошо в меру. Поделись об особенностях
(фитчах) этой АмигаОС.
VI>> Опpеделился с FS ?. Какой pазpядности она будет ?. Imho меньше 32-х
VI>> битной делать не стоит.
MB> Да, будет 32-разрядная. Только конкретную еще не выбирал. Надо рас-
MB> сматривать организацию каждой FS отдельно, и выбрать оптимальную по
MB> соотношению "сложность реализации/скорость работы/надежность".
Imho надо было с самого начала выбрать FS и только потом планировать
остальные части новой ОС. Лог. диски в АмигаОС тоже надо монтировать
как в *nix-ах ?. Если так, то можно за основу взять FS от UZIX и доработать
ее для новой ОС-и. Все легче, чем начинать с "чистого листа".
Насколько я помню, название своей ОС-и ты дал "Ozon" ?. Значит давай
его юзать
.
Было бы не плохо в FS юзать бинарное дерево для работы с именами файлов
(поиск имени файла, поиск свободного места в FS).
VI>> С чего начинать писать новую ОС ?.
MB> С техзадания.
Вот и я о том же
. Надо его выработать.
VI>> Поскольку поpты Спpинтеpа нам доступны, надо писать биосные дисковые
VI>> функции под новую ОС и паpаллельно с этим файловую систему.
MB> Про функции БИОС ты совершенно прав. Вообще было-бы неплохо раздобыть
MB> эту вещь и спосмотреть как она устроена, а потом сделать свое, но лучше.
Я тоже разделяю такой подход к проблеме
. Только вот бывшая Sprinter
Team отмолчится, со всеми вытекающими...
А что тебя интересует в Биосе: вывод на экран, выделение памяти, обработка
клавы, структура экранов ?.
MB> Можем для начала определиться какие должны быть функции у основного
MB> модуля ядра, а какие у остальных модулей. Под функциями подразуме-
MB> ваютcя конкретные вызовы.
Если уж ты постоянно говоришь о АмигаОС
, то возможно есть смысл
огласить общественности список данных функций этой ОС-и.