Info Guide #13 01 апреля 2021

Программирование

Системки - NedoOS истоки: в 2007 Fido фактически умерло и я перешёл в Интернет

        NedoOS: SMAN 
Alone Coder 

   К  лету 2007 года Fido фактически умер─
ло. Я перешёл в Интернет,меня пригласили в
IRC-канал  #mhm  для  обсуждения концепции
операционной  системы. Выпустив Info Guide
#10,  я  закрыл  все  старые  проекты  под 
TR-DOS (последним  был MCX viewer - предок 
недоосовского NedoView ).5 июня был создан
виртуальный   персонаж  SMAN  и  его  сайт 
http://smansite.narod.ru . На сайте выкла─ 
дывались  предварительные  заметки по ядру
SOS, текстовому редактору SWORD, графичес─ 
кому редактору spaint. В июне-октябре SMAN
придумал соглашения о стиле (насколько это
было возможно в ALASM ), написал структур─
ные  макросы  для  ALASM, первые процедуры
ядра,текстового редактора SWORD, цифрового
музыкального редактора под ось (потом идея
этого редактора была отброшена).
   Мы обсуждали с mhm-щиками межпроцессное
взаимодействие, сокеты, библиотеки ncurses
и  X11, подбирали  литературу (Lions' Com─
mentary on UNIX v6, "Современные  операци─ 
онные  системы" Таненбаума, описание Amiga 
OS ),но получалось так, что программировал 
один я. Хотя  изначально  SMAN задумывался
как  коллективный  псевдоним.  Предполага─
лось, что  он жил в Туле, звали его Сергей 
Манохин, он хотел попасть в группу MAYhEM, 
но его туда не приняли :)
   В  2007-2008  я  также  вёл переписку с
ZET-9 про доработку DNA OS под "скрытость" 
резидента в рамках 128K/1M (там я отказал─
ся от сплошной виртуальной нумерации стра─
ниц  в каждой программе и перешёл к заказу
номеров  страниц), с Vitamin'ом про память
и  шедулинг,  а  также  с  Budder'ом, fk0,
Screw'ом  и  другими, кто теоретически мог 
помочь с разработкой оси, но, к сожалению,
не  помогли. Всё  это происходило в тайне,
чтобы  никто  не  догадался, что  никакого
SMAN'а не существует. Даже если бы и дога─ 
дался, про разработку операционной системы
знал  только  узкий  круг лиц. Снаружи всё
выглядело так,как будто Alone Coder просто
снизил активность.

   К 2008 году в ядре SMAN'а была реализо─
вана вытесняющая  многозадачность, приори─
теты, критические секции, сообщения фикси─
рованной длины, подписка на прерывания, на
уровне ядра планировались 256-байтные бло─
ки  памяти, пайпы  и  vfs (но так и не был
придуман формат данных для неё).Для вирту─
ализации  программ под будущей осью 5 июля 
2007 года был написан эмулятор ZX Spectrum 
на  ZX Spectrum. После  изучения всяческих 
кодировок и раскладок клавиатуры ещё в де─
кабре 2007 была придумана раскладка ШВЕРТЫ
-  на  которой  в  русском   режиме  можно
набрать любой символ (сначала она попала в
ACEdit, а уже оттуда в NedoOS ). Был напи─ 
сан модуль хранения и обработки текста для
редактора  SWORD - он  был основан на 256-
байтных блоках с байтом кодирования сдвига
блока.

   В  2009  году я написал дему The Link -
эксперименты  с  реальной многозадачностью
(два процессора Z80 - второй в NeoGS ).Она
отлаживалась  в новой версии Unreal Speccy
- я передал этот проект  Deathsoft'у. Дема
была зарелижена в исходниках с автосборщи─
ком  mkace. Каждый эффект мог отлаживаться
и  отдельно, и в составе демы. Имелся гло─
бальный обработчик прерываний с глобальным
таймером, но  без глобального скрипта. Все
эффекты  писались в едином стиле "игрового
цикла". Впоследствии на базе этих исходни─
ков  я  выпустил ещё несколько дем, но уже
без  второго  Z80. Но  проект операционной
системы  катился под гору. Я крутил и так,
и  так, и получалось, что выделение нижней
памяти 256-байтными блоками совершенно не─
юзабельно  для программиста, так же, как и
своп нижней динамической памяти. Требуется
именно аппаратное переключение всех частей
памяти, причём не менее чем четырёх. Памя─
тником этим рассуждениям осталось три тек─
ста SMAN'а общей длиной 60 килобайт.
   Последние изменения ядра SMAN'а датиру─
