Каталог зогружается как ни в чем не бывало. А вот дальше дисковод не работает, как будто из него вытащили интерфейсный кабель.

Не пробовал еще; многие байты попробовал, а этот - нет. Сегодня попробую.

Ага, ну это после того как процедура выключения дисковода первый раз отработает, сразу после загрузки каталога, так всё и вырубается начисто.

Добавлено через 10 минут
По-моему её вообще удалить надо, от греха подальше.

Попробовал. Всё стало работать нормально. Таким образом, верно: "процедура останова дисковода" глушит его намертво. :-O

Я уже не против. :)

Есть шанс её оставить.
Я тут посмотрел исходники. Ваша процедура останова дисковода использует байт из ячейки 23830. Там по идее хранится копия системного регистра. Так вот, загрузчик коммандера затирает часть байта этой ячейки (делается команда: LD A,(23830): AND 3: LD (23830),A). Так что наверное здесь причина. Мой загрузчик оказался несовместимым с Вашей процедурой останова дисковода. :)

Изменил загрузчик. Теперь он не меняет ячейку 23830, используемую процедурой выключения дисковода. Версию 0.5 выложил в первый пост этой ветки.

Добавлено через 52 минуты
Еще вопрос появился по Вашей процедуре останова дисковода.
Код такой (я немного ужал по объему):

Мне не понятно, зачем использовать ячейку 23830. Например, у меня в коммандере она не меняется при смене дисковода (она вообще коммандером не меняется). Может это какие-то левые глюки за собой повлечь может?
И особенно мне не ясна команда XOR 1. Выполняет роль переключения дисковода с текущего на другой, потом обратно. В моём случае ячейка не будет указывать на текущий дисковод (в общем случае), поэтому иногда это будет работать, возможно, не так как задумывалось. Могут ли в связи с этим быть какие-то глюки?

Да, это и явилась причиной. Но в собственной программе можно использовать и собственную ячейку, где хранится копия системного регистра.
А системные переменные (системы Спектрум-BASIC и TR-DOS) портить всё же нежелательно: командер ведь предназначен ещё и для запуска других программ, которые должны будут работать в системе.

Отвечу подробно в следующем своём посте.

Попробую подробно рассказать о методе снятия выбора дисковода эмуляцией индексных импульсов.

Как известно, микроконтроллер КР1818ВГ93 (и его "западные оригиналы"), завершив выполнение команды, снимает выбор дисковода после поступления определённого количества индексных импульсов. Однако, если дискеты нет, то и индексных импульсов не будет. Авторы Beta Disk Interface не стали добавлять аппаратное снятие выбора (очевидно, ради удешевления схемы), но предусмотрели программную эмуляцию индексных импульсов. Это делается с помощью переключения 3-го бита системного регистра. Про эту возможность написано не во всяком описании по программированию контроллера; обычно сказано, что этот бит отвечает за "загрузку головки". Если мы посмотрим на схему любого нашего клона Beta Disk Interface, то увидим, что соответствующий выход триггера (обычно TM9 или TM8), отвечающий за 3-й бит системного регистра, соединён еще и через диод или логический элемент И с 35-м выводом ВГ93; это и призвано обеспечить программную эмуляцию индексных импульсов.
Однако, мало сэмулировать индексные импульсы, надо еще и переключиться на "противоположный" дисковод. В ПЗУ TR-DOS V5.03, процедура снятия выбора дисковода находится с адреса 727. Однако там есть ошибка: по адресу 730 вместо команды OR 3 должно быть XOR 3; из-за этой ошибки не остановится дисковод B: в интерфейсе, где аппаратно реализовано два дисковода, или дисковод D:, - где реализовано четыре дисковода.

В процедуре, модифицированной мной:команда XOR 1 в строке 5 гарантированно переключает дисковод на "противоположный", и это обеспечивает снятие выбора. "Упрощение" этого алгоритма я не рекомендую: возможно он перестанет выполнять свою функцию для каких-то типов дисководов. Но сейчас в TFC версии 5 останов [мойх] дисководов работает наконец-то нормально. :)

По поводу использования ячейки "копия системного регистра": адрес для этой самой копии системного регистра, конечно же, может быть и другим. Но значение должно быть действительно копией, поскольку оно отправляется непосредственно в порт #FF подпрограммой ПЗУ TR-DOS по адресу 697. После того, как отработает
предложенная мной процедура, в порте #FF окажется точно такое же значение, как и до её вызова (только дисковод будет остановлен).


