CD...
ZXNet эхоконференция «real.speccy»
Сегодня подключал 8-скоростной сидюк (Mitsumi) через SMUC как Slave. Если кто
помнит, то раньше я сюда писал о 16-скоростном Hitachi:-)
Глючит этот сидюк не меньше, но все-таки работает. Hа сей раз мне удалось
немного поближе подойти к сути проблемы, теперь, собственно, все попорядку:
CDPlayer. Тут все довольно печально: работать в нем нормально почти
невозможно, так как нельзя нормально переключать треки:-( Операции же типа
"Выдвинуть трей", "Остановить проигрывание" итп. работают без сбоев:) При
дальнейшем раскапывании выяснилось, что операция запуска проигрывания тоже
работает нормально - здесь проблема кроется в другом: когда мы тыкаемся в
"Выбрать трек" считывается таблица треков, находящихся на диске (как я понял,
она содержит номера песен и их смещение и заканчивается байтом #AA).
Выкачивается из сидюка она словами (которые по 16 бит:)). Сначала берется
младший байт, потом старший и так по кругу. Так вот мой сидюк, как я понял, не
успевает предоставлять очередное слово, а задержек ожидания готовности в
программе нет, то есть CDPlayer не проверяет: готов ли CD-ROM отправить
следующее слово компу. Hапример: имеем последовательность:
... 03 00 4С 1B ...
читая, получаем: ... 03 00 03 00 4С 1B ...
или нечто подобное.
Если же сделать искусственные задержки при чтении этой таблицы (например,
трассируя ее в теневике командой slow#84;)), то таблица считывается нормально,
правда долго;)) Видимо, если сидюк будет более быстрым, то таких проблем не
возникнет. Даже когда я подключал 16-скоростной сидюк, помогало отключение
Turbo, на этом сидюке не помагает;(
2Vlad Sotnikov: Может быть здесь лучше проверять сигнал Busy, как и при работе
с винтом, но только для каждого байта, или для сидюка это невозможно?
CD-WALK. Здесь все так же, как и с прошлым сидюком: устройство не
определяется, однако если пропустить проверку, то все работает на ура. Причем в
режиме трассировки проверка проходит:-\ Видимо, проблема здесь все в том же:
сидюк не успевает за компом.
Проверка проходит, даже если не трассировать ее этапы (точнее вложенные
подпрограммы в подпрограмме проверки). Возможно там бы хватило простых
задержек...
Очень надеюсь, что данная информация поможет авторам в работе над
программой:-)
Желаю удачи !
С уважением Fyodor Odegov aka FION.
31 Окт 01 18:18, Fyodor Odegov -> All:
FO> Выкачивается из сидюка она словами (которые по 16 бит:)). Сначала
FO> берется младший байт, потом старший и так по кругу. Так вот мой сидюк, как
FO> я понял, не успевает предоставлять очередное слово, а задержек ожидания
FO> готовности в программе нет, то есть CDPlayer не проверяет: готов ли CD-ROM
FO> отправить следующее слово компу. Hапример: имеем последовательность:
FO> ... 03 00 4С 1B ...
FO> читая, получаем: ... 03 00 03 00 4С 1B ...
FO> или нечто подобное.
FO> Если же сделать искусственные задержки при чтении этой таблицы (например,
FO> трассируя ее в теневике командой slow#84;)), то таблица считывается
FO> нормально, правда долго;)) Видимо, если сидюк будет более быстрым, то таких
FO> проблем не возникнет. Даже когда я подключал 16-скоростной сидюк, помогало
FO> отключение Turbo, на этом сидюке не помагает;( 2Vlad Sotnikov: Может быть
FO> здесь лучше проверять сигнал Busy, как и при работе с винтом, но только для
FO> каждого байта, или для сидюка это невозможно?
BSY не для этого предназначен. Если уж синхриться, то только по DRQ.
В каждом сидюке (и винте тоже) есть буфер, минимум на 1 сектор, обычно что-то
в районе 16-128 кил. Сектора сначала читаются в него и только после этого
передаются компу. Синхриться надо только между секторами, сами же сектора хоть
по INIR засасывать можно. Есть еще блочный режим, там можно блоками до 64 КБ за
раз таскать без всяких задержек и синхронизаций.
Странно это. Может в железе что-то криво? Сигналы звенят?
WBR, Jason.