Назад в будущее?

[Sonic]

Здравствуйте, товарищи! Разрешите представиться, Павел Федин. Да-да, тот самый, автор дизассемблера TR-DOS и многих предложений по новой ОС, безвременно оставивший платформу в далеком 1998, кажется, году...
Бродил по ссылкам, по ресурсам... А коммьюнити-то оказывается еще живет... И решил я попробовать в него вернуться. Прошло много времени, многие взгляды поменялись, появился новый опыт...
Ходя по сайтам заграничных сообществ пользователей старых компьютеров я много натыкался на объявления о поддержке, производстве и продаже программ и оборудования. Интересно, а чем мы хуже? На этом форуме я нашел также объявление Чунина Романа, который, насколько я понял, занимается примерно тем же. Возможно есть еще заинтересованные люди.
Мое сообщение предназначено для прочтения в первую очередь теми, кто хотел бы реально организовать какую-либо поддержку, либо ищет людей для осуществления подобных проектов. Мне было бы очень интересно связаться и обсудить условия возможного сотрудничества.
У меня есть несколько предложений, софтово-железного характера. Дабы не распыляться, напишу все здесь, надеюсь мне это простят. :)
Итак, первое. Вспоминая свою идею супер-ОС, а также примерно представляя, что представляет собой среднестатистический реально имеющийся в наличии современный Спектрум... Поправьте меня пожалуйста, если я не прав, но по крайней мере в России и сопредельных странах используется Спектрум-128 (возможно с некоторыми расширениями) с дисковой ОС TR-DOS. Имеется также опыт использования винчестеров (я хотел бы с ним ознакомиться), ибо пространства дискетки на текущий момент явно не хватает, хотя мне неизвестно о полноценных реализациях.
Итак, предложение №1. Разработка TR-DOS-совместимой дисковой системы, способной работать с ЛЮБЫМИ видами носителей информации, а не только с дискетками. Ключевые аспекты реализации следующие:
1. Нахождение в ПЗУ, оригинально предназначенном для TR-DOS.
2. Полная совместимость с TR-DOS по вызовам бейсика и #3D13.
3. Расширенный набор вызовов #3D13, обеспечивающий полноценную работу и легкость переадаптации игр и прочих программ, работающих вне контекста ОС (без системных переменных).
4. (возможно) ограниченная совместимость на уровне прямых вызовов наиболее часто используемых подпрограмм.
5. Поддержка подкаталогов на всех видах носителей информации.
6. (в перспективе, при необходимости, требуется аппаратное вмешательство) обеспечение совместимости на уровне системных вызовов с прочими (псевдо)дисковыми системами (Disciple, Opus, +3, Microdrive, и т. д.) с целью обеспечения работоспособности программ без необходимости переадаптации.
В качестве конечного результата мне видится прошивка (несколько версий аппаратно-зависимых прошивок) ПЗУ, вставляемого взамен имеющегося.
Возможно обеспечение 100% совместимости с TR-DOS путем аппаратной доработки машины с добавлением новой страницы ПЗУ, подменяющей собой TR-DOS, с программным переключением.
В перспективе возможно развитие проекта с целью превращения в полноценную ОС с менеджментом памяти, подключаемыми модулями и т. д.
Предложение №2. Насколько мне известно, ситуация с устройствами хранения информации на ZX в данный момент следующая:
1. Дискетки. Морально устарели, емкость ограничена, возможность эксплуатации 5.25" приводов ограничена (выпуск давно прекращен, запчастей нет, носителей тоже).
2. Жесткие диски. Установка на ZX современного накопителя большой емкости (типичный размер современного диска исчисляется десятками гб) по моему мнению не имеет смысла в принципе, работа с ним сложна технически (64-битная адресация) и крайне медленна. Возможно использование только начальной области такого диска, но при этом появляется такой фактор, как неоправданность стоимости самого накопителя (которая равна, если не больше, цене компьютера). Вариант совместного использования жесткого диска в большой машине (PC) и ZX с его постоянным переставлянием возможен, но неудобен. Приобретение же жестких дисков малой емкости (<500 мб) затруднено их ограниченной доступностью, а также ограниченностью их остаточного ресурса.
Предлагаю следующие пути решения данной проблемы:
1. Более простой путь - использование большой машины в качестве файл-сервера. Насколько мне известно, в данный момент не существует разработок, позволяющих использовать такой вариант в отечественных условиях (хотя есть реализации с использованием последовательных портов интерфейса-1, а также Spectrum+3).
2. Более сложный путь - разработка собственного устройства на базе Flash-памяти средней емкости (до десятка мб). Собственно, это логическое продолжение идеи ROM-картриджей, популярных во времена становления домашней игровой индустрии. Имеет следующие плюсы:
а) абсолютная бесшумность накопителя.
б) очень высокая скорость работы.
в) практически абсолютная надежность.
г) малые размеры
д) легкость транспортировки
Итак, если есть реально заинтересованные люди, согласные реально помочь (организацией, спонсорством, предоставлением железа, и т. д.) - мне было бы крайне приятно вновь вступить в ваши стройные ряды.