P.S. Извиняюсь за десятичные адреса - я изучал TR-DOS по книге П.Федина "Полное описание и полный дизассемблер TR-DOS", а там все адреса десятичные. :)

Ясно. Значит там еще поменять надо кое-что.

Я обнаружил пару глюков в докторе. Будет время - исправлю и выложу.

Исправил процедуру снятия выбора дисковода, убрал глюки в докторе (один опасный глючок был). Выложил версию 0.6 в первый пост ветки.

Я тут на некоторое время исчезал... :)

Повнимательнее протестировал дисковые операции, и вот что могу сообщить.
В режиме TURBO дисковые операции не работают - выдаётся NO DISK; всё можно делать только в обычнном режиме.
Запись на 3,5"-дисковод по-видимому происходит нормально, а вот при записи на 5,25"-дисковод иногда происходять ошибки: первый сектор на некоторых дорожках перестаёт читаться.
В общем-то, такая картина для меня не нова: еще в конце 1990-х годов, когда стали появляться первые командеры с "turbosaver'ами", я получал аналогичные результаты. Еще тогда у меня сложилось мнение, что "turboloader'ы" вероятно могут иметь практическое применение, а вот "turbosaver'ы" - никогда. У меня установлен индикатор записи на дисковод, так вот: скорость записи на 5,25" такая, что даже во время перехода с дорожки на дорожку, он гаснуть не успевает. Надо разобраться с таймингом процедур записи, и сделать величины задержек такие как в ПЗУ TR-DOS.
Одним словом, я солидарен с теми, кто предлагает использовать только точку входа 15635: там такие проблемы никогда не возникают.

- Увеличил время проверки наличия диска. Теоретически должно работать на 11 МГц.

- Поставил задержку после команды "шаг вперед". 5 halt'ов. Получается в районе 0.1 сек, что по моим расчетам составляет 50% длины трека и должно привести к пропуску одного оборота диска.

Всё заработало. Пробовал операцию Track copy как с дисковода 3,5" на 5,25", так и наоборот (в т.ч. и в TURBO-режиме). Ошибок не обнаружено (использовалась моя собственная программа верификации дисков, написанная много лет назад специально для таких случаев :)).
Что ж, можно с уверенностью сказать, получилась неплохая утилита. У меня пока пожеланий больше нет. Возможно, в эксплуатации, обнарущатся какие-нибудь ошибки, - тогда вновь обсудим их в данной теме. :)

Я извиняюсь, что поздно пишу, хочу несколько комментариев написать по этой ветке:

1. Дайте, пожалуйста, ветке осмысленное название. Коммандеров на спектруме немеряно, так назовите эту ветку именем своего коммандера.
2. Чтобы правильно выводить счетчик процентов во вьювере, вам надо считать не байты, а строки. Тогда у вас будет очень плавное изменение счетчика при скролле по строкам. При достижении конца файла, очень неплохо выставлять 100% принудательно.
3. Сделайте работу как через #3d13, так и через #3d2f. Отлавливать ошибки (пресловутый disk error) при работе через #3d13 не сложно, в какой-то газете я видел хорошее описание от RealSoft'а. Вроде это был Impulse.
4. Книжка Федина переведенная на шестнадцатеричную систему у меня есть (как-то сам попереводил все). Я хотел ее выложить, даже выходил на самого Федина с вопросом не желает ли он пофиксить мелкие найденные ошибки перед тем как я выложу эту книжку, но тот отказался.
5. Известных универсальных драйверов памяти есть как минимум 2. Один из них вы без проблем можете найти в комплекте Real Commander'а (исходник в zasm'е).
6. Модули - это плохая идея. Я не раз высказывался на эту тему, в том числе и на этом форуме. Не повторяйте чужие ошибки. :)
7. В 48К можно всунуть очень и очень много. Также, легко можно сделать версию которая будет запускаться из теневого ОЗУ и ПЗУ, для этого надо чтобы весь коммандер влазил в 16Кб, помните это.

Обычно количество строк заранее неизвестно; его можно узнать, произведя предварительное форматирование текста. "К счастью", длина файла в TR-DOS ограничена 255-ю секторами, но в 48K длинный файл "перелопачивать" придется долго.
В TR-DOS Navigator'е ничего этого не делается. Текст разбивается на строки в процессе вывода, какими бы длинными они не были (хоть весь текст одна строка!). Считаются именно байты, и результат не плохой. Вот какая "процентная" формула там используется:
процентная_величина_прокрученного_текста=адрес_в_тексте_на_котором_остановился_вывод/(длина_текста_в_байтах/100)

