The Unified Platform


Last week Qualcomm announced that major PC vendors (including HP and Asus) will soon be shipping Windows 10 laptops with ARM processors. ARM is the processor architecture that all smartphones run on. Whether an iPhone or Android phone, they all use ARM based processors.

From Digital Trends:

Qualcomm will be using its Snapdragon 835 processor, a chip usually reserved to power smartphones, in a new line of Windows 2-in-1s. They’re referred to as “Always Connected PCs” or “mobile PCs.”

[Source]

These new machines will run Windows 10 S, but with a twist. Unlike other Windows 10 S machines, these won’t be limited to just Windows Store apps - they can also run nearly all traditional Windows apps due to a built-in x86 emulator.

ARM based processors like the Qualcomm’s or Apple’s A11 Bionic have made great leaps and bounds in performance in the past few years. Chips like the A11 Bionic are now just as powerful as the Intel chips in some current MacBook Pros, so it can’t be much of a surprise that they’re now powerful enough to emulate x86 (the processor architecture all Macs and PCs run on). Make no mistake, what Qualcomm & Microsoft have pulled off here is significant. By emulating x86 on an ARM chips they’re opening up the possibilities for mainstream laptops with ARM processors. No longer will a laptop with this type of chip be relegated to the anemic selection of the Windows Store, now the world of software is open to these computers.

This announcement got me thinking about the possibilities for an ARM based Mac. For a few years now there has been wild speculation about Apple releasing a Mac with an A series processor. The thought has been that if Apple were to release such a machine developers would need to completely recompile their applications to be compatible, like they did during the PPC to Intel transition. There has even been talk of an iOS based laptop. What the Qualcomm announcement shows us is that there won’t necessarily be a need for anyone to recompile for an ARM based Mac. If Qualcomm’s chip can do x86 emulation, the A11 Bionic can certainly do the same.

If Apple does release an ARM Mac, I believe they’ll start with the 12” MacBook. MacBook is a perfect fit, with its fanless design and single port it’s already designed to be ultra-mobile basic performance machine. For Mac App Store apps Apple could enable developers to ship software compiled for both x86 and ARM based machines in a single package (they already do something similar with single apps that are universal between iPhone and iPad), and for the developers that don’t recompile for x86, the ARM Mac could run the app in question in x86 emulation mode.

Expanding upon this idea, once the infrastructure is in place Apple could begin to ship hybrid machines. While low end machines would be ARM only, their higher end machines like MacBook Pro and iMac could ship with an Intel processor and an A series ARM chip. I envision functionality similar to how Apple handles graphics switching now - when the Mac is running simple apps (or those compiled natively for ARM) it would rely on the ARM chip, and it would use the Intel chip for high performance apps.

Such a hybrid MacBook Pro could only further extend the battery life one can expect from a laptop. A lot of people only push their machine some of the time, If you’re like me, the majority of computer usage is for basic tasks like web browsing. Imagine an experience where you get killer battery life (say 20 hours) the majority of the time, but still had the raw grunt when handling big tasks (like After Effects and the like).

Alternatively, with x86 emulation we could see an even bigger shift from Apple. From SixColors:

In the last few weeks, both my colleague Jason Snell and I have looked ahead to what Apple might be envisioning for the future of its devices. I’ve opined on ARM-powered Macs; Jason’s wondered about the possibility of a laptop running iOS. In a recent conversation—on our secret podcast, which you should check out—we started to put some pieces together and conjectured that maybe these aren’t two different stories but rather one larger tale of what Apple’s future might hold.

What if, to paraphrase the late Steve Jobs himself, these aren’t two platforms, but one platform with a bunch of devices?

I would be all for for a single unified platform (with different interfaces). Apple already does this with a majority of their product line. iOS, watchOS, and tvOS are all the same thing under the hood - why shouldn’t the Mac be part of this? Apple has repeatedly said that they don’t want to build a unified OS based on touch, but single operating system under the hood, with universal binaries and interfaces to match the device the app is on - that would be a stroke of genius. A unified platform would signal a whole new era for Apple and the Mac.


