Binary Clock Kit Blips Again

December 10, 2023 by 16 Comments

Back in 1978, the world was a bit different. There was no Raspberry Pi, no Internet, and not even an ESP32 to build projects with. And rather than order electronics kits from Tindie or Adafruit, [Dr. Francitosh] selected this binary clock with his mother from a catalog, and made the order via mail. Simpler times. The good Doctor, AKA [Greg Smith], was a young electronics tinkerer, and his mother wanted a good project-in-a-box to show off his skills. Thus, a Greymark Binary Clock was ordered and assembled. Then, sadly, the beloved clock crashed from its proud mantle position, doomed to never to blink or blip again. Or was it?
Continue reading “Binary Clock Kit Blips Again” →

Nyan Keys: Because Your Keyboard Is Painfully Slow

December 10, 2023 by 33 Comments

You probably don’t notice keyboard latency when typing or doing mundane tasks, but if you start gaming, that’s also when you might start complaining. Every millisecond counts in that arena. Think your keyboard is fast? Think again. Because unfortunately, no matter what you’ve got in there, that key matrix is slowing you down. What you need is an FPGA-based keyboard with an overkill MCU. You need Nyan Keys.

[Portland.HODL] set out to make the lowest-latency mechanical keyboard possible that would accept any Cherry-compatible switches, and boy howdy, is this thing fast.

Coupled with the STM32F723VET6 MCU is USB 2.0 HS, which has an 8000Hz polling rate. At worst, key latency measures 30μS, which blows the 1mS average out of the water.

Because it uses a Lattice Semi iCE40HX 4k FPGA, each key switch can connect to its own I/O pin, which also eliminates the need for diodes.

It also means that each key switch can have its own “core” — an 8-bit timer that is always counting up to 255. The key can only change its state when the timer reads 255. This acts as a rather clever debounce mechanism.

If all that’s not enough, [Portland.HODL] built an operating system called NyanOS written in C to avoid any performance-reducing overhead. Oh, and it has an opt-in Bitcoin miner.

We’ve seen a lot of keyboards, the fast ones are fast because of the input side — they are chording keyboards that take combinations to type, rather than using one key (or so) per character. The Characorder is so fast that it was banned from competition.

Printing With Glass Fiber Filament

December 10, 2023 by 12 Comments

[ModBot] has been trying different engineering plastics for 3D printing. He recently looked at carbon fiber mixed with PET, but this time, he shows us his results with PET with glass fiber, or PET-GF. You can see how it all turned out in the video below.

The first part of the video compares the specifications, and, as you might expect, some factors are better for carbon fiber, and others are better for glass fibers. Once he gets to the printing, he covers the high temperatures needed (280-320C). He also talks about how either fiber will chew up nozzles and extruders.

Continue reading “Printing With Glass Fiber Filament” →

Clockhands For Faster CPU Execution

December 9, 2023 by 15 Comments

When you design your first homebrew CPU, you probably are happy if it works and you don’t worry as much about performance. But, eventually, you’ll start trying to think about how to make things run faster. For a single CPU, the standard strategy is to execute multiple instructions at the same time. This is feasible because you can do different parts of the instructions at the same time. But like most solutions, this one comes with a new set of problems. Japanese researchers are proposing a novel way to work around some of those problems in a recent paper about a technique they call Clockhands.

Suppose you have a set of instructions like this:

LOAD A, 10
LOAD B, 20
SUB A,B
LOAD B, 30
JMPZ  DONE
INC B

If you do these one at a time, you have no problem. But if you try to execute them all together, there are a variety of problems. First, the subtract has to wait for A and B to have the proper values in them. Also, the INC B may or may not execute, and unless we know the values of A and B ahead of time (which, of course, we do here), we can’t tell until run time. But the biggest problem is the subtract has to use B before B contains 30, and the increment has to use it afterward. If everything is running together, it can be hard to keep straight.

Continue reading “Clockhands For Faster CPU Execution” →

Impact Of Imperfect Timekeeping On Quantum Control And Computing

December 9, 2023 by 12 Comments

In classical control theory, both open-loop and closed-loop control systems are commonly used. These systems are well understood and rather straightforward, controlling everything from washing machines to industrial equipment to the classical computing devices that make today’s society work. When trying to transfer this knowledge to the world of quantum control theory, however, many issues arise. The most pertinent ones involve closed-loop quantum control and the clocking of quantum computations. With physical limitations on the accuracy and resolution of clocks, this would set hard limits on the accuracy and speed of quantum computing.

The entire argument is covered in two letters to Physical Review Letters, by Florian Meier et al. titled Fundamental Accuracy-Resolution Trade-Off for Timekeeping Devices (Arxiv preprint), and by Jake Xuereb et al. titled Impact of Imperfect Timekeeping on Quantum Control (Arxiv preprint). The simple version is that by simply increasing the clock rate, accuracy suffers, with dephasing and other issues becoming more frequent.

Solving the riddle of closed-loop quantum control theory is a hard one, as noted by Daoyi Dong and Ian R Peterson in 2011. In their paper titled Quantum control theory and applications: A survey, the most fundamental problem with such a closed-loop quantum control system lies with aspects such as the uncertainty principle, which limits the accuracy with which properties of the system can be known.

In this regard, an accurately clocked open-loop system could work better, except that here we run into other fundamental issues. Even though this shouldn’t phase us, as with time solutions may be found to the timekeeping and other issues, it’s nonetheless part of the uncertainties that keep causing waves in quantum physics.

Top image: Impact of timekeeping error on quantum gate fidelity & independent clock dephasing (Xuereb et al., 2023)

Nanobots Self Replicate

December 9, 2023 by 11 Comments

Hey, what if you could have a factory that makes robots that is run by… robots? This is hardly an original thought, but we are a long way from having an assembly line of C3POs self-replicating. On the other hand, animals — including humans — self-replicate all the time using DNA. Now, scientists are making tiny nanorobots from DNA that can assemble more DNA, including copies of themselves.

Assembling 3D structures with DNA has deep implications. For example, it might be possible to build drugs in situ, delivering powerful toxins only to cancer cells. Another example would be putting DNA factories in diabetes patients to manufacture the insulin they can’t.

Continue reading “Nanobots Self Replicate” →

How The First IPod Was Blown Wide Open

December 9, 2023 by 21 Comments

If someone makes a device, someone else will want to break it open and run their own software on it. When the original manufacturer is Apple this is never made easy, and as [Daniel Stenberg] reminds us in the case of one of the earlier iPod models it required an unusual approach.

In short, an HTML file was found which triggered a reboot, meaning a buffer overrun had been found in the firmware. After much experimenting, the memory location was found which would flash the backlight, and from there a piece of ARM code could be injected which would dump the firmware very slowly bitwise by flashing the light. Enough code could be extracted to find the address of the USB serial port, allowing new code to be made which dumped the firmware via USB. We remember the earliest models using FireWire instead of USB, so perhaps we can zero in on the 3rd or 4th generation. From there enough could be deduced to run the Rockbox music player firmware. We remember seeing friends doing this back in the day, something which was for a while the height of open-source coolness.

Fast forward twenty years or so, and we’re still covering people chipping away at Apple’s defenses. We don’t know whether a first-generation iPod could run Doom, but we know Rockbox was capable of it on other players.