Пишем свою ОС. Практика

[Zet9]

Вот нашёл эту книжку:
http://trd.speccy.cz/book/ZX_TRDOS.ZIP

---------- Post added at 18:10 ---------- Previous post was at 18:01 ----------

При наличии аппаратной реализации принципа "любая страница в любом окне" нужно планировать под память пользователя (программы/процесса) все 64к адресного пространства. Ядро держать в "теневой" странице и подключать только на время обращения к его функциям.

Так всё и будет
НО!
Не в первом же классе учить детей решать квадратные уравнения

[Advertiser]

[Rubts0FF]

Все это мне напоминает ситуацию, а-ля - почему нельзя на площади заняться сексом с женщиной, советами достанут.

[Vitamin]

это кем она планируется?
я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.

Сорри что вмешиваюсь, возможно упустив нить рассуждения. Какова цель данного "курса" по написанию оси? Поделиться/обменяться знаниями? Написать ось?

[GriV]

Вмешиваюсь как модератор:
1. Тема находится в разделе программирование - пишите сюда код и критикуйте код; если не увижу далее в теме кода, тема уедет в другой раздел;
2. Много подобных рассуждений уже было и на этом форуме: читаем и ищем в http://zx.pk.ru/forumdisplay.php?f=23 - там рассказывается и про ММУ, и про ядро, и про драйверы, и про файловую систему в т.ч.;
3. Прежде чем продолжать дискуссию не поленитесь заняться ликбезом, например прочитать книгу про то, как создаются ОСи. В качестве рекомендуемого издания: "Сетевые Операционные Системы" В.Г. Олифер, Н.А. Олифер.

я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.

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

[Zet9]

