After decades of improvements to hard disk drive (HDD) technology, manufacturers are now close to taking the next big leap that will boost storage density to new levels. Using laser-assisted writes, manufacturers like Seagate are projecting 50+ TB HDDs by 2026 and 120+ TB HDDs after 2030. One part of the secret recipe is heat-assisted magnetic recording (HAMR).
One of the hurdles with implementing HAMR is finding a protective coating for the magnetic media that can handle this frequent heating while also being thinner than current coatings, so that the head can move even closer to the surface. According to a recent paper by N. Dwivedi et al. published in Nature Communications, this new protective coating may have been found in the form of sheets of graphene.
With the market for STM32F103C8-based ‘Blue Pill’ boards slowly being overrun with boards that contain either a cloned, fake or outright broken chip, [Terry Porter] really wanted to have an easy, automated way to quickly detect whether a new board contains genuine STM32 silicon, or some fake that tries to look the part. After more than a year of work, the Blue Pill Diagnostics project is now ready for prime time.
We have covered those clone MCUs previously. It’s clear that some of those ‘Blue Pill’ boards obviously do not have a genuine STM32 MCU on them, as they do not have the STM32 markings on them, while others fake those markings on the package and identifying can be hard to impossible. Often only testing the MCU’s actual functionality can give clarity on whether it’s a real STM32 MCU.
These diagnostics allow one to test not only the 64 kB of Flash, but also the 64 kB of ‘hidden’ Flash that’s often found on these MCUs (rebadged 128 kB STM32F103 cores). It further checks the manufacturer JDEC code and uses a silicon bug in genuine STM32F1xx MCUs where the BGMCU_IDCODE cannot be read without either SWD or JTAG connected.
Another interesting feature of Blue Pill Diagnostics is using Mecrisp-Stellaris Forth as its foundation, which allows for easy access to a Forth shell via this firmware as well, not unlike MicroPython and Lua, only in a fraction of the Flash required by those. We have previously written about using Mecrisp-Stellaris in your projects.
[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.
[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.
As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.
An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.
Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.
Turning a game like Super Mario World for SNES into a widescreen game is not a small task, but [Vitor Vilela] accomplished just that. [Vitor] has a long list of incredible patches such as optimizing code for better frame rates and adding code to take advantage of the SA-1 accelerator chip, so out of anyone he has the know-how to pull a widescreen mod off. This patch represents a true labor of love as many levels were designed with a specific screen width in mind. [Vitor] went through each of these single-screen width levels and expanded them by writing the extra assembly needed.
On a technical level, this hack was achieved by using the panning feature built into the game. The left and right shoulder buttons allowed a player to pan the camera to the left and right. The viewport is considered to be two times the screen resolution and so items will be rendered within the widescreen resolution. By taking away the panning feature and render a larger section of the viewport to the screen, you get a widescreen view. However, to save cycles, enemies and items don’t start moving until they get close to the screen edge. So how do you make a game widescreen without ruining the timing of every enemy that spawns? Suddenly the hours of muscle memory that fans have drilled in over the years is a disadvantage rather than a strength. The answer is a significant time investment and an eye for detail.
All the code is available on GitHub. A video of a playthrough of the mod is after the break.
Game developer and eternal learner [David Tucker] just posted a project where he’s making linear flexures on a 3D printer. Tinkerer [Tucker] wanted something that would be rigid in five of the six degrees of freedom, but would provide linear motion along one axis. In this case, it is for a pen or knife on a CNC flatbed device. [David]’s design combines the properties of a 1-dimensional flexure and a spring to give a constant downward force. Not only is this an interesting build in and of itself, but he gives a good explanation and examples of more traditional flexible constructs. He also points out this site by MIT Precision Compliant Systems Lab engineer [Marcel Thomas] which provides a wealth of information on flexures.
Let’s face it: pretty much everything about e-textiles is fiddly. If wearables were easy, more people would probably work in that space. But whereas most circuit prototyping is done in two dimensions, the prototyping of wearables requires thinking and planning in 3D. On top of that, you have to figure out how much conductive thread you need, and that stuff’s not cheap.
[alch_emist] has a method for arranging circuits in 3D space that addresses the harsh realities of trying to prototype wearables. There’s that whole gravity thing to deal with, and then of course there are no straight lines anywhere on the human body. So here’s how it works: [alch_emist] made a bunch of reusable tie points designed to work with an adhesive substrate such as felt. They laser-cut a set of acrylic squares and drilled a hole in each one to accommodate a neodymium magnet. On the back of each square is a small piece of the hook side of hook-and-loop tape, which makes the tie points stay put on the felt, but rearrange easily.
We love the idea of prototyping with felt because it’s such a cheap and versatile fabric, and because you can easily wrap it around your arm or leg and see how the circuit will move when you do.
If you’re looking for a reminder of how powerful the tiny microcontrollers that run our everyday gadgets have become, check out the work impressive work [Audun Wilhelmsen] has done to get DOOM running on the Nordic Semiconductor nRF5340. This is the sort of Bluetooth SoC you’d expect to find in a headset or wireless keyboard, and yet it’s packing a 128 MHz processor that can go head to head with the Intel 486 that the iconic first person shooter recommended you have in your old beige box PC.
That said, porting the open source shooter over to the nRF5340 wasn’t exactly easy. The challenge was getting the game, which recommended your PC have 8 MB back in 1993, to run on a microcontroller with a paltry 512 KB of memory. Luckily, a lot of the data the game loads into RAM is static. While that might have been necessary when the game was running from a pokey IDE hard drive, the nearly instantaneous access times of solid state storage and the nRF5340’s execute in place (XIP) capability meant [Audun] could move all of that over to an SPI-connected 8 MB flash chip with some tweaks to the code.
nRF53 Development board with I2S DAC
In general, [Audun] explains that many of the design decisions made for the original DOOM engine were made with the assumption that the limiting factor would be CPU power rather than RAM. So that lead to things often getting pre-calculated and stored in memory for instant access. But with the extra horsepower of the nRF5340, it was often helpful to flip this dynamic over and reverse the optimizations made by the original developers.
On the hardware side, things are relatively straightforward. The 4.3″ 800×480 LCD display is connected over SPI, and an I2S DAC handles the sound. Bluetooth would have been the logical choice for the controls, but to keep things simple, [Audun] ended up using a BBC micro:bit that could communicate with the nRF5340 via Nordic’s own proprietary protocol. Though he does note that Bluetooth mouse and keyboard support is something he’d like to implement eventually.
If some of the software tricks employed by this hack sounded familiar, it’s because a very similar technique was used to get DOOM running on an IKEA TRÅDFRI light bulb a week or so back. Unfortunately it must have ruffled some feathers, as it was pulled from the Internet in short order. It sounds like [Audun] got the OK from his bosses at Nordic Semiconductor to go public with this project, so hopefully this one will stick around for awhile.
