О том, как найти ошибку в микропроцессоре, выпущенном тридцать пять лет назад

К1801ВМ1А


В это трудно поверить, но иногда ошибки в процессорах по сути живут дольше, чем сами процессоры. Недавно мне довелось в этом убедиться на примере 16-разрядного микропроцессора 1801ВМ1А, на основе которого в свое время в СССР было создано семейство бытовых компьютеров БК-0010/11М. Об этом семействе на Хабре неоднократно писали.


Период активной жизни "БэКашек" приходится на конец 80-х — начало 90-х годов прошлого века. В эти годы, усилиями многочисленных энтузиастов-одиночек, а также групп кружковцев и кооператоров был наработан основной массив прикладных программ для БК: игры, утилиты, разнообразные "ДОСы" (дисковые операционные системы). Параллельно с развитием софта создавалась периферия, под которую писался свой системный софт. В целом, экосистема этих 16-разрядных PDP-подобных ЭВМ развивалась по схожим принципам, как, например, развивались ранние 8-битные открытые архитектуры на основе Intel 8080 и шины S-100. Позже, по мере отхода от утилитарной роли БК, фокус в программировании сместился в сторону демосцены.


Объем программного обеспечения для БК можно оценить, посетив общедоступные сайты с коллекциями программ. Конечно, по сравнению, например, с ZX-Spectrum, этот объем значительно скромнее. Тем не менее, даже такого объема, казалось бы, должно было хватить, чтобы обойти все мыслимые закоулки машинного кода. Можно ли найти что-то необычное в поведении процессора, после более чем тридцатилетней практики его использования? Как оказалось — да! Об этом и пойдет речь ниже.


Пожалуй, имеет смысл рассказать эту историю в хронологическом порядке. Прежде всего, должен сразу заметить, что я вовсе не "программист со стажем", ни по роду занятий, ни по принадлежности к когорте энтузиастов БК, о которых я написал выше. К БК я пришел окольными путями, частично через ностальгию по увлечениям детства и юности (аналоговая и цифровая электроника, журнал Юный Техник, ЮТ-88 и прочие поделки и недоделки), а частично через интерес к архитектуре и системе команд PDP-11. БК "в железе" у меня нет и программы под БК я, как правило, запускаю и отлаживаю в эмуляторе bkemu на планшете под Андроид.


Некоторое время назад, я заинтересовался программой "Kaleidoscope" за авторством Li-Chen Wang-a. Программа была написана в 1976 г. в машинных кодах, под микропроцессор Intel 8080 в составе компьютера Altair 8800 с графическим адаптером Cromemco Dazzler. Мне захотелось детально разобрать алгоритм Li-Chen Wang-a и, заодно, портировать его на БК. Надо сказать, что желание портировать Калейдоскоп под БК высказывалось в среде демосценеров и ранее, и даже были попытки разобрать алгоритм, но они не увенчались успехом.


В своей следующей статье, я, возможно, разберу этот алгоритм в деталях (а для нетерпеливых тут выложу ссылку на исходники кросс-платформенного Калейдоскопа под libSDL на С). Для дальнейшего же, достаточно будет указать, что задача была решена, и Калейдоскоп был успешно портирован на БК. Более того, в алгоритм на БК была добавлена генерация звука, причем, поскольку и картинка, и звук генерируются одним и тем же кодом, можно сказать, что сама картинка и звучит (вся демка уместилась менее, чем в 256 байт машинного кода, и, надеюсь, будет представлена общественности на CAFe Demoparty 2019 в Казани в конце октября).


Закончив с написанием и отладкой моей программы в эмуляторе, я обратился к Дамиру ("Адамычу") Насырову (он один из организаторов CAFe Demoparty и весьма известный в среде демосценеров человек) с просьбой проверить выполнение программы на реальной БК. Особенно меня интересовало воспроизведение звука, так как тайминги в эмуляторе могли отличаться от таймингов на реальном железе. Каково же было мое разочарование, когда Дамир сообщил мне, что на реальной БК изображение есть, а звука нет!


