Операционная система ShaOS

[Shaos]

Формат квазидисков операционки ShaOS:

Cтруктура аналогична ордосу - у каждого файла есть 16-байтовый заголовок (есть возможность иметь 32-байтовый - с меткой времени), среди файлов могут попадаться подкаталоги. Формат простого заголовка:

Code: Select all

struct HEADER
{
   char name[8];
   BYTE ext;
   UINT len;
   UINT adr;
   BYTE atr;
   UINT kc;
};

где
name - имя файла или каталога
ext - однобайтовое представление расширения файла (есть стандартная таблица перекодировки), для имени подкаталога оно 00
len - длина файла в параграфах (т.е. кратно 16 байтам), для подкаталога - 0000 (используется при пробегании по файлам для поиска следующего файла)
adr - адрес загрузки файла, для подкаталога - FFFF
atr - атрибуты файла
kc - контрольная сумма для файла, а для подкаталога это является указателем в параграфах (т.е. кратно 16 байтам) внутри образа диска на цепочку файлов-подкаталогов этого подкаталога

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

[Shaos]

В связи с очередным осенним обострением я решил подружить nedoPC-580M и ShaOS. Идея заключается в добавлении в эту операционку многозадачности!
Чётко можно выделить 4 категории железяк, на которых эта операционка потенциально может работать:
1) один процессор i8080/i8085/z80 с фиксированной памятью без прерываний (РК86);
2) один процессор i8080/i8085/z80 с фиксированной памятью и прерываниями по таймеру (оригинальный ZX48);
3) один процессор i8080/i8085/z80 с банками памяти и прерываниями по таймеру ("современные" ZX клоны, например Sprinter);
4) несколько процессоров i8080/i8085/z80 с общей памятью, разделённой на банки, а также прерываниями по таймеру (nedoPC-580M).
Я вчера осознал, что программист может писать одну мультитредную программу, которая может работать на любой из выше-перечисленных категорий железа БЕЗ перекомпиляции! Для этого всего-то лишь надо придумать вменяемый API и написать 4 варианта операционки для каждой категории:
1) поддерживается кооперативная многозадачность, нет возможности непосредственно аллоцировать большие объёмы памяти (но можно реализовать работу с виртуальной памятью, находящейся на внешнем носителе);
2) поддерживается вытесняющая многозадачность и виртуальная память (см.выше);
3) поддерживается вытесняющая многозадачность и возможность непосредственной аллокации больших объёмов памяти (плюс виртуальная память);
4) поддерживается вытесняющая многозадачность и параллельная работа процессов на разных процессорах с общей памятью, а также большие аллокации и возможность использования виртуальной памяти.

[aav8]

В связи с очередным осенним обострением я решил подружить nedoPC-580M и ShaOS. Идея заключается в добавлении в эту операционку многозадачности!
Чётко можно выделить 4 категории железяк, на которых эта операционка потенциально может работать:
1) один процессор i8080/i8085/z80 с фиксированной памятью без прерываний (РК86);
2) один процессор i8080/i8085/z80 с фиксированной памятью и прерываниями по таймеру (оригинальный ZX48);
3) один процессор i8080/i8085/z80 с банками памяти и прерываниями по таймеру ("современные" ZX клоны, например Sprinter);
4) несколько процессоров i8080/i8085/z80 с общей памятью, разделённой на банки, а также прерываниями по таймеру (nedoPC-580M).
Я вчера осознал, что программист может писать одну мультитредную программу, которая может работать на любой из выше-перечисленных категорий железа БЕЗ перекомпиляции! Для этого всего-то лишь надо придумать вменяемый API и написать 4 варианта операционки для каждой категории:
1) поддерживается кооперативная многозадачность, нет возможности непосредственно аллоцировать большие объёмы памяти (но можно реализовать работу с виртуальной памятью, находящейся на внешнем носителе);
2) поддерживается вытесняющая многозадачность и виртуальная память (см.выше);
3) поддерживается вытесняющая многозадачность и возможность непосредственной аллокации больших объёмов памяти (плюс виртуальная память);
4) поддерживается вытесняющая многозадачность и параллельная работа процессов на разных процессорах с общей памятью, а также большие аллокации и возможность использования виртуальной памяти.

Примерно такакая идеология имела в свое время
системв RT-11 от DEC. Имелись разные мониторы:
SJ - для одной задачи
MJ - многозадачная
XM - расширенная память
BL - вообще без ОС
(кажется примерно такие названия)
Начсет API есть кое-какие идеи/наработки, и кое-что работает...

[MC68k]

P.S. Откопал в своих старых бумагах, что название ShaOS я придумал 25 января 1998 года, а до этого (примерно с апреля 1996) система имела кодовое наименование S004, а ещё раньше (конец 1992) - SH-DOS или ROS (Radio Operating System)...

вот с этого места поподробнее, пожалуйста

[Shaos]

P.S. Откопал в своих старых бумагах, что название ShaOS я придумал 25 января 1998 года, а до этого (примерно с апреля 1996) система имела кодовое наименование S004, а ещё раньше (конец 1992) - SH-DOS или ROS (Radio Operating System)...

