Azure DevOps для Commodore 64?

Я – великий фанат сервісу Azure DevOps з самих ранніх його днів, коли він ще називався Visual Studio Online. Я використовую його в професійних і особистих цілях,
і рекомендую його своїм клієнтам з консалтингу.

Однак скільки б я не розхвалював цю платформу, часто буває важко переконати розробників на Node або Java в тому, що Azure DevOps чудово впорається і з їх проектами, не гірше, ніж для .NET. Незалежно від кількості демонстрацій та презентацій, що спростовують упередження, в будь-якій групі знаходяться люди, які свято вірять у те, що ADO для них не підійде, тому що це «інструмент від Microsoft».

Відставивши у бік філософські дебати, я можу пояснити більшу частину опору відсутністю розуміння того, як Azure DevOps розвинулася з свого попередника Team Foundation Services (TFS), і стала кращим у своєму класі набором інструментів, здатних підтримувати проекти будь-якого розміру на будь-якій мові і в будь-якій платформі». Питання в тому, як я можу незаперечно довести це раз і назавжди?

Я трохи погрався з цією ідеєю, а потім мене осінило. Доказ треба робити, не створюючи чергову демку CI/CD для микросервисов SpringBoot, розвертають для Kubernetes на AWS – його потрібно робити з більш ексцентричним підходом.

А тепер щось зовсім інше

Що, якщо ми перестанемо концентруватися на сучасних мовах і платформах, і перенесемося на 30 років назад, щоб подивитися, чи можна використовувати сучасні засоби і ADO для розробки, складання, розбивка на модулі та впровадження програми, написаної для 8-бітної комп’ютерної платформи?

Як і у випадку з іншими демками для ADO, створюваними мною в минулому, я хотів показати абсолютно закінчений продукт від редагування коду, його перевірки, і так далі, аж до живого оточення, в якому можна спостерігати за змінами.

В теорії все це звучало непогано, але реальним питанням стало – з чого почати? Це, очевидно, була не така ситуація, в якій можна передивитись StackOverflow в пошуках попередніх прикладів. Однак, обговоривши ідею з друзями і колегами (всі вони вирішили, що я рушив), я почав оформляти свою ідею.

Я вирішив, що демонстраційна програма повинна бути написана в 8-бітному машинному коді для Commodore 64 за допомогою редактора VS Code. Ісходник буде оброблятися репозиторієм Git на ADO, а конвеєр CI/CD буде відповідати за білди, модулі і впровадження в Azure. Я вже почав підозрювати, що мої друзі були праві, і дах моя вже поїхала, але все ж ця ідея здавалася цікавим викликом.

Вибір редактора

Всім відома приказка про вибір правильного інструменту для конкретної роботи. Це застосовно і для роботи по дому, і для ремонту автомобіля, і для написання коду.

Як розробник .NET, більшу частину часу я проводжу в Visual Studio 2017. Якщо мені треба переключитися на проект на Java або написання нативних програм для Android, я запускаю IntelliJ або Android Studio відповідно. Який же редактор мені використовувати для машинного коду C64?

Хочете – вірте, хочете – ні, але сьогодні існує кілька непоганих редакторів, придатних для написання CBM. Я погрався з деякими з них, але насправді я хотів використовувати Visual Studio Code. Я використовував VS Code для інших своїх проектів, і мені він здався досить гнучким, комфортабельним, так і наявність вбудованої інтеграції з git було приємним доповненням.

Читайте також  OpenSceneGraph: Основи роботи з геометрією сцени

Мінусом цього рішення було те, що мені довелося б пожертвувати підсвічуванням синтаксису в асемблері 6510, і я б просто витріщався на чорний текст на білому фоні. Ця ситуація не відповідає моєму заяви про «правильному інструменті».

Раптово я вирішив сходити на Visual Studio Marketplace, і подивитися, чи немає там якогось розширення для VS Code, придатного для вирішення мого завдання. Я був приємно здивований знайти там кілька розширень, призначених для роботи на асемблері. На жаль, жодне з них не було заточено під ACME Cross Assembler, обраний мною для проекту.

Мене це не зупинило, і, не бажаючи заново переживати монохромні аспекти розробки 80-х, я зарився в документацію про створення розширень для VS Code. Через кілька днів я з радістю випустив першу версію розширення для Visual Studio Marketplace.

І це вправу виявилося більш корисним, ніж здавалося спочатку.

У свій час я так і не нагострили в написанні програм на асемблері. Кілька разів я намагався його вивчити, але зазвичай відчував нудьгу або роздратування, і переходив до чогось іншого. Створивши плагін, я не тільки дізнався про механіку створення розширень для VS Code, але і придбав непогане розуміння незрозумілого синтаксису і коди операцій.

