Commodore 64向けのAzure DevOps？

私は、まだVisual Studio Onlineと呼ばれていた初期の頃から、Azure DevOpsサービスの大ファンです。 私はそれを専門的および個人的な目的で使用しますが、

コンサルティングクライアントに推奨します。



ただし、このプラットフォームをどれほど高く評価しても、Azure DevOpsが.NETの場合よりも悪くないので、Azure DevOpsがプロジェクトで問題なく動作することをNodeまたはJava開発者に納得させることはしばしば困難です。 偏見に反論するデモやプレゼンテーションの数に関係なく、どのグループにも、ADOは "Microsoftのツール"であるため、ADOはそれらに適さないと固く信じる人々がいます。



哲学的な議論はさておき、Azure DevOpsがその前身であるTeam Foundation Services（TFS）からどのように進化したかを理解していないことで、ほとんどの抵抗を説明できます。プラットフォーム。」 問題は、どうすればこれを最終的に証明できるのでしょうか？



私はこのアイデアを少し試してみて、それから私は思いつきました。 AWS上のKubernetesにデプロイされたSpringBootマイクロサービス用に別のCI / CDデモを作成せずに、証明を行う必要があります-よりエキセントリックなアプローチで行う必要があります。

今、完全に異なるもの

現代の言語とプラットフォームに焦点を当てるのをやめて、30年前に進んで、現代のツールとADOを使用して、モジュールに開発、構築、分解し、8ビットコンピュータープラットフォーム用に作成されたプログラムを実装できるかどうかを確認したらどうでしょうか？



過去に作成したADOの他のデモの場合と同様に、コードの編集からチェックなど、変更を監視できるライブ環境まで、完全に完成した製品を表示したかったのです。



理論的には、これはすべて良さそうに見えましたが、本当の疑問は-どこから始めればよいのか、ということでした。 これは、明らかに、前の例を探してStackOverflowを実行できる状況ではありませんでした。 しかし、友人や同僚（全員が私が動いたと判断した）とアイデアについて話し合った後、アイデアを練り始めました。



デモプログラムは、VS Codeエディターを使用してCommodore 64の8ビットマシンコードで作成することにしました。 ソースはADOのGitリポジトリによって処理され、CI / CDパイプラインがAzureのビルド、モジュール、実装を担当します。 私はすでに友人が正しいと疑い始め、私の屋根はすでになくなっていましたが、それでもこのアイデアは興味深い挑戦に思えました。

編集者の選択

特定の仕事に適したツールを選択することについては誰もが知っています。 これは、家事、車の修理、コードの作成に適用されます。



.NET開発者として、私はほとんどの時間をVisual Studio 2017で過ごします。Javaプロジェクトに切り替えるか、ネイティブAndroidプログラムを作成する必要がある場合は、それぞれIntelliJまたはAndroid Studioを起動します。 C64マシンコードにはどのエディターを使用する必要がありますか？



あなたがしたいこと-信じるかどうか-しかし、今日はCBMを書くのに適したいくつかの優れたエディタがあります。 それらのいくつかで遊んでみましたが、実際にはVisual Studio Codeを使用したかったのです。 私は他のプロジェクトにVS Codeを使用しましたが、非常に柔軟で快適であり、gitとの組み込みの統合の存在は素晴らしい追加でした。



このソリューションの欠点は、アセンブラー6510で構文の強調表示を犠牲にしなければならず、白い背景の黒いテキストを見つめることでした。 この状況は、「正しいツール」に関する私の声明には対応していません。



突然、Visual Studio Marketplaceにアクセスして、問題を解決するのに適したVS Codeの拡張機能が既にあるかどうかを確認することにしました。 アセンブラーで動作するように設計されたいくつかの拡張機能があることを嬉しく思いました。 残念ながら、私がプロジェクトのために選んだACMEクロスアセンブラーのために投獄された人はいませんでした。



これは私を止めるものではなく、80年代の開発のモノクロの側面を追体験したくないので、VS Codeの拡張機能の作成に関するドキュメントに没頭しました。 数日後、私は喜んでVisual Studio Marketplaceの拡張機能の最初のバージョンをリリースしました。



そして、この演習は当初考えられていたよりも有用であることが判明しました。



かつては、アセンブラーでプログラムを書くことに集中していませんでした。 何回か勉強しようとしましたが、たいてい退屈したりイライラしたりして、他のことに移りました。 プラグインを作成した後、VS Codeの拡張機能を作成するメカニズムについて学習しただけでなく、あいまいな構文と操作コードを十分に理解しました。