[Shiru]

Предлагаю следующие пути решения данной проблемы:
1. Более простой путь - использование большой машины в качестве файл-сервера. Насколько мне известно, в данный момент не существует разработок, позволяющих использовать такой вариант в отечественных условиях (хотя есть реализации с использованием последовательных портов интерфейса-1, а также Spectrum+3).
2. Более сложный путь - разработка собственного устройства на базе Flash-памяти средней емкости (до десятка мб). Собственно, это логическое продолжение идеи ROM-картриджей, популярных во времена становления домашней игровой индустрии. Имеет следующие плюсы:
Как насчёт пути номер 0 - использование CF-флешек?;) Они по интерфейсу совместимы с IDE.

[Sonic]

Как насчёт пути номер 0 - использование CF-флешек? Они по интерфейсу совместимы с IDE.
Нормально. Просто я побоялся за стоимость - около 1000 рублей за самую дешевую карточку.
Думаю, собственный накопитель можно сделать со стоимость рублей за 300.
Хотя, если подумать... Карты памяти дешевеют... Так что пожалуй ты и прав. Через некоторое время карточка будет стоить рублей 500.

[CHRV]

Итак, предложение №1. Разработка TR-DOS-совместимой дисковой системы, способной работать с ЛЮБЫМИ видами носителей информации, а не только с дискетками. Ключевые аспекты реализации следующие:
1. Нахождение в ПЗУ, оригинально предназначенном для TR-DOS.
2. Полная совместимость с TR-DOS по вызовам бейсика и #3D13.
3. Расширенный набор вызовов #3D13, обеспечивающий полноценную работу и легкость переадаптации игр и прочих программ, работающих вне контекста ОС (без системных переменных).
4. (возможно) ограниченная совместимость на уровне прямых вызовов наиболее часто используемых подпрограмм.
5. Поддержка подкаталогов на всех видах носителей информации.
6. (в перспективе, при необходимости, требуется аппаратное вмешательство) обеспечение совместимости на уровне системных вызовов с прочими (псевдо)дисковыми системами (Disciple, Opus, +3, Microdrive, и т. д.) с целью обеспечения работоспособности программ без необходимости переадаптации.
В качестве конечного результата мне видится прошивка (несколько версий аппаратно-зависимых прошивок) ПЗУ, вставляемого взамен имеющегося.

Привет! Рад видеть!
Ознакомся с http://atmturbo.narod.ru/projects/hdd_prj.htm.
Прошивка уже готова и я ее пробовал! Сейчас дописывается менюшка стартовая и прочие вещи, будет поставляться с АТМ!
Для остальных клонов тоже будет, подробности у UKMZ!

[Sonic]

