Зачем?
Если Вы — энтузиаст ретро-компьютеров, то мотивационную речь можете смело пропустить и перейти к следующему разделу.
Весь август 2018-го года я и мой 13-летний сын Ivanq потратили на написание демки Good Apple. На фестивале Chaos Constructions наша работа заняла второе место, за что мы получили денежный приз 35 тысяч рублей, который честно поделили поровну. Для ребёнка это неплохой доход, хотя, созданием сайтов он зарабатывал столько же за меньшее время. Очевидно, и я мог потратить своё время с большей экономической выгодой… Но только не август! Надо же когда-то отдыхать от работы. Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.
Материальное вознаграждение, конечно, не служит мотивацией, но закрепляет положительные эмоции. Удивительно, что демка для забытого советского компьютера собрала тысячи просмотров на youtube и попала в плейлист с почти сотней тысяч просмотров. Но ещё более удивительно, что в 2018-ом году за неё вручают денежный приз! Возможно, сама невероятность происходящего и порождает такой эмоциональный подъём.
Однако, есть кое-что более важное.
При создании “Good Apple” нам пришлось работать с реальным железом, так как мы использовали возможности компьютера, которые эмуляторы воспроизводят не совсем корректно. Прежде всего, хотелось добиться одинаково устойчивой работы с жёсткими дисками формата IDE и с их современными заменителями в виде Compact Flash.
Именно на этом проекте мой 13-летний сын обрёл бесценный опыт промышленной разработки. Дефектное железо. Хорошее железо, которое ведёт себя не так, как описано в документации. Документация, которая составлена с ошибками. Отсутствие документации по ряду вопросов. Написание собственных тестов для выявления проблем с железом. Выходящие сроки. Тестирование на разных машинах и конфигурациях. Написание собственного кросс-ассемблера (когда стало понятно, что существующие решения тормозят процесс разработки). И, наконец, после короткого празднования успеха — обязательный выпуск финальной версии, исправляющей ряд багов.
На первый взгляд кажется, что подобный опыт можно было получить и с каким-нибудь современным Arduino. По факту же, нам пришлось погрузиться в самые дебри схемотехники. Мы вычисляли число тактов, за которое исполняются инструкции. В разных типах памяти это время отличается. Контроллер памяти и процессор работают на разных частотах, поэтому одинаковые команды могут выполняться разное время даже в памяти одного типа. Длительность исполнения подпрограммы не равна сумме длительностей команд этой подпрограммы. Нам пришлось писать собственные инструменты для тестирования и оптимизации кода на реальном железе.
Закончилось тем, что сын изучал схемотехнику БК 0011 (какие фронты сигналов куда приходят, когда срабатывает RPLY и т.д. — я в этом уже ничего не понимаю). Так он пришёл к идее сделать собственный эмулятор БК, совместимый с реальным железом с точностью до такта, и даже написал ядро… Впрочем, это уже другая история.
Итого, за месяц — от изучения ассемблера до создания собственных средств разработки, от хардварных тестов до готового мультимедийного произведения. Всё это было бы невозможно без главного: Планирование. Пожалуй, наиболее ценный вынесенный урок. Берёшь невозможную задачу. Понимаешь, что столкнёшься с непреодолимыми сложностями. Планируешь. Делаешь. Результат поражает всех настолько, что даже знатоки обвиняют в читерстве (“вы разогнали процессор!”).
Почему не ZX Spectrum?
Опять начну со странного: с финансов. Судя по объявлениям на 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 (загружать первую встреченную программу). Для передачи звука в турбо-формате нужно предварительно запустить микро-загрузчик (у меня он автоматически запускается с жёсткого диска при включении БК; в любой момент можно выйти в систему, нажав клавишу СТОП).
Подключить БК к телевизору проще всего в монохромном режиме, в обычный композитный 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 МГц. Впрочем, подёргивание было заметно только в некоторых демках. Большинство программ на БК не использует синхронизацию с кадровой частотой.
Почему не довольствоваться эмулятором, для чего вообще может понадобиться реальный компьютер? Я обнаружил четыре вещи, которые плохо эмулируются:
- Поведение динамика на высоких частотах.
- Синхронизация изображения и палитр с ходом луча.
- Точное время исполнения команд (важно для музыки через Covox).
- Работа с жёсткими дисками IDE на высоких скоростях.
Если вы не планируете делать ничего из вышеперечисленного, вам вполне хватит эмулятора.
Эмуляция
На MacOS я использую эмулятор BK2010. Он не очень точный, но для большинства задач подходит.
Самый продвинутый на сегодняшний день эмулятор GID работает под Windows. Он также запускается в CrossOver под MacOS и в Wine под Linux. В эмуляторе хороший отладчик, просмотрщик страниц памяти и тому подобное.
Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher. Но чаще передаю данные по звуковому каналу.
Средства разработки
Ребята из демогруппы 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 ; строка должна заканчивать нулевым байтом
Покажите исходники!
Легче всего будет начать, посмотрев исходники готовых демок:
In Your Space — демо для Covox, исходники в архиве.
Good Apple — исходники на GitLab (сложный многофайловый проект).
EIS — эмулятор инструкций расширенной арифметики с исходниками.
Исходники трёх 256-байтных демок.
В 28-ом выпуске журнала Downgrade большая статья про эволюцию алгоритмов трекерной музыки на БК 0010, с фрагментами программ и подробными разъяснениями. Ностальгический рассказ о ранней демосцене в придачу.
Когда приступать?
Прямо сейчас. Через 4 недели в Казани состоится демопати CAFe 2019. В программе фестиваля есть конкурс БК 0010 — 512 байт. В такой размер уместится от 85 до 256 инструкций – идеально для начинающих. Двух недель вам хватит на то, чтобы разобраться с инструментарием и написать первую простенькую демку. После этого ещё останется неделя-полторы на написание второй, более серьёзной работы.
Дерзайте, вы можете! Телеграм-чат, форум на zx-pk — везде вам помогут. присылайте работы на конкурс, а лучше ещё и приезжайте сами. Scene is alive!
Комментарии (74)
Lopar
27.09.2019 11:46Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.
Программировать во время отпуска, это не роскошь, а скорее профдеформация. На море съездить, в поход, сменить род деятельности, банально отоспаться… но нет. Как вы не выгораете? И не боитесь ли выгореть?0xd34df00d
29.09.2019 05:04+2Автора как раз легко понять. Полтора месяца, что я провел за редактором кода (и за учебниками) между двумя работами этим летом — одни из самых лучших за последние несколько лет.
GarryC
27.09.2019 11:55Если я правильно понял просмотренные по диагонали исходники, то вся программа состоит в чтении информации с диска и выдачи ее на экран. При всем уважении к труду 13-летнего программиста — это НЕ демо-сцена.
Manwe_SandS Автор
27.09.2019 12:54Ну тогда и это не демосцена: www.pouet.net/prod.php?which=63591
И демки с музыкой в MP3-формате — не демосцена.frog
01.10.2019 13:36Человек говорит про твою работу, а ты ссылаешься на чужую, в подтверждении того, что твоя — демо. Немного странно. Да, по ссылке — тоже не демо. Я бы назвал это «демонстрация технологии». При всём уважении — наличия крутого кода совершенно недостаточно, чтобы считать работу «демо». Вдобавок, с полностью заимствованным видеорядом.
Что касается демок с музыкой в mp3 формате, то всё зависит от демки. Само наличие там mp3 музыки ни о чём не говорит.Manwe_SandS Автор
01.10.2019 14:22Говоря о моей работе, человек сам ссылается на другие работы, ибо определять что есть демо, а что нет, можно только при наличии некоторого множества работ и устоявшегося их названия. Поэтому мой аргумент — отсылка к другим общепризнанным на демосцене работам. Логично же. Это первое.
Второе: видеоряд не «полностью заимствован». Здесь можно увидеть как я рисовал 3D-вставки: twitter.com/Manwe_sns/status/1177540242125066240
Третье: когда в демках начали использовать MP3, это было встречено негативно. Потом ещё на Амиге начали играть неупакованную музыку прямо с диска — это вообще было фу. Я и сам так считал, и отчасти до сих пор придерживаюсь такого мнения. В идеале всё должно быть в риалтайме. Но демо-сообщество в целом переварило и смирилось с использованием потоковой музыки в демо. У нас в «Good Apple» тоже неупакованная потоковая музыка. Будем за это ругать или как? Просто чтобы я смог понять объективность подхода.
Ну и четвёртое: да, это «демонстрация технологии». Никто же не обманывает, не говорит, что силуэты рендерятся в 3D в реальном времени. Была изобретена технология упаковки и скоростного вывода видео. Идею бесшовного вывода звука ещё за полгода до этого придумали Excess Team. Всё это в сочетании, а также титры с многоцветным трюком — некий законченный продукт. Как его назвать, если не «демо»?
На БК словом «демо» называли вообще всё что попало: например, многочисленные подборки музыки под пищалку. Или взять наш прошлогодний релиз «In Your Space» — для БК-сцены это вполне «демо», хотя там даже на экране ничего не изменяется во время проигрывания музыки.
Мне кажется, надо просто смотреть контекст: в каком состоянии находится демосцена на той или иной платформе. Где-то помигать курсором — уже демо. А на другой платформе это пффф.
Whuthering
27.09.2019 16:34+6Так это же Bad Apple. С ним как раз и связан challenge — заставить играть real-time видео железо, про которое все думают, что оно на такое в прицнипе не способно.
Похожая история была с 8088 MPH (1, 2), когда чуваки со стандартной CGA-карточки смогли вывести 1024 цвета. Сами эффекты там более чем стандартные, а основная фишка именно в выжимании из железа возможностей, для которых оно изначально вообще не предназначено.tormozedison
28.09.2019 00:15Получается, что если бы в 1985 году были жёсткие диски такого объёма и с такой скоростью считывания, то можно было бы проигрывать в реальном времени аудио+видео (пусть и с 1 битом на пиксель) на железе того времени. Не только БК, к другому железу демосценщики бы тоже нашли подход.
saboteur_kiev
28.09.2019 02:31ну собственно довольно быстрый скроллинг экрана на БК показывал, что как минимум видеопамять способна отображать несколько кадров в секунду
pokryshkin
30.09.2019 09:29На сколько я помню, видеопамять — это кольцевой буфер, скролл «аппаратный», т.е. задается смещение относительно начала видеопамяти и перерисовывать нужно всего одну строку изображения.
Videoman
27.09.2019 12:29+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 на основании предыдущего значения операнда.Manwe_SandS Автор
27.09.2019 12:38Под равноправием я имел в виду использование любых регистров в качестве аргументов любых команд. Например, никто не запрещает использовать регистр стека (SP) или счётчик команд (PC) в качестве индекса цикла или в качестве приёмника слова состояния процессора (PSW). Правда, что после этого будет — берегись! :)
PlusPlus
27.09.2019 13:04Ага, мое любимое: MOV --(PC), --(PC)
Videoman
27.09.2019 13:44Мне больше нравился такой код "защиты от стопа":
SUB (PC),(SP)<br> RTI
Вроде ничего не напутал. Он одной командой вычитал 2 (т.к в момент выполнения PC указывает на адрес RTI — opcode которой как раз двойка) из PC сохраненного в стеке, который тут же восстанавливался при возврате с помощью RTI, что приводило к выполнению последней прерванной команды.Antohin
27.09.2019 16:13Смутно помнится что была команда, которая копировала себя адресом выше и передавала управление на этот адрес. Занеся и запустив команду по младшему адресу получали зависший комп с полосатым экраном. С некоторой натяжкой можно считать самым коротким «червём» :) Как сказано неоднократно выше, это было возможно благодаря развитой и разнообразной системе адресации
mxms
27.09.2019 13:08Я прошёлся трассировкой по ПЗУ, выявил как можно слегка перехитрить алгоритм загрузки с магнитофона и заставить БК читать данные в 4 раза быстрее.
На БК был загрузчик Turbo, если не ошибаюсь, авторства Саяпина, который повышал скорость чтения — записи с аудионосителей примерно на порядок. Причиной тому использование четырёхтональной записи (вместо стандартной двух), и оптимизация кодирования, когда наиболее часто встречаемые последовательности кодировались более высокочастотными тонами, что дополнительно повышало скорость обмена.
Manwe_SandS Автор
27.09.2019 13:46Да, были на БК загрузчики с собственным форматом, самый известный из них — Help7. По тем временам это было очень круто, прямо волшебство (если у тебя качественный магнитофон).
Но я хотел добиться повышения скорости загрузки без сторонних решений, то есть читать разогнанные звуковые файлы стандартной подпрограммой из ПЗУ, чтобы это работало во всех играх и программах. Больше 4-кратного прироста у меня не получилось.
Ну а потом сделал и турбо-формат свой. Вариант с 4-тоновым сигналом поначалу тоже рассматривал (смотрел код Help12), но в итоге пришёл к тому, что чем меньше код загрузчика, тем лучше. Поэтому турбо-формат у меня простой как валенок, загрузчик микроскопический, скорость вполне устраивает (в 8 раз выше нормы).
vicsoftware
27.09.2019 13:48+1Это да, но Turbo требовал своего загрузчика, плюс (из-за того, что на БК0011М отсутствует механизм автозапуска загружаемых приложений) — непонятно как целостно реализовать процедуру загрузки. Загружать загрузчик, останавливать ленту, запускать загрузчик, запускать ленту? Если магнитофон без управления — неудобно. В варианте автора запись готовится в совместимом со стандартным формате, разве что тайминги в модуляции укорочены, что требует хорошего качества устройства воспроизведения.
nzeemin
27.09.2019 14:02На БК-0010 есть автозапуск через загрузку прямо поверх текущего стека. В БК-0011М этого нет?
vicsoftware
27.09.2019 14:17У 11М стек в другом месте (не с 1000о), потому не затирается.
Manwe_SandS Автор
27.09.2019 14:28Хуже того – не в той странице памяти, в которую происходит загрузка с магнитофона. То есть во время загрузки физически невозможно перетереть системный стек.
Videoman
27.09.2019 15:55Зато 11М появилась позже и монитор, первым делом, передавал управление в ПЗУ по адресу 140000, где, в случае подключения контроллера дисковода, как раз оказывался загрузчик с диска, а в 10-ке операционку приходилось стартовать в ручную.
Manwe_SandS Автор
27.09.2019 16:16С контроллером дисковода — да, вручную. А контроллер HDD на БК-0010 уже делал всё как надо сам.
Videoman
27.09.2019 16:22К сожалению у меня были только БК 0010-01 и БК 11М, но с дисководами. HDD я не застал. Могу только предположить что на 10-ке контроллером HDD подменялась ПЗУ по адресу 120000, где штатно был Бейсик и вместо него стартовал контроллер.
Videoman
27.09.2019 13:48Был такой подход к ускорению загрузки/записи, но на практике пользоваться им было очень трудно. Уж больно этот загрузчик был требовательным к качеству ленты и оборудования. Малейшее провисание ленты или повреждение и все сохраненные данные в помойку. Дисковод в это смысле был гораздо практичнее и надежнее.
vicsoftware
27.09.2019 14:00В каком-то копировщике я видел оригинальный загрузчик — он делил файл на блоки и считал контрольные суммы для каждого блока. Если какой блок грузился с ошибкой, то дозагружался только повреждённый блок — для этого после загрузчика шла не одна копия файла, а две. Да, по расходу ленты — это увеличение в два раза (хотя сам формат записи тоже был ускоренный, так что перерасход по сути — в 1,5), зато удобство — значительно выше. Если с лентой и оборудованием всё норм, то программа загружалась в 1,5-2 раза быстрее. Если были ошибки — то не надо было загружать всё снова.
mxms
27.09.2019 15:24Дисковод появился на БК позже уже. Касаемо саяпинского Турбо, он, помнится, писал, данные поблочно и двумя копиями, так что если вдруг была какая-то проблема со считыванием, она решалась чтением того же блока из второй копии.
u_235
27.09.2019 15:31Закончилось тем, что сын изучал схемотехнику БК 0011 (какие фронты сигналов куда приходят, когда срабатывает RPLY и т.д. — я в этом уже ничего не понимаю). Так он пришёл к идее сделать собственный эмулятор БК, совместимый с реальным железом с точностью до такта, и даже написал ядро… Впрочем, это уже другая история.
Было бы интересно узнать подробности. Обычно в эмуляторах все крутится вокруг тактов процессора и когда нужно добавить эмуляцию чего-то асинхронного по отношению к процессору, начинаются трудности.Manwe_SandS Автор
27.09.2019 21:41+1Идея эмулятора была в том, что он запускается без OS. Грузится прямо с нулевого сектора HDD, написан на чистом ассемблере и всё такое. В общем, превращает PC в БК. До работы с асинхронными устройствами типа дисковода не дошли.
Arkafon
27.09.2019 15:35+213 лет, кросс-ассемблер, работа с железом… Оказывается не все так плохо и теперь я спокоен за наше ближайшее будущее :)
saboteur_kiev
27.09.2019 15:51Мне казалось, что памяти на БК-010-01 (Вильнюс) гораздо меньше, чем 40к.
В детстве я вообще считал что около 4 кбайт доступно пользователю, остальное — пзу и экранная память.
Кто может подсказать спецификацию, которая в то время поставлялась в учебные заведения?
Интернет говорит что 32 кб… Но я помню, как некоторые программы, которые дома писал в тетрадке, не помещались в память компа.Videoman
27.09.2019 15:56+132КБ ОЗУ (16КБ основная + 16КБ экран) и 32КБ ПЗУ (8КБ монитор + 24КБ Бейсик «Вильнюс»)
saboteur_kiev
27.09.2019 19:11Точно, был какой-то монитор, но тогда я не понимал зачем он…
Значит 16 кбайт для пользователя. Спасибо.
tormozedison
27.09.2019 23:41Но на БК0010 можно часть видеопамяти использовать как ОЗУ, верхняя четверть экрана будет занята картинкой, нижние три четверти — данными. Об этом способе потом забыли надолго, а недавно здесь один из авторов написал эмулятор ZX Spectrum для микроконтроллера, там не хватило ОЗУ, он использовал часть видеопамяти ЖК-дисплея.
saboteur_kiev
28.09.2019 02:32на спектруме тоже легко было использовать часть видеопамяти как озу.
Насколько я помню, один из кассетных копировальщиков (copycopy) именно так и работал — код расположен в верхней трети, меню посредине, вся остальная память — для хранения копируемого содержимого.
qw1
27.09.2019 17:22Звук в youtube-ролике слишком хорош для Covox 8-bit.
Его записывали с эмулятора? Интересно было бы послушать запись с реальной железки.Manwe_SandS Автор
27.09.2019 20:37+1Записывали с эмулятора, но с живой БК так же звучит: twitter.com/manwe_sns/status/1177539614371921920?s=21
Могу на следующей неделе записать в линию и выложить.qw1
28.09.2019 09:50Не нужно, из этого видео понятно.
На Спектруме 8-битный covox звучал куда шумнее. Хотя там не было 22KHz.
SADKO
28.09.2019 09:45+1А они по качеству сильно разные, кучка резисторов это одно, микросхема совсем другое. А если резисторы подстроечные многооборотистые а питание ключей стабилизированно и всё это в ручную настраивается то можно вообще проф пригодный вариант получить.
В общем, R-2R решае, а разочарование в ково сах постигало лишь особо жадных до резисторов.
safari2012
27.09.2019 17:43Казань — прекрасное место для проведения такого мероприятия. Огромное количество БК-шек производилось на местном заводе «Элекон». Мне, будучи школьником, довелось поработать одно лето на этом прекрасном заводе, так что, может быть вам досталась БК-шка частично собранная моими руками :)
PS: да, да, собиралась плата в те годы вручную, все радиодетали втыкались, потом специально обученные женщины их паяли, потом мы кисточками наносили латекс на контакты, после купания в лаке, их ножиками и пинцетами сдирали. Потом вибро-стенд, печка, морозильник по нескольку раз.
aleksandros
27.09.2019 19:50Эх, ностальгия. В середине 90-х упрашивал родителей обменять ваучер на БК 0010-01, но тщетно. В итоге купили Спектрум. А недавно на работе в хламе нашел БКшку с монитором Электроника. Включил племяннику Бейсик, показал. Он полазил денёк, понажимал кнопки, да отложил в сторону. Ну а я держу для какого-то светлого будущего)
BasilM
27.09.2019 21:29+1Прикольно. Я начинал не с БК-0010. Все было хуже — программируемый калькулятор «МК-59», игры из «Науки и жизни» и свои (ха, «охота на лис», вспомнил). Потом" Д3-28"" со встроенным кассетником и монозеленым монитором с клавиатурой дикой раскладки. По советской легенде — копия американского компьютера с подводных лодок. Мне было тогда настолько мало лет, что только спустя годы, после того, как я стал «президентом», я понял что такое «лидер профсоюза мусорщиков».
БК была потом. Начали с другом писать в машинных кодах. Написали SUPERCALC. Работало. Даже формулы переносились. Фокал, Клад, Тетрис… Basic.
А еще вечная обида — IBM PC была в стотысяч раз круче БК-0010, а книжка Л.Пула — волшебной (всё выбросил, а её оставил).
P.S. Сейчас всё лучше. Это очень вдохновляет.Kobzar_habr
28.09.2019 14:32МК-59 — не программируемый, а бухгалтерский настольный. Может быть МК-54? Моим первым компьютером был «Электроника Б3-21». А любимый Д3-28 — клон (или даже развитие, т. к. клоном была предыдущая модель) американского Wang 700.
Azya
27.09.2019 22:44+1Тоже этим летом игрался с легендарным PDP-11, правда в лице МК-90, и тоже участвовал в CC. Программирование под древние платформы, конечно, очень увлекательное занятие!
Noiwex
27.09.2019 23:46Bad Apple — это статичная картинка или всё же полная анимация? Я думаю стоит на YouTube выложить, чтобы прям по классике.
skop8
27.09.2019 23:58Спасибо, очень интересная статья)
Но меня терзает вопрос какие сайты может создавать ребёнок 13 лет?Manwe_SandS Автор
28.09.2019 00:00+1Есть вариант пройти по первой ссылке в начале статьи и посмотреть какие сайты может создавать ребёнок в 13 лет :)
Ну или, чтобы далеко не ходить, вот сайт, созданный ребёнком в 10 лет (фронтэнд и бэкэнд): thesands.ru/forth-demotool
mxms
28.09.2019 00:24+1Кстати, тут у нас, на Хабре, есть AlexeyNadezhin который теперь главный по лампочкам. Так вот он, будучи автором самого популярного DOS для этих машин, может много чего рассказать про БК...
tormozedison
28.09.2019 17:34У меня в девяностых был БК с ОС ANDOS и издательской системой Vortex. Строчил рефераты. После пишущей машинки всё это казалось удобным профессиональным инструментом.
vladkorotnev
28.09.2019 03:56Великолепная работа! Отсылка к рекламе айподов понравилась — ныне и сам эпл точно так же потерял себя и (надо надеяться) мечется в поисках :-)
Надо по возвращении домой попробовать что-то подобное на МК-90 замутить :-)
Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher.
Эх, а вот такие, если их можно назвать, "продукты", человеку, понимающему в производительности и оптимизации, упоминать должно быть стыдно...
Manwe_SandS Автор
28.09.2019 07:58Благодарю за отзыв!
Что касается оптимизации, для меня было важно наладить как можно более простой и быстрый процесс разработки. Упомянутая утилита позволяет записывать образ флешки за 2 клика. Более простого решения для MacOS я не нашёл. Под Windows пользуюсь также программой USB Image Tool – она хороша во всём, но всё же требует чуть больше движений.
breeze
28.09.2019 10:31Спасибо за хороший материал. Всегда интересно разбираться в чём-то новом, даже если это хорошо забытое старое ;)
saboteur_kiev
30.09.2019 15:51Спасибо на ссылку на эмулятор.
Достал с полки тетрадку с записями из детства — все заработало! Даже клавиатура привычно глбючила, пока не нашел опцию, что можно отключить идентичную эмуляцию клавиатуры =)
alec_kalinin
Очень рад слышать, что сообщество БК 0010 живо и активно! С БК 0010 начался мой путь в ИТ. Помню как я ребенком простаивал часы в маленьком игровом салоне с компьютерами БК 00100.
У меня вопрос насчет эмуляторов. Есть ли сейчас активные проекты по разработке эмуляторов? Нет ли акивных проектов разработки эмуляторов под web assembly?
Manwe_SandS Автор
Исходники эмулятора Gid открыты, в них иногда вносят изменения.
Есть ещё открытый проект хардварного эмулятора на микроконтроллере: zx-pk.ru/threads/30072-emulyator-bk-0011m-na-esp8266.html
WebAssembly – хорошая идея, я не слышал об эмуляторе БК, но было бы здорово. Если задумаете взяться, я с удовольствием поучаствую.
nzeemin
Собирал свой эмулятор (BKBTL) под WASM, скорее чтобы попробовать чем как реально широко используемый проект — nzeemin.github.io/bkbtl-wasm/index.html
Ну и свой основной эмулятор (UKNCBTL) тоже собирал под WASM — nzeemin.github.io/ukncbtl-wasm/index.html
alec_kalinin
Огромное спасибо за проект! Собрал проект из репозитория, вернулся в детство.
Собрал под Windows 10, Visual Studio Community 2019. Единственно, в файле Board.cpp в строчке 169 добавил проверку:
nzeemin
Да, тоже на это наткнулся на днях, поправлю. Спасибо!
FForth
Тоже делал для себя (лет 15-ть назад) эмулятор системы команд PDP-11 :)
и под ним даже отладил Форт систему уже для реального железа функционирующего в рамках некоторой самопальной IDE. (сам эмулируемый процессор поддерживал передачу по COM порту и поэтому его можно было соединить через виртуальный COM порт на этом же компьютере с IDE)
P.S. Программирование, в пределах этого инструментария, было на «высокоуровневом» ассемблере (if, else, while ...) в рамках этой IDE с расширенными псевдокомандами ассемблера. IDE тоже была на диалекте Форта (Win32Forth), а эмулируемый процессор на Форт системе (SPF4)
До сих пор есть желание сделать эмулятор на каком нибудь контроллере (типа STM32)
А, для того же ZX-Spectrum делал прошивку ПЗУ с русификацией и турбированием.
а к редактору TLW подключил 64-е клавишную клавиатуру.
Ну и где то остались дискетки от ZX-Spectrum с каким то своим ассемблерным программированием и играми (может уже и не читаются после такого времени ) :)
3cky
Есть еще Open-Source эмулятор для Android — BkEmu. Разрабатываю я его не то чтобы очень активно, но баги фиксятся и даже иногда добавляются новые фичи. Люди запускали его даже на видеотелефоне. :)