Restoration Of A Thinkpad 701C

This is like ASMR for Hackers: restoration specialist [Polymatt] has put together a video of his work restoring a 1995 IBM Thinkpad 701c, the famous butterfly keyboard laptop. It’s an incredible bit of restoration, with a complete teardown and rebuild, even including remaking the decals and rubber feet.

[Polymatt] runs Project Butterfly, an excellent site for those who love these iconic laptops, offering advice and spare parts for restoring them. In this video, he does a complete teardown, taking the restored laptop completely apart, cleaning it out, and replacing parts that are beyond salvaging, like the battery, and replacing them. Finally, he puts the whole thing back together again and watches it boot up. It’s a great video that we’ve put below the break and is well worth watching if you wonder about how much work this sort of thing involves: the entire process took him over two years.

We’ve covered some of his work in the past, including the surprisingly complicated business of analyzing and replacing the Ni-Cad battery that the original laptop used. Continue reading “Restoration Of A Thinkpad 701C”

Error-Correcting RAM On The Desktop

When running a server, especially one with mission-critical applications, it’s common practice to use error-correcting code (ECC) memory. As the name suggests, it uses an error-correcting algorithm to continually check for and fix certain errors in memory. We don’t often see these memory modules on the desktop for plenty of reasons, among which are increased cost and overhead and decreased performance for only marginal gains, but if your data is of upmost importance even when working on a desktop machine, it is possible to get these modules up and running in certain modern AMD computers.

Specifically, this feature was available on AMD Ryzen CPUs, but since the 7000 series with the AM5 socket launched, the feature wasn’t officially supported anymore. [Rain] decided to upgrade their computer anyway, but there were some rumors floating around the Internet that this feature might still be functional. An upgrade to the new motherboard’s UEFI was required, as well as some tweaks to the Linux kernel to make sure there was support for these memory modules. After probing the system’s behavior, it is verified that the ECC RAM is working and properly reporting errors to the operating system.

Reporting to the OS and enabling the correct modules is one thing, actually correcting an error was another. It turns out that introducing errors manually and letting the memory correct them is possible as well, and [Rain] was able to perform this check during this process as well. While ECC RAM may be considered overkill for most desktop users, it offers valuable data integrity for professional or work-related tasks. Just don’t use it for your Super Mario 64 speedruns.

Meshtastic And Owntracks To Kick Your Google Habit

I have an admission to make. I have a Google addiction. Not the normal addiction — I have a problem with Google Maps, and the timeline feature. I know, I’m giving my location data to Google, who does who-knows-what-all with it. But it’s convenient to have an easy way to share location with my wife, and very useful to track my business related travel for each month. What we could really use is a self-hosted, open source system to track locations and display location history. And for bonus points, let’s include some extra features, like the ability to track vehicles, kids, and pets that aren’t carrying a dedicated Internet connection.

You can read the title — you know where we’re going with this. We’re setting up an Owntracks service, and then tying it to Meshtastic for off-Internet usability. The backbone that makes this work is MQTT, a network message bus that has really found its niche in the Home Assistant project among others. It’s a simple protocol, where clients send brief messages labeled by topic, and can also subscribe to specific topics. For this little endeavor we’ll use the Mosquito MQTT broker.

One of the nice things about MQTT is that the messages are all text strings, and often take the form of JSON. When trying to get two applications to talking using a shared MQTT server, there may need to be a bit of translation. One application may label a field latitude, and the other shortens it to lat. The glue code to put these together is often known as an MQTT translator, or sometimes an MQTT bridge. This is a program that listens to a given topic, ingests each message, and sends it back to the MQTT server in a different format and topic name.

The last piece is Owntracks, which has a recorder project, which pulls locations from the MQTT server, and stores it locally. Then there’s Owntracks Frontend, which is a much nicer user interface, with some nice features like viewing movement a day at a time. Continue reading “Meshtastic And Owntracks To Kick Your Google Habit”

A monitoring station as set up in the CEZ, featuring both the legacy (ARMS) and new wireless monitoring system.

How The 2022 CEZ Event Shows The Fragility Of Environmental Sensors In High-Risk Areas

In what reads somewhat like a convoluted detective story, the events unfolding at the Chornobyl Exclusion Zone (CEZ) in Ukraine during late February had the media channels lighting up with chatter about ‘elevated gamma radiation levels’, which showed up on the public CEZ radiation monitoring dashboard for a handful of gamma radiation sensors. This happened right before this reporting system went off-line, leaving outside observers guessing at what was going on. By the time occupying forces had been driven out of the CEZ, the gamma radiation levels were reported as being similar to before the invasion, yet the computer hardware which was part of the monitoring system had vanished along with the occupying forces. After considering many explanations, this left security researchers like [Ruben Santamarta] to consider that the high values had been spoofed.

Continue reading “How The 2022 CEZ Event Shows The Fragility Of Environmental Sensors In High-Risk Areas”