Ознакомся с http://atmturbo.narod.ru/projects/hdd_prj.htm.
Прошивка уже готова и я ее пробовал! Сейчас дописывается менюшка стартовая и прочие вещи, будет поставляться с АТМ!
ИМХО не очень хорошо что такие требования к памяти.
А что если поступить следующим образом:
1. Из ПЗУ TR-DOS выносим нафиг стартер (RST 0) - имхо необходимость набрать RANDOMIZE USR 15616 - небольшая потеря. Можно также убрать работу с #-файлами, которые так и не нашли использования.
2. За счет освободившегося места вводим новые функции #3D13, которые работают, например, так:
LD IX,LoadRequest ; структура, описывающая вызов
LD HL,Dest ; указываем, куда грузить
LD C,#20 ; загрузить файл
CALL #3D13 ; на выходе в A - код ошибки
.........
LoadRequest:
DEFW Buffer ; указатель на 512-байтовый буфер для
; дисковых операций
DEFW ErrorHandler ; указатель на нашу процедуру отработки запроса
; Retry/Abort/Ignore (в A она должна возвращать 0,
;1 или 2 скажем)
Drive DEFB 0 ; номер дисковода - сейчас работаем с НГМД A
DirCyl DEFW 0 ; цилиндр, сектор и головка - ссылка на текущий
; открытый каталог
DirSec DEFB 0 ; хотя, можно и в LBA-номер блока, тогда будет два DEFW
DirHd DEFB 0 ; в данном примере читаем корневой каталог
DEFB "FILENAME" ; имя файла
DEFB 'C' ; тип файла
На выходе из такого вызова прерывания запрещены (если работаем с дисководом) или оставлены без изменений (жесткие диски к этому не критичны), этим обеспечивается совместимость со многими существующими игрушками.
3. Формат диска изменен следующим образом:
- снято ограничение на количество файлов в каталоге
- введено понятие подкаталога.
- любой каталог не непрерывен, а представляет из себя цепочку секторов, где каждый сектор указывает на следующий. Для отслеживания занятого места, видимо, придется вводить дополнительную карту диска, как в IS-DOS.
- на жестких дисках длина сектора - 512 байтов, адресация идет по CHS или LBA. На флопиках все по-старому.
- файлы по-прежнему непрерывны. Требования располагать их в том же порядке, что и дескрипторы, нет. Процедуру MOVE из ПЗУ тоже выносим, делаем отдельную программу (полагаю на HDD мы не будем ее часто вызывать).
- описанные изменения могут касаться только HDD, формат флопика можно и вовсе оставить прежним для пущей совместимости (вряд-ли кто-то захочет использовать их в качестве основного хранилища, так что можно и пожертвовать подкаталогами на них).
Вот, собственно, и все. Получаем TR-DOS-совместимую систему, переадаптация ПО к которой производится крайне легко (плюс работает большинство из существующего).

[CHRV]

ИМХО не очень хорошо что такие требования к памяти.
Собственно прошивка делалась изначально для АТМ, но без особого труда можно воткнуть в КАЙ-1024 и Profi! Рассчитывали на современную базу. В прочем АТМ единственная машинка сейчас выпускающаяся :) (Не считая запаса Кворумов у Caro).

[Sonic]

В прочем АТМ единственная машинка сейчас выпускающаяся
Это ты верно подметил. Только вот - а каков парк уже имеющихся машин? А что если мы будем рассматривать в качестве целевой аудитории не только Россию, а весь мир (ИМХО Россия в настоящее время - уже мало)?
Смысл идеи - поддержка ИМЕЮЩЕГОСЯ железа

[CHRV]

Это ты верно подметил. Только вот - а каков парк уже имеющихся машин? А что если мы будем рассматривать в качестве целевой аудитории не только Россию, а весь мир (ИМХО Россия в настоящее время - уже мало)?
Смысл идеи - поддержка ИМЕЮЩЕГОСЯ железа
Ты хотел сказать железа имеющего IDE или подобный контроллер ввода?
Для не имеющих сейчас разрабатывается "Hard taper" смотри соответствующий трейд в "железе". У буржуев есть поддержка FLASH и IDE для +3DOS.

[Paul_ls]

IMHO с вариантом 128 упорно спорят 256,512,1024 и т.д.
Прошивка в ПЗУ надежнее, но кто ее будет делать? Посмотрите опрос по ПЗУ! ДОС должна иметь возможность грузиться с HDD, виртуальную память, многозадачность, эмуляцию устроуств и т.д. Если делать для среднестатстической ZX128, то получится IS-DOS.

[CHRV]

IMHO с вариантом 128 упорно спорят 256,512,1024 и т.д.
Прошивка в ПЗУ надежнее, но кто ее будет делать? Посмотрите опрос по ПЗУ! ДОС должна иметь возможность грузиться с HDD, виртуальную память, многозадачность, эмуляцию устроуств и т.д. Если делать для среднестатстической ZX128, то получится IS-DOS.
Ну вот поэтому и решили что для выпускаемых компов надо попробовать такое сделать, а смотришь и остальной народ подтянется. Речь правда идет об эмуляции обращений к ВГ93, чтобы не терять накопленный софт, а не чисто по работе с хардом!

[Sonic]

IMHO с вариантом 128 упорно спорят 256,512,1024 и т.д.
А никто и не говорит что их надо игнорировать.

Прошивка в ПЗУ надежнее, но кто ее будет делать?
Ну, допустим, я ее готов сделать, если вопрос стоит именно так. При условии некоторой оправданности затраченного времени (допустим, ПЗУ с прошивкой продается по 100 руб/экземпляр)

