Where Old Files Go To Die

We all lead digital lives, and we work in and on files of one sort or another. And sometimes we get attached to them. That long manifesto you poured your heart into, but nonetheless probably shouldn’t see the light of day? Love letters from former flames? Your first favorite video game that you can’t play any more, but it just sits there eating up drive space?

These are the files that are important enough that they deserve better than just a drag-and-drop into the trashcan. They deserve to be buried with dignity, and that’s just what [Ulf Schleth]’s /death/null offers us – a digital graveyard where our files no longer exist as they were, but still are allowed to linger in memory.

This is an old project, but one that tickled our funny  and poignant bones in equal parts. The pun on /dev/null probably works just a little better if you read both filepaths with a German accent in your head, but the idea translates anyway.

To use it, you simply upload your file and it gets sent to the great trashcan in the sky, but along the way a 4 x 5 matrix of colored blocks is created that represents the file, and it is registered forever in the graveyard, where you can check up on it any time you like. Of course you can’t read it – only 20 RGB triples remain – but you have the digital “gravestone” as commemoration.

Even if you don’t have any loved ones in [Ulf]’s graveyard, you can walk by and see which files others have chosen to remember. Swing on by and pay your respects to notepad.exe.

Grab Your ‘Scope’s Screen From The Command Line

Many of us have oscilloscopes and other instruments with built-in digital interfaces, but how many of us use them? [Andrej Radović] has a Tektronix TDS2022 which can print its screen to any of its various interfaces, and he set about automating the process of acquisition with a Bash script.

The easiest interface to use was the trusty serial port — hardly the fastest but definitely the best supported. But how does one retrieve an image fired down a serial port? Most of the post is devoted to spotting file headers in a Bash script monitoring the serial port, and streaming the result to a local file. There’s a discussion of the various formats supported by the Tek, with an ancient PCX bitmap format being chosen over Postscript for speed. The result is a decent quality screen grab, making the ‘scope that little bit more useful and perhaps extending its life.

Perhaps your instrument isn’t a TEK, but the chances are you can still make it bend to your will from a PC. Try it, with the magic of VISA.

DOOM On IPhone OS, On Android

So you want to play some games from the early days of 32-bit iPhone OS that no longer run on recent OS versions? [Hikari-no-yume] wrote a sweet high-level emulator, touchHLE, to do so on modern iOS phones. But maybe you don’t have an iPhone? [Ciciplusplus] has your back. He ported the iPhone OS emulator, written in Rust, to Android, and then ported a version of DOOM that runs on iPhone OS to go with it.

[Ciciplusplus] also made a video (embedded below) where he documented the trials and tribulations of porting Rust code to the Android platform – an intensely Java environment. It doesn’t sound like it was at all trivial. Of course, this couldn’t have been accomplished without [Hikari-no-yume]’s original work on touchHLE, which was made essentially to fulfill [Hikari-no-yume]’s long-time obsession with the game Super Monkey Ball.

So for now, touchHLE can boast the ability to run a few old 32-bit games on Android and desktop operating systems. What other games from the first years of gaming on smart phones (and iPods) do you need to see ported? Get involved in the project if you’ve got an itch you need scratched.

Continue reading DOOM On IPhone OS, On Android”

Text-to-Speech Model Can Do Music, Background Noises, And Sound Effects

Bark is a universal text-to-audio model that can not only create realistic speech, it can incorporate music, background noises, and sound effects. It can even include non-speech sounds like laughter, sighs, throat clearings, and similar elements. But despite the fact that it can deliver such complex results, it’s important to understand some of the peculiarities.

The model takes a prompt and generates the resulting sound from scratch. Results might sometimes be unexpected.

Bark is not a conventional text-to-speech program, and how it works has a lot more in common with large language model AI chatbots. This means that results can deviate from expectations, and outputs aren’t necessarily going to be studio-quality speech. As the project’s README points out, “(generated outputs can) be anything from perfect speech to multiple people arguing at a baseball game recorded with bad microphones.” That being said, there is some support for voice presets as a way to help guide the model with some consistency.

Bark was designed by a company called Suno for research purposes and is available under the MIT License. It can be installed and run locally, and has some demos available as well as an online implementation.

The ability to install and run Bark locally is promising territory for incorporating it into projects. And should you be more interested in speech-to-text instead, don’t forget about this plain C/C++ implementaion of AI-powered speech recognition.

Bridging A Gap Between LLMs And Programming With TypeChat

