Modern video game consoles rarely have expansion ports, but in the 80s and 90s it was practically guaranteed. With the speed that hardware was advancing it made sense to build in some way to expand a system’s capabilities throughout its lifespan, like the memory port in the Nintendo 64 or the Sega CD and 32X attachments for the Sega Genesis. Some were ultimately unused as well, like the port under the Super Nintendo or, arguably, the interesting way that [decrazyo] figured out how to add graphics capabilities to the original Nintendo Entertainment System.

The basis of this upgrade is the fact that the Picture Processing Unit (PPU) on the NES has four pins that are grounded. These four pins tell the NES to display the background color if the pixel is transparent. Since they’re normally grounded, this means the NES can only display a limited background image, but there’s no reason these pins must be grounded. By using a second PPU configured to output graphics information and wiring it to these four pins on the first PPU, the NES can be given all kinds of new abilities, such as adding parallax effects to backgrounds, rendering more sprites, and showing more colors in the backgrounds.

Of course, the hardware requirements for this will require a donor NES to get the second PPU as well as the necessary memory chip for it, and we don’t recommend tearing apart perfectly good retro consoles for experimentation if it can be avoided. Presumably, you could use this open-source NES hardware alternative instead. But for those with the parts and the gumption, creating a demo or adding graphics features to homebrew games using this second graphics chip is within reach.

As great and streamlined as the Windows desktop experience is, one area where it’s at best disappointing and at worst rage-inducing is when it comes to its command line interface (CLI) offerings. In Windows 9x/ME this could be excused by the fact that it was essentially just a dressed-up MS-DOS CLI experience, but on Windows NT-based OSes no such excuse exists.

Yet even after Microsoft finally acknowledged the shortcomings of the cmd.exe shell by 2006, they then proceeded to go their own way with PowerShell, industry standards be damned. Especially for those of us who have no beef with the UNIX/BSD/Linux CLI experience and the joys of shell scripting, this insistence was disappointing. Simultaneously, everyone from OS X/MacOS to Haiku were happily offering a familiar CLI environment alongside POSIX compatibility.

Although Windows NT OSes were POSIX compliant, they never offered a suitable shell along with it, nor any of the other things you’d expect in a modern-day BSD, Haiku or Linux CLI environment. In a recent article by my esteemed colleague Al Williams, these sore points were somewhat addressed as far as basic CLI tools go, but the issue goes obviously much deeper than just the basic userland tools. Which is where MSYS2 comes into the picture.

Defining The Problem

When one says that they’d like a ‘Linux shell on Windows’, it can be hard to pin down exactly what this means. As Al noted in his article on CoreUtils last week, there are solutions like Cygwin that add a translation layer between Windows and Linux-ish code and offer a basic shell experience, but what if you really want to have a full Linux-like shell experience including support for common POSIX tools and libraries, as well as typical tooling like make and gcc?

Microsoft’s CoreUtils package gets you a GNU userland-like experience, but that’s arguably a small part of the whole issue. The reason why over the years I drifted away from Linux tools ported to Windows – as well as bailed on WSL, WSL2, Cygwin and full-fat VMs – is due the amount of friction these added when all that I wanted was to use a Bash-like shell for day-to-day tasks and general software development. For all intents and purposes I wanted to pretend that I was just on a modern Linux distro like Arch without having to fire up some special application with significant overhead or waddle over to one of my systems that have Linux installed.

This means a GNU-style userland, basic POSIX compatibility, being able to run shell scripts, having access to a package manager like on BSDs/Linuxes/Haiku/etc., ideally all in a way where it blends quite seamlessly into the overall Windows GUI experience. Essentially the laziest and most off-the-shelf experience possible, if you want.

This is where a full-fat VM is obviously too heavy and restricted, while WSL(2) also carries too many of the VM-related flaws with it, as it’s too much trying to be Linux instead of integrating with the Windows experience. The ideal solution here would probably feel more like the standard terminal on Haiku.

The MSYS2 Solution