Jenny’s Daily Drivers: SerenityOS, And In Particular, Ladybird

As we continue on with the series in which I take a different OS for a spin every month I am afraid, dear reader, that this month I have a confession to make. Our subject here isn’t a Daily Driver at all, and it’s not the fault of the operating system in question. Instead I’m taking a look at a subject that’s not quite ready for the big time but is interesting for another reason. The OS is SerenityOS, which describes itself as “a love letter to ’90s user interfaces with a custom Unix-like core“, and the reason I’m interested in it comes from its web browser. I know that the OS is very much a work in progress and I’ll have to forgo my usual real hardware and run it in QEMU, but I’ve heard good things about it and I want to try it. The browser in question is called Ladybird, and it’s interesting because it has the aim of creating a modern fully capable cross-platform browser from scratch, rather than being yet another WebKit-based appliance.

A Pleasant Trip Into The 1990s

Part of a Linux desktop with the SerenityOS build instructions in the background, a terminal having built the OS, and the OS itself in a QEMU window.
My first look at SerenityOS after building it.

SerenityOS isn’t ready to be installed on real hardware, and there’s no handy ISO to download. Instead I had to clone the repository to my Linux machine and run the build script to compile the whole thing, something I was very pleased to observe only took about 40 minutes. It creates a hard disk image and opens QEMU for you, and you’re straight into a desktop.

When they mention ’90s user interfaces they definitely weren’t hiding anything, because what I found myself in could have easily been a Windows 9x desktop from the middle of that decade. There areĀ  a bunch of themes including some Mac-like ones, but should you select the “Redmond” one, you’re on very familiar ground if you had a Microsoft environment back then. It’s only skin-deep though, because as soon as you venture into a command line shell there’s no DOS to be found. This is a UNIX-like operating system, so backslashes are not allowed and it’s familiarly similar to an equivalent on my Linux box. The purpose of this review is not to dive too far into the workings of the OS, but suffice it to say that both the underpinnings and the desktop feel stable and as polished as a Windows 95 lookalike can be. The various bundled utilities and other small programs seem to work well, and without any hint of the instabilities I’ve become used to when I’ve experimented with other esoteric operating systems. Continue reading “Jenny’s Daily Drivers: SerenityOS, And In Particular, Ladybird”

Decoding The 8088

There is a lot to like about open software, and in some areas, a well-thought-out piece of software can really make a huge impact. A great example of this is the Sigrok project. Creating simple devices that act like a logic analyzer is relatively easy. What’s hard is writing nice software for such a setup including protocol decoders. Sigrok has done it and since it is open, you can add your device and decode your protocol. [GloriousCow] had done the hardware part of interfacing to the 8088 in an IBM PC using an off-the-shelf logic analyzer that uses a customized version of Sigrok. But the output was a CSV file you had to process in a spreadsheet program. The next step: write a decoder for Sigrok to understand 8088 bus cycles.

The post covers the details of writing such a plug-in for Pulseview, the Sigrok GUI. It will also work for the command line interface if you prefer that. The code is in Python.

Continue reading “Decoding The 8088”

Implementing Commodore’s IEC Bus Protocol On A KIM-1 Single Board Computer

Although the PET is most likely the more well-known of Commodore’s early computer systems, the KIM-1 (Keyboard Input Monitor) single board computer was launched a year prior, in 1976. It featured not only the same MOS 6502 MPU as later Commodore systems, but also an MCS6530 PIO IC that contained the ROM, RAM and programmable I/O, reminiscent of later I/O chips on Commodore systems. As the KIM-1 was only designed to be used with an external tape drive (and a terminal for fancy users), adding a floppy drive like the ubiquitous 1541 with its IEC bus interface was not a first-party accessory. How the IEC bus can be retrofitted to a KIM-1 system is demonstrated in this video by the Commodore History channel.

The Commodore KIM-1 hardware is almost directly compatible with the C64 hardware. (Credit: Commodore History on YouTube)
The Commodore KIM-1 hardware is almost directly compatible with the C64 hardware. (Credit: Commodore History on YouTube)

What is most notable is just how similar the KIM-1 hardware is to later PET and VIC hardware, with the CIA and PIO ICs featuring the same requisite pins for this purpose, and requiring only the addition of an inverting (SN7406) IC and an EPROM featuring the new code to support the proprietary Commodore IEC bus protocol, which was mostly pilfered byte-for-byte from a C64 kernal ROM.

With some creative breadboarding in place and using nothing more than the on-board LED display and keyboard matrix, it was then possible to write to the inserted floppy disk, and also to read back from it. What’s interesting here is that this essentially replaces the tape drive as target for the KIM-1, which thus retains a lot of the original functionality, but with a big performance boost. While perhaps only interesting as an academic exercise, it’s definitely an interesting look at the early beginnings of what would blossom into the Commodore 64.

Continue reading “Implementing Commodore’s IEC Bus Protocol On A KIM-1 Single Board Computer”