MULTICS Gets A New Release… 52 Years After Launch

August 7, 2021 by Jenny List 27 Comments

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

August 5, 2021 by Mike Szczys 43 Comments

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

July 31, 2021 by Jenny List 10 Comments

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

July 30, 2021 by Matthew Carlson 21 Comments

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].

It Takes A Lot To Build A Hacker’s Laptop

July 28, 2021 by Jenny List 80 Comments

An essential tool that nearly all of us will have is our laptop. For hardware and software people alike it’s our workplace, entertainment device, window on the world, and so much more. The relationship between hacker and laptop is one that lasts through thick and thin, so choosing a new one is an important task. Will it be a dependable second-hand ThinkPad, the latest object of desire from Apple, or whatever cast-off could be scrounged and given a GNU/Linux distro? On paper all laptops deliver substantially the same mix of performance and portability, but in reality there are so many variables that separate a star from a complete dog. Into this mix comes a newcomer that we’ve had an eye on for a while, the Framework. It’s a laptop that looks just like so many others on the market and comes with all the specs at a price you’d expect from any decent laptop, but it has a few tricks up its sleeve that make it worth a glance.

These USB-C based modules are a neat idea.

Probably the most obvious among them is that as well as the off-the-shelf models, it can be bought as a customised kit for self-assembly. Bring your own networking, memory, or storage, and configure your new laptop in a much more personal way than the norm from the big manufacturers. We like that all the parts are QR coded with a URL that delivers full information on them, but we’re surprised that for a laptop with this as its USP there’s no preinstalled open source OS as an option. Few readers will find installing a GNU/Linux distro a problem, but it’s an obvious hole in the line-up.

On the rear is the laptop’s other party trick, a system of expansion cards that are dockable modules with a USB-C interface. So far they provide USB, display, and storage interfaces with more to come including an Arduino module, and we like this idea a lot.

It’s all very well to exclaim at a few features and party tricks, but the qualities that define a hacker’s laptop are only earned through use. Does it have a keyboard that will last forever, can it survive being dropped, and will its electronics prove to be fragile, are all questions that can be answered only by word-of-mouth from users. It’s easy for a manufacturer to get those wrong — the temperamental and fragile Dell this is being typed on is a case in point — but if they survive the trials presented by their early adopters and match up to the competition they could be on to a winner.

What Kind Of GPU Are You?

July 22, 2021 by Al Williams 9 Comments

In the old days, big computers often had some form of external array processor. The idea is you could load a bunch of numbers into the processor and then do some math operations on all of the numbers in parallel. These days, you are more likely to turn to your graphics card for number crunching support. You’ll usually use some library to help you do that, but things are always better when you understand what’s going on under the hood. That’s why we enjoyed [RasterGrid’s] post on GPU architecture types.

If you can tell the difference between IMR (immediate mode) and TBR (tile-based) rendering this might not be the post for you. But while we knew the terms, we found a lot of interesting detail including some graphics and pseudo code that clarified the key differences.

Continue reading “What Kind Of GPU Are You?” →

Raspberry Pi Server Cluster In 1U Rack-Mount Case

July 21, 2021 by Chris Lott 30 Comments

[Paul Brown] wants to take advantage of off-site server colocation services. But the providers within [Paul]’s region typically place a limit of 1A @ 120V on each server. Rather than search out commercial low-power solutions, [Paul] embraced the hacker spirit and built his own server from five Raspberry Pi 4b single board computers.

The task involves a little bit more than just mounting five Pi4s in a chassis and calling it done. There is an Ethernet switch connecting all the modules to the network, and each Pi has a comparatively bulky SSD drive + enclosure attached. By far the most annoying part of the assembly is the power supply and distribution cabling, which is further complicated by remote controlled power switching relays (one of the computers is dedicated to power management and can shut the other four modules on and off).

Even if you’re not planning on building your own server, check out the thoroughly documented assembly process and parts list — we particularly liked the USB connector to screw terminal breakout connector that he’s using for power distribution. For all the detailed information, assembly instructions and photos, we think a top-level block diagram / interconnection drawing would be very helpful for anyone trying to understand or replicate this project.

There are a lot of connections in this box, and the final result has a messy look-and-feel. But in fairness to [Paul]’s craftsmanship, there aren’t many other ways to hook everything together given the Raspberry Pi form-factor. Maybe a large and costly PCB or using CM4 modules instead of Raspberry Pi boards could help with cable management? In the end, [Paul] reckons he shelled out about $800 for this unit. He compares this expense with some commercial options in his writeup, which shows there are some cheaper and more powerful solutions. But while it may be cheaper to buy, we understand that strong urge to roll your own.

We’ve written about many Pi cluster projects in the past, including this one which contains a whopping 750 Raspberry Pis. Have you ever used a colocation service, and if so, did you use a DIY or an off-the-shelf server?