вот с этого места поподробнее, пожалуйста

Имелось ввиду ОС для Радио-86РК, которую я писал прямо в кодах в тетрадочке

[Shaos]

Начсет API есть кое-какие идеи/наработки, и кое-что работает...

Ну рассказывай

[aav8]

Ну рассказывай

Основная мысля была в отношении файловой системы:
Сама ось (и тем более какая-либо программа) ничего
не знает как устроены каталоги и как и где
располагаются файлы. Все это ложится на драйвер устройства.
Т.е. ось просто передает файловые запросы конкретному устройству
запросы типа:
Открыть файл <устройство>:[имя файла]. возвращается
какой-то идентификатор.
Прочитать/записать чего нибудь. Если при открытии файла имя файла
было пустое - при чтении выдается каталог этого устройства.
Конечно закрыть файл.
И какие-то дополнительные функции, о которых знает утилита,
специфичная для этого конкретного устройства.
Сама ось ничего не умеет, кроме как загрузить какой-то файл и передать ему управление.
т.е. что-бы посмотреть каталог я набираю:
LN:DIR.EXE LN:
Сейчас работают устройста:
ТТ: - терминал (как файловое устройство).
LN: - файлы на PC через COM-порт.
RM: - файлы в ПЗУ.
Все это вертится в связке Партнер 01.01 + win98.
На win98 также есть терминал к партнеру (все-таки на PC кнопки
удобнее).
По идее это не совсем OS (как-бы OS / 2 или даже OS / - больше
похоже на что-то вроде ядра, к которому пристегивается
необходимый функционал.
Подробнее - чуть позже - надо все это дело разыскать - давно не занимался...

[Shaos]

У меня примерно также - драйвера файловой системы, выстроенные в цепочку и обрабатывающие только свои диски. У меня правда более классические наименования дисков - A:, B:, C:

[aav8]

У меня примерно также - драйвера файловой системы, выстроенные в цепочку и обрабатывающие только свои диски. У меня правда более классические наименования дисков - A:, B:, C:

Я все делал в таблицах.
В таблице назватие девайса и его адрес.
А там еще таблица кажется на 8 входов с адресами функций.
Две буквы в названии, чтобы можно было различать или не различать
тот-же терминал/принтер/<еще чего нибудь> от склада файлов.
А как в nix* - все из корня - для 8 разрядов тяжеловато.

[VituZz]

А как в nix* - все из корня - для 8 разрядов тяжеловато.

Зато, на мой взгляд, чудовищно удобно.
И вообще, некоторые академические товарищи утверждают, что файловая система must die .

[aav8]

А как в nix* - все из корня - для 8 разрядов тяжеловато.


Зато, на мой взгляд, чудовищно удобно.
И вообще, некоторые академические товарищи утверждают, что файловая система must die

Такая идеология изначально была в nix*.
Мне не понравилось деление на блоковые/неблоковые устройства.
все из корня - действительно удобно и красиво. но для 8 разрядов тяжеловато (повторяюсь) поэтому весь функционал (конкретно файлы) переложил на PC.
Еше подумывал в командной строке такую конструкцию:
??:>LM.ROM.EDIT
должен будет вызваться этот объект (в данном случае, к примеру, редактор)
Примерно таким-же образом и доступ ко всему остальному
... обработка строк в x80 ...

[b2m]

И вообще, некоторые академические товарищи утверждают, что файловая система must die .

Даже если заменить файловую систему на базу данных и/или сериализуемые на диск объекты, всё равно любую древовидную иерархию объектов можно считать файловой системой. Вряд-ли объекты в такой системе будут безымянными, а древовидная именованная иерархия объектов - это и есть файловая система.

[Shaos]

Снова выложил описание операционки SHAOS от 1998 года:

http://nedopc.org/nedopc/shaos/shaos.htm

Думаю при реанимировании упаковать вектор вызовов системных подпрограмм покомпактнее, чтобы было без дырок, тогда в область #CCxx влезет 256/3=85.33 переходов на подпрограммы...

[Shaos]

Смотрю в свои старые тетрадки - весной 1994 я выдумал способ писать перемещаемые программы для 8080 под названием SYS-TRANS - суть в том, что переходы и вызовы подпрограмм по конкретным адресам (а также обращение к памяти за данными) происходят не напрямую, а через специальные подпрограммы, которые модифицируют адрес в соответствии с тем, в каком месте памяти загружена такая программа. Вот слегка переработанный вариант такого подхода, который можно вставить в новую ShaOS:

Предположим у нас есть подпрограмма SYS по адресу #CCFC, которая при вызове залезает по адресу возврата и берёт один или более байтов идущих следом за вызовом, чтобы сделать сдедующее:
CD FC CC 00 - корректировка регистровой пары BC путём прибавления к ней базового адреса загрузки SYS-программы;
CD FC CC 10 - корректировка регистровой пары DE путём прибавления к ней базового адреса загрузки SYS-программы;
CD FC CC 20 - корректировка регистровой пары HL путём прибавления к ней базового адреса загрузки SYS-программы;
CD FC CC 30 - по адресу HL находитя имя SYS-программы (с аргументами), которую надо загрузить (если ещё не загружена) и выполнить;
CD FC CC xx yy zz - во всех остальных случаях базовый адрес прибавляется к zzyy и оно вместе с xx копируется в специальную область памяти, где находятся 6 байтов:
xx yy' zz' C3 aa bb - где bbaa это адрес следующего за zz байта, т.е. таким образом можно корректировать адреса в трёхбайтовых командах 8080 - таких как условные переходы или условная передача управления. Вот собственно код (пока без логики загрузки):

Code: Select all

SYS-BASE DW 0
SYS-TEMP DW 0
SYS-CODE DB 0,0,0,0,0,0 

SYS:
 SHLD SYS-TEMP ; запоминаем HL
 POP HL ; вытаскиваем адрес возврата
 PUSH PSW ; запоминаем на стеке аккумулятор и флаги 
 MOV A,M ; читаем байт по адресу возврата
 INX H ; инкрементируем HL
 CPI #00 ; проверяем прочитанный байт на #00
 JNZ SYS1 ; если не равно, то идём на SYS1
 POP PSW ; восстанавливаем аккумулятор и флаги
 PUSH H ; запоминаем на стеке новый адрес возврата
 LHLD SYS-BASE ; загружаем базовый адрес текущей SYS-программы
 DAD B ; корректируем адрес BC
 PUSH H ; кладём HL на стек
 POP B ; снимаем со стека BC
 LHLD SYS-TEMP ; восстанавливаем HL
 RET ; возвращаемся
SYS1:
 CPI #10 ; проверяем прочитанный байт на #10
 JNZ SYS2 ; если не равно, то идём на SYS2
 POP PSW ; восстанавливаем аккумулятор и флаги
 PUSH H ; запоминаем на стеке новый адрес возврата
 LHLD SYS-BASE ; загружаем базовый адрес текущей SYS-программы
 DAD D ; корректируем адрес DE
 PUSH H ; кладём HL на стек
 POP D ; снимаем со стека DE
 LHLD SYS-TEMP ; восстанавливаем HL
 RET ; возвращаемся
SYS2:
 CPI #20 ; проверяем прочитанный байт на #20
 JNZ SYS3 ; если не равно, то идём на SYS3
 POP PSW ; восстанавливаем аккумулятор и флаги
 PUSH H ; запоминаем на стеке новый адрес возврата
 PUSH D ; запоминаем на стеке DE
 LHLD SYS-TEMP ; восстанавливаем HL
 XCHG ; меняем местами DE и HL
 LHLD SYS-BASE ; загружаем базовый адрес текущей SYS-программы
 DAD D ; корректируем адрес сохраняя его в HL
 POP D ; восстанавливаем DE 
 RET ; возвращаемся
SYS3:
 CPI #30 ; проверяем прочитанный байт на #30
 JNZ SYS_ ; если не равно, то идём на SYS_
 POP PSW ; восстанавливаем аккумулятор и флаги
 PUSH H ; запоминаем на стеке новый адрес возврата
 ; TODO: загрузка SYS-файла в память
 LHLD SYS-TEMP ; восстанавливаем HL
 RET ; возвращаемся
SYS_:
 STA SYS-CODE ; запоминаем байт после вызова как команду
 PUSH D ; запоминаем DE
 MOV E,M ; читаем следующий байт
 INX H ; инкрементируем HL
 MOV D,M ; читаем следующий байт
 INX H ; инкрементируем HL
 MVI A,#C3 ; запоминаем в аккумуляторе код #C3
 STA SYS-CODE+3 ; запоминаем код #C3
 SHLD SYS-CODE+4 ; запоминаем адрес возврата после команды JMP
 LHLD SYS-BASE ; загружаем базовый адрес текущей SYS-программы
 DAD D ; корректируем адрес сохраняя его в HL
 SHLD SYS-CODE+1 ; запоминаем значение HL в коде
 POP D ; восстанавливаем DE
 POP PSW ; восстанавливаем аккумулятор и флаги
 JMP SYS-CODE ; передаём управление на сформированную последовательность инструкций

[Shaos]

Ну и второй способ представления перемещаемых программ это когда к коду приделан bitmap размером 1/8 размера кода, где каждый бит отвечает за байт кода и сигнализирует о том, что этот байт содержит старшую половину адреса и должен быть модифицирован при загрузке в определённую область памяти (с шагом 256 байт) - такими будут EXE и DLL файлы (см. мой LIBMAN, написанный в 2002 году для Спринтера). Получить такой битмап очень просто - компилируем ASM-программку с ORG 0 (и именно этот код используем при создании файла), а потом с ORG 256 и побайтно сравниваем с предыдущим кодом - если байты отличаются, то битик в битмапе ставится в 1.

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

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

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