dual screen cyberdeck

Ditch The Laptop For The Tabletop

The idea of a cyberdeck is simple. A relatively portable case that is primarily a keyboard with some screen attached. Cyberdecks often try to hit a particular aesthetic or vibe rather than focusing on usability or practicality. [Carter Hurd] took a step back and asked himself what would be a cyberdeck-like system that he could practically use every day.

[Carter’s] build is a prototype that allows him to try out the form factor and use it as a daily driver, so many decisions were made to speed up the build and get something functional. For example, rather than spend the time tweaking and printing his own keyboard, he used an off-the-shelf keyboard he knew he liked. While a framework motherboard would have been perfect for something like this, they, unfortunately, weren’t available when [Carter] started the build. So [Carter] used a used gaming laptop for the task. He had hoped to drive the display directly from the motherboard as many laptops use embedded DisplayPort internally. Unfortunately, this didn’t work as the motherboard didn’t support the resolution he was trying to drive at, so he just used the external port to drive the screen. A 3d printed base fits underneath the keyboard to hold the laptop motherboard with little extensions for bits that don’t work well, such as the wifi card. The chassis also has a slot that allows a secondary display to slot right in.

Ultimately, it is something of a modern-day typewriter and something like a cyberdeck. Either way, we love it. Video after the break.

Continue reading “Ditch The Laptop For The Tabletop”

Hack Another ELF On The Stack

[dropbear] recently found herself in a pickle. Dumping some data out of an Android app at a specific point for reverse engineering purposes. While it worked great in the simulator, it was painfully slow on hardware via lldb. The solution was to write a patch and apply it to the ELF file.

Writing the AArch64 assembly to dump the buffer is relatively trivial, but adding it to the existing ELF and repackaging it into a new APK leads to strange errors. The relative offsets into .rodata are now all wrong. For those who don’t routinely interface with the format of ELF files, we have a fantastic resource to take you into the dark depths. But the quick summary version is that sections contain various resources, and you find parts of those resources by relative offsets. The program header describes what type of resources each section contains.

[dropbear] found a NOTE section that just contained some metadata. She created a new section at the end of the file for her custom assembly and modified the header to declare the NOTE section as a LOAD section that pointed at her new section, which would get mapped into memory. All that was left to do was tweak the assembly in the actual code to jump to her new code that dumps. The BSS section was extended by a few bytes so that her program could store its state there.

It’s an impressive technique, and her program for modifying the program header is on her website under a BSD-3 license.

AVX-512: When The Bits Really Count

For the majority of workloads, fiddling with assembly instructions isn’t worth it. The added complexity and code obfuscation generally outweigh the relatively modest gains. Mainly because compilers have become quite fantastic at generation code and because processors are just so much faster, it is hard to get a meaningful speedup by tweaking a small section of code. That changes when you introduce SIMD instructions and need to decode lots of bitsets fast. Intel’s fancy AVX-512 SIMD instructions can offer some meaningful performance gains with relatively low custom assembly.

Like many software engineers, [Daniel Lemire] had many bitsets (a range of ints/enums encoded into a binary number, each bit corresponding to a different integer or enum). Rather than checking if just a specific flag is present (a bitwise and), [Daniel] wanted to know all the flags in a given bitset. The easiest way would be to iterate through all of them like so:

while (word != 0) {
  result[i] = trailingzeroes(word);
  word = word & (word - 1);
  i++;
}

The naive version of this look is very likely to have a branch misprediction, and either you or the compiler would speed it up by unrolling the loop. However, the AVX-512 instruction set on the latest Intel processors has some handy instructions just for this kind of thing. The instruction is vpcompressd and Intel provides a handy and memorable C/C++ function called _mm512_mask_compressstoreu_epi32.

The function generates an array of integers and you can use the infamous popcnt instruction to get the number of ones. Some early benchmark testing shows the AVX-512 version uses 45% fewer cycles. You might be wondering, doesn’t the processor downclock when wide 512-bite registers are used? Yes. But even with the downclocking, the SIMD version is still 33% faster. The code is up on Github if you want to try it yourself.

How A Smartphone Is Made, In Eight “Easy” Blocks

The smartphone represents one of the most significant shifts in our world. In less than thirteen years, we went from some people owning a dumb phone to the majority of the planet having a smartphone (~83.7% as of 2022, according to Statista). There are very few things that a larger percentage of people on this planet have. Not clean water, not housing, not even food.

How does a smartphone work? Most people have no idea; they are insanely complicated devices. However, you can break them down into eight submodules, each of which is merely complex. What makes them work is that each of these components can be made small, at massive economies of scale, and are tightly integrated, allowing easy assembly.

So without further ado, the fundamental eight building blocks of the modern cellphone are: the application processor, the baseband processor, a SIM card, the RF processor, sensors, a display, cameras & lenses, and power management. Let’s have a look at them all, and how they fit together.

Continue reading “How A Smartphone Is Made, In Eight “Easy” Blocks”

Reflecting On A Queueing Prism Leads To Unexpected Results

Computers are difficult enough to reason about when there’s just a single thread doing one task. There are dozens of cores in today’s modern processor world, and your program might try to take advantage of using more than just one. Things happening concurrently makes the number of states and interactions explode in to a mess we as humans are likely going to have trouble understanding. So, like [Hillel], you might turn to the computer to try and model those interactions.

The model in question is a task queue. Things are added to the pile, and “workers” grab one from the pile and process it. There are two metrics used to measure the effectiveness of a task queue: throughput and latency. Throughput is the number of things you can do per second (like this maximum throughput 3d printer), while latency is the amount of time it takes to finish one thing. Continue reading “Reflecting On A Queueing Prism Leads To Unexpected Results”

Bringing Zelda Classic To The Browser

Finding a device or app that isn’t a web browser doesn’t seem easy. These days, it is either connected to the web (looking at you ESP32) or is just a web browser pretending to be something else (a la electron, PWAs, or React Native). So, of course, it is on us to create more and more exciting things to browse. [Connor Clark] is one of those people, and he brought Zelda Classic to the browser.

Zelda Classic (ZC) isn’t an official Zelda game. Instead, it’s an old engine designed to run the world in the OG Legend of Zelda and be easily modified to support hundreds of different games. To date, there are over 600 games submitted by a large community. ZC is an Allegro-based Windows-only game, so the first step was to bust out Emscripten to start tweaking the C++ code to support a web environment. Rather than completely port the huge codebase over from Allegro, [Connor] made the jump from Allegro 4 to 5. Allegro 5 has SDL as a backend and adds support for Emscripten.

Unfortunately, the 4 to 5 wasn’t as simple as changing the dependency. The API was wholly re-written, and there is a handy adapter known as Allegro Legacy to help transition a project from one to another. After squashing a multitude of bugs, it was a relatively painless procedure. After a quick detour getting music and level data working, [Connor] faced his next challenge: multi-threading. Efforts to move the main loop off of the browser thread and into a web worker ran into issues with having to yield in loops, deadlocks, and recursive mutexes. Finally, he added music and gamepad support after fixing several bugs in SDL and Allegro.

It’s an incredible journey with many tips and tricks for debugging seemingly intractable bugs. The code is up on GitHub, or jump in and start playing if you’re interested. Why not check out this browser-based OpenSCAD as well?

Photo rail setup for stop motion

Stop-Motion Angels In The Light Field

Baseball jokes aside, holograms have been a dream for decades, and with devices finally around that support something like them, we have finally started to wonder how to make content for them. [Mike Rigsby] recently entered his stop-motion holographic setup into our sci-fi contest, and we love the idea.

Rather than a three-dimensional model or a 2d picture with pixels, the Looking Glass light field display supports a series of images as quantized points (hence light field). As you move around an object, images are interpolated between the frames you do know, giving a pretty convincing effect. In a traditional stop motion animation, you need to take anywhere between 12-24 frames to equal about one second of animation. Now that you need to take 48 pictures for one frame, over 1152 pictures for just one second of animation. Two problems quickly appear, how to take photographs accurately from the same position every time and how do you manage the deluge of photos sensibly. [Mike] started with a wooden stage for his actors. A magnet was mounted to the photo rail carriage, and a sensor allowed it to detect that it was in the same spot. An Arduino controls the rail, reads the magnet via a sensor, and controls the camera shutter. The DSLR he’s using can’t do that many frames per second, but that’s a problem for another sci-fi contest.

Holographic-ish displays are finally here, and they’re getting better. But if a display isn’t your speed, perhaps some laser-powered glasses can be the holographic experience you’re looking for?

This project was an entry into the 2022 Sci-Fi Contest. Check out all of the winning entries here.