Посмотрите опрос по ПЗУ! ДОС должна иметь возможность грузиться с HDD, виртуальную память, многозадачность, эмуляцию устроуств и т.д. Если делать для среднестатстической ZX128, то получится IS-DOS.
Так, так, так, СТОП!!!
Это уже все реализовано и не раз, насколько я понял. Развития не получает по простой причине - отъедает всю память.
Итак, раз уж мы снова говорим о новой ОС, то вот ИМХО первые критерии, которым она должна удовлетворять (и именно от этого надо плясать, а ни от чего другого, иначе мы попросту остаемся без софта):
1. Поддержка ПЗУшного BASIC-48. Простыми средствами, наподобие TR-DOSного RANDOMIZE USR 15619:REM:... Без отбирания верхней памяти под резиденты.
2. Предоставление в пользование программ НЕ МЕНЬШЕ памяти, чем это делает TR-DOS.
3. Работоспособность при области нижней памяти в 48 кб, полностью занятой программой пользователя.
Все полностью ОЗУ-резидентные системы не проходят по этим показателям.
Из этого можно нарисовать например следующую модель распределения памяти (адреса не помню за давностью лет):
1. ПЗУ - 16 кб. В нулевой странице (вместо бейсика-128) - базовая часть ОС (эквивалент KickStart на Амиге). Обеспечивает загрузку с носителя (FDD или HDD) и машинно-зависимый менеджмент страниц.
2. экран - 6912 байтов;
3. буфер принтера - 256 байтов - требуется для функционирования бейсика. ZX-LPRINT 3 им пользуется для своих целей, при его отсутствии первая команда работы с принтером его засрет, посему там разместить ничего не получится.
4. системные переменные Бейсика - требуются для функционирования бейсика как такового
5. на месте системных переменных TR-DOS располагаем BASIC HELPER - резидент, вызываемый вместо 15619, отрабатывающий обращения из бейсика. Ну или альтернативно - патч RST 8, отрабатывающий расширения бейсика (совместимые с Microdrive или свои собственные - отдельный вопрос), хотя это сложнее и наверное требует больше памяти.
6. ВСЕ. Дальше - программа пользователя.
Загружаемая часть ОС хранится в верхней памяти. Задача BASIC HELPER'а при обращении к нему - зная номер страницы и стартовый адрес модуля поддержки BASIC, вызвать модуль, по возврату включить обратно 0 страницу, вернуться. ВСЕ.
Средствами ПЗУ все страницы виртуализируются (жестко спроецированные с #4000 и #8000 выбрасываются), каждой странице присваиваем виртуальный номер от 0 до 255 (достаточно?). Страницы имеют динамический менеджмент памяти. Инсталляция модуля (например загружаемого драйвера) происходит следующим образом: размер мы знаем, ищем самую верхнюю страницу с достаточным местом, грузим модуль, линкуем адреса (модуль релоцируемый), получаем номер страницы и стартовый адрес модуля. Информация о занятых/свободных областях хранится внутри самой страницы. Ограничение - размер модуля не больше 16 КБ, имхо не сильная проблема.
ОС не имеет жестко заданной области системных переменных, параметры передаются через структуры (как в IS-DOS, AmigaOS, и т. д.). Все данные для работы модулей хранятся там же, где и сами модули - в страницах. Какой механизм использовать для обеспечения возможности их модификации из программы пользователя - дело автора модуля.
Загружаемая часть ядра ОС - тоже модуль, загружается первым и хранится в самой верхней странице ОЗУ, ПЗУ вызывает его, зная этот номер страницы, переходом на адрес #FFFD (этим он отличается от остальных модулей). Этот модуль содержит все, что не уместилось в ПЗУ (в том числе и механизм взаимодействия с остальными модулями, таблицу их размещения, основные рабочие переменные ОС, и т. д.)
Описанная карта нижней памяти действительна только при загруженной поддержке бейсика. Изначально при загрузке бейсика в карте памяти нет. Буфера принтера, системных переменных BASIC и BASIC HELPER'а нет. Ограничений на использование HL' и IY тоже нет. Программа пользователя вызывается с включенной 0 страницей ПЗУ и вызвает точки входа ОС прямо оттуда. Переключаться в ПЗУ 48 кб можно, но осторожно (а зачем? ;-)) Единственное, что необходим знать ПЗУшным подпрограммам - номер самой верхней страницы памяти; его можно сделать обязательным аргументом для вызовов ПЗУ и сообщать программе пользователя при старте. Загружаемые модули можно в принципе вызывать и напрямую, зная номер страницы и стартовый адрес модуля, для этого в ПЗУ должны быть функции типа FindModule (этакий аналог OpenLibrary() на Амиге) и SetPage() - включение страницы с заданным номером.
О многозадачности. Увы, это факт, но полноценную вытесняющую многозадачность на ZX реализовать можно только при условии, что мы ограничим пространство программ пользователя в 16 кб. Тогда получаем одну страницу на задачу. Тут были ссылки на UZIX - он сделан именно так. Только на MSX можно переключать страницы в любом окне, а не только в верхних 16 кб. Конкретно в UZIX используются верхние 32 кб. Так что возможна реализация ограниченной многозадачности поверх описанной ОС, но при этом использование уже существующих программ невозможно принципиально, а это есть большущий минус, из-за которого имеющиеся проекты ОС потерпели крах.
Единственная проблема - конфигурация со 128 кб. Придется ухищряться с игрушками, занимающими всю память без остатка и желающими при этом работать с дисками. Увы, совсем без системных переменных, на голом ПЗУ, никакая DOS работать не может. Посему минимальное требование для вызова ОС - нетронутое содержимое как минимум одной страницы (при желании модуль SYSTEM можно легко переместить из самой верхней страницы в любую другую, при этом работоспособность менеджера подгружаемых модулей скорее всего потеряется, но файл прочитать/записать на нативной файловой системе можно - требуемая поддержка есть в ПЗУ). Если игрушка подгрузки/записи не требует - вуаля, делаем что хотим, выходим по кнопке Reset. :)
Для совсем уж тяжелых случаев - TR-DOS у нас никуда не девается, но ИМХО этих случаев мало. С загрузкой с флопа под музыку придется проститься, однако, хотя через это пожалуй все платформы проходили, никто не умер. ;)
Вот концепция. И никакая другая ИМХО работать не будет.