Последующие несколько вечеров прошли в попытках вычитать из системной документации на БК-0011М и принципиальной схемы, где же могла быть ошибка со звуком. Звук в БК организован довольно просто: 6-й бит в регистре ввода/вывода с восьмеричным адресом 177716 (регистр управления магнитофоном) выведен через буфер на пьезоэлектрический динамик (бипер). В дополнение к 6-му разряду, разряды 2 и 5 того же самого регистра заведены на простейший цифро-аналоговый преобразователь на 4-х резисторах. С выхода этого преобразователя звук может идти на магнитофон. Все исключительно ясно и логично, но звука на реальной БК упорно не было, независимо от комбинаций битовых масок, которые я пытался применить к данным, выводимым в этот регистр. Параллельно были установлены и протестированы все известные мне эмуляторы БК — и звук работал во всех!


В какой-то момент мне даже почти удалось убедить Дамира, что его БК неисправна, однако поведение повторилось на другой живой БК-0011М, а также и на БК-0010. У меня закончились идеи, и обитатели телеграм-канала по БК-тематике тоже ничего не могли подсказать… Однако, помог, как водится, случай. В процессе одного из экспериментов, Дамир запустил демку на эмуляторе, чтобы убедиться, что звук в эмуляторе есть. И вот тут ему удалось заметить, что не только звук в эмуляторе есть, а на БК нет, но еще и картинки в эмуляторе и на живой БК отличаются! Здесь я должен вам напомнить, что в моей программе и картинка, и звук генерируются одним кодом. Соответственно, все это время я искал причину не в том месте: причина была в коде, который генерировал данные для содержимого экрана.


Дамир прислал мне снимок экрана, и стало понятно, что алгоритм производит байты с нулевым содержимым старших 4-х разрядов, и, по стечению обстоятельств, именно эти биты выводились на звук (т.е., всегда нули). Однако причина, почему алгоритм так себя ведет оставалась туманной. Вот это место в коде (ассемблер macro11 от PDP-11, регистры r0-r5 переименованы!):


; renamed registers
a   =   %0
b   =   %1
c   =   %2
d   =   %3
e   =   %4
h   =   %5

    ...
    ...

    asr     b           ; sets CF
    bic     #177760, b
    bis     b, c
    bis     (h)+, c     ; screen address in c
    movb    (c), a      ; get a byte from screen RAM
    bcc     1$          ; check CF

    bic     #177760, a  ; keep bits 0-3, clear rest
    bisb    d, a        ; fill bits 4-7
    br      2$
1$:
    bic     #177417, a  ; keep bits 4-7, clear rest
    bisb    e, a        ; fill bits 0-3
2$:

    ...
    ...

По какой-то причине, на реальной БК, всегда выполнялся условный переход по метке 1$. То есть, инструкция bcc всегда воспринимала флаг переноса, как сброшенный, хотя инструкция сдвига ASR могла этот флаг установить как в 0, так и в 1. Как такое могло быть, ведь по документации на процессор, ни BIC, ни BIS, ни MOVB не должны оказывать влияние на флаг переноса?!


Причем, во всех эмуляторах (которые ведь писались по документации на процессор!) так и есть: эти инструкции не трогают флаг С. Стало ясно, что реальный процессор 1801ВМ1А работает в этом случае не по документации. Осталось это подтвердить.


Для начала, очевидный quick fix:


    ...

    asr    b             ; sets CF
    mfps   -(sp)         ; store PSW on stack 
    bic    #177760, b
    bis    b, c
    bis    (h)+, c       ; screen address in c
    movb   (c), a        ; get a byte from screen RAM
    mtps   (sp)+         ; restore PSW from stack
    bcc    1$            ; check CF

    ...

Сохранение флагов в стеке сразу после инструкции сдвига и их восстановление перед условным переходом тут же решило проблему, что показало, что я на верном пути. Осталось сузить "круг подозреваемых". Для проверки гипотезы был сначала написан такой синтетический тест (тут регистры не переименованы; начальная инициализация опущена, чтобы не загромождать код; emt 64 — программное прерывание для печати строки):


    ...
    mov    #1, r1
    jsr    pc, test
    clr    r1
    jsr    pc, test
    halt

test:
    mov    #40000, r2    ; r2 points to screen RAM
    mov    #dummy, r5    ; r5 points to dummy = 200
    ; *** begin ***
    asr    r1            ; affects CF
    bic    #177760, r1
    bis    r1, r2
    bis    (r5)+, r2
    movb   (r2), r0
    ; *** end ***
    jsr    pc, prt
    rts    pc

prt: 
    mov    #msg1, r0
    bcs    l1
    mov    #msg2, r0
l1:
    emt    64
    rts    pc

msg1:
    .asciz /Flag CF set/
