Реверс-инжиниринг УКНЦ (1515ХМ1&2, 1801ВП1, 1801ВМ2)

Цитата:

---

Сообщение от Alex_K

Жду с нетерпением.

---

Там работы немало, скажу я вам)

Вообще, процессор в целом весьма сложная штуковина. Я думаю, какой-нибудь Z80 явно в разы попроще.
Тут и независимые блоки, и конвейеры в каждом блоке, сложные зависимости.
И, самое интересное, есть много вещей, которые словно приляпывались поверх уже существующих. Я не говорю о расширенной арифметике, которая именно так и сделана.
Например, модификаторы для микрокоманды сделаны совершено по-разному. Этому один бит, этому два, этому три, и все эти биты разбросаны, перемешаны и доляпаны друг к другу. Не говоря уже о том, то, видимо, за нехваткой разрядности микрокода, в качестве модификаторов использовались даже отдельные биты адреса следующей микрокоманды (NA5..NA0). Так что сборной солянки для расшифровки там не мало.
Ну, и, конечно же многофункциональное поле RI, сделанное в виде трехпортового трехбитного регистра, при этом третий порт работает в виде reset/set/set, как описано чуть выше.
Полно было триггеров, которых надо было проверять, не встанут ли они в третье состояние.
Словом, распутано и приведено в человеческий вид многое, но еще не все.

Я вообще не понимаю, как @Vslav разбирается в потранзисторной схеме, или же в ее аналоге на VHDL. Запускать это можно, отследить любые сигналы можно, но разобраться во всей поднаготной и систематизировать реверс, при этом не теряя всю общую картину, по такой схеме для меня было бы нереально.

Цитата:

---

Сообщение от Titus

но разобраться во всей поднаготной и систематизировать реверс

---

Думацо, он не ставил такой цели. Можно же реверс разделить на несколько этапов:
1. Чтоб работало как оригинал;
2. Чтоб понять как работает оригинал;
3. Чтоб понять почему оригинал сделали именно так.

Цитата:

---

Сообщение от CodeMaster

2. Чтоб понять как работает оригинал;
3. Чтоб понять почему оригинал сделали именно так.

---

Вот мне как раз важно 2-е.
Ибо, я эмуляторщик, и если соберусь писать потактовый УКНЦ, то без второго пункта можно даже не пробовать.
Естественно, писать даже потактовую эмуляцию в виде эмуляции всех вентилей - это абсурд и дикие тормоза.
А, стало быть, надо понять ВСЮ структуру процессора до мелочей, и преобразовать в тот вид, когда это уже можно эмулировать, а не просто тупо повентильно симулировать.
Поэтому, опять же, верилог для основы мне не подходит.

@Alex_K, интересное наблюдение.
При обработке прерывания безадресный регистр (SEL) читается в любом случае, независимо от того, в режиме USER обрабатывается прерывание или в режиме HALT.

Цитата:

---

Сообщение от Titus

@Alex_K, интересное наблюдение.
При обработке прерывания безадресный регистр (SEL) читается в любом случае, независимо от того, в режиме USER обрабатывается прерывание или в режиме HALT.

---

Да, это уже известно. Было обнаружено при моделировании процессора. Да и в официальной документации описано, рис.51 во второй части ТО.

Цитата:

---

Сообщение от Alex_K

Да, это уже известно.

---

А я уж думал, что открыл Америку)

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

Цитата:

---

Сообщение от Titus

А я уж думал, что открыл Америку)

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

---

Вероятнее всего, что так и есть. Это, кстати, сохранено и в 1806ВМ2. А куда читается SEL?

Цитата:

---

Сообщение от Alex_K

Вероятнее всего, что так и есть. Это, кстати, сохранено и в 1806ВМ2. А куда читается SEL?

---

Все, что читается с шины, размещается в BRD (буферный регистр данных).
А если читается код следующей инструкции, то он размещается и в BRD, и в BIR (буферный регистр инструкций) одновременно.

- - - Добавлено - - -

Уточню - все, что я уже рассмотрел. Но могут быть режимы, до которых я еще не добрался.

Чтение вектора прерывания в документации от @Alex_K нарисовано неправильно:

https://pic.maxiol.com/images2/16058...51043.iak0.png


На самом деле происходит так:

https://pic.maxiol.com/images2/16058...51043.iak1.png

То есть, данные с шины защелкиваются внутри активного DIN, а точнее внутри RDAT.

А если ответить RPLY не дожидаясь IAKO, то можно сократить время чтения на два такта,
хотя практической пользы от этого, видимо, никакой.

https://pic.maxiol.com/images2/16058...51043.iak2.png

Цикл записи шины в процессоре ВМ2 (12 тактов) значительно медленнее, чем цикл чтения (8 тактов).
Кроме того, невозможно задать опережающий RPLY, таким же образом, как в цикле чтения, чтобы сократить время доступа к шине. Это связано с тем, что 'увидев' RPLY на шине, контроллер не выдаст данные. Поэтому, если мы хотим ускорить запись опережающим RPLY, выдавать его нужно после того, как на шину выставлены данные, но до того, как появился сигнал DOUT.
Как же этого добиться? В принципе, такое возможно.
Например, после получения адреса сперва ожидаем появление на шине значения 0x0000, затем ожидаем любого изменения на шине, либо же появления сигнала DOUT. После чего выдаем RPLY.
В случае, если записывается число 0x0000, опережающего RPLY выдать не получится. При записи любого другого числа, RPLY будет с опережением, и цикл записи сократится до 10 тактов.
Конечно, это усложнит контроллер памяти, но позволит ускорить запись.

https://pic.maxiol.com/images2/16059...1951043.01.png