Программирование под БК 0010 в 2019-ом году

  • Tutorial

Зачем?


Если Вы — энтузиаст ретро-компьютеров, то мотивационную речь можете смело пропустить и перейти к следующему разделу.

Весь август 2018-го года я и мой 13-летний сын Ivanq потратили на написание демки Good Apple. На фестивале Chaos Constructions наша работа заняла второе место, за что мы получили денежный приз 35 тысяч рублей, который честно поделили поровну. Для ребёнка это неплохой доход, хотя, созданием сайтов он зарабатывал столько же за меньшее время. Очевидно, и я мог потратить своё время с большей экономической выгодой… Но только не август! Надо же когда-то отдыхать от работы. Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.

Good Apple demo by SandS

Материальное вознаграждение, конечно, не служит мотивацией, но закрепляет положительные эмоции. Удивительно, что демка для забытого советского компьютера собрала тысячи просмотров на youtube и попала в плейлист с почти сотней тысяч просмотров. Но ещё более удивительно, что в 2018-ом году за неё вручают денежный приз! Возможно, сама невероятность происходящего и порождает такой эмоциональный подъём.

Однако, есть кое-что более важное.

При создании “Good Apple” нам пришлось работать с реальным железом, так как мы использовали возможности компьютера, которые эмуляторы воспроизводят не совсем корректно. Прежде всего, хотелось добиться одинаково устойчивой работы с жёсткими дисками формата IDE и с их современными заменителями в виде Compact Flash.

Именно на этом проекте мой 13-летний сын обрёл бесценный опыт промышленной разработки. Дефектное железо. Хорошее железо, которое ведёт себя не так, как описано в документации. Документация, которая составлена с ошибками. Отсутствие документации по ряду вопросов. Написание собственных тестов для выявления проблем с железом. Выходящие сроки. Тестирование на разных машинах и конфигурациях. Написание собственного кросс-ассемблера (когда стало понятно, что существующие решения тормозят процесс разработки). И, наконец, после короткого празднования успеха — обязательный выпуск финальной версии, исправляющей ряд багов.

На первый взгляд кажется, что подобный опыт можно было получить и с каким-нибудь современным Arduino. По факту же, нам пришлось погрузиться в самые дебри схемотехники. Мы вычисляли число тактов, за которое исполняются инструкции. В разных типах памяти это время отличается. Контроллер памяти и процессор работают на разных частотах, поэтому одинаковые команды могут выполняться разное время даже в памяти одного типа. Длительность исполнения подпрограммы не равна сумме длительностей команд этой подпрограммы. Нам пришлось писать собственные инструменты для тестирования и оптимизации кода на реальном железе.

Утилита для замера скорости выполнения фрагмента кода

Закончилось тем, что сын изучал схемотехнику БК 0011 (какие фронты сигналов куда приходят, когда срабатывает RPLY и т.д. — я в этом уже ничего не понимаю). Так он пришёл к идее сделать собственный эмулятор БК, совместимый с реальным железом с точностью до такта, и даже написал ядро… Впрочем, это уже другая история.

Итого, за месяц — от изучения ассемблера до создания собственных средств разработки, от хардварных тестов до готового мультимедийного произведения. Всё это было бы невозможно без главного: Планирование. Пожалуй, наиболее ценный вынесенный урок. Берёшь невозможную задачу. Понимаешь, что столкнёшься с непреодолимыми сложностями. Планируешь. Делаешь. Результат поражает всех настолько, что даже знатоки обвиняют в читерстве (“вы разогнали процессор!”).

Почему не ZX Spectrum?


Odnazhdy demo by Excess team

Опять начну со странного: с финансов. Судя по объявлениям на Avito, в среднем БК 0010 стоит в несколько раз дороже, чем ZX Spectrum. Понятно, что за редкий экземпляр родного Спектрума в идеальном состоянии запросят круглую сумму. Но БК 0011м в полной комплектации всё равно выйдет дороже. Если вообще удастся найти. Цены говорят сами за себя: коллекционная значимость БК 0010 выше. А БК 0011м – и подавно. Иметь такой компьютер дома очень приятно.

Второй аргумент – 16-бит. В БК 0010 нет ничего 8-разрядного. Процессор даже не умеет складывать 8-битные числа, у него нет команды ADDB. 16-битность во всём. Причиной тому – архитектура DEC PDP-11. Многие называют систему команд процессора PDP-11 самой удачной и самой удобной из когда-либо созданных. Конечно, найдутся желающие поспорить с этим утверждением. Но вот один факт: на прошедшем в Яндексе фестивале “Демодуляция” три семинара были посвящёны архитектурам процессоров, и два из них – о PDP-11. Это, действительно, легенда, важнейшая веха в истории вычислительной техники, которая до сих пор продолжает будоражить умы энтузиастов. БК 0010 даёт возможность прикоснуться к этой легенде. И не просто прикоснуться, а разобраться в ней до мельчайших деталей, прочувствовать всю красоту и изящество DEC’овского ассемблера: абсолютно равноправные регистры, восемь методов адресации, линейная память – красота!

Третий довод: для ZX Spectrum написано множество демок. Для БК 0010 — меньше полусотни, считая мелкие 256-байтные и 4-килобайтные. Место на демосцене почти свободно, есть где себя проявить даже начинающему!

И последнее соображение, чисто субъективное. Я наблюдаю за российской демосценой с 1994-го года. Тусовка спектрумистов представляется мне, к сожалению, более токсичной и враждебной. Конечно, есть и прекрасные дружелюбные люди! Испытываю огромное уважение к ним и к их творчеству. Но в целом – вероятно из-за своей массовости – спектрумовская сцена наполнилась конфликтами, выяснением отношений и даже интригами типа name-voting (когда на конкурсах голосуют только за “своих”). В то время как на маленькой БК-шной сцене не ставят вопросов типа “кто круче” и рады каждому новому участнику. Повторю: это моё сугубо личное впечатление, которое вы можете проигнорировать.

Реальное железо


Прошло 20 лет, прежде чем я вернулся к написанию программ для БК. За эти 20 лет многое изменилось. Лично для меня главный сдвиг произошёл в сознании: “Think Different”. Именно этот слоган помещён в заключительные титры нашей демки “Good Apple”.

