Поиск файла и обработка ошибок в 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).
Это как-то можно обойти?

[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, или в дисководе нет дискеты. Вопрос - как это можно обойти? Пока придумал только считывать всю область каталога в память и уже там искать нужный файл своей процедурой.