Ask Hackaday: What’s The Best Way To Heat A Tent With A Laptop?

For Europeans, August is usually a month of blistering heatwaves, day after day of cloudless skies and burning sun that ripens fruit and turns we locals a variety of shades of pink. Hacker camps during this month are lazy days of cool projects and hot nights of lasers, Club-Mate, and techno music, with tents being warm enough under the night sky to dispense with a sleeping bag altogether.

Sometimes though, the whims of the global weather patterns smile less upon us hackers, and our balmy summer break becomes a little more frigid. At BornHack 2021 for example we packed for a heatwave and were met with a Denmark under the grip of the Northern air mass. How’s a hacker to keep warm?

Continue reading “Ask Hackaday: What’s The Best Way To Heat A Tent With A Laptop?”

School Surplus Laptop BIOS Hacked To Remove Hardware Restrictions

Why did [Hales] end up hacking the BIOS on a 10 year old laptop left over from an Australian education program? When your BIOS starts telling you you’re not allowed to use a particular type of hardware, you don’t have much of a choice.

Originally [Hales] planned on purchasing a used Lenovo X260 to replace his dying laptop, but his plans were wrecked. A pandemic-induced surge in demand that even the used laptop market caused prices to bloat. The need for a small and affordable laptop with a built in Ethernet port led to the purchase of a Lenovo Thinkpad x131e. Although the laptop was older than he liked, [Hales] was determined to make it work. Little did he know the right-to-repair journey he was about to embark on.

Problems first arose when the Broadcom WiFi adapter stopped working reliably. He replaced it, but the coaxial antenna cable was found to be damaged. Even after replacing the damaged cabling, the WiFi adapter was still operating very poorly. Recalling past problems with fickle Broadcom WiFi adapters, it was decided that an Intel mPCIe WiFi adapter would take its place. When power was re-applied, [Hales] was shocked to find the following message:

Unauthorized network card is plugged in – Power off and remove the miniPCI network card

And this is where things got interesting. With off the shelf SOIC8 clips and a CH340 programmer, [Hales] dumped the BIOS from the laptop’s flash chip to another computer and started hacking away. After countless hours of researching, prodding, hacking, and reverse engineering, the laptop was useful once again with the new Intel WiFi adapter. His site documents in great detail how he was able to reverse engineer the BIOS over the course of several days.

But that’s not all! [Hales] was also able to modify the hardware so that his slightly more modern mPCIe WiFi adapter would come back on after the computer had been put in Hibernation. It’s an elegant hack, and be sure to check [Hales’] site to get the full details. And at the end, there’s a nice Easter egg for anybody who’s ever wanted to make their laptop boot up with their own logo.

We applaud [Hales] for his fine efforts to keep working equipment out of the landfill. We’ve covered many hacks that had similar goals in the past. Do you have a hack you’d like to share? Submit it via the Tips Line.

Take Note: An E-Paper Tablet From Pine64

Over the years we’ve seen a variety of interesting pieces of hardware emerging from the folks at Pine64, so it’s always worth a second look when they announce a new product. This time it’s the PineNote, a tablet that packs the same Rockchip RK3566 as used in the company’s Quartz64 single board computers behind a 10.1″ 1404 x 1872 16-tone greyscale e-paper screen.

Fitted with 4 GB of LPDDR4 RAM and 128 GB eMMC flash storage, it will feature the same Linux support as previous Pine64 products, with the slight snag of the display driver not yet being complete for 5.xx kernels. They are thus at pains to point out that this is not a ready-to-go consumer device and that early adopters will be expected to write code rather than notes on it.

That last sentence sums up Pine64’s offering perfectly, they produce interesting hardware with open-source support, but sometimes the path from hardware release to stable and usable product can be a rocky one. If you’re interested in hardcore hacking of an e-paper tablet, then you may want to be an early adopter. Otherwise, hang back for a while and buy one once some of the bugs have been ironed out. Meanwhile you can see the whole update in the video below; it has a few other things including a nifty keyboard for the PinePhone.

We’ve mentioned Pine64 a few times over the years, it’s worth noting that their products also lie outside the realm of Linux boxen.

Continue reading “Take Note: An E-Paper Tablet From Pine64”

MULTICS Gets A New Release… 52 Years After Launch

If you have ever read anything about the history of UNIX, you may remember that its early development was influenced by an older operating system. MULTICS was developed in the 1960s by MIT and General Electric as a commercial operating system, and had been the system which UNIX writers [Thompson] and [Ritchie] had used. It became a Honeywell product, and the source code for its final commercial version was eventually released to the public. Has it become a dusty relic of interest only to historians? Seemingly not, because a new version has been released. It’s intended for us on the dps8m Honeywell mainframe simulator rather than physical hardware, so perhaps while it’s not such a dusty relic it remains something only for the enthusiast.

We won’t pretend to be experts on the architectures of 1960s mainframe operating systems, but it’s interesting to read for a moment about what it was in MULTICS that caused UNIX to be written. For something described by [Ken Thompson] as “Close to unusable”, with a fresh release in its 52nd year it isn’t doing badly.

We’ve traced the UNIX story in the past, without realising that MULTICS never entirely went away. Shame on us for the omission!

[Via Hacker News]

Raspberry Pi Pico Used As A Transputer

You can’t fake that feeling when a $4 microcontroller dev board can stand in as cutting-edge 1980s technology. Such is the case with the working transputer that [Amen] has built using a Raspberry Pi Pico.

