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-движок.
Оказалось,что работать в этой системе неу─
добно.Не получилось сделать защиту памяти,
не хватало редактора текста, а сам интер─
претатор занимает не так уж и мало.Да и не
так быстро работает, а ускорение потребо─
вало бы переписывания всей системы. Может
быть, я ещё вернусь к этому скриптовому
языку...
Other articles:
