NK-DOS (вариант MS-DOS под TR-DOS)

[Максагор]

Я, кстати, планировал дописать только поддержку RAM-диска, доотладить основные команды - и приступить к написанию Nomy Commander'а под NK-DOS, используя как раз те самые процедурки, встроенные в систему, о которых я упоминал.

Предлагаю создать описание как создать под систему драйвер (и его структуру) любого устройства ввода-вывода и как его загрузить в память и подсоединить к логическому устройству (буквы A: B: C: D: E: F: и далее).

Тогда я бы сам взялся попробовать скрестить систему с винтом или RAM-диском произвольного объема. Или у тебя файловая система жестко ориентирована на файловую систему в размерах флопа и не терпит увеличение размеров дискового пространства на порядки (мегабайты и десятки мегабайт)?

[Sonic]

Кстати а с менеджментом памяти там что?
Как используется 128 кб или выше?
Могу помочь, у меня наработки в голове еще остались со времен мыслей о написании собственной ОС в далеком 1998 году... Наработки эти можно усовершенствовать.
О некоторых мыслях я тут писал в разных тредах.

[Nomy Graphics]

http://tuneyourcar.narod.ru/NKWORK.ZIP

выкладываю исходник.

Касательно ограничений по объему, безусловно, они присутствуют, т.е. под длину файла и адрес выделяются 16-битные переменные и используются 16-битные регистры, под длину в секторах - 8-битные.. Встроенный калькулятор также рассчитан на 16 битные числа, при выводе на экран десятичных чисел в том числе. Все это надо будет расширять под соответствующий порядок значений.

Касательно подключения драйверов других устройств, см. в самом конце исходника обработчик, зануленный временно на RET для устройств с буквами старше "D". Их велкам - как раз туда. (этим объясняется фича работы системы при попытке задать диск "Е","F" и т.п. - обращений к диску не происходит, а данные берутся из буфера памяти, оставшиеся с предыдущего раза). Таким образом, для RAM диска, необходимо добавить конструкцию с LDIR'ами, закачивающие данные из места его расположения в буфер (для чтения с него), либо наооборот, для записи.

Подробную инструкцию постараюсь составить, но, может быть, после просмотра исходника, что-то и так станет понятным?

Менеджмента памяти, как такового, в NK не реализовано. Система занимает адреса с С000h (в банке по умолчанию) по свою длину, с FС00h память отведена под фонт (его, кстати, возьмите с релизной версии, в исходник не добавил) Т.е. она работает под 48К. Все это тож можно исправить при необходимости.

[Sonic]