msg2:
    .asciz /Flag CF clear/
dummy:
    .word 200
     ...

И тест … не сработал! Программа напечатала на экране


Flag CF set
Flag CF clear


Что же оказалось? Оказалось, что исходное предположение, что фрагмент кода между begin и end просто портит флаг C — неверно, и требует уточнения. Чем же так отличается этот тест от исходного кода? А тем, что между блоком "подозрительных" команд и условным переходом появились другие инструкции. Не влияющие на флаг С, но тем не менее, меняющие внутреннее состояние процессора. Поэтому, следующий тест был такой:


    ...
    mov    #1, r1
    jsr    pc, test
    clr    r1
    jsr    pc, test
    halt

test:
    mov    #40000, r2
    mov    #dummy, r5
    ; *** begin ***
    asr    r1            ; affects CF
    bic    #177760, r1
    bis    r1, r2
    bis    (r5)+, r2
    movb   (r2), r0
    bcc    l1
    ; *** end ***
    mov    #msg1, r0
    emt    64
    rts    pc
l1:
    mov    #msg2, r0
    emt    64
    rts    pc

msg1:
    .asciz /Flag CF set/
msg2:
    .asciz /Flag CF clear/
dummy:
    .word 200
    ...

И вот этот тест уже напечатал на реальной БК-0011М:


Flag CF clear
Flag CF clear


На эмуляторе же, по-прежнему,


Flag CF set
Flag CF clear


Дальнейшее — дело техники. Путем постепенных упрощений был получен вот такой минимальный тест, на котором воспроизводится баг (привожу исходник целиком):


    .title test
    .psect code
    .=.+1000
    mov    #15, r0
    emt    63
    sec
    jsr    pc, test
    clc
    jsr    pc, test
    halt

test:
    movb   r0, r0
    bcc    l1
    mov    #msg1, r0
    emt    64
    rts    pc
l1:
    mov    #msg2, r0
    emt    64
    rts    pc

msg1:
    .asciz /Flag CF set/
msg2:
    .asciz /Flag CF clear/
    .end

На реальной БК-0011М этот тест выводит


Flag CF clear
Flag CF clear


То есть, виновата оказалась инструкция MOVB, стоящая прямо перед командой условного перехода, причем вид первого операнда не суть важен. Если же между MOVB и BCC вставить, например, NOP, то поведение вернется к документированному, и программа напечатает


Flag CF set
Flag CF clear


Что позволило сформулировать уточненную гипотезу (цитирую себя, из телеграм-канала):


… По поводу бага: поведение вроде прояснилось. Как я себе представляю, MOVB src, dst (кстати, похоже что операнды не суть важны) из-за каких-то особенностей архитектуры временно портит флаг С внутрях проца, но не фатально, ибо проц, похоже, сохраняет копию этого флага. В результате, если между MOVB и условным переходом есть другие команды (не влияющие на С), например, NOP, то поведение как по документации.

Что же было дальше? Дальше, коллеги из канала помогли привлечь к обсуждению Вячеслава (@K1801ВМ1, легендарного человека, который ранее отреверсил этот процессор на уровне транзисторов). Реакция Вячеслава (Yuot), когда он протестировал поведение на стенде с реальным 1801ВМ1A (орфография и пунктуация сохранены):


Stanislav Maslovski:
минимум для воспроизводства нужны две команды
movb и условный переход по С
ну и перед этим флаг С выставить в известное состояние

Yuot:
Флаг с всегда сброшен получается

Stanislav Maslovski:
да
теперь вставь ноп

Yuot:
А теперь ни всигда

Yuot:
Чередуется 0 1
Это какой-то позор

С помощью Вячеслава выяснились детали, а именно, что причина бага в том, что в процессоре, помимо PSW есть еще один 4-х битный регистр, который, в норме, хранит копию флагов из PSW. Регистр этот связан с автоматом микропрограмм и условные переходы берут значения флагов из него. При выполнении же инструкций МОVB, SWAB, MFPS с регистром-приемником, из-за особенностей обработки знакового расширения и из-за ошибки в микрокоде, копия флага С в этом регистре сбрасывается и условные переходы по этому флагу работают некорректно. Однако, при выполнении следующей инструкции, значение временного регистра восстанавливается из PSW. Именно поэтому, вставка NOP восстанавливает правильное поведение.