With MSYS2 you can use the same pacman package manager you’d use on Arch/Manjaro to fetch packages. You’re also using a regular Bash shell and the only major hurdles you’re likely to run into concern limitations with low-level tools like Valgrind and some Windows-related quirks that the MSYS2 developers can’t do too much about because Microsoft. Internally it’s still based on Cygwin, so you can count on a similar level of compatibility, but without fuss.

For day-to-day use it’s a very familiar Linux-like experience for especially software-development purposes and common shell-based shenanigans like automation tasks and running a range of tools such as ffmpeg and yt-dlp, both of which are of course readily available from the package repository. In this sense MSYS2 adds a terminal and CLI environment that blurs the lines between BSD/Haiku/Linux and Windows, just the way us cross-platform developers like things, as this way you can use the same scripts and same know-how and muscle-memory across terminals and TTYs.

Perhaps the only negative here is again due to MSYS2 being not fully integrated into Windows, resulting in e.g. binaries compiled within an MSYS2 environment relying on shared libraries that are not on the Windows system path. This can be worked around by copying all the DLLs into the binary folder, or doing system path things, but it’s one of the reasons why I do distribute binary builds for Windows of my OSS projects that are compiled using NMake and MSVC.

The MSYS2 Environments

When you first install MSYS2, the most important thing to learn are the distinctions between the various MSYS2 environments. This is the first thing you see after happily installing MSYS2, finding yourself staring at a list of various terminal options, as summarized below. Over the years a number of these environments have been retired, in particular the 32-bit environments, but also the MinGW64 environment that used to be the primary one until Windows 10 added the Universal C Runtime (UCRT).

The MSYS2 environments page provides a lot more detail, but the brief summary is that you should just use the UCRT terminal. It builds upon the MSYS environment just like the other options, essentially setting up a number of defaults, with some of these listed in the above table. Although you can use the Clang environments, these aren’t nearly as mature or full-featured, so your mileage may vary there.

Development Features

My basic software development workflow involves Notepad++ to write code and a Makefile, and the use of an MSYS2 UCRT terminal to run make, along with gdb, grep and utilities such as ldd for happy-fun debugging purposes. When I do embedded development that targets e.g. STM32, I can fetch the entire GCC-based toolchain for ARM Cortex-M via pacman and use that in exactly the same way as I would in a Linux-based terminal or TTY.

I have always found doing such development things the ‘Windows way’ to be rather tedious and cumbersome, having spent considerable time in the past using environments like Visual Studio and other IDEs such as Code::Blocks. While any approach can be made to work, just being able to use the same shell scripts, same gdb configurations, and the same Makefiles. across FreeBSD, Linux, Haiku, and Windows saves a lot of time and effort as you never have to duplicate effort.

MSYS2 Limitations

As alluded to earlier, MSYS2 doesn’t integrate perfectly in Windows as it is still just a third-party application. It also only covers userland, so kernel-level drivers and tools like Valgrind will require a full-blown Linux system. However, unless I’m doing some crazy involved profiling or debugging I’ll generally just use Dr. Memory on Windows, which works the same as Valgrind and also has packages for Linux and MacOS.

Whether it’s a limitation or not I’m not entirely sure, but stdout in MSYS2 Bash also sometimes does seem to have trouble outputting where Bash or similar on BSD/Haiku/Linux does not, which is an issue that I still need to diagnose in more depth one day to file a ticket for. That said, having created issue tickets for the MSYS2 (packages) project in the past has at least made it clear that its developers are quite responsive and fairly tame.

These minor niggles aside, I’m quite grateful to the MSYS2 project for allowing me to have both the solid Windows GUI experience and also have my heavily Arch-inspired CLI cake with pacman icing.

Many oscilloscopes have provisions to be connected to a computer and used remotely, but most of those interfaces are fairly rudimentary. To address this, [Winfried] has developed the SDS-Remote, a remote interface for the Siglent SDS 1000X-E series oscilloscopes.

The 1000X-E series oscilloscopes have both USB and network interfaces, and the SDS-Remote can use either (though the USB interface is still somewhat experimental). SDS-Remote allows for remote controlling the oscilloscope, capturing waveforms super handy as it lets you export a CSV file of the waveforms for further analysis. You can also capture screenshots of the scope through the web interface, making it much easier to compare waveforms as you’re working on a project. The built-in data logging lets you run long experiments and save out their results. The macro recorder lets you automate complex tests using SCPI commands and brings basic scripting to the interface without needing to run separate code. There’s also a mechanism to integrate an AI LLM to help translate common language into the correct scope configuration.