By now, large language models (LLMs) like OpenAI’s ChatGPT are old news. While not perfect, they can assist with all kinds of tasks like creating efficient Excel spreadsheets, writing cover letters, asking for music references, and putting together functional computer programs in a variety of languages. One thing these LLMs don’t do yet though is integrate well with existing app interfaces. However, that’s where the TypeChat library comes in, bridging the gap between LLMs and programming.

TypeChat is an experimental MIT-licensed library from Microsoft which sits in between a user and a LLM and formats responses from the AI that are type-safe so that they can easily be plugged back in to the original interface. It does this by generating JSON responses based on user input, making it easier to take the user input directly, run it through the LLM, and then use the output directly in another piece of code. It can be used for things like prototyping prompts, validating responses, and handling errors. It’s also not limited to a single LLM and can be fairly easily modified to work with many of the existing models.

The software is still in its infancy but does hope to make it somewhat easier to work between user inputs within existing pieces of software and LLMs which have quickly become all the rage in the computer science world. We expect to see plenty more tools like this become available as more people take up using these new tools, which have plenty of applications beyond just writing code.

Who’s Afraid Of Assembly Language?

This week, [Al Williams] wrote a great thought piece about whether or not it was worth learning an assembly language at all anymore, and when. The comments overflowed, and we’re surprised that so many people basically agree with us: yes. Of course, it’s a Hackaday crowd, but I still didn’t expect the outpouring of love for the most primitive of languages.

Assembly language isn’t really one language, though. Every chip speaks its own dialect. Of course there are similarities: every CPU has an add function, right? But almost no CPU has just one add – there are variants with and without carry, storing and reading from working registers or RAM. And once you start talking about memory access, direct or indirect, the individual architectures of the chips demand different assembly languages.

But still, although the particular ways that CPUs do what they do can be incompatible from a strictly language perspective, they are a lot more similar in terms of the programming idioms that you’ll pick up along the way. Just as learning a set of solid algorithms will help you no matter which higher-level language you use, learning the concepts behind crafting loops and simple memory structures out of raw assembly language will serve you no matter which CPU you choose.

I have only written assembly language for a handful of CPUs, and not much of it at that, but I’ve found the microcontrollers to be the friendliest. So if you want to dip your toes in that water, pick up an AVR or an MSP430. Or maybe even the new hotness – a RISC-V. You’ll find the instruction sets small enough that you have to do most of the work yourself. And that is, after all, the point of learning an assembly language: learning to think like the silicon. If you treat it like a fun puzzle to solve, you’ll probably even enjoy the experience.

[Al]’s original question was when you should learn an assembly language: before or after a higher-level language. For 99% of our readers, I’d say the answer is right now.

Modern Software Brings Back The Timex Datalink

As much as some people on the Internet might like to think — no, Apple did not come up with the idea of the smart watch. Even if you ignore the calculator watches that we imagine a full 60% of Hackaday readers wore at one time or another in their lives, the Timex Datalink was already syncing with computers and pulling down the user’s list of appointments back in 1994 by decoding the pulses of light produced by a CRT monitor. Hey, it sounded like a good idea at the time.

Unfortunately, this idea hasn’t aged well. The technique doesn’t work on more modern displays, and naturally the companion software to generate the flashing patterns was written for Windows 3.1. But thanks to the reverse engineering efforts of [Synthead], you can now sync any version of the Timex Datalink to your computer using nothing more complex than the onboard LED of the Teensy LC or Raspberry Pi Pico.

There’s actually several different projects working together to make this happen. In place of a CRT, there was an official “Timex Datalink Notebook Adapter” back in the day that was designed to be used on laptops and featured a single blinking LED. That’s what [Synthead] has recreated with timex-datalink-arduino, allowing a microcontroller to stand in for this gadget and featuring 100% backwards compatibility with the original Datalink software.

Appointment data is loaded from a text file.

But since you’re probably not rocking Windows 3.1 anymore, having access to that software is far from a given. That’s why [Synthead] also created timex_datalink_client, which is a Ruby library that lets you generate data fit for upload into the Timex Datalink. At the time of this writing there doesn’t seem to be a friendly user interface (graphical or otherwise) for this software, but it’s easy enough to feed data into it using plain-text configuration files.

Helpfully [Synthead] provides screenshots of information loaded into the original software, followed by a config file example that accomplishes the same thing. It looks like writing some glue code that pulls your schedule from whatever service you fancy and formats it for the Datalink client should be relatively simple.

We’ve previously seen projects that got the Timex Datalink synced without the need for a CRT, but they still required the original software. To our knowledge, this is the first complete implementation of the Datalink protocol that doesn’t rely on any original hardware or software. Expect eBay prices to go up accordingly.