Расширяем TR-DOS
Конечно SD карты и FAT-ы это модно стильно молодежно
но софтварной поддержки у оно мало и много уже не будет...
при этом остается туевая хуча старой софтвари которая про эти ваши fat-ы и не слышала
так же, иногда, как и про выбор дисковода...
но так как 640 килобайт хватит всем
когда хочешь закинуть например каких нибудь .mod-ов
их влазит всего штуки 3...
что вощем то не фонтан
а патчить старые софтвари под фаты и сд карты есное дело никто никогда уже не будет...
и если 640К может и прибито? железно к *****му вг93
но оно не прибито к формату диска и к вызовам $3D13
так что в новый год с новыми концепиями
собственно что мы имеем для адресации положения на диске сейчас
используемые номера дорожек 0...159 (для архаичных дисков еще и 79, 39)
используемые номера секторов 0...15
чего хватит всем 160 дорожек * 16 секторов = 2560 секторов = 655 360 байт
максимальный размер файла
256 байт * 255 секторов = 65280 байт
максимальная вместимость диска в файлах может быть
65280 байт * 128 файлов = 8 355 840 байт
что в 12 раз больше чем "хватит всем"
а максимально можно адресовать вообще
256 дорожек * 256 секторов = 65536 секторов = 16 777 216 байт
и не сложно догадаться
что можно монтерывать увеличенный трд образ прямо с карты
и то что какое то количество старых софтварей смогут с ним работать
(например мои трдос-ные поделки должны будут свободно оно переваривать)
кроме того системный сектор вполне содержит описание формата диска
ну и собственно требуется стандартизация расширенных trd образов
сейчас уже есть 4 варианта
40 * 16 = 640 = 163 840
80 * 16 = 1280 = 327 680
80 * 16 = 1280 = 327 680
160 * 16 = 2560 = 655 360
(4096 системная дорожка)
и описывается оно 8-м сектором 0-й дорожки
+227 тип диска:
$16 10110 - 80-дорожечный двухсторонний,
$17 10111 - 40-дорожечный двухсторонний,
$18 11000 - 80-дорожечный односторонний,
$19 11001 - 40-дорожечный односторонний.
и
+231 - 16 - Количество секторов на дорожке
идем дальше
+225 номер первого свободного сектора
+226 номер первой свободной дорожки
тоже позволяют адресовать все 16М диска
+229...230 количество свободных секторов.
$09F0 - 80 track, 2 side (160-1)*16 (1 системный)
$04F0 - 40 track, 2 side (80-1)*16
$04F0 - 80 track, 1 side (80-1)*16
$0270 - 40 track, 1 side (40-1)*16
тоже позволяет адресовать все 16М
$FF00 - (256-1)*256
варианты расширения
вариант 1
256 * 16 = 4096 = 1 048 576 байт
без потери совместимости при прямом щелкании номером дорожки после каждых 16 секторов
которые могут ВНЕЗАПНО быть при попытках читать по секторно
и таким может даже получится обдурить некоторые сильно умные софтвари которые щелкают напрямую вг-шкой
(если получится запилить перехваты обращения к ней)
но это всего лишь на 393 216 байт больше чем обычное "хватит всем"
бесполезные варианты с изменением размера дорожки
вариант 2
256 * 32 = 8192 = 2 097 152 байт
вариант 3
256 * 64 = 16384 = 4 194 304 байт
вариант 4
256 * 128 = 32768 = 8 388 608 байт (32768 системная дорожка)
под файлы
255 * 128 = 32640 = 8 355 840 что ровно 128 файлов по 65280 байт
что нам и нужно
но если какая либо софтварь захочет гадить на якобы дополнительные сектора
например 160-й то
161 * 128 = 20608 = 5 275 648 то это вполне может быть 80-й по счету полезный файл...
вариант 5
менее рациональный по занимаемому месту
256 * 256 = 65536 = 16 777 216 байт (65536 системная дорожка)
под файлы
255 * 256 = 65280 = 16 711 680 (могло бы влезть ровно 256 если бы их можно было поместить в каталоге)
из которых половина 8 290 304 останется незадействованной
так же 256 секторов невозможно прямо указать в +231 8-го сектора
но можно использовать логичное для такого случая $00
из преимуществ такого варианта
при попытке писать в дальние сектора
161 * 256 = 41216 = 10 551 296
записываемое уже находятся за пределами максимального количества файлов (160-й)
и любая софтварь может срать туда сколько влезет
еще логичные варианты расширения по принципу уплотнения (как бы это могло быть на самом деле)
40 * 16 = 640 = 163 840
80 * 16 = 1280 = 327 680
160 * 16 = 2560 = 655 360
40 * 32 = 1280 = 327 680
80 * 32 = 2560 = 655 360
160 * 32 = 5120 = 1 310 720
40 * 64 = 2560 = 655 360
80 * 64 = 5120 = 1 310 720
160 * 64 = 10240 = 2 621 440
40 * 128 5120 = 1 310 720
80 * 128 = 10240 = 2 621 440
160 * 128 = 20480 = 5 242 880 (маловато будет)
40 * 256 = 10240 = 2 621 440
80 * 256 = 20480 = 5 242 880
160 * 256 = 40960 = 10 485 760
юзабельный только последний вариант
да и выглядят все кроме 256 секторного не очень привлекательно...
ну и тут собственно вопрос какие варианты нужны? (как по мне 1-й и 5-й остальные фтопку)
нужно ли их описывать в +231 +227 чтоб ВСЁ было правильно
или вообще не трогать их для большей совместимости
и определять тип образа чисто по его размеру
а то мало ли может какая софтварь проверяет наличие там 16
хотя запускать дискдокторы, там где высокая вероятность такой проверки, на таком образе никакого смысла и так нет
так же для типа диска по +227 не прослеживается логика в обозначении
$16 (1011 0) - 80-дорожечный двухсторонний,
$17 (1011 1) - 40-дорожечный двухсторонний,
$18 (1100 0) - 80-дорожечный односторонний,
$19 (1100 1) - 40-дорожечный односторонний.
и не есно как логично сгенерировать новые номера для 256 дорожечных
конечно реализовать подобное будет не так просто как хотелось бы
и наверное будет оно только для достаточно расширенных клонов
как вариант для начала думаю запилить набор трдосных вызовов $3D13 который будет загружаться в кеш
у кого какие соображения по этому поводу?
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
Сообщение от zx_
Profi must live!