Typed on MacBook

We've Moved!


After a long time considering it, I have moved this website from the old missourivalleyambulance.com domain to missourivalley.tech.

Truth be told, this change was largely motivated by the simple fact that the old domain was really long. Anytime I brought it up in conversation I had just the slightest embarrassment at the fact that the domain was so long and ridiculous sounding.

After a few years of having the old Ambulance domain it was time for a change. The new domain name is a lot shorter, and really gets to the heart of what this site is all about: technology.

With the change to the new domain I’ve made a few changes to under the hood of the site:

  • Comments are now enabled, using Disqus.
  • FancyBox support has been added for images.
  • Widgets for featured posts have been added to the homepage.

Over the coming days I’ll be adding comments sections to most (if not all) of the old posts, and I’ll be updating most inline images to use FancyBox

In addition to the new domain, I’ve also rebranded the blog’s twitter, follow it here: MoValleyTech.

I’ve also started a dedicated Youtube Channel for the blog. There aren’t any videos up yet, but I’ve got a couple in the pipe, and will be making a push to make more video content for the site very soon.


Typed on MacBook

AirPods


I picked up a set of AirPods about three weeks ago, and have been in love with them. They are one of the most Apple-y products I’ve ever used.

I’ve long avoided using headphones as there’s too much friction. You’ve gotta have somewhere to put them, detangle the cords every time you want to use them, and constantly get the cable stuck on things. I can’t tell you how many times as a younger man that I had earbuds violently ripped from my ears after getting caught on something.

I even tried a set of wireless Plantronics earbuds for a while - a set with a cable running between the ears. They were barely an improvement over normal wired earbuds. The battery life was awful, they had clunky charging, and I still had to deal with a cable getting tangled every time I had to take them out of my pockets.

AirPods are the opposite of all this friction. Quite simply: they just work. For the first time in years I’m using and enjoying earbuds.

Setup is absolutely effortless. After removing AirPods from the box, there are only two steps:

  1. Open the lid of the case
  2. Tap ‘connect’ on your phone.

That’s it.

No entering pairing mode, no diving down into Bluetooth settings, just pop open the case and connect.

Once connected, using AirPods is seamless and effortless. There’s no turning them on and off, you just open the case, pop them in ears, and you’re going. AirPods have sensors for each earbud that will detect when they’re in your ear, and will automatically turn on and begin routing your device’s audio to them.

AirPods Playback Controls

While there are no buttons on the earbuds, Airpods do have a small amount of physical controls. You can double tap on either earbud and they can perform a small set of tasks, either play/pause, next/previous track, or Siri. If you take one of the earbuds out (to talk to someone for example), any music that’s playing will automatically pause, and it will resume once you put the earbud back in.

AirPods charge exclusively through the included charging case. Apple rates the earbuds for 5 hours of charge, and the charging case can provide multiple full charges. The case charges using the included lightning cable, and provides a simple and fool-proof way to carry AirPods with you when you’re not using them, and I’ve experience great battery life in real-world testing.

Connecting AirPods to Mac

AirPods aren’t just for iPhone, they work brilliantly with Macs as well. AirPods are connected to your iCloud account so you don’t even need to pair them with your Mac. When switching from iPhone to Mac, just pop open the AirPods case, and select AirPods from the volume menu in the menu bar.

For me, the biggest use case for AirPods is actually for calls. At work I use a soft phone exclusively, but have struggled to find a good way to do audio. I’ve tried a few standard Bluetooth headsets and they’re all awful. None of them have decent audio quality, charging them is super clunky, and they all randomly disconnect for no reason. Just. Awful.

Conversely, AirPods have been great for calls. The audio is top notch, I don’t have to deal with clunky chargers or making sure that things are paired - they just work.

Audio quality in general with AirPods is pretty good. Obviously they’re not going to surpass a high-quality set of dedicated wired headphones, but the audio is sufficient for most people. It comes down to a trade off: you can get high fidelity audio (and suffer through dealing with a cable), or you can have a set of truly wireless earbuds with audio quality that is on par with the EarPods you get out of the box with the phone.