Операционная система Микроб
Версия 0.00.
Пока только ядро в составе рассмотренных выше драйверов клавиатуры и экрана, плюс исходники этих драйверов и драйвера: файловой системы тр-дос и дисковода (последний в двух вариантах - непосредственно работающий с ВГ93 и работающий через #3D13 - этот будет нужен для ускорения отладки(на винте, на рам-диске и т.д.), плюс лицензия
Загружается ядро и пишет на экран приветствие.

---------- Post added at 21:33 ---------- Previous post was at 21:23 ----------

Исходники в формате ассемблера Alasm
Файлы исходников:
DEVKBD - драйвер клавиатуры
DEVSCR32 - драйвер экрана - выводит 32 символа в строке
Материалы для драйверов - требуется "доработка напильником" для превращения в драйвера, пока не входят в состав ядра.
TRD - материал для драйвера файловой системы тр-дос
FDD_3D13 - "ненастоящий" драйвер дисковода, обращается к 3D13
FDD_VG93 - драйвер дисковода, для доступа к ВГ93 использует один из мини-драйверов
FDD_RAM - мини-драйвер ВГ93 - использует точку доступа 3D2F и часть процедур пзу трдос
FDD_CASH - мини-дайвер ВГ93 - напрямую обращается к ВГ93 - должен располагаться в кеше или в свободной области пзу тр-дос.

Изучаем, задаём вопросы,
быстрые ответы не обещаю[COLOR="Silver"]

---------- Post added at 21:53 ---------- Previous post was at 21:33 ----------

Сорри что вмешиваюсь, возможно упустив нить рассуждения. Какова цель данного "курса" по написанию оси?

Вроде ж в первых постах этой темы и "Теории" говорил о целях
Ну попробую ещё раз

Поделиться/обменяться знаниями? Написать ось?

Просто хочу поделиться своим видением вопроса.
Предлагаю сделать ось home use only, так сказать чисто для домашнего применения, которая не будет пытаться затмить уже существующее, и не должна распространяться, словно чума, на всё сообщество, а наоборот, призвана решать конкретные задачи её автора - это с одной стороны. А с другой стороны - сделать её достаточно простой и такой, чтобы любой желающий мог,изменив одну или несколько её частей, использовать в своих конкретных целях, без оглядки на "авторитеты", на "концепции и идеологии", так сказать "для себя любимого", ведь платформа Спектрум - это в первую очередь - свобода творчества, здесь можно делать то, что нужно именно тебе,и именно таким образом,которым удобно тебе, И над нами не довлеет человек,указывающий нам единствено верный, с его точки зрения, путь, и свернувший с этого пути У НАС, не будет тут же убит упавшим на него окном "Программа выполнила недопустимую операцию и будет закрыта".
А значит, можно делать что угодно в этом направлении, и в этой теме я хочу осветить некоторые возможности,доступные только на нашей платформе,[COLOR="Silver"]

[Zet9]

Моя программка на С для AT8535

Т.е. всё по-прежнему

Вмешиваюсь как модератор:
1. Тема находится в разделе программирование - пишите сюда код и критикуйте код;

модератора не слышим?
Неужели так трудно отвечать на оффтоп в теме "Пишем свою ОС.Теория" (если уж очень хочеться на него отвечать) ?

По-моему вы не с того начали.

Драйвера - это всё хорошо, но!

"Восходящий" метод пользуется популярностью даже у таких ГУРУ,как Кен Томпсон.
Мне тож нравиться

Есоли пишите ОС, то, ИМХО, вначале ответьте на такие вопросы:

Почти на все уже отвечал, можете полистать тему, если повезёт - в куче флэйма найдёте ответы - или ждите пока модератор очистит тему от мусора
Микроб однозадачный. Переключение задач и многозадачность будем изучать на следующих курсах.Это учебная ОС, поэтому вопрос совместимости в данном слуяае не важен. Впрочем никто не запрещает сделать запускалку для Бэйсиков,кодовых файлов,всяких там TRF-фов.

---------- Post added at 17:23 ---------- Previous post was at 17:14 ----------

Пришло время добавить нашему микробу какие-нибудь конечности, которыми он сможет грести к "светлому будущему"(уши,например).
Сегодня мы займемся файловой системой,ведь пока она не подключена к ядру, мы не можем загрузить ни задачу, ни конфигурационные файлы системы.
Брукс в своей книге "Мифический человеко-месяц" предлагает понаделать заменителей и заглушек, собрать всё в один главный цикл и как можно быстрее получить "Работающую версию программы".А в дальнейшем переделывать заменители на нужные функции, вместо заглушек добавлять модули, и при этом на каждом шаге разработки по-прежнему будет РАБОТАЮЩАЯ версия программы.
Для файловой системы в качестве предлагаемого заменителя будем использовать драйвер дисковода FDD_3D13,который в дальнейшем заменим на FDD_VG93.
Диспетчера виртуальной файловой системы пока у нас не будет, будем сразу обращаться к драйверу TRD,а тот будет вызывать FDD_3D13.
Но сделаем заготовки - обращаться к ним будем не напрямую, а через дополнительные JP XX, в которых сначала лежат адреса ЭТИХ драйверов, а позже будет подставляться диспетчером адреса драйверов для конкретных логических устройств.
Распределим память ядра следующим образом (впрочем это не обязательно окончательное решение):
Стэк пока будет общий для ядра и задачи - длиной 256 байт по адресам #5b00-#5c00.
Шрифт у нас длиной 2 Кб будет по адресу #7800 (это #8000-2Кб).
Буфер файловой системы для каталога длиной 2,25 Кб будет по адресу #6F00 (это #8000-2Кб-2.25Кб).
С адреса #6000 по #6A00 (примерно) сейчас расположен код ядра.
Свободным на данный момент 1,25 Кб после кода ядра и .5 КБ до кода ядра по адресу #5e00.
Драйвер FDD_3D13 принимает номер функции в рег. A,содержит 3 функции:
0-выбрать диск , в рег.C - номер дисковода 0,1,2 или 3
1-прочитать несколько(в рег.B) блоков по 256 байт в буфер по адресу HL',номер блока в рег. DE (младшие байты номера) и в рег. DE' (старшие байты)
2-записать блоки - входные параметры такие же ,как для функции 1
TRD - драйвер файловой системы TR-DOS принимает номер функции в рег. А и пока обрабатывает только функцию 4, это функция чтение части файла в буфер по адресу HL',длина части в блоках по 256 байт в рег.B, а в рег. HL адрес таблицы параметров вызова длиной 32+11. Первые 32 байта будут использоваться для хранения различных данных,необходимых для работы с этим файлом, рассмотрим их позже.Последние 11 байт это имя файла 8 байт+3 байта расширение. В дальнейшем длину имени и расширения можно будет увеличить.

Сделаю отступление насчет функций файловой системы.Мы сейчас не будем использовать OPEN,CLOSE, поскольку во-первых, у нас однозадачная,однопользова� �ельская система и нет необходимости в захвате файлов одной задачей,для прекращения доступа к этому файлу другими задачами. Во-вторых,у нас чтение и запись будут по блокам напрямую с/на диск, а не по байтам,и не будет системного буфера, в котором могут быть несохранённые данные, и которые надо сохранить, используя CLOSE.
И ещё,если бы мы их использовали, то вот те 32+11 байта должны были бы располагаться в памяти ядра(хотя это можно конечно и обойти), что неминуемо привело бы к ограничению на количество одновременно открытых файлов,в необходимости создания механизма для обработки этих операций - а это не есть очень просто.
Впрочем в будущем можно будет их использовать, а пока наш микроб обойдется без них

Теперь рассмотрим способы вызова функций ядра из задачи.
Будем использовать передачу параметров вызова в регистрах для тех функций,в которых параметры помещаються в регистры - сейчас это у нас функции 0 - "вывод строки символов на экран" и 1 - "получить символ с клавиатуры".
И второй способ для тех функций, параметры которой не помещаются в регистры, в котором будем оставшиеся параметры передавать в таблице,а в регистровой паре HL (или в другой) будет адрес этой таблицы. Этот способ используем для рассмотренной выше функции 2 - "чтение части файла".
Номер функции (пока что одной из этих 3-х) будем передавать в рег. A.
Ну и остается определиться,откуда задача узнает адрес точки входа в ядро, на который необходимо передавать управления при вызове функций.
Просто при запуске задачи будем передавать ей этот адрес в рег.HL и задача сохранит его в памяти и будет использовать.
Это даст нам возможность не привязывать точку входа в ядро, и даже в дальнейшем менять его перед запуском программы (например при большой её длине).

Для проверки этих функций будем использовать простейшую программу показа текста AUTOLOAD.MIC.Эту программу ядро загружает и запускает после печати приветствия.Запущенная программа (уже задача) печатает своё название и строку "загружаем текст" - вызывая функцию 0 (вывод строки символов).
Далее с помощью вызова функции 2 (чтение части файла) - задача загружает
текст в память задачи.В случае ошибки - выводит сообщение и ждет нажатие любой клавиши с помощью вызова функции 1 (получить символ с клавиатуры).
После успешной загрузки текста выводит его на экран постранично (функция 0).
(Уже заметна не высокая скорость заполнения экрана).
После каждой страницы ждёт нажатия любой клавиши и выводит следующую страницу.
По окончании текста возврат в ядро с помошью простой команды RET. (В дальнейшем мы добавим функций EXIT и задача будет завершаться,вызывая эту функцию).
И далее ядро перезапускает TR-DOS.
Поскольку книженции в стиле "криминального чтива" сразу не нашлось,на первое время закинул на дискету 1-ю главу книги У.Гибсона "Перегруженная Мона Лиза".

[Vovoi]

.....Диспетчера виртуальной файловой системы пока у нас не будет, будем сразу обращаться к драйверу TRD,а тот будет вызывать FDD_3D13.

А не хочешь в приложении сразу реализовать упрощенное "SAVE 16384,6912" , а потом заниматься уже драйверами? То есть:
LD HL, data;адрес данных
LD DE, lenght; длина
CALL save1;save1-TR-DOS, save2-RAMDISK, save3-MsDOS...
И "шапка" драйвера сама уже все разложит по полочкам, избавляя кодера от расчетов. Мне бы хотелось сделать именно так, разгрузив само приложение.

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

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

..После успешной загрузки текста выводит его на экран постранично (функция 0).
(Уже заметна не высокая скорость заполнения экрана)...

Это нормально, у тебя же не оживленная игра, а операционка. Что-то все равно будет теряться.

[Zet9]

Пример с программой показа текста
Добавились файлы FS.H - это заменитель диспетчера вирт.файл.системы
и AUTOLOAD.H - исходник программы показа

[Zet9]

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

Этот способ ограничивает свободу приложения в плане того , что обязательно должен быть заголовок определенной длины в определенном месте программы - например в начале файла заголовок 100 байт - в результате - этот заголовок нарушает все планы - если код упакован упаковщиком - драгоценной памяти в моем варианте тратиться на 3 байта больше:
LD (OS+1),hl

---------- Post added at 13:42 ---------- Previous post was at 13:34 ----------

А не хочешь в приложении сразу реализовать упрощенное "SAVE 16384,6912" , а потом заниматься уже драйверами? То есть:
LD HL, data;адрес данных
LD DE, lenght; длина
CALL save1;save1-TR-DOS, save2-RAMDISK, save3-MsDOS...

В чем упрощение? Надо смотреть в будущее
трдос-дисков и мс-дос-дисков у нас может быть по 4 штуки, рам-дисков до 6 штук (на 4-х метровой Пентеве) - итого уже 14 адресов функций только для записи, потом мы захотим добавить 2 сдрома, 2 сд-карты, 2 винта по 8 разделов - и уже получаем 34 адреса только для save - save1...save34
А ведь нам ещё надо по столько же для функций load,create,delete,rename,cat - сам умножь 34*6 - и ужаснись
а если в новой версии ядра адреса изменяться?
Надо делать табличку из двух сотен JP XX - сколько она займет - около 610 байт
а если мы захотим при каждом вызове ядра выполнять одинаковое действие - например ставить свой указатель стэка - перед этим запоминать стэк задачи в ячейке памяти?
простым CALL NEW_STACK - уже не отделаешься!
Предлагаю ученику Vovoi - аргументировать своё предложение

[GriV]

Ученик Zet9! прочитали ли Вы список рекомендуемой литературы? Ознакомились ли с рекомендованными ссылками?