Hacking 16GB Into An Old PC That Doesn’t Want That Much

April 6, 2019 by Al Williams 23 Comments

From the title, you might think this post is going to be some lame story about someone plugging in some RAM and maybe updating a BIOS. That’s where you’d be wrong. [Downtown Doug Brown] has a much more interesting and instructive story.

[Doug] found his motherboard was rated for 8 GB maximum and decided he’d make 16 GB of RAM work despite the limitation. He updated the BIOS and it worked — in Linux. He was able to see all the memory and it tested good. If that was it, you wouldn’t be reading about it here. The story gets interesting when he tried to boot Windows 10 and it refused, showing its kinder and gentler blue screen of death. For many people, that would be the end of the story, especially since Windows 10 doesn’t give you much information about why it crashed.

Like so many problems, this one had to be peeled back like an onion. The first thing to do was to change the Windows registry to allow the blue screen to output some technical information that was present in older versions of Windows. The error code indicated that the issue had to do with the BIOS reporting overlapping memory regions.

With some investigating in Linux, whose log files get a lot more BIOS information, [Doug] realized the E820 interface was returning a memory region that conflicted with ACPI’s information. It seems as though the motherboard was reserving space at the top of the 8 GB range for PCI operations which was punching a hole in the system’s (now larger) memory. Turning off a setting in the BIOS fixed the problem, but only because it makes Linux and Windows both see only 4GB of memory. That also wouldn’t be a very interesting story. [Doug] theorized that if he could move the mapping area to the top of the 16 GB range, things would work.

What follows is a great exposition of the Linux tools for reading and changing system information. Did he get it to work? Read the post and find out. But we will tell you that he did manage to have grub patch his system information.

Most of the motherboard hacks we’ve seen relate to hardware, not software. Of course, you could just buy a new motherboard. If you need ideas for what to do with the old one, here you go.

How The Gigatron TTL Microcomputer Works

March 25, 2019 by Jenny List 26 Comments

About a year ago when Hackaday and Tindie were at Maker Faire UK in Newcastle, we were shown an interesting retrocomputer by a member of York Hackspace. The Gigatron is a fully functional home computer of the type you might have owned in the early 1980s, but its special trick is that it does not contain a microprocessor. Instead of a 6502, Z80, or other integrated CPU it only has simple TTL chips, it doesn’t even contain the 74181 ALU-in-a-chip. You might thus expect it to have a PCB the size of a football pitch studded with countless chips, but it only occupies a modest footprint with 36 TTL chips, a RAM, and a ROM. Its RISC architecture provides the explanation, and its originator [Marcel van Kervinck] was recently good enough to point us to a video explaining its operation.

It was recorded at last year’s Hacker Hotel hacker camp in the Netherlands, and is delivered by the other half of the Gigatron team [Walter Belgers]. In it he provides a fascinating rundown of how a RISC computer works, and whether or not you have any interest in the Gigatron it is still worth a watch just for that. We hear about the design philosophy and the choice of a Harvard architecture, explained the difference between CISC and RISC, and we then settle down for a piece-by-piece disassembly of how the machine works. The format of an instruction is explained, then the detail of their 10-chip ALU.

The display differs from a typical home computer of the 1980s in that it has a full-color VGA output rather than the more usual NTSC or PAL. The hardware is simple enough as a set of 2-bit resistor DACs, but the tricks to leave enough processing time to run programs while also running the display are straight from the era. The sync interval is used to drive another DAC for audio, for example.

The result is one of those what-might-have-been moments, a glimpse into a world in which RISC architectures arrived at the consumer level years earlier than [Sophie Wilson]’s first ARM design for an Acorn Archimedes. There’s no reason that a machine like this one could not have been built in the late 1970s, but as we know the industry took an entirely different turn. It remains then the machine we wish we’d had in the early 1980s, but of course that doesn’t stop any of us having one now. You can buy a Gigatron of your very own, and once you’ve soldered all those through-hole chips you can run the example games or get to grips with some of the barest bare-metal RISC programming we’ve seen. We have to admit, we’re tempted!

Continue reading “How The Gigatron TTL Microcomputer Works” →

Faster Computers Lead To Slower Experiences?

March 22, 2019 by Kerry Scharfglass 110 Comments

Ever get that funny feeling that things aren’t quite what they used to be? Not in the way that a new washing machine has more plastic parts than one 40 years its senior. More like “my laptop can churn through hundreds of gigaflops, but when I scroll it doesn’t feel great.” That perception of smoothness might be based on a couple factors, including system latency. A couple years ago [danluu] had that feeling too and measured the latency of “devices I’ve run into in the past few months” (based on this list, he lives a more interesting life than we do). It turns out his hunch was objectively correct. What he wrote was a wonderful deep dive into how and why a wide variety of devices work and the hardware and software contributors to latency.

Let’s be clear about what “latency” means in this context. [danluu] was checking the time between a user input and some response on screen. For desktop systems he measured a keystroke, for mobile devices scrolling a browser. If you’re here on Hackaday (or maybe at a Vintage Computer Festival) the cause of the apparent contradiction at the top of the charts might be obvious.

Q: Why are some older systems faster than devices built decades later? A: The older systems just didn’t do much! Instead of complex multi-tasking operating systems doing hundreds of things at once, the CPU’s entire attention was bent on whatever user process was running. There are obvious practical drawbacks here but it certainly reduces context switching!

