Cobalt-68 История проекта

Предыдущая заметка: Cobalt-68: Предыстория проекта

Проект на GitLab: https://gitlab.com/alkid1/cobalt68

Проект по созданию компьютера занял у меня почти три года неспешной работы с большими перерывами. Это был увлекательный квест воина паяльника и клавиатуры, который научил меня многому в отношении создания систем. Особенностью этого проект является то, что я одновременно создавал и отлаживал и аппаратную и программную части системы, которые очень тесно связаны между собой. И если с программной частью для меня всё было более-менее понятно (жизнь в этом смысле меня изрядно покидала, поэтому я не боюсь ассемблера и железа), то разработка и отладка аппаратуры для меня во многом оставалась полем поисков и экспериментов.

Подготовка и заточка инструмента

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

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

Инструментарий проектирования

Начинать разработку надо с проектирования схемы. Раньше мне хватало бумаги, но теперь я решил освоить какую-нибудь CAD-систему. Я перебрал несколько разных вариантов программ, но в итоге остановил свой выбор на онлайн-сервисе EasyEDA. Он привлёк меня своей простотой в работе и отсутствием необходимости устанавливать программу на свой компьютер. Бесплатный аккаунт даёт достаточно возможностей для неискушённого пользователя: можно  рисовать схемы, разводить платы и заказывать их у производителя. Возможно, в будущем я перейду на какой-нибудь Proteus, но пока меня полностью устраивает и этот инструмент.

TIP: При пайке с тыльной стороны платы очень удобно иметь схему, зеркально отражённую по вертикальной оси, тогда на ней расположение контактов у микросхем будет таким же, как и при взгляд с тыльной стороны платы. Это очень сильно облегчает процесс пайки проводков при макетированнии. EasyEDA позволяет получить такую схему с небольшим количеством усилий.

TIP2: EasyEDA имеет функцию автороутинга - автоматической разводки печатных плат. Но доступный в облаке роутер часто бывает недоступен из-за перегрузки. Редактор даёт возможность развернуть роутер локально и использовать мощности компьютера. Очень рекомендую сделать сделать это сразу.

Логический анализатор

Внутри компьютера очень много разных линий соединения по котором с частотой в несколько мегагерц бегают туда-сюда сигналы. Чтобы понять, как работает система, и что в ней не так. надо уметь заглянуть "внутрь"  этого процесса. Отладку предыдущих схем я осуществлял при помощи светодиодов и режима ручного тактирования. Это адски трудоёмкий способ. 

К счастью, есть устройства, позволяющие заглянуть внутрь системы - это логические анализаторы (иногда их называют шинными анализаторами). Доступные в российских магазинах системы неприятно удивляют своей ценой. К счастью есть китайцы и сделанные ими клоны, которые можно приобрести за вполне разумные деньги. Я выбрал Saleae Logic-16 - 16-канальный анализатор с подключением к компьютеру через USB. У него нет многих функций дорогих профессиональных моделей, зато его можно купить за 2500 рублей (на момент написания заметки).

Среди полезных фишек его программного обеспечения - возможность декодирования некоторых протоколов из данных о перехваченных сигналах. Мне очень помогла возможность декодировать UART, SPI, и просто параллельные шины данных.

Программаторы

Микроконтроллер и ПЗУшки компьютера надо чем-то программировать. Традиционно я использовал свой старый добрый WizardProg 87i (российская нелицензионная копия китайского(!) программатора TL866 MiniPro). Он умеет и в параллельное программирование и в ISP-программирование, но его программная оболочка не умеет выполнять операции из командной строки. Без этого заливка прошивки становится операцией в несколько ручных действий. 

Чтобы закрыть этот "пробел" я прикупил копеечный USBAsp 2.0, который можно использовать с утилитой AVRDude. Запуск этой утилиты можно прописать в External Tools в Atmel Studio и прошивать микроконтроллер в один клик.

Паяльная ванна

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

Чтобы спаять более-менее сложную схему и не получить комок лапши на плате, надо использовать очень тонкий провод. Для этого идеально подходит МГТФ с сечением 0.03 мм. Он тонкий, гибкий, не ломается. Его тефлоновая изоляция хорошо выдерживает нагрев и при пайке не оголяет лишнего провода. У этого провода есть один большой недостаток - его ну ОЧЕНЬ муторно зачищать руками, обычные стрипперы его не берут. 

В качестве выхода подсмотрел в интернете идею использования паяльной ванны. При правильно подобранной температуре достаточно окунуть конец МГТФ в флюс и потом в расплавленный припой, чтобы за один раз зачистить и залудить кончик, подходящий для припаивания к ножкам микросхемы. Это позволяет в два движения сделать то, что без ванны потребует целой серии ручных операций. 

Первые эксперименты

Дождавшись из Китая и ЧипДипа комплектующих и инструментов, я собрал несколько простейших схем с новым процессором на макетной плате. Для микроконтроллеров своего рода аналогом "Hellow World" является мигающий светодиод ("Blinkenlights"), для мира самопальных компьютеров - это "холостой ход" процессора, когда он без всякой памяти циклически исполняет NOP-инструкции. Когда я увидел в логическом анализаторе заветные меандры сигналов на шине, я сел паять первую версию вычислительного ядра. 

Вид тыльной стороны платы при пайке МГТФ.
Оригинальные материнские платы не
сохранились, на фото - макет видеоадаптера

