More from Alyssa Rosenzweig
In 2020, Apple released the M1 with a custom GPU. We got to work reverse-engineering the hardware and porting Linux. Today, you can run Linux on a range of M1 and M2 Macs, with almost all hardware working: wireless, audio, and full graphics acceleration. Our story begins in December 2020, when Hector Martin kicked off Asahi Linux. I was working for Collabora working on Panfrost, the open source Mesa3D driver for Arm Mali GPUs. Hector put out a public call for guidance from upstream open source maintainers, and I bit. I just intended to give some quick pointers. Instead, I bought myself a Christmas present and got to work. In between my university coursework and Collabora work, I poked at the shader instruction set. One thing led to another. Within a few weeks, I drew a triangle. In 3D graphics, once you can draw a triangle, you can do anything. Pretty soon, I started work on a shader compiler. After my final exams that semester, I took a few days off from Collabora to bring up an OpenGL driver capable of spinning gears with my new compiler. Over the next year, I kept reverse-engineering and improving the driver until it could run 3D games on macOS. Meanwhile, Asahi Lina wrote a kernel driver for the Apple GPU. My userspace OpenGL driver ran on macOS, leaving her kernel driver as the missing piece for an open source graphics stack. In December 2022, we shipped graphics acceleration in Asahi Linux. In January 2023, I started my final semester in my Computer Science program at the University of Toronto. For years I juggled my courses with my part-time job and my hobby driver. I faced the same question as my peers: what will I do after graduation? Maybe Panfrost? I started reverse-engineering of the Mali Midgard GPU back in 2017, when I was still in high school. That led to an internship at Collabora in 2019 once I graduated, turning into my job throughout four years of university. During that time, Panfrost grew from a kid’s pet project based on blackbox reverse-engineering, to a professional driver engineered by a team with Arm’s backing and hardware documentation. I did what I set out to do, and the project succeeded beyond my dreams. It was time to move on. What did I want to do next? Finish what I started with the M1. Ship a great driver. Bring full, conformant OpenGL drivers to the M1. Apple’s drivers are not conformant, but we should strive for the industry standard. Bring full, conformant Vulkan to Apple platforms, disproving the myth that Vulkan isn’t suitable for Apple hardware. Bring Proton gaming to Asahi Linux. Thanks to Valve’s work for the Steam Deck, Windows games can run better on Linux than even on Windows. Why not reap those benefits on the M1? Panfrost was my challenge until we “won”. My next challenge? Gaming on Linux on M1. Once I finished my coursework, I started full-time on gaming on Linux. Within a month, we shipped OpenGL 3.1 on Asahi Linux. A few weeks later, we passed official conformance for OpenGL ES 3.1. That put us at feature parity with Panfrost. I wanted to go further. OpenGL (ES) 3.2 requires geometry shaders, a legacy feature not supported by either Arm or Apple hardware. The proprietary OpenGL drivers emulate geometry shaders with compute, but there was no open source prior art to borrow. Even though multiple Mesa drivers need geometry/tessellation emulation, nobody did the work to get there. My early progress on OpenGL was fast thanks to the mature common code in Mesa. It was time to pay it forward. Over the rest of the year, I implemented geometry/tessellation shader emulation. And also the rest of the owl. In January 2024, I passed conformance for the full OpenGL 4.6 specification, finishing up OpenGL. Vulkan wasn’t too bad, either. I polished the OpenGL driver for a few months, but once I started typing a Vulkan driver, I passed 1.3 conformance in a few weeks. What remained was wiring up the geometry/tessellation emulation to my shiny new Vulkan driver, since those are required for Direct3D. Et voilà, Proton games. Along the way, Karol Herbst passed OpenCL 3.0 conformance on the M1, running my compiler atop his “rusticl” frontend. Meanwhile, when the Vulkan 1.4 specification was published, we were ready and shipped a conformant implementation on the same day. After that, I implemented sparse texture support, unlocking Direct3D 12 via Proton. …Now what? Ship a great driver? Check. Conformant OpenGL 4.6, OpenGL ES 3.2, and OpenCL 3.0? Check. Conformant Vulkan 1.4? Check. Proton gaming? Check. That’s a wrap. We’ve succeeded beyond my dreams. The challenges I chased, I have tackled. The drivers are fully upstream in Mesa. Performance isn’t too bad. With the Vulkan on Apple myth busted, conformant Vulkan is now coming to macOS via LunarG’s KosmicKrisp project building on my work. Satisfied, I am now stepping away from the Apple ecosystem. My friends in the Asahi Linux orbit will carry the torch from here. As for me? Onto the next challenge!
English version follows. Aujourd’hui, Khronos Group a sorti la spécification 1.4 de l’API graphique standard Vulkan. Le projet Asahi Linux est fier d’annoncer le premier pilote Vulkan 1.4 pour le matériel d’Apple. En effet, notre pilote graphique Honeykrisp est reconnu par Khronos comme conforme à cette nouvelle version dès aujourd’hui. Ce pilote est déjà disponible dans nos dépôts officiels. Après avoir installé Fedora Asahi Remix, executez dnf upgrade --refresh pour obtenir la dernière version du pilote. Vulkan 1.4 standardise plusieurs fonctionnalités importantes, y compris les horodatages et la lecture locale avec le rendu dynamique. L’industrie suppose que ces fonctionnalités devront être plus courantes, et nous y sommes préparés. Sortir un pilote conforme reflète notre engagement en faveur des standards graphiques et du logiciel libre. Asahi Linux est aussi compatible avec OpenGL 4.6, OpenGL ES 3.2, et OpenCL 3.0, tous conformes aux spécifications pertinentes. D’ailleurs, les nôtres sont les seuls pilotes conformes pour le materiel d’Apple de n’importe quel standard graphique. Même si le pilote est sorti, il faut encore compiler une version expérimentale de Vulkan-Loader pour utiliser la nouvelle version de Vulkan. Toutes les nouvelles fonctionnalités sont néanmoins disponibles comme extensions à notre pilote Vulkan 1.3 pour en profiter tout de suite. Pour plus d’informations, consultez l’article du blog de Khronos. Today, the Khronos Group released the 1.4 specification of Vulkan, the standard graphics API. The Asahi Linux project is proud to announce the first Vulkan 1.4 driver for Apple hardware. Our Honeykrisp driver is Khronos-recognized as conformant to the new version since day one. That driver is already available in our official repositories. After installing Fedora Asahi Remix, run dnf upgrade --refresh to get the latest drivers. Vulkan 1.4 standardizes several important features, including timestamps and dynamic rendering local read. The industry expects that these features will become more common, and we are prepared. Releasing a conformant driver reflects our commitment to graphics standards and software freedom. Asahi Linux is also compatible with OpenGL 4.6, OpenGL ES 3.2, and OpenCL 3.0, all conformant to the relevant specifications. For that matter, ours are the only conformant drivers on Apple hardware for any graphics standard. Although the driver is released, you still need to build an experimental version of Vulkan-Loader to access the new Vulkan version. Nevertheless, you can immediately use all the new features as extensions in our Vulkan 1.3 driver. For more information, see the Khronos blog post.
Gaming on Linux on M1 is here! We’re thrilled to release our Asahi game playing toolkit, which integrates our Vulkan 1.3 drivers with x86 emulation and Windows compatibility. Plus a bonus: conformant OpenCL 3.0. Asahi Linux now ships the only conformant OpenGL®, OpenCL™, and Vulkan® drivers for this hardware. As for gaming… while today’s release is an alpha, Control runs well! Installation First, install Fedora Asahi Remix. Once installed, get the latest drivers with dnf upgrade --refresh && reboot. Then just dnf install steam and play. While all M1/M2-series systems work, most games require 16GB of memory due to emulation overhead. The stack Games are typically x86 Windows binaries rendering with DirectX, while our target is Arm Linux with Vulkan. We need to handle each difference: FEX emulates x86 on Arm. Wine translates Windows to Linux. DXVK and vkd3d-proton translate DirectX to Vulkan. There’s one curveball: page size. Operating systems allocate memory in fixed size “pages”. If an application expects smaller pages than the system uses, they will break due to insufficient alignment of allocations. That’s a problem: x86 expects 4K pages but Apple systems use 16K pages. While Linux can’t mix page sizes between processes, it can virtualize another Arm Linux kernel with a different page size. So we run games inside a tiny virtual machine using muvm, passing through devices like the GPU and game controllers. The hardware is happy because the system is 16K, the game is happy because the virtual machine is 4K, and you’re happy because you can play Fallout 4. Vulkan The final piece is an adult-level Vulkan driver, since translating DirectX requires Vulkan 1.3 with many extensions. Back in April, I wrote Honeykrisp, the only Vulkan 1.3 driver for Apple hardware. I’ve since added DXVK support. Let’s look at some new features. Tessellation Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders, as detailed in today’s talk at XDC2024. Geometry shaders Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute. Is that fast? No, but geometry shaders are slow even on desktop GPUs. They don’t need to be fast – just fast enough for games like Ghostrunner. Enhanced robustness “Robustness” permits an application’s shaders to access buffers out-of-bounds without crashing the hardware. In OpenGL and Vulkan, out-of-bounds loads may return arbitrary elements, and out-of-bounds stores may corrupt the buffer. Our OpenGL driver exploits this definition for efficient robustness on the M1. Some games require stronger guarantees. In DirectX, out-of-bounds loads return zero, and out-of-bounds stores are ignored. DXVK therefore requires VK_EXT_robustness2, a Vulkan extension strengthening robustness. Like before, we implement robustness with compare-and-select instructions. A naïve implementation would compare a loaded index with the buffer size and select a zero result if out-of-bounds. However, our GPU loads are vector while arithmetic is scalar. Even if we disabled page faults, we would need up to four compare-and-selects per load. load R, buffer, index * 16 ulesel R[0], index, size, R[0], 0 ulesel R[1], index, size, R[1], 0 ulesel R[2], index, size, R[2], 0 ulesel R[3], index, size, R[3], 0 There’s a trick: reserve 64 gigabytes of zeroes using virtual memory voodoo. Since every 32-bit index multiplied by 16 fits in 64 gigabytes, any index into this region loads zeroes. For out-of-bounds loads, we simply replace the buffer address with the reserved address while preserving the index. Replacing a 64-bit address costs just two 32-bit compare-and-selects. ulesel buffer.lo, index, size, buffer.lo, RESERVED.lo ulesel buffer.hi, index, size, buffer.hi, RESERVED.hi load R, buffer, index * 16 Two instructions, not four. Next steps Sparse texturing is next for Honeykrisp, which will unlock more DX12 games. The alpha already runs DX12 games that don’t require sparse, like Cyberpunk 2077. While many games are playable, newer AAA titles don’t hit 60fps yet. Correctness comes first. Performance improves next. Indie games like Hollow Knight do run full speed. Beyond gaming, we’re adding general purpose x86 emulation based on this stack. For more information, see the FAQ. Today’s alpha is a taste of what’s to come. Not the final form, but enough to enjoy Portal 2 while we work towards “1.0”. Acknowledgements This work has been years in the making with major contributions from… Alyssa Rosenzweig Asahi Lina chaos_princess Davide Cavalca Dougall Johnson Ella Stanforth Faith Ekstrand Janne Grunau Karol Herbst marcan Mary Guillemard Neal Gompa Sergio López TellowKrinkle Teoh Han Hui Rob Clark Ryan Houdek … Plus hundreds of developers whose work we build upon, spanning the Linux, Mesa, Wine, and FEX projects. Today’s release is thanks to the magic of open source. We hope you enjoy the magic. Happy gaming.
u{text-decoration-thickness:0.09em;text-decoration-color:skyblue} Finally, conformant Vulkan for the M1! The new “Honeykrisp” driver is the first conformant Vulkan® for Apple hardware on any operating system, implementing the full 1.3 spec without “portability” waivers. Honeykrisp is not yet released for end users. We’re continuing to add features, improve performance, and port to more hardware. Source code is available for developers. HoloCure running on Honeykrisp ft. DXVK, FEX, and Proton. Honeykrisp is not based on prior M1 Vulkan efforts, but rather Faith Ekstrand’s open source NVK driver for NVIDIA GPUs. In her words: All Vulkan drivers in Mesa trace their lineage to the Intel Vulkan driver and started by copying+pasting from it. My hope is that NVK will eventually become the driver that everyone copies and pastes from. To that end, I’m building NVK with all the best practices we’ve developed for Vulkan drivers over the last 7.5 years and trying to keep the code-base clean and well-organized. Why spend years implementing features from scratch when we can reuse NVK? There will be friction starting out, given NVIDIA’s desktop architecture differs from the M1’s mobile roots. In exchange, we get a modern driver designed for desktop games. We’ll need to pass a half-million tests ensuring correctness, submit the results, and then we’ll become conformant after 30 days of industry review. Starting from NVK and our OpenGL 4.6 driver… can we write a driver passing the Vulkan 1.3 conformance test suite faster than the 30 day review period? It’s unprecedented… Challenge accepted. April 2 It begins with a text. Faith… I think I want to write a Vulkan driver. Her advice? Just start typing. There’s no copy-pasting yet – we just add M1 code to NVK and remove NVIDIA as we go. Since the kernel mediates our access to the hardware, we begin connecting “NVK” to Asahi Lina’s kernel driver using code shared with OpenGL. Then we plug in our shader compiler and hit the hay. April 3 To access resources, GPUs use “descriptors” containing the address, format, and size of a resource. Vulkan bundles descriptors into “sets” per the application’s “descriptor set layout”. When compiling shaders, the driver lowers descriptor accesses to marry the set layout with the hardware’s data structures. As our descriptors differ from NVIDIA’s, our next task is adapting NVK’s descriptor set lowering. We start with a simple but correct approach, deleting far more code than we add. April 4 With working descriptors, we can compile compute shaders. Now we program the fixed-function hardware to dispatch compute. We first add bookkeeping to map Vulkan command buffers to lists of M1 “control streams”, then we generate a compute control stream. We copy that code from our OpenGL driver, translate the GL into Vulkan, and compute works. That’s enough to move on to “copies” of buffers and images. We implement Vulkan’s copies with compute shaders, internally dispatched with Vulkan commands as if we were the application. The first copy test passes. April 5 Fleshing out yesterday’s code, all copy tests pass. April 6 We’re ready to tackle graphics. The novelty is handling graphics state like depth/stencil. That’s straightforward, but there’s a lot of state to handle. Faith’s code collects all “dynamic state” into a single structure, which we translate into hardware control words. As usual, we grab that translation from our OpenGL driver, blend with NVK, and move on. April 7 What makes state “dynamic”? Dynamic state can change without recompiling shaders. By contrast, static state is baked into shader binaries called “pipelines”. If games create all their pipelines during a loading screen, there is no compiler “stutter” during gameplay. The idea hasn’t quite panned out: many game developers don’t know their state ahead-of-time so cannot create pipelines early. In response, Vulkan has made ever more state dynamic, punctuated with the EXT_shader_object extension that makes pipelines optional. We want full dynamic state and shader objects. Unfortunately, the M1 bakes random state into shaders: vertex attributes, fragment outputs, blending, even linked interpolation qualifiers. Like most of the industry in the 2010s, the M1’s designers bet on pipelines. Faced with this hardware, a reasonable driver developer would double-down on pipelines. DXVK would stutter, but we’d pass conformance. I am not reasonable. To eliminate stuttering in OpenGL, we make state dynamic with four strategies: Conditional code. Precompiled variants. Indirection. Prologs and epilogs. Wait, what-a-logs? AMD also bakes state into shaders… with a twist. They divide the hardware binary into three parts: a prolog, the shader, and an epilog. Confining dynamic state to the periphery eliminates shader variants. They compile prologs and epilogs on the fly, but that’s fast and doesn’t stutter. Linking shader parts is a quick concatenation, or long jumps avoid linking altogether. This strategy works for the M1, too. For Honeykrisp, let’s follow NVK’s lead and treat all state as dynamic. No other Vulkan driver has implemented full dynamic state and shader objects this early on, but it avoids refactoring later. Today we add the code to build, compile, and cache prologs and epilogs. Putting it together, we get a (dynamic) triangle: April 8 Guided by the list of failing tests, we wire up the little bits missed along the way, like translating border colours. /* Translate an American VkBorderColor into a Canadian agx_border_colour */ enum agx_border_colour translate_border_color(VkBorderColor color) { switch (color) { case VK_BORDER_COLOR_INT_TRANSPARENT_BLACK: return AGX_BORDER_COLOUR_TRANSPARENT_BLACK; ... } } Test results are getting there. Pass: 149770, Fail: 7741, Crash: 2396 That’s good enough for vkQuake. April 9 Lots of little fixes bring us to a 99.6% pass rate… for Vulkan 1.1. Why stop there? NVK is 1.3 conformant, so let’s claim 1.3 and skip to the finish line. Pass: 255209, Fail: 3818, Crash: 599 98.3% pass rate for 1.3 on our 1 week anniversary. Not bad. April 10 SuperTuxKart has a Vulkan renderer. April 11 Zink works too. April 12 I tracked down some fails to a test bug, where an arbitrary verification threshold was too strict to pass on some devices. I filed a bug report, and it’s resolved within a few weeks. April 16 The tests for “descriptor indexing” revealed a compiler bug affecting subgroup shuffles in non-uniform control flow. The M1’s shuffle instruction is quirky, but it’s easy to workaround. Fixing that fixes the descriptor indexing tests. April 17 A few tests crash inside our register allocator. Their shaders contain a peculiar construction: if (condition) { while (true) { } } condition is always false, but the compiler doesn’t know that. Infinite loops are nominally invalid since shaders must terminate in finite time, but this shader is syntactically valid. “All loops contain a break” seems obvious for a shader, but it’s false. It’s straightforward to fix register allocation, but what a doozy. April 18 Remember copies? They’re slow, and every frame currently requires a copy to get on screen. For “zero copy” rendering, we need enough Linux window system integration to negotiate an efficient surface layout across process boundaries. Linux uses “modifiers” for this purpose, so we implement the EXT_image_drm_format_modifier extension. And by implement, I mean copy. Copies to avoid copies. April 20 “I’d like a 4K x86 Windows Direct3D PC game on a 16K arm64 Linux Vulkan Mac.” … “Ma’am, this is a Wendy’s.” April 22 As bug fixing slows down, we step back and check our driver architecture. Since we treat all state as dynamic, we don’t pre-pack control words during pipeline creation. That adds theoretical CPU overhead. Is that a problem? After some optimization, vkoverhead says we’re pushing 100 million draws per second. I think we’re okay. April 24 Time to light up YCbCr. If we don’t use special YCbCr hardware, this feature is “software-only”. However, it touches a lot of code. It touches so much code that Mohamed Ahmed spent an entire summer adding it to NVK. Which means he spent a summer adding it to Honeykrisp. Thanks, Mohamed ;-) April 25 Query copies are next. In Vulkan, the application can query the number of samples rendered, writing the result into an opaque “query pool”. The result can be copied from the query pool on the CPU or GPU. For the CPU, the driver maps the pool’s internal data structure and copies the result. This may require nontrivial repacking. For the GPU, we need to repack in a compute shader. That’s harder, because we can’t just run C code on the GPU, right? …Actually, we can. A little witchcraft makes GPU query copies as easy as C. void copy_query(struct params *p, int i) { uintptr_t dst = p->dest + i * p->stride; int query = p->first + i; if (p->available[query] || p->partial) { int q = p->index[query]; write_result(dst, p->_64, p->results[q]); } ... } April 26 The final boss: border colours, hard mode. Direct3D lets the application choose an arbitrary border colour when creating a sampler. By contrast, Vulkan only requires three border colours: (0, 0, 0, 0) – transparent black (0, 0, 0, 1) – opaque black (1, 1, 1, 1) – opaque white We handled these on April 8. Unfortunately, there are two problems. First, we need custom border colours for Direct3D compatibility. Both DXVK and vkd3d-proton require the EXT_custom_border_color extension. Second, there’s a subtle problem with our hardware, causing dozens of fails even without custom border colours. To understand the issue, let’s revisit texture descriptors, which contain a pixel format and a component reordering swizzle. Some formats are implicitly reordered. Common “BGRA” formats swap red and blue for historical reasons. The M1 does not directly support these formats. Instead, the driver composes the swizzle with the format’s reordering. If the application uses a BARB swizzle with a BGRA format, the driver uses an RABR swizzle with an RGBA format. There’s a catch: swizzles apply to the border colour, but formats do not. We need to undo the format reordering when programming the border colour for correct results after the hardware applies the composed swizzle. Our OpenGL driver implements border colours this way, because it knows the texture format when creating the sampler. Unfortunately, Vulkan doesn’t give us that information. Without custom border colour support, we “should” be okay. Swapping red and blue doesn’t change anything if the colour is white or black. There’s an even subtler catch. Vulkan mandates support for a packed 16-bit format with 4-bit components. The M1 supports a similar format… but with reversed “endianness”, swapping red and alpha. That still seems okay. For transparent black (all zero) and opaque white (all one), swapping components doesn’t change the result. The problem is opaque black: (0, 0, 0, 1). Swapping red and alpha gives (1, 0, 0, 0). Transparent red? Uh-oh. We’re stuck. No known hardware configuration implements correct Vulkan semantics. Is hope lost? Do we give up? A reasonable person would. I am not reasonable. Let’s jump into the deep end. If we implement custom border colours, opaque black becomes a special case. But how? The M1’s custom border colours entangle the texture format with the sampler. A reasonable person would skip Direct3D support. As you know, I am not reasonable. Although the hardware is unsuitable, we control software. Whenever a shader samples a texture, we’ll inject code to fix up the border colour. This emulation is simple, correct, and slow. We’ll use dirty driver tricks to speed it up later. For now, we eat the cost, advertise full custom border colours, and pass the opaque black tests. April 27 All that’s left is some last minute bug fixing, and… Pass: 686930, Fail: 0 Success. The future The next task is implementing everything that DXVK and vkd3d-proton require to layer Direct3D. That includes esoteric extensions like transform feedback. Then Wine and an open source x86 emulator will run Windows games on Asahi Linux. That’s getting ahead of ourselves. In the mean time, enjoy Linux games with our conformant OpenGL 4.6 drivers… and stay tuned. Baby Storm running on Honeykrisp ft. DXVK, FEX, and Proton.
More in technology
There are few things worse than a dead AirTag when you need it. That's why we designed the The 4-Year Battery Keychain for AirTag. It replaces the low power CR2032 coin cell with an included Toshiba CR2477 battery for over 4x more capacity. And does so in a minimal form factor. Assembles in seconds. Split key ring + braided cord included. Easy to open with included tool. Perfect on a keychain. And great for backpacks or a purse. Also available on Amazon.
In the corner of the rear Floodgap lab sits a pile of classic game consoles. It used to look like this: Sega Dreamcast all the consoles here only came with NTSC RF output and date from the pre-flat panel TV era. That includes multiple Atari consoles (including the inevitable VCS, here a Darth Vader 2600), several Pong machines — including two Commodore units — with various chipsets, an Intellivision (as the rebadged Tandyvision One, my first) and a Bally Astrocade with lots of upgrades. It seems wrong to use them with a flat panel, and CRTs lag less. Plus, games with a light gun (here the Dreamcast and one of the Pong consoles) often rely on the CRT's rapidly scanning beam to know where they're pointed. So what do you do when the CRT TV goes bad? I should note that this isn't all the old school gaming fun in the house. In the commons next to the pinball machines are an Xbox 360 Slim and a PlayStation 2, and in the home theatre connected to the 3D projector is a PlayStation 3 since it has some stereoscopic titles. These might appear in future articles. But most of the rest are here. I bought this Panasonic Omnivision PV-M2035 from a friend at church in 1999 for $100 [about $200 in 2026 dollars]. He had no use for it, and the top of the plastic shell had been heat-warped by sitting in his car too long, but it worked, still had the remote, and was a suitably cheap TV for my unsuitably cheap studio apartment. I used it for local news and Friends with a set of rabbit ears, VHS movies, and speakers for playing music by connecting a CD player to the single rear input. When I moved to a less cheap 1-bedroom, it came along, and its flat top was flat enough to become a shelf for a DVD player. I got the Dreamcast from Fry's in 2001 after Sega discontinued it and managed to share the composite input between them. That apartment was my crashpad for about a decade before moving to the current orbiting HQ, whereupon I bought a passive-3D flat panel TV and moved the Omnivision to its current location in the back of the house. It shared the RF input between the Inty, and later the Atari 2600, and later still the Astrocade and various Pongs. At any one time there were at least four consoles always connected to it via switches and switchboxes, and I wired up an accessory port for more. plastic was broken and on these TVs that's pretty much the load-bearing part. When it arrived at the mailbox and I unpacked it, I could see the lower half had sandwiched right through the VCR slot, with visible PCB fragments and broken buttons; aside from the tube itself (ironically), the thing was a total loss. The seller nevertheless made good on the refund, to their credit, and I got to schlep it to the recycler. Overall, however, it had occurred to me that there were very few TVs sufficiently contemporary with the M2035 out there, which might be a hint about their general longevity. So, if I was going to be forced to buy a different Panasonic, then it might as well be a more recent one, and it should be one of the "triple play" units (i.e., TV, VCR, DVD) so that I could at least get rid of the external DVD player. Mission: Impossible '88 and '89 DVD sets, where the "in stereo" animation was even burned into the video stream.) not recording and thus impossible to watch many DVDs, for which the Sima CopyMaster was the cheapest solution: it simply blots out that portion of the vertical blank along with the pulses, which also has the side effect of sometimes stripping closed captioning (in the vertical blank as well), though DVDs with proper subtitles are of course unaffected. Later Sima devices could regenerate portions of the vertical blank for better quality, and Macrovision actually sued them over their products in 2005, but later settled. The mixer on the right was purchased literal decades ago at Radio Shack (more specifically a "Video Enhancer Stereo Audio Mixer") that I think we used for a Halloween display exactly once and then forgot about. Here it was used first as a cutoff switch, and second as a way to match the audio volume from the DVD player with the audio volume from the Dreamcast, which was also directly connected to the second rear Y-cable. This TV is mono, so the stereo channels from the audio mixer and the DC get merged using their own Y-connectors (also Radio Shack) before going into the Y-cable to the single line audio input. The video function isn't used here at all; it was just a audio mixer on the shelf I wasn't otherwise using. The DVD player is under the mixer and the CopyMaster, a cheapie Sony special that will only eject discs if it's in the mood or summarily threatened with violence. You already met this system when we adjusted the laser pickup and refurbished its rechargeable battery. you met the Tandyvision One (otherwise identical to the Mattel Intellivision Master Component, and manufactured by them as an OEM) when we installed a composite video modification and a front power-cutoff reset. I later upgraded it with an original Mattel Intellivoice speech synthesizer (Tandy never rebadged these) and a CuttleCart. But you haven't met the Bally on the bottom, officially introduced in 1978 as a game console and simple home computer, sold under various names such as the Bally Professional Arcade seen on early units, later the Bally Computer System badging here, and now collectively referred to under its final incarnation as the Astrocade. These machines were based around a 1.789MHz Z80 (half NTSC colourburst) combined with the same graphics hardware Dave Nutting Associates used for Midway's arcade games Gorf and Wizard of Wor, among others. Unfortunately, much of its theoretical graphics power went unrealized because it only has half the video memory of the arcade units (i.e., 4K) — and that's all the memory it has, so it has to interleave bits in the video memory to store BASIC programs, meaning only game ROMs can take full advantage. Still, that was enough to be solid competition for the likes of the Atari VCS and Fairchild Channel F, and it holds its own well against the slightly later Intellivision. does have is a doozy: the cooling vents are on the underside. These machines are very prone to overheating and can be easily damaged by it, which is why I use two foam struts to keep it off the carpet. The yellow label is for Astrovision, a separate enterprise that had been attempting to develop their own console. The (then) Bally Professional Arcade was selling poorly, though part of this was due to a tardy launch and Bally's weak retail presence, and Bally decided to sell off the consumer products division in 1979. Astrovision, unable to get their unit to market quickly, bought it in 1981 along with a limited license to the Bally name and reintroduced it at Winter CES 1982. Astrovision units are otherwise the same except for the badging and are the most common Astrocades today, though the company became another victim of the 1983 video game crash and went bankrupt shortly afterwards. Simultaneously, an Astrocade derivative merged with Bally's unfinished ZGRASS-100 expansion chassis was reworked into the Datamax UV-1 graphics generator, sold in small numbers until around 1982. the wall warts and power strips, and do a little spot vacuuming with the Roomba. out in spring. Gremlin's Blockade; and a simple calculator and screen paint toy ("Scribbling"). The display is a bit noisier than the Inty/Tandyvision, probably because of the difference in shielding, but still quite good. Videostak Video Game Center, which allegedly could accomodate a VCS, Intellivision or ColecoVision. The front decal is somewhat worn and the woodgrain veneer doesn't match the Vader VCS nearly as well, but it's still a fun-looking setup. Intellivision System Changer which has Atari 2600 hardware in an expansion box for the Intellivision II (useable on the original Inty with modification). It might be fun to explore the reputed irregularities between what is believed to be a VTI clone TIA in the System Changer and the slightly earlier Coleco Expansion Module 1 (and the related Coleco Gemini), and see how they differ in practice. Now for the Pong machines. These attach to the "accessory port" on the input switcher. The current Pong menagerie are mostly MOS 7600-based, MOS' own Pong-on-a-chip: two from Commodore themselves but PAL only using the MOS 7601 (the TV Game 2000K and TV Game 3000H), plus two MOS 7600 (NTSC) systems, a Coleco Telstar Gemini, not to be confused with the Coleco Gemini or Coleco Telstar, and an Allied Leisure Name of the Game II, possibly the earliest use of the chip in NTSC regions. We'll play the Name of the Game II and Telstar Gemini below. These will be consoles for another day, but I also have a boxed Atari Video Pinball, an "honorary" Pong machine though it plays several other games, and a boxed Atari Ultra Pong Doubles, which we had before we got the Tandyvision, but I don't ever recall it working fully and it later failed to power up and got thrown away, so this is a replacement. My least favourite of the Pongs here (I really only picked it up because it was cheap) is a 1977 Magnavox Odyssey 3000. The 3000 is basically an upmarket Odyssey 2000 with proper handheld controllers, but otherwise the same me-too AY-3-8500 Pong-on-a-chip generating the same black-and-white display. Allied Leisure Name of the Game II is a two-player Pong based on the MOS 7600-001. This chip notionally contains three field games (a tennis game, a "goal" game usually billed as either soccer or hockey, and a racquetball game) and a skeet shooter, but the racquetball game can be put into a single player mode by setting it to "four" players and the NotG2's switch triggers this mode in place of the skeet shooter. It was noisy on the other TV and it's noisy here, possibly because it has its own internal RF switchbox, but it plays fine. Coleco Telstar Gemini, an MOS 7600-004 system. This has two "pinball" variants (with flippers and moveable Pong paddles, so it's still a Pong of sorts) and two shooting gallery variants involving shooting a deformed bear sprite. The light gun connector is the same as the Coleco Telstar, so I borrowed the gun from that. sing along with The Offspring. But the output looks crisp through the rear jacks, the sound is proper stereo, and we now have front inputs I can use for something else without rigging a whole bunch of Y-adapters again. Plus, if the Telstar Gemini's gun works, it's all but guaranteed the Dreamcast's does. am likely to play some Video Pinball, and in its box that's easy to move, so that can go on top of the 2600 and the NotG and Telstar Gemini can sit next to it. The old TV is out in the garage and as I have time I'll extract its circuit boards and go over them more thoroughly, since I had a lot of good times with that television and it would be nice to fix. If I do, I'll write it up here, since it's an actual old VCR. Meanwhile, I have some possible projects in mind for the Tandyvision and Astrocade, and maybe some mods to go in the VCS, and you can read about those in future articles too. In the end, with the new TV all set up, the 1980s can live again in my rear office. Or, as my wife likes to point out, they never actually died there either.
By a mile, the iPhone Duo has garnered more questions about what I think about it than any other phone I’ve ever had. It’s clearly a phone that has people intrigued, so I thought I’d jot down some loose, unorganized thoughts about what I think about it after about ten days. If I could sum all my thoughts up into one word, it’d simply be “fun”. I think for the vast majority of people, myself included, the iPhone 18 Pro is a more practical phone that through scientific analysis you’d likely even find a better phone. Even if they were priced the same, its package is more traditionally comfortable and ergonomic, with a better quality main camera, a helpful telephoto camera, a screen that’s more practical to use more of the time, a better biometric system (Face ID versus Touch ID) and a more established software experience. But damn if the iPhone Duo isn’t fun. Phones have been downright boring for so long. Incredible technology, lovely apps, but the hardware has been a bit slow moving since the iPhone X. Maybe that’s why I jumped onto the iPhone Air so readily. Even that slight departure from “black slab of glass” to “a dramatically thinner black slab of glass” was exciting versus what we’ve grown accustomed to. So I pick up the Duo, and it’s kinda just exciting to hold a phone for the first time in ages. Maybe that’s a honeymoon period and after a few months I’ll be over it. Maybe everyone who tries a folding phone for the first time experiences this. And to be clear, it’s not just all raw novelty. The fun aspect is fueled by having an absolutely incredible inner screen that fundamentally transforms what a phone is and can be. In addition, support the Apple Pencil has turned out to be phenomenally handy for me to be able to jot down quick thoughts and notes. For downsides, Touch ID is objectively worse than Face ID, but honestly, I don’t mind it as much as I expected I would. The smaller camera sensor than the Pro series phones is still decidedly great (rumors were it was a 17e size which was not correct, it’s the size of the normal 17’s). Software support gets better by the day, though iOS on the Duo is still decidedly a bit buggy at times. Other random thoughts Touch ID is objectively worse than Face ID, but honestly, I don’t mind it as much as I expected I would, previewing notifications is where I miss it the most After getting used to having a single speaker in the iPhone Air for a year, having stereo (not to mention great sounding) speakers is amazing The FaceTime camera on the inside is indeed not great for selfies/photography but honestly perfectly acceptable for FaceTime, and I’d definitely prefer this solution over a cutout on the inside so I’m happy! It definitely has a heavy feel to it, but it’s nothing honestly that bothersome A lot of the reviews said something to the effect of “the crease is practically invisible” and while I don’t really mind it or anything I definitely would disagree with that statement, you can see it a fair bit even with light content The hinge is a bit harder to open than I expected, I’ve found the secret is don’t pry from the middle of the side, instead put a thumb near the top and bottom (also helps prevent pressing Camera Control instead which I was doing all the time). I imagine this is necessary to have it be able to stop at arbitrary angles once open (which I do like) and hopefully it loosens up a bit with more use, but playing with Android foldables at Best Buy I did find their hinge easier to open I am really split on the inner, nano texture screen. It definitely helps reflections, has a neat look to it, and is super nice to draw on with the pencil, but it’s significantly less vibrant than the outer display which to my eyes looks a fair bit nicer. I think they made the right decision ultimately but it’s definitely not a zero-compromise solution. I was considering nano texture on my next MacBook but after this I think I’ll stick with glossy. My glass half full take with the Duo for now though is that we get two really cool screens to play with The outer screen is awesome for taking photos, unlike taller iPhones, your viewfinder fills the screen completely so it’s the largest feeling viewfinder I’ve used on a phone I miss the action button, nice little launcher for ChatGPT/Claude depending on which month it is Battery life is downright phenomenal versus my iPhone Air and 15 Pro (two devices admittedly not known for having great battery life) So, I don’t think the Duo is for most people who either don’t care much about phones, or care a lot about having the perfect phone, but for a decent amount of people in the middle I think the Duo represents a fundamentally different experience, that’s a ton of fun, and I’m excited to be excited about a phone again. (But, Apple, please figure out a way to add a telephoto lens.)
Going through a collection of old parts, CuriousMarc encountered some ICs that he couldn't identify. He opened up one of these ICs, and I studied it under the microscope. After some reverse engineering, I determined that it was a logic chip that implemented four NAND gates using old-fashioned diode-transistor logic (DTL).1 The chip turned out to be the ST680A, a member of the Signetics 600 series of chips from 1965. In this article, I discuss the circuitry in this chip and how diode-transistor logic works. The die of the ST680A under the microscope. Integrated circuits can be packaged in many ways. One of the most popular is the plastic DIP (Dual In-line Package), a black rectangle of epoxy with two rows of metal pins. This type of package was invented by Signetics: "Introduced in late 1965, the 600 series was the first integrated circuit family to be offered in a solid, plastic, dual in-line package (DIP)." Earlier integrated circuits were packaged in round metal cans or in small flat-packs. In 1965, engineers at Fairchild invented the DIP, which had two rows of pins on 0.1" spacing. Unlike the surface-mounted flat-pack, the DIP had pins that were inserted into holes, making manual or automated assembly quick and easy. Because the pins of a DIP were on a regular grid, rather than the circular pattern of a metal can, circuit board design and manufacturing were also easier (details). The first DIP chips had ceramic packages. The plastic DIP, introduced by Signetics, was much cheaper and became very popular. An advertisement for the Signetics 600 series. From Electronics, March 21, 1966. The plastic DIP is less popular with me, however, because it is harder to open. With a ceramic package, I can simply tap it with a chisel and pop it open, but that doesn't work with epoxy packages. An epoxy package can be dissolved with nitric or sulfuric acid, but I try to avoid dangerous acids. Instead, CuriousMarc used Antoine's hot air decapping method. Unfortunately, the hot air technique doesn't always work. In this case, tiny bits of epoxy were stuck to the die, obscuring the circuitry. I used a few drops of boiling sulfuric acid to clean the die. (I'm okay with sulfuric acid in tiny quantities.) The die on its metal frame. The photo above shows the silicon die on its metal frame, the lead frame. The golden blobs are where the bond wires were attached to the die. You can see the doped silicon regions that form diodes and bipolar NPN transistors, as well as 16 resistors in the center, forming serpentine paths. Most chips have a passivation layer—a thin layer of silicon dioxide—over the chip. Inconveniently, this old chip didn't have a passivation layer, so the acid also stripped off the metal layer. (A few remnants are visible in the upper left.) Without the metal layer, I had to guess at how the components were connected to form logic gates. The die has very faint color differences where the silicon was protected by the metal, so that helped. Eventually, I came up with the diagram below, showing how the metal layer was probably configured. This wiring reveals that the chip implements four DTL NAND gates, which I'll describe in more detail below. One puzzle was that the chip has two unused diodes, indicated with question marks below. The metal layer for a quad NAND chip. I desaturated the image to make the labels clearer. Transistors, diodes, and resistors In this section, I'll explain how the patterns in the image correspond to components of the circuit. The silicon die is doped with various impurities to form regions with different electrical characteristics. These regions appear red or green under the microscope due to thin-film effects. As a result, the chip's transistors, diodes, and resistors are visible. The chip is made from bipolar NPN transistors, which have a completely different construction from the MOS transistors in modern ICs. In an NPN transistor, the current from the collector to the emitter is controlled by the current through the base. The collector is a large region of N-type silicon, silicon that is doped with atoms such as phosphorus or arsenic. Since these elements have one more valence electron than silicon, they give the silicon more negative charge carriers, so it is called N for negative. The N-type silicon happens to appear reddish. On top of the collector, the base is a thin region of P-type silicon, which appears green. This silicon has been doped with atoms such as boron or gallium, which have one fewer valence electron than silicon. The missing electrons form "holes", which act as positive charge carriers. Finally, the emitter is N-type silicon, on top of the base layer. These layers work together through semiconductor magic, amplifying the base current. Two NPN transistors on the chip. The second transistor is a larger output transistor. The chip's output transistors are slightly larger so they can sink more current. In the transistor on the right above, note that the collector contact wraps around three sides of the transistor. The emitter is also larger, with an L-shaped contact. According to the datasheet, each output transistor can sink 2.5 mA of current. The chip uses many diodes since it is diode-transistor logic. The structure of a diode is similar to a transistor, but without the emitter. In a diode, current flows from the cathode (P-type silicon) to the anode (N-type). A diode and a resistor on the chip. The chip uses 16 resistors, located in the middle of the die. A resistor is constructed from a long, thin region of doped silicon. Since silicon has moderately high resistance, a long strip of silicon acts as a resistor. Most of the resistors have a serpentine layout to fit a long resistor into a smaller area. These resistors consist of P-type silicon (green) in a "tub" of N-type silicon (red). The tub is connected to the positive voltage supply; since current doesn't flow from N-type silicon to P-type silicon, this isolates the resistors from each other. Operation of a DTL gate Logic gates can be created in many ways. The earliest integrated circuits (such as the ones in the Apollo Guidance Computer) used Resistor-Transistor Logic (RTL), where logic gates were constructed from resistors and transistors. In March 1962, Signetics announced the first family of commercial Diode-Transistor Logic (DTL) integrated circuits (details). By using diodes on the inputs instead of resistors, DTL provided better performance than RTL. However, DTL soon became overshadowed by TTL (Transistor-Transistor Logic), which was faster and used less power. (If you built digital circuits a few decades ago, you're probably familiar with the popular 7400 series of TTL chips.) The diagram below shows how the DTL NAND gate works. If both inputs are high, the current from the first resistor flows through the base of the first transistor, turning it on. The transistor amplifies this current, passing a much larger current from the transistor's collector to the transistor's emitter. This current goes through the base of the second transistor, which turns on the second transistor. The second transistor passes an even larger current from the output pin to ground, pulling the output pin low. The DTL NAND gate with both inputs high. The schematic is from the datasheet. This circuit is considerably more complicated than the DTL gate on Wikipedia. But if one of the input pins is pulled low, the current from the resistor goes through the diode instead of the transistor. The first transistor turns off, and without a base current, the second transistor turns off. The third resistor pulls the output high. Thus, the output is low only if both inputs are high: a NAND gate. The DTL NAND gate with an input low. I'll point out a few features of this circuit. The diodes on the inputs ensure that one input doesn't affect the other input. The diode in the middle raises the voltage on the first transistor's emitter, so it requires more voltage to turn on, reducing the sensitivity to noise. The output uses a resistor to pull the output high; more advanced circuits use another transistor. When the output is low, the third resistor is still "trying" to pull the output high, which is wasting power. Moreover, the resistor limits the output current, so the high output is fairly weak. In some DTL families, you can get gates with different values for the output resistor, so you can select the tradeoff between wasting power and having an output that is too weak. If you've used TTL integrated circuits from the 1970s, you know that chips usually have power and ground on diagonal pins: ground on pin 7 and power on pin 14. (Putting power and ground diagonally opposite both helps die layout and circuit board layout.) Much to my surprise, I found that the Signetics chips predate this standard and have ground on pin 1 and power on pin 8: still diagonal, but the wrong diagonal! The diagram below shows how the four NAND gates are wired in the chip. Pinout of the 680A quad NAND gate. From the databook. Three chips from one die When I examined the die under the microscope, I figured out the circuit, but I was puzzled by two extra diodes, as if two NAND gates had a third input that wasn't used. The explanation is that Signetics used the same silicon layout for at least three different chips, applying a different metal layer for different functionality. This saved money since it's much cheaper to produce a single optical mask for the metal layer than a complete set of new masks. Signetics sold semi-custom ICs to customers, using an approach called variFEBS (Variable Functional Electronics Blocks). This approach used a custom metal layer on top of fixed silicon, providing custom circuits without the cost of a full mask set. These circuits didn't sell well, but Signetics used the same approach for standard ICs. Pinout of the 670A triple NAND gate and the 616A quad NAND gate. All three chips have some similarities, such as using pins 2 and 14 as outputs. From the databook. One IC with the same silicon as the quad NAND gate is the 670A chip, which has three NAND gates, each with three inputs (above left). The diagram below shows how the silicon can be wired to provide this functionality. The hypothesized metal layer for the 670A triple-NAND gate. The layout for the triple chip above is a bit tricky because the top gate has inputs on both sides of the power (Vcc) pin. This creates a layout problem because the power and ground metal runs vertically to the resistors, blocking metal wiring from one side to the other. The solution is a "crossunder", a region of silicon that allows a signal to pass under the metal layer, connecting the inputs on the left to the rest of the circuitry on the right. This crossunder is visible near the top of the chip. Another chip with the same layout is the 616A dual NAND gate, with five inputs on each gate. Since this chip has 10 inputs in total (compared to 8 on the quad gate), this chip uses the two "extra" diodes that I spotted. If that isn't enough inputs, each NAND gate has an expansion input; by connecting external diodes to the expansion input, the gate can be made as large as desired. The hypothesized metal layer for the 616A dual-NAND chip. Some history The history of Signetics is closely tied to Fairchild. The story of Fairchild's founding is well known: in 1957, eight engineers—the Traitorous Eight—left Shockley Semiconductor and created Fairchild Semiconductor. Hundreds of companies (the "Fairchildren") were started by engineers who left Fairchild. Signetics was one of those companies, formed in 1961 and said to be the first company to exclusively design and manufacture integrated circuits.2 Signetics announced its first product in 1962, a NAND gate that cost $125 (over $1000 in current dollars).3 Not surprisingly, sales were weak. Signetics soon ran short of money, so in 1962, Corning Glass invested $1.7 million for 51% ownership of Signetics. Corning Glass may seem like a strange investor, but Corning was more of a high-tech company than you'd expect, making components such as resistors and glass capacitors, and later creating fiber optics. Moreover, in the early 1960s, integrated circuits were the hot area (much like AI now), and everyone wanted to get involved. In 1963, the Department of Defense pushed for contractors to use integrated circuits in new products. Riding this wave, Signetics became the leading producer of integrated circuits.4 However, Fairchild soon introduced a series of DTL chips that competed with Signetics. The Fairchild 930 series was faster than the Signetics chips and less than half the price, so Fairchild took much of the market from Signetics and dominated the IC market. Signetics also produced analog integrated circuits. Signetics is probably best known for creating the 555 timer chip in 1970, said to be the world's most popular IC, with billions sold.5 Signetics was acquired by Philips in 1975, and then Philips Semiconductors was spun off as NXP (Next exPerience) in 2006. NXP is currently the #10 semiconductor manufacturer worldwide, so the heritage of Signetics lives on. For more, follow me on Bluesky (@righto.com), Mastodon (@[email protected]), or RSS. Thanks to CuriousMarc for providing the IC and thanks to TubeTime for finding the databook. AI statement: Despite the presence of the em dash, no AI was used in the writing of this article (details). Notes and references After I had reverse-engineered the chip, TubeTime found datasheets for it, making my reverse engineering unnecessary. (See the Signetics Condensed Catalog 1969, Utilogic II Databook 1971, and Utilogic 2 Databook 1972.) We must have been unlucky with our original web searches since we didn't find anything. But this way you get to see what's inside the chip :-) The Signetics ST680A IC in its package. The large circular depression marks pin 1. From the date code, this chip is from 1971. ↩ For more Signetics history, see Signetics Founding History, written by Lionel Kattner, a co-founder of Signetics. He states that the company name was inspired by the words "signals" and "networks", as well as the high-tech suffix "-netics". ↩ See History of Semiconductor Engineering, page 156. ↩ The book Making Silicon Valley describes the history of Signetics. It has a negative view of the Corning investment, saying that Signetics executives "Van Poppelen and Kattner dissented on the grounds that Corning was not a good fit for an integrated circuit company. In their view, Corning was a staid Eastern firm, ignorant about semiconductors and antithetic to the ways and culture of the electronics industry on the West Coast. Their view later proved to be correct." ↩ The 555 timer was created by analog IC wizard Hans Camenzind. If you're interested in analog circuits, you should read his book Designing Analog Chips, which you can download for free. ↩