In some sense this complexity that [danluu] describes is at the core of how we solve problems with programming. Writing code is all about abstraction. While it’s true that any program could be written directly in machine code and customized to an individual machine’s hardware configuration, it would be pretty inconvenient for both developer and user. So over time layers of sugar have been added on top to hide raw hardware behind nicer interfaces written in higher-level programming languages.

And instead of writing every program to target exact hardware configurations there is a kernel to handle the lowest layers, then layers adding hotplug systems, power management, pluggable module and driver infrastructure, and more. When considering solutions to a programming problem the approach is always recursive: you can solve the problem, or add a layer of abstraction and reframe it. Enough layers of the latter makes the former trivial. But it’s abstractions all the way down.

[danluu]’s observation is that we’re just now starting to curve back around and hit low latency again, but this time by brute force! Modern solutions to latency largely look like increasingly exotic display technologies and complex optimizations which reach from UI draw functions all the way down to the silicon, not removing software and system infrastructure. It turns out the benefits of software complexity in terms of user experience and ease of development are worth it most of the time.

For a very tangible illustration of latency as applied to touchscreen devices, check out the Microsoft Research video after the break (linked to in [danluu]’s piece).

Continue reading “Faster Computers Lead To Slower Experiences?” →

Venabili Is The Delightful Keyboard You Can’t Buy

March 19, 2019 by Al Williams 31 Comments

If you code or write a lot, you live or die with your keyboard. The Venabili web site calls Venabili “the delightful keyboard” which begs the question: what makes a keyboard delightful. The site continues:

“Venabili is a 40% mechanical, programmable, ergonomic and hackable computer keyboard.

Being a fully programmable keyboard, it gives you the ability to create layers of functionality, declare multifunction keys that can operate as both modifiers and normal keys, control the mouse, define macros, and more.”

Sounds at least 40% delightful, right? Where do you buy one? You don’t. The keyboard is a set of plans and like a Jedi lightsaber, you have to build your own. Continue reading “Venabili Is The Delightful Keyboard You Can’t Buy” →

A Lasercut ATX Case For Your Next Desktop Rig

March 17, 2019 by Lewin Day 36 Comments

Case modding exploded in the late 1990s, as computer enthusiasts the world over grew tired of the beige box and took matters into their own hands. The movement began with custom paints and finishes on existing cases, with competitions and bragging rights then taking over to further push the state of the art. It’s one thing to mod a case, however, and another to build one entirely from scratch. [Wesley]’s lasercut case build is an excellent example of the latter.

The build is designed for the ATX form factor, making it suitable for regular desktop computer parts. There are provisions for 3.5 and 2.5 inch drives, as well as a standard ATX PSU and provisions for case fans. The large lasercut panels are supplemented by some 3D printed parts, and the usual metric M3 hardware used with the ATX standard.

It’s a tidy build you can replicate yourself, with the parts available on Thingiverse for your making pleasure. [Wesley]’s build is resplendent in orange, but we’d also love to see an all-transparent build with blinding LED light effects. If you build it, you know where to send it.

Of course, if you’re looking for something more compact, you could always build the whole computer inside the power supply.

From A Dead Laptop To A Portable KVM And PiTop

March 10, 2019 by Jenny List 14 Comments

An essential tool of many sysadmins is a portable terminal ready to plug into an ailing rack-mounted server to administer first aid. At their simplest, they are simply a monitor and keyboard on a trolley, but more often they will be a laptop pre-loaded with tools for the purpose. Sysadmins will hang on tenaciously to now-ancient laptops for this application because they possess a hardware serial port.

[Frank Adams] has taken a different route with his emergency server crash cart, because while he’s used an old laptop he hasn’t hung onto it for its original hardware. Instead, he’s used a Teensy and an LVDS driver board to replace the motherboards of two old Dell Latitude laptops, one of which is a simple KVM device and the other of which is a laptop in its own right featuring a Raspberry Pi 3. He’s produced a video as well, which we’ve placed below the break.

There was a time when laptop display panels were seen as unhackable, but the advent of cheap driver boards has meant that conversions such as this one have become a relatively well-worn path. The job he’s done here is a particularly well-executed one though, making good use of the generous amount of space to be found in an older business-class laptop. There isn’t a battery because this application doesn’t demand one, however, with the battery compartment intact it does not seem impossible that a suitable charger/monitor board could be included along with a boost converter to provide his 12V supply.

This isn’t the first Pi laptop in a re-used commercial machine’s case we’ve seen, there was also this Sony Vaio.

Continue reading “From A Dead Laptop To A Portable KVM And PiTop” →

A Nurse Call System Becomes Turing Complete

March 9, 2019 by Bryan Cockfield 3 Comments

George Mallory, a famous English mountaineer, once suggested that it was of no use to climb mountains. Instead, he posited, the only reason to climb a mountain is because it is there. Likewise, when you become an expert in nurse call systems like those found in hospitals, you may find that you do things with them that are of similar use. Making a Turing-complete nurse call system is something you do because you can.

[Erik] has been working on this particular call system, known as Netrix, and used Wireshark to sniff out all of its protocols. With this information he realized that it would be possible to use the system’s routing features to perform all of the tasks that any Turing complete system can do: conditional branching and memory access. He set up a virtual machine and set about implementing all of these tasks using the nurse call system’s features.

The setup for this project is impressive, and belies an extensive knowledge of this one proprietary system but also of computer science in general. It’s interesting to see how something can be formed into a working computer system from parts that otherwise might not be used that way. Even things that aren’t electronic can be used as Turing-complete computers.

Photo via Wikimedia Commons