AirPods are one of the best Apple products I’ve used in years. They’re pure Apple. Simple. Easy to use, and innovative. Wireless headphones have been around for a while, but no one nailed it until now.


Typed on Git2Go

RedScarf II Ver.D Build Log

60% + Numpad with Gatistotle Switches

I’ve long been interested in RedScarf keyboards, their interesting interpretations of 60% keyboard layouts. The most well-known variants are the RedScarf II Ver.B (65% + 10 Fkeys in 2 columns), and the RedScarf III 96 (60% + Numpad + Fkey row). I’d been particularly fascinated with the RS96 for a while. It seemed to be a really great and efficient layout, one that provides nearly a full-sized layout, but with all the keys brought together, reducing the board’s overall size. Of course, by the time I got seriously interested in the RS96 it was nowhere to be found - which is probably a good thing. After thinking long and hard I realized that what I really wanted was an RS96 without the function key row. I rarely make use of function keys, so I really wanted a 60% board with built-in numpad. Then one day along came the RedScarf II Ver.D - I had to have it.

Parts

I opted to go with the barebones kit from Massdrop during the RedScarf group buy. I ordered only the acrylic case, PCB, and fiberglass plate. At the time I wasn’t quite sure which switches or keycaps I’d be using. I settled on the below for this build:

Switch Mods

For RedScarf I decided to do something new: instead of using off-the-shelf Gaterons, Cherrys, or Zealios, I opted to use modified switches.

Switches for this board are Gatistotles - a portmanteau of Gateron + Aristotle.

The Aristotle variants started to pop up in the keyboard scene about a year ago. Someone out in Asia found a large stockpile of new-old-stock Aristotle switches. Heretofore an unknown switch in the community. Aristotles are notable for a very tactile yet clicky stem. The Aristotle stems are really quite superb - the switch houses are…less so. Typical switch housings are made from strong plastic like ABS. The Aristotle housings are really soft plastic, likely POM. The result is that you’ve got really great internals, but the switch feels pretty crappy because of a poor switch housing. The solution to this is to remove the stem from the switch and transplant it into a housing from another manufacturer. This gives you switches like Cherrystotles, Gatistotles, and Zealistotles - you do the math on which housings are used for each of these.

For my mods I chose to use Gateron Greens as my ‘donor switches’. The resulting Gatistotle switch would have a really smooth housing to work with, and a nice heavy 80g spring.

open Aristotle switchs

I’ve never actually done switch mods before. I’ve lubed switches, but never modified them. The process is fairly simple: use a switch opening tool to open the Aristotles. pull out the stem. Open the Gaterons, pull out the stem. Insert the Aristotle stem in the Gateron housing. Close the switch up (carefully).

For these mods I didn’t make use of a proper switch opening tool nor a switch modding station, but I was able to get all 80 or so switches done in about an hour. For future mods I’ll definitely use a proper switch opening tool as opposed to a bodged-together one. It’ll make the process a lot quicker.

Time To Build

The build itself was pretty straightforward, as far as custom boards go. RedScarf II comes with all diodes, resistors, and even the RGB underglow LEDs preinstalled.

First I installed the included stabs (after lubing them of course).

Then it was time to put all the switches in the appropriate spots.

And solder away.

I ended up not having enough Gatistotles for full coverage, so I leaned on my old standby, the Cherry Black to fill the remaining spots.

Programming - TKG

After soldering, the board was actually fully functional. It comes from the factory with a pretty usable layout preinstalled. Even the RGB underglow is usable after assembly, when using the included remote control.

Of course, I can’t abide using anyone’s default layout, so I had to flash the board with a layout I’d prefer.

With RedScarf the only option for building its firmware is TKG tools. I’d used a variant of TKG on a previous build and hated the entire process. The flashing method for RedScarf is actually pretty easy though, far better than my previous TKG experience

