Подкаталоги в VTR-DOS и подобных разработках.

[Sonic]

Хочу подарить идею.
1. VTR-DOS эмулирует реальные дисководы посредством образов, хранящихся на жестком диске, на уровне эмуляции ВГ93.
2. Пользователи хотят иметь систему с подкаталогами.
Отсюда напрашивается решение: ввести новый тип файла - ссылку на образ. Это может быть файл с неким новым типом (например "dir" в 3-символьном представлении), внутри которого хранятся абсолютные координаты на HDD того образа, на который мы переходим (например имя файла образа, если несущая файловая система на HDD - FAT).
Таким образом, смена образов может осуществляться абсолютно прозрачно, одной-единственной командой (или нажатием Enter в коммандере). Никаких меню с выбором образов.
Например: GO SUB "Sources"
Можно перемещаться по цепочке ссылок, например:
GO SUB "Games/Arcade"
Можно расширить синтаксис команд LOAD, SAVE и пр., работающих с именем файла, чтобы они могли обращаться за пределы текущего образа, например:
LOAD "GFX/Porn/Pervert/TwoCows"SCREEN$
Более того, структуре не обязательно быть древовидной. Ссылка может указывать на абсолютно любой образ, хоть на родительский. Это даже не директории, а симлинки в терминологии UNIX-подобных файловых систем. Можно делать несколько ссылок из разных мест на один и тот же образ, замыкать пути в кольцо, и т. д.
На уровне асма поддержка такой системы ссылок потребует введения новых функций #3D13, необходимых для перехода по ссылке, а также работы с длинными именами (с указанием пути). Старые функции при этом будут работать с текущим образом, таким образом данная реализация является абсолютно совместимой сверху вниз с уже существующими программами.
На втором этапе реализации предлагаю для жесткого диска зарезервировать еще одно устройство - E:. Много программ, использующих доступ через #3D13, также смогут с ним работать. Для обеспечения совместимости с остальным ПО можно ввести команды переназначения устройств A:, B:, C: и D: с физических дисководов на эмулируемые и обратно, например:
FOR A: "Magazine/ZX-Format/Issue2" - включаем маппинг устройства A: на указанный образ
FOR A: "" - маппинг устройства A: на тот образ, в котором мы сейчас находимся
FOR A: - отключаем маппинг устройства A: и возвращаем на место дисковод.
На третьем этапе, можно реализовать поддержку удлиненных образов (256 логических дорожек вместо 160). TR-DOS это вполне допускает по своей идеологии; большинство, если не все, программы смогут с ними работать.
Также хотелось бы связаться с авторами VTR-DOS на предмет использования ее для проекта "файл-сервер". В виду хорошести разработки я предложил бы внедрить поддержку сервера в нее наряду с поддержкой жесткого диска вместо создания собственной системы.

[Advertiser]

[Максагор]

Хочу подарить идею.
1. VTR-DOS эмулирует реальные дисководы посредством образов, хранящихся на жестком диске, на уровне эмуляции ВГ93.

Как один из соавторов отвечаю:
vTR-DOS НЕ ЭМУЛИРУЕТ реальные дисководы НА ЖЕСТКОМ ДИСКЕ. Он эмудлирует люразы в верхней памяти мегабайтного ATM-turbo 2+ (а также потенциально - на других мегабайтных компах). А вот как в эту память попадет образ, уже vTR-DOS совершенно не волнует. Это дело пользователя и других НАСТОЯЩИХ (в отличие от TR-DOS) осей. На данный момент для vTR-DOS написана поддержка под CP/M (грузилка(в память)/запускалка, сохрнялка(из памяти на внешние носители), а также просмотрищик каталога в образах), а также под iS-DOS (грузилка в память, пока еще глючноватая).

2. Пользователи хотят иметь систему с подкаталогами.

Ну и пусть себе хотят на здоровье! Тем более, что система такая уже давно есть - iS-DOS. И можно спокойно размещать образы TRD и SCL по подкаталогам и грузить их по мере надобности.

Отсюда напрашивается решение: ввести новый тип файла - ссылку на образ. Это может быть файл с неким новым типом (например "dir" в 3-символьном представлении),

Ага. В iS-DOS такой файл называется EXTENT.TXT(или EXTKEY.TXT), где данная строчка для запуска образа будет выглядеть так(к примеру):

TRD: Q:UTIL\ldtrd
SCL: Q:UTIL\ldscl

На третьем этапе, можно реализовать поддержку удлиненных образов (256 логических дорожек вместо 160). TR-DOS это вполне допускает по своей идеологии; большинство, если не все, программы смогут с ними работать.

Поддержка удлиненных образов сделана, правда не на 255 дорожек, так как памяти не хватит на столько. Все ниже сказанное не имеет смысла, ибо изначальное предположение об vTR-DOS было неверным. Только хочу добавить, что различные дополнительные функции в vTR-DOS действительно реализоваты в специальной кернали, не затрагивая #3D13 и прочее.