На ассемблере это выглядит так:Счетчик показывает величину прокрученного текста, и принудительное значение "100%" никогда не выставляется.

Можно было бы пофиксить эти ошибки самому, и опубликовать только эту информацию.

Если модули организованы как в Real Commander'е, то идея действительно плохая. А вот если сделать динамическую подгрузку оверлеев в зависимости от выполняемой функции, то идея хорошая. Недостаток - нужно держать в дисководе "системный" диск, но и он обходится, если оверлейный файл будет на RAM-диске (в 128K).

Я собственно нигде и не спорю, что считать по байтам можно, тем более что это самый простой способ. ;) Я просто утверждал, что единственный способ добиться плавности изменения счетчика - это считать именно строки, потому что скроллинг осуществляется именно по строкам (а не по байтам). Разбивка строк, разные разделители строк, скорость подсчета и прочее - все это решаемо. Например, посмотрите QC 3.11...

Я обычно использую собственную процедуру деления для этого расчета:

Если кому нужно та дока - напишите мне и я ее вышлю. Просто в таком (необработанном) виде не хочется выкладывать на всеобщее обозрение.

Проблема модулей (оверлеев, плагинов) на спектруме (не только касательно коммандеров) в том, что их пишет только автор программы и все. В том-же RC была изумительно документированная система работы с модулями, куча примеров, поддержка автора и тем не менее количество написанных модулей (сторонними авторами) совсем не впечатляет (несколько штук). За время, пока Pawel писал все эти доки, он возможно сам бы написал эти несколько модулей. :v2_clapp:

В действительности описанный мной способ выбран вот почему.
В первых версиях TRDN в просмотрщике текстов была сделана интересная возможность: "на ходу" переключаться в режим дампа и обратно. Мне захотелось это сохранить, а для этого значения в памяти должны оставаться неизменными, иначе при переключении надо будет всё перезагружать и переформатировать. Перед написанием своего просмотрщика я изучал аналоги, в том числе и QC 3.10 (3.11 тогда еще не было). Идеи в QC мне понравились, но захотелось опробовать своё, и чтобы это работало и в 48K. Думаю, всё получилось. :)


Там ситуация, если мне не изменяет память, была другой. Эта дока распространялась за деньги. (Может быть потом она стала открытой, но мне попалась версия RC, где было про это написано именно так. Описание про модули RC я не видел и поныне.) Как знать, прочитай я эту доку в те годы, может быть я сейчас занимался бы RC-модулями, а не TRDN? :) Но TRDN я теперь не брошу! :)

Неправда, документация по разработке модулей была вместе с самой первой версией (2.0). Причём документация была сразу вполне вменяемая, на её написание было потрачено очень много времени. А что касается денег, то было предложение купить полную версию командера включаюшего два дополнительных модуля, а уже через несколько версий они были включены в скачиваемый дистриб.

люди добрые, доработайте пожалуйста модуль RC - pt3play+.rcm, чтобы он мог играть vortex tracker файлы и, самое главное, turbo sound! спасите реальщиков! :)

в RC мне не хватает только этого.

Так ведь vortex tracker вроде как играется (использован универсальный плеер от Sergey Bulba). В комплекте RC есть достаточно подробно закомментированные исходники PT3Play, так что сделать на их основе плеер других форматов проблемы составить не должно.

вортекс плеер только одночиповый играется, традиционный AY, так сказать. Турбо не играет.

Когда-то на Народ.ру была выложена эта книга. У кого-нибудь осталась или мне сканировать?

alone, я с полгода назад эту книгу скачивал с оффсайта сайта scorpion в MS WORD, так что думаю нет необходимости ее сканировать.

---------- Post added at 21:52 ---------- Previous post was at 21:42 ----------

эх... давно это было... помнится, когда я пропатчил RC1.8 до RC1.81+, Павлу предлагал сделать двухпанельный командер, но получил решительный отпор, мол: "зачем две панели? У спектрума нет винтов и кучи каталогов, как на ПЦ, где это оправдано :)"... Но от судьбы не уйдешь!

---------- Post added at 21:52 ---------- Previous post was at 21:52 ----------

эх... давно это было... помнится, когда я пропатчил RC1.8 до RC1.81+, Павлу предлагал сделать двухпанельный командер, но получил решительный отпор, мол: "зачем две панели? У спектрума нет винтов и кучи каталогов, как на ПЦ, где это оправдано :)"... Но от судьбы не уйдешь!