Раньше мы по 5 минут грузили игры с магнитофона. Затем появились контроллеры дисководов. За ними – жёсткие диски. Потом новодельные реплики контроллеров с Compact Flash на борту. Теперь на ретро-сцене принято эмулировать дисководы флешками… Но постойте, в 2019-ом году у нас есть высококачественный портативный источник звука – iPhone. Так давайте возьмём стандартный аудио-шнур DIN-5 — mini jack (даже перепаивать не придётся) и будем грузить БК с iPhone на высокой скорости.

Я прошёлся трассировкой по ПЗУ, выявил как можно слегка перехитрить алгоритм загрузки с магнитофона и заставить БК читать данные в 4 раза быстрее.

Следующим этапом стало написание микро-загрузчика, который считывал данные в специально разработанном турбо-формате. И загрузчик, и данные помещались друг за другом в единый WAV-файл (конвертер написал Ленар Закиров). БК 0010 считывает и автоматически запускает микро-загрузчик, а тот, в свою очередь, читает остаток данных из файла. Частоты в турбо-формате доходят до 22 КГц, поэтому требования к качеству источника звука высоки. iPhone справляется. Хороший музыкальный плеер тем более. Звуковая карта компьютера тоже.

Затем настала очередь кросс-ассемблера. В него были добавлены опции сохранения программы в WAV (как в стандартном, так и в турбо-формате). Более того, кросс-ассемблер умеет сразу проигрывать WAV через звуковую карту. Только представьте, насколько ускорилась разработка! Не нужно возиться с записью образа диска на CF-карту после каждой компиляции. Просто вносишь изменения в код, нажимаешь “Build”, звук льётся в БК и через несколько секунд программа уже запущена на реальном железе. Для приёма звука в стандартном формате достаточно нажать на БК 0011 клавиши L (Load) и Enter (загружать первую встреченную программу). Для передачи звука в турбо-формате нужно предварительно запустить микро-загрузчик (у меня он автоматически запускается с жёсткого диска при включении БК; в любой момент можно выйти в систему, нажав клавишу СТОП).

Загрузка программ в БК 0011м с компьютера

Подключить БК к телевизору проще всего в монохромном режиме, в обычный композитный AV-вход. Нужно спаять кабель с “тюльпаном” на одном конце и DIN-5 на другом. Монохромный сигнал выходит с 4-го контакта DIN-5 разъёма БК, обозначенного “ТВ”. Земле традиционно соответствует 2-ой контакт DIN-5.

Лично я поклонник монохромных ЭЛТ дисплеев – они обеспчивают чёткость изображения, недостижимую на цветных мониторах с их апертурной решёткой. Но большинство игр и все демки предпочтительней смотреть в цвете. Для этого используют “ТВЦ” выход БК и подключение к телевизору через RGB SCART. Контакты 3, 4, 5 на DIN-5 – соответственно красный, синий, зелёный. Контакт 1 – синхронизация. Контакт 2 – земля. В случае подключения к ЖК-телевизору полезно подать +5 вольт на 16-ый контакт SCART (через резистор 200 Ом или около того). 5 вольт обычно берут с соседнего разъёма “ТВ” (контакт 1).

Можно воспользоваться конвертером SCART-HDMI. Сразу предупрежу, что БК выводит изображение с частотой не 50 кадров в секунду, а 48.83, поэтому вместо плавного скроллинга на ЖК-мониторах будет заметно периодическое подёргивание. Я решил эту проблему заменой 12-мегагерцового кварцевого резонатора БК на 12.288 МГц. Впрочем, подёргивание было заметно только в некоторых демках. Большинство программ на БК не использует синхронизацию с кадровой частотой.

Почему не довольствоваться эмулятором, для чего вообще может понадобиться реальный компьютер? Я обнаружил четыре вещи, которые плохо эмулируются:

  1. Поведение динамика на высоких частотах.
  2. Синхронизация изображения и палитр с ходом луча.
  3. Точное время исполнения команд (важно для музыки через Covox).
  4. Работа с жёсткими дисками IDE на высоких скоростях.

Если вы не планируете делать ничего из вышеперечисленного, вам вполне хватит эмулятора.

Эмуляция


На MacOS я использую эмулятор BK2010. Он не очень точный, но для большинства задач подходит.

Самый продвинутый на сегодняшний день эмулятор GID работает под Windows. Он также запускается в CrossOver под MacOS и в Wine под Linux. В эмуляторе хороший отладчик, просмотрщик страниц памяти и тому подобное.

Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher. Но чаще передаю данные по звуковому каналу.

Средства разработки


Компиляция из Sublime Text кросс-ассемблером PDPy11

Ребята из демогруппы Excess Team подсказали кросс-ассемблер Алексея Морозова. Сперва мы пользовались им, но вскоре Ivanq написал свой собственный – мультиплатформенный, на Python. Он работает медленней, зато гораздо богаче функционально. Тут и поддержка многофайловых проектов, и сложные арифметические выражения, типы данных double word, интеграция с Sublime Text и расширенная поддержка ошибок компиляции, сохранение результата в формате звукового файла, компиляция не только под БК, но и под УКНЦ, и многое другое. Обо всём этом можно почитать в официальной документации.

Кросс-ассемблер называется PDPy11.

Некоторые из ветеранов жалуются, что в PDPy11 не хватает макросов классического DEC’овского макро-ассемблера (Macro-11). Макро-ассемблер – это в некотором смысле другой язык. Он, вероятно, хорош для написания системных программ, но серьёзные игры и демки для БК писали, насколько я знаю, на обычном классическом ассемблере. Иронично: для исходников БК-шных программ принято использовать расширение фала .mac (от “макро”) даже в тех ассемблерах, которые не поддерживают макросы. В любом случае, возможностей PDPy11 хватает для написания программ любого уровня сложности.

Отладчик встроен в эмулятор GID. Он позволяет задать адреса точек останова, в любой момент прерывать или продолжать исполнение программы, смотреть содержимое регистров и памяти, выполнять программу пошагово, изменять содержимое памяти и т.д.

