Расширяем TR-DOS

[AndTorp]

Я за усовершенствование TR-DOS без потери совместимости с ПО. Но меня мало интересует размер дискеты, т.е. 640K меня, в подавляющем большинстве случаев, устраивает.

Меня очень не устраивает НЕсегментированность файлов. Было бы значительно интереснее "прикрутить" сегментированность. Пусть даже за счет потери некоторого количества дорожек-секторов и уменьшения скорости чтения/записи на дискетах нового варианта TR-DOS.

Можно попробовать такую концепцию.
Новая TR-DOS должна работать с двумя типами дискет. Различать можно по байту #E7 служебного сектора: #10 - старый вариант (несегментированный) и #11 - новый (сегментированный).
Начиная с дорожки 1 располагается информация о сегментации файлов. Файл может иметь объем до 255 секторов, т.о., для сохранения информации о каждом секторе файла (номер дорожки+номер сектора) необходимо 510 байт, т.е. два сектора. Для 128 файлов - 256 секторов или 16 дорожек.
При работе с дискетой, TR-DOS определяет ее тип и работает с ней по старому или новому принципу. Т.е. ПО, работающее через #3d13, не должно замечать разницу в чтении/записи на дискету, независимо от сегментированности файла.
При этом не обязательно "держать" все функции новой TR-DOS в 16K ПЗУ. Такие функции как форматирование и конвертация в старый/новый форматы могут быть в виде программ на внешнем носителе.


З.Ы. В 1989 году была разработана интересная система https://speccy.info/C-DOS

Отличительной особенностью является использование кластерной системы записи информации. Такая система предусматривает наличие на дискете таблицы размещения файлов, (FAT) которая содержит данные о состоянии всех кластеров (единиц хранения информации). Это позволяет, в частности,при форматировании дискеты проверять качество носителя и, в случае обнаружения дефектных участков, исключать их из дальнейшего использования. Благодаря специальному формату разметки, емкость одной дискеты составляет более 800 КБ пространства пользователя.

[Advertiser]

[NEO SPECTRUMAN]

Меня очень не устраивает НЕсегментированность файлов.

и чем она тебе не устравиает и что тебе даст фрагментация файлов?

даже если сделать таблицу соответствия виртуальных секторов физическим
все равно с точки зрения трдоса будут торчать удаленные файлы
и в конечном итоге все упрется в 128 файлов (когда на диске их будет штук 10)

если же постоянно сжимать каталог прямо средствами трдос-а (напомню что у него нет своей памяти под все это)
то ВНЕЗАПНО неожиданно для программы может изменится весь каталог
и она будет писать не туда куда надо
а по адресам из копии не измененного каталога который лежит в памяти

так что совместимости не будет
так же как и каких то преимуществ

[AndTorp]

и чем она тебе не устравиает и что тебе даст фрагментация файлов?

Было бы удобнее работать с несколькими файлами, например, в том же ZASM. Потому что, например, файлы изображений имеют (в большинстве случаев) стандартный размер - 6912 байт и некоторые графические редакторы поддерживают возможность записи "поверх" предыдущего файла. С текстами так не получится.

даже если сделать таблицу соответствия виртуальных секторов физическим
все равно с точки зрения трдоса будут торчать удаленные файлы

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

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

Ну папками нас и в TR-DOS не удивишь

Сейчас нет, а для времени создания (1989) - круто.

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

Это хорошо, когда на внешнем носителе несколько сотен гигабайт, на малых объемах будет весьма расточительно.

[NEO SPECTRUMAN]

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

это плохо вяжется с большими файлами (нарезкой)
для которых собственно и нужно расширение трдосов

ну и новые файлы будут ВНЕЗАПНО создаваться посреди каталога
сортированость будет еще хуже чем сейчас

и вообще
это равносильно тому что сразу выделять под файл 64К
и хоть 16М образ это без проблем позволяет

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

[Sayman]

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

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

[AndTorp]

это плохо вяжется с большими файлами (нарезкой)

Для коллекции (1 раз записали на дискету) mod-файлов (или еще чего-то объемного) подойдет, как я предлагал выше, старый (несегментированный) вариант (с максимальным использованием дискового объема). Для работы с файлами, объем которых изменяется, - новый вариант. Новая TR-DOS определяет как отформатирована дискета и работает с ней соответственно. Если ПО работает через #3d13, то все операции по размещению/считыванию сегментированного файла берет на себя TR-DOS. Если прямое программирование контроллера, то старый (несегментированный) вариант.

[Gutten]

Гулять так гулять!
В фирменном мануале по СМУКу упоминалась некая "Micro DOS - лучшее средство для программиста". Что это за диковина и можно ли её прикрутить к спеку?

[zx_]

CDOS да, прикольная


https://web.archive.org/web/20041014...grinenko/CDOS/

[AndTorp]

C-DOS еще и папки поддерживает:


Есть образ ПЗУ и эмулятор, на котором запускается C-DOS?

[Grand]

C-DOS еще и папки поддерживает:

Ну папками нас и в TR-DOS не удивишь. https://zx-pk.ru/showthread.php?p=98252

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

Было бы значительно интереснее "прикрутить" сегментированность.

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