nedoPC.org

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

Ну и EXE файл может подвешиваться резидентом, подменяя некоторые системные вызовы в векторе переходов - например такими резидентами могут быть разные текстовые драйвера - на 42 символа в строке, на 64 символа в строке и т.д.

Вспомнил, что изначально в 90х я задумывал именно такое кодирование для расширения файлов, чтобы первые несколько вариантов использовались для поиска исполняемого файла для выполнения команды, если она была задана без расширения - сначала ищется файл .BAT, потом .SYS, потом .COM и уже в самом конце - .EXE:

К сожалению такой способ не будет работать с вызовом подпрограмм - по видимому надо сделать отдельный спец.вызов для CALL:
CD 0F CC CD aa bb - вызов подпрограммы с возвратом на следующий адрес после bb (надо ли такой же подход распространять на условные вызовы подпрограмм?).
В этом случае всё также надо скорректировать адрес aa bb, но вместо вызова инструкции CALL надо засунуть в стек адрес байта после bb и сделать JMP на модифицированный адрес bbaa.
Если аналогично поддержать условые вызовы подпрограмм (C4,D4,E4,F4,CC,DC,EC,FC) то там кроме первого условного джампа (соответствующего условию вызова подпрограммы) в специальную область памяти надо будет вписывать и второй безусловный JMP на адрес возврата, если условие не выполнится. Можно относительно быстро проверить что требуется сделать с кодом идущим следом за CD 0F 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 для идентификации ошибочного выбора):
Если вдруг по ошибке программист применит неприемлиемый код, например FE (CPI n) типа CD 0F CC FE n ... то при обработке такого вызова можно завершить исполнение с печатью ошибки в терминале. А вот если кто-то воспользуется неправильной командой из покрываемой колонки (например OUT n с кодом D3), то последствия могут быть непредсказуемыми, т.к. транслятор будет ожидать 2-байтовый аргумент и произведёт с ним соответствующие манипуляции (прибавит базовый адрес SYS-программы).

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

Для спец.кодов #00, #10, #20 и #30 можно завести макросы:
Вроде ничего не перепутал и все варианты учёл - есть у кого какие мысли по этому поводу?

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

Для вывода списка загруженных SYS-программ, а также для их выборочного удаления из памяти с компактированием, можно сделать отдельную COM или EXE программу, чтобы не нагружать этим функционалом ядро ОС.

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

CD 0F CC #30 'D' 'I' 'R' #00

Но потом я таки остановился на варианте с HL:
Если этот код запущен изнутри другой SYS-программы, то ненулевой адрес смешения SYS_BASE (адрес начала текущей SYS-программы) будет использован чтобы модифицировать HL для чтения имени.
Если же этот код запущен из обычной EXE или COM программы (или из ядра ОС), то SYS_BASE в данном случае будет нулевым и никакой коррекции не произоёдёт.
Кстати при вызове SYS-программы из SYS-программы надо в стек возвратов затолкать ещё и предыдущее значение SYS_BASE, чтобы по возврату его можно было восстановить.
Ещё один момент - у SYS-программ нет своего стека - вся работа происходит в стеке программы вызвавшей SYS-программу.

На сегодняшний момент существует ядро ОС с большинством функций, способное подгружать из внешнего ПЗУ программы с расширением .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 может заработать.

Более того - можно даже условную компиляцию применить, чтобы можно было собирать один и тот же исходник и как SYS файл, и как COM файл (и даже как EXE):

Самодельный простой препроцессор у меня уже с 2008 года имеется: https://gitlab.com/nedopc/sdk/-/blob/master/utils/minicpp.c
(я его делал для собственной досовской сборки тунгуски, а потом включил в состав nedoPC SDK)

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

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

Однако кроме процессора ещё должна быть совместимость по железу - в частности по графике.
Думаю должно быть достаточно задавать тип компьютера где-то в недрах ShaOS с возможность выдать строку по запросу:
ZX
ZX128K
ZX2068
ZXATM
NPC85A
RK86
ORION
SPETS
SPETSM (пытаюсь утолкаться в 6 байт)
т.е. скажем программа, использующая графику ZX-спектрума, при запуске проверит слово-описатель компьютера, и если первые 2 буквы в нём не ZX, то программа выйдет с ощибкой.