В заключение, хотел бы также поблагодарить подписчиков телеграм-канала "БК0010/11М World" за участие в обсуждении этого бага, и за высказанные замечания по тексту статьи. Заглавное фото к статье любезно предоставлено Manwe_SandS. Что еще более интересно, Manwe был близок к обнаружению того же самого бага, практически в то же время, когда мы с Дамиром бились над решением проблемы звука!


Теперь же дело за малым (шучу) — привести все эмуляторы в соответствие с реальным поведением процессора. Ведь сам процессор, увы, уже не исправишь.


На этом я и закончу. Надеюсь, было интересно.

Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 68

    –7
    В итоге причина такого поведения не выяснена?
      +4
      Причина выяснена, объяснение (весьма упрощенное, конечно) дано ближе к концу статьи. На самом деле, поскольку есть полная модель процессора в Verilog (благодаря реверсу, который Вячеслав проделал), можно пройтись по всем деталям.
        0
        С этого помента поподробнее — о каком реверсе идёт речь? Насколько я знаю копировали КР580ВМ80А, калькуляторы (МК-54, МК-61), а вот с БК вроде на этом уровне никто не работал… или работал?
          +1
            +1
            Ого. Круто. Интересно — никто не пытался эмулятор поверх этого устроить? Слишком медленно получается или «не особо и нужно»?

            Любители калькуляторов таки создали себе эмулятор с ЕГГОГами и «оборотнями», а БК пока отстаёт…
              0
              На моей памяти, на форуме ZX-PK.ru обсуждалась такая возможность. По-моему, как раз в теме, на которую сослался Wesha.
                0

                Кстати, о птицах: я буквально недавно получил обратно свои БКшные кассеты тогдашних лет, написал (на Ruby) с ленты, и сейчас потихоньку считываю свою коллекцию с лент.

                  0
                  Выкладывайте на форуме zx-pk! Там есть тема про БК.
                    0

                    Эти #$@ (форумные администраторы) отключили регистрацию. Оставил заявку неделю назад — молчание. (А мне есть чего сказать: например, в описании протокола по этой ссылке есть фактические ошибки.


                    Пока что размещаю на гитхабе.

                      0
                      Я заметил только два отличия между моим и Вашим описанием:
                      1. длина конечного тона у меня 128, а у Вас 256,
                      2. скважность нулевого импульса у Вас 1:1, а у меня 2:1.
                      Но это не «ошибки», это оптимизация. Я трассировал ПЗУшную подпрограмму чтения, а не записи, чтобы оптимизировать входные данные (то есть для меня не важно как записывает на ленту стандартная ПЗУшная процедура). В том виде, в котором я описал, данные пригодны для чтения, но занимают меньше.
                        +1

                        А я — подпрограмму записи (кстати, очень легкая для понимания!), и там это выглядит так:


                        1) у Вас нарисовано, что синхробит идёт перед импульсом данных. На самом деле он идёт после. Дело в том, что любые биты выводятся с последующим синхробитом (подпрограмма одна и та же ж!) — в том числе и вот эта единица в конце — и они поменялись местами: у Вас [ пилот, ограничивающий импульс, 1 ] + [ (0, импульс данных), (0, импульс данных),… ], и последний 0-импульс приклеился к "pilotone (9)" — у меня (ещё до того, как я начал освежать код в памяти) с самого начала были подозрения — а с какого перепугу у Вас там число ипульсов не круглое (в восьмеричной системе, конечно). А на деле — выводится [ пилот, ограничивающий импульс, 1, 0 ] + [ (импульс данных, 0), (импульс данных, 0)… ], и следующий маркер должен быть "pilotone (8)".


                        2) У Вас нарисовано, что после "DATA (file)" сразу идёт "DATA (checksum)". Это неправильно, товарищи, надо говорить "ширее" после контрольной суммы идёт ещё один маркер, точно такой же, как и перед ней.


                        3) У Вас в конце файла идёт "pilotone(128)", а на самом деле идёт там должно быть [ "end tone четверной длины", "pilotone(256)", 1, 0 ] — но это уже непринципиально, т.к. этот маркер Неуловимый Джо мало кто вообще читает.


                        Я понимаю, что для чтения Ваши ошибки непринципиальны — но мы же составляем документацию, в которой должно описываться, как вещи оказываются такими, какими они есть, а не только то, что мы видим в результате. Разница в том, что если бы Вы писали документацию на ядерную бомбу, она при вашем подходе она была бы в стиле "нажимаешь кнопочку, и оно громко бабахает", а у меня — "при инициации просходит обжимка ядра из урана точно рассчитанными взрывами" и ещё 100 страниц :)


                        Кстати, попутно в недрах интернета я обнаружили "исходники Дябина", которые на самом деле не являются тем, что реально залито в БК (то, что реально залито — это декомпиляция Фролкина с комментарями Зальцмана, могу залить фотографии распечаток — руки пока не дошли полностью распознать их в текст).

                          0
                          после контрольной суммы идёт ещё один маркер, точно такой же, как и перед ней.

                          Тут у меня описка — следует читать "после заголовка идёт ещё один маркер, точно такой же, как и перед ним" (пока до меня дошло, Хабр уже закрыл редактирование).

                            0
                            Единица и синхроимпульс?
                            Возможно. Мы чего-то там на ходу правили в JS-конвертере, я уже не помню. Надо посмотреть код.
                            0
                            у Вас нарисовано, что синхробит идёт перед импульсом данных. На самом деле он идёт после
                            Пожалуй, Вы правы! Описанный мной формат будет читаться (я же проверял), но формально он описан со сдвигом на один синхроимпульс. Поправлю при случае.

                            У Вас в конце файла идёт «pilotone(128)», а на самом деле идёт там должно быть
                            Не должно, потому я описываю не как ПЗУ выводит звук, а как я его готовлю для чтения. Действительно, можно сократить ещё больше, но какой-то из копировальщиков обломался на коротком пилотоне, поэтому я оставил такой.
                              0

                              Тьфу ты, тут одну минуточку, параграф, помеченный 2) выше вычеркните, я там спросонья всё перепутал, сейчас напишу по новой. Но смысл в том, что один маркер Вы таки забыли.


                              Не должно, потому я описываю не как ПЗУ выводит звук, а как я его готовлю для чтения.

                              А я описываю то, что человек реально встретит на ленте; а как он захочет это обрабатывать — это уже дело пятнадцатое: например, всё, что после контрольной суммы, вполне можно смело скатать в трубочку и засунуть, но на ленте-то оно есть!

                                0
                                Понятно, но в моём случае не важно что БК пишет на ленту, потому что там получается много лишнего. Важно что можно скормить компьютеру, чтобы он побыстрее это съел, но не подавился :)
                                  0

                                  Во-первых, это зависит от Вашей задачи: если только прочитать, то таки да, а вот если правдоподбно писать...


                                  Во-вторых, повторюсь, если Ваша задача — максимально всё упростить, то, например, маркер конца файла Вам совершенно не упёрся: чтение (насколько я помню) завершается на КС, и дальше никто ничего не проверяет.

                                0

                                А, вот: параграф 2) следует читать:


                                2) у Вас нарисовано, что после стартового 4096-импульсного пилотона с конечной единицей сразу идёт заголовок. Это неправильно: перед заголовком идёт маркерная последовательность — точно такая же, как перед основными данными файла. (Причина — в том, что 20 байт заголовка выводит та же самая подпрограмма, которая потом выводит тело файла — то есть идут вызовы CALL write_array(HEADER); CALL write_array(BODY);.)


                                В общем, смотрите мой гитхаб по ссылке выше, там код правильный :)

            0
            Получается, что в реальном коде никто не ставил операции МОVB, SXT, SWAB и MFPS перед условним переходом, что в общем-то логично. Странно, что у вас так получилось.
              +6
              Вообще, очень часто встречается в других процессорах, которые при MOVB меняют флаги, например Motorola 68000. И это поведение использовали игроделы.
                +7

                Такой порядок команд возник вследствие оптимизации программы. Раньше никто настолько не заморачивался, чтобы уложить демку в 256 байт, да ещё добиться максимальной скорости.

                  +3
                  Как уже совершенно верно тут заметили, это сделано ради экономии места за счет уменьшения числа инструкций.
                  +2

                  Увлекательно и захватывающе. Как детектив. Правда, я не совсем понял. Этот баг присутствует и в оригинальном процессоре, или только в отечественном клоне?

                    +12
                    1801вм1 НЕ является клоном.
                      +8
                      Спасибо! 1801ВМ1 — отечественная разработка, от PDP-11 позаимствована лишь система команд и общая архитектура.
                        +1
                        И тем не менее, в PDP-11 такой баг есть или нет?
                          +3
                          Про какой-либо аналогичный баг на PDP-11 мне ничего не известно. По документации (ссылка есть в статье), инструкция MOVB на PDP-11 не влияет на флаг С.
                            +13
                            А вы сам как думаете, есть ли никому доселе не известный баг процессора К1801ВМ1 в компьютере, где нет процессора К1801ВМ1?
                        +1
                        Сколько живу, думал, что это именно клон :) А сейчас залез на вики, почитал про него, может кто расскажет, а использовалась эта возможность: «Микропроцессор поддерживает работу в многопроцессорной (до 4-х процессоров) конфигурации. Номер процессора задаётся входами PA0 и PA1 (выводы 27 и 26)»? Просто всегда думал, что это уже более новое изобретение — распаралеливание процессоров.
                          +3
                          Википедия: en.wikipedia.org/wiki/Burroughs_large_systems#Unique_features — мультипроцессорная машина в 1961 году.
                            +1
                            Компьютер БК разрабатывался начиная с 1979-го года, в прототипе было два процессора. Потом от этой идеи отказались и в 1983-ем году появилась однопроцессорная конструкция, весьма близкая к той, что в итоге пошла в массовый тираж.
                              +2
                              Просто всегда думал, что это уже более новое изобретение — распаралеливание процессоров.

                              А там не предусматривалось никакого распареллеливания. Симметричная мультипроцессорность, это уже более современная фишка. Тогда центральный процессор был всего один, но могли быть периферийные, которые решали другие задачи. Например, в дальней родственнице БК-0010, школьной Электронике УКНЦ как раз стоит два таких процессора. Один центральный, другой управляет периферией.
                              А могли быть и разные процессоры, например, тот же i8086 умел работать в связке с двумя другими, арифметическим i8087 и процессором ввода-вывода i8089. Последний, впрочем, не попал в конструкцию IBM PC, потому не так известен, как первые два.
                                +1
                                Интересно почему не попал? Из-за удешевления? Так то выделить ввод-вывод на отдельный процессор логично.
                                  +1
                                  Сопроцессор это дорогое удовольствие для РС. По этому он был опциональным до 486-х
                                  Here are list of these price for these Intel 8087 Math CoProcessor (USD):

                                  Model: Model Number, Suggested Unit Price

                                  8087: BOX8087, $142
                                  8087-2: BOX8087-2, $205
                                  8087-1: BOX8087-1, $270

                                  Source: Intel Corporation, «Personal Computer Enhancement» brochure, Order No. 245.2 10-89/75K/AL/GO, October 1989

                                  По этой же причине IBM не использовало I8089 в IBM PC
                                    +1
                                    Вставить 8089 в дизайн материнской платы образца 1981 года с ISA-шиной скорее всего просто так нельзя. Те компьютеры, где он реально стоял (Apricot PC, Altos 586) это либо рабочие станции очень высокого ценового уровня, либо вообще не PC по архитектуре внутри с очень условной с ним совместимостью. Для 8089 нужен арбитр шины (8289) и вообще желательно что-нибудь вроде EISA-шины, которая появилась через 8 лет, или Мультибас, который в обычных PC не применялся. Да, все из-за удешевления, но, конечно, ни IBM и никто другой даже в самых смелых планах вряд ли думали, что это семейство окажется настолько живучим и не закладывали туда таких решений на десятилетия вперед.
                                      0
                                      Для 8089 нужен арбитр шины (8289)

                                      В IBM PC же есть арбитр шины :) Там 8088 работает в максимальном режиме, чтобы была возможность установки сопра.
                                        0
                                        Для ограниченных целей (сопряжение 16-битного чипа, взятого из комплекта 8085 с 20-битной адресной шиной). Арбитража в том смысле, какой был на EISA, там нет, на EISA — Multiple Bus Mastering, до 7 устройств, на XT-Bus он очень ограничен и только для устройств, встроенных в материнскую плату, не для слотов расширения. «An important feature of the EISA bus is that the host or any bus master can access any memory device or peripheral in the system, even if their bus widths differ.» — чем в общем и занимался 8089, у него тоже была эта функция. В этом плане наверное можно рассматривать шины MCA, EISA как дальнейшие развитие, универсализацию тех же идей. И ранние PC с «ассиметричной» многопроцессорностью, (Compaq SystemPro 386/486), как мне кажется, в принципе повторяют ту же схему с гипотетическим 8089.
                                          0
                                          Для ограниченных целей (сопряжение 16-битного чипа, взятого из комплекта 8085 с 20-битной адресной шиной).

                                          Не совсем понял, что вы имеете в виду. Арбитр 8289 служит для управления захватом шины между двумя процессорами. Причем оба они, 8087 и 8088/8086, имеют ту же ширину шины, что и компьютер, 20 бит адреса, 8 или 16 бит данных.
                                            0
                                            16-битный там DMA-контроллер 8237. «As a member of the Intel MCS-85 device family, the 8237 is an 8-bit device with 16-bit addressing. However, it is compatible with the 8086/88 microprocessors. The IBM PC and PC XT models (machine types 5150 and 5160) have an 8088 CPU and an 8-bit system bus architecture; the latter interfaces directly to the 8237, but the 8088 has a 20-bit address bus, so four additional 4-bit address latches, one for each DMA channel, are added alongside the 8237 to augment the address counters. However, because these external latches are separate from the 8237 address counters, they are never automatically incremented or decremented during DMA operations, making it impossible to perform a DMA operation across a 64 KiB address boundary» (Wiki-en). Причем в минимальном режиме 8086 ничего, кроме этих защелок, для работы не нужно, однако именно в максимальном режиме 8086 нужен арбитр шины (не все источники понимают или приводят эту разницу). Источник информации — книга Pablo Mary «Microprocessors and Microcontrollers», глава 14.18
                                              0
                                              Самому теперь такой вопрос интересен — а на упрощенных клонах PC, где не было в конструкции и гнезда под 8087 и/или контроллера DMA (IBM PcJr) появлялся арбитр шины, или же выбрасывали и его тоже?
                                                0
                                                Не знаю насчет PCjr, но на советских домашних IBM-совместимых машинках, а-ля Поиск, Электроника МС1502, Квазар и т.д., процессор работал в минимальном режиме, и не было ни контроллера DMA, ни арбитра. Просто проц обвязывался регистрами для защелки адреса и данных, и шинными формирователями, ну и сам непосредственно рулил регистрами.
                                                  0
                                                  Логично. Кстати, встречал информация, что 8089 попал в некоторые советские ПК («Нивка» (также СМ1820)[1] — 32-разрядный персональный компьютер, ограниченно совместимый с IBM PS/2. Выпускался Киевским НПО «Электронмаш». Окончание разработки и выпуск первой ревизии датируется 1990 годом.)
                                                    0
                                                    Насчет Нивки не знаю, но знаю точно, что он был в ЕС-1842, причем он использовался там как собственный процессор в контроллере жесткого диска.
                                        0
                                        Да, упрощение конструкции и удешевление. Установка i8089, даже если не учитывать его собственную стоимость, значительно усложняет архитектуру материнки. Необходимо было бы разводить две раздельные шины, одну внутреннюю для общения процессоров с памятью и ПЗУ, вторую внешнюю для подключения периферии, со всей обвязкой. Поскольку компьютер планировался для массового потребителя, его решили делать без лишних наворотов. И так спасибо, что и DMA включили, и аж пять слотов расширения.
                                      0
                                      Как раз PDPшки (у нас — СМки) параллелились. Была и двухвходовая память, всякие трюки с взаимным пробросом окон в адресных пространствах процессоров и п.р
                                      +1
                                      Есть ли какая-то возможность использовать этот баг как фичу?
                                        +7
                                        Например, пока не пофиксят эмуляторы, этот баг дает возможность отличить выполнение на реальном железе от выполнения из-под эмулятора.
                                        +2

                                        Почему на Вашем телеграм-канале не работает превью через /s/? А то скачивать клиента не хочется.

                                          0

                                          Можно зайти через веб клиент: https://web.telegram.org/

                                            +2

                                            Для этого надо иметь тг-аккаунт. А я свой номер телефона налево и направо не раздаю.

                                              +1
                                              Вроде бы недавно отменили обязательное указание номера телефона
                                                0

                                                А поподробнее можно?

                                                  0
                                                  Ну я просто знаю что теперь при регистрации теперь не обязательно указывать номер телефона. Сам проверить не могу, ибо уже зареган)
                                          +3
                                          что показало, что я на верном пути. Осталось сузить «круг подозреваемых».

                                          на этом моменте я ощутил накал страстей
                                          Надеюсь, было интересно.

                                          Да, отличный тех.детектив, спасибо!
                                            0

                                            Спасибо за оценку!

                                            0
                                            Уверен, что в хоть одной игре на БКшке есть код, который эксплуатирует этот баг.
                                            Когда я писал игры для ПК-01 Львов, то там тоже нашел баг связанный со звуком и сменой палитры — можно было сопровождать звуковые эффекты визуальными.
                                            К сожалению у меня был монохромный дисплей. На цветном это выглядело отвратно.
                                              0
                                              Уверен, что в хоть одной игре на БКшке есть код, который эксплуатирует этот баг.

                                              Кстати, о птицах. Я в свое время открыл такую багофичу: между сигналом, что на клавиатуре что-то нажато (рязряд в ячейке 177716) и сигналом, что код клавиши готов к считыванию (разряд в ячейке 177660) проходило некоторое время (что-то порядка 50 циклов SOB), причём это время было с точностью до пары циклов стабильным для данного конкретного экземпляра БК, но плавало между экземплярами (то есть потенциально можно было написать привязку программы к более-менее конкретному экземляру). Объяснялось это тем, что в цепи формирования разряда в 177716 стоял конденсатор, параметры которого немного "плавали" от экземпляра к экземпляру. Тогда я эту информацию засекретил, чтобы не позволить людям запилить ещё одну защиту — но факс остаётся факсом :)

                                              0

                                              Что интересно, если не путаю, то на таком проце (или ВМ2?) делался компьютер управления ракетным огнем для Курска — баллистика, вот это все. Кажется модернизация под новое вооружение. Дюжина параллельных одноплатных машин в шкафу, в виде гроба в рост человека (буквально — граненые пирамидальные крышки-дверцы).

                                                0
                                                Наверное не на таком (там для оборонки были другие серии), но на подобном. Это же любимая архитектура МЭП в СССР, на ней делалось всё, от калькуляторов до станков ЧПУ.
                                                  0

                                                  Камень тот же, но в керамике. ДВК ж были по сути.
                                                  Что то отбирали (очень много брака), но все равно, плат столько для дубляжа, они часто сбоили в работе, и сделать с этим ничего было нельзя. Помимо того, что работали минимум три (4?) параллельно по требованиям надежности вычислений. Да 4, и 16 плат.

                                                0
                                                Искали баг в процессоре, нашли его во всех его эмуляторах, получается.
                                                  0

                                                  Ну, строго говоря, в процессоре тоже. Спецификации-то не соответствует, в отличие от эмуляторов.

                                                    –2
                                                    Мы не знаем умышленно ли сделано такое поведение и умышленно ли сокрыто в спецификациях.
                                                    Но мы знаем, что теперь это недокументированная фича и что все эмуляторы надо исправлять.
                                                      +3
                                                      Этот микропроцессор появился на базе другой советской разработки, а именно, однокристального микрокомпьютера 1801ВЕ1, у которого была своя, полностью оригинальная система команд и архитектура (Электроника НЦ). Первые прототипы того, что позже стало БК-0010, были собраны именно на ВЕ1 (с 79 по 81 г.). Однако, в связи с тем, что в 82 году МЭП СССР закрыло все работы по НЦ, процессор пришлось лихорадочно переделывать под архитектуру и систему команд, cовместимую с Электроникой 60 (клон PDP-11), как того хотело министерство. Поэтому, Ваш вариант с «закладкой» я исключаю, как не имеющий под собой оснований (иначе была бы вероятность поиметь проблемы с совместимостью). Более вероятно, что это баг, который появился в процессе спешной переделки микрокода под новую систему команд.
                                                    0
                                                    Нет, не получается. Читайте внимательнее!
                                                      0
                                                      Это зависит от того, какая ставится цель: если эмуль должен следовать спецификациям, то да.
                                                      А если он должен работать как настоящее железо — то это ошибка в эмуляторе.
                                                        +2
                                                        Правильная интерпретация того, что было сделано, это а) нашли баг в процессоре и б) как следствие, во всех эмуляторах.
                                                    0
                                                    Есть такой проект BKUNIX (основана на ядре LSX (вариант UNIX V6ruen)), если я ничего не путаю в ней были какието, случайные/спорадические вылетания/зависания. Не может ли это быть связано с операцией MOVB, или другой еще не известной операции портящей флаги?

                                                    Only users with full accounts can post comments. Log in, please.