Для конвертации графики в формат БК мы написали онлайн-конвертер. Разрешение БК – 256x256 точек в цветном режиме или 512x256 в монохромном. Картинки большего размера лучше не подавать на вход конвертеру.

Документация


Прекрасное пособие по программированию на ассемблере написал Юрий Зальцман. Об отличиях БК 0011м от БК 0010 написано здесь. Существовала ещё модель БК 0011 (без “м”), но её быстро сняли с производства, признав неудачной.

Несмотря на то, что БК 0011м обладает большими возможностями (цветовые палитры, дополнительные страницы памяти), поначалу я советую программировать под БК 0010 — эта модель проще и понятней. Любая программа, корректно написанная для БК 0010, запустится и на БК 0011м.

Устройство процессора и набор инструкций хорошо описаны в Wikipedia.

Для самых отважных — программирование в кодах.

Hello, world!


Область экранной памяти в БК 0010 начинается с адреса 40000 (левый верхний угол) и заканчивается адресом 77777 (правый нижний угол экрана). Как нетрудно догадаться, в архитектуре PDP-11 используют 8-ричную систему счисления. Но кросс-ассемблер PDPy11 позволяет, конечно, записывать числа также в двоичной, десятичной, шестнадцатиричной системе – поступайте как вам привычней.

Чтобы поставить точку на экране, нужно записать какое-нибудь число в область экранной памяти. Аргументы в DEC’овском ассемблере записываются слева направо: источник, затем приёмник Например:

MOV #100000,@#60040 ; поставить точку в середину экрана

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

   MOV #40000,R1 ; начальный адрес
   MOV #20000,R0 ; счётчик цикла
1: CLR (R1)+ ; очищаем слово по адресу, после увеличиваем R1
   SOB R0,1 ; оператор цикла

Косвенная адресация (R1) использует регистр R1 как указатель адреса. Память в БК адресуется побайтно, но инструкция CLR очищает сразу два соседних байта: сначала 40000 и 40001, на следующем шаге цикла 40002 и 40003, и так далее. Запись (R1)+ означает, что после использования аргумента нужно его увеличить. В данном случае на 2, потому что команда обрабатывает 2 байта. Счётчиком цикла может быть любой регистр. SOB вычитает единицу из регистра и переходит на метку 1. Локальные метки обозначаются цифрами и двоеточием, их область видимости между двумя глобальными метками. Глобальные метки должны начинаться с буквы и также заканчиваться двоеточием.

Инструкцию CLR можно заставить работать с байтами, дописав букву “B”. Тогда CLRB (R1)+ будет увеличивать регистр R1 уже не на 2, а на 1.

   MOV #40000,R1
   MOV R1,R0 ; теперь счётчик цикла должен быть вдвое больше
1: CLRB (R1)+
   SOB R0,1

Можно сделать то же самое короче. Очищаем экран снизу вверх при помощи индексного метода адресации:

   MOV #40000,R0
1: CLRB 37777(R0) ; по сути это (37777+R0)
   SOB R0,1

Если нужна высокая скорость, то лучше очищать память не побайтно, а сразу словами. Получится вдвое быстрее. Но можно ускориться сверх того: по какой-то причине команда CLR работает медленней, чем MOV. Поэтому:

   CLR R2 ; записываем ноль в регистр R2
   MOV #40000,R1 ; начальный адрес
   MOV #20000,R0 ; счётчик цикла
1: MOV R2,(R1)+ ; очищаем слово по адресу, после увеличиваем R1
   SOB R0,1 ; оператор цикла

Теперь, выбрав один из четырёх способов очистки экрана, можно уже ставить точки. В цветном режиме каждой точке соответствуют два бита. В монохромном — один бит. Программного переключения режимов экрана у БК нет. К какому выходу подключил монитор, такое изображение и получил.
Для наглядности запишем цвета точек в двоичной системе счисления:

   MOVB #0b00001100,@#50010
   MOVB #0b00110000,@#50112
   MOVB #0b11000000,@#50313

Цвета в каждой паре битов кодируются так: если установлен только чётный бит — зелёная точка, только нечётный бит — синяя, установлены оба бита — красная, сброшены оба бита — чёрная. Ну а монохромный монитор показывает каждый бит как отдельную точку.
Команда MOVB записывает в экранную память сразу 4 точки, а команда MOV — 8 точек. Если вы не хотите затрагивать соседние точки, используйте команду BIC (Bit Clear) и BIS (Bit Set), например:

   BICB #0b00001100,@#50112 ; стереть точку
   BISB #0b00000100,@#50112 ; поставить синюю точку

Интересный момент: в тексте мы записываем младшие биты правее старших. А на экране наоборот: точки, соответствующие младшим битам, появляются левее.
Вот, собственно, и всё об устройстве экранной памяти БК 0010.

А что же на счёт вывода текста?

      MOV #Text,R1 ; адрес текстовой строки
      EMT 20 ; вызов зашитой в ПЗУ процедуры печати текста 
      HALT   ; останов программы
Text: .ASCII “Hello, World!”
      .BYTE 0 ; строка должна заканчивать нулевым байтом

Покажите исходники!


Road2CAFe 256 bytes intro by Excess team

Легче всего будет начать, посмотрев исходники готовых демок:

In Your Space — демо для Covox, исходники в архиве.
Good Apple — исходники на GitLab (сложный многофайловый проект).
EIS — эмулятор инструкций расширенной арифметики с исходниками.
Исходники трёх 256-байтных демок.
В 28-ом выпуске журнала Downgrade большая статья про эволюцию алгоритмов трекерной музыки на БК 0010, с фрагментами программ и подробными разъяснениями. Ностальгический рассказ о ранней демосцене в придачу.

Когда приступать?


Прямо сейчас. Через 4 недели в Казани состоится демопати CAFe 2019. В программе фестиваля есть конкурс БК 0010 — 512 байт. В такой размер уместится от 85 до 256 инструкций – идеально для начинающих. Двух недель вам хватит на то, чтобы разобраться с инструментарием и написать первую простенькую демку. После этого ещё останется неделя-полторы на написание второй, более серьёзной работы.

