The Birth of the Atari VCS Operating System: Part 1

As many of you know and appreciate, Atari is lucky to have Rob Wyatt working with us as the System Architect for the Atari VCS. We won’t rehash Rob’s esteemed credentials here, but has had a hand in creating some amazing and beloved gaming and entertainment products. Rob has some very interesting and colorful back-stories for many of those products, and the Atari VCS is no different.

Below are (mostly) unfiltered excerpts of some of Rob Wyatt’s internal notes to the Atari VCS team over the past several months of development that reveal some of the story around the origins of the Atari VCS Operating System. We’ve removed anything sensitive, confusing or otherwise inappropriate to share and hope you enjoy this particular peek behind the scenes.

Atari OS: Rob Wyatt Notes, Late-Summer 2018

Sandbox Mode: What’s That?

We’ve had discussions about sandbox mode for the VCS, and the multiple OS idea isn’t new: The PS3 let you boot Linux, at least for a while, but their hypervisor completely masked out the GPU so PS3 Linux was always somewhat crippled. This was done so users couldn’t write content in Linux that would compete with their software. Even the Xbox One uses multiple OS’s; the front end is a Windows derivative, and games run in an entirely different OS (game OS).

The VCS is all about democratizing the game console; they have been locked down for too long. The VCS can have an “Atari world” which has an online store, is safe and secure, parental controls, the ability to launch apps and chat and do all the stuff a modern console should.

Outside of our world, we will support users installing other operating systems. Very much like the original PS3, but without any hardware restrictions. If you want to install full Ubuntu, complete with the desktop then go for it — this will never be the standard use case because people who want to do this already can. 99% of users just want to turn the box on and use it. Playing into the small percentage who want to mess with the box is a great move, but it’s just a small group.

Running another OS means you have to reboot the machine, I want any OS to have all the resources and running one OS inside another isn’t a great solution and its not good. It makes any hypervisor very complicated as it becomes more of a virtual machine hypervisor rather than a system monitor hypervisor. I want to keep the hypervisor as simple as possible, the more code in the hypervisor the more of an attack surface there is. The hypervisor is root of keeping the Atari world secure.

I want to make supporting another OS as easy as possible but not at the expense of the user experience of the Atari box in its native form. Something along the lines of: if you plug in a bootable external USB drive our hypervisor will boot from it, otherwise it will boot the internal Atari OS. This keeps both OS’s completely separate and makes supporting multiple OS’s really easy, there is no risk of the internal storage getting corrupted by the other OS. Any OS that is installed will need its startup code modifying because our hypervisor/boot code will enter the OS directly in 64 bit protected mode, the current linux boots from real mode.

We’ll release example code on how to do it.

Linux, Apps, and Browsers

Linux is just the kernel and by itself it’s fairly useless. The Atari OS is based on a modified version of the Linux kernel and we package components with it in order to make it usable as a game console. Some of these components are custom, some are standard. In some ways the Atari OS is a linux distro but this doesn’t make us Ubuntu in same way that Android isn’t Ubuntu. Sure we all have a lot in common but there is also a lot of differences. The story is more confusing because we can install Ubuntu as the Other OS, in which case it really is Ubuntu and does have the window system and does need a mouse and keyboard, however at the same time it’s not Atari OS.

Apps will need to be written for our platform, the way they render to the screen will be different to normal Linux but that’s all low level details and apps. From a developer point of view it will support as many standard APIs as we can, for graphics will support OpenGL and Vulkan, it will also support hardware command buffer rendering for people who want to go there. You can’t have a console without hardware access!

