TR-DOS Navigator (TRDN)

[Grand]

Хм... а в коде вот это:

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

[Advertiser]

[Evgeny Muchkin]

а это не драйвер 48/128

А да, похоже на то.

[Grand]

Ну не запускается из TRDN файл, который я дал.

Я пока не разобрался с этим.

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

а это не драйвер 48/128 ? (ну то есть для скорпа он загружаться/исполняться не должен)

Это просто проверка на 128К. В TRDOS-версии она работает в загрузчике, еще до загрузки. TRDN.

[Grand]

Во втором - только на Скорпионе, но драйвер уже загружен

Однако, я не прав. Драйвер загружается после установки 23388. И TRDN при работе в 23388 ничего не пишет.

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

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

Это происходит потому-что объем всех файлов в секторах превышает объем стандартного диска, из которого он вычитается. (Кому интересно, смотрите процедуру "SECTOR9_" в тексте исходников). Объем нестандартного дмска неизвестен и правильно расчитать количество свободных секторов не представляется возможным.
Однако, возможно сделать поддержку дисков, отформатированных в прогрвмме DCU Н.Родионова, - там объем диска в секторах записывается в служебном секторе в ячейках +#DF, +#E0.
Во вложении тестовая версия X4.1, в которую я попробовал вставить поддержку дисков DCU. Проверяйте, но без важный данных на диске.

Справедливости ради следует заметить, что попытка сделать поддержку дисков DCU предпринималась до меня в версии TR-DOS Navigator'а V0.67b, но поддерживались только диски от 80 дорожек двухсторонние, и та процедура содержала ошибки. Когда я процедуру переписывал в 2006 году, то упростил до работы со стандартными дисками, но зато всех возможных в TR-DOS стандартных форматов.

[Evgeny Muchkin]

Grand, не представляется возможным? А как же данные из Е5,Е6 в служебном секторе?

[Grand]

А как же данные из Е5,Е6 в служебном секторе?

Количество cвободных секторов?
Оно учитываются до начала операции только, чтобы определить есть ли свободное место. Когда на диск
добавились/удалились файлы, это значение, как и остальные в сл. секторе, уже не актуально.


Попроюовал ли кто нибудь мою последнюю тестовую версию в работес дисками от DCU?

А можно сделать, чтобы имена SMUC дисков нормально отображались, а не как
файлы - с пробелом после 8-го символа?

Оболочка TRDN отображает имена элементов в виде 8+3 - имя и тип в своем столбце. Когда элемент замаркирован, между именем и типом рисуется символ с кодом #FB. Конечно, сейчас имена прсевдодисков не маркируются, но в будущем - может быть.
Мне кажется вполне логичным, что дополнительные три символа к имени диска воспринимаются как
расширение.
В GB оболочка другая.

[Evgeny Muchkin]

Попроюовал ли кто нибудь мою последнюю тестовую версию в работес дисками от DCU?

Да. Глюков не было. Записал диск под завязку, удалял файлы, добавлял, делал Move. Нормально.


Набросал драйвер для всех 2Мб GMX. Идея почти такая-же, как и в предыдущий раз - чтобы, и память юзалась вся доступная, и часы отображались в любой конфигурации GMX. Т.е. в режиме Скорпа видны 2Мб, а в режиме Пентагона и Композита - 128К.
Для работы часов порты SMUC открывать не обязательно, их чтение сделал через TR-DOS. Ну и прошивку теневика GMX не забываем обновить до G5.01, чтобы при чтении с винта через #3D13 не висло, если кто не в курсе.
Драйвер сделан из драйвера от Grand (спасибо! ) . 8 и 15 страницы не используются.

В аттаче скомпиленный драйвер и текстовый исходник.

gmxdrv.zip (перекачайте, кто скачивал ранее, ошибочка вкралась, на работу не влияет, но для порядку... )

Текст:

Скрытый текст

        ORG #5B00,#6B00

        JR MEM
        JR CLOCK

        DB 0,0

MEM     CP #02
        JR C,$+3
        INC A
        CP #05
        JR C,$+3
        INC A
        PUSH HL
        LD L,A
        LD H,#08
        LD A,(#08)
        CP #C3
        LD A,L
        JR NZ,ZX128_1
        CP H
        LD HL,#F507;    RLCA: PUSH AF
        LD (ZX128_2),HL
        LD H,#80
        JR C,$+3
        INC A
        CP #0F
        JR C,$+3
        INC A

ZX128_1 CP H
        POP HL
        CCF
        RET C
        PUSH BC
        LD BC,#7FFD
        PUSH AF
        AND #07
        OR #10
        OUT (C),A
        POP AF
ZX128_2 POP BC;   RLCA: PUSH AF
        RET
        AND #10
        LD B,#1F
        OUT (C),A
        POP AF
        RLCA
        RLCA
        RLCA
        AND #07
        LD B,#DF
        OUT (C),A
        POP BC
        RET

        DS #5B5D-$,#00

CLOCK   LD BC,#DFBA
        LD A,#04
        CALL OUTIN
        LD E,H
        LD A,#02
        CALL OUTIN
        LD D,H
        SUB A
        CALL OUTIN
        LD C,H
        LD B,D
        RET

OUTIN   CALL OUTDOS
        LD A,#D8
        PUSH BC
        LD C,#1F
        CALL OUTDOS
        POP BC
        LD HL,#3EF3
        JR JMPDOS

OUTDOS  LD HL,#2A53
JMPDOS  PUSH HL
        JP #3D2F

[свернуть]

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

Количество cвободных секторов?
Оно учитываются до начала операции только, чтобы определить есть ли свободное место. Когда на диск
добавились/удалились файлы, это значение, как и остальные в сл. секторе, уже не актуально.

Я что-то все равно не врублюсь Почему не актуально? Разве после записи файлов на диск эти значения не меняются?
Я всегда считал, что меняются, по крайней мере должны. Таким образом, чтобы узнать общий объем диска (хоть стандартного, хоть dcu'шного) достаточно сложить длины всех файлов с тем, что лежит в E5,E6 в 9-м секторе.
И DF,E0 трогать нет необходимости, т.к. нельзя исключать, что какой-нибудь 'социально ответственный' коммандер при копировании может затереть эти значения в соответствии со своими представлении о правильности формата диска.

[Grand]

чтобы узнать общий объем диска (хоть стандартного, хоть dcu'шного) достаточно сложить длины всех файлов с тем, что лежит в E5,E6 в 9-м секторе.

Но при этом точно также приходится уповать на то, что значение в #E5 истинно.
Для TRDN такая переделка на практике обернется тем, что придется грубо вмешиваться в процедуру копирования/дефрагментации, а мне этого делать по многим причинам не хочется.

[Evgeny Muchkin]

Grand, а почему оно неистинно должно быть? Есть хоть один копир, который не знает, что там должно лежать кол-во свободных секторов? И к DF E0 куда меньше доверия... про них то точно мало кто знает.

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

А если места мало для такой считалки дискового объема, уберите 'проверку на corruptnostь' каталога. Бесит жутко (почти как в STORM), половину trd'шников со снятой защитой не запустить из TRDN, т.к. они не отображаются.

[Grand]

Я тут поймал себя на мысли,что последние несколько лет мы только и делаем,что защищаем TRDN от 'нестандартых стандартов'. Твк уже есть:

• защита от диска формата IS-DOS (только для Скорпиона)
• защита от нулевого размера в элементе каталога

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

Может всем лучше пользоваться стандартным дисками???