Azure DevOps for Commodore 64?

I am a big fan of Azure DevOps from the earliest days when it was called Visual Studio Online. I use it for professional and personal purposes,
and recommend it to my clients for consulting.

However, no matter how much I praise this platform, it is often hard to convince developers on Node or Java that Azure DevOps will do an excellent job with their projects, no worse than for .NET. Regardless of the number of demonstrations and presentations that refute prejudice, in any group there are people who firmly believe that ADO is not suitable for them, because it is “a tool from Microsoft”.
')
Putting aside the philosophical debate, I can explain most of the resistance with a lack of understanding of how Azure DevOps evolved from its predecessor Team Foundation Services (TFS), and became the best-in-class set of tools capable of supporting projects of any size “in any language and any platform. " The question is, how can I conclusively prove this once and for all?

I played a little with this idea, and then it dawned on me. Proof needs to be done without creating another CI / CD demo for SpringBoot microservices deployed to Kubernetes on AWS — it needs to be done with a more eccentric approach.

And now something completely different

What if we stop focusing on modern languages ​​and platforms, and move on 30 years ago to see if you can use modern tools and ADO to develop, build, module, and implement a program written for an 8-bit computer platform?

As was the case with other demos for ADO, which I created in the past, I wanted to show a completely finished product - from editing the code, checking it, and so on, right down to the live environment in which you can watch the changes.

In theory, it all sounded good, but the real question was - where to start? This, obviously, was not a situation in which you could go through StackOverflow in search of previous examples. However, after discussing the idea with friends and colleagues (they all decided that I had moved), I began to draw up my idea.

I decided that the demo should be written in 8-bit machine code for the Commodore 64 using the VS Code editor. The source will be processed by the Git repository on ADO, and the CI / CD pipeline will be responsible for the builds, modules, and implementation in Azure. I had already begun to suspect that my friends were right, and my roof had already gone, but still this idea seemed an interesting challenge.

Editor's Pick

Everyone knows the saying about choosing the right tool for a particular job. This applies to household chores, car repairs, and writing code.

As a .NET developer, I spend most of my time in Visual Studio 2017. If I need to switch to a Java project or write native Android programs, I launch IntelliJ or Android Studio, respectively. What editor should I use for C64 machine code?

Believe it or not, believe it or not, but today there are several good editors suitable for writing CBM. I played with some of them, but actually I wanted to use Visual Studio Code. I used VS Code for my other projects, and it seemed to me very flexible, comfortable, and the presence of built-in integration with git was a nice addition.

The disadvantage of this solution was that I would have to sacrifice syntax highlighting in assembler 6510, and I would just stare at black text on a white background. This situation does not correspond to my statement about the "right tool".

Suddenly, I decided to go to the Visual Studio Marketplace, and see if there is already any extension for VS Code that is suitable for solving my problem. I was pleasantly surprised to find there are several extensions designed to work in assembly language. Unfortunately, none of them was sharpened by the ACME Cross Assembler that I chose for the project.

This did not stop me, and, not wanting to relive the monochrome aspects of the development of the 80s, I dug into the documentation about creating extensions for VS Code. A few days later I happily released the first version of the extension for the Visual Studio Marketplace.

And this exercise turned out to be more useful than it seemed initially.

At one time, I didn’t get overlooked in writing programs in assembler. Several times I tried to study it, but usually experienced boredom or irritation, and moved on to something else. Having created a plugin, I not only learned about the mechanics of creating extensions for VS Code, but also gained a good understanding of unintelligible syntax and opcodes.

Armed with a suitable editor and several old programming books from the 80s, I started writing code. Very quickly, I had a working program that imports a music file in SID format and plays an 8-bit version of Beatles When I'm 64 (this is an old Commodore users joke, but for this project it seems to work just right).



Until now, I have compiled and tested the program on a laptop. The source was logged into the git repository, so the next step was the need to create a build for Continuous Integration.

One of ADO's impressive capabilities is the ability to handle almost any situation with CI / CD. Directly “out of the box”, the service offers many predefined tasks that allow you to quickly create CI / CD chains for most modern projects with just a few clicks.

If your needs are not included in the basic service, the Marketplace will usually provide you with many different suitable tools. If that doesn't work either, you can write a script on PowerShell that does the work you need.

An obvious problem of the project was that, despite the wide range of service capabilities, there was simply no cross-assembler and disk imaging for the Commodore 64. Of course, I could create a special virtual machine in Azure with the tools I needed, or follow the path of PowerShell, but would that be interesting?

Also, I dislike virtual virtual machines in the cloud, and for this exercise I wanted to use Hosted Agents, so I had only one choice. To prove the purpose of which the whole exercise was intended, I decided that it would be best to create my own extension to handle all of these tasks.

ACME Cross-Assembler Extension

The first extension needed for my CI chain was to compile my assembler code into machine code C64. To do this, I needed to install a cross-assembler on one of the server agents of the assembly [hosted build agent].

An assembler is a program that converts a human-readable assembly language into real machine code intended for a particular binary processor. Usually, machine code is generated for the processor used in the machine on which it runs. Cross-assembler takes the next step in code conversion, allowing you to generate machine code for another processor.