適切なエディターと80年代の古いプログラミング本をいくつか用意して、コードを書き始めました。 非常に迅速に、SID形式の音楽ファイルをインポートし、64歳のときにビートルズの8ビットバージョンを再生する作業プログラムを取得しました（これはCommodoreユーザーの古いジョークですが、このプロジェクトに適しているようです）。







これまで、ラップトップでプログラムをコンパイルしてテストしました。 ソースコードはgitリポジトリにコミットされたため、次のステップは継続的インテグレーションのビルドを作成する必要がありました。



ADOの優れた機能の1つは、ほぼすべてのCI / CDの状況を処理できることです。 すぐに使用できるサービスには、数回クリックするだけで最新のほとんどのプロジェクトのCI / CDチェーンをすばやく作成できる多くの定義済みタスクが用意されています。



ニーズが基本サービスの一部ではない場合、マーケットプレイスは通常、多くの異なる適切なツールを提供します。 これが機能しない場合は、必要な作業を実行するPowerShellスクリプトをスケッチできます。



このプロジェクトの明らかな問題は、幅広いサービス機能にもかかわらず、コモドール64のクロスアセンブラとディスクイメージングが単に存在しなかったことでした。 もちろん、必要なツールを使用してAzureで特別な仮想マシンを作成することも、PowerShellパスに従うこともできますが、それは興味深いでしょうか？



クラウド内の仮想マシンも好きではないので、この演習ではHosted Agentを使用したかったので、選択肢は1つだけでした。 演習全体の目的を証明するために、これらすべてのタスクを処理する独自の拡張機能を作成するのが最善だと判断しました。

ACMEクロスアセンブラ拡張

CIチェーンに必要な最初の拡張は、アセンブラーコードをC64マシンコードにコンパイルすることでした。 これを行うには、ホストされているビルドエージェントの1つにクロスアセンブラーをインストールする必要がありました。



アセンブラーは、人間が読めるアセンブラー言語を特定のバイナリハンドラー用に設計された実際のマシンコードに変換するプログラムです。 通常、マシンコードは、実行されるマシンで使用されるプロセッサ用に生成されます。 クロスアセンブラはコード変換の次のステップを実行し、別のプロセッサ用のマシンコードを生成できるようにします。



前述したように、私のプロジェクトではACME Cross-Assemblerを選択しました。これはCommodoreの開発に推奨されているためです。 また、任天堂エンターテインメントシステムや65xxプロセッサを使用するAtariファミリなど、他のさまざまな8ビットプロジェクトもサポートしています。



マイクロソフトやその他のソースから提供されたドキュメントと例に基づいて、拡張機能の作業バージョンを作成し、検証し、Marketplaceで公開するのに、1日の大半を費やしました。



タスクが起動すると、ACME Cross-Assemblerの最新バージョンが自動的にダウンロードされ、ターゲットプラットフォーム用の最終ファイルを作成できるオプションで起動されます。 ACMEの選択に関連する利点の1つは、プログラムを構築するためのパラメーターのほとんどがソースコードに組み込まれていることです。これにより、拡張機能で定義する必要がある入力の量が最小限に抑えられます。

誰もがディスケットを貸し出していますか？

チェーンの次のステップは、Commodore 64と互換性のあるメディア形式にプログラムを転送することです。つまり、フロッピーディスクに配置します。 開発者も日常生活でこのような問題に遭遇することはありません。 幸いなことに、このタスクには個別のアプリケーションが存在します。



VICEはCommodoreで最も人気のあるエミュレーターです。 さまざまなCommodoreモデルごとに多くのエミュレーターがあるだけでなく、c1541仮想ディスクマネージャーを含むいくつかの便利なツールもあります。 それで作成されたディスクイメージは、エミュレータで使用するか、物理メディアにコピーするか（5¼ "低密度フロッピーディスク）、またはmicroSDにダウンロードしてSD2IECドライブエミュレータで使用できます。



ソースファイルのヘッダーからすべての設定を取得するACMEタスクとは異なり、c1541ディスクユーティリティはCLIに依存しており、ユーザーはディスクを管理するための多くのオプションがあります。 拡張のために、私は自分のタスクに必要なプロパティのみに専念することを決めましたが、それでも私はそれを作るためにどれだけ徹底する必要があるかという選択に直面しました。



Commodoreは、フォーマットとメディアタイプに基づいてディスクボリュームを処理する方法が異なる3つの異なるドライブモデルをリリースしました。 ほとんどのユーザーになじみのある基本モデルは、容量が170 KB（はい、キロバイト。両親に尋ねてください）の片面ドライブでしか動作しません。 Commodore 128で使用された後のモデルである1571は、両面ディスクで動作し、その容量は340 Kbに増加しました。 拡張機能に柔軟性を追加することにしたので、ドロップダウンメニューからインターフェイスで選択できる設定の形式で、さまざまなディスク形式のサポートを追加しました。