Озброївшись відповідним редактором і кількома старими книжками з програмування з 80-х, я почав писати код. Дуже швидко у мене вийшла працююча програма, яка імпортує музичний файл формату SID і програє 8-бітну версію пісні Beatles When i’m 64 (це стара жарт користувачів Commodore, але для даного проекту вона, здається, підходить в самий раз).

До цього моменту я компилировал і тестував програму на ноутбуці. Ісходник був закомичен на репозиторій git, тому наступним кроком стала необхідність створити білд для Continuous Integration.

Одна з вражаючих здібностей ADO – можливість обробляти практично будь-яку ситуацію з CI/CD. Прямо «з коробки» сервіс пропонує безліч встановлених завдань, що дозволяє вам швидко створювати CI/CD ланцюжки для більшості сучасних проектів всього в кілька кліків.

Якщо в базовий сервіс ваші потреби не входять, то Marketplace звичайно надасть вам безліч різних відповідних інструментів. Якщо і це не спрацює, можна накидати скрипт на PowerShell, виконує необхідну вам роботу.

Очевидною проблемою проекту стало те, що незважаючи на широкий спектр можливостей сервісу, крос-асемблера і створення образів дисків для Commodore 64 просто не було. Я, звичайно, міг створити спеціальну віртуальну машину в Azure з необхідними мені інструментами, або піти по шляху PowerShell, але хіба це було б цікаво?

Також я недолюблюю виртуалки в хмарі, і для цієї вправи я хотів використовувати Hosted Agents, тому вибір у мене залишався тільки один. Щоб довести те, заради чого і замислювалося все це вправа, я вирішив, що найкраще буде створити власне розширення для обробки всіх цих завдань.

Розширення ACME Cross-Assembler

Перше розширення, необхідне для моєї ланцюжка CI, повинно було компілювати мій асемблерний код в машинний код C64. Для цього мені потрібно було встановити крос-асемблер на одного з серверних агентів складання [hosted build agent].

Асемблер – це програма, що перетворює людино-читається мова асемблера в реальний машинний код, призначений для конкретної двійкового обробника. Зазвичай машинний код генерується для процесора, що використовується в машині, на якій він працює. Крос-асемблер робить наступний крок у перетворенні коду, дозволяючи генерувати машинний код для іншого процесора.

Читайте також  Цікавий JavaScript: Без фігурних дужок

Як я вже згадував, для свого проекту я вибрав ACME Cross-Assembler, оскільки його рекомендують для розробки під Commodore. Він також підтримує широкий спектр інших 8-бітних проектів, наприклад, Nintendo Entertainment System або сімейство Atari, що використовує процесори 65xx.

Мені потрібна більша частина дня, щоб на основі документації і прикладів, забезпечених Microsoft та іншими джерелами, щоб написати, перевірити і опублікувати на Marketplace робочу версію розширення.

При запуску завдання автоматично завантажує останню версію ACME Cross-Assembler і запускає його з параметрами, що дозволяють створювати підсумковий файл для цільової платформи. Одна з переваг, пов’язаних з вибором саме ACME, полягає в тому, що велика частина параметрів для складання програми вбудована в вихідний код, що звело до мінімуму кількість вхідних даних, які потрібно було визначати у розширенні.

Є у кого дискета борг?

Наступний крок ланцюга – перевести програму у формат носія, сумісного з Commodore 64, тобто, помістити її на дискету. З такою проблемою розробники також не стикаються в повсякденному житті. На щастя, для виконання цього завдання існують окремі програми.

VICE – самий популярний емулятор для Commodore. У нього є не тільки безліч емуляторів для кожної із різних моделей, що випускалися Commodore, але і кілька корисних інструментів, включаючи менеджер віртуальних дисків c1541. Образи дисків, створених з його допомогою, можна використовувати з емулятором, копіювати на фізичний носій (гнучкий диск низької щільності 5¼”), або завантажувати на microSD і використовувати з емулятором SD2IEC drive emulator.

На відміну від завдання ACME, що бере всі налаштування з заголовка вихідного файлу, дискова утиліта c1541 покладається на CLI, і користувачеві доступно безліч налаштувань управління диском. Для мого розширення я вирішив зупинитися тільки на властивостях, необхідних для мого завдання, але навіть і тоді переді мною постав вибір, пов’язаний з тим, наскільки ґрунтовною мені потрібно було її зробити.