For a thorough overview of the transputer you should check out [Jenny List’s] longer article on the topic but boiled down we’re talking about a chip architecture mostly forgotten in time. Targetting parallel computing, each transputer chip has four serial communication links for connecting to other transputers. [Amen] has wanted to play with the architecture since its inception. It was expensive back then and today, finding multiple transputers is both difficult and costly. However, the RP2040 chip found on the Raspberry Pi Pico struck him as the perfect way to emulate the transputer design.

The RP2040 chip on the Pico board has two programmable input/output blocks (PIOs), each with four state machines in them. That matches up perfectly with the four transputer links (each is bi-directional so you need eight state machines). Furthermore, the link speed is spec’d at 10 MHz which is well within the Pico’s capabilities, and since the RP2040 runs at 133 MHz, it’s conceivable that an emulated core can get close to the 20 MHz top speed of the original transputers.

Bringing up the hardware has been a success. To see what’s actually going on, [Amen] sourced some link adapter chips (IMSC011), interfacing them through an Arduino Mega to a computer to use the keyboard and display. The transputer architecture allows code to be loaded via a ROM, or through the links. The latter is what’s running now. Future plans are to figure out a better system to compile code, as right now the only way is by running the original INMOS compiler on DOS in a VM.

Listen to [Amen] explain the project in the first of a (so far) six video series. You can find the links to the rest of those videos on his YouTube channel.

Continue reading “Raspberry Pi Pico Used As A Transputer”

An Epic Tale Of Reset Line Detective Work

The Pine64 folks have given us so many tasty pieces of hardware over the last few years, but it’s fair to say that their products are for experimenters rather than consumers and can thus be a little rough around the edges at times. Their Clusterboard for example is a Mini-ITX PCB which takes up to seven of their SOPINE A64 compute modules, and networks them for use as a cluster by means of an onboard Gigabit Ethernet switch. It’s a veritable powerhouse, but it has an annoying bug in that it appears reluctant to restart when told. [Eric Draken] embarked upon a quest to fix this problem, and while he got there in the end his progress makes for a long and engrossing read.

We journey through the guts of the board and along the way discover a lot about how reset signals are generated. The eventual culprit is a back-EMF generated through the reset distribution logic itself causing the low-pulled line to never quite descend into logic 0 territory once it has been pulled high, and the solution an extremely simple application of a diode. For anyone who wishes to learn about logic level detective work it’s well worth a look. Meanwhile the board itself with its 28 ARM cores appears to have plenty of potential. It’s even a board we’ve mentioned before, in a personal supercomputer project.

Streaming Video From A Mouse

The first optical mice had to be used on a specially printed mousepad with a printed grid that the four-quadrant infrared sensor could detect. Later, mice swapped the infrared sensor for an optoelectric module (essentially a tiny, very low-resolution camera) and a powerful image processing. [8051enthusiast] was lying in bed one day when they decided to crack the firmware in their gaming mouse and eventually start streaming frames from the camera inside.

Step one was to analyze the protocol between the mouse and the host machine. Booting up a Windows VM and Wireshark allowed him to capture all the control transfers to the USB controller. Since it was a “programmable” gaming mouse that allowed a user to set macros, [8051enthusiast] could use the control transfers that would normally query that macro that had been set to return the memory at an arbitrary location. A little bit of tinkering later, and he now had a dump of the firmware. Looking at the most abundant bytes, it seems to match a profile similar to the Intel 8051. In a fascinating blur of reverse engineering, he traced the main structure of the program back from the function that sets the LED colors for the scroll wheel (which is dependent on the current DPI setting). Unfortunately, the firmware prevented the same macro mechanism from writing to arbitrary locations.

Looking through the code, a good old buffer overflow exploit seemed possible, but it caused the system to reset via watchdog. So he took another approach, invoking recovery mode and loading an entirely new firmware on the device, which a set_report control transfer can invoke.

Next, he moved onto the ADNS-9800 optical sensor (pictured in the top image provided by JACK Enterprises), which had a large encrypted blob in the firmware. Some poking around and deduction lead to a guess that the optical sensor was another 8051 system. With some clever reasoning and sheer determination, [8051enthusiast] was able to crack the XOR stream cipher encryption with a program that showed him versions of the disassembled assembly and allowed him to pick the one that was the most likely. With the firmware decrypted, he was able to see the encryption code and confirm his deducted algorithm.

With the sensor now cracked open, it was onto the 30 x 30 240 fps video stream. The sensor communicates over SPI, and the USB controller has to bit-bang the connection as it doesn’t have the hardware. Putting two custom firmware images on with a few extra functions was easy enough, but the 7 fps was somewhat lacking. The first optimization was loop unrolling and removing some sleeps in the firmware, which bought it up to 34 fps. By measuring the cycle counts of individual instructions, he was able to find some alternatives such as a mov instead of a setb that took one less cycle. Going from a 17 cycle loop to an 11 cycle loop and some other optimizations gave him 54 fps. Not content to stop there, he modified the ADNS-9800 firmware to continuously sample rather than waiting for the USB controller to finish processing. While this yielded 100 fps, there was still more to do: image compression. At a whopping 230 fps, [8051enthusiast] decided to call it done.

However, there was one last thing he wanted to do: control the mouse with the video stream. Writing some image processing into his Python-based program that received the image files allowed him to use the mouse, however impractically.

All in all, it’s an incredible journey by [8051enthusiast], and we would highly recommend reading the whole journey yourself. This isn’t the first time he’s modified the firmware of 8051-based devices, such as modifying the firmware of the WiFi chipset in his laptop.

[Thanks to JACK Enterprises over at Tindie for the use of the image of an ADNS9000].