Вид для печати
Вопрос по RealCommander2.6FR. При запуске на скорпионе-1024 с виртуальной дискеты (через смук) на экран выводятся в хаотичном порядке белые точки на чёрном фоне и всё так и зависает. При запуске в Unreal с таким же образом ПрофПЗУ и объёмом памяти эти же точки появляются и через пару секунд выводится основной экран программы.
Кто-то с таким сталкивался?
Gutten, какие модули подгружаются при запуске командера? Убери все из автозагрузки, поставь используемую память в 256, а то и в 128 кб.
Имеется в виду поправить настройки самого командера? Но в эмуляторе и на реале поставлены одинаковые настройки скорпиона...
Как показывает практика не все то, что работает на эмуляторе - работает и на реале :(Цитата:
Сообщение от Gutten
У меня такая же фигня бывает. Сразу после загрузки RC что-то какает в экранную область, после чего иногда происходит сброс, и иногда после этого сброса часы в смуке сбрасываются.
Глючит в турбо режиме. В нормале не смог сброс поймать.
Хз что за тема :(
Убрал из автозагрузки HDD_0.1. Стало запускаться. Но если несколько раз переключиться между панелями (туда-сюда-туда), то зависает или сбрасывается.
Кто-нибудь знает, что это за файл?
Виртуальная дискета с мегабайтом памяти работать не будет. ПрофПЗУ понимает только 256К.
Это драйвер HDD через открытые порты TRDOS плюс утилита для подключения и отключения образов дисков на HDD.Цитата:
Сообщение от Gutten
Замещает стандартный драйвер #3D13 при обращении к "виртуальным дискетам" на HDD, подключенному по стандарту SMUC.
Повышает скорость работы с такими дисками на порядок и при этом не конфликтует с расширенной памятью свыше 256 кБ, т.к. не использует функции теневого монитора.
---------- Post added at 12:09 ---------- Previous post was at 12:09 ----------
При работе HDD_0.1 не использует функции ПрофПЗУ, общаясь с HDD напрямую.Цитата:
Сообщение от Blade
А почему тогда с ним зависает? На моём смуке сигналы /DOS и /IODOS для адресации/дешифрации не используются (джамперы не поставлены).
Я ничего не знаю про сигналы в смуке, но у меня всё работает и никаких джамперов на нём нет.Цитата:
Сообщение от Gutten
HDD_0.1 требует прямого доступа к портам SMUC, через установку BIT2 в порту 1FFDh. Может это о чём то скажет?
Если вместо жёсткого диска будет CompactFlash карта через переходник, то HDD_0.1 зависнет при инициализации плагина, на бесконечном опросе готовности к передачи данных. Проблема уже более 4 лет не имеет решения. Исходных текстов не найти, а отлаживать по-живому при открытых портах DOS теневой монитор не умеет.
---------- Post added at 11:43 ---------- Previous post was at 11:40 ----------
Кстати, никаких чёрточек при инициализации HDD_0.1 (запуске Real Commander) не должно быть. Такими чёрточками "страдает" HDDMOUNT. Он же пытается подключиться к HDD_0.1, чтобы использовать его быстрые процедуры чтения и записи.
так поставь BreakPoint на изменение в экранных адресах и смотри что гадит.Цитата:
Сообщение от Gutten
Чёрточки не критичны, они появляются на чёрном экране и исчезают при картинке. А вот то, что зависание происходит при CF это интересно. Я как раз ей и пользуюсь, надо попробовать винт подключить.
Напиши, что получится
Да, с винтом не зависает. Но он сильно шумный, так что останусь на карточках и HDDmout.RCM.
В свое время HDD mounter написан именно из за того что плагин с открытыми портами не работал, даже после того как эти самые порты были сделаны на плате.Цитата:
Сообщение от Gutten
HDD mounter, два драйвера, один по 3d13 другой через rst (вызов на проф пзу работает в 2 раза быстрее), а вот 3 в свое время на открытых портах не хватило сил и мотивации (я делал трюк использовал свой HDD mounter и подгружал плагин с портами для работы драйвера).
Теперь я знаю что HDD mounter пользовались аж 4 человека считая меня.
+1 :)Цитата:
Сообщение от Firestarter
Ну я потихоньку ковыряю HDD_0.1.rcm. Совершенно точно известно в каком месте зависает, но пока непонятно почему.Цитата:
Сообщение от Firestarter
Я было подумал, что CF карты не очень то совместимы со старыми стандартами обмена, под которые писался HDD_0.1. Но написав небольшую программу посекторного чтения убедился, что всё работает так же, как с HDD.
Кстати, с HDD_0.1 и винтом программа по выходу в "HDD плагин" показывает на экране какой-то мусор, включая атрибутный.
Ты делись наблюдениями, одна голова хорошо, а форум - лучше! Глядишь совместными усилиями и разрешим проблемку-то.Цитата:
Сообщение от AmoNik
Не так же. Драйвер Jason.blk для исдос не работает с CF. Там правда сам драйвер не по стандарту работает.Цитата:
Сообщение от AmoNik
У себя такого не наблюдал за всю историю использования этого плагина.Цитата:
Сообщение от Gutten
---------- Post added at 19:46 ---------- Previous post was at 19:15 ----------
Ну ок.Цитата:
Сообщение от Дмитрий
Сейчас есть две проблемы. Первая - заключается в том, что после дизассемблирования плагина с помощью ZX TURBO DISASSEMBLER 1.1 и последующего обратного процесса в ALASM размер кода плагина уменьшается на 4 байта. Непонятно, что и где при этом теряется.
Вторая - трудность отладки по живому, т.к. на реале теневой монитор сразу закрывает порты DOS, а эмулятора с прямым доступом к портам HDD (т.е. работающего с реальным устройством, а не с его образом в виде файла) я пока не встречал.
Как вариант можно попробовать переделать плагин на работу с закрытыми портами и ковырять после этого в теневом мониторе, но тогда надо понять, что такого пропадает из кода, почему плагин становится короче.
Вот фрагмент плагина, на котором происходит зависание (*):
;К этому моменту порты дос уже открыты
ld de,#0000; номер цилиндра
ld hl,#0002; номер головки/сектора
call LC94D; позиционирование (см. ниже**)
ld a,#41; Количество секторов
ld b,#fa; Регистр счётчика секторов
out (c),a; Записали
ld a,#20; Команда чтения
call LC943; Передача команды (см. ниже***)
call LC935; Ожидание завершения выполнения команды (лишний вызов)
ld b,#fb; Регистр номера сектора
LC9FE push bc
in (d),c
push de
ld b,#ff; Регистр состояния
LCA04 in a,(c)
* bit 3,a; Проверка флага DRQ (запрос данных)
jr z,LCA04; Тут образовался бесконечный цикл
ld a,#20
ld hl,#f000
call LC889
call LC935
pop de
pop bc
in a,(c)
sub d
jr nc,LC9FE
.......
**
LC94D ld b,#fe; Регистр накопителя и головки
ld a,#a0; Неиспользуемые разряды
xor h; Номер головки (наверно лучше or h?)
out (c),a
dec b; Регистр цилиндра (старшая часть)
out (c),d; Номер цилиндра
dec b; Регистр цилиндра (младшая часть)
out (c),e; Номер цилиндра
dec b; Регистр номера сектора
out (c),l; Номер сектора
ret
***
LC943 ld b,#ff; Регистр команды
out (c),a
call LC935; Ожидаем завершения выполнения команды
jp LC93D
LC93D in b,#ff; Регистр состояния
in a,(c)
rrca; Флаг ERR
ret
LC935 ld b,#ff; Регистр состояния
LC937 in a,(c)
rlca; Флаг BSY
ret nc
jr LC937; Ждём завершения выполнения команды
---------- Post added at 19:51 ---------- Previous post was at 19:46 ----------
Такого драйвера не встречал. Сам много лет пользуюсь драйвером IDESMUC.BLK от Валерия Кожевникова (тот же Jason). До него использовал поставочный ZHDD4.BLK.Цитата:
Сообщение от Blade
Да, с CF картами IDESMUC подглючивает. Причём пришлось подбирать карту памяти такую, чтобы и нормально размечалась теневым монитором и работала в iS-DOS. Другие карты либо вообще не размечались даже в теневом мониторе, либо напрочь завешивали драйвер в iS-DOS.
Похоже есть какие-то особенности в их работе.
Однако моим тестом никаких особенностей не выявилось. Правда проверял в режиме LBA...
---------- Post added at 20:36 ---------- Previous post was at 19:51 ----------
Исходники IDESMUC.BLK есть в наличии. Знать бы какой стандарт предпочитают CF карты - можно бы было ковырнуть драйвер.
CF тестил такой программой.
В режиме LBA читает влёт и не виснет. Классика.
В старых ATA стандартах было написано, что после окончания операций чтения/записи в регистрах сектора/дорожки/головы содержится номер последнего сектора, с которого производилось чтение/запись. В современном стандарте состояние этих регистров после успешного окончания операции не определено. Та CF карта, которую я смотрел, выдавала те же значения, что и перед началом чтения.Цитата:
Сообщение от AmoNik