nedoPC.org

Взял исходник от лета 1998, переписал все комменты по английски и выложил на гитхаб:

https://github.com/shaos/ShaOS/blob/master/SHAOS.A

P.S. Линки на старые архивы:
http://www.nedopc.org/nedopc/shaos/s004_v0.zip (20K) - оригинальные исходники для RASM (1998)
http://www.nedopc.org/nedopc/shaos/s004_v0_.zip (13K) - перетранслированные в 2006 году исходники для ZMAC плюс TAP-файл:

По решётке выполнилась вот такая тест-программа:

Основная идея вектора переходов в ОЗУ была в том, что можно было на лету подменять любую из системных подпрограмм, а также выстраивать цепочки драйверов (по аналогии с обработчиками софтовых прерываний в DOS) скажем для поддержки операций с файлами на разных носителях.

P.S. Может быть перенастройку вывода в файл или на принтер делать точно также? Просто подменяя адрес перехода? т.е. команда
ECHO SOMETHING >FILE
будет выполнена путём подмены адреса перехода на функцию печати символа, выполнения ECHO и восстановления адреса перехода на функцию печати символа...

P.P.S. Вобщем в новой реинкарнации ShaOS надо перетасовать системные функции так, чтобы вначале шли зависящие от конкретного железа (или в конце), а не в перемешку, как сейчас...

Вместо ответвителя я наверное просто файлы-пустышки сделаю - это файлы у которых имя начинается с нуля. С другой стороны как-то надо отличать друг от друга стёртые файлы и файлы закрывающие собой битые части ПЗУ...

Вот "осовремененный" список стандартных расширений ShaOS (добавил специфические для ZX форматы в конец и SHJ):
0 - (три пробела) будет означать имя директория (точка при этом не печатается);
1 - .BAT для пакетных файлов;
2 - .SYS для перемещаемых "системных" программ (точность перемещения 1 байт, могут быть перенесены после загрузки);
3 - .COM для неперемещаемых программ, оттранслированных для какого-то конкретного адреса;
4 - .OVL для оверлеев, оттранслированных в какой-то конкретный адрес (загружаются из COM);
5 - .EXE для перемещаемых программ (точность перемещения 256 байт, не могут быть перенесены после загрузки);
6 - .DLL для перемещаемых библиотек (точность перемещения 256 байт, не могут быть перенесены после загрузки);
7 - .TXT для обычных досовских текстовых файлов в альтернативной кодировке;
8 - .CFG для текстовых файлов конфигурации;
9 - .BAK для копий текстовых файлов;
A - .TMP для временных файлов;
B - .BIN для бинарных данных, не привязанных к конкретным адресам;
C - .SCR для ZX-экранов;
D - .SNA для ZX-образов;
E - .TAP для ZX-лент;
F - .SHJ для скриптов SHJob (используется в nedoPC SDK).
Потом можно ещё 16 кодов добавить - от #10 до #1F.

Кроме того если код расширения файла представляет из себя код печатного символа, то он будет считаться однобуквенным расширением - примеры:
.A - текст программы для RASM;
.B - бейсик программа ZX;
.C - код для ZX;
.D - данные для ZX;
.L - файл статической библиотеки (для будущих версий nedoPC SDK);
.O - объектный файл (для будущих версий nedoPC SDK);
.R - текст программы на языке Robby (для nedoPC SDK);
.Z - ZX-образ в формате Z80?
В будущем могут быть .c и .h (для программ на языке Си), но пока ограничимся только большими буквами...

P.S. Атрибуты файла (по состоянию на 1996 год):
бит 0 - R (только для чтения);
бит 1 - H (скрытый);
бит 2 - C (закодирован?);
бит 3 - P (находитя на своём месте в памяти?);
бит 4 - F (фрагментирован?);
бит 5 - L (файл имеет расширенный заголовок в 32 байта вместо 16);
биты 6 и 7 - C0,C1 (совместимость кода - 00 для 8080, 01 для 8085, 10 для Z80, 11 - см.расширенный заголовок).
Расширенный заголовок с датой и временем создания файла пока не предполагается...

По поводу исполняемых файлов ShaOS:

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