As I already mentioned, I chose ACME Cross-Assembler for my project, as it is recommended for development for Commodore. It also supports a wide range of other 8-bit projects, such as the Nintendo Entertainment System or the Atari family using 65xx processors.

It took me much of the day to write, test, and publish on the Marketplace a working version of the extension, based on the documentation and examples provided by Microsoft and other sources.

On startup, the task automatically downloads the latest version of ACME Cross-Assembler and launches it with parameters that allow you to create a final file for the target platform. One of the advantages associated with the choice of ACME is that most of the parameters for building the program are built into the source code, which minimizes the amount of input data that needed to be defined in the extension.

Does anyone have a floppy disk loan?

The next step of the chain is to transfer the program to the format of media compatible with Commodore 64, that is, put it on a floppy disk. Developers also do not face such a problem in everyday life. Fortunately, there are separate applications for this task.

VICE is the most popular emulator for Commodore. It not only has a lot of emulators for each of the various models produced by Commodore, but also several useful tools, including the c1541 virtual disk manager. Disk images created with it can be used with an emulator, copied to physical media (5 ¼ "low density floppy disk), or uploaded to microSD and used with an SD2IEC drive emulator.

Unlike the ACME task, which takes all the settings from the header of the source file, the disk utility c1541 relies on the CLI, and the user has many options for managing the disk. For my expansion, I decided to dwell only on the properties necessary for my task, but even then I had a choice regarding how solid I needed to do it.

Commodore produced three different disk drive models, differing in how they handle disk volumes based on formatting and media type. The basic model, familiar to most users, could only work with 170 KB single-sided disks (yes, kilobyte. Ask parents). A later model, 1571, used on the Commodore 128, could work with double-sided discs, the volume of which increased to 340 Kb. I decided to add flexibility to the extension, so I added support for various disk formats in the form of settings that can be selected in the interface via the drop-down menu.

Since I already had a working example, the creation of this extension went much faster. I learned something new, which allowed me to improve the code for the ACME extension.

As in the case of cross-assembler, the required software is downloaded from the repository of the open source project and installed in the assembly agent. The task creates a disk image in the required format, and then a file is copied onto it from the build task. The resulting file is moved to the Build Artifacts directory, where it can be downloaded.



This is what happens - so much work, and as a result you need to download the file? This should be a training material on CI / CD. If we need to prove our position, we need to deploy the program on the machine so that it can be used as a demonstration.

Floppy disconnected

The working versions of the real Commodore 64 computer and the 1541 drive are quite rare things, not to mention the fact that they are big and heavy. In addition, they are unable to display a picture on modern monitors without special adapters, and this greatly limits the effectiveness of the demonstration.



The Commodore SX-64 (the first “portable” color computer out of large batches) had a built-in monitor, but it is about the size of my suitcase for hand luggage and weighs about 10 kg. Imagine how hard it would be to get through the airport security with such a monster?

The recently released C64 Mini is small enough to travel with it, the ability to download programs from USB and the HDMI output. In some cases, this would be one of the options. But he still does not reach the desired goal.

The real problem is not iron portability, but lack of automation. The need to transfer the program from a laptop to a machine using a flash drive does not allow to fully reveal the possibilities of ADO in the presentation.

Option without server

As I mentioned, VICE is the most popular Commodore emulator. It was ported to Windows, Linux, Mac OS X, MS-DOS and many other operating systems. However, for cloud development, such an option would require setting up a VM as a host, and I wanted to get by with a solution that does not require a server.

In addition to these versions, VICE has an option for JavaScript, which normally works in most browsers. Although front-end development is not my element, I was able to bungle a decent responsive page.



To organize the release chain, I upload the disk image file to a directory in the same repository. I linked this to a call to an Azure Function App application that returns a list of available disk images. Choosing one of them from the drop-down menu automatically loads and runs it in a JavaScript emulator.

The system works not only with my program, I managed to create a chain for deploying and running the program on Commodore 64 BASIC.

10 PRINT "HELLO WORLD"
20 GOTO 10

We finish

DevOps for Commodore 64? Unthinkable



The meaning of this exercise is not only to prove that when Azure DevOps is said to support “any language and any platform”, they mean not only everything related to Microsoft (although the Commodore version of BASIC was purchased under license from Microsoft). It distracts us from concentrating on technological aspects and forces people to go beyond the artificial framework they have appointed for themselves.

Regardless of the excuses, statements like “it will not work here” are often equivalent to statements “we always did it this way, why change something”. Both phrases demonstrate an unwillingness to grow and develop, to adapt to the constantly changing technological landscape, to overcome the challenges generated by these rapid and aggressive changes.

DevOps are not tools. In the end, tools are simply means to an end, regardless of who publishes them.

In order for DevOps to become successful for an organization, it is necessary to change the way of thinking and develop our corporate culture. We need to take a lot of new ideas, rethink what we think we know, and move away from thoughts like “it won't work here,” because we haven't tried it before.

Creating a CI / CD chain for a 30-year-old computer has no business value, except for the explicit illustration of this point of view.