Задумка была простая - сделать плату с микросхемами, на которой будут разведены основные сигнальные пути, оставив возможность подключаться к каждому сигналу через штыревой разъем. Так появилась гибридная схема из паечной и контактной макетных плат. Этот подход позволил мне опробовать много идей, не гадая каждый раз, включится ли ранее работавшая схема, или нет. В этой схеме я ещё использовал в качестве системного контроллера старую добрую Atmega32, но уже в тот момент мне стало понятно, что для нормальной системы потребуется намного больше сигналов.

На одном из этапов работы я бился с непонятным сбоем системы при обращении к памяти. Логический анализатор показывал полную чушь, а я не мог понять что к чему. Проверки пайки показывали, что всё, вроде бы, в в норме. Только дотошный прозвон контактов на замыкания показал, что две сигнальные линии замкнуты. И только потом с лупой наотсвет я почти случайно увидел тонюсенькую ниточку припоя, соединившую соседние контакты.

 

Новый микроконтроллер и новые амбициозные цели - подключение SD-карт - заставили меня перейти на следующий этап проекта и начать паять более полную схему на большой паечной макетной плате. Этот этап проекта стал для меня большим разочарованием - потратив много часов на кропотливый ручной роутинг проводков по гигантской макетной плате, я в итоге пришёл к нестабильно работающей схеме. Что-то я такое хитрое умудрился сделать при пайке, но система более-менее стабильно заводилась, только если на плату в центре нажать пальцем и слегка её прогнуть.

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

Китай спешит на помощь

Этот неудачный опыт научил меня тому, что с кустарными технологиями пора завязывать. Лапша из проводов и всё такое - это не для настоящих пацанов, надо разводить и делать нормальную печатную плату. Для других своих проектов я уже начал осваивать ЛУТ-метод производства плат в домашних условиях, но здесь решил не рисковать. 

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

1. Плату я разводил двухслойную, чтобы иметь возможность любую дорожку при необходимости точечно разорвать. Правда, мне пока это не потребовалось.
2. Для основных сигналов я заложил штыревые разъёмы, чтобы можно было подключать логический анализатор и/или дополнительные схемы.
3. Сразу заложил в схему шинную архитектуру, разъёмы для SD-карт, PS/2 разъём и достаточно сигналов, чтобы превратить контроллер ещё и в DMA-контроллер.

Тот самый погнутый рычаг ZIP-панели.
Ещё и развернул его на 180 градусов.
Бонусом можно видеть припаянный
проводок - обход ещё одной
ошибки в схеме.

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

Естественно, что я накосячил в схеме, а как иначе? Но самой смешной ошибкой стало то, что рычажок ZIF-панели для ПЗУ упирался в соседнюю микросхему, не давая полностью защёлкнуться. Это была настолько глупая и очевидная ошибка, но она стала возможной из-за того, что я слишком фокусировался на схеме и логике, упустив более комплексный взгляд на систему. К счастью, все ошибки я так или иначе сумел обойти, применив смекалку и грубую силу (да-да, этот рычажок я просто согнул). На этой плате я пока и продолжаю развивать проект, так как она в целом делает всё, что я от неё хочу. 

Отдельная весёлая история приключилась с платой видеоадаптера, которую я спаял для своего компьютера. Схема уже была ранее опробована на макетной плате, поэтому я не ожидал сюрпризов. Но, видимо, что-то забылось из-за долгого перерыва а работе над проектом, и я допустил одну маленькую ошибку, из-за чего схема не запускалась. Юмор ситуации был в том, что я перебрал почти все варианты "сложных" ошибок и даже собирал на стенде макеты, воспроизводившие корректную работу контроллера. На деле же оказалось, что я банально забыл про некоторые особенности микросхемы  программируемой логики и забыл задействовать ножку, которая включала бы выходные буферы запрограммированной схемы. И только после нескольких недель мучений, меланхолично перечитывая datasheet от этой микросхемы, я догадался, в чем проблема.

Но в конечном итоге, именно такие трудности на пути к решению вызывают потом франкенштейновский восторг ("It's alive!"), когда паззл складывается и схема начинает работать. Ради этой радости я и занимаюсь подобными проектами. О том, что именно у меня получилось в результате этих стараний, я расскажу в следующей заметке. А пока всех с наступающим 21-ым годом!

Cobalt-68: Предыстория проекта

С момента прошлой публикации, посвящённой проекту самодельного компьютера, прошло уже три года, но я это время не терял даром, мой проект не стоял на месте. За это время я успел поменять концепцию, преодолеть кучу технических сложностей, прокрастинации и нехватки времени, и добиться неплохого результата. О том, что именно удалось сделать за это время, я и хочу рассказать в цикле из нескольких заметок.

Предыстория

В прошлый раз мы остановились на том, что я создал макет комепьютера на базе классического процессора Z80 (точнее, его "осовремененного" CMOS-аналога). На тот момент у меня в планах было сделать полноценную компьютерную систему в стиле микрокомпьютеров 80-ых.  Моя дальнейшая работа в области компьютеростроения базировалась на этом проекте, но приобрела некотрый сюжетный поворот, о котором я хочу рассказать чуть подробнее.

Начну издалека. Как вы, безусловно, знаете мир настолько и серверного вычисления достаточно прочно занят x86-процессорами (хотя по общему количеству вычислительных устройств ARM-архитектура уже вышла на первое место, в основном за счёт мобильных и встраиваемых устройств). Эта архитектура названа в честь легендарного процессора 8086, вариант которого который был выбран IBM для создания своего персонального компьютера (об этом я писал ранее). Именно IBM PC дал этому процессору и его наследникам "путёвку в жизнь", обеспечив его архитектуре почётное лидерское место на многие годы. Что интересно, IBM PC дал путёвку в жизнь и другому важному феномену IT-индустрии - компании Microsoft.  Кто знает, как бы выглядела сейчас наша индустрия, сделай инеженеры IBM в тот момент другой выбор...

