В это трудно поверить, но иногда ошибки в процессорах, по сути, живут дольше, чем сами процессоры. Недавно мне довелось в этом убедиться на примере 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, SXT, MFPS, из-за особенностей обработки знакового расширения, и из-за ошибки в микрокоде, копия флага С в этом регистре сбрасывается и условные переходы по этому флагу работают некорректно. Однако, при выполнении следующей инструкции, значение временного регистра восстанавливается из PSW. Именно поэтому, вставка NOP восстанавливает правильное поведение.
В заключение, хотел бы также поблагодарить подписчиков телеграм-канала "БК0010/11М World" за участие в обсуждении этого бага, и за высказанные замечания по тексту статьи. Заглавное фото к статье любезно предоставлено Manwe_SandS. Что еще более интересно, Manwe был близок к обнаружению того же самого бага, практически в то же время, когда мы с Дамиром бились над решением проблемы звука!
Теперь же дело за малым (шучу) — привести все эмуляторы в соответствие с реальным поведением процессора. Ведь сам процессор, увы, уже не исправишь.
На этом я и закончу. Надеюсь, было интересно.
Комментарии (57)
scg
10.10.2019 19:16Получается, что в реальном коде никто не ставил операции МОVB, SXT, SWAB и MFPS перед условним переходом, что в общем-то логично. Странно, что у вас так получилось.
DrMefistO
10.10.2019 20:02+2Вообще, очень часто встречается в других процессорах, которые при MOVB меняют флаги, например Motorola 68000. И это поведение использовали игроделы.
Manwe_SandS
10.10.2019 20:37+2Такой порядок команд возник вследствие оптимизации программы. Раньше никто настолько не заморачивался, чтобы уложить демку в 256 байт, да ещё добиться максимальной скорости.
smaslovski Автор
10.10.2019 20:53Как уже совершенно верно тут заметили, это сделано ради экономии места за счет уменьшения числа инструкций.
alex_kag
10.10.2019 19:25-1Увлекательно и захватывающе. Как детектив. Правда, я не совсем понял. Этот баг присутствует и в оригинальном процессоре, или только в отечественном клоне?
smaslovski Автор
10.10.2019 21:03+1Спасибо! 1801ВМ1 — отечественная разработка, от PDP-11 позаимствована лишь система команд и общая архитектура.
soul32bit
10.10.2019 22:45-1И тем не менее, в PDP-11 такой баг есть или нет?
smaslovski Автор
10.10.2019 22:48+1Про какой-либо аналогичный баг на PDP-11 мне ничего не известно. По документации (ссылка есть в статье), инструкция MOVB на PDP-11 не влияет на флаг С.
DrPass
10.10.2019 22:55+3А вы сам как думаете, есть ли никому доселе не известный баг процессора К1801ВМ1 в компьютере, где нет процессора К1801ВМ1?
alex_kag
10.10.2019 22:33Сколько живу, думал, что это именно клон :) А сейчас залез на вики, почитал про него, может кто расскажет, а использовалась эта возможность: «Микропроцессор поддерживает работу в многопроцессорной (до 4-х процессоров) конфигурации. Номер процессора задаётся входами PA0 и PA1 (выводы 27 и 26)»? Просто всегда думал, что это уже более новое изобретение — распаралеливание процессоров.
mpa4b
10.10.2019 22:41+2Википедия: en.wikipedia.org/wiki/Burroughs_large_systems#Unique_features — мультипроцессорная машина в 1961 году.
Manwe_SandS
10.10.2019 23:10Компьютер БК разрабатывался начиная с 1979-го года, в прототипе было два процессора. Потом от этой идеи отказались и в 1983-ем году появилась однопроцессорная конструкция, весьма близкая к той, что в итоге пошла в массовый тираж.
DrPass
10.10.2019 23:41+2Просто всегда думал, что это уже более новое изобретение — распаралеливание процессоров.
А там не предусматривалось никакого распареллеливания. Симметричная мультипроцессорность, это уже более современная фишка. Тогда центральный процессор был всего один, но могли быть периферийные, которые решали другие задачи. Например, в дальней родственнице БК-0010, школьной Электронике УКНЦ как раз стоит два таких процессора. Один центральный, другой управляет периферией.
А могли быть и разные процессоры, например, тот же i8086 умел работать в связке с двумя другими, арифметическим i8087 и процессором ввода-вывода i8089. Последний, впрочем, не попал в конструкцию IBM PC, потому не так известен, как первые два.
Sheti
11.10.2019 09:12Интересно почему не попал? Из-за удешевления? Так то выделить ввод-вывод на отдельный процессор логично.
axe_chita
11.10.2019 09:38Сопроцессор это дорогое удовольствие для РС. По этому он был опциональным до 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
vitalyvitaly
11.10.2019 13:14Вставить 8089 в дизайн материнской платы образца 1981 года с ISA-шиной скорее всего просто так нельзя. Те компьютеры, где он реально стоял (Apricot PC, Altos 586) это либо рабочие станции очень высокого ценового уровня, либо вообще не PC по архитектуре внутри с очень условной с ним совместимостью. Для 8089 нужен арбитр шины (8289) и вообще желательно что-нибудь вроде EISA-шины, которая появилась через 8 лет, или Мультибас, который в обычных PC не применялся. Да, все из-за удешевления, но, конечно, ни IBM и никто другой даже в самых смелых планах вряд ли думали, что это семейство окажется настолько живучим и не закладывали туда таких решений на десятилетия вперед.
DrPass
11.10.2019 14:18Для 8089 нужен арбитр шины (8289)
В IBM PC же есть арбитр шины :) Там 8088 работает в максимальном режиме, чтобы была возможность установки сопра.vitalyvitaly
12.10.2019 10:21Для ограниченных целей (сопряжение 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.
DrPass
12.10.2019 12:58Для ограниченных целей (сопряжение 16-битного чипа, взятого из комплекта 8085 с 20-битной адресной шиной).
Не совсем понял, что вы имеете в виду. Арбитр 8289 служит для управления захватом шины между двумя процессорами. Причем оба они, 8087 и 8088/8086, имеют ту же ширину шины, что и компьютер, 20 бит адреса, 8 или 16 бит данных.vitalyvitaly
12.10.2019 13:2716-битный там 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
vitalyvitaly
12.10.2019 14:00Самому теперь такой вопрос интересен — а на упрощенных клонах PC, где не было в конструкции и гнезда под 8087 и/или контроллера DMA (IBM PcJr) появлялся арбитр шины, или же выбрасывали и его тоже?
DrPass
12.10.2019 17:30Не знаю насчет PCjr, но на советских домашних IBM-совместимых машинках, а-ля Поиск, Электроника МС1502, Квазар и т.д., процессор работал в минимальном режиме, и не было ни контроллера DMA, ни арбитра. Просто проц обвязывался регистрами для защелки адреса и данных, и шинными формирователями, ну и сам непосредственно рулил регистрами.
vitalyvitaly
12.10.2019 20:19Логично. Кстати, встречал информация, что 8089 попал в некоторые советские ПК («Нивка» (также СМ1820)[1] — 32-разрядный персональный компьютер, ограниченно совместимый с IBM PS/2. Выпускался Киевским НПО «Электронмаш». Окончание разработки и выпуск первой ревизии датируется 1990 годом.)
DrPass
12.10.2019 21:33Насчет Нивки не знаю, но знаю точно, что он был в ЕС-1842, причем он использовался там как собственный процессор в контроллере жесткого диска.
DrPass
11.10.2019 14:09Да, упрощение конструкции и удешевление. Установка i8089, даже если не учитывать его собственную стоимость, значительно усложняет архитектуру материнки. Необходимо было бы разводить две раздельные шины, одну внутреннюю для общения процессоров с памятью и ПЗУ, вторую внешнюю для подключения периферии, со всей обвязкой. Поскольку компьютер планировался для массового потребителя, его решили делать без лишних наворотов. И так спасибо, что и DMA включили, и аж пять слотов расширения.
MacIn
11.10.2019 14:11Как раз PDPшки (у нас — СМки) параллелились. Была и двухвходовая память, всякие трюки с взаимным пробросом окон в адресных пространствах процессоров и п.р
LuckyOok
10.10.2019 22:49Есть ли какая-то возможность использовать этот баг как фичу?
smaslovski Автор
10.10.2019 22:51+1Например, пока не пофиксят эмуляторы, этот баг дает возможность отличить выполнение на реальном железе от выполнения из-под эмулятора.
Wesha
11.10.2019 02:40Почему на Вашем телеграм-канале не работает превью через /s/? А то скачивать клиента не хочется.
tmin10
11.10.2019 08:53Можно зайти через веб клиент: https://web.telegram.org/
Wesha
11.10.2019 09:10+1Для этого надо иметь тг-аккаунт. А я свой номер телефона налево и направо не раздаю.
TheSima
11.10.2019 09:56что показало, что я на верном пути. Осталось сузить «круг подозреваемых».
на этом моменте я ощутил накал страстей
Надеюсь, было интересно.
Да, отличный тех.детектив, спасибо!
Andrey_Rogovsky
11.10.2019 11:37Уверен, что в хоть одной игре на БКшке есть код, который эксплуатирует этот баг.
Когда я писал игры для ПК-01 Львов, то там тоже нашел баг связанный со звуком и сменой палитры — можно было сопровождать звуковые эффекты визуальными.
К сожалению у меня был монохромный дисплей. На цветном это выглядело отвратно.Wesha
11.10.2019 17:40Уверен, что в хоть одной игре на БКшке есть код, который эксплуатирует этот баг.
Кстати, о птицах. Я в свое время открыл такую багофичу: между сигналом, что на клавиатуре что-то нажато (рязряд в ячейке 177716) и сигналом, что код клавиши готов к считыванию (разряд в ячейке 177660) проходило некоторое время (что-то порядка 50 циклов SOB), причём это время было с точностью до пары циклов стабильным для данного конкретного экземпляра БК, но плавало между экземплярами (то есть потенциально можно было написать привязку программы к более-менее конкретному экземляру). Объяснялось это тем, что в цепи формирования разряда в 177716 стоял конденсатор, параметры которого немного "плавали" от экземпляра к экземпляру. Тогда я эту информацию засекретил, чтобы не позволить людям запилить ещё одну защиту — но факс остаётся факсом :)
chapai22
11.10.2019 14:37Что интересно, если не путаю, то на таком проце (или ВМ2?) делался компьютер управления ракетным огнем для Курска — баллистика, вот это все. Кажется модернизация под новое вооружение. Дюжина параллельных одноплатных машин в шкафу, в виде гроба в рост человека (буквально — граненые пирамидальные крышки-дверцы).
DrPass
11.10.2019 14:45Наверное не на таком (там для оборонки были другие серии), но на подобном. Это же любимая архитектура МЭП в СССР, на ней делалось всё, от калькуляторов до станков ЧПУ.
chapai22
11.10.2019 15:11Камень тот же, но кажись в керамике. Девелоперская плата была в пластике. ДВК ж были по сути.
Что то отбирали (очень много брака), но все равно, плат столько для дубляжа, они часто сбоили в работе, и сделать с этим ничего было нельзя. Помимо того, что работали минимум три параллельно по требованиям надежности вычислений.
perfect_genius
11.10.2019 21:39Искали баг в процессоре, нашли его во всех его эмуляторах, получается.
Cerberuser
11.10.2019 21:58Ну, строго говоря, в процессоре тоже. Спецификации-то не соответствует, в отличие от эмуляторов.
perfect_genius
11.10.2019 23:04-2Мы не знаем умышленно ли сделано такое поведение и умышленно ли сокрыто в спецификациях.
Но мы знаем, что теперь это недокументированная фича и что все эмуляторы надо исправлять.smaslovski Автор
12.10.2019 00:05Этот микропроцессор появился на базе другой советской разработки, а именно, однокристального микрокомпьютера 1801ВЕ1, у которого была своя, полностью оригинальная система команд и архитектура (Электроника НЦ). Первые прототипы того, что позже стало БК-0010, были собраны именно на ВЕ1 (с 79 по 81 г.). Однако, в связи с тем, что в 82 году МЭП СССР закрыло все работы по НЦ, процессор пришлось лихорадочно переделывать под архитектуру и систему команд, cовместимую с Электроникой 60 (клон PDP-11), как того хотело министерство. Поэтому, Ваш вариант с «закладкой» я исключаю, как не имеющий под собой оснований (иначе была бы вероятность поиметь проблемы с совместимостью). Более вероятно, что это баг, который появился в процессе спешной переделки микрокода под новую систему команд.
smaslovski Автор
11.10.2019 22:52Нет, не получается. Читайте внимательнее!
MacIn
11.10.2019 22:58Это зависит от того, какая ставится цель: если эмуль должен следовать спецификациям, то да.
А если он должен работать как настоящее железо — то это ошибка в эмуляторе.smaslovski Автор
11.10.2019 23:12+1Правильная интерпретация того, что было сделано, это а) нашли баг в процессоре и б) как следствие, во всех эмуляторах.
axe_chita
12.10.2019 20:35Есть такой проект BKUNIX (основана на ядре LSX (вариант UNIX V6ruen)), если я ничего не путаю в ней были какието, случайные/спорадические вылетания/зависания. Не может ли это быть связано с операцией MOVB, или другой еще не известной операции портящей флаги?
dss_kalika
В итоге причина такого поведения не выяснена?
smaslovski Автор
Причина выяснена, объяснение (весьма упрощенное, конечно) дано ближе к концу статьи. На самом деле, поскольку есть полная модель процессора в Verilog (благодаря реверсу, который Вячеслав проделал), можно пройтись по всем деталям.
khim
С этого помента поподробнее — о каком реверсе идёт речь? Насколько я знаю копировали КР580ВМ80А, калькуляторы (МК-54, МК-61), а вот с БК вроде на этом уровне никто не работал… или работал?
Wesha
Реверсом занимается 1801BM1, см. https://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
khim
Ого. Круто. Интересно — никто не пытался эмулятор поверх этого устроить? Слишком медленно получается или «не особо и нужно»?
Любители калькуляторов таки создали себе эмулятор с ЕГГОГами и «оборотнями», а БК пока отстаёт…
smaslovski Автор
На моей памяти, на форуме ZX-PK.ru обсуждалась такая возможность. По-моему, как раз в теме, на которую сослался Wesha.
Wesha
Кстати, о птицах: я буквально недавно получил обратно свои БКшные кассеты тогдашних лет, написал (на Ruby) с ленты, и сейчас потихоньку считываю свою коллекцию с лент.