kovdry, я бы посоветовал еще обратиться за советом к caro и vinxru. Они на этом собаку съели.
kovdry, я бы посоветовал еще обратиться за советом к caro и vinxru. Они на этом собаку съели.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Все нормально. Просто из вашей схемы убираем RD/WR и всего делов. Согласно эпюры, проц выставляет адреса и в следующем такте анализирует RDY. В следующем такте (ожидающий он или нет) выставляет RD/WR. Таким образом, зацепившись на CS микрухи, вы затормозите процессор. А к анализу его сигналов можно приступить в аккурат после входа АТмеги в прерывание.Сообщение от kovdry
Эх! Так бы сразу и сказал!!!
Но какой же, HardWareMan, по вашему выход из этого положения?
Что, неужели все так безнадежно?
Вы бы дали свои дельные предложения, а то все пугаете своими глитчами.
Я тут вспомнил, что при подключении к Ориону-128 флоппи накопителя по версии "Орионсофта", применялось подобное торможение.
Пошел я читать доку...
А вы не думаете что могут быть проблемы с ПДП ВТ57 и, соответственно, с регенерацией изображения в ВГ75?
Sent from my A7HD using Tapatalk 4
alx32, Взял и мой вопросик умыкнул.
Ну наверное, не только мой, и не только я знаю к чему приводят игры с RDYIN, хотя бы на том же Орионе...
Sent from my A7HD using Tapatalk 4
Проблемы возможны. Да.
Ладно, схема упрощается (смотри внизу).
Пытался понять суть глюков в сообщении HardWareMan, но так ничего и не понял. Сигналы не подписаны.
Но если рассуждать логически, то глюки могут быть связаны с:
1. Провалами сигнала /CS0 или /CS1 в такте Т1 при активности сигнала SYNC.
2. Появлением ложного сигнала /CS0 или /CS1 в такте Т1, если нет обращения к ВВ55.
Оба этих варианта глюков должны исчезать в такте Т2, когда формируется сигнал DBIN, иначе может произойти сбой при обмене с ВВ55, чего на практике не наблюдается.
Как же могут повлиять подобные глюки при работе нашей схемы торможения:
1. Решение о формировании такта Tw процессор принимает в активной фазе Ф2 в такте Т2, даже после активации DBIN, так что влияние такого глюка исключается.
2. Диф. цепочка транслирует сигналы /CS0 или /CS1 на выход. Так что если эти входные сигналы снимаются, то на выходе RDYIN сразу же устанавливается в 1. Задержки вентелей составляют пару десятков наносекунд, так что, думаю, этот глюк нам тоже не страшен.
По поводу схемы КГМД от ОРИОН СОФТ:
Там, действительно, все запутано. Согласно фирменной документации, используется одновибратор на К155АГ3. Я сам делал такую схему в 1992г. Помнится никаких глюков с ней не было. Кстати на новой плате, которую производит zorel, стоит именно эта ИМС.
В более поздней схеме в "Радиолюбителе" №6 1993г. уже стоит К155ТМ2 с каким то непонятным включением. Очевидно авторы изменили схему увеличив ее надежность и ограничив время задержки одним тактом.
Думаю, что ненадежность схемы в Орионе вызвана применением одновибратора. Он мог перезапускаться от помехи и тормозить ВМ80 бесконечно долго. У нас же используется диф. цепочка, которая не имеет элементов памяти, и не чуствительна к помехам.
Теперь насчет ущерба, который может нанести торможение ВМ80 регенерации изображения на экране, организованного циклами ПДП микросхемами ВТ57 и ВГ75.
ВГ75 выдает на экран изображение знакорядами. На отображение знакоряда уходит 10 строк, это 64мкс х 10 = 640мкс. В то время, пока очередной знакоряд отображается, информация о следующем загружается в другой буфер. Это 80 байт ОЗУ. Загружаются они пакетами по 8 байт с перерывом между пересылками 7 тактов ВГ75 (~2.7мкс). Итак время на пересылку 80 байт в циклах ПДП составляет: (цикл ПДП ~1.7мкс х 8 = 13.5мкс) х 10 + (7 тактов ВГ75 ~2.7мкс х 9 = 24мкс) = 160мкс. Сюда еще можно добавить 10% на задержку от ожидания окончания циклов при захвате шин и того мы имеем 176мкс. Что составляет 30% от времени необходимого на отображение знакоряда. После загрузки буфера ВГ75 просто ждет, не формируя циклов ПДП.
Значит у нас есть еще как минимум 470 мкс для задержки ВМ80.
Я собираюсь тормозить ВМ80 на ~7мкс, значит за время отображения знакоряда, я могу затормозить процессор 67 раз. Конечно вы скажете: кроме циклов ПДП и торможения, ВМ80 должен выполнять другую полезную работу (производить вычисления там).
Я предлагаю определить какова максимальная частота обращения ВМ80 к ВВ55, и посмотреть, уложимся ли мы в это количество обращений за наши 640 мкс.
В качастве примера привожу отрывок программы МОНИТОРА РК в котором обращение, на мой взгляд, наиболее интенсивное.
Здесь обращение к ВВ55 происходит раз в 46 тактов ВМ80, что составляет 25мкс. Следовательно, за 640 мкс мы можем обратиться в ВВ55 25 раз. Это не превышает наш лимит в 67 обращений. Естественно, что торможение замедлит процесс вычисления, но , думаю, учитывая отношение количества циклов обращений к ВВ55 к общему числу циклов, не на много. Что же будет, если какой нибудь извращенец напишет программу, которая будет в бесконечном цикле обращаться к ВВ55, так, что ВГ75 не успеет забрать свои 80 байт из видео ОЗУ за свои 640 мкс? Ничего страшного. Изображение не поплывет. Просто знакоряд, который не успел к отображеню не будет выведен. В этом на практике убеждает нас подключение и отключение пошагователя. Если пошагователь "на ходу" включить, то изображение на экране исчезнет (останется только курсор), а если отключить, то изображение восстановится.Код:; Устранение дребезга контактов ; Происходит путем опроса нажатия 32 раза ; Если хотя бы 1 раз не будет подтверждения нажатия, ; то клавиша считается ненажатой scan_bounce: mvi l,32 ; Инициализируем счетчик количества ; опросов scan_boun_loop: lda port_B_kbd ; Читаем состояние клавиш cma ora a ; Если не нажаты, jz not_press ; то выйти dcr l ; модифицировать счетчик опроса jnz scan_boun_loop ; если не последний, то продолжить
По поводу помощи от caro и winxru.
У caro я взял прошивку его знаменитого контроллера на ATMega48. Дизассемблировал его и сейчас внимательно изучаю. У caro нет проблем с задержками отклика, поскольку он взял ATMega48, у которого есть прерывание на изменение уровня на любом выводе порта D. Кроме того он не лезет на шину данных и для него критична только задержка между обращениями к портам А и Б ВВ55, а она составляет несколько мкс.
С winxru, к сожалению не контактировал, и не знаю как к нему обратится, если не через личку, поскольку вижу, что мужик не лазит по форуму с апреля этого года.
Он вроде как переехал сюда.
kovdry, Я советовал к ним обратиться по следующей причине. Наверняка изначально, при задумке контроллера рассматривался вариант с микроконтроллером без ВВ55. И по какой причине этот вариант не реализован?
С vinxru можно пообщаться на форуме nedopc.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