Intel 8080 - первый
культовый процессор

В IBM PC использовался процессор 8088 - "усечённый" вариант знаменитого 8086. Этот процессор был разработан на базе другого очень успешного процессора - 8085, который являлся усовершенствованной версией 8080, который, в свою очередь, развивал идеи, заложенные в самом первом в истории 8-битном микропроцессоре - 8008. 

Процессор 8080 ста

Фредерико Фаджин -
разработчик первого в мире
микропроцессора 4004
и первого 8-битного
процессора 8008

л иконой первой "гаражной" волны персоналок. Его разработчик -  Фредерико Фаджин - после этого проекта ушёл из Intel и основал собственную компанию Zilog, которая стала выпускать процессоры Z80. Этот процессор был развитием 8080, сохранив бинарную совместимость со своим "папой", и став ему прямым конкурентом.

Первые процессоры делались в условиях недостатка опыта и более жёстких технических ограничений, что привело к созданию "вычурной" архитектуры команд. Их потомки унаследовали эти "родимые пятна" первых шагов прогресса, добавив к ним дополнительные навороты для сохранения совместимости. Когда я начал глубже изучать ассемблер Z80 я всё больше и больше разочаровывался в его архитектуре и системе команд. По сравнению   с моей собственной разработкой (писал тут) it looked like a mess. Я ни в коем случае не претендую на превосходство в инженерном искусстве над Фараджем, мой проект был сделан с совершенно иными целями в условиях намного более доступных и мощных технологий. Тем не менее, моё эстетическое чувство оказалось оскорблённым и я решил поискать альтернативу.

Альтернатива была найдена в виде архитектуры Motorola 68000 (часто пишут M68K). Эта компания так же конкурировала за рынок 8-битных микропроцессоров со своей предыдущей серией 6800, хотя её процессоры не были так же популярны как Intel-овские. Разработка этого процессора началась в 1976 году. В отличие от Intel, инженеры Motorola нацелились на создание совершенно новой, более совершенной архитектуры без цели сохранить бинарную или идологическую совместимость с предыдущими наработками. В результате появился процессор MC68000 - 32-битный процессор с 16-битной шиной данных (напомним, его "сверстник" 8086 был 16-битным). Архитектура команд этого процессора очень изящна и элеганта. Видно, что её авторы изрядно вдохновлялись другой легендарной архитектурой PDP-11, которая до сих пор считается эталоном CISC-архитектур. 

DEC PDP-11