EXE и DLL отличаются тем, что у EXE только одна точка входа (может быть где угодно по ходу файла) и он выгружается при возврате, а у DLL точек входа много и такой файл остаётся в памяти пока его не выгрузят программно.

SYS лепятся друг за другом в конец свободной памяти и остаются там пока их не выгрузят поимённо через специальный API.

(IMHO) у файлов должны быть такие аттрибуты :
{заархивированный/закодированный}
{фрагментированный/длинное_имя} -от удлинителя имени часть "отгрызть" для указателя на следующий фрагмент.*
{скрытый/системный}
{}
{разрешено_чтение}
{разрешена_запись}
{разрешено_выполнение}|\_и на каком цпу оно разрешено, а 11 пусть будет "не_разрешено"
{разрешено_выполнение}|/

*_То есть с этим флагом имя может выглядет как то так :
" |файл_с_длинным_и|[frag№]#{адр.след.фраг.}менем.TXT| "

Неее - никаких длинных имён

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

Ну тогда даже проще, пущай будут такие аттрибуты :

бит№0 {разрешена_запись}
бит№1 {скрытый/системный}
бит№2 {заархивированный/закодированный}
бит№3 { ??? }
бит№4 {фрагментированный/<зарезервировано>} -от удлинителя имени /-часть-/ все "отгрызть" для указателя на следующий фрагмент.*
бит№5 {разрешено_чтение}
бит№6 {разрешено_выполнение}|\_и на каком цпу оно разрешено, а 11 пусть будет "не_разрешено"*
бит№7 {разрешено_выполнение}|/

а что будет если чтение не разрешено? в чём смысл такого файла?

Ну .. это .. важные системные выполняемые файлы обычно имеют разрешение на выполнение и запрет на чтение и тем более запрет на запись. ( Хотя зачастую всё равно "root" может то, что не могут другие пользователи. )

Если ещё есть и запрет на запись в область памяти, где лежит выполняемый код, то это повышает надёжность системы.
( Для нищебродских решений на i8080 контроль доступа к памяти не очень актуален, ибо требует такого диспетчера памяти, который "навороченнее" самого i8080 )

Ну в этом и проблема - у меня нету суперпользователя
Поэтому флага read-only будет достаточно (для ПЗУ)
Значит пока пусть остаётся дизайн 1996 года:

Расширенный заголовок (вторые 16 байт заголовка, если флаг L=1):

Тогда в вот этот вот "резерв" и впихнуть адрес_следующего_фрагмента :

И 5й бит пущай на сие и указывает :

бит№5 {фрагментированный/<зарезервировано>} -от разширителя /-все-/ часть "отгрызть" для указателя на следующий фрагмент.*

не - фрагментированный файл с коротким заголовком тоже будет - у него в теле просто будут идти ссылки на фрагменты, являющиеся скрытыми файлами (не видимыми юзеру)

Битики в атрибутиках надо немного переставить:

биты 0 и 1 - C0,C1 (совместимость кода - 00 для 8080, 01 для 8085, 10 для Z80, 11 - см.расширенный заголовок);
бит 2 - E (закодирован);
бит 3 - F (фрагментирован);
бит 4 - S (находится на своём месте в памяти для ОЗУ или указатель);
бит 5 - H (скрытый);
бит 6 - R (только для чтения);
бит 7 - L (файл имеет расширенный заголовок в 32 байта вместо 16).

В случае директория (ext=0) младшие 4 бита атрибутов превращаются в 4 старших бита адреса ссылки (A20,A21,A22,A23).

P.S. Бит 4 (S) является признаком указателя (symlink) для всех накопителей кроме основного ОЗУ (где все заголовки по сути являются указателями т.к. хранятся отдельно от файлов), в этом случае младшие 4 бита атрибутов также превращаются в 4 старших бита адреса ссылки (A20,A21,A22,A23). Возможно для директориев установку бита 4 в "1" надо сделать обязательным, тогда указатель на конкретное место накопителя будет обрабатываться только в случае S=1 (с той лишь разницей, что для директория он будет указывать на цепочку файлов, лежащих в директории, а для файла-указателя - на конкретный файл, куда ссылается этот symlink).