Поиск файла и обработка ошибок в TR-DOS

[AndTorp]

Столкнулся с такой проблемкой:

        ;<...>
         LD   A,9
         LD   (#5D06),A
         LD   C,#0A
         CALL DOS
        ;<...>
         RET

DOS     ;<...>
         LD    HL,0
         LD    (#5D0F),HL
        ;<...>
         CALL #3D13
        ;<...>
         LD    A,(#5D0F)
         OR    A
         RET   Z
        ;Далее обработка ошибки

Так вот, ошибка выскакивает всегда - есть/нет файл, есть/нет диск.
Просмотр значения переменной #5D0F показал, что после выполнения функции "Поиска элемента каталога #0A" в эту переменную копируется значение регистра С (а там или номер первого совпадающего элемента каталога или #FF).
Это как-то можно обойти?

[Advertiser]

[Wlodek]

Лучше всего перед _каждым_ вызовом TR DOS обнулять системные переменные ошибок как в TR DOS, так и в основной системе. Я традиционно использую такую конструкцию (она входит во все мои программы, работающие с TR DOS):

TRDOS DI
LD (IY+0),#FF
PUSH HL
LD HL,0
LD (23823),HL
POP HL
CALL #3D13
[ DI,EI ]
RET

Как обычно, на входе в C код операции, в парах, если надо, параметры.
Просто вместо вызова сразу CALL #3D13 вызываете CALL TRDOS.

[AndTorp]

Wlodek, ну я, примерно, это и делаю. Кроме (LD (IY+0),#FF).
Проблема в том, что функция "Поиск элемента каталога #0A" не только возвращает значение (номер первого совпавшего файла или при отсутствии #FF) в регистре C, но и дублирует это значение в переменной #5D0F (код ошибки TR-DOS). Зачем такой дубляж непонятно, может глюк TR-DOS.

[Wlodek]

Ну, я под TR DOS пишу с 1993 года (как появился Pentagon 128), и всё, абсолютно всё работает . Так что я типо знаю, чтО советую .

[AndTorp]

Ну, я под TR DOS пишу с 1993 года (как появился Pentagon 128), и всё, абсолютно всё работает . Так что я типо знаю, чтО советую .

Wlodek, я совершенно не собирался (и не собираюсь) преуменьшать Ваши знания и навыки работы с TR-DOS. Просто столкнулся с проблемой, что функция #0A возвращает значение не только в регистре C, но и, почему-то, в переменной #5D0F.

Вот, если потрассировать данную программку в отладчике, то перед RET будет C=A=(#5D0F).

	ORG  	25000
	
	LD	HL,FILE
	LD	C,#13
	CALL	#3D13

	LD	A,9
	LD	(#5D06),A
	LD	HL,0
	LD	(#5D0F),HL
	LD	C,#0A
	CALL	#3D13
	
	LD	A,(#5D0F)
	RET

FILE	DB	"FILENAMET"

Из-за этого получается непонятная ситуация. Например, при значении C=(#5D0F)=6 непонятно - или на дискете присутствует файл (имя.тип которого заданы в дескрипторе) и его номер 6, или в дисководе нет дискеты. Вопрос - как это можно обойти? Пока придумал только считывать всю область каталога в память и уже там искать нужный файл своей процедурой.