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

Публичный форум для http://www.nedopc.org/nedopc

Moderator: Shaos

User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

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

Ну и EXE файл может подвешиваться резидентом, подменяя некоторые системные вызовы в векторе переходов - например такими резидентами могут быть разные текстовые драйвера - на 42 символа в строке, на 64 символа в строке и т.д.
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

Re: Re:

Post by Shaos »

Вспомнил, что изначально в 90х я задумывал именно такое кодирование для расширения файлов, чтобы первые несколько вариантов использовались для поиска исполняемого файла для выполнения команды, если она была задана без расширения - сначала ищется файл .BAT, потом .SYS, потом .COM и уже в самом конце - .EXE:
Shaos wrote:Вот "осовремененный" список стандартных расширений ShaOS (добавил специфические для ZX форматы в конец и SHJ):
0 - (три пробела) будет означать имя директория (точка при этом не печатается);
1 - .BAT для пакетных файлов;
2 - .SYS для перемещаемых "системных" программ (точность перемещения 1 байт, могут быть перенесены после загрузки);
3 - .COM для неперемещаемых программ, оттранслированных для какого-то конкретного адреса;
4 - .EXE для перемещаемых программ (точность перемещения 256 байт, не могут быть перенесены после загрузки);
6 - .OVL для оверлеев, оттранслированных в какой-то конкретный адрес (загружаются из COM);
6 - .DLL для перемещаемых библиотек (точность перемещения 256 байт, не могут быть перенесены после загрузки);
7 - .BAS для программ на языке Бейсик (не ZX);
8 - .INI для текстовых файлов конфигураций в интуитивно-понятном формате INI;
9 - .INC для включаемых ассемблерных файлов (не RASM);
A - .ASM для ассемблерных файлов (не RASM);
B - .BIN для бинарных данных, не привязанных к конкретным адресам;
C - .CPP для программ на Си++ (так было задумано в 1996 году)
D - .DAT для произвольных данных, которые могут быть перемещаемы по памяти;
E - .TXT для обычных досовских текстовых файлов в альтернативной кодировке;
F - .TMP для временных файлов;
Потом можно ещё 16 кодов добавить - от #10 до #1F:
#10 - .SCR для ZX-экранов (включая таймекс);
#11 - .ATR для ZX-атрибутов;
#12 - .IMG для ZX-экранов в формате Gigascreen;
#13 - .SNA для ZX-образов;
#14 - .Z80 для ZX-образов;
#15 - .SZX для ZX-образов;
#16 - .TAP для ZX-лент;
#17 - .TRD для обрезанных образов TR-DOS;
...

