Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.
PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:
It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris
Whenever phone-based thermal cameras are brought up here on Hackaday, we inevitably receive some comments about how they’re a bad investment compared to a standalone unit. Sure they might be cheaper, but what happens in a couple years when the app stops working and the manufacturer no longer feels like keeping it updated?
It’s a valid concern, and if we’re honest, we don’t like the idea of relying on some shady proprietary app just to use the camera in the first place. Which is why we’re so excited to see open source software being developed that allows you to use these (relatively) inexpensive cameras on your computer. [Les Wright] recently sent word that he’s been working on a project called PyThermalCamera which specifically targets the TOPDON TC001, which in turn is based on a project called P2Pro-Viewer developed by LeoDJ for the InfiRay P2 Pro.
Readers may recall we posted a review of the P2 Pro last month, and while the compact hardware was very impressive, the official Android software lacked a certain degree of polish. While these projects won’t help you on the mobile front in their current form, it’s good to know there’s at least a viable “Plan B” if you’re unwilling or unable to use the software provided from the manufacturer. Naturally this also opens up a lot of new possibilities for the camera, as being connected to a proper Linux box means you can do all sorts of interesting things with the video feed.
The two video feeds on the left are combined to produce the final thermal image.
Speaking of the video feed, we should say that both of these projects were born out of a reverse engineering effort by members of the EEVblog forums. They figured out early on that the InfiRay (and other similar models) were picked up as a standard USB video device by Linux, and that they provided two video streams: one being a B&W feed from the camera where the relative temperature is used as luminance, and the other containing the raw thermal data cleverly encoded into a green-tinted video. With a little poking they found an FFmpeg one liner that would combine the two streams, which provided the basis for much of the future work.
In the video below, you can see the review [Les] produced for the TOPDON TC001, which includes a demonstration of both the official Windows software and his homebrew alternative running on the Raspberry Pi. Here’s hoping these projects inspire others to join in the effort to produce flexible open source tools that not only unlock the impressive capabilities of these new thermal cameras but save us from having to install yet another smartphone application just to use a device we purchased.
As a recent emigre from the Ubuntu Linux distribution to Manjaro, I’ve had the chance to survey the field as I chose a new distro, and I realised that there’s a whole world of operating systems out there that we all know about, but which few of us really know. Hence this is the start of what I hope will be a long-running series, in which I try different operating systems in my everyday life as a Hackaday writer, to find out about them and then to see whether they can deliver on the promise of giving me a stable platform on which to earn a living.
For that they need an internet connection and a web browser up-to-date enough to author Hackaday stories, as well as a decent graphics package. In addition to using the OS every day though, I’ll also be taking a look at what makes it different from all the others, what its direction and history is, and how user-friendly it is as an experience. Historical systems such as CP/M are probably out of the question as are extremely esoteric ones such as the famous TempleOS, but this still leaves plenty of choice for an operating system tourist. Join me then, as I try all the operating systems.
A Distro From The 1990s, Today
The Hackaday test PC gets its first outing.
When deciding where to start on this road, there was an obvious choice. Slackware was the first Linux-based distribution I tried back in 1995, I’m not sure which version it was , but it came to me via a magazine coverdisk. It was by no means the first OS that captured my attention as I’d been an Amiga user for quite a few years at that point, but at the moment I can’t start with AmigaOS as I don’t have nay up-to-date Amiga-compatible hardware.
July 2023 also marks the 30th anniversary for the distro making it the oldest one still in active development, so this seems the perfect month to start this series with the descendant of my first Linux distro. Slackware 15 comes as a 3.8 GB ISO file download for 64-bit computers, and my target for the distro was an old desktop PC with an AMD processor and a big-enough spinning rust hard disk which had been a high-end gaming system a little over ten years ago. Not the powerhouse it once was, but it cost me nothing and it’s adequate for my needs. Installed on a USB Flash drive the Slackware installer booted, and I was ready to go. Continue reading “Jenny’s Daily Drivers: Slackware 15”→
Of course, Quake is an old game with a software renderer. Just throwing another camera into the scene, rendering to another texture, and then mapping that texture to the scene isn’t an option. Quake uses an edge rasterizer and generates spans along scanlines that track where edges intersect the current scanline. Rather than making expensive per-pixel comparisons, [Matt] stashes the portal spans and renders them in a second render, so even with multiple portals, only a single screen’s worth of pixels are rendered.
However, this technique has no near clipping plane, which means objects can appear in the portal that don’t make any sense as they are in front of the portal’s viewpoint. Luckily, Quake has an ingenious method for polygon occlusion: the BSP. While [Matt] is manually checking polygons, the BSP is the perfect tool for bisecting a room along a plane. It’s an incredible hack, and we’re excited to see Quake expand into a puzzle game. [Matt] dives into greater detail on how the software renderer works in another video that’s well worth a watch.
Perhaps the most incredible aspect of this technique is that it could run on original hardware. If you want to bring a little more Quake to life, why not get the Quake light flicker in your house? Video after the break.
We always enjoy [FesZ’s] videos, and his latest about FREQ function in LTSpice is no exception. In fact, LTSpice doesn’t document it, but it is part of the underlying Spice system. So, of course, you can figure it out or just watch the video below. The FREQ keyword allows you to change component attributes in a frequency-depended way.
Of course, capacitors and inductors are frequency dependent by design. But the FREQ technique allows you to adjust things like voltage sources or resistance in arbitrary ways. By default, you must specify the frequency response data in decibels, which isn’t always convenient. However, [FesZ] shows you how to use other methods to express them using modifiers to the command.
The repository concerns the Microsoft 16K BASIC Interpreter as built for the Motorola 6809, as used in the Dragon 64 computer. This is also known as BASIC-69 or Extended Color Basic.
Hilariously, the source code was recovered from 340 pages of fan-fold tractor paper stored in four bundles. The output of a Motorola assembler was printed back in 1983 at Dragon Data’s R&D facility in Wales, and was recently recovered after being stored in an attic for much of the last four decades. The paper was carefully scanned at the 2022 Dragon Meetup, before passing the resulting images through OCR software. The output was then manually corrected and the source code was complete for both the 32K and 64K mode ROMs. There are some differences between the scanned source and what Microsoft shipped, which is outlined in the repository.
We’ve seen other heroic retrocomputer recovery efforts before, too, like the work to save the Polish CROOK OS. If you’ve been working on similar feats, be sure to let us know.
There are few rites of programmer passage as iconic as writing your first parser. You might want to interpret or compile a scripting language, or you might want to accept natural-language-like commands. You need a parser. [Varunramesh] wants to show you parser combinators, a technique used to make practical parsers. But the demonstration using interactive code cells in the web page is nearly as interesting as the technique.
Historically, you parse tokens, and this technique can do that too, but it can also operate directly on character streams if you prefer. The idea is related to recursive descent parsing, where you attempt to parse certain things, and if those things fail, you try again.