Thanks [Winfried] for sharing this awesome web interface for the oscilloscope no doubt it’ll be a welcome upgrade for those already remote controlling their Siglent scope. Head over to his GitHub page and check it out for yourself! Have you written any improved user interfaces for your equipment? Be sure to let us know what you’ve done so we can share with others who may find use in an interface that offers more than came with the product.

McCulloch County, Texas, is smack dab in the middle of a very large state. We wouldn’t exactly call it the middle of nowhere, but given there’s so little light pollution it scores a 1 on the Bortle Scale, it’s not exactly the Big Apple, either. [Bray Falls] lives there, and has a job description we have become immediately jealous of: [Bray] is a telescope rancher.

Like the song goes, the stars really are big and bright at night deep in the heart of Texas. Not only is his ranch free of the light pollution that plagues more urban locations, central Texas is pretty dry, with only a few days of rain in any given month. That’s not great for agriculture, but it’s great for astronomy since it means the skies are most often cloud-free. Combine that with access to high-speed internet, and you have the makings of a telescope ranch.

It’s brilliant in its simplicity: along with his own ‘scopes, [Bray]’s Starscope Observatory hosts hundreds of other people’s CCD equipped goto telescopes, all set up to be remote controlled over the information superhighway. On clear nights– which again, is most of them–the roofs roll off the telescope barns and observations can begin. Pad rental comes with tech support, too, so you don’t have to fly out to heart of darkest Texas if your mount gets jammed or you lose signal for any reason. That said, you should be sure to read the fine print before signing up, because said tech support probably doesn’t apply if you 3D printed your own ‘scope, or built your own mount.

That said, having gone to the effort of doing all that, would you really send your baby away to a farm upstate? Best reserve that for the old Celestron collecting dust in the corner. If you think we should be leaving these observations to the pros, be aware [Bray] has apparently discovered a very oddly-placed supernova remnant, 40 degrees off the galactic plane in Virgo. So this isn’t just a rewarding hobby; it’s still science, too.

The British government is in a headlong rush to ban under-16s from social media, and restrict the access of under-18s. And in typical form, the EFF is here with a warning about the dangers and futility of such legislation.

The proposed new law will involve an age restriction policed through online ID verification, something which will not be limited to the young, as every British adult will also have to show ID to access large parts of the Internet.

There is little in the way of information about how this unprecedented invasion of privacy will be implemented, however we expect that it will be left to the lax security measures of a range of lowest-bidder third party identity verification services. The resulting database will become a very rich target indeed.

The EFF pull no punches in warning of the harms these measures will bring upon those it seeks to protect. Far from “Giving under-16s their childhood back” as it is being promoted, they warn that it will deprive them of access to community, friends, and distant family, as well as educational content that could be vital for them.

If it works at all. Certainly he more technically minded youth will put their efforts into the world of computer networking. A VPN ban is reportedly in the works, so a whole generation of future software developers and IT specialists will get their start running software to get round this on their Raspberry Pi.

We’ve reported on the EFF’s concerns over UK ID laws before.

Header image: Diliff, CC BY-SA 2.5.

There are as almost as many kinds of coffee as there are of coffee drinkers, with each method for preparing the beverage appealing to a different kind of palate: moka pots, filter coffee, pour-over coffee, French presses, cold brews, espresso, and more produce their own unique flavours by extracting different compounds from the grounds to different degrees. Now, a new method has joined the throng: ultrasonic-assisted extraction, which can produce even an espresso at room temperature.

Espresso is normally made by forcing hot water through tightly-packed, finely-ground coffee beans, quickly producing a concentrated extraction. Its one of the hardest kinds of coffee to consistently make well, since the outcome is influenced by everything from grind size and packing density to temperature, pressure, and more. Ultrasonic agitation helps here by creating cavitation bubbles, which form shock waves as they collapse, breaking open the bean structure and producing small, strong jets of water. The experimental apparatus was built into a modified espresso machine. An ultrasonic transducer delivers vibrations to the basket containing the room-temperature slurry of coffee grounds for two or three minutes.

