An Open-Source, Free Circuit Simulator

The original circuit simulation software, called the Simulation Program with Integrated Circuit Emphasis, or SPICE as it is more commonly known, was originally developed at the University of Califorina Berkeley in the 1970s with an open-source license. That’s the reason for the vast versions of SPICE available now decades after the original was released, not all of which are as open or free as we might like. Qucs is a GPL circuit simulator. And if you want the GUI option, you might want to try out QucsStudio, which uses Qucs under the hood, and is free to use, but binary-only.

(Editor’s note: the author was confused between the GPL open-source Qucs and the closed-source, binary-only QucsStudio. We’ve cleaned that up.)

QucsStudio supports a wide range of circuit components and models much in the same fashion as other more popular SPICE programs, including semiconductor devices, passive components, and digital logic gates. Qucs also utilizes SPICE-based simulation, which can model various types of circuit behavior, such as DC, AC, transient, and small-signal analysis.

Unfortunately there are only Windows versions available, and although some might have some success running it under WINE. There are plenty of other options for those of us running non-Windows operating systems though. Here’s a review of 30 of them.

Thanks to [Electroagenda] for the tip!

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.