безвейтовый контроллер AT-клавы на МК
 

плз, обьясните, почему если контроллер AT-клавы с программной эмуляцией матрицы в МК, то обязательно надо вейтить Z80?
неужто, если опрашивать клаву в бесконечном цикле, уходить в INT по /RD+/IORQ+A0=0 и тут же отдавать Z80 готовые данные, МК не успеет? :o

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

а если держать в памяти МК (заполняя по мере нажатия клавиш) 256-байтную таблицу с текущим состоянием клавы для всех возможных сочетаний линий a8-a15 (т.е обьединять полуряды по ИЛИ заранее) и в прерывании просто брать оттуда готовое значение?

Всеравно нужно время на обработку прерывания контроллеру и выборку нужного значения.

Можно сделать безвайтовый контроллер без особых ухищрений, если между МК и спеком поставить маааленьку м/с памяти на 256 байт - мк будет обновлять данные в ней, спек - читать (с большим приоритетом).
Однако изза незначительной длительности Wait-а в схеме "без-вайта" вся канитель с доп памятью смысла не имеет.
(По моим приблизительным подсчетам, если делать с табличкой в памяти МК то можно добиться значения wait-а в 2-3 спековских такта при частоте МК 8 мгц (AVR)).

А зачем 256 байт? Мне хватило 5 байтов (40 битов, 40 кнопок Спектрума). А еще я не стал ставить микросхему памяти, а поставил ПЛИС, куда была запихнута и вся мелкая логика. Данные в ПЛИС периодически закачивает контроллер КР1878ВЕ1, на котором реализован ps2 интерфейс и сопутствующая перекодировка скан-кодов.


Допустим, контроллер работает на частоте 10 МГц. Период тактовой частоты составляет 100 нс. Современные контроллеры, как правило, с гарвардской архитектурой и выполняют лобую команду за 2 периода тактовой частоты, т.е. в нашем случае за 200 нс. А сколько команд нужно выполнить, просто чтобы зафиксировать факт обращения процессора к порту FEh? Десяток точно наберется. Отсюда и необходимость тормозить процессор на время, необходимое контроллеру, чтобы прочитать состояние шины адреса, вычислить необходимое значение в соответствии с принятыми скан-кодами и выдать его на шину данных. Поэтому безвайтный контроллер просто так не сделать, надо извращаться.

256 байт - как раз чтобы не заниматься каждый раз высчитыванием ответа спектруму - чтобы убыстрить отклик МК на чтение порта FE.
Хотя с ПЛИС такой проблемы явно нету ;-) - она сама всё что нужно насчитает.
В целом вывод ни в коей мере не оспариваю - от вайта в схеме без ПЛИС/внешней памяти сложно избавиться Лишь несколько корректировок.
AVR (ATmega) выполняет команду за такт. Вход в прерывание - 4 такта. 1 такт - чтение старшего байта адреса с порта МК. еще 2 такта - чтение байта клавиатуры из памяти (это в лучшем случае - если таблица в 256 байт готова). 1 такт - на вывод байта наружу. Итого - 8 тактов. т.е. 800 нс.
На нетурбированном спеке за это время истечет 3 такта (286 нс) - т.е. может быть можно успеть за время I/O операции Z80 (как раз 3 такта) (если я нигде не обсчитался. На турбированном - точно не успеть.

А, вот зачем.

ПЛИС у меня ничего не считает, там жесткая логика (мультиплексор + 5 штук 8-разрядных регистров, в которые микроконтроллер периодически закачивает уже сформированную матрицу клавиатуры: 5x8=40 бит, по 1 биту на каждую кнопку).

Не люблю avr :v2_crazy:

ангстрем маздай.
у атмела есть mcu+fpga в одном чипе (не знаю, может уже и cpld осилили)

Если внимательно посмотрите, значение каждого байта этого ОЗУ надо предварительно рассчитать
в зависимости от нажатых клавиш, так что никакого выигрыша в быстродействии такой подход не дает.
Как раз жесткая логика, реализованная на CPLD дает выигрыш, поскольку операция ИЛИ в матрице
клавиатуры реализуется аппаратно.
Что касается применяемого микроконтроллера, то на вкус и цвет товарищей нет.
Лично я делаю на том, что наиболее приемлемо в разрабатываемой кострукции, по разным критериям -
цена, быстродействие, подходящий тип корпуса, наличие хороших средств разработки и отладки и т.д.

Да там делов ... Может уже и писали -
контроллер+внешнее озу... все.
Но в стиле ретро нужно контроллер заменять
на несколько логических мс ...

Несколько десятков мс :v2_wink:

и клубок МГТФа :v2_thumb:

Ну маздай и ради бога, давай теперь всю выжившую отечественную электронику нах развалим. Пойдем по пути гайдара - 'мы все это купим'. А через 30 лет станем американской колонией и будем нахаляву качать нефть для дядюшки сэма.

в быстродействии не дает в целом, но ведь позволяет сразу отдать на ШД 5 бит (по крайней мере в варианте с ОЗУ сразу). вот только успеет ли МК это ОЗУ заполнять достаточно оперативно.. :v2_conf2:

Так она никогда отечественной то не была, как сдирали всякое западное старье так и щас сдирают (отставание всегда было лет на 10). Интел во всю испльзовал ПЛМ (с середины 80х) (PLA и PAL) а у нас использовали РЕ3 и РТ4, а ПЛМ появились только в начале 90х (когда на западе про них все уже забыли, там к этому времени появились CPLD и FPGA).

Сейчас наметилась тенденция к разработке чисто "своих" компонентов. См. продукцию НТЦ "Модуль", НПЦ "Элвис", тот же самый "Ангстрем". Процесс сдирания тоже идет, но в меньшей степени. В микропроцессорных делах мы сильно отстали (более, чем на 10 лет), т.к. кибернетика в свое время считалась лженаукой и не развивалась. Теперь будет очень тяжело все наверстать, но первые шаги сделаны.

Ну, читаем с сайта тогоже ГУП НПЦ "ЭЛВИС":
процессорные RISC - ядра с архитектурой MIPS32, выполняющие функции центрального контроллера системы CPU (Central Processing Unit); - это что свое изобретение? Да, DSP у них какойто самопал, но сделать его никакой проблемы щас нет, т.к. полно средств разработки типа VHDL/VERILOG в которых даже студент может сделать и отладить процессор.

А тотже "Ангстрем" научился передирать большие альтеры в БМК. Вот на базе этого и делается (по дико устаремшей технологии 250нм) отечественные процессоры.

Такие продукты подходят разве что для военных, для которых важно чтобы продукт был без "закладок", а цена их не волнует. Но обычного пользователя волнует соотношение цена/производительность, и он такой продукт никогда не купит.

Это все равно как если бы был выбор: за одни и теже деньги купить мерседес или запорожец. Естественно, что большинство бы выбрало мерседес.

PS: правда все это не имеет отношения к теме топика, эти пост надо перенести во флейм. (Рома (CHRV), перенеси пожалуйста).

Чтобы отладить до конца, надо изготовить кристалл и на его базе разработать несколько реальных изделий. Студенту это не под силу хотя бы потому, что изготовить кристалл - недешевое удовольствие.

Дело в том, что рассчитывать новую матрицу нужно относительно редко - лишь при нажатиях человека на PC клаву - а это несколько раз в секунду, не чаще. Пересчет таблицы на Z80 у меня занимает около 4500 тактов т.е. около 1.3 миллисек. при 3.5 МГц (значит можно пересчитывать до 750 раз в сек). Думаю, что на МК получится не дольше, а с учетом более высокой тактовой частоты - вообще быстро.

Зато мы получаем почти мгновенный (максимум 3 такта вейта в турбо режиме, 0 в обычном) отклик на спектрумовский IN (#XXFE).

Добавлено через 7 минут
Ну там же должна быть логика объединения данных по AND из этих самых регистров на случай чтения спектрумом из порта, например, #00FE. Именно это я и называю "ПЛИС считает". (Причем это такая нехилая логика, на дискретах ее делать громоздко.).
Хотя можно конечно сделать и без обсчета - простым методом "AND на диодах". Но нужно 40 диодов.

Жесть! :v2_smile:

Откуда появился /WAIT в Турбо-режиме, если надо просто прочитать байт из заданной ячейки ОЗУ?

Мы тебе про CPLD, а ты нам про диоды :)
Обсуждать эту тему стало не интересно :)

Ну я ж приводил расчеты - вроде как быстрее чем за 8 своих тактов МК ATmega ответить не успеет, даже если просто читает данные из памяти. Если частота МК 8 мгц, а Z80 - 7Мгц, то это не укладывается в отведенные 3 Z80-такта на ответ.

А про диоды,CPLD и специальное внешнее ОЗУ это все не то - нужны дополнительные (к МК) элементы. Считаю что без них стоит попытаться обойтись при создании "безваитового контроллера".

ИМХО, выходит что на МК (без внешней обвязки всякой фигней) можно создать безваитовый (или почти безваитовый) контроллер. Причем это можно сделать простой модификацией прошивки ZXMC - введя предварительно рассчитанную таблицу (а это сделать можно - ведь у ATmega8515/35 - 512 байт SRAM).

а почему? не знаю про CPLD, и цену диода на 40 умножать ломает, но (256x8 SRAM)+MUX=копейки, и никаких вейтов в турбе.
...заняться, что-ли, AVRский ассемблер выучить заодно ;)
что-то наподобие http://www.speccy.org/trastero/cosas...r3/imar3_e.htm
если выкинуть оттуда шифратор, а /RD+/IORQ+A0 на INT повесить