As for the browser think about PlayStation, Xbox, Apple TV, Roku — people want optimized experiences with the input system they have, a typical browser is optimized for a mouse and keyboard or touch. Try browsing the web on a console to see how painful it is. Part of our job is to understand the market and giving people what they want. A lot of people are already suspicious of what Atari is doing, forcing people to use a browser isn’t going to help to the external view that this box is (being) thrown together. Nobody is going to use the box if we force them to use a browser with a controller. I can’t think of anything more frustrating and nobody has managed to pull it off yet. No one wants to type in a web address and navigate web pages to watch a movie. Dedicated apps are the only way to go, on a PlayStation or Xbox anything you want to do is just a couple clicks from the front end. That is a completely different and far superior user experience than forcing somebody to use a traditional browser. This doesn’t mean we don’t support a browser although personally I’d like to not support it and put the development effort elsewhere. Lots of consoles get hacked through webkit based browsers.

Platform and Security

As a platform provider you must own the platform. You can’t just put a box out there and say go for it. A Linux box in a fancy case is just that, people can already do that and do by using (Raspberry) Pi’s, Beaglebones or Intel sticks.

For a platform to succeed there must be a goal in mind. What is the platform going to be used for? The software and the hardware and the Industrial Design and the Marketing must be one. From that use case, what could people do with the platform that interferes or prevents the intended goal of the platform? For a game platform, hacking, piracy and cheating typically come to mind and they will destroy the platform.

For a game platform there needs to be some level of security. If games can easily be copied, then there is no incentive to purchase games and therefore there is no incentive to make them. If online games can easily be cheated, then people won’t want to play games on the platform at all. From a digital distribution point of view there has to be a solid online store. People are going to be unwilling to give payment information if the either the front end or back end isn’t secure. Piracy will destroy any content, be it to new content or old emulated content. Copyright holders will only put content on the box if they know it’s secure.

Atari VCS OS Boots!

The Atari OS is alive! Its booting on the reference board but its still very crude. Don’t even ask about graphics and audio support, its a long way off. At the moment we are working on a clean kernel boot for the given hardware and an initial process.

My team’s goal is to get the OS and built-in apps to consume just under a gig of storage and leave the rest for the user. Our hardware is fixed so all the drivers will be built in to the kernel, there are less security risks if we don’t load kernel modules, our OS won’t be able to load them at all. USB/BT might need a couple of external class drivers depending on what we want to support, but we’ll just build them in and waste a bit of memory if they are not used.

“Can everyone make a quick team call today?”

I broke myself, I’m in the hospital… l will try to make the call.

“Holy crap Rob! What happened?”

Yesterday I had a skydiving accident, I hit the ground while doing a high performance ‘swoop’ landing, probably hit at about 65 mph. I have a broken femur, a cracked pelvis and compression fracture of T6, I’ll be in the hospital for a few days for surgery and monitoring.

A couple of surgeries later and some really expensive metal pieces; good as new.

We now resume our regularly scheduled programming.

Audio is working via alsa, graphics is working with vulkan and Open GL, we have a full screen graphics app.

The Atari OS is enumerating and identifying USB devices on either USB2 or USB3 ports. It will identify any USB device and libusb can talk to all of them from user mode so things like custom/game specific usb devices are possible in a very standard way. For standard devices we have a few class drivers built in for things like HID, Mass Storage, UVC/camera etc. I am not planning on supporting every known USB device as there is no point and we don’t support kernel modules. It whatever we support plus whatever developers write for libusb.

Audio is working… I think the application side of ALSA is way too complicated, we might need to create ‘atari audio library’ which uses the same kernel side backend but a much simpler front end. Alsa has crazy configuration options which mean nothing to us, we have fixed hardware and only one output. If we do something custom keeping it looking like ALSA will help upstream code. Keeping standard is good but only where it makes sense.

Graphics support is still flakey and annoying. Mostly because it kills the screen, so you can’t see what you’re typing. I built a new kernel with remote TTY over serial USB, so you can type on another system and not need the local display. It helps but I really need to fix the graphics.

Right now we are still using the ‘standard-ish’ bios on the reference hardware. From when this hands over control to the OS loader I can load the entire OS and a simple 3D ‘front end’ app in about a second and a half, although the real speed depends on USB enumeration. I said above that we don’t support kernel modules, right now we do because it’s convenient for development.