To quantify the results, the researchers analysed total dissolved solids, extraction yield, pH, colour, volatile components, and caffeine and chlorogenic acid contents. By varying ultrasonic power and grind size, the extraction yield and dissolved solids could be adjusted to closely match traditional espresso or cold-brew coffee. The other metrics had no significant differences, and a survey of 100 coffee drinkers found no preference between this and traditional espresso. When the drinkers tried the cold-brew coffees, they preferred the version made with ultrasonic assistance. The experiment succeeded in its goal of reducing energy consumption: the ultrasonic-assisted coffee took about a quarter as much energy to make.

If you still prefer a more traditional approach, we’ve covered some beautiful espresso machines before, including one made out of motorcycle engine parts.

Today marks the summer solstice, the longest day of the year and the start of astronomical summer in the Northern Hemisphere. This doesn’t really have much to do with hacking hardware or building gadgets other than the fact that from this point on you’ll have progressively less daylight hours to do it in each day. Of course, if you do your best work in the middle of the night this won’t impact things much.

If you’re as likely to find a controller in your hand as a soldering iron in the evenings, you might be interested in a recent filing against Sony. Lawyers representing a group of four gamers allege that the entertainment giant is violating a California law that says digital storefronts need to make it clear that buyers don’t technically own the games in question but are merely licensing them — a license which, as we’ve seen in the past, can be revoked or modified at any time with no restitution made to the purchaser.

Now while we agree conceptually that selling gamers a license rather than an actual copy of the game is clearly a one-sided deal, we’re still not sure this case has a lot of merit. As far as we can tell, Sony does make it clear in the fine print that you’re not really going to own anything once they take your money. Or, at the very least, they make it equally as clear as any other company that’s selling digital downloads these days. Should the court actually find that said fine print is a little too fine, it could conceivably have ramifications throughout the entertainment industry. This is certainly a case to keep an eye on.

If you want to be sure none of your games can be removed from your digital grasp without warning, perhaps your best bet is to stick to the classics. Fans of 1989’s F-15 Strike Eagle II on PC will be excited to hear that there’s an ongoing effort by Neuvieme Porte to reverse engineer the flight sim and re-implement the whole thing in portable C.

This would open up all sorts of possibilities, such as ports to other platforms and the addition of new features and content. But before the project can get to that point however, Neuvieme is looking to recruit some virtual test pilots. Just keep in mind that the goal, at least for now, is to recreate the game exactly. That means bugs present in the original release are to be preserved. As such, it would help to have logged enough hours back in the DOS days to recognize what’s an OG bug and what’s been newly introduced.

From working on virtual jet fighters to the real deal, IEEE Spectrum recently ran an article about a startup called Phoenix Semiconductor that’s looking to produce bespoke pin-compatible replacements of critical chips for the military. They reason that the Air Force won’t mind paying $1,000 for a chip that cost them a buck back in 1975 when the alternative is grounding a $70+ million F-18 that needs the thing to take off. The goal isn’t really to recreate the old parts as they were, but instead to build drop-in replacements that are tailored for specific applications. In other words, Uncle Sam doesn’t care of the IC actually looks like the original, so long as it fits and it gets the jet up in the air again.

Finally, on the subject of aerospace technology, NASA’s Jet Propulsion Laboratory published a blog post earlier this week detailing their work on the Exploration Rover for Navigating Extreme Sloped Terrain (ERNEST). While NASA’s Curiosity and Perseverance rovers have done some incredible work on Mars, they’re slow and have to be operated with the utmost caution to make sure they don’t get stuck. In comparison, ERNEST is several times faster and is designed with an active suspension system that lets it lift each wheel up off the ground independently if needed.

The prototype rover also features improved autonomy that may allow future rovers make more decisions on their own. That may not be a huge time saver on the Moon, but given the communication delays with the Red Planet, a Mars rover that doesn’t have to stop and ask Earth for directions so often will be able to get more useful work done at the end of the day.

See something interesting that you think would be a good fit for our weekly Links column? Drop us a line, we’d love to hear about it.