[lvd]

O многозадачности. Увы, это факт, но полноценную вытесняющую многозадачность на ZX реализовать можно только при условии, что мы ограничим пространство программ пользователя в 16 кб.

Хм - это с какого же перепоя такое? Какое дело многозадачности до того, где программы сидят? Ты бы лучше о контроллере прерываний бы подумал...

[Paul_ls]

Ну, допустим, я ее готов сделать, если вопрос стоит именно так. При условии некоторой оправданности затраченного времени (допустим, ПЗУ с прошивкой продается по 100 руб/экземпляр)

И посылать неграм в африку, которые тоже хотят новую ОС на свой ZX? Ведь кроме Москвы есть еще необъятная Родина и загнивающий капиталлизм. А при разработке ОС новые версии будут выходить 2 раза за 1 час, и что ПЗУ перешивать, и опять на почту? В таком случае, ОС будет жить только на эмулях и всё.

Нужна не новая ПЗУ, а минимальные изменения в существующих, которые дадут спокойно работать всем остальным реализациям ОС. А на SCORPIONе и переделывать ничего не надо, там и так всё перехватывать можно, вплоть до RESET :)

А память выше 128 для того и нужна, чтобы ее не для ALASMA использовать и рамдисков всяких да копировщиков. Ведь посчитайте коэффициент использования памяти выше указанного? Стремиться к 0. Так зачем она вообще? Давайте возьмем напильники и дружно отпилим. Ведь если ориентировать ОС на стандарт 128, то это опять получится либо рамдиск, либо буфер для копировщика и всё. А HDD просто расширение возможности (тоже отпилим).

Естественно, при работе новой ОС снизится быстродействие системы в целом из-за диспетчеризации ресурсов, но кто вам мешает писать демки под чистый TRDOS (как в Windows single mode MSDOS)?

[Sonic]

И посылать неграм в африку, которые тоже хотят новую ОС на свой ZX? Ведь кроме Москвы есть еще необъятная Родина и загнивающий капиталлизм. А при разработке ОС новые версии будут выходить 2 раза за 1 час, и что ПЗУ перешивать, и опять на почту? В таком случае, ОС будет жить только на эмулях и всё.

Да, посылать. Желающим/способным - файл. Нежелающим/неспособным - ПЗУ. Впрочем, копировальщики и так найдутся.


Нужна не новая ПЗУ, а минимальные изменения в существующих, которые дадут спокойно работать всем остальным реализациям ОС. А на SCORPIONе и переделывать ничего не надо, там и так всё перехватывать можно, вплоть до RESET

А память выше 128 для того и нужна, чтобы ее не для ALASMA использовать и рамдисков всяких да копировщиков. Ведь посчитайте коэффициент использования памяти выше указанного? Стремиться к 0. Так зачем она вообще? Давайте возьмем напильники и дружно отпилим. Ведь если ориентировать ОС на стандарт 128, то это опять получится либо рамдиск, либо буфер для копировщика и всё. А HDD просто расширение возможности (тоже отпилим).