Кроме того если код расширения файла представляет из себя код печатного символа (#20...#7E), то он будет считаться однобуквенным расширением - примеры:
.A - текст программы для RASM;
.B - бейсик программа ZX;
.C - код для ZX;
.D - данные для ZX;
.L - файл статической библиотеки (для будущих версий nedoPC SDK);
.O - объектный файл (для будущих версий nedoPC SDK);
.R - текст программы на языке Robby (для nedoPC SDK);
.N - скрипт для nedoPC SDK (бывший SHJ).
В будущем могут быть .c и .h (для программ на языке Си), но пока ограничимся только большими буквами...
You do not have the required permissions to view the files attached to this post.
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Shaos wrote:Смотрю в свои старые тетрадки - весной 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 - таких как условные переходы или условная передача управления.
К сожалению такой способ не будет работать с вызовом подпрограмм - по видимому надо сделать отдельный спец.вызов для CALL:
CD FC CC CD aa bb - вызов подпрограммы с возвратом на следующий адрес после bb (надо ли такой же подход распространять на условные вызовы подпрограмм?).
В этом случае всё также надо скорректировать адрес aa bb, но вместо вызова инструкции CALL надо засунуть в стек адрес байта после bb и сделать JMP на модифицированный адрес bbaa.
Если аналогично поддержать условые вызовы подпрограмм (C4,D4,E4,F4,CC,DC,EC,FC) то там кроме первого условного джампа (соответствующего условию вызова подпрограммы) в специальную область памяти надо будет вписывать и второй безусловный JMP на адрес возврата, если условие не выполнится. Можно относительно быстро проверить что требуется сделать с кодом идущим следом за CD FC CC по его младшему нибблу:
x0 - простая корректировка регистровой пары BC,DE или HL, а также загрузка SYS-программ по имени, как описано выше (никаких инструкций с аргументами с этим кодом нет, поэтому ничего больше применяться не будет);
x1 - общий случай для инструкций 01 (LXI B, ...), 11 (LXI D, ...), 21 (LXI H, ...) и 31 (LXI SP, ...);
x2 - общий случай для инструкций 22 (SHLD ...), 32 (STA ...), C2 (JNZ ...), D2 (JNC ...), E2 (JPO ...) и F2 (JP ...);
x3 - общий случай только для инструкции C3 (JMP ...);
x4 - специальный случай для инструкций C4 (CNZ ...), D4 (CNC ...), E4 (CPO ...) и F4 (CP ...), которые при транслировании превращаются в C2 (JNZ ...), D2 (JNC ...), E2 (JPO ...) и F2 (JP ...) соответственно (т.е. минус 2);
x5...x9 - инструкций с 2-байтовым аргументом среди таких кодов нет;
xA - общий случай для инструкций 2A (LHLD ...), 3A (LDA ...), CA (JZ ...), DA (JC ...), EA (JPE ...) и FA (JM ...);
xB - инструкций с 2-байтовым аргументом среди таких кодов нет;
xC - специальный случай для инструкций CC (CZ ...), DC (CC ...), EC (CPE ...) и FC (CM ...), которые при транслировании превращаются в CA (JZ ...), DA (JC ...), EA (JPE ...) и FA (JM ...) соответственно (т.е. минус 2);
xD - специальный случай только для инструкции CD (CALL ...), которая при транслировании превращается в C3 (JMP) или минус 10;
xE...xF - инструкций с 2-байтовым аргументом среди таких кодов нет.
Соответственно можно одним массивом из 16 байт определить все наши действия (там будет либо величина смещения кода инструкции, либо #FF для идентификации ошибочного выбора):

Code: Select all

SYS_ACTION DB #00,#00,#00,#00,#02,#FF,#FF,#FF,#FF,#FF,#00,#FF,#02,#0A,#FF,#FF
Если вдруг по ошибке программист применит неприемлиемый код, например FE (CPI n) типа CD FC CC FE n ... то при обработке такого вызова можно завершить исполнение с печатью ошибки в терминале. А вот если кто-то воспользуется неправильной командой из покрываемой колонки (например OUT n с кодом D3), то последствия могут быть непредсказуемыми, т.к. транслятор будет ожидать 2-байтовый аргумент и произведёт с ним соответствующие манипуляции (прибавит базовый адрес SYS-программы).

Такой подход может упростить ассемблирование т.к. теперь можно просто писать программу с ORG 0 и обычными мнемониками типа JMP, CALL и т.д.:

Code: Select all

SYS EQU #CCFC

 ORG 0
....
 CALL @SYS
 CALL SUB1 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L1+base;JMP SUB1+base
L1:
...
SUB1:
 ...
 CALL @SYS
 CZ SUB2 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L2+base;JZ SUB1+base; JMP L2+base
L2:
 RET
SUB2:
 ...
 RET
Для спец.кодов #00, #10, #20 и #30 можно завести макросы:

Code: Select all

SYS_TRANS_BC EQU #00
SYS_TRANS_DE EQU #10
SYS_TRANS_HL EQU #20
SYS_TRANS_RUN EQU #30
...
  LXI_H, VAR
  CALL @SYS
  DB @SYS_TRANS_HL
  \ тут в HL будет реальный адрес VAR с учётом смещения 
...
VAR DB 0
Вроде ничего не перепутал и все варианты учёл - есть у кого какие мысли по этому поводу?

Таким образом можно реализовать подгружаемые команды ОС в частности CD.SYS и DIR.SYS - будучи единожды запущены они останутся в памяти (в перемещённом виде) для более быстрого дальнейшего запуска.

Для вывода списка загруженных SYS-программ, а также для их выборочного удаления из памяти с компактированием, можно сделать отдельную COM или EXE программу, чтобы не нагружать этим функционалом ядро ОС.
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

У меня была мысль задавать имя подгружаемой SYS-программы (с возможными аргументами) не через указатель HL, а следом за вызовом подпрограммы загрузки:

CD FC CC #30 'D' 'I' 'R' #00

Но потом я таки остановился на варианте с HL:

Code: Select all

   LXI_H, SYSFILE
   CALL @SYS
   DB @SYS_TRANS_RUN
   ...
SYSFILE DB "DIR",0
Если этот код запущен изнутри другой SYS-программы, то ненулевой адрес смешения SYS_BASE (адрес начала текущей SYS-программы) будет использован чтобы модифицировать HL для чтения имени.
Если же этот код запущен из обычной EXE или COM программы (или из ядра ОС), то SYS_BASE в данном случае будет нулевым и никакой коррекции не произоёдёт.
Кстати при вызове SYS-программы из SYS-программы надо в стек возвратов затолкать ещё и предыдущее значение SYS_BASE, чтобы по возврату его можно было восстановить.
Ещё один момент - у SYS-программ нет своего стека - вся работа происходит в стеке программы вызвавшей SYS-программу.
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

На сегодняшний момент существует ядро ОС с большинством функций, способное подгружать из внешнего ПЗУ программы с расширением .COM и запускать их. В моей операционной системе COM-файлы не обязательно оттранслированы с адреса #0100 - они могут быть оттранслированы с любого адреса (адрес начала указывается в заголовке файла), но этот адрес должен быть согласован с конкретной реализацией ShaOS - например в случае РК86 таким адресом может быть #0000 (ну или #0100, чтобы была возможность "симулировать" CP/M-80), а в тесте, что я запускал на своём Урала-64К, этот адрес был #E800. Для дальнейшей разработки можно принять такой план, чтобы система оставалась работоспособной в каждом пункте:
  1. COM-файлы (уже есть);
  2. SYS-файлы (обсуждение выше);
  3. OVL-файлы (может понадобиться в скором будущем);
  4. EXE-файлы (перемещаемые с битовой маской);
  5. BAT-файлы (простой командный процессор);
  6. DLL-файлы (по аналогии со спринтеровским либманом);
  7. BAT-файлы (продвинутый командный процессор).
Для версии под ZX-спектрум я могу задействовать свою платку Romulus 32K, с которой система будет "бутаться" и на которой может содержаться ромдиск с файлами. Можно вернутся к тому, что я делал в 1997 году - Урал-48К с внешним ромдиском, подключаемым к бортовой ВВ55. Для российских клонов ZX с диском можно сделать тестовую сборку в формате TRD чтобы демонстрировать возможностей системы ShaOS на эмулях и реалах с TR-DOS. Также можно реанимировать nedoPC-85-A и сделать версию для него (всё должно уместиться в ПЗУ 8 Кб либо придётся цеплять внешний SPI EEPROM для хранения файлов). Ну и Radio-86RK 128KB надо дособирать - там тоже ShaOS может заработать. :rotate:
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Shaos wrote:Такой подход может упростить ассемблирование т.к. теперь можно просто писать программу с ORG 0 и обычными мнемониками типа JMP, CALL и т.д.:

Code: Select all

SYS EQU #CC0F

 ORG 0
....
 CALL @SYS
 CALL SUB1 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L1+base;JMP SUB1+base
L1:
...
SUB1:
 ...
 CALL @SYS
 CZ SUB2 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L2+base;JZ SUB1+base; JMP L2+base
L2:
 RET
SUB2:
 ...
 RET
Более того - можно даже условную компиляцию применить, чтобы можно было собирать один и тот же исходник и как SYS файл, и как COM файл (и даже как EXE):

Code: Select all

#ifdef SYSTRANS
 ORG 0
#else
 ORG #E800
#endif
....
#ifdef SYSTRANS
 CALL @SYS
#endif
 CALL SUB1 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L1+base;JMP SUB1+base
L1:
...
SUB1:
 ...
#ifdef SYSTRANS
 CALL @SYS
#endif
 CZ SUB2 \ вышестоящий вызов прочитает эти 3 байта и передаст управление на PUSH L2+base;JZ SUB1+base; JMP L2+base
L2:
 RET
SUB2:
 ...
 RET
Самодельный простой препроцессор у меня уже с 2008 года имеется: https://gitlab.com/nedopc/sdk/-/blob/master/sdk/minicpp.c
(я его делал для собственной досовской сборки тунгуски, а потом включил в состав nedoPC SDK)
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Ещё мысль о совместимости.

В данный момент подразумевается, что флаги в заголовке файла будут иметь биты совместимости:
00 - 8080
01 - 8085
10 - Z80
11 - см.расширенный заголовок (а там будет Z180 и т.д.)
Система будет понимать, что можно будет запускать на целевой платформе, а что нет.

Однако кроме процессора ещё должна быть совместимость по железу - в частности по графике.
Думаю должно быть достаточно задавать тип компьютера где-то в недрах ShaOS с возможность выдать строку по запросу:
ZX
ZX128K
ZX2068
ZXATM
NPC85A
RK86
ORION
SPETS
SPETSMX (максимум 7 байт плюс ноль?)
т.е. скажем программа, использующая графику ZX-спектрума, при запуске проверит слово-описатель компьютера, и если первые 2 буквы в нём не ZX, то программа выйдет с ошибкой.
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Shaos wrote:
Shaos wrote:Смотрю в свои старые тетрадки - весной 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 - таких как условные переходы или условная передача управления.
К сожалению такой способ не будет работать с вызовом подпрограмм - по видимому надо сделать отдельный спец.вызов для CALL:
CD FC CC CD aa bb - вызов подпрограммы с возвратом на следующий адрес после bb (надо ли такой же подход распространять на условные вызовы подпрограмм?).
В этом случае всё также надо скорректировать адрес aa bb, но вместо вызова инструкции CALL надо засунуть в стек адрес байта после bb и сделать JMP на модифицированный адрес bbaa...
Пытаюсь вспомнить почему я год назад решил, что озвученный выше подход не будет работать с вызовами подпрограмм :roll:

Допустим у нас есть SYS-TRANS программа, оттранслированная с адреса #6000 и по смещению #1000 там стоит транс-вызов подпрограммы:

Code: Select all

7000 CD FC CC CD FF 07 ; тут мы хотим вызвать подпрограмму по смещению 7FF
7006 ; сюда должно вернутся управление после завершения подрограммы
По старому подходу в специальной области памяти генерируется следующий код, на который и будет передано управление:

Code: Select all

CD FF 67 C3 06 70 ; вызов подпрограммы по скорректированному адресу #67FF и дальнейшая передача управления на #7006
И почему это не будет работать? По-моему очень даже будет! Причём даже с условными вызовами...

P.S. PUSH работает быстрее, чем SHLD, так что наверное спец область должна иметь не JMP NN, а RET (а правильный адрес возврата будет предварительно записан в стек).

P.P.S. Заодно везде исправил адрес подпрограммы SYS на #CCFC (последний адрес в векторе переходов ShaOS), в котором эта подпрограмма скорее всего в итоге и будет сидеть...
Я тут за главного - если что шлите мыло на me собака shaos точка net
b2m
Devil
Posts: 907
Joined: 26 May 2003 06:57

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

Post by b2m »

Shaos wrote:Пытаюсь вспомнить почему я год назад решил, что озвученный выше подход не будет работать с вызовами подпрограмм
Видимо потому, что очень хотелось оставить возможность передавать параметры следом за командой CALL.
Страничка эмулятора наших компьютеров
http://bashkiria-2m.narod.ru/
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

b2m wrote:
Shaos wrote:Пытаюсь вспомнить почему я год назад решил, что озвученный выше подход не будет работать с вызовами подпрограмм
Видимо потому, что очень хотелось оставить возможность передавать параметры следом за командой CALL.
Да вроде не хотелось :roll:

Надо оставить себе заметочку на полях - более расширенно описывать проблему и процесс обдумывания тех или иных решений, чтобы потом спустя годы не ломать голову зачем я это написал :oops:
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Я изначально когда создавал ShaOS вдохновлялся орионовским ордосом и вот наверное надо формат хедера файла ShaOS сделать совместимым c ORDOS, а то у меня чуток отличается:
Shaos wrote:Формат квазидисков операционки 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 байтам) внутри образа диска на цепочку файлов-подкаталогов этого подкаталога

также описатель может быть не только файлом или каталогом, но и так называемым "ответвителем", когда цепочка файлов-подкаталогов прерывается и перескакивает в другое место ром-диска...
Вот как в ORDOS:
0 - 7 - имя файла. может содержать не более 8 символов. Если имя содержит меньше символов, свободные ячейки заполняются пробелами.
8 - 9 - начальный адрес размещения программы при считывании ее из диска в озу - адрес "посадки".
а - в - размер файла. в этот параметр оглавление файла (16 байт) не входит.
с - байт флагов. бит d7=1 - указывает на то, что файл защищен от уничтожения. Бит d0=1 - файл относится к разряду системных и игнорируется функцией 7. Изменение состояния бита d1,d7 производят внешние загружаемые программы.
d - f - служебные ячейки системы.
Соответственно в ShaOS заголовок надо поправить так, чтобы первые 13 байтов на 100% повторяли ORDOS:

Code: Select all

struct HEADER
{
   char name[8]; // имя файла (для совместимости с ORDOS надо добивать пробелами)
   UINT adr; // адрес загрузки
   UINT len; // длина файла без заголовка
   BYTE atr; // байт атрибутов
   BYTE ext; // байт расширения (ShaOS)
   UINT kc; // слово хранящее контрольную сумму с заголовком (ShaOS)
};
В образах диска ордоса последние 3 байта заголовка равны FF, поэтому будем считать, что если ext=FF, то это файл без расширения (или когда расширение внутри имени после точки как у некоторых файлов ордоса типа setup.tx) ну и kc=FFFF будет означать, что контрольная сумма не считалась.

А вот по атрибутам надо только чтобы бит R/O совпадал:
Shaos wrote:Битики в атрибутиках надо немного переставить:

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

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

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

Бит расширенного заголовка в ShaOS означает, что следом за обычным 16-байтным заголовком идут ещё 16 байтов расширенного заголовка:

Code: Select all

struct HEADER_EX
{
   BYTE C; /* столетие */
   BYTE Y; /* номер года в пределах столетия */
   BYTE M; /* месяц */
   BYTE D; /* день */
   BYTE h; /* часы */
   BYTE m; /* минуты */
   BYTE s; /* секунды */
   BYTE r[8]; /* резерв */
   BYTE c; /* расширенный байт совместимости - 0x00 для 8080/8085/Z80, 0x01 для Z180 и т.д.) */
};
но чтобы ORDOS мог спокойно обходить такие файлы в цепочке, значение len в основном заголовке должно включать длину этого расширения, т.е. быть на 16 байт больше, чем размер файла с точки зрения ShaOS, ну и раньше я предполагал, что len в ShaOS это длина файла в параграфах (т.к. длина всегда кратна 16 байтам и при таком представлении может достигать 1МБ), но из-за сохранения совместимости с ORDOS придётся ограничиться максимальной длиной в 64КБ...
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
oldlazycat
Fanat
Posts: 59
Joined: 18 Nov 2022 06:33
Location: Урюпинск

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

Post by oldlazycat »

Т.е. ShaOS можно запустить на Орионе?
Two Beer? Or not Two Beer?
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

oldlazycat wrote:Т.е. ShaOS можно запустить на Орионе?
Пока нет - надо подковырять по мелочи, чтобы на Орионе заработало :roll:

По формату квазидисков основное отличие от ордоса это наличие подкаталогов (причём ордос сможет показать только содержимое корневого каталога - в нём можно держать ShaOS Loader)
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
oldlazycat
Fanat
Posts: 59
Joined: 18 Nov 2022 06:33
Location: Урюпинск

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

Post by oldlazycat »

Очень интересно! Как раз мысля мне пришла скрестить Орион с Z180 NedoPC.
Стандартные орионовские порты через память оставляем, а для видео конструируем спецадаптер на ПЛИС-е, который преобразует структуру экрана из ОЗУ и передаёт на SVGA через Feature Connector!
Two Beer? Or not Two Beer?
User avatar
Shaos
Admin
Posts: 24011
Joined: 08 Jan 2003 23:22
Location: Silicon Valley

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

Post by Shaos »

Ну этой мысле уже 2 года как, не? :lol:
Я тут за главного - если что шлите мыло на me собака shaos точка net