Commodore випускала три різних моделі дисководів, визначалися методом обробки обсягів дисків на основі формату та типу носія. Базова модель, знайома більшості користувачів, могла працювати тільки з односторонніми дисками об’ємом 170 Кб (кілобайт. Батьків запитаєте). Більш пізня модель, 1571, що використовувалася на Commodore 128, могла працювати з двосторонніми дисками, обсяг яких збільшувався до 340 Кб. Я вирішив додати розширення гнучкості, тому додав підтримку різних форматів дисків у вигляді установки, яку можна вибирати в інтерфейсі через випадаюче меню.

Оскільки у мене вже був робочий приклад, створення цього розширення йшло набагато швидше. Я дізнався дещо нове, що дозволило мені поліпшити код і для розширення ACME.

Як і у випадку крос-асемблера, необхідне скачується з репозиторію проекту з відкритим кодом і встановлюється в агента складання. Завдання створює образ диска в потрібному форматі, а потім на нього копіюється файл із завдання складання. Отриманий файл переміщується в директорію Build Artifacts, звідки його можна скачати.

Це що ж виходить – стільки роботи, а в результаті треба завантажувати файл? Це повинен бути навчальний матеріал за CI/CD. Якщо нам потрібно довести нашу позицію, нам треба розгорнути програму на машині так, щоб її можна було використовувати в якості демонстрації.

Читайте також  Як зробити пошук користувачів з GitHub використовуючи React + RxJS 6 + Recompose

Флоппинет відключений

Працюють версії реального комп’ютера Commodore 64 і дисководу 1541 – річ досить рідкісна, не кажучи вже про те, що велика і важка. Крім того, вони здатні виводити картинку на сучасні монітори без спеціальних адаптерів, а це сильно обмежує ефективність демонстрації.

У Commodore SX-64 (першого «портативного» кольорового комп’ютера з випускалися великими партіями) був вбудований монітор, проте розміром він приблизно з мій чемодан для ручної поклажі, і важить близько 10 кг Уявіть собі, як важко було б пройти через службу безпеки аеропорту з таким монстром?

Недавно випущений C64 Mini має досить малий розмір, щоб з ним можна було подорожувати, можливість завантажувати програми з USB і вихід HDMI. У деяких випадках це був би один з варіантів. Але він все одно не досягає потрібної мети.

Реальна проблема – не в портативності заліза, а у відсутності автоматизації. Необхідність переносити програму з ноутбука на машину за допомогою флешки не дозволяє повністю розкрити можливості ADO в презентації.

Варіант без сервера

Як я вже згадував, VICE – самий популярний емулятор для Commodore. Його портувати на Windows, Linux, Mac OS X, MS-DOS і безліч інших ОС. Однак для хмарної розробки такий варіант зажадав б налаштування VM в якості хоста, а я хотів обійтися рішенням, що не вимагає сервера.

Крім згаданих версій, у VICE є варіант для JavaScript, нормально працює в більшості браузерів. Хоча фронтенд-розробка – не моя стихія, я зміг зварганити пристойну чуйну сторінку.

Для організації ланцюжка випуску я завантажую файл з образом диска в каталог в тому ж сховище. Я пов’язав це з викликом додатки Azure Function App, повертає список доступних образів дисків. Вибір одного з них з випадаючого меню автоматично завантажує і запускає його в JavaScript-емулятора.

Система працює не тільки з моєю програмою, у мене вийшло створити ланцюжок для розгортання і запуску програми на Commodore 64 BASIC.

10 PRINT "HELLO WORLD"
20 GOTO 10

Закінчуємо

DevOps для Commodore 64? Немислимо!

Сенс цієї вправи полягає не тільки в доказі того, що коли про Azure DevOps заявляють, що вона підтримує «будь-яка мова і будь-яку платформу», мають на увазі не тільки все, що пов’язано з Microsoft (хоча версія BASIC для Commodore була куплена за ліцензії у Microsoft). Воно відволікає нас від концентрації на технологічних аспектах і змушує людей виходити за штучні рамки, призначені ними для самих себе.

Незалежно від виправдань, заяви типу «це не спрацює» часто рівнозначні заявами «ми завжди це робили так-то, навіщо щось змінювати». Обидві фрази демонструють небажання рости і розвиватися, адаптуватися до постійно мінливого технологічного ландшафту, долати виклики, породжувані цими швидкими і агресивними змінами.

DevOps – це не інструменти. Інструменти в підсумку виявляються просто засобами для досягнення мети, незалежно від того, хто їх публікує.

Щоб DevOps стали успішними для організації, необхідно змінити стиль мислення і розвивати нашу корпоративну культуру. Нам потрібно прийняти багато нових ідей, заново обдумати те, що, як нам здається, нам відомо, і відійти від думок типу «це тут не спрацює», тому що ми не пробували це раніше.

Створення ланцюжка CI/CD для 30-річного комп’ютера не має цінності для бізнесу, крім явної ілюстрації даної точки зору.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *