Smallest USB Device… So Far

For better or worse it seems to be human nature to compete with one another, as individuals or teams, rather than experience contentedness while moving to the woods and admiring nature Thoreau-style. On the plus side, competition often results in benefits for all of us, driving down costs for everything from agriculture to medical care to technology. Although perhaps a niche area of competition, the realm of “smallest USB device” seems to have a new champion: this PCB built by [Emma] that’s barely larger than the USB connector pads themselves.

With one side hosting the pads to make contact with a standard USB type-A connector, the other side’s real estate is taken up by a tiny STM32 microcontroller, four phototransistors that can arm or disarm the microcontroller, and a tiny voltage regulator that drops the 5V provided by the USB port to the 3.3V the STM32 needs to operate. This is an impressive amount of computing power for less than three millimeters of vertical space, and can operate as a HID device with a wide variety of possible use cases.

Perhaps the most obvious thing to do with a device like this would be to build a more stealthy version of this handy tool to manage micromanagers, but there are certainly other tasks that a tiny HID can be put to use towards. And, as far as the smallest USB device competition goes, we’d also note that USB-A is not the smallest connector available and, therefore, the competition still has some potential if someone can figure out how to do something similar with an even smaller USB connector.

Thanks to [JohnU] for the tip!

You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t

DOOM used to primarily run on x86 PCs. It later got ported to a bunch of consoles with middling success, and then everything under the sun, from random embedded systems to PDFs. Now, thanks to [Wojciech Graj], you can even play it in Microsoft Word.

To run DOOM inside Microsoft Word, you must enable VBA macros, and ignore security warnings, to boot. You’ll need a modern version of Word, and it will only work on Windows on an x64 CPU. As you might imagine, too, the *.DOCM file is not exactly lightweight. It comes in at 6.6 MB, no surprise given it contains an entire FPS. It carries inside it a library called doomgeneric_docm.dll and the whole doom1.wad data file. Once the file is opened, a macro then extracts all the game data and executes it.

If you think that Microsoft Word doesn’t really have a way of displaying live game graphics, you’d be correct. Instead, that DLL is creating a bitmap image of the game state for every frame, which is then displayed inside Word itself. It uses the GetAsyncKeyState function to grab inputs from the arrow keys, number keys, and CTRL and space so the player can move around. It certainly sounds convoluted, but it actually runs pretty smoothly given all the fuss.

While this obviously works, you shouldn’t get in the habit of executing random code in your word processor. It’s just not proper, you see, like elbows on the dinner table! And, you know. It’s insecure. So don’t do that.

Continue reading “You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t”

Porting Dragon’s Lair To The Game Boy Color Was A Technical Triumph

If you remember the 80s arcade game Dragon’s Lair, you probably also remember it was strikingly unlike anything else at the time. It didn’t look or play like anything else. So it might come as a surprise that it was ported to Nintendo’s Game Boy Color, and that took some doing!

Dragon’s Lair used LaserDisc technology, and gameplay was a series of what we’d today call quick-time events (QTE). The player essentially navigated a series of brief video clips strung together by QTEs. Generally, if the player chose correctly the narrative would progress. If they chose poorly, well, that’s what extra lives (and a stack of quarters) were for.

More after the break!

Continue reading “Porting Dragon’s Lair To The Game Boy Color Was A Technical Triumph”

Quake In 276 KB Of RAM

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

Getting PCIe Working On The New Pi 5

After the Pi 4 released, a discovery was quickly made that the internals of the popular single-board computer use PCIe to communicate with each other. This wasn’t an accessible PCIe bus normally available in things like desktop computers for expansion cards, though; this seemed to be done entirely internally. But a few attempts were made to break out the PCIe capabilities and connect peripherals to it anyway, with varying levels of success. The new Pi 5 seems to have taken that idea to its logical conclusion and included a PCIe connector, and [George] is showing us a way to interface with this bus.

The bus requires the port to be enabled, but once that’s done it’s ready to be used. First, though, some support circuitry needs to be worked out which is why [George] is reverse engineering the system to see what’s going on under the hood. There are a few handshakes that happen before it will work with any peripherals, but with that out of the way a PCIe card can be connected. [George] removed the connector to solder wires to the board directly in order to connect a proper PCIe port allowing a variety of cards to be connected, in this case a wireless networking card and an old Firewire card. This specific build only allows Gen 1 speeds, but the bus itself supports faster connections in theory with better wiring and support circuitry.

While it might not be the prettiest solution, as [George] admits, it does a great job of showing the inner workings of this communication protocol and its use in the new, more powerful Raspberry Pi 5. This makes a lot of things more accessible, such as high-speed PCIe HATs allowing for a wide range of expansion for these popular single-board computers, which wouldn’t have been possible before. If you’re still stuck with a Pi 4, though, don’t despair. You can still access the PCIe bus on these older models but it’ll take a little bit more work.

Thanks to [CJay] for the tip!

Continue reading “Getting PCIe Working On The New Pi 5”

The Ease Of Wireless Charging, Without The Wait

Historically, there have been a few cases of useful wireless power transmission over great distances, like a team at MIT that was able to light up a 60 W bulb at several meters, and of course Nikola Tesla had grand dreams of drawing energy from the atmosphere. But for most of us wireless power is limited to small, short-range devices like cellphone chargers. While it’s not a lot of work to plug in a phone when it needs a charge, even this small task can be automated.

This build begins with a 3D printed cradle for the smartphone to sit in. When the device detects that the phone has been placed in the cradle, it uses a linear actuator to drive a custom-built charging cable into the phone’s USB port. Similarly, when the phone is lifted from the cradle the cable is automatically removed. It appears that there is some play in the phone’s position that lets the charger be plugged in smoothly, and the project’s creator [Larpushka] points out that the linear actuator is not particularly strong so we don’t imagine the risk of damage is very high.

While wireless charging still may have the edge when it comes to keeping debris out of the port, we still really enjoy a project like this that seems to be done for its own sake. There are some improvements that [Larpushka] plans to make, but for now we’re delighted by this build. For anyone looking to add true wireless charging to any phone that doesn’t have it, though, it’s not too difficult to accomplish either.

Talking To A Texas Instruments Calculator

Texas Instruments is a world-class semiconductors company, but unfortunately what they are best known for among the general public is dated consumer-grade calculators thanks to entrenched standardized testing. These testing standards are so entrenched, in fact, that TI has not had to update the hardware in these calculators since the early 90s. They still run their code on a Z80 microcontroller, but [Ben Heck] found himself in possession of one which has a modern ARM coprocessor in it and thus can run Python.

While he’s not sure exactly what implementation of Python the calculator is running, he did tear it apart to try and figure out as much as he could about what this machine is doing. The immediately noticeable difference is the ARM coprocessor that is not present in other graphing calculators. After some investigation of test points, [Ben] found that the Z80 and ARM chips are communicating with each other over twin serial lines using a very “janky” interface. Jankiness aside, eventually [Ben] was able to wire up a port to the side of the calculator which lets him use his computer to send Python commands to the device when it is in its Python programming mode.

While there are probably limited use cases for 1980s calculators to run Python programs, we can at least commend TI for attempting to modernize within its self-built standardized testing prison. Perhaps this is the starting point for someone else to figure out something more useful to put these machines to work with beyond the classroom too. We’ve already seen some TI-84s that have been modified to connect to the Internet, for example.

Thanks to [Nikša] for the tip!

Continue reading “Talking To A Texas Instruments Calculator”