ИМХО надо отвязываться от TR-DOS и бейсика-48. Предлагаю рассмотреть память в следующих понятиях.
1. Нижняя область памяти - low memory, non-paged memory.
2. Страничное окно - Paged memory, по адресу 0xC000. Количество страниц - до 256 (#00 - #FF).
Страничную память виртуализировать в следующем виде:
1. Страницы жестко спроецированные в #4000 и #8000 из нумерации исключить.
2. Страничную память виртуально представить в виде непрерывной, заполняемой сверху вниз.
Далее вводим границы:
1. Нижняя граница low memory доступной для программ.
2. Номер первой страницы доступной для программ (фактически верхняя граница памяти).
Страница содержит модули ОС (драйвера, файловые системы, библиотеки). Модуль начинается с заголовка, который содержит длину модуля и его имя. Модуль с пустым именем (#00) означает свободный блок. Таким образом. При размещении нового модуля (драйвера) система начинает сканирование страниц начиная с самой верхней до тех пор, пока не найдет кусок памяти нужного размера. После инсталляции драйвера мы имеем его базовый адрес и номер его страницы, этого достаточно чтобы к нему обратиться.
Для межстраничных обращений в нижней памяти имеем коротенький резидент. Резидент содержит в себе номер системной страницы (как правило самой верхней), в которой находится модуль CORE - он отвечает за взаимосвязь остальных модулей, содержит карту страниц памяти и т. д. Он умеет включать эту страницу и передавать управление туда.
Единственное ограничение - размер модуля не может превышать 16 кб. Легко обходится путем разбивки больших модулей на несколько маленьких.
Область системных переменных бейсика-48 можно "свернуть", оставив только FRAMES, KSTATE, MODE, FLAGS, REPDEL и REPPER. Они используются обработчиком INT и пригодятся нам для обслуживания ввода с клавиатуры. Если хотим задействовать RST #10 для собственных нужд а-ля IS-DOS, то еще и CURCHL. Кстати FRAMES3, MODE и FLAGS можно переместить поближе к экрану, изменив IY. Это дает максимальное высвобождение нижней памяти вместе с возможностью в любой момент восстановить полные системные переменные, обеспечив таким образом совместимость бейсика с новой системой. Переменные TR-DOS нам не нужны.
Можно создать и ПЗУ-версию системы, которая работает без системных переменных и резидента вообще.

[Nomy Graphics]

Да, несколько непривычны для меня эти понятия, к тому же вот что хочется спросить:
- переменные Бейсика - а если их затереть, как же мы будем запускать Бейсик-программу из ДОС? для ее нормальной работы они же, типа, нужны в более полном составе, чем перечислено?
- переменные TR-DOS тот же вопрос, а как же тогда вообще все будет работать?? вообще-то, NK-DOS на данный момент, по сути, лишь надстройка над TR-DOS, не имеющая собственных прямых процедур работы с диском (не считая заделки под RAM-DISK), а пользующаяся 3D13h? переменные TR-DOS активно используются в NK.

[Максагор]

вообще-то, NK-DOS на данный момент, по сути, лишь надстройка над TR-DOS, не имеющая собственных прямых процедур работы с диском (не считая заделки под RAM-DISK),

Вот именно это я и хотел знать,задавая выше все свои вопросы. Тогда все намного хуже. Сколько уже таких оболочек-надстроек уже было. ИМХО, самая лучшая из оных - ZX-Windows v1.6

[Vovoi]

ИМХО надо отвязываться от TR-DOS и бейсика-48. Предлагаю рассмотреть память в следующих понятиях.
1. Нижняя область памяти - low memory, non-paged memory.
2. Страничное окно - Paged memory, по адресу 0xC000.......

Баллин, до 90% прямо как из моей головы вытащил :)
Дело не в отвязывании (не надо на Спектруме что-то ломать) от TR-DOS, а конструировании некой прослойки, в которую надо обращаться, ну, в проге идет:
CALL savefile
..
CALL loadfile
...
RET
;подпрограммы работы с внешними девайсами
savefile JR initial; ХОРОШО и ПОЛНОСТЬЮ документированный кусок памяти, его объем определяется вначале (ессно не до бесконечности:).
DRIVE DEFM "A"; здесь размещаются переменные
.....
initial; сам драйвер
RET
Только вот может возникнуть ситуация как в издос "Insert System Disk Please". Так что есть необходимость в хранении жизненно важных драйверов в каком-то RAM-банке данных, помеченным "системным", т.е. при недостатке памяти в ситуации Load Program, система сообщит: "Осталась только системная память, хотите грохнуть неиспользуемые сейчас драйвера? Будут стерты подпрограммы для работы с:" и тут читается список имен драйверов из оперативки. Выбираем, убиваем помеченные. По мере удаления, растет счетчик свободной памяти. Как только ситуация станет комфортной, цвет имени загружаемого файла с красного перерисуется зеленым и можно давить ентер (терпеть не могу, когда для освобождения памяти надо выходить куда, то, а потом снова искать файл, который хотел запустить:).
Ушел я от темы. Так вот, решив скинуть файл на MS-DOS-диск, переключаем драйвер и теперь, обращаясь к вышеуказанным /CALL savefile/ с просьбой "сохранить как: mytext.txt", подпрограмма будет ожидать диск МСДОС. Далее, до тех пор, пока снова не произведем переключение, система будет работать только с МСДОС (ессно, не найдя системных файлов, она попросит указать место и тип диска, где они находятся).
Но для MS-DOS требуется много ОЗУ, сам в первую очередь рассчитываю на использование пользователями издосного драйвера, поскольку TASIS вероятно прочно войдет в жизнь АТМ, а ПЦ маст дай.

Ну а 48к, то это минимум. Мне хочется изначально ориентироваться именно на 48к, но там тоже будет драйвер, который можно будет подменить, расширить как хочется (т.е. у драйвера есть свое системное меню). Сам напишу поддержку 48к, опубликую характеристики этого драйвера (команды, точки входа, размеры драйвера). Вообще, точки входа, имхо, только для качественных процедур. Хочу иметь возможность подключать любой драйвер, который накодил программер. Если в бэйске PRINT AT 10,10;"Speccy", означает печать слова в координатах, это ни в коем случае не значит что надо пропищать в динамик, верно? Кодеры будут ориентироваться на основу, а если прога написана с учетом новых команд (используется новый драйвер, большего/меньшего размера), то перед запуском, нормальная прога сообщит, мол "программа использует команды, отсутствующие в этом драйвере, так что заускаться и сносить вашу систему не будем, драйвер качать там-то. Дается URL"

Подытоживая, отмечу, что создавая систему (ИМХО), надо ориентироваться на остальных кодеров, т.е. чтобы была возможность замены твоих фрагментов системы чужими. Как бы, система, состоящая из блоков: Вывод текста, вывод графики, вывод данных на внешние устройства памяти и т.д.
Когда же я засяду за написание!!!
:)))

[Nomy Graphics]

Вот именно это я и хотел знать,задавая выше все свои вопросы. Тогда все намного хуже.

Итак, еще раз объясню, как осуществлена работа с девайсами. NK-DOS вместо процедуры TR-DOS #3D13 использует свою точку входа (в исходнике под меткой M3D13), которая проверяет значение дисковода, если оно менее 4-х (диски A-D), то обращается к #3D13, если более чем 4 (диски с именем "E" и старше) - то на отдельную процедуру, которая пока не дописана (стоит RET). При этом #3D13 используется почти исключительно для 2-х вещей - считать в буфер сектор и записать из буфера сектор. Специальных своих процедур для работы с TR-DOS диском в NK, действительно, нет.

Однако, для подключения драйверов других дисковых устройств, рекомендуется именно на место этой процедуры (в самом конце исходника) вставить JP на драйвер, который обеспечит считывание в буфер информации с другого носителя. Так, например, можно сделать поддержку RAM-диска. Что касается винта, то потребуются более существенные переделки, поскольку везде и всюду подразумевается, что мы имеем дело с 16-битными значениями для адресов, размеров в байтах, 256-байтный диск-сектор, 8-битный номер дорожки и трека.

[Sonic]

Да, несколько непривычны для меня эти понятия, к тому же вот что хочется спросить:
- переменные Бейсика - а если их затереть, как же мы будем запускать Бейсик-программу из ДОС? для ее нормальной работы они же, типа, нужны в более полном составе, чем перечислено?

Можно зарезервировать Low memory и восстановить их.

- переменные TR-DOS тот же вопрос, а как же тогда вообще все будет работать?? вообще-то, NK-DOS на данный момент, по сути, лишь надстройка над TR-DOS, не имеющая собственных прямых процедур работы с диском

Так дописать прямые функции разве сложно?

[Dr.Potapov]

ну как там? продвигается? внимательно слежу за разработкой.