Комментарии 79
Реверсом занимается 1801BM1, см. https://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
Любители калькуляторов таки создали себе эмулятор с ЕГГОГами и «оборотнями», а БК пока отстаёт…
Кстати, о птицах: я буквально недавно получил обратно свои БКшные кассеты тогдашних лет, написал (на Ruby) с ленты, и сейчас потихоньку считываю свою коллекцию с лент.
Эти #$@ (форумные администраторы) отключили регистрацию. Оставил заявку неделю назад — молчание. (А мне есть чего сказать: например, в описании протокола по этой ссылке есть фактические ошибки.
Пока что размещаю на гитхабе.
1. длина конечного тона у меня 128, а у Вас 256,
2. скважность нулевого импульса у Вас 1:1, а у меня 2: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 страниц :)
Кстати, попутно в недрах интернета я обнаружили "исходники Дябина", которые на самом деле не являются тем, что реально залито в БК (то, что реально залито — это декомпиляция Фролкина с комментарями Зальцмана, могу залить фотографии распечаток — руки пока не дошли полностью распознать их в текст).
после контрольной суммы идёт ещё один маркер, точно такой же, как и перед ней.
Тут у меня описка — следует читать "после заголовка идёт ещё один маркер, точно такой же, как и перед ним" (пока до меня дошло, Хабр уже закрыл редактирование).
у Вас нарисовано, что синхробит идёт перед импульсом данных. На самом деле он идёт послеПожалуй, Вы правы! Описанный мной формат будет читаться (я же проверял), но формально он описан со сдвигом на один синхроимпульс. Поправлю при случае.
У Вас в конце файла идёт «pilotone(128)», а на самом деле идёт там должно бытьНе должно, потому я описываю не как ПЗУ выводит звук, а как я его готовлю для чтения. Действительно, можно сократить ещё больше, но какой-то из копировальщиков обломался на коротком пилотоне, поэтому я оставил такой.
Тьфу ты, тут одну минуточку, параграф, помеченный 2) выше вычеркните, я там спросонья всё перепутал, сейчас напишу по новой. Но смысл в том, что один маркер Вы таки забыли.
Не должно, потому я описываю не как ПЗУ выводит звук, а как я его готовлю для чтения.
А я описываю то, что человек реально встретит на ленте; а как он захочет это обрабатывать — это уже дело пятнадцатое: например, всё, что после контрольной суммы, вполне можно смело скатать в трубочку и засунуть, но на ленте-то оно есть!
Во-первых, это зависит от Вашей задачи: если только прочитать, то таки да, а вот если правдоподбно писать...
Во-вторых, повторюсь, если Ваша задача — максимально всё упростить, то, например, маркер конца файла Вам совершенно не упёрся: чтение (насколько я помню) завершается на КС, и дальше никто ничего не проверяет.
А, вот: параграф 2) следует читать:
2) у Вас нарисовано, что после стартового 4096-импульсного пилотона с конечной единицей сразу идёт заголовок. Это неправильно: перед заголовком идёт маркерная последовательность — точно такая же, как перед основными данными файла. (Причина — в том, что 20 байт заголовка выводит та же самая подпрограмма, которая потом выводит тело файла — то есть идут вызовы CALL write_array(HEADER); CALL write_array(BODY);.)
В общем, смотрите мой гитхаб по ссылке выше, там код правильный :)
Спасибо за исправления. На данный момент я почти доковырял формат HELP7, читалка будет на гитхабе по тому же адресу.
Так лежит уже давно — https://github.com/weshatheleopard/bktools — я уже почти все свои кассеты прочитал. Сейчас раздумываю, нужна ли писалка (ну чисто для коллекции).
Теперь без асбеста с дизассемблером. Всё там же.
Добавил парсинг файлов FOCAL. На очереди Бейсик.
Вы бы присоединялись к Телеграм-чату, там народ любит такие новости! t.me/bk0010_11m
А что он делает (в документации не написано)? Переводит в текстовый файл?
Да (ну, в текстовую строку, которую записать в файл сумеет любой джун).
Вы бы присоединялись к Телеграм-чату, там народ любит такие новости! t.me/bk0010_11m
Когда тг перестанет требовать телефон при регистрации. "Ну нет у меня телевизора, НЕТУ!!!" ©
Кстати, забыл поинтересоваться — какого Цоя этот канал недоступен для чтения через веб-интерфейс? Вы что там, в жо наркотики продаёте?
Такой порядок команд возник вследствие оптимизации программы. Раньше никто настолько не заморачивался, чтобы уложить демку в 256 байт, да ещё добиться максимальной скорости.
Увлекательно и захватывающе. Как детектив. Правда, я не совсем понял. Этот баг присутствует и в оригинальном процессоре, или только в отечественном клоне?
Просто всегда думал, что это уже более новое изобретение — распаралеливание процессоров.
А там не предусматривалось никакого распареллеливания. Симметричная мультипроцессорность, это уже более современная фишка. Тогда центральный процессор был всего один, но могли быть периферийные, которые решали другие задачи. Например, в дальней родственнице БК-0010, школьной Электронике УКНЦ как раз стоит два таких процессора. Один центральный, другой управляет периферией.
А могли быть и разные процессоры, например, тот же i8086 умел работать в связке с двумя другими, арифметическим i8087 и процессором ввода-вывода i8089. Последний, впрочем, не попал в конструкцию IBM PC, потому не так известен, как первые два.
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
Для 8089 нужен арбитр шины (8289)
В IBM PC же есть арбитр шины :) Там 8088 работает в максимальном режиме, чтобы была возможность установки сопра.
Для ограниченных целей (сопряжение 16-битного чипа, взятого из комплекта 8085 с 20-битной адресной шиной).
Не совсем понял, что вы имеете в виду. Арбитр 8289 служит для управления захватом шины между двумя процессорами. Причем оба они, 8087 и 8088/8086, имеют ту же ширину шины, что и компьютер, 20 бит адреса, 8 или 16 бит данных.
Почему на Вашем телеграм-канале не работает превью через /s/? А то скачивать клиента не хочется.
Можно зайти через веб клиент: https://web.telegram.org/
что показало, что я на верном пути. Осталось сузить «круг подозреваемых».
на этом моменте я ощутил накал страстей
Надеюсь, было интересно.
Да, отличный тех.детектив, спасибо!
Когда я писал игры для ПК-01 Львов, то там тоже нашел баг связанный со звуком и сменой палитры — можно было сопровождать звуковые эффекты визуальными.
К сожалению у меня был монохромный дисплей. На цветном это выглядело отвратно.
Уверен, что в хоть одной игре на БКшке есть код, который эксплуатирует этот баг.
Кстати, о птицах. Я в свое время открыл такую багофичу: между сигналом, что на клавиатуре что-то нажато (рязряд в ячейке 177716) и сигналом, что код клавиши готов к считыванию (разряд в ячейке 177660) проходило некоторое время (что-то порядка 50 циклов SOB), причём это время было с точностью до пары циклов стабильным для данного конкретного экземпляра БК, но плавало между экземплярами (то есть потенциально можно было написать привязку программы к более-менее конкретному экземляру). Объяснялось это тем, что в цепи формирования разряда в 177716 стоял конденсатор, параметры которого немного "плавали" от экземпляра к экземпляру. Тогда я эту информацию засекретил, чтобы не позволить людям запилить ещё одну защиту — но факс остаётся факсом :)
Что интересно, если не путаю, то на таком проце (или ВМ2?) делался компьютер управления ракетным огнем для Курска — баллистика, вот это все. Кажется модернизация под новое вооружение. Дюжина параллельных одноплатных машин в шкафу, в виде гроба в рост человека (буквально — граненые пирамидальные крышки-дверцы).
Камень тот же, но в керамике. ДВК ж были по сути.
Что то отбирали (очень много брака), но все равно, плат столько для дубляжа, они часто сбоили в работе, и сделать с этим ничего было нельзя. Помимо того, что работали минимум три (4?) параллельно по требованиям надежности вычислений. Да 4, и 16 плат.
Ну, строго говоря, в процессоре тоже. Спецификации-то не соответствует, в отличие от эмуляторов.
Но мы знаем, что теперь это недокументированная фича и что все эмуляторы надо исправлять.
Именно поэтому, вставка NOP восстанавливает правильное поведение.
Уважаемый автор! Я тут в процессе разработки своего дизассемблера вспомнил такой момент про флаги, а именно — давайте посмотрим на табличку:
команда / восьмеричный код / двоичный код / примечание
----------------
CLC / 000241 / 0 000 000 010 100 001 / очистить флаг C
CLV / 000242 / 0 000 000 010 100 010 / очистить флаг V
CLZ / 000244 / 0 000 000 010 100 100 / очистить флаг Z
CLN / 000250 / 0 000 000 010 101 000 / очистить флаг N
CCC / 000257 / 0 000 000 010 101 111 / очистить все флаги
----------------
SEC / 000261 / 0 000 000 010 110 001 / установить флаг C
SEV / 000262 / 0 000 000 010 110 010 / установить флаг V
SEZ / 000264 / 0 000 000 010 110 100 / установить флаг Z
SEN / 000270 / 0 000 000 010 111 000 / установить флаг N
SCC / 000277 / 0 000 000 010 111 111 / установить все флагиПосле чего немедленно становится очевидным, что на самом деле команда — одна, c кодом 0 000 000 010 1XN ZCV, где X — признак "устанавливать или сбрасывать биты по маске", а NZVC — маска, определяющая, какие именно биты нужно изменить (установить или сбросить). И действительно, коды команд, для которых в ассемблерах не предусмотрено мнемоник — например, 000272, изменяют несколько бит одновременно. Кроме того, очевидно, что где-то в процессоре есть скрытый регистр, в котором биты состояния хранятся — потому что при исполнении этих команд надо эти биты достать, BIC или BIS их по маске, и записать обратно.
Так к чему этот я? Да к тому, что код команды NOP — 000240, то есть 0 000 000 010 100 000, маска NZVC — нулевая, и соответственно никакие биты изменяться не должны! Однако вытаскивание их из этого скрытого регистра и запись их обратно (в неизменном состоянии!) всё равно имеет место быть! Что и объясняет наблюдаемое Вами поведение с "самоисправлением" битов при добавлении NOP.
Довеском — существует и вторая, недокументированная команда NOP, с кодом 000260 :) Схема та же: всё по той же нулевой маске не сбрасываем, а устанавливаем биты, ровно с тем же эффектом.
Вдогон: сегодня на сон грядущий перечитывал PDP-11 Handbook, именно так эти команды и описаны на стр. 92.
О том, как найти ошибку в микропроцессоре, выпущенном тридцать пять лет назад