私はすでに実用的な例を持っているので、この拡張機能の作成はずっと速くなりました。 ACME拡張機能のコードも改善できる新しいことを学びました。



クロスアセンブラの場合と同様に、必要なソフトウェアはオープンソースプロジェクトリポジトリからダウンロードされ、ビルドエージェントにインストールされます。 タスクは目的の形式でディスクイメージを作成し、ビルドタスクのファイルがそこにコピーされます。 結果のファイルはBuild Artifactsディレクトリに移動され、そこでダウンロードできます。







何が判明したのですか-非常に多くの作業があり、その結果、ファイルをダウンロードする必要がありますか？ これはCI / CDトレーニング資料である必要があります。 自分の立場を証明する必要がある場合は、デモとして使用できるように、プログラムをマシンに展開する必要があります。

フロップピネット無効

実際のCommodore 64コンピューターと1541ドライブのバージョンを実行することは、大規模で重いことは言うまでもありません。 さらに、特殊なアダプターなしでは最新のモニターに画像を表示できず、これによりデモの有効性が大幅に制限されます。







Commodore SX-64（大規模なバッチで生産される最初の「ポータブル」カラーコンピューター）にはモニターが組み込まれていましたが、それは私の持ち込みスーツケースとほぼ同じサイズで、重量は約10 kgでした。 このようなモンスターと空港のセキュリティサービスを通過するのがどれほど難しいか想像してみてください。



最近リリースされたC64 Miniは、USBやHDMI出力からプログラムをダウンロードする機能を備えており、 持ち運びに十分なサイズです。 場合によっては、これは1つのオプションになります。 しかし、彼はまだ目標を達成していません。



本当の問題は、アイロンの携帯性ではなく、自動化の欠如です。 フラッシュドライブを使用してラップトップからプログラムを車に転送する必要性は、プレゼンテーションのADOの機能を完全には明らかにしません。

サーバーなしのオプション

前述したように、VICEはCommodoreで最も人気のあるエミュレーターです。 Windows、Linux、Mac OS X、MS-DOS、および他の多くのOSに移植されました。 ただし、クラウド開発の場合、このオプションではVMをホストとして構成する必要があり、サーバーを必要としないソリューションで対処したかったのです。



上記のバージョンに加えて、VICEにはJavaScriptのオプションがあり、ほとんどのブラウザーで正常に動作します。 フロントエンド開発は私の要素ではありませんが、適切なレスポンシブページをまとめることができました。







リリースチェーンを整理するために、ディスクイメージを含むファイルを同じリポジトリ内のディレクトリにアップロードします。 これを、利用可能なディスクイメージのリストを返すAzure Function Appの呼び出しに関連付けました。 ドロップダウンメニューからそれらのいずれかを選択すると、JavaScriptエミュレーターで自動的にロードおよび起動されます。



システムは私のプログラムだけでなく、Commodore 64 BASICでプログラムを展開および実行するためのチェーンを作成することができました。



10 PRINT "HELLO WORLD"

20 GOTO 10

終わります

Commodore 64のDevOps？ 考えられない！







この演習の意味は、Azure DevOpsについて「任意の言語とプラットフォーム」をサポートしていると言うだけでなく、Microsoftに関連するすべてを意味するだけではありません（ただし、CommodoreのBASICバージョンはMicrosoft）。 それは、技術的な側面に集中することから私たちをそらし、人々が彼らが自分自身のために任命した人工的な枠組みを超えて行くようにします。



言い訳に関係なく、「これはここでは機能しません」のようなステートメントは、「私たちは常にこのようにしたのに、なぜ何かを変えるのか」というステートメントと同じです。 両方のフレーズは、成長と発展、絶えず変化する技術環境への適応、およびこれらの迅速かつ積極的な変化によってもたらされる課題の克服に消極的であることを示しています。



DevOpsはツールではありません。 最終的にツールは、誰がそれらを公開するかに関係なく、目的を達成するための手段にすぎません。



DevOpsが組織で成功するためには、考え方を変え、企業文化を発展させる必要があります。 たくさんの新しいアイデアを受け入れ、私たちが知っていると思うことを再考し、「これはここでは機能しません」のような考えから離れる必要があります。



30年前のコンピューター用にCI / CDチェーンを作成することは、この観点を明確に示すことを除いて、ビジネスにとって価値がありません。