nedoPC.org

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

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

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

К сожалению такой способ не будет работать с вызовом подпрограмм - по видимому надо сделать отдельный спец.вызов для 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 для идентификации ошибочного выбора):
Если вдруг по ошибке программист применит неприемлиемый код, например FE (CPI n) типа CD FC 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 FC 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/sdk/minicpp.c
(я его делал для собственной досовской сборки тунгуски, а потом включил в состав nedoPC SDK)

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

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

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

Пытаюсь вспомнить почему я год назад решил, что озвученный выше подход не будет работать с вызовами подпрограмм

Допустим у нас есть SYS-TRANS программа, оттранслированная с адреса #6000 и по смещению #1000 там стоит транс-вызов подпрограммы:
По старому подходу в специальной области памяти генерируется следующий код, на который и будет передано управление:
И почему это не будет работать? По-моему очень даже будет! Причём даже с условными вызовами...

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

P.P.S. Заодно везде исправил адрес подпрограммы SYS на #CCFC (последний адрес в векторе переходов ShaOS), в котором эта подпрограмма скорее всего в итоге и будет сидеть...

Видимо потому, что очень хотелось оставить возможность передавать параметры следом за командой CALL.

Да вроде не хотелось

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

Я изначально когда создавал ShaOS вдохновлялся орионовским ордосом и вот наверное надо формат хедера файла ShaOS сделать совместимым c ORDOS, а то у меня чуток отличается:

Вот как в ORDOS:

Соответственно в ShaOS заголовок надо поправить так, чтобы первые 13 байтов на 100% повторяли ORDOS:
В образах диска ордоса последние 3 байта заголовка равны FF, поэтому будем считать, что если ext=FF, то это файл без расширения (или когда расширение внутри имени после точки как у некоторых файлов ордоса типа setup.tx) ну и kc=FFFF будет означать, что контрольная сумма не считалась.

А вот по атрибутам надо только чтобы бит R/O совпадал:
(в ордос4 используется ещё бит 0 атрибутов как скрытый/системный, но он только на функцию получения списка файлов в ордосе действует и нам не нужен - на его месте будет один из битов совместимости)

Бит расширенного заголовка в ShaOS означает, что следом за обычным 16-байтным заголовком идут ещё 16 байтов расширенного заголовка:
но чтобы ORDOS мог спокойно обходить такие файлы в цепочке, значение len в основном заголовке должно включать длину этого расширения, т.е. быть на 16 байт больше, чем размер файла с точки зрения ShaOS, ну и раньше я предполагал, что len в ShaOS это длина файла в параграфах (т.к. длина всегда кратна 16 байтам и при таком представлении может достигать 1МБ), но из-за сохранения совместимости с ORDOS придётся ограничиться максимальной длиной в 64КБ...

Т.е. ShaOS можно запустить на Орионе?

Пока нет - надо подковырять по мелочи, чтобы на Орионе заработало

По формату квазидисков основное отличие от ордоса это наличие подкаталогов (причём ордос сможет показать только содержимое корневого каталога - в нём можно держать ShaOS Loader)

Очень интересно! Как раз мысля мне пришла скрестить Орион с Z180 NedoPC.
Стандартные орионовские порты через память оставляем, а для видео конструируем спецадаптер на ПЛИС-е, который преобразует структуру экрана из ОЗУ и передаёт на SVGA через Feature Connector!

Ну этой мысле уже 2 года как, не?