ются  21  сентября 2010 года (с небольшими
изменениями  в 2015 году). Это ядро выкла─
дывалось на zx-pk.ru, но не вызвало  ника─
кого энтузиазма. По сути оно было бесполе─
зно. Я даже не стал писать для него систе─
мные  вызовы. Ошибка была и при проектиро─
вании редактора SWORD - во внутреннем фор─
мате документа не были поддержаны ни обра─
тные  ссылки, ни  внедрённые  изображения.
Кроме того, структура данных "rope" выгля─
дела  перспективнее  прокручивающихся 256-
байтных сегментов,которые тормозили линей─
но  от длины текста. И было непонятно, как
при переходе на новую ОС продолжать разра─
ботку  её  программ  в ALASM. Стал изучать
книгу John R. Levine "Linkers & Loaders" и
думать дальше.

   С 2009 года я занимался и другим проек─
том - движком  Wolf48, который  должен был
заменить движок Big L, который в свою оче─
редь  заменял  движок  Wolfenstein 2004. В
марте  2011  года  вышел  первый  релиз  с
использованием   движка  Wolf48 - Critical
Error  demo  от HPRG. Было понятно, что на 
48K памяти под полноценную игру мало, фор─ 
мат 128K мёртв и только периодически галь─
ванизируется без каких-либо новых техноло─
гий, а  в  ATM-Turbo есть всё, что нужно и
для  этой  игры, и  для  других, которые я
планировал ( Super Mario, цветного Чёрного
Ворона, Worms ...),и для многозадачной ОС. 
Более того, большие игры и надо делать под
ОС - хотя  бы  для того, чтобы не пришлось
писать собственную файловую систему в каж─
дой.
   В  2011-2012  я участвовал в разработке
Evo SDK  совместно  с Shiru. Я  отвечал за 
вывод  спрайтов и поддержку ATM2. Эта сис─
тема - плод  долгих раздумий после выпуска
Ball Quest.  Хотелось  иметь  произвольное 
количество  спрайтов (а не по размеру дис─
кетки) и  более 32K  непрерывного кода под
логику. Планировался также переход на поя─
вившийся  в  2009 году видеоконтроллер Eva
V9990  (разработал  его  Ronin/NedoPC, все 
материалы  есть  у меня на сайте), поэтому
все спрайты были заложены одинакового раз─
мера - 16x16. Это ещё и позволило избежать
написания  редактора  анимаций или скрипта
вырезания спрайтов - спрайты просто снима─
ются из bmp слева направо, сверху вниз.
  Evo SDK был достаточно прост для освое─
ния начинающими игроделами, но у него была
беда - он почти не расширялся.Максимум,что
удалось  потом  добавить в TR-DOS версии -
поддержку  TurboSound FM,  работу с диском
по #3d13, чтение-запись байтов в страницах
памяти  и  копирование  кусков  экрана. Не
удалось  даже  организовать  запуск  одной
программы   из  другой  из-за  ограничений
встроенного ассемблера SDCC, который ещё и
несовместим  между разными версиями компи─
лятора. (Теперь  мы с Hippiman'ом уже пор─
тировали Evo SDK под NedoOS, и в этой вер─
сии  уже  можно  добавлять любые функции с
помощью SjASMPlus .)

   Нам  не  удалось  убедить автора SymbOS
