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

[NEO SPECTRUMAN]

Конечно 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 который будет загружаться в кеш


у кого какие соображения по этому поводу?

[Advertiser]