Тогда - читай вторую часть того письма, на которое ты ответил. Там все есть - и доп. память и винт и диспетчеризация ресурсов.
Память выше 128 кб есть не у всех. Тем более - опять же, читай, ограничения там будут, так что стимул ставить больше памяти есть.
При такой реализации новая ПЗУ не будет выходить так часто. Тем более что никто не заставляет продавать нестабилные development-версии.

[acidrain]

Нормально. Просто я побоялся за стоимость - около 1000 рублей за самую дешевую карточку.

Если угодно могу продать самый дешевый в районе 15 уе или того меньне, причем не в еденичном экземпляре, т.е. это реальная оптовая цена. Свою на 256 метров я купил менее чем за 20 $. Что не намного больше 300 р. изобретаем велик, господа ;).

[ukms[z]]

Sonic
минимальные требования для работы эмулятора - наличие возможности чтения из порта #7ffd или возможность использования дополнительной страницы озу не затрагивая вышеуказанный порт.

а вообще читаю и диву даюсь - большинство идей уже воплощено в коде :)

вот к примеру совсем немного из мануала к vtr-dos 2.5xt:

set_vtrd_map
замена/востановление стандартной разводки памяти под рамдиск,

по умолчанию соотвествующей используемой в honey commander 4.0.
карта памяти берётся по адресу = (#80 or подкоманда)*256.
в этой версии карта памяти должна состоять из номеров страниц #00..#7F,
все иные значения заменяются идентификаторами недействительной страницы,
а так же иметь длину 256 байт. т.к. карта памяти в длину обычно
меньше 256 байт, то последние байты должны устанавливаться значениями
недействительной страницы равным #FF
номера страниц выше #40 являются страницами пзу и нумеруются в обратном порядке, т.е. #40 на самом деле является #3f страницой пзу

set_page_hook
установка/удаление обработчика обращений к недействительным страницам

общий размер обработчиков не может быть больше #1FFF байт
<для компиляции> стартовый адрес РАБОТЫ кодового блока обработчиков = #4200
блок обработчиков загружается в страницу #38 и выполняется из неё в окне #4000
прерывания запрещены.

set_nmi_hook
установка/удаление обработчика нажатия клавиши magic

производится копирование кодового блока в страницу #38 откуда он
и будет работать, стартовый адрес #6200
подкоманды не используются

set_reset_hook
установка перехватчика нажатия клавиши reset и инициализации vTR-DOS

в данной версии всегда копируется все 16кб данных,
из которых 1-й байт и 3 последних изменяются соответствующим образом
для работы резидента (см. соответствующую литературу)

подкоманды не используются

set_io_hook
установка/удаление перехватчика доступа к расширенным портам

кодовый блок копируется в страницу #38, стартовый адрес обработчика #7200
подкоманды не используются

DMS_CALL
вызов драйвера

производит вызов драйвера или операционной библиотеки по их идентификатору. регистры передаются драйверу/операционной библиотеке.

DMS_LOAD
установка драйвера

драйвер представляет собой кодовый блок вызываемый прикладными программами для отработки машинно-спецефичных задач. выполняется из невыгружаемой страницы с открытыми портами. условно драйвера делятся на группы. каждой группе по-порядку присвоены следующие идентификаторы :

00 драйвера верхней памяти (только один может быть загружен)
01 драйвера логических накопителей (только один может быть загружен)
02 драйвера файловых систем
03 драйвера физических накопителей
04 драйвера графических подсистем
05 драйвера ввода-вывода
06 операционная библиотека
07 резидент реального времени

следует заметить что работа группы 1 не имеет смысла без установки драйверов группы 2, а той в свою очередь - группы 3.

формат кодового блока драйвера следующий :

#C000 DMS_CALL: JP _CALL ;рабочий вызов драйвера
#C003 DMS_LOAD: JP _INIT ;первоначальный вызов драйвера (при инициализации)
#C006 DMS_KILL: JP _KILL ;финальный вызов драйвера (при удалении)
#C009 DMS_FIND: JP _VERSION ;идентификация драйвера по группе и версии
#C00C DMS_MESS: JP _HARD_INIT_MESSAGE ;сообщение BIOS об аппаратных событиях
#C00F _TX_VERS: DB 'СТРОКА КОНТРОЛЛЕРА' ;понятное текстовое имя драйвера
#C100 _CODE: ... ;тело драйвера ...

или к примеру вот

машиннозависимые подкоманды защищённого режима :

- подкоманда 80. vendor_protect_hide
= тихий режим защиты. подключение запрещённых страниц игнорируется. попытки использования системного порта игнорируются. программы использующие верхнюю память могут работать неправильно. не рекомендуется.

- подкоманда 81. vendor_protect_break
= обычный режим защиты. при обращении в запрещённую страницу памяти или к системному порту выполнение программы прекращается и демонстрируется сообщение.

там много, всё писать сюда смысла нет. если есть желание - пишите на мыло.

[Sonic]

2 UKMZ: Насколько я понял, это все - ATM-specific (судя по требованию наличия окна с #4000)? Тогда жаль что без аппаратных изменений оно непортабельное никуда, кроме Profi.

[ukms[z]]

2 UKMZ: Насколько я понял, это все - ATM-specific (судя по требованию наличия окна с #4000)? Тогда жаль что без аппаратных изменений оно непортабельное никуда, кроме Profi.

окно с 4000 предоставлено для машиннозависимых модулей. а это для каждой машины по-своему компилить, так или иначе - согласись ?
драйвера и всё остальное работает из С000

[Sonic]

]окно с 4000 предоставлено для машиннозависимых модулей. а это для каждой машины по-своему компилить, так или иначе - согласись ?
драйвера и всё остальное работает из С000
А отработчик NMI почему с #4100? Его ведь тоже можно реализовать для всех машин. И Reset-хендлер тоже...
Кстати говоря, можно реализовать их двумя альтернативными способами:
1. Где-то есть переменная, где оно явно прописано.
2. Если область переменных разрушена (пользователю отдано 100% памяти), то производим сканирование ВСЕЙ имеющейся оперативки на предмет наличия следующего (например) тега:
ResTag DC.B "NMIH" ; сигнатура NMI-хендлера (для Reset'а - "RSTH")
DC.W <длина области> ; Длина проверяемой области начиная с ResEntry
DC.W <CRC> ; CRC проверяемой области
ResEntry ; Здесь собственно вызываемый код
Подпрограмма отработки прерывания определяет текущую страницу (машиннозависимо: с помощью чтения портов либо методом интеллектуальной проверки с помощью CRC - образец см. в TR-DOS Magic). Далее производится поиск по всей доступной памяти сигнатуры. При ее обнаружении происходит сравнение CRC указанной области (контроль целостности кода). Если CRC совпала, резидент считается валидным и запускается на выполнение с запрещенными прерываниями. Что делать дальше - абсолютно его дело. На стеке пользователя при вызове прерывания сохраняется только минимум регистров, необходимый для работы функций определения текущей активной страницы и поиска резидента, все остальное - задача резидента (рекомендуется поиметь собственный стек).
Невалидный резидент пропускается с продолжением поиска.
Плюсы: возможна работа совместно с любым программным обеспечением, даже если оно уничтожает системные области.
Минусы: возможный метод защиты - установка в памяти еще одного собственного резидента, блокирующего работу отладчика.

[ukms[z]]

А отработчик NMI почему с #4100? Его ведь тоже можно реализовать для всех машин.

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


И Reset-хендлер тоже...

а это выполняется из С000


Кстати говоря, можно реализовать их двумя альтернативными способами:
1. Где-то есть переменная, где оно явно прописано.
2. Если область переменных разрушена (пользователю отдано 100% памяти)


области переменных теневые. обычная программа их не видит.


то производим сканирование ВСЕЙ имеющейся оперативки на предмет наличия следующего (например) тега:


а смысл ? можно установить в защищённую системную страницу - никто туда не сунется. можно установить как модуль и тоже закрыть страницу от посторонних. и вылавливать сообщения от биоса.

[GriV]

Несмотря на всё моё к тебе уважение, я позволю с тобой не согласиться.
Здесь уже неоднократно тебе намекали о том, что использовать для новой ОСИ ПЗУ неэффективно. Причина: почти все обычные пользователи своих спектрумов видеть не видели никогда ПЗУ и даже не знают где оно там есть. Поэтому вариант с прошивкой ПЗУ отпадает, хотя никто не говорит что это очевидно плохой вариант, да у него есть и плюсы и минусы, но вот например я ни за что не полезу в свой скорп вынимать ПЗУ оттуда и везти её на программатор. На самом деле, прошивка ПЗУ процедура должна быть очень редкая, а как показывает практика версии ПЗУ летят одни за одной чуть не раз в день. Даже отбрасывая факт не очень высокой надёжности носителя (т.е. самой микросхемы), тратить по 100 руб каждый день только на проверку качества работы новой системы и т.д. мне не хочется, а тем более не хочется покупать программатор.
Кроме того, как бы там не было, если вместо ПЗУ TR-DOS стоит какая то модифицированная версия, то это рано или поздно придёт к ситуации "нашла коса на камень", вот например подавляющее большинство дисковых для TR-DOS программ которое есть у меня дома, и даже те немногие что я писал используют точки ПРЯМОГО выхода к регистрам TR-DOS. Предусмотреть все варианты невозможно, поэтому в любом случае ПЗУ DOS оставляется нетронутой. Использование вместо ПЗУ SOS128 тоже не очень правильно, я вообще считаю что ПЗУ никогда не должна иметь ОСи зашитой и тогда всё будет хорошо (старая схема, когда ПЗУ менялась единственный раз - в 1990 году - ПЗУ turbo) это показала. Неофициальные версии ПЗУ я не считаю.
А насчёт самой ОСи я бы так сказал: есть такое положение (продиктованное пратикой) дабы избежать глюков, на каждый ресурс компьютера должен быть менеджер, которые бы его разделял (посмотри на треды, которые есть в данном разделе - менеджер памяти, менеджер процессора = менеджер задач/потоков, менеджер ЖД и т.д.).
Если же всего этого костяка не будет, то не будет возможности РАЗВИВАТЬСЯ. Как справедливо заметил Paul ls - зачем память системе, которая про память то и не знает? Новая система обязана управлять памятью, а даже по первым прикидкам весь вместе костяк "менеджер памяти+процессов+файловой системы" будет занимать далеко не 16КБ...
Да, мы и до этого замечательно под TR-DOS программы делали и геморроились со всем чем можно, не хочется чтобы новая система оставляла эти пережитки...

[GriV]

Я бы тебе всё таки посоветовал ещё раз внимательно посмотреть треды в этой теме, все те вопросы которые у тебя есть так или иначе были разобраны...

[rw6hrm]

Позвольте скромное ИМХО. Почему все разговоры начинаются от 128К? Не секрет же, что по миру пущено куча 48К-шных машин, которые и являются по существу стандартом Спектрума? Мне кажется, что создав нормальную систему для 48К, более "крутые" аппараты автоматически должны будут ее поддержать.

Что касается носителей, то использование HDD полностью неразумно из-за соотношения цена/возможность ипользования пространства. Флопы - только как для совместимости и переносимости программ (речь идет о 3,5 моделях). Вот вариант флэшек - самый оптимальный. Покупается один раз, если мало - есть возможность поменять или подцепить в параллель...

...или сосредоточиться на переходнике на ISA-шину. Хоть устаревшая, но позволит и мультяху подключить, и модем..., такого барахла куча выпущена была, почему бы не использовать?

[acidrain]

создав нормальную систему для 48К, более "крутые" аппараты автоматически должны будут ее поддержать.
Ну не совсем - нельзя привязываться к спеки 48 адресам, ведь самая большая загвоздка имхо - это память и дурацкая страничное деление на 128 и выше.

ИСА - имхо нах. А вот CF или (лучше для меня) ММС - самый правильный вариант, можно еще и pcmcia. =)

[rw6hrm]

Why ISA нах? Подключая только мультяХу получаем и флоп, и хард, и принтер, и СОМ зараз. Уже в конце 90-х была разработка, но до ума ее так и не довели, где-то валяется описание. Что касается карточек - то лучше выбирать IDE-совместимую.

[Максагор]

Что касается носителей, то использование HDD полностью неразумно из-за соотношения цена/возможность ипользования пространства.

Сразу видно человека, который ни разу не использовал винт на Спеке и не видел как его использовал. А я с ним работал, работаю и буду работать, потому как очень удобно!


...или сосредоточиться на переходнике на ISA-шину. Хоть устаревшая, но позволит и мультяху подключить, и модем..., такого барахла куча выпущена была, почему бы не использовать?

Нафиг мультяху! Что, у нас проблема сконтроллерами дисководов? А модем лучше всего подключать не через ISA (сейчас такие все труднее найти), а внешний через RS-232. ВОт этот интерфейс и надо подключать.

[CHRV]

Why ISA нах? Подключая только мультяХу получаем и флоп, и хард, и принтер, и СОМ зараз. Уже в конце 90-х была разработка, но до ума ее так и не довели, где-то валяется описание. Что касается карточек - то лучше выбирать IDE-совместимую.
ISA-16 технологически сложно подключить к Спектруму, обьяснять почему не буду...
ISA-8 подключали но опять же это нетехнологичный путь, уже сформировались спектрумовские стандарты (заметь не ПЦшные) под которые написан софт. А кто будет писать под ИСА?

Во вторых это оффтопик не в тему!

[jtn]

Подключая только мультяХу получаем и флоп, и хард, и принтер, и СОМ зараз
г, подключение иса16 сродни подключению винта только толку 0