Дерзайте, вы можете! Телеграм-чат, форум на zx-pk — везде вам помогут. присылайте работы на конкурс, а лучше ещё и приезжайте сами. Scene is alive!
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 85

    +1
    Очень рад слышать, что сообщество БК 0010 живо и активно! С БК 0010 начался мой путь в ИТ. Помню как я ребенком простаивал часы в маленьком игровом салоне с компьютерами БК 00100.

    У меня вопрос насчет эмуляторов. Есть ли сейчас активные проекты по разработке эмуляторов? Нет ли акивных проектов разработки эмуляторов под web assembly?
      0
      Исходники эмулятора Gid открыты, в них иногда вносят изменения.
      Есть ещё открытый проект хардварного эмулятора на микроконтроллере: zx-pk.ru/threads/30072-emulyator-bk-0011m-na-esp8266.html
      WebAssembly – хорошая идея, я не слышал об эмуляторе БК, но было бы здорово. Если задумаете взяться, я с удовольствием поучаствую.
        +2
        Собирал свой эмулятор (BKBTL) под WASM, скорее чтобы попробовать чем как реально широко используемый проект — nzeemin.github.io/bkbtl-wasm/index.html
        Ну и свой основной эмулятор (UKNCBTL) тоже собирал под WASM — nzeemin.github.io/ukncbtl-wasm/index.html
          +1
          Огромное спасибо за проект! Собрал проект из репозитория, вернулся в детство.

          Собрал под Windows 10, Visual Studio Community 2019. Единственно, в файле Board.cpp в строчке 169 добавил проверку:
          bool CMotherboard::IsFloppyEngineOn() const
          {
          	if (m_pFloppyCtl == NULL)
          		return false;
          
          	return m_pFloppyCtl->IsEngineOn();
          }
          
            0
            Да, тоже на это наткнулся на днях, поправлю. Спасибо!
          0
          Тоже делал для себя (лет 15-ть назад) эмулятор системы команд PDP-11 :)
          и под ним даже отладил Форт систему уже для реального железа функционирующего в рамках некоторой самопальной IDE. (сам эмулируемый процессор поддерживал передачу по COM порту и поэтому его можно было соединить через виртуальный COM порт на этом же компьютере с IDE)

          P.S. Программирование, в пределах этого инструментария, было на «высокоуровневом» ассемблере (if, else, while ...) в рамках этой IDE с расширенными псевдокомандами ассемблера. IDE тоже была на диалекте Форта (Win32Forth), а эмулируемый процессор на Форт системе (SPF4)
          До сих пор есть желание сделать эмулятор на каком нибудь контроллере (типа STM32)

          А, для того же ZX-Spectrum делал прошивку ПЗУ с русификацией и турбированием.
          а к редактору TLW подключил 64-е клавишную клавиатуру.
          Ну и где то остались дискетки от ZX-Spectrum с каким то своим ассемблерным программированием и играми (может уже и не читаются после такого времени ) :)
            +3

            Есть еще Open-Source эмулятор для Android — BkEmu. Разрабатываю я его не то чтобы очень активно, но баги фиксятся и даже иногда добавляются новые фичи. Люди запускали его даже на видеотелефоне. :)

            +5
            Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.
            Программировать во время отпуска, это не роскошь, а скорее профдеформация. На море съездить, в поход, сменить род деятельности, банально отоспаться… но нет. Как вы не выгораете? И не боитесь ли выгореть?
              +3
              Просто моя работа не связана напрямую с программированием.
                +3

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

                +1
                Если я правильно понял просмотренные по диагонали исходники, то вся программа состоит в чтении информации с диска и выдачи ее на экран. При всем уважении к труду 13-летнего программиста — это НЕ демо-сцена.
                  +3
                  Ну тогда и это не демосцена: www.pouet.net/prod.php?which=63591
                  И демки с музыкой в MP3-формате — не демосцена.
                    0
                    Человек говорит про твою работу, а ты ссылаешься на чужую, в подтверждении того, что твоя — демо. Немного странно. Да, по ссылке — тоже не демо. Я бы назвал это «демонстрация технологии». При всём уважении — наличия крутого кода совершенно недостаточно, чтобы считать работу «демо». Вдобавок, с полностью заимствованным видеорядом.
                    Что касается демок с музыкой в mp3 формате, то всё зависит от демки. Само наличие там mp3 музыки ни о чём не говорит.
                      +1
                      Говоря о моей работе, человек сам ссылается на другие работы, ибо определять что есть демо, а что нет, можно только при наличии некоторого множества работ и устоявшегося их названия. Поэтому мой аргумент — отсылка к другим общепризнанным на демосцене работам. Логично же. Это первое.
                      Второе: видеоряд не «полностью заимствован». Здесь можно увидеть как я рисовал 3D-вставки: twitter.com/Manwe_sns/status/1177540242125066240
                      Третье: когда в демках начали использовать MP3, это было встречено негативно. Потом ещё на Амиге начали играть неупакованную музыку прямо с диска — это вообще было фу. Я и сам так считал, и отчасти до сих пор придерживаюсь такого мнения. В идеале всё должно быть в риалтайме. Но демо-сообщество в целом переварило и смирилось с использованием потоковой музыки в демо. У нас в «Good Apple» тоже неупакованная потоковая музыка. Будем за это ругать или как? Просто чтобы я смог понять объективность подхода.
                      Ну и четвёртое: да, это «демонстрация технологии». Никто же не обманывает, не говорит, что силуэты рендерятся в 3D в реальном времени. Была изобретена технология упаковки и скоростного вывода видео. Идею бесшовного вывода звука ещё за полгода до этого придумали Excess Team. Всё это в сочетании, а также титры с многоцветным трюком — некий законченный продукт. Как его назвать, если не «демо»?
                      На БК словом «демо» называли вообще всё что попало: например, многочисленные подборки музыки под пищалку. Или взять наш прошлогодний релиз «In Your Space» — для БК-сцены это вполне «демо», хотя там даже на экране ничего не изменяется во время проигрывания музыки.
                      Мне кажется, надо просто смотреть контекст: в каком состоянии находится демосцена на той или иной платформе. Где-то помигать курсором — уже демо. А на другой платформе это пффф.
                    +7
                    Так это же Bad Apple. С ним как раз и связан challenge — заставить играть real-time видео железо, про которое все думают, что оно на такое в прицнипе не способно.

                    Похожая история была с 8088 MPH (1, 2), когда чуваки со стандартной CGA-карточки смогли вывести 1024 цвета. Сами эффекты там более чем стандартные, а основная фишка именно в выжимании из железа возможностей, для которых оно изначально вообще не предназначено.
                      0
                      Получается, что если бы в 1985 году были жёсткие диски такого объёма и с такой скоростью считывания, то можно было бы проигрывать в реальном времени аудио+видео (пусть и с 1 битом на пиксель) на железе того времени. Не только БК, к другому железу демосценщики бы тоже нашли подход.
                        0
                        ну собственно довольно быстрый скроллинг экрана на БК показывал, что как минимум видеопамять способна отображать несколько кадров в секунду
                          0
                          На сколько я помню, видеопамять — это кольцевой буфер, скролл «аппаратный», т.е. задается смещение относительно начала видеопамяти и перерисовывать нужно всего одну строку изображения.
                    +3
                    Все: невозможно услышать изображение
                    КДПВ:
                      +1

                      Эх были же времена. Помню, как мне нравился ассемблер PDP-11, с его выразительной системой команд. Когда перешел на PC и начал профессионально и заниматься программированием, ностальгия стала такой сильной, что даже пришлось написать эмулятор. Система команд PDP-11 оказалась настолько простой и логичной что у меня сходу запустился монитор и даже некоторые программы, хотя я писал по памяти, не заглядывая в документацию. БЕЙСИК все же не заработал, так как о использовал несколько хитрых команд в реализации которых я допустил ошибки, а о существовании парочки я даже не подозревал. Пришлось тогда искать материалы, того же Юрия Зальцмана и т.д. Удивительно что спустя 20 лет проект всем еще жив и приносит пользу. Спасибо большое тому замечательному человеку, который поддерживает и развивает его сейчас.

                      … прочувствовать всю красоту и изящество DEC’овского ассемблера: абсолютно равноправные регистры, восемь методов адресации, линейная память – красота!
                      Небольшое уточнение: все почти так, но некоторые регистры все же были "равноправнее" других. R6: стек RS и R7: счетчик команд PC, всеже неявно использовались некоторыми специальными командами и по другому интерпретировались в автоинкремендах и автодекрементах. Так MOVB #377, -(SP) сдвигает адрес на 2 (слово), а не на байт, как можно было бы ожидать с другими регистрами.
                      Если нужна высокая скорость, то лучше очищать память не побайтно, а сразу словами. Получится вдвое быстрее. Но можно ускориться сверх того: по какой-то причине команда CLR работает медленней, чем MOV. Поэтому:
                      CLR(Rd), сначала загружала значение из указанного адреса в R0, потом обнуляла его, а потом уже загружала обратно. MOV Rs, (Rd) не делала лишней загрузки из памяти. Я точно не помню уже зачем это было нужно. По-моему, CLR необходимо было выставить флаги состояние процессора NZCV на основании предыдущего значения операнда.
                        0
                        Под равноправием я имел в виду использование любых регистров в качестве аргументов любых команд. Например, никто не запрещает использовать регистр стека (SP) или счётчик команд (PC) в качестве индекса цикла или в качестве приёмника слова состояния процессора (PSW). Правда, что после этого будет — берегись! :)
                          0
                          Ага, мое любимое: MOV --(PC), --(PC)
                            0

                            Мне больше нравился такой код "защиты от стопа":
                            SUB (PC),(SP)<br> RTI
                            Вроде ничего не напутал. Он одной командой вычитал 2 (т.к в момент выполнения PC указывает на адрес RTI — opcode которой как раз двойка) из PC сохраненного в стеке, который тут же восстанавливался при возврате с помощью RTI, что приводило к выполнению последней прерванной команды.

                              +1
                              Смутно помнится что была команда, которая копировала себя адресом выше и передавала управление на этот адрес. Занеся и запустив команду по младшему адресу получали зависший комп с полосатым экраном. С некоторой натяжкой можно считать самым коротким «червём» :) Как сказано неоднократно выше, это было возможно благодаря развитой и разнообразной системе адресации
                                0
                                MOV --(PC), --(PC) — вот это и есть этот червь :)
                            0
                            Ортогональность, если по-нормальному.
                            +1
                            Чем мне лично нравились PDP/LSI 11в отношении управления оборудованием — что можно было обращаться к регистрам внешних устройств, как к ячейкам ОЗУ и делать с ними те же операции, а не гонять через аккумулятор. )
                              0
                              Ну в итоге к этому же и пришли на PC. Сначала была старая система, где использовались специальные команды для работы с портами (так они экономили адресное пространство). Теперь, когда адресное пространство стало огромным и устройства стали гонять огромные порции данных с огромной скоростью, всё опять мапится в адресное пространство, как на БК.
                            +1
                            Я прошёлся трассировкой по ПЗУ, выявил как можно слегка перехитрить алгоритм загрузки с магнитофона и заставить БК читать данные в 4 раза быстрее.

                            На БК был загрузчик Turbo, если не ошибаюсь, авторства Саяпина, который повышал скорость чтения — записи с аудионосителей примерно на порядок. Причиной тому использование четырёхтональной записи (вместо стандартной двух), и оптимизация кодирования, когда наиболее часто встречаемые последовательности кодировались более высокочастотными тонами, что дополнительно повышало скорость обмена.

                              0
                              Да, были на БК загрузчики с собственным форматом, самый известный из них — Help7. По тем временам это было очень круто, прямо волшебство (если у тебя качественный магнитофон).
                              Но я хотел добиться повышения скорости загрузки без сторонних решений, то есть читать разогнанные звуковые файлы стандартной подпрограммой из ПЗУ, чтобы это работало во всех играх и программах. Больше 4-кратного прироста у меня не получилось.
                              Ну а потом сделал и турбо-формат свой. Вариант с 4-тоновым сигналом поначалу тоже рассматривал (смотрел код Help12), но в итоге пришёл к тому, что чем меньше код загрузчика, тем лучше. Поэтому турбо-формат у меня простой как валенок, загрузчик микроскопический, скорость вполне устраивает (в 8 раз выше нормы).
                                +1
                                Это да, но Turbo требовал своего загрузчика, плюс (из-за того, что на БК0011М отсутствует механизм автозапуска загружаемых приложений) — непонятно как целостно реализовать процедуру загрузки. Загружать загрузчик, останавливать ленту, запускать загрузчик, запускать ленту? Если магнитофон без управления — неудобно. В варианте автора запись готовится в совместимом со стандартным формате, разве что тайминги в модуляции укорочены, что требует хорошего качества устройства воспроизведения.
                                  0
                                  На БК-0010 есть автозапуск через загрузку прямо поверх текущего стека. В БК-0011М этого нет?
                                    0
                                    У 11М стек в другом месте (не с 1000о), потому не затирается.
                                      0
                                      Хуже того – не в той странице памяти, в которую происходит загрузка с магнитофона. То есть во время загрузки физически невозможно перетереть системный стек.
                                      0
                                      Зато 11М появилась позже и монитор, первым делом, передавал управление в ПЗУ по адресу 140000, где, в случае подключения контроллера дисковода, как раз оказывался загрузчик с диска, а в 10-ке операционку приходилось стартовать в ручную.
                                        0
                                        С контроллером дисковода — да, вручную. А контроллер HDD на БК-0010 уже делал всё как надо сам.
                                          0
                                          К сожалению у меня были только БК 0010-01 и БК 11М, но с дисководами. HDD я не застал. Могу только предположить что на 10-ке контроллером HDD подменялась ПЗУ по адресу 120000, где штатно был Бейсик и вместо него стартовал контроллер.
                                    0

                                    Был такой подход к ускорению загрузки/записи, но на практике пользоваться им было очень трудно. Уж больно этот загрузчик был требовательным к качеству ленты и оборудования. Малейшее провисание ленты или повреждение и все сохраненные данные в помойку. Дисковод в это смысле был гораздо практичнее и надежнее.

                                      0
                                      В каком-то копировщике я видел оригинальный загрузчик — он делил файл на блоки и считал контрольные суммы для каждого блока. Если какой блок грузился с ошибкой, то дозагружался только повреждённый блок — для этого после загрузчика шла не одна копия файла, а две. Да, по расходу ленты — это увеличение в два раза (хотя сам формат записи тоже был ускоренный, так что перерасход по сути — в 1,5), зато удобство — значительно выше. Если с лентой и оборудованием всё норм, то программа загружалась в 1,5-2 раза быстрее. Если были ошибки — то не надо было загружать всё снова.
                                        0
                                        Такой формат загрузки был штатным на советском же Вектор-06ц. Любопытно, почему на других домашних ПК той эпохи он если и прижился, то только в стороннем софте?
                                          0

                                          Копировщик назывался HELP7. Две копии файла люди писали почти всегда — даже в стандартном формате: магнитофоны имели тенденцию время от времени "зажёвывать" плёнку, после чего в этом месте информация восстановлению (на доступной тогда аппаратуре) не подлежала. Вторая копия предназначалась для спасения как раз от таких случаев (такой вот RAID на кассетах). У меня сохранилась записанная им кассета — как-нибудь покажу осциллограмму.

                                          0

                                          Дисковод появился на БК позже уже. Касаемо саяпинского Турбо, он, помнится, писал, данные поблочно и двумя копиями, так что если вдруг была какая-то проблема со считыванием, она решалась чтением того же блока из второй копии.

                                          0
                                          Слушайте, на подобных машинах (включая Радио РК-86, Специалист, ЮТ, ZX-Spectrum и подобные) всегда используется кодировка Манчестер-2. Она ДВУХ-тональная. (спектр манчестера-2 используется как лого фирмы Cisco).

                                          Причина в том, что этот кодировщик наиболее плотный из простых (без частотной манипуляции и фазовой манипуляции) и легко реализуется снятием сигнала с цифровой микросхемы практически без подготовки.

                                          Но главное свойство этого кода в том, что он САМОсинхронизирующийся. САМО, означает, что носитель информации, несущий этот код может быть нестабильным (что в условиях использования бытового магнитофона, или при передаче через дальний эфир — очень актуально).

                                          У Манчестера-2 синхронизация происходит в каждом такте — при передаче каждого символа. Нестабильность может достигать до 25% частоты передачи или записи.
                                          Т.е. теоретически, каждый следующий такт (символ или бит — плотность Манчестера-2 — это 1 бит на символ) может иметь частоту на 25% отличающуюся от предыдущего символа. За счёт этого совершенно неважно какой формы сигнал и насколько плохой тракт записи-воспроизведения используется — по барабану — код всё исправит.

                                          Поэтому этот код очень устойчив к среде носителя. Конечно глушение сигнала не спасёт, но для этого на простых системах использовали либо просто повтор, либо индикацию сбоя т.е. просто подсчёт контрольной суммы (CRC32). На сложных системах — перемежение инфы и восстанавливающие коды (чаще всего eat-Salmon )). Конечно не такие мощные как на компакт-дисках, но и плотность инфы на носителе была в то время невысокая — так что хватало перемежать блок на 4-8 байтов (У CD блоки что-то около от 2-х до 8-ми килобайт).

                                          Так что никакие многотональные кодировщики не могли быть плотнее и устойчивее, чем Манчестер-2 в то время.
                                          Любое уплотнение и фазовая манипуляция требовала либо колоссальное повышение затрат (объёма вычислений в реальном времени), либо спец микросхем, на что пойти не могли изготовители оборудования (либо дорого, либо невозможно). Это всё позже родилось. В CD — наиболее массово.
                                            0

                                            Да, но нет.
                                            Как человек много в те годы работавший над вскрытием защит от копирования на магнитной ленте (а потом и на флоппи, но это уже другая история), могу сказать что в БК настройка на частоту и, соответственно, скорость протяжки, во всех форматах записи производилась на основе начальной тональной настроечной последовательности. Исходя из произведённых замеров — импульсов за заданную единицу времени или тактов процессора, в случае с БК, далее производился анализ основных тонов, которыми кодировалась информация. Контроль на основе CRC32.
                                            Никакой подстройки в процессе или кодов Рида-Соломона там не было. Хотя для последних попадалась где-то сторонняя реализация.
                                            Но возможно я что-то запамятовал, конечно.

                                              0
                                              Под «самосинхронизацией» имеется в виду, наверное, ожидание программой конца импульса (проверка в цикле).

                                              Настроечный тон БК использует так: высчитывает его период, умножает на 1.5 и любой импульс который длинней этой величины считает за 1, а любой который короче – за 0. Получается, что допустим люфт ~ 25%.

                                              Полностью формат записи БК я описал здесь (и способ его оптимизации): ссылка дана в статье.

                                              В формате БК после каждого бита зачем-то вставлен синхроимпульс. Я не понял смысла этих синхроимпульсов. Ощущение, что это какой-то ментальный артефакт, стереотип программиста: мол, деды ставили синхроимпульсы, и мы должны ставить. В итоге длительность записи увеличивается аж на 150% (в среднем). Лучше бы убрали синхроимпульсы и замедлили звук вдвое – надёжность сильно возросла бы.

                                              В своём турбо-формате я использовал что-то типа Манчестера-2 (хотя и не знал о существовании такого). Просто это самый очевидный, короткий и быстрый метод передачи, допускающий небольшой люфт частоты сигнала.

                                              Ivanq экспериментировал и с другим методом, без самосинхронизации. Там частоты намного превышают слышимый спектр (у нас профессиональная внешняя звуковая карта T.C. Electronic с частотой 96 КГц). БК даже читает десяток-другой байт, после чего сбивается. За clock звуковой карты я спокоен, дело в неточности кварца БК. Так что без самосинхронизации никак не получается.
                                          0
                                          Закончилось тем, что сын изучал схемотехнику БК 0011 (какие фронты сигналов куда приходят, когда срабатывает RPLY и т.д. — я в этом уже ничего не понимаю). Так он пришёл к идее сделать собственный эмулятор БК, совместимый с реальным железом с точностью до такта, и даже написал ядро… Впрочем, это уже другая история.
                                          Было бы интересно узнать подробности. Обычно в эмуляторах все крутится вокруг тактов процессора и когда нужно добавить эмуляцию чего-то асинхронного по отношению к процессору, начинаются трудности.
                                            +1
                                            Идея эмулятора была в том, что он запускается без OS. Грузится прямо с нулевого сектора HDD, написан на чистом ассемблере и всё такое. В общем, превращает PC в БК. До работы с асинхронными устройствами типа дисковода не дошли.
                                              0
                                              Но ведь это означает реальный режим процессора с неудобной сегментацией.
                                                +1

                                                Почему же? Переход из real mode в protected mode никто не отменял.

                                            +2
                                            13 лет, кросс-ассемблер, работа с железом… Оказывается не все так плохо и теперь я спокоен за наше ближайшее будущее :)
                                              0
                                              Блин, а я свою БКшку просто отдал. И она где-то утеряна на данный момент.
                                                0
                                                Мне казалось, что памяти на БК-010-01 (Вильнюс) гораздо меньше, чем 40к.
                                                В детстве я вообще считал что около 4 кбайт доступно пользователю, остальное — пзу и экранная память.
                                                Кто может подсказать спецификацию, которая в то время поставлялась в учебные заведения?
                                                Интернет говорит что 32 кб… Но я помню, как некоторые программы, которые дома писал в тетрадке, не помещались в память компа.
                                                  +1
                                                  32КБ ОЗУ (16КБ основная + 16КБ экран) и 32КБ ПЗУ (8КБ монитор + 24КБ Бейсик «Вильнюс»)
                                                    0
                                                    Точно, был какой-то монитор, но тогда я не понимал зачем он…

                                                    Значит 16 кбайт для пользователя. Спасибо.
                                                      0

                                                      Монитор это BIOS по-современному

                                                      0
                                                      Но на БК0010 можно часть видеопамяти использовать как ОЗУ, верхняя четверть экрана будет занята картинкой, нижние три четверти — данными. Об этом способе потом забыли надолго, а недавно здесь один из авторов написал эмулятор ZX Spectrum для микроконтроллера, там не хватило ОЗУ, он использовал часть видеопамяти ЖК-дисплея.
                                                        +1
                                                        на спектруме тоже легко было использовать часть видеопамяти как озу.
                                                        Насколько я помню, один из кассетных копировальщиков (copycopy) именно так и работал — код расположен в верхней трети, меню посредине, вся остальная память — для хранения копируемого содержимого.
                                                          0
                                                          Так почти все копировщики работали.
                                                            0

                                                            Они еще и данные сжимали на лету. А 128ые переключали страницы и могли загрузить непрерывный файл вплоть до 120 кб. Лента-диск копировщики Родионова и МОА тоже умели использовать расширенную память. Особенно кдобно это было при записи с диска на кассету — напихал файлы на сколько памяти хватило, и он пишет. Причем Родионовсеий грузил с ленты лучше. И поддерживал скриптинг. Можно было хоть всю кассету автоматически записать.

                                                    0
                                                    Звук в youtube-ролике слишком хорош для Covox 8-bit.
                                                    Его записывали с эмулятора? Интересно было бы послушать запись с реальной железки.
                                                      +2
                                                      Записывали с эмулятора, но с живой БК так же звучит: twitter.com/manwe_sns/status/1177539614371921920?s=21
                                                      Могу на следующей неделе записать в линию и выложить.
                                                        0
                                                        Не нужно, из этого видео понятно.
                                                        На Спектруме 8-битный covox звучал куда шумнее. Хотя там не было 22KHz.
                                                        +1

                                                        А они по качеству сильно разные, кучка резисторов это одно, микросхема совсем другое. А если резисторы подстроечные многооборотистые а питание ключей стабилизированно и всё это в ручную настраивается то можно вообще проф пригодный вариант получить.
                                                        В общем, R-2R решае, а разочарование в ково сах постигало лишь особо жадных до резисторов.

                                                        0
                                                        Казань — прекрасное место для проведения такого мероприятия. Огромное количество БК-шек производилось на местном заводе «Элекон». Мне, будучи школьником, довелось поработать одно лето на этом прекрасном заводе, так что, может быть вам досталась БК-шка частично собранная моими руками :)
                                                        PS: да, да, собиралась плата в те годы вручную, все радиодетали втыкались, потом специально обученные женщины их паяли, потом мы кисточками наносили латекс на контакты, после купания в лаке, их ножиками и пинцетами сдирали. Потом вибро-стенд, печка, морозильник по нескольку раз.
                                                          0
                                                          А для какой цели латекс наносился?
                                                            +1
                                                            Чтобы в нужных местах получились участки без лака.
                                                          0
                                                          Эх, ностальгия. В середине 90-х упрашивал родителей обменять ваучер на БК 0010-01, но тщетно. В итоге купили Спектрум. А недавно на работе в хламе нашел БКшку с монитором Электроника. Включил племяннику Бейсик, показал. Он полазил денёк, понажимал кнопки, да отложил в сторону. Ну а я держу для какого-то светлого будущего)
                                                            +1
                                                            Прикольно. Я начинал не с БК-0010. Все было хуже — программируемый калькулятор «МК-59», игры из «Науки и жизни» и свои (ха, «охота на лис», вспомнил). Потом" Д3-28"" со встроенным кассетником и монозеленым монитором с клавиатурой дикой раскладки. По советской легенде — копия американского компьютера с подводных лодок. Мне было тогда настолько мало лет, что только спустя годы, после того, как я стал «президентом», я понял что такое «лидер профсоюза мусорщиков».
                                                            БК была потом. Начали с другом писать в машинных кодах. Написали SUPERCALC. Работало. Даже формулы переносились. Фокал, Клад, Тетрис… Basic.
                                                            А еще вечная обида — IBM PC была в стотысяч раз круче БК-0010, а книжка Л.Пула — волшебной (всё выбросил, а её оставил).
                                                            P.S. Сейчас всё лучше. Это очень вдохновляет.
                                                              0
                                                              МК-59 — не программируемый, а бухгалтерский настольный. Может быть МК-54? Моим первым компьютером был «Электроника Б3-21». А любимый Д3-28 — клон (или даже развитие, т. к. клоном была предыдущая модель) американского Wang 700.
                                                                0
                                                                56. Он программируемый, а по размерам как 59.
                                                              +1

                                                              Тоже этим летом игрался с легендарным PDP-11, правда в лице МК-90, и тоже участвовал в CC. Программирование под древние платформы, конечно, очень увлекательное занятие!

                                                                0

                                                                Bad Apple — это статичная картинка или всё же полная анимация? Я думаю стоит на YouTube выложить, чтобы прям по классике.

                                                                  0
                                                                  Там же есть ссылка на youtube
                                                                    0

                                                                    Ага, нашёл. Не сразу увидел.

                                                                  0
                                                                  Спасибо, очень интересная статья)
                                                                  Но меня терзает вопрос какие сайты может создавать ребёнок 13 лет?
                                                                  +2

                                                                  Кстати, тут у нас, на Хабре, есть AlexeyNadezhin который теперь главный по лампочкам. Так вот он, будучи автором самого популярного DOS для этих машин, может много чего рассказать про БК...

                                                                    0
                                                                    У меня в девяностых был БК с ОС ANDOS и издательской системой Vortex. Строчил рефераты. После пишущей машинки всё это казалось удобным профессиональным инструментом.
                                                                    0

                                                                    Великолепная работа! Отсылка к рекламе айподов понравилась — ныне и сам эпл точно так же потерял себя и (надо надеяться) мечется в поисках :-)


                                                                    Надо по возвращении домой попробовать что-то подобное на МК-90 замутить :-)


                                                                    Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher.

                                                                    Эх, а вот такие, если их можно назвать, "продукты", человеку, понимающему в производительности и оптимизации, упоминать должно быть стыдно...

                                                                      0
                                                                      Благодарю за отзыв!
                                                                      Что касается оптимизации, для меня было важно наладить как можно более простой и быстрый процесс разработки. Упомянутая утилита позволяет записывать образ флешки за 2 клика. Более простого решения для MacOS я не нашёл. Под Windows пользуюсь также программой USB Image Tool – она хороша во всём, но всё же требует чуть больше движений.
                                                                      +1
                                                                      Спасибо за хороший материал. Всегда интересно разбираться в чём-то новом, даже если это хорошо забытое старое ;)
                                                                        0
                                                                        Спасибо на ссылку на эмулятор.
                                                                        Достал с полки тетрадку с записями из детства — все заработало! Даже клавиатура привычно глбючила, пока не нашел опцию, что можно отключить идентичную эмуляцию клавиатуры =)
                                                                          0
                                                                          по какой-то причине команда CLR работает медленней, чем MOV.

                                                                          По той причине, что в микропрограмме CLR x реализована как BIC x, x (нестрого говоря, "сбросить в числе X биты по маске X"), то есть ячейку назначения надо сначала прочитать, а потом записать. А MOV R2, x сразу пишет (чтение из регистра ожидаемо быстрее чтения из памяти).

                                                                            0
                                                                            Пользуясь случаем, хочу порекламировать наш ютуб канал. Сейчас там в основном наши (Excess team) демки, но в ближайшее время мы начнем заполнять белые пятна БКшной демосцены. Причем записи будут с реальной машины, а не с эмулятора.
                                                                              0
                                                                              Напомнило старую добрую амиговскую демку 9 Fingers (видео, кое-какие технические детали). Там был очень похожий принцип потоковой подгрузки видео с дискеты:

                                                                              At the core, the demo consists of an animplayer (which is an image sequence playback program) that takes its data and calculates the graphics data at runtime, resulting in a line drawer to create the polygons and blitter to fill them.
                                                                              To do this, they took their footage, and had it displayed fame per frame as a bitmap. Now they would not store these bitmaps but rather have a coder outline the image and store this basic data to disk. The lines could then be created at runtime as mentioned above, requiring very little disk space.

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                              Самое читаемое