Этот процессор предоставляет очень удобную схему с шестнадцатью 32-битными регистрами (восемь для данных и столько же для адресов) и плоскую модель памяти с 32-битными адресами, разделение на пользовательский и супервизорский режимы, удобную схему 8-,16-,32-битных команд и другие хорошие вещи. Надо ли говорить, что я влюбился в этот процессор с первых страниц его datasheet`а, поэтому свой следующий проект я решил делать именно на базе этой архитектуры. 

IBM в рамках проекта IBM PC рассматривала вариант использования процессоров 68000-серии, но к тому моменту они ещё не были полностью готовы. Этот пример хорошо показывает, что оказаться в нужное время в нужном месте намного важнее, чем иметь технологическое превосходство. "Motorola, with its superior technology, lost the single most important design contest of the last 50 years"  Walden Rhines (link).

Тем не менее, разработки Motorola нашли своё применение в большом количество компьютерных изделий. Например, на них были основаны станции Sun Microsystems и некоторые продукты Apple. Благодаря этому сейчас нет проблем найти процессоры любой модели из этой линейки процессоров. 

В следующей заметке я начну подробный рассказ о своём проекте, а пока для затравки рекламное фото моего компьютера. Здесь вы видите систему с потрясающей тактовой частотой в 8 МГц, огромной памятью в 512 килобайт, текстовым видеоадаптером (цветным! поддерживает целых два цвета - чёрный и белый) и клавиатурой. 

В следующих заметках я подбробнее  расскажу об истории проекта, "софте" и "железе". Надеюсь, что эта статья будет полезна и интересна таким же гикам-самодельщикам.

P.S. Ссылка на проект в gitlab: https://gitlab.com/alkid1/cobalt68

Компьютер "Zиркон-Б"

Некоторое время назад я писал о своём проекте компьютера на базе ПЛИС (см. "Проект Янтарь"). Некоторое время этот проект занимал меня, но со временем душа стала просить чего-то более "физического". Все-таки работа с FPGA - это всё то же глядение в монитор и нажимание кнопок. После нескольких небольших проектов, вроде колесных роботов с мозгами на AVR-ах я решил сделать второй подход к компьютерной тематике. На этот раз я решил собрать компьютер из "обычных" микросхем. Мой выбор пал на легендарный процессор Z80, олицетворявший целую эпоху персональных компьютеров.

Надо сказать, этот "материал" поддался мне не сразу. Программа в компьютере (или даже прошивка для ПЛИС) имеет от собранной электрической схемы одно важное отличие. В компьютере не может быть так, чтобы конкретный оператор сложения в 17-ой строке начал сбоить из-за того, что был неаккуратно набран при вводе программы. Когда имеешь дело с электрическими схемами, подобного рода проблем не избежать. Очень весело было убить час, изучая логическую схему и программу прошивки, чтобы обнаружить, что проблема была из-за плохо воткнутого в гнездо проводка. Более того, из-за таких ошибок я умудрился угробить три процессора (благо, я купил их с запасом).

Однако после нескольких прототипов и экспериментов, мне удалось собрать на макетной плате компактный, но в то же время полнофункциональный компьютер со следующими характеристиками:

1. Процессор Z84C00 (CMOS-вариант Zilog Z80) с тактовой частотой 2 МГц.
2. 32 КБ ПЗУ
3. 32 КБ статической ОЗУ
4. Последовательный порт ввода-вывода для связи с Большим компьютером

Все это я назвал "Zиркон-Б". "Zиркон" - это потому что  Z80 + название какого-нибудь драгоценного камня, а "Б" - потому что это уже вторая конструкция в этом проекте.

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

1. Для соединений я активно применял самодельные шины из проводов, "заточенные" под конкретное место в схеме. Это в разы снижает трудоёмкость монтажа и демонтажа схемы. 
2. При подключении микросхемы статической памяти совершенно не обязательно соблюдать последовательность подключения адресных линий, т.к. читать и писать всегда будет только процессор. Это облегчает монтаж (можно шины использовать). Для ПЗУ это не работает, т.к. читает данные процессор, а пишет - программатор.
3. Всю логику генерации управляющих сигналов я реализовал на микросхеме программируемой логики Atmel ATF16V8. Это позволило избежать клубка спагетти и оставить одну микросхему вместо трёх-четырёх.
4. Весь ввод-вывод реализован на микроконтроллере Atmel Atmega32A. Это потребовало применить техническую хитрость, о которой я скажу ниже. Зато появилась возможность в дальнейшем расширять возможности системы за счёт программирования контроллера. Это жульничество, конечно, но на первых этапах позволяет сэкономить время.
5. Для подключения микросхемы ПЗУ я на макетную плату посадил ZIF-панель. Держится так себе, но на порядок снижает количество вырванных из гнезд проводов при снятии микросхемы ПЗУ для перепрошивки.
6. RC-осциллятор на базе триггера Шмитта (74HCT14) генерирует хороший тактовый сигнал только на небольших частотах (100-200 герц).

Подключение Atmega32 к процессору Z80:

Идея использовать контроллер для управления системой несет в себе большой потенциал развития системы, но требует некоторых ухищрений для своей реализации. Дело в том, что процессор Z80 в машинном цикле ввода-вывода даёт строго два такта, в течение которых устройство должно отреагировать. Микроконтроллер не успеет отработать функцию за два такта. Специально для работы с такими "медленными" устройствами в процессоре предусмотрен сигнал WAIT#. Если внешнее устройство подаст на него логический ноль, то процессор приостановит цикл обращения и будет ждать, пока сигнал не вернут в значение "1". Значит нам надо сделать так, чтобы контроллер, обнаружив обращение к себе, выдал нужный сигнал, так? Не так. Контроллер не успеет даже этот сигнал выдать, т.к. это тоже реализовано программно.

Чтобы выйти из ситуации необходимо применить аппаратное решение, которое бы "ловило" процессор в момент обращения к контроллеру. К счастью у меня была под рукой микросхема 74HCT74 - два D-триггера со сбросом и предустановкой. Один из триггеров я подсоединил к системе так, чтобы при обнаружении порога на сигнале выбора микроконтроллера (CE#), он защёлкивался и "держал" процессор. Когда контроллер завершал свои дела, он подавал триггеру сигнал на сброс и "отпускал" процессор.

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

Это решение - буферная микросхема 74HCT245, которая при "пропадании" сигнала CE# просто изолирует микроконтроллер от шины данных ровно тогда, когда надо.

Микросхема ATF16V8:

Эта маленькая микросхема стала для меня огромным подспорьем при разработке логических схем. Она достаточно проста и немногофункциональна (по сравнению с современными FPGA и CPLD), но сочетает в себе два важных свойства:

1. DIP-корпус, который можно монтировать на макетной плате
2. Поддержку широким спектром программаторов.

При этом в неё можно "зашить" комбинационную логическую схему, которую в ином случае пришлось бы "разводить" руками с использованием нескольких обычных логических схем 7400-й серии и кучи проводков со всеми вытекающими следствиями - комок "лапши" на макетной плате, случайные сбои из-за плохих контактов и невозможность уже на второй день разобраться в том, что же ты такого нагородил.

Программируется эта микросхема на весьма малоизвестном проприетарном языке CUPL.

Программирование:

Для программирования системы я применял сразу несколько инструментов. Прошивку микроконтроллера я писал при помощи Atmel Studio 7. Программы для самого компьютера я готовил при помощи набора инструментария SDCC, куда входят ассемблер и компилятор языка С.  Для программируемой логики есть старая программа WinCupl, заставляющая вспомнить с ностальгие времена Windows 3.11 и 95.

Для заливки программ в микроконтроллер, PLD и ПЗУ использую недорогой программатор WizardProg87i (судя по всему - российский клон китайского MiniPRO TL866), который умеет программировать много разных микросхем. Контроллер он умеет программировать некоторые микросхемы так же и через ISP-подключение, что позволяет программировать его без демонтажа с макетной платы. Конкретно, я так программировал Atmega32 (attiny в режие ISP этот программатор "не умеет").

Полный список компонент:

Вот полный список компонент, которые я использовал, чтобы собрать систему:

1. Процессор Z84C00AB6
2. 32K EEPROM Atmel AT28C256
3. 128K SRAM Ultron UT621024-70LL (используется только 32К)
4. Микроконтроллер Atmel ATMEGA32A
5. Буфер 74HCT245 - 2 шт.
6. Сдвоенный D-триггер 74HCT74
7. Микросхема программируемой логики Atmel ATF16V8B
8. Кварцевый генератор частоты 2 МГц.
9. Адаптер USB<->UART Wavesahre FT232
10. ZIF-панель SCL-28 (для монтажа ПЗУ).
11. Макетная плата SYB-800
12. Провода, резисторы - много.

Наполеоновские планы:

Как видно, на макетной плате осталось ещё больше половины места - есть куда расширяться. Следующие шаги, которые я планирую сделать для развития этого проекта:

1. Добавить MMU, который позволит адресовать 1 МГ адресного пространства через механизм переключения банков.
2. Добавить поддержку SD-карты.
3. Воткнуть "нормальный" UART вместо микроконтроллера.
4. Сделать самодельный VGA-адаптер
5. Собрать механическую клавиатуру с закосом "под старину" - клавиатуры старых компьютеров в до-IBM-PC-шную эпоху

Тепличные системы

Наверное, все сталкивались с ситуацией, когда код в продукте - какое-то страшное нагромождение, которое "хочется взять и .... переписать", или бизнес-процессы в компании закручены клубком и всё как-то не работает. Часто возникает желание "начать с чистого листа" и в спокойной обстановке "сделать всё по уму". Но не выходит, потому что постоянно "мешают" - отвлекают каким-то запросами, проблемами. Клиент у них там чего-то резко захотел странного, надо быстро деплоиться, issues от саппорта сыплются, руководство срочно требует чего-то такого всем куда-то внедрить, чтобы работать лучше стали.

Сегодня я бы хотел поговорить о стремлении "сделать всё по уму" и о том, почему это опасно делать. Эта заметка навеяна моим личным опытом, а так же книгами Нассима Талеба, где я увидел очень хорошие формы для тех мыслей, которые уже некоторые время бродят у меня в голове.

Итак, о чем мечтает каждый автор? О том, чтобы ему дали карт-бланш ("чистый лист") на то, что бы разработать что-то в соответствии с лучшими практиками, технологиями и методологиями. Чтобы его не отвлекали в этой работе от стремления к идеалу, не торопили, заставляя "срезать углы". Дайте уже спокойно поработать! 

Это относится вовсе не только к программным продуктам, это может относиться к любым системам. Например, к организационным структурам и пронизывающим их бизнес-процессам.

Эта идея действительно выглядит привлекательно - клубок проблем в текущем легаси тянет нас назад, не дает расправить крылья и устремиться к цели. Как было бы хорошо сбросить этот балласт его со всеми проблемами, и в спокойной обстановке, с чистого листа сделать всё заново, не правда ли? Эту идею часто удается даже "продать" спонсорам, во власти которых организовать тепличные условиях (я видел такие примеры). Но, как-то так получалось на моем опыте, что подобные начинания (в которых я участвовал или же был свидетелем) стабильно заканчивались одним и тем же - деньги и время потрачены, а на выходе результат столь чудовищного качества, что не знаешь как его к делу приспособить. 

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

Каждый раз, когда мы беремся что-то изобретать, у нас есть гипотеза о том, что и зачем мы делаем. Она появляется у нас в голове из предыдущего опыта, от того, что мы поговорили с какими-то людьми и они передали нам свои идеи, что мы где-то что-то прочитали или услышали. Из всего супа идей варится наше понимание цели и ожидаемого результата деятельности. Сколько бы у нас не было опыта и информации, то, что мы имеем - это всегда только гипотеза, которая всегда более или менее неверна. 

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

И вот здесь тепличные условия загоняют нас в ловушку ошибки подтверждения. Когда жизнь сама не подбрасывает нам "черных лебедей" - фактов, опровергающих гипотезу - процесс разработки легко вырождается в своеобразный интеллектуальный декаданс. Он начинает вместо решения реальных проблем обслуживать фантазии авторов об идеальном результате - логичном, симметричном, эстетичном. И, конечно же, реализующим самые модные в данном сезоне концепции. 

Талеб называет этот стиль мышления "платонизмом" - предпочтение фокусироваться на идеальном в противовес реальному. Забвение того факта, то реальность не совпадает с нашими представлениями о ней. Платонизм-по-Талебу создаёт ложное ощущение того, что мы понимаем, что происходит. Ложное ощущение уверенности в себе. Действительно, у нас же такие красивые и передовые модели, что может пойти не так?

Чтобы избежать этого, необходимо внешнее давление. Это необходимо так же, как организму для развития здоровой иммунной системы необходима разнообразная внешняя инфекция. Без нее иммунитет получается слабый, а здоровье хрупкое.

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

Окей, это всё была философия и теория. Какие практические выводы из всего этого сделал для себя я?

"Top-down" подход

1. Если видишь, как узкий круг лиц за закрытыми дверями принимает решения о реорганизации - жди беды. Оттуда вылезет какой-нибудь процессный монстр. Перед тем, как издохнуть он успеет помотать нервы сотрудникам. В такой ситуации надо либо сразу искать убежище, либо пытаться побиться в этот "узкий круг", чтобы заранее воздействовать на результат.
2. Если решение разрабатывается в "top-down" подходе, где берут некую концепцию и пытаются "натянуть" её на текущую реальность - жди беды. Это один из тех методов, на которые надо наклеить предупреждающий знак - "никогда не пользоваться". 
3. Бойся красивых, логичных и симметричных концепций - они приведут тебя в ад. 
4. Если всё идет слишком гладко - жди беды. Скорее всего, выбран именно тот путь "проверки", который подвержен ошибке подтверждения. 
5. Если кто-то даёт точные прогнозы - не верь им. Если таких прогнозов требуют от тебя - прояви скромность и честно скажи: "не знаю".
6. Если не видишь в своей идее слабых мест, это не значит, что их нет. Это значит только то,что ты их просто не видишь. Включай "диверсионное мышление", обсуди её с самым вредным и критически настроенным коллегой, ищи failure stories схожие по ситуации. Ищи опровержения.
7. Не надо расстраиваться, если "мешают работать", подсовывая "неудобные проблемы". Раз тебя достают, значит ты делаешь что-то нужное. Гораздо хуже, если о твоей работе не вспоминают. Скорее всего, ты уже оторвался от реальности, и неизбежное столкновение с ней будет болезненным.

Ничего нового не сказал, правда? Подвох в том, что все эти принципы просты в теории, но сложны на практике. Они идут против естественного для человека хода мыслительного процесса, они создают дискомфорт. В кутерьме и спешке, когда нет времени спокойно подумать, легко поддаться искушению и сделать ровно наоборот. Чтобы применять всё это на практике, необходимо иметь высокий уровень интеллектуальной дисциплины. По моему глубокому убеждению это вопрос личной компетенции каждого человека. Никакие навязанные извне процессы и практики не помогут, если этого нет внутри.

За сим прощаюсь с вами, спасибо за внимание.

Проект "Янтарь"

Некоторое время назад я делился (тыц, тыц) своими впечатлениями от первых наивных шагов в цифровой схемотехнике. С тех пор прошло несколько месяцев в течение которых мой проект неспешно развивался. В этой заметке я хотел бы подытожить результат полугодовой работы над своим собственным компьютером, который я назвал "Янтарь".

Что такое "Янтарь"?

Если коротко - то это мой собственный компьютер, придуманный с нуля, и реализованный на базе отладочной платы Terasic DE0 с чипом Altera Cyclone III. Он имеет собственную архитектуру, набор команд и некоторый набор инструментария разработчика и уже написанных программ. 

Компьютер "Янтарь" на фоне Большого Компьютера

Каковы характеристики компьютера на данный момент?

• Разрядность процессора - 16 бит.
• ОЗУ - 65536 16-битовых слов.
• Тактовая частота: 160 КГц.
• VGA-адаптер с монохромным текстовым режимом 80х30.
• PS/2-клавиатура.
• USB UART-модуль Wavesahre FT232 для связи с "большим" компьютером.
• Инструментарий разработки: ассемблер "ALASM" (написан на C#)
• Программная оболочка: программа-монитор "M3004" 

Зачем это нужно?

Этот проект имеет исключительно развлекательные и самообразовательные цели. Во-первых, я давно хотел разобраться в том, как работает компьютерное железо. Шутка ли, больше двадцати лет программировал, а до конца этого не понимал. Во-вторых, меня всегда немного завораживала старая компьютерная техника. Чтобы убить двух зайцев, я решил разработать с нуля собственный компьютер в духе классических домашних компьютеров эпохи процессора Intel 8080, его брата - Zilog Z80 и операционной системы CP/M.

Система

Здесь я в двух словах опишу систему, как она есть сейчас. На этой схеме изображены основные блоки:

В принципе, тут должно быть всё понятно, отмечу лишь несколько моментов:

1. Первые 16К ОЗУ реализованы на встроенных блоках памяти, находящихся на чипе ПЛИС. В них прямо в VHDL-коде "зашита" первоначальная программа, с котрой стартует компьютер. Для остальных 48К используется SDRAM-чип, расположенный на плате.
2. Одна из кнопок на плате напрямую заведена на шину как сигнал аппаратного прерывания. Она используется для прерывания программы и вызова отладчика.
3. На борту у платы есть микросхема электрического интерфейса для RS232, но у меня не нашлось под рукой нужных разъемов, поэтому я купил отдельный UART<->USB адаптер Waveshare FT232 и подсоединил его через GPIO-выходы на плате.
4. Я пока не освоил запись в Flash-память, поэтому использую этот чип как ПЗУ. 

Системная шина устроена достаточно примитивно и состоит из следующих сигналов:

• Данные - 16 бит.
• Адрес - 16 бит.
• Сигнал чтения.
• Сигнал записи.
• Сигнал выбора пространства ввода/вывода.
• Сигналы запроса на прерывание - 16 бит.

Процессор

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

• SP (stack pointer) 
• BP (base pointer) 

последний указывает на фрейм текущей подпрограммы.

Система команд выполнена в духе так называемых "load/store" архитектур. Практически все операции выполняются над значениями в регистрах или над регистром и константой. Команды load/store поддерживают немного более широкий список режимов адресации:

• Абсолютный адрес: ld R0, [0FC00]
• Адресация через регистр: ld R0, [R1]
• Адресация через регистр + константа: ld R0, [R1 + 100]
• Адресация через регистр + регистр:     ld R0, [BP + R1]

Для косвенной адресации могут применяться любые регистры из вышеперечисленных.

Микрокод процессора похож на примитивный ассемблер и выполняется строго последовательно, поэтому такты расходуются достаточно неэффективно. Вот так выглядит мирокпрограмма операции сложения регистра с константой:

ADDC:
INI OA, OP_ADD; // Установка кода операции АЛУ
FETCH;          // Вычитка слова с константой
MOV O1, REG1;   // Инициализация первого операнда
MOV O2, DATA;   // Инициализация второго операнда
MOV REG1, RES;  // Запись результата
END;

Как видно, пять микрокоманд. С учётом дополнительных издержек - 7 тактов. Такая чудовищная неэффективность процессора есть результат сознательного выбора - чем проще, тем лучше.

Из интересных особенностей процессора могу отметить встроенный механизм переключения контекста: по команде или по прерыванию процессор может атомарно сохранить своё состояние в ОЗУ и считать новое состояние. Этот механизм применяется для обработки прерываний, так же для управления программами в мониторе.

Ассемблер

Ещё в самом начале работы над виртуальной версией процессора я быстро понял, что программирование в машинных кодах - это для меня слишком брутально и хардкорно. Тогда я написал первую версию ассемблера на VBA. С тех пор я два раза переписал его на C# и теперь он приобрел достаточно законченный и функциональный вид. Вот так выглядит процедура вывода строки на экран:

subroutine print(message)
    push    R0
    push    R1
    ld      R0, [BP + message]
loop:
    ld      R1, [R0]
    cmp     R1, 0
    je      [exit]
    out     R1, [TTY]
    inc     R0
    jmp     [loop]
exit:
    pop     R1
    pop     R0
    return
end

Ассемблер написан с использованием парсера Sprache, который позволил достаточно быстро и без заморочек описать синтаксис. Правда, как оказалось, для более сложных случаев он не годится, поэтому я сейчас гляжу в сторону Irony.

Монитор

Венцом работы на данный момент является программный монитор "M3004" (назван так потому что эту версию я начал разрабатывать 30 апреля). По мере того, как я переходил от разработки аппаратной части к программной, всё больше появлялась потребность в какой-то оболочке, которая бы облегчила отладку и обеспечила бы базовый инструментарий для управления компьютером. Так постепенно появился и стал развиваться Монитор. Что умеет монитор делать сейчас?

• Загружать и запускать программы из ПЗУ, а так же из последовательного порта
• Прерывать исполнение программы по аппаратной кнопке, исследовать и модифицировать состояние памяти и регистров.
• Выполнять программу по шагам.
• Ставить точки останова.
• Читать и писать в порты ввода/вывода

На следующей картинке видно, как была загружена программа, и установлена точка останова. После того, как програма "налетает" на неё, управление  предаётся монитору, где можно проинспектировать состояние и продолжить отладку. Монитор занимает верхние 4К слов адресного пространства, оставляя всю нижнюю память для отлаживаемых программ. Для прерывания программы можно использовать аппаратную кнопку на плате.

Всего Монитор - это ~22 килобайта кода на ассемблере, которые в итоге собираются в ~3500 машинных слов. Потребление памяи машинным кодом оказалось несколько выше, чем я ожидал, но я пока не оптимизировал код.

Заключение

По результату полугодовой работы получилось достаточно функциональный компьютер, который демонстрирует свою работоспособность. Схема, конечно, получилась не без огрехов которые регулярно всплывают в ходе её доработки. Оно и понятно - я действую больше наугад, чем "по книге". Основной нерешённой проблемой для меня остаётся создание устройства долговоременного хранения "на борту" - я так и не смог пока научиться писать в Flash-чип, да и с ним есть определённые проблемы. Подумываю о том, чтобы прикупить дисковод и дискеты и научиться взаимодействовать с ними. Другое направление деятельности - развитие инструментария. Программировать на ассемблере не так уж и весело, хочется реализовать язык высокого уровня. Ну и, наконец, трансформировать Монитор в полноценную операционную систему по типу CP/M

История появления IBM PC

Недавно я прочитал в вики статью про IBM PC. Это был первый компьютер, с которым я близко познакомился, поэтому я до сих пор испытываю к нему теплые ностальгические чувства.

В статье была историческая справка о том, как именно в недрах IBM зарождался и шёл этот проект. Я её прочитал, не ожидая для себя ничего интересно. Между тем, я нашёл там весьма любопытную и поучительную историю, которая может кое-чему научить.

Когда танцору не яйца мешают...

Для понимания всей изюминки истории надо немного понимать, что из себя представляла IBM на рубеже 70-80ых годов. Это была вертикально интегрированная компания, которая производила дорогие мейнфреймы для толстых корпоративных клиентов. Вся их культура и традиция была заточена под это. Они делали всё своё от схем до софта. Они не пускали никого в свои системы и не публиковали технической документации. Они привыкли к длительному циклу разработки решений. 

В то время начал зарождаться совершенно новый рынок - рынок недорогих персоналок - который был ориентирован на небогатого массового потребителя. На рынке действовали небольшие компании (типа MITS) - стартапы в современной терминологии. IBM не хотела упустить этот рынок, но не знала, как его завоевать. Бытовало мнение, что "выпустить персональный компьютер в IBM - это всё равно, что научить слона танцевать чечётку"

Тащи динамит, строить будем

Самое прекрасное в этой истории то, что руководство компании прекрасно понимало положение дел и было достаточно смелым, чтобы сделать смелые шаги. Чтобы справиться разрывом между тем, что надо сделать, и тем, что может сделать существующая система, в IBM пошли на радикальный шаг - создали отдельную организационную единицу, которой разрешили действовать по своему усмотрению, положив всё, что нужно, на сложившиеся традиции, практики и процессы. Не будучи связанные этими ограничениями, они сумели очень быстро выкатить новый продукт .

Они сделали все ровно наперерез тому, как это было принято в компании делать ранее. Они не стали делать "всё своё", а положились на готовые компоненты от других производителей. Собственно, известная история с покупкой MS-DOS, которая открыла Microsoft дорогу в светлое будущее, обусловлена именно этим обстоятельством. Не желая ждать разработки собственной ОС и нести связанные с этим риски, они положились на готовое решение о стороннего вендора.

Другой революцией стало открытие архитектуры системы и публикация исчерпывающей документации, позволяющей другим компаниям производить совместимые компоненты. Для компании, у которой vendor lock-in был органической частью рыночной стратегии, это было очень смелое решение. Прекрасно понимая, что IBM не сможет быстро вывести на рынок достаточное количество периферийных устройств, они дали возможность другим производителям создавать экосистему для их компьютера.

Кроме того, впервые использовались новые каналы продаж и обслуживания клиентов - независимые магазины компьютеров и сервисные центры. Понимая, что компания не умеет работать с массовым клиентом, они отдали эту работу тем, кто умеет

Самобытный Agile?

Весьма интересно описание того, как работала группа, занимавшаяся разработкой программной части нового компьютера:

Dave Bradley, изобрёл
"три весёлые клавиши"
Ctrl-Alt-Del

About a dozen people made up the first development team, recalls Dave Bradley, who wrote the interface code for the new product. "For a month, we met every morning to hash out what it was this machine had to do and then in the afternoons worked on the morning's decisions. We started to build a prototype to take — by the end of the year — to a then little-known company called Microsoft." The team beat that deadline. The engineers were virtually finished with the machine by April 1981, when the manufacturing team took over.

Хотя это и не сказано нигде явно, вырисовывается картина того, что сейчас бы назвали "гибкой разработкой".

Итог

Группа работала год. За первый месяц они разработали и предоставили бизнес-план, в конце года - работающий прототип компьютера. Результатом стало то, что IBM сумела против всех ожиданий не только успешно дебютировать на этом новом и непривычно для себя рынке, но и занять там лидирующее положение, определив стандарт де факто на персональные компьютеры. 

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

Так же это история о том, как настоящий прорыв был сделан небольшой, но сфокусированной и компетентной группой в рамках большой компании. Ведомая Уильямом Лоувом группа насчитывала 12 человек. В неё попадали добровольцы, увлеченные новым проектом

Ну и наконец это история о том, что группа профессионалов, не связанная спущенной сверху бюрократией, способна родить самый настоящий гибкий процесс задолго до появления монетизируемого бренда "Agile Development". Это подтверждает идею о том, что гибкие процессы являются результатом соответствующей культуры, а не наоборот.

Запись в дневнике после удаления зуба мудрости

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

Как и все разработчики, однажды я был очарован передовыми идеями объектно-ориентированного подхода, паттернами "Банды четырёх", компонентной объектной моделью и мантрами "все есть объект". В институте нас учили, что ООП - это Единственный Правильный Путь Программирования, иные парадигмы отметались как устаревшие и недостаточно продвинутые. Объектная истерия тогда изрядно захлестнула индустрию. Помню, как одно время сильно пиарили ООБД, которые должны были похоронить РСУБД как класс, но почему-то не взлетели. Я был очарован, но одновременно и подавлен: у меня никак не получалось достичь гармонии. Мои системы классов были запутаны, я тратил часы и дни пытаясь придумать идеальную иерархию, а потом тратил вдесятеро больше времени, борясь с полученными монстром. От этого я натурально впадал в депрессию и не хотел возвращаться к своим программам.

Первой вехой на пути к освобождению ума стало открытие, что в процедурном стиле можно написать очень хороший код, который будет понятен, расширяем и весьма сопровождабелен. Это заставило меня пересмотреть свои взгляды. Оказалось, что качество кода и пути его достижения не зависят от выбранной парадигмы. Они фундаментальны и приходят с опытом. Если ты делаешь BDUF при отсутствии исчерпывающих вводных, то ты дурак вне зависимости от того, какое у тебя любимое ключевое слово - "class" или "procedure". Или даже "predicate". Плохо ли ООП? Ничуть! Проблема не в парадигме как таковой, а в людях, которые уверовали в её чудодейственную силу решить все наши проблемы. И лично во мне, поскольку я тоже уверовал и тратил время на достижение "объектной чистоты" вместо того, что бы обучаться фундаментальным навыкам, критичным для своего дела.

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

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

Управление - это наука о людях и окружающем мире. Умение разговаривать и договариваться, давать и принимать обратную связь, выстраивать рабочие отношения, планировать и координировать совместные действия, учиться и обучать, доверять и проверять, надеяться на лучшее, рассчитывая на худшее, соизмерять свои амбиции со своими силами, давать и держать слово, планировать свое личное время, искать решения проблем, и т.д. Все это нужно для успешной работы, как бы ни называлась книжка, по которой вы строите свою организацию. Это фундамент на который опирается любой метод. Нет фундамента - пиши пропало. Провалится и Scrum, и PMBOK. Чтобы заниматься строевой подготовкой, надо сначала научиться ходить.

Беда в том, что про этот фундамент как-то... забывают, что ли. Открываешь первые десять ссылок в гугле по слову "Scrum", там все одно и то же: роли, спринты, бэклог, планирование-дейлимитинг-ретроспектива. Вроде и написано в манифесте, что "люди и взаимодействие важнее процессов и инструментов", но почему-то упор делают не на том, как научить людей друг с другом разговаривать, а все как-то о процессах и инструментах.

Плох ли Agile? Ничуть! Это хороший и полезный инструмент для ряда задач, но он не заменяет фундаментальных навыков, необходимых для работы. Наоборот, он весьма требователен к их наличию.

Этот опыт изменил мой подход к работе: от развития "сверху вниз" я стал переходить к развитию "снизу вверх". Это означает, что я не занимаюсь внедрением готового процесса ("с понедельника живём по скраму"), а занимаюсь систематическим поиском и решением конкретных проблем, а так же развиваю в себе и своих коллегах базовые навыки, составляющие тот самый фундамент. Это не так гламурно, как размахивать флагом с новым модным названием. Это долгая и кропотливая работа, но эти вложения окупаются. Agile, Scrum, PBMOK, Теория ограничений Голдратта и прочие полезные вещи лежат у меня в загашнике и применяются по мере необходимости, когда я считаю их подходящими к ситуации.

За сим свои бухтения прекращаю.