Также хотелось бы связаться с авторами VTR-DOS на предмет использования ее для проекта "файл-сервер". В виду хорошести разработки я предложил бы внедрить поддержку сервера в нее наряду с поддержкой жесткого диска вместо создания собственной системы.

Ну, если основной разработчик UKMS[z] найдет нужным откликнуться, то можно, конечно и пообсуждать. Но мое личное мнение состоит в том, что наворачивать TR-DOS не просто не нужно, но и бесполезно, особенно на машинах с винтом. Та доработка, что была сделана Юрой UKMS[z] при моем скромном участии, была единственной, которая оправдана. Ее цель - "отвязать" TR-DOS от реальных дискет, чтобы решить извечную проблему новых спектрумовских осей, когда система написана, а весь основной софт и игры все равно остались под древнюю TR-DOS, и переделывать их некому, а часто и невозможно. Теперь же эта проблема снимается тем, что почти весь тырдосный софт можно спокойно хранить в файловой системе данной оси в виде образов и запускать их оттуда(кроме тех прграмм, которые лезут выше 128Кб, но наких - подавляющее меньшинство). А с ATMовской поддержкой резидента (специальный перехватчик кнопки RESET по нулевым адресам ПЗУ, передающий управление программе пользователя в верхней памяти) легко можно организовать возврат в эту систему по кнопке RESET (в случае с ATM с контроллером пЦ-клавы - по комбинации Ctrl+Alt+Del).

В общем, мое мнение - надо развивать уже существующие системы, прежде всего iS-DOS, под которую вполне реально написать поддержку сервера.В крайнем случае, написать новую ось (Breeze, ау!!! Где товя Aqua?Doors?!).

[Shiru]

Он эмудлирует люразы

Мама родная....

[ukms[z]]

Sonic

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

На третьем этапе, можно реализовать поддержку удлиненных образов (256 логических дорожек вместо 160). TR-DOS это вполне допускает по своей идеологии; большинство, если не все, программы смогут с ними работать.

это реализовано (только сейчас принудительно стоит ограничитель), но через пользовательскую таблицу памяти. если памяти не хватит, (а её не хватит, т.к. как минимум 8 страниц отдано под текущее приложение + 1 системная +1 резидент если есть) то потребуется устанавливать свой драйвер виртуальной памяти.

Также хотелось бы связаться с авторами VTR-DOS на предмет использования ее для проекта "файл-сервер". В виду хорошести разработки я предложил бы внедрить поддержку сервера в нее наряду с поддержкой жесткого диска вместо создания собственной системы.

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

[Максагор]

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

Там я еще чуток глючков мелких отловил (не в самом vTR-DOS), а в менюшке. На днях отпишусь про них подробнее, как время будет.

[Максагор]

Мама родная....

Опечатка - не ошибка. Краснеть не заставит.

[Sonic]

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

Ну я понял, работой непосредственно с образами у тебя занимается внешний софт под другой ОС

это реализовано (только сейчас принудительно стоит ограничитель), но через пользовательскую таблицу памяти. если памяти не хватит, (а её не хватит, т.к. как минимум 8 страниц отдано под текущее приложение + 1 системная +1 резидент если есть) то потребуется устанавливать свой драйвер виртуальной памяти.

А если не секрет, зачем держать весь образ в памяти? Что мешает держать его непосредственно на HDD?
И как же тогда ты планируешь работать на не-мегабайтных машинах?

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

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

[ukms[z]]

А если не секрет, зачем держать весь образ в памяти?

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

Что мешает держать его непосредственно на HDD?

ничего не мешает. но я посчитал лишним встраивать в прошивку драйвера под разные HDD и разные FS. это всегда может реализовать сам пользователь - загрузив драйвер своего накопителя.

И как же тогда ты планируешь работать на не-мегабайтных машинах?

на 128к ? никак. пора товарищи выбираться из своих тесных пешерок
на 256к и больше ? элементарно. ставите драйвер накопителя и всё. можете в пзу зашить.

[Максагор]

на 128к ? никак. пора товарищи выбираться из своих тесных пешерок
на 256к и больше ? элементарно. ставите драйвер накопителя и всё. можете в пзу зашить.

Юра, до тех пор, пока у тебя существует жесткая привязка новых системных переменных к странице #38 - не элементарно. Уже на ATM-turbo 2+ с памятью не 1 мег, а 512Кб прошивка не идет. Проверено. Разве что ты в самой последней версии что-то изменил, о чем я еще не знаю.

[ukms[z]]

разве ? если я правильно понимаю работу т2+ 512к то старший бит системной страницы должен обрезаться и превращаться в #18. эта страница не лежит в общей памяти zx-128k и нет препятствий к использованию. нужно загрузить свою таблицу страниц на маленький рам диск или забитой идентификаторами недействительных страниц и свой драйвер ввода-вывода из таких страниц для прямого ремапа на винт.