Intel’s Chips Light The Way To Faster Processor Arrays

It’s very likely indeed that whatever you are reading this on will have a multi-core processor. They’re now the norm, but the path to they octa-or-more-core chip in your phone has gone from individual processors with PCB interconnects through many generations of ever faster on-chip ones.

But what if your power needs are so high-end that you need more cores that can be fitted on one chip, but without the slow PCB interconnect to another? If you’re Intel, you develop a multi-core processor with an on-chip photonic interconnect. It talks to the neighboring ones in its cluster at full speed, via light.

The chip in question isn’t one you’ll see in a machine near you, instead it’s inspired by the extremely demanding requirements for DARPA’s HIVE graph analytics program. So this is a machine for supercomputers in huge data centers rather than desktop computers, it will be assembled into multi-die packages with that chip-to-chip optical networking built in. But your computer today is the equal of a supercomputer from not that many years ago, so never say you won’t one day be using its descendant technologies.

Jenny’s Daily Drivers: Raspberry Pi Desktop

One of the more exciting prospects upon receiving one of the earliest Raspberry Pi boards back in 2012 was that it was a fully-functional desktop computer in the palm of your hand. In those far-off days, the Debian OS distro for the board wasn’t even yet called Raspbian, but it would run a full-on desktop on your TV and you could use it after a fashion to browse the web or do wordprocessing. It wasn’t in any way fast, but it was usable enough to be more than a novelty. I’ve said before on these pages that the Raspberry Pi folks’ key product is their OS rather than their computers. While they rarely have the fastest or highest spec hardware, you can depend on Raspberry Pi OS being updated and supported through the life of the board unlike many of their competitors. I can download their latest OS image and still run it on that 2012 board, which to me ranks as a very laudable achievement.

The OS They Don’t Really Tell You About

Screenshot of the first i386 Pi desktop
The background image may have changed since the first release back in 2016, but the UI hasn’t.

Raspberry Pi OS doesn’t run on any other ARM single board computers but their own, but it’s not quite accurate to say that it only runs on Raspberry Pi hardware. Since 2016 when it was launched as PIXEL, the folks in Cambridge have also maintained a PC version for 32-bit i386 computers, now called Raspberry Pi Desktop. It may be the Pi product they don’t talk about much, but  you can still find it on their downloads page.

Like the ARM version, it’s based on Debian and presents as close as possible to the environment you’d find on your Pi. I’m interested to see whether it still lives up to the claim of being usable on older hardware, so I’ve downloaded a copy and installed it on my trusty 2007 Dell Inspiron 640. It rocks a 1.6 GHz Core Duo with 4 GB of memory and a SATA SSD so it’s not the lowest spec hardware on the block, but by 2023’s standard it represents a giveaway-spec old laptop. Can I use it as a daily driver? Let’s find out! Continue reading “Jenny’s Daily Drivers: Raspberry Pi Desktop”

Only 8 Chips Make A CPU

We’re no stranger to homemade CPUs on these pages, but we think that [Jiri Stepanovsky]’s 16-bit serial CPU might be a little special. Why? It has an astonishingly low chip count, with only 8 ICs in total. How on earth does he do it?

While a traditional TTL CPU has a relatively high chip count due to a parallel data bus, registers, and discrete ALU, this one takes a few shortcuts by opting for a one-bit serial bus with serial memory chips and an EPROM serving as a look-up-table ALU. Perhaps the most interesting result of this architecture is that it also allows the CPU to dispense with registers, like the Texas Instruments 16-bit chips back in the day. They all live in memory. You can see it below the break in action, streaming a video to a Nokia-style LCD.

Such a CPU would indeed have been unlikely to have been made back in the day due to the prohibitive cost of buying and programming such a large EPROM. However, old computers like the EDSAC also used a serial data path and mercury delay line memory to manage complexity. But for a solid-state CPU in 2023, we think the design is innovative. We think it would be challenging to reduce the chip count further — and no, we’re not counting designs that use a microcontroller to replicate a block of circuitry; that’s cheating — but we’re sure that somewhere there’s a designer with ideas for slimming the design further.

Continue reading “Only 8 Chips Make A CPU”

Thin Client Wysens Up To Become OpenWrt Router

For some of us, unused hardware lying around just calls to be used. It seems like [Miles Goodhew] heard the call, and wanted to put a Dell Wyse 3040 thin client to use — in this case as a wireless router. It seems simple enough. OpenWrt supports x64_64 targets, and the thin client has 2G of ram and 8G of flash. It should make for a very capable router.

And before you tell us that it’s just another computer, and that installing OpenWrt on a miniature x86 machine isn’t a hack, note that there were some speedbumps along the way. First off, the motherboard has integrated storage, with the not-very-useful ThinLinux installed, and the system BIOS locked down to prevent reinstall. There is a BIOS clear button on the system’s diminutive motherboard. With the BIOS lock out of the way, a real Linux system can be installed on the small 8 GB mmcblk device.

