Вектор-06Ц: Операционные системы

[svofski]

зачем образ с носителя(SD, IDE) загружать в некую дополнительную память, выполняя таким образом монтирование, потом еще и размонтирование с обратной 'выгрузкой' этого образа на носитель, если была запись?

Я присоединяюсь к этому вопросу, только я бы его расширил еще дальше.

Если я правильно понимаю, речь идет все еще о работе с образами FDD. Но по-моему основной кайф поддержки SD нативно состоит в том, что можно будет сделать поддержку FAT и не надо будет делать никаких образов. Я не знаю кому как, а лично я все эти образы терпеть не могу.

Какие теоретические пределы адресации у файловой системы в МикроДОС?

Софт, который хочет дисковод напрямую, это отдельная категория. Понятно, что к нему все это неприменимо. Ну и ладно.

[ivagor]

о по-моему основной кайф поддержки SD нативно состоит в том, что можно будет сделать поддержку FAT и не надо будет делать никаких образов.

Примерно как у msx dos с современными патчами. Там с sd можно работать без образов, прямо с файлами. Пробовал только на плисовых девбордах, но думаю на реале должно быть примерно так же.

[b2m]

Какие теоретические пределы адресации у файловой системы в МикроДОС?

Я так понимаю, твоя идея в том, чтобы полностью переписать МикроДОС? Чтобы это нечто новое работало с FAT и предоставляло API МикроДОС? Это-ж сколько человеко-дней потратить надо! Одно дело - читалка, типа моей xsd, и другое дело полная поддержка файловой системы... Алло, мы ищем таланты!

- - - Добавлено - - -

Или ты предлагаешь что-то типа контроллера Морозова?

[svofski]

b2m, я скорее о том, что сказал ivagor - МикроДОС с современными патчами. Человекочасы меня в таких проектах не пугают, никто не торопится и доделывать до конца совсем необязательно Ну что такого страшного в поддержке FAT, или в проекции ее на старые CP/M-ные вызовы? Они все довольно абстрактные, кроме пары особо дурацких, которые надеюсь нечасто используются.

Но это правда большой проект. Для начала можно было бы сделать что-то минимальное -- заменить процедуры работы с дисководом в БДОС на работу с SD картой через, например, xsd (BTW, прости, я не знаю, где быстро посмотреть на xsd, схему и код?). Можно добавлять смещения и разбивать карту на много дискет. Насколько я понимаю поддержка твердых дисков примерно так и работает. Или такое для SD уже сделано?

(Я совсем не имею ввиду, что я сам собираюсь это делать. То есть не надо сидеть, сложа руки и думая, что а, ну это svofski уже все равно что сделал, поддержку FAT и SD карт делать не буду )

[PVV]

Если я правильно понимаю, речь идет все еще о работе с образами FDD.

да. Суть в том, что если уж менять код на поддержку работы с образами в неком стороннем ОЗУ, то это вариант сделать аналогичный функционал, но без этого стороннего ОЗУ(меньше требуется аппаратных доработок - ~1МБ ОЗУ сделать не совсем тривиальная задача).

Для начала можно было бы сделать что-то минимальное -- заменить процедуры работы с дисководом в БДОС на работу с SD картой через, например, xsd (BTW, прости, я не знаю, где быстро посмотреть на xsd, схему и код?).

посмотреть схемы и код можно здесь, все, что отвечает за работу с FAT взято из xsd на 100%.

- - - Добавлено - - -

Примерно как у msx dos с современными патчами. Там с sd можно работать без образов, прямо с файлами. Пробовал только на плисовых девбордах, но думаю на реале должно быть примерно так же.

Именно таким образом, заменив функции обращения к IDE на SD из кода SDOS(xsd), получил поддержку SD. На своей 'железной' макетке(реале) проверил, работает... Однако там FAT12 была изначально, а это разделы до 32МБ, и переделать такое на FAT16 существенно проще.

[ivagor]

Однако там FAT12 была изначально, а это разделы до 32МБ, и переделать такое на FAT16 существенно проще.

Да уж, если бы сразу в микродосе был FAT, то было бы намного проще. А сейчас вероятность внедрения FAT16 в микродос ненамного выше вероятности адаптации msx dos 2 с fat16 для вектора.

[Advertiser]

[Improver]

После публикации исходников Т-34, тут уже на две страницы сообщений, к этому добавлю немного, что я думаю по возможному развитию МДОСа...

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

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

Ещё, кстати, будут актуальны модули-драйвера на PC-клавиатуру (подключаемую к разъёму ПУ), сетевую карту, драйвер для доступа к ROM-картриджу с обращением по букве диска и т.п. В общем, универсальная единая МДОС имеет кучу плюсов при ограниченных на разработку человеко-часах, но только её надо ещё сделать.

[KTSerg]

А кто как вообще решает проблему создания "адресно не зависимых" программ/драйверов для Вектора, запускаемых с любого адреса?
Я решал через создание таблица адресов, в которых нужно исправить "адреса перехода" или "переменной"... и соответствующего загрузчика...
Может есть более простой путь?

[KTSerg]

Я не могу у себя найти доки, в которых расписано значение инфы, которую ОС помещает в первые 128 байт памяти Вектора.
Там вроде где-то хранится адрес верхушки свободной памяти и ещё какая-то инфа.
Подкиньте пожалуйста.

[PPC]

Я не могу у себя найти доки, в которых расписано значение инфы, которую ОС помещает в первые 128 байт памяти Вектора.
Там вроде где-то хранится адрес верхушки свободной памяти и ещё какая-то инфа.
Подкиньте пожалуйста.

Слово по адресу 6 хранит самый младший адрес, используемый операционной системой (или максимальный размер TPA)