Unlike QMK, where a board’s layout is built in text files, and flashing done from terminal, TKG allows an entirely GUI-based flashing process. There are a bunch of steps, but the process is simple enough that a novice or newbie to custom keyboards should be able to flash using TKG with ease. The only really complicated part of this process is finding/building a layout to work with - more on that below.

Building a layout

The first step is to build out your layout and keymap on Keyboard Layout Editor (KLE). On KLE you can either place all the individual keys so that the on-screen layout matches your RedScarf, or start using a template. When using a template, you copy a text file into the ‘raw data’ section of KLE, and the proper layout will be displayed on screen. One then selects each individual key and sets the ‘top legend’ to what you want that key to be. Once you have the layout you want, copy the raw data from KLE into a text file - be sure to save that text file should you want to ever change your keyboard’s firmware in the future. Repeat this process for each subsequent layer you’re going to have on your board.

Note: for function keys, you must designate these in your layout on KLE. With RedScarf, Fn0-24 are reserved for the remote control to change RGB underglow settings. Any function keys you assign must start at Fn25 or above.

My RedScarf has 3 layers. Layer 0 is the base layer, normal layout. Layer 1 has things like media controls, arrows, etc. Layer 2 gives me Fkeys (for the rare times I need them.) Text files for each of these layers are here (Layer 0, Layer 1, Layer 2, if you’re building a RedScarf you can paste this data directly into KLE.

RGB Underglow

As mentioned above RedScarf comes with RGB LEDs preinstalled, and also comes with a physical remote control that can be used to control RGB effects on the board. RedScarf reserves Fn0-24 for RGB functions. It’s also possible to set up additional function keys within RedScarf’s layout, enabling control of RGB without using the remote. For my build, I assigned RN28-31 to RGB functions.

Setting up TKG

TKG is actually just a website/webapp. One builds the desired layout on the site, then the site can actually flash your board directly from your web browser. Before setting up your keyboard’s layout, it’s first necessary to install the TKG Chrome App. The app allows the TKG website to interface with your keyboard.

Build your board in TKG

With a layout set in KLE, it’s time to open TKG. Set the ‘keyboard’ to RedScarfII+, layer mode to normal. Paste each of your layer’s raw data into the appropriate fields.

After the raw data has been pasted in, you’ll then see settings for function keys. TKG supports all the same function key types as standard QMK/TMK.

Once function keys have been assigned, it’s nearly time to actually flash the RedScarf. If you’re building one yourself, I’d recommend going to Tools > Export FN, and also save a text file for each of your layer’s raw data before you flash your board - that way you’ve got copies to work with should you ever want to change your board’s layout in the future.

My exported FN layer settings are here.

Flashing is desperately simple. Easier than flashing with something like dfu-programmer, actually.

Hold down the top-left key on RedScarf, and plug it into your computer. The burn .eep file or burn .hex file on the TKG website will go green. Click it, and the RedScarf has been flashed.

Final Thoughts

The build experience on this board was a lot of fun. With all the electronics (like diodes and RGB LEDs) preinstalled, assembling this board was a breeze, and the TKG experience was actually pretty easy. A lot less frustration than I had with my previous TKG experience.

I genuinely enjoyed the process of modding together the Gatistotle switches. They’re really the star of the show with this board for me. I’ve very much fallen in love with Gatistotles. Shortly after finishing RedScarf I went out and bought another 80 Aristotle switches to use in future builds. As Aristotles are no longer in production, the supply of them out in the world is dwindling. The Aristotle stems with Gateron housings are a powerhouse. They’re SUPER clicky, and SUPER tactile, a wonderful combination.

Using this board day-to-day has been excellent. I find the 60% + numpad layout to be very functional for me, especially at work. It’s a same that there aren’t a lot of boards that use this, I think it could really catch on.

RedScarf Underglow

For a long time my Test ErgoDox was my daily driver at work, but for the past few months I’ve been using RedScarf consistently, and it’s been fantastic. Going in to this build, I’d expected that with this layout I’d use RedScarf quite a bit, but it’s definitely become one of my favorite boards. I actually typed this entire post on RedScarf.


Typed on RedScarf II+ Ver.D