The next issue the the CPU. It’s an Intel Atom x5 z-series. OpenWrt won’t actually boot on that oddball, not-quite- processor, so [Miles] opted to install Fedora and test via virtualization instead. If that statement makes you do a double-take, you’re not alone. The initial explanation sounded like the mobile-centric processor was missing instructions to make OpenWrt run, but virtualization doesn’t add any instructions for a guest to use. It turns out, the problem is a missing serial port that OpenWrt uses as a debugging output by default.

After a custom OpenWrt compile, the device comes up just as you’d expect, and while it would be underpowered as a desktop, OpenWrt runs happily shuffling bits from Ethernet to wireless adapter at respectable speeds. As [Miles] points out, there’s nothing ground-breaking here, but it’s nice to have the details on re-using these machines compiled in one place. And if you too love the idea of putting OpenWrt in places where nobody intended, we’ve got you covered.

Jenny’s Daily Drivers: FreeBSD 13.2

Last month I started a series in which I try out different operating systems with the aim of using them for my everyday work, and my pick was Slackware 15, the latest version of the first Linux distro I tried back in the mid 1990s. I’ll be back with more Linux-based operating systems in due course, but the whole point of this series is to roam as far and wide as possible and try every reasonable OS I can. Thus today I’m making the obvious first sideways step and trying a BSD-based operating system. These are uncharted waters for me and there was a substantial choice to be made as to which one, so after reading around the subject I settled on FreeBSD as it seemed the most accessible.

First, A Bit Of Context

A PC with the FreeBSD boot screen
Success! My first sight of a working FreeBSD installation.

Most readers will be aware that the BSD operating systems trace their heritage in a direct line back to the original AT&T UNIX, while GNU/Linux is a pretty good UNIX clone originating with Linus Torvalds in the early 1990s and Richard Stallman’s GNU project from the 1980s onwards. This means that for Linux users there’s a difference in language to get used to.

Where Linux is a kernel around which distributions are built with different implementations of the userland components, the various BSD operating systems are different operating systems in their own right. Thus we talk about for example Slackware and Debian as different Linux distributions, but by contrast NetBSD and FreeBSD are different operating systems even if they have a shared history. There are BSD distributions such as GhostBSD which use FreeBSD as its core, but it’s a far less common word in this context. So I snagged the FreeBSD 13.2 USB stick file from the torrent, and wrote it to a USB Flash drive. Out with the Hackaday test PC, and on with the show. Continue reading “Jenny’s Daily Drivers: FreeBSD 13.2”

Understanding And Using Unicode

Computer engineer [Marco Cilloni] realized a lot of developers today still have trouble dealing with Unicode in their programs, especially in the C/C++ world. He wrote an excellent guide that summarizes many of the issues surrounding Unicode and its encoding called “Unicode is harder than you think“. He first presents a brief history of Unicode and how it came about, so you can understand the reasons for the frustrating edge cases you’re bound to encounter.

There have been a variety of Unicode encoding methods over the years, but modern programs dealing with strings will probably be using UTF-8 encoding — and you should too. This multibyte encoding scheme has the convenient property of not changing the original character values when dealing with 7-bit ASCII text. We were surprised to read that there is actually an EBCDIC version of UTF still officially on the books today:

UTF-EBCDIC, a variable-width encoding that uses 1-byte characters designed for IBM’s EBCDIC systems (note: I think it’s safe to argue that using EBCDIC in 2023 edges very close to being a felony)

Continue reading “Understanding And Using Unicode”

Running A Modern Graphics Card In A 33 MHz PCI Slot

If you ever looked at a PCI to PCIe x16 adapter and wondered what’d happen if you were to stick a modern PCIe GPU in it, the answer apparently is ‘it works’ according to an attempt by [Circuit Rewind]. As long as you accept needing to supply external power with even a low-end GT 1030 card – as the PCI slot cannot provide enough power – and being limited to a single PCIe lane. This latter point isn’t so much of an issue as a single PCIe lane offers more bandwidth than the (shared) PCI bus anyway.

Despite the somewhat improvised setup, the GT 1030 card provided a decent 1080p experience in a range of games, after removing half of the 8 GB of system RAM before the configuration would work, probably due to VRAM mapping issues. Since the mainboard used also offered PCIe, the same card was run in a PCIe x4 slot, as well as in an x1 configuration, both with noticeably higher performance and putting the ‘why’ in ‘try’.

Perhaps unsurprisingly, a RTX 3080 also booted fine with external power and only 4 GB system RAM installed. Despite the PCIe x1 link, the system was able to finish a 3D benchmark and play Doom 2016, but with only 4 GB of system RAM and an old Athlon quad-core CPU, it was a terrible experience. Perhaps the most fascinating lesson to learn from this is that PCI and PCIe are amazingly compatible with only a simple translation bridge, even if high-performance graphics aren’t quite what PCI was meant for. After all, that’s why we got cursed with AGP for many years.

Continue reading “Running A Modern Graphics Card In A 33 MHz PCI Slot”