портировать свою систему на Спектрум. Поэ─
тому я стал продумывать план развёртывания
оси  (под влиянием статьи ZET-9 про "Шмат─
рицу", которая  потом  попала в Info Guide 
#11 ): 
 - первая отладочная модель: 
клавиатура -> бордюр; 
 - вторая отладочная модель: 
клавиатура -> текстовый экран; 
 - третья отладочная модель: shell.
   Также  начал писать ТЗ на систему (пос─
ледняя  версия датирована 2016 годом). Оно
сейчас смотрится  несколько устаревшим, но
для своего времени было просто революцион─
но: 
────────────────────────────────────────── 
  Размер   задачи  должен  ограничиваться 
только объёмом памяти. 
  В существующих на ZX многозадачных осях 
размер  задачи  ограничен одной страничкой 
верхней памяти. 
 
  Число одновременно запущенных задач до─ 
лжно ограничиваться только объёмом памяти. 
  В  существующих  на ZX осях число запу─ 
щенных  задач  ограничено выделенным окном 
под резиденты в нижней памяти. 
 
  Ось  должна  работать  на  голом АТМ2 и 
поддерживать АТМ3. 
  Существующие  на ZX оси не поддерживают 
АТМ3. 
 
  Ось  должна  реализовывать  многозадач─ 
ность в следующих видах (одновременно): 
 + кооперативно по событиям
 + квантами по 1/50 с
 + переключением фокуса кнопками
  Существующие  на  ZX оси не умеют все 3 
пункта одновременно. 
 
  Ось должна давать программам не окошки, 
а  терминалы  (контекст экрана и клавиату─ 
ры). Каждая  программа  может  работать  в 
своём экранном режиме. 
  Должна быть возможность реализации про─ 
граммы  GUI, которая  будет  предоставлять 
оконный интерфейс другим программам, зато─ 
ченным  под неё, желательно с возможностью 
вклиниться  в  цепочку переключения фокуса 
кнопками  (чтобы не было 3 уровня переклю─ 
чения: magic для переключения TR-DOS и TAP 
задач,  кнопки   переключения  терминалов, 
кнопки  переключения  окошек  в  терминале 
GUI). 
  Существующие на ZX оси не позволяют ра─ 
ботать  каждой  программе в своём экранном 
режиме. 
 
  Ось  должна иметь среды разработки (од─ 
новременно): 
 + кросс-ассемблер со сборкой на носитель 
одной  кнопкой (первое, что надо сделать) 
 + шеллскрипт
 + нативный макроассемблер мощнее аласма
 + кросс-си (некоммерческий)  со  сборкой 
на носитель одной кнопкой 
 + нативный  си  с  поддержкой ассемблера 
(качество  кода не важно, можно сделать из 
C Warp) 
 + нативный  текстовый  редактор   мощнее 
ACEdit (для начала можно простой блокнот) 
 + нативный  графический   редактор  (для 
начала можно простой paint) 
  Существующие  на ZX оси не имеют однов─ 
ременно нативную и кросс-среды разработки. 
 
  Ось  должна поддерживать следующие кон─ 
фигурации носителей (на выбор, должны быть 
поддержаны все): 
 + Nemo HDD / CompactFlash  как  основной 
носитель и SD-карта как дополнительный (ZX 
Evo baseconf, Pentagon 2.666) 
 + SD-карта  как  основной носитель и SD- 
карта  на NeoGS как дополнительный (ZX Evo 
baseconf + NeoGS, Pentagon 2.666 + NeoGS) 
 + ATM2 HDD/CompactFlash (master) как ос─ 
новной носитель и CompactFlash (slave) как 
дополнительный (ATM2) 
  Существующие  на ZX оси не поддерживают 
SD-карту. 
 
  Ось  должна  поддерживать горячую смену 
дополнительного носителя. 
  Существующие  на ZX оси не поддерживают 
горячую смену чего-либо, кроме дискеты. 
 
  Ось должна поддерживать FAT32 как осно─ 
вную файловую систему. 
  Существующие  на ZX оси не поддерживают 
FAT32. 
 
  Ось  должна иметь возможность запускать 
TR-DOS  софт  следующими способами (на вы─ 
бор, должны быть поддержаны все): 
 + через vTRDOS, если он есть (ATM2)
 + через Evo DOS (ZX Evo baseconf)
 + через  рамдиск / эмулятор ВГ93 в оста─ 
льных случаях (АТМ2, Pentagon 2.666) 
 
  Ось  должна иметь возможность запускать 
TAP  софт  следующими способами (на выбор, 
должны быть поддержаны все): 
 + через  подмену  ПЗУ  48  Basic  (ATM2, 
Pentagon 2.666) 
 + через Evo DOS (ZX Evo baseconf) 

  Причём запуск TR-DOS и TAP с переключе─ 
нием/возвратом, что можно реализовать сле─ 
дующими способами (любым из): 
 - плагин для magic (ZX Evo baseconf?)
 - резидент  для  reset  (ATM2,  Pentagon 
2.666) 
 - гибернация  системы, загрузка в следу─ 
ющий  раз  в  том же состоянии (простейший 
вариант для начала, также возможно для бу─ 
дущих компьютеров) 
  В любом случае во время работы TR-DOS и 
TAP  софта  использованная  память системы 
сохраняется на основной носитель. 
  В  любом случае должна быть возможность 
холодной загрузки при удержании кнопки. 
  Существующие  на ZX оси не поддерживают 
запуск TR-DOS софта с возвратом. 
 
  Ось  должна эмулировать CP/M (как мини─ 
мум  запускать игры) в многозадачном режи─ 
ме, если это вообще возможно. 
  Существующие  на  ZX  оси, кроме самого 
CP/M, не могут запускать CP/M-задачи. 
 
  Ось  должна поддерживать следующие кла─ 
виатуры  (на выбор, должны быть поддержаны 
все): 
 + 40-key
 + ATM2 XT keyboard
 + ZX Evo
  Приложениям  они  должны быть видны как 
одна  и та же клавиатура, с получением со─ 
бытий ввода, нажатия и отжатия. 
  Существующие  на ZX оси не поддерживают 
все три клавиатуры. 
 
  Пользователь должен получать ось в сле─ 
дующем виде (одновременно): 
 + список плюшек
 + документация   пользователя   в  стиле 
"сделай 1, сделай 2" 
 + образ под настроенным эмулятором
 + набор файлов для копирования на SD-ка─ 
рту (*.$c главный) или HDD (+ образ диске─ 
ты для запуска) 
 + набор файлов для копирования на SD-ка─ 
рту,fdisk+format для HDD и копировщик SD-> 
HDD с установкой автозапуска 
 + документация разработчика в стиле "как 
написать первую софтину" 
 + настроенные среды для кросс-разработки 
с примерами 
 + документация разработчика в стиле "по─ 
лный список вызовов со всеми параметрами" 
 + документация разработчика в стиле "как 
это грузится и работает" 
  При первом запуске ось должна сама нас─ 
троиться  под  аппаратуру  или сообщить, в 
чём проблема. 
  При  первом  запуске ось должна войти в 
командер  (универсальный копировщик-запус─ 
кальщик-просмотрщик, расширяемый через до─ 
бавление запускалок расширений в текстовом 
файле). 
 
  Пользователь  должен получать следующие 
удобства от использования оси (одновремен─ 
но): 
 + полноценный копировщик-запускальщик,он 
же универсальный просмотрщик 
 + одновременная работа в нескольких про─ 
граммах с несколькими файлами 
 + нативная работа на FAT32
 + горячая смена носителя
 + запуск TR-DOS и TAP софта с переключе─ 
нием/возвратом 
 + поддержка расширенной клавиатуры
 + нативный графический редактор под цвет 
на точку 
 + нативный  текстовый  редактор   мощнее 
ACEdit 
 + батники
 + нативный макроассемблер мощнее аласма, 
с батниками 
 + нативный си удобнее C Warp,с батниками
 + настроенные среды для кросс-разработки
 + одна среда исполнения,не нужно мудрить 
с  лоадером  и  инициализацией программы с 
учётом глюков разных ПЗУ 
 + отсутствие необходимости  писать драй─ 
веры носителей, разгребаторы файловых сис─ 
тем и опрашиватели клавиатуры 
 + возможность писать действительно боль─ 
шие программы (в том числе большие игры) 
 + удобно  делать  логинг  при отладке (а 
логинг переключения памяти и вызова систе─ 
мных функций сможет делать сама система) 
 + возможность совместной разработки (об─ 
щая среда разработки,общие шаблоны,модуль─ 
ность) 
 + живые авторы оси, все сюрпризы центра─ 
лизованно документируются 
 + в  перспективе  возможность шарить на─ 
тивные   каталоги   по   сети  (RS232  или 
ZXNetUSB), причём в фоновом режиме 
 + в перспективе возможность создать веб- 
браузер 
 + в  перспективе  возможность аппаратной 
защиты памяти и устройств 
 
  возможность быстрой переделки трдос ре─ 
лизов под ось (вряд ли тулзой)? для  этого 
надо  иметь  возможность  включать экран в 
#4000  и ставить хук прерываний для задачи 
в фокусе 
  при  переключении  терминалов надо глу─ 
шить/восстанавливать   AY/TS?/TFM??   (где 
хранить  его  состояние?) или переделывать 
руками  так, чтобы  музыка  была отдельным 
потоком  и не прерывалась при переключении 
терминалов 
 
  почему  ни в одной оси не показано гра─ 
фом, как  соединены  программы  (драйверы, 
гуи, керналь+резиденты итп)? 

  как отделить vfs от ядра? vfs в библио─ 
теке, и  ссылки на подключенные библиотеки 
не отваливаются при fork-exec? 
  или  начальную  загрузку сделать другим 
механизмом? (снапшот или из канала) 
────────────────────────────────────────── 

   В  2013  году  я изучал CP/M и MSX-DOS,
архив исходников МикроАРТа, активно порти─
ровал  программы под АТМ2 (по сути набивал
руку), писал SDK "Unreal Project" - после─
дняя  моя надежда на ALASM, которая не оп─
равдалась.
   В  2014  году  я  перешёл  с  ALASM  на
кросс-компилятор SjASMPlus, потому что его
можно использовать в пакетной сборке с ку─
чей операций. ALASM может использовать при
сборке только тот код, который скомпилиро─
вал  сам  или  подгрузил как кодовый блок.
ALASM  не может скомпилировать два незави─ 
симых  проекта  одной командой - мы не мо─
жем, например, скомпилировать  одовременно
русскую и английскую версии BGE.
   Изучал  язык  и систему Oberon. История
Оберона  убеждает, что  написать серьёзную 
операционную  систему со средой разработки
можно одному-двум людям всего за пару лет.
Тогда же я начал писать графический редак─
тора gfxed (бывший spaint, который сущест─
вовал  только  в  виде  текстовых фантазий
SMAN'а, причём дизайн был взят из того са─ 
мого  ненаписанного мультиколорного редак─
тора 1997 года). В этом  редакторе наконец
было  концептуально  побеждено ограничение
размера  картинки одним экраном. Для срав─
нения, максимум, что я смог добавить в BGE
- картинку размером в два экрана...
   В  2015  году я изучал и другие простые
языки: C--, PLM, K65, не забывал и о Форте
с  Лиспом. Копал  информацию в Википедии о
самых разных языках программирования. Изу─
чал  UNIX  Haters Handbook. Изучал PQ-DOS,
написанную  для  Profi. В 2016 году понял,
как  сделать резидент для "скрытого" CP/M.
Почему-то  до  этого  во всех версиях CP/M
нельзя было убрать его код из верхнего ок─
на адресного пространства! 14 сентября на─
чал  писать язык NedoLang. До первой само─
компиляции  NedoLang  дошёл  31 марта 2017
года, 12  апреля  вышел первый гифт, напи─
санный в нём, а в сентябре была уже полно─
ценная  система  NedoLang  с библиотеками,
утилитами  и двумя таргетами (второй - ARM
Thumb ). Теперь была  реальная возможность 
компилировать  одни и те же исходники и на
PC, и на ZX. 

   В 2018 году я писал ещё и другой язык -
скриптовый   язык  Listh,  помесь  Lisp  и
Forth. Хотел  сделать совсем маленький ин─ 
терпретатор, чтобы его можно было засунуть
в  любую  программу, даже в дему или игру.
Для  примера  прикрутил  к нему 3D-движок.
Оказалось,что работать в этой системе неу─
добно.Не получилось сделать защиту памяти,
не  хватало редактора текста, а сам интер─
претатор занимает не так уж и мало.Да и не
так  быстро работает, а ускорение потребо─
вало бы переписывания всей  системы. Может
быть, я  ещё  вернусь  к этому скриптовому
языку...