DevOps and the C64: what's your excuse
•Transferir como PPTX, PDF•
2 gostaram•491 visualizações
Slides presented at NDC sydney 2019. Most of the video have been removed to save space
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a DevOps and the C64: what's your excuse
Semelhante a DevOps and the C64: what's your excuse (20)
Mais de Todd Whitehead
Mais de Todd Whitehead (8)
Último
Último (20)
DevOps and the C64: what's your excuse
- 1. **** DEVOPS AND THECOMMODORE 64 **** 10 PRINT “Todd Whitehead” 20 PRINT “Cloud Solution Architect @ Microsoft” 30 PRINT “@TodWhitehead” SO WHAT’S YOUR EXCUSE?
- 2. Hi, I’m Todd
- 3. Micro-soft
- 4. No, not those 80’s
- 6. People. Process. Products. Talking about DevOps DevOps is the union of people, process, and products to enable continuous delivery of value to your end users. DevOps is the combination of cultural philosophies, practices, and tools …. https://aws.amazon.com/devops/ https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops DevOps is an organizational and cultural movement that aims to ….. https://cloud.google.com/devops
- 7. People. Process. Products. Why !DevOps? 1. Products 2. Process 3. People We have legacy code & tools Connectivity is complicated Our process is complex We can’t automate everything
- 12. © OldSkoolPixels.com - used with permission Video Removed Go to https://www.youtube.com/watch?v=verzp18Vhm4&t=453s to view it
- 13. Hans Challenge: DevOps on a C64 Inner dev loop Productive Dev Environment Display Text Colour Effects 8 Bit Music Rub a little DevOps on it Source Control Work Planning and Tracking Continuous Integration Continuous Delivery Running on a real C64
- 14. https://www.c64forever.com/ C64, PET 2001, CBM 3032, CBM 4032, CBM 8032, VIC 20, CBM 610, C16, Plus/4, C128 (40-column and 80-column) and more
- 18. Composite Video RF Luminance & Chrominance HDMI RCA audio svideo Super AV Adapter Line Doubler
- 19. Dev Tool Chain https://code.visualstudio.com IDE: Visual Studio Code https://sourceforge.net/projects/acme-crossass Assembler: ACME Cross-Assembler https://azure.microsoft.com/en-us/services/devo CI/CD: Azure DevOps https://vice-emu.sourceforge.net VICE - the Versatile Commodore Emulator
- 26. > dotnet new console
- 30. Address Bus Address Bus 16 bits | 0–65,536 Data Bus 8 bits | 0-255
- 32. CPU SIDCIA Basic CharKernal 64K RAM VIC-II Data Bus Data Bus
- 40. POKE 55296,11
- 43. Meet SID
- 46. Let’s add some 8-bit sound
- 47. Hans Challenge: DevOps on a C64 Inner dev loop Productive Dev Environment Display Text Colour Effects 8 Bit Music Rub a little DevOps on it Source Control Work Planning and Tracking Continuous Integration Continuous Delivery Running on a real C64
- 51. Choose a build agent
- 52. TypeScript Custom Build and Release Pipeline Tasks Dashboard & custom views Extend work item, sections, and actions Public or Private Marketplace Building a Azure DevOps extension
- 69. Hans Challenge: DevOps on a C64 Inner dev loop Productive Dev Environment Display Text Colour Effects 8 Bit Music Rub a little DevOps on it Source Control Work Planning and Tracking Continuous Integration Continuous Delivery Running on a real C64
- 70. https://usborne.com/browse-books/features/computer-and-coding-books/ Release Pipeline 1: Printed
- 71. Release Pipeline 1: Printed
- 72. Release Pipeline 2: Physical
- 73. Build Artefact Continuous Delivery: UAT Azure Blob Static Site CDN Azure Key Vault secrets Azure Function
- 75. Release Pipeline 3: Bulletin Board Systems
- 76. code commit Continuous Delivery: Prod Azure Blob Static Site CDN Azure Key Vault Azure Key Vault secrets secrets Azure Function
- 77. 21:4/100 bbs.castlerockbbs.com:23 21:4/159 bbs.retrodevops.com:23 21:4/109 bbs.foo.com:23 fsxNet
- 85. A C64 & BBS in 2019? Prove it cowboy! https://www.retrodevops.com/c64.html
- 86. Hans Challenge: Retrospective Mr. Miyagi Infrastructure as Code Configuration as Code IaaS, PaaS & Serverless Dashboarding and Alerting Rub a little DevOps on it Source Control Work Planning and Tracking Continuous Integration Continuous Delivery Running on a real C64 Inner dev loop Productive Dev Environment Display Text Colour Effects 8 Bit Music
- 87. VS VS Code VSTS Github Jenkins Comprehensive DevOps workflow for IoT Edge solution teams of any size • Shorten cycle times and deliver IoT solution faster • Improve quality and availability • Can be easily adopted with essential tools Dev tools for IoT Edge for all languages & platforms • Visual Studio IoT Edge extension (coming soon) • Visual Studio Code IoT Edge extension (github.com/microsoft/vscode-azure-iot-edge) • CLI dev tool (github.com/azure/iotedgedev) • CI/CD in VSTS, Jenkins and etc. IoT Edge CI/CD • Check in IoT Edge deployment • Distribute to test cluster, run tests • Deploy to edge devices on successful tests • Support single + multiple of devices
- 88. So everything's code now? Yes, but Hans, baby, it’s going to be ok Is Hans Happy?
- 89. Takeaway: Be a good DevOps Citizen Things we can share (shift right) Living in a code world Collaborating around code Being practical about code Iterating on solutions Things we can learn (shift left) Different domains Alternative delivery models Reliability Engineering
Notas do Editor
- Good morning. Welcome to my curiously named session DevOps and the commodore 64: so whats you’re excuse” Quick Poll before we start. Who has ever committed code that triggered an automated build? Who has ever owned a computer that did not have a hard drive? Who has ever lost their online connection because their mum picked up the phone in the kitchen? There’s been some great sessions this week all about the latest and greatest tech. This talk is a little different. This talk is about using some very old tech to solve a modern problem. So lets go back to the beginning.
- So like I said my name is Todd. [Click] Like some of you I started out as a child. [Click] I discovered containers at an early age. [Click] and that maybe fashion wasn’t going to be my thing
- Little did I know that across the world was a small group of not dissimilar people starting a company that much later in my career would end up joining. At this time Micro-soft was a small company in New Mexico that made most of it money licensing its version of basic to computer manufacturers. More on that later. Meanwhile my journey through life continued into the 80’s.
- And when I say 80’s I don’t mean the mullet growing, parachute silk wearing 80’s.
- I mean this these 80s. Where home computers become a reality and gave nerds like me the hope that maybe our skills would mean we could meet a girl, or failing that build one. And maybe the computers in our rooms could help us save the world, even if we were the ones who got the world into trouble in the first place. So with these sort movies as a rough life plan I became a software developer, architect, tech lead, scrum master and eventually found myself working for Microsoft.
- At Microsoft my job is help customer use Azure to make their apps and their businesses even more awesome. And this transformation conversation always seems to lead to the topic of DevOps. There's lots of definitions of devops bit I like uncle Donovans one. DevOps is the union of people, process and products to enable the continuous delivery of value to your end customers. The order of the highlighted words is not accidental. [Click] If you look at AWS or googles definition they will use something similar
- But the funny thing is almost without fail when I start talking about devops [Click] there always seems to be that one person in the room who rolls their eyes and claim devops just isnt right for them. For the sake of argument we’ll call him “Hans Grubber”. [Click] They will provide a slew of reasons but the interesting things ive noticed is that the always seem to reverse the order of the 3 components with products or technical reasons seen as the main blocker. And unless you know the minute details of that tool or technology its difficult to short circuit that as a blocker. So instead I thought the best way to debunk these arguments was to show that devops could work far a tech familiar yet so far out of left field it made it seem very unlikely it couldnt work for their tech. So find something like that I reached back to my childhood.
- So who has owned or used a C64? You're not alone [CLICK] as the c64 till holds the world record for the highest selling computer and was in production for more than 12 years. At the height of its run commodore was shipping almost half a million units per month or put another way more than the rest of the pc industry combined including IBM. The C64 was built around the 6510, a 1 MHz 8-bit CPU which was an improved design of the very successful 6502. The 6502 powered not only the c64 but other commodore hardware such as the VIC-20, PET and 1541 Disk Drive. Oh it also was at the heart of the Apple I , Apple II family, BBC Micro, Atari 8-bit family and video game systems like the Atari 2600, Nintendo Entertainment System, Atari Lynx and even the Tamagotchi.
- And futurama fans might have noted it also seems to have powered bender
- And based on the code we see in the first terminator move also the T-800. But we so many system using the same chip, why was the 64 so successful.
- Firstly commodore made it very accessible both by pricing it low and moving sales out of traditional electronics and computers stores and into large retail chains like kmart and toys r us. These environments also provided very public ways for a generation of coders to demonstrate coding prowess with a simple and sometimes offensive looping message. But the c64 also had some serious technical advantages which we’ll use today especially in its graphics and sound chips.
- The combination of technical capabilities and the volume of sales made it an attractive platform for software development especially games which is the enduring memory most people have of it. [Click]
- So this lead me to create the Hans Devops challenge. If I can get a relaworld devops pipeline working for a C64 then surely you can get it working for anything. [Click] so first I want a productive inner dev loop, not just functional and has to be somewhere I could do real work day after day. Then I want to use that to create a hello world program 80’s style. One that deals with spme of the complexities of that platform. [Click] Then we need to “rub a little devops on it, with build and release pipelines that somehow ends up with us being able to run our program on this real c64.
- So first thing needed to decide was how to do it. Easiest option was just to use an emulator.
- Before we can do any of that that however we need solve some hardware challenges. Looking at the user guide connecting it up it looks simple enough, but hides 2 big problems. The first is the power supply. Given the volumes commodore was shipping, managing production costs was critical. Even when new the power supply had a failure rate of nearly 30% and to save money it lacked any form of over voltage protection, failure often meant fried chips. Add nearly 40 years of use and abuse and just connected it up and hoping for the best isn’t a great option. Instead I bough a custom power supply from one of the original commodore service engineers.
- The next problem is connecting it to a modern display. The C64 actually had 3 display output options [Click]. The first was RF which allowed it to be connected to a TV [Click] but since almost nothing in existence today supports that its out. The other two could work [Click] but the connector isn’t anything usable today so [Click] we’ll add a Super AV adapter that connects to the 64 cleans up the signal and provides a standard composite, rca audio and s-video output. Unfortunately that signal is still using a 15Hz signal which is too slow for any modern display to copy with. [Click] To fix that we’ll add an upscalar to take an svideo signal, increase the frequency and convert it to a digital signal that we can finally connect to our HDMI display. [Click] And after all that we can finally power up our 64[Click]
- To get started we to setup our dev environment [Click] Whilst there are dedicated tools both for the 64 and PC, I’m going to use Visual Studio Code because I know it, its open source, crosss platform and claims to support any language or platform. [Click] Since I’m not coding on the C64 I’ll need a cross compiler which is actually how a lot of software was developed for the C64 originally. I’ve chosen the ACME assembler because it seems to be actively developed and used. [Click] To simplify my dev process I’ll use the VICE emulator to test locally [Click] And finally for all my devops goodness I’ll use Azure DevOps for my code repository, task management as well as build and release pipelines. Again it’s a something I know and claims to support any language and platform so lets put that to the test.
- So when I open my solution in VSCode I get not surprisingly no syntax highlighting, no intellisense and all the stuff I’m used to to make me productive. Different Assemblers use different syntax for advanced features so what I really need is not just support for C64 but I need support for the specific Assembler Ive chosen. VSCode has a powerful extensions framework so I could just write an extension.
- But sure enough if you search the marketplace you’ll find a whole of great extensions for the C64 including one for exactly what I need. Thank you Tony Landi.
- Great now we have something we can use, colours and intellisence etc. Note there is no project or solution concept so we have to explicitly add the code we need. But will still need a way to build using acme and deploy to vice emulator.
- All we need is a .vscode folder containing a tasks.json file that defines our tasks. We give it some meta data to describe the task, the command line and even parse any error output so it is displayed in VSCode’s problem window.
- VS Code Tasks to the rescue, allows us to design any kind of task we need.
- In our case we have 2 option, Assemble and deploy and assemble, compress and deploy
- So now we have our hardware running and a dev environment we can use, now we need to write our hello world app. If we were doing this in dot net core we could just dotnet new console and get [Click] Well pretty much our whole solution.
- Just to make some effort we could add some colour and [Click] hey presto. That was easy because we had an awful lot of help from tooling, .net core libarries and runtime as well as operating system and hardware abstractions that made our life so easy.
- After the
- To get things done on the 64 we aren’t going to have those abstractions to help use we are going to have to understand our hardware to make some hello world magic. Which is why the programmers guide includes [click] a lot of hardware detail including a full motherboard schematic.
- Generally today we don’t need to know a lot about the processor our code is running on. On the C64 however we don’t have all those lovely abstractions so we need to understand a little more detail. The C64 is powered by the 6510 a slight physical modification to the 6502 since Commodore owned MOS that made them and do whatever they wanted. {Click] the 6510 gives us an 8 bit data bus so each byte represents a number from 0-255. [Click] It also has 16bits for its address bus meaning we can use up to 64K of memory.
- The weird thing is when we start up, the welcome screen tells us it’s a 64K system [Click] but only has 38K free
- Turns out there is a whole lot of things within the 64 that need to use that same addressing bus including ROM chips for the kernel, basic and character sets as well as the video, sound and input/output chips.
- Understanding that is going to be very important to write out hello world app. We are going to directly control hardware like the [Click] For example The VIC2 Display CHIP reads from two areas of memory to get the character and colour information to display. We are also going to be responsible for telling the c64 where in memory to store our program and variables.
- Screen Ram: 40 columns wide, 25 lines gives 1000 bytes of memory to represent the screen.
- If we wanted to write hello world to the screen, load hello byte by byte into memory [Click], unfortunately we cant just copy from memory location to location, we have to use the 6502 registers. In this case we load each byte [Click] into the accumulator register then [Click] store the value into the right screen memory location.
- ACME provides a helper function to load text into memory scr
- We’ll use the x-register to hold out loop counter [Click]LDA to load the next character from our variable to the Accumulator register STA to store the value in the accumulator into the memory location that represents the row and column we want to display the character in. [Click]Handy to have the windows 10 calculator to figure out what Hex 590 + Dec 80 is to write the second text string 2 lines down.
- plain text screen. Good start we definitely need some colour
- In a world where pc’s and other 6502 machines could handle 4 colours, the c64’s 16 gave it huge advantage
- Colour ram has the same 1000 bytes, but only uses 4 of the 8 bits to store colour (16 colours)
- This time we’ll specify and range of hex colour values to wash over the text
- Again we’ll loop through the data and change the colours associated with
- We’ve got the colour happening now we just need to added that magic 80’s sound. SID (short for Sound Interface Device) is the name of the sound chip used in the C64 and C128. The chip's distinctive sound is easily recognized and was clearly ahead the competition. When other computers of the day were making beeps and simple flat tones, the SID was in another league. It had 3 discrete voice that could be configured on the fly to make very complex music and even digitized speech and samples.
- Developers were also able to exploit a bug in the volume control to product digital samples. [Click] So given how much work we had to do to print some text on the screen. How hard is it going to be to add some sound?
- Turns out not that hard. [Click] We load the sid file and jump to that memory location. How can it be that simple? Any guesses? The music file actually contains not just the music data but the assembler instructions to play that data. Lack of separation of concerns might be an afront to our modern mindset but I’ll take it.
- So now we can show Hans our super productive inner loop for development. Now we need to rub a little devops on it. Starting with some continuous integration.
- For this I have been working away adding some more of that C64ness into our hello world. So since im using VSCODE which has all the built in git goodness I can commit my my code which is hosted in a github repo.
- So that’s the inner loop sorted and we have our code repository which we have pushed our latest code into. Now need to move onto our Automated Build Pipeline.
- Azure DevOps has a marketplace for sharing extensions to the any part of the devops process. These extensions can be shared publicly, within my organization or with specific people. I’d never written one before but it didn’t look too difficult. They are written in typescript an sdk is provided to make interacting with the platform easy. We’ll also supply a JSON manifest file that contains basic info about the extension to make it discoverable in the marketplace.
- One extension can contain several tasks so all we need to do is create a solution structure with the extension manifest at the top level and a folder for each task that is part of the extension
- Most of the manifest is meta-data to make the extension discoverable in the portal.
- Each Task has a json file with the meta data and version information to help with discovery
- The other important fields define the input UI that are displayed in DevOps Portal when you are configuring a task in a pipeline
- The extension itself is written in typescript, which is something I’m not familiar with but the provided tutorials had me up and going in a few hours. The extension library has a framework and helper functions to help manage the tool installation process.
- The extension library provides functions to download, extract and install files and a cache so this only happens if it isn’t already installed on the build agent.
- The extension file can be uploaded via the portal or preferably via a build pipeline with extensions available for building extensions.
- Then you are good to go
- Our build pipeline in Azure Devops mirrors what we had locally. The parameters we defined in our extension make configuring the build step straight forward.
- We do have a few extra steps here including generating a description file which we will use later on.
- In our CI build we going to create a C64 disk image containing our program, as well as the chuck Norris build enhancer, because cmon chuck Norris.
- We can see each our builds and very the steps passed on you’ll notice even when we are pulling down and installing tools, each step is only taking a few seconds.
- We can also drill down into each build steps and see exactly what happened and verify the parameters we set are being passed through as expected.
- The end of result of our build is 3 artifacts: the program of course, a c64 disk image containing the program and a meta data file we will use shortly.
- And now that our CI builds are running we get all the nice sort of dashboarding and reporting you’d expect and need.
- So far so good but hans still doesn’t look happy. We still need to add the delivery pipelines for a UAR and prod environment and the minor detail of getting to run on a real C64.
- So how did we distribute software back in the 80’s. Early on one of the most common ways was just to print it out make people type it back in. There were some awesome books that I remember fondly and thankfully are all available for free online. You also had to accept that the finished result may not match the hi-res artwork used on the cover.
- https://archive.org/details/compute-magazine There was also a range of local and international magazines. All you had to do was type in pages of code and hope you didn’t make a typo or there wasn’t a printing error. [Click] If the magazine really wanted to make your life interesting they might publish the machine language version.
- Option 2 was physical media be that cartridge with a maximum of 16K, Painfully slow floppy disks with a whopping 160K and higher capacity but even slower tapes. For our UAT environment we are going to use disks, sort of…
- For our UAT environment I’ve setup a static website using the Hugo framework that’s deployed using its own devops pipleline. On this site is a JavaScript based C64 emulator for rapid testing. The UAT pipeline pushes the disk image from the CI build to blob storage and we use a Azure function to regenerate a json file containing the list of available disks. The sensitive connection info for the storage account is kept safe in Azure Keyvault and injected into the pipeline for it to use.
- So this is our website which contains a bunch of resources for ewverything you are seeing today including a c64 emulator implemented in javascript. Made it through UAT but now we have to make the connection to real hardware to close the deal with Hans.
- For our production release we are going to use a bulletin board system which transformed what you could with tech in the 80’s. I could dial in and share files, messages and even play games all for the price of a local call. [Click] Of course if I wanted to do that with someone far away I would have to pay expensive timed call rates. To get around this [Click] BBS’s joined networks like FIDONET and starting calling each other to pass stuff on. [Click] to keep costs down they would call up other BBSs who could pass the message along until it got where it needed to go. See we had Eventual consistency modes in the 80’s too.
- So to complete our prod release pipeline all we need all we need is to create a BBS and see if any of these network still exist. So luckily theres a community of sysops and developers that have kept updating some of the BBS systems to take advantage of some of the Internet protocols. So I’ve deployed a BBS using the Mystic BBS software onto an Azure virtual machine and now all we need is BBS network to join.
- Found One. fsxNet is a fun, simple and experimental network established in late 2015. It uses Fido Technology Networking to communicate between connected Bulletin Board Systems (BBS). Since FSXNet can use internet friendly protocols like Telnet we no longer have the longs distance call issue to worry about so nodes can dial a hub to collect message and files.
- http://my.ftelnet.ca/
- To make this work though we are going to need 2 more bits of hardware. In order to run our bbs client and download the program we will need some form of storage. My luggage was already at the weight limit so I couldn’t bring my full size 1541 [Click] so I brought his little brother which is an SD2IEC drive an opensource project that allows me to use a SD card to emulate a 1541. For connectivity [Click] I’m going to use a WiModem which connects to the standard user port and can accept AT compatible modem commands on the C64 side and use wifi updtream to connect us to the internet.
- So my release pipeline actually becomes pretty straight forward. I get my BBS credentials from Keyvault. Im then going to create a zip fiel containing the disk image, program file and the metadata file we talked about earlier. The BBS will use this file to populate its file base with useful information. Then we can use ftp to move the file to the BBS as it noe supports it and save me having to implement one of the older BBS protocols.
- Again we can see the pipeline has run and again its only taking a few seconds for each step.
- So moment of truth time. Who supremely confident this will work? Demo via https://www.retrodevops.com/c64.html
- So looks like we managed to tick of the items on Hans’s original checklist. [Click] Along the way we managed to sneak in a few extra practises too. At first glance the peipleine we’be built to keep Hans happy may seem a little out there….
- But the pattern is actually very familiar if you have done any devops with technologies like IOT. This combines simulated devices for testing environments before deploying down to real devices on the edge that can using some very old school protocols and hardware.
- So the penny has dropped for Hans but he’s still not happy. Code, repositories, pipelines this is not something he’s had to deal with before. [Click] Luckily Hans isn’t alone. There’s people, stange people who can help him. Just ask Jim Butterfield in the C64 training course.
- So what I hope you takeaway from today is not just that devops is great even though it is. Its not just that tech in the 80’s was not always beautiful but it was awesome, which it was. Its just this:[Click] we as developers have a tremendous amount of knowledge and experience, we can share. Practices and ways of working in a code based world we’ve developed throughout our careers can unlock enormous value for our companies and communities if we share it. [Click] But equally there all sorts of things we as developers can learn by working more closely with our non-dev cousins be they in Infra, Ops, Database administrators. Who have a different worldview and set of experiences that can help us deliver better value.
- I thank you for sharing this journey back in time with me. If you’d like to learn more about this and have a play, all of the resources, emulators and code can be found on the retrodevops.com website. If you’ve enjoyed the session please leave feedback on your way out the door so I can prove to my wife that all those weird ebay purchases really were work related. Thank You.