Полигон-2

Да, по ALE защелкивается не адрес, а некий код, разбор которого выполняется согласно выдаваемому типу цикла на AI0..3, для некоторой части циклов - это адрес, для других - служебная инфа или вообще мусор. Но в проекте по ссылке используется упрощённый способ декодирования - по коду на BS0..1, не используются прерывания, не используется GPR, потому выборка памяти и регистров в/в определяется однозначно (для циклов прерывания, обмена с сопроцессором и доступа к GPR, на BS должен выдаваться признак внутренней адресации. Сейчас лениво включать и проверять, уж извините.).

Или другими словами, у меня сделан блок дешифрации адреса.
Если по спаду ALE защёлкнулось нечто, что выполнило одно из условий равенства этого дешифратора,
то дальше можно не смотреть. Это в любом случае адрес.
Бяка наступает, если я хочу работать на максимуме возможностей процессора (когда нибудь потом) или мне нужно обратиться к
безадресному регистру. Типа того же РНП.
Тогда я анализирую режим работы шины декодируя параллельно и AIO. Если это GP чтение или запись, то то что защёлкнулось по ALE на шине AD
и есть GP код.

Да приделана ПЛИСина. Куда ж без неё.
Это продолжение страданий с нестабильным входом в ODT и невыводом символа в порт.
Т.е. я остановился на том, что изредка я по HALT в пульт попадаю.
При этом у меня опрашивается бит готовности данных приёмника,
если данные готовы (нажата клавиша) срабатывает ловушка след. адреса и данные считываются.
Затем отрашивается бит готовности передатчика.
А вот эха нет. Считывание работает а запись глючит.

Я купил плату KDJ11, проверил свои камни. По крайней мере в пульте работают и RT11 через порт грузят.
Дальше мне захотелось записать в ПЗУ программку, выводящую в бесконечном цикле символ на экран и разобраться уже и с выводом.
А тут РНП оказался безадресным...


Anonymous написал:

[q]

А если не GP, то у нас либо приоритет подтверждаемого прерывания, либо мусор от внутренних коммуникаций между компонентами процессора, или процессора и сопроцессора (если есть), всё остальное - адрес,

[/q]

Во всех этих случаях ALE неактивен. Или нет?

Любопытная штука. Смотрю я на доку по DCJ11 и доку на 1818ВА19.
Первый практически по всем выводам ТТЛ, вторая - чистый КМОП. А так хотелось припаяться по простому проводочками.
Вот за что такое счастье (((

С DCJ11 в плане проектов есть два сюрприза.
Сюрприз первый, в обязательном порядке нужно прикручивать декодер шины AOI.
Без этого работать можно только в пределах самого процессора.
Т.е. если вам хватает исключительно регистров самого процессора и пультового режима, то можно и без декодирования.
Но вот если вам хочется память там внешнюю, то всё.
Так же нелишним оказывается РНП, что требует дополнительного декодирования циклов General-Purpose (GP) Read Cycle.
И если без второго оно как то ещё шевелится, то без первого полный затык.
И как работает широко известный PDP11/HACK совершенно непонятно

https://web.archive.org/web/20...index.html
Второй сюрприз, не столь неприятный для самодельщиков, но по ряду причин очень неприятный для меня
заключается во времянках чтения шины. Без картинок оно неинформативно, а картинки я сейчас прицепить не могу
В двух словах, несмотря на наличие пары интересных пинов: DV (готовность данных!!!), и CONT мне так и не удалось
поуправлять длительностью цикла и моментом считываения данных с шины. При чём такое поведение противоречит ТО на камень.
Но косвенно мою правоту подтверждают известные мне конструкции, где скажем на DV подан просто постоянный уровень.
Но, для 90% применений это особого значения не имеет.