Vehicles long ago began to incorporate electronics and software, to the point that modern vehicles increasingly have a sort of architecture problem. The software end of things evolves ever more rapidly, but vehicles and their centralized architecture are poorly-suited to continuous updates. As a result, the automotive industry is moving away from static, hardware-defined designs and more toward dynamic, software-defined platforms. In short, the era of software-defined vehicles looms nearer every year.

There are very good reasons vehicles are the way they are, however inconvenient it may be for pushing updates. A vehicle may be in service for decades, with safety and reliability a prime concern over that lifetime. Reflecting this, automobiles are built around centralized SoCs (System-on-a-Chip) supported by tried and true components and assemblies. As mentioned, this architecture isn’t terribly well suited to meshing with a rapidly evolving software world that may also have changing computing needs. How can one accommodate this without increasing safety risks?

Some new designs are moving away from monolithic SoCs to more modular systems; ones that can support and optimize safety-critical functions and other workloads independently. Computing requirements are chosen to prioritize consistent performance and low-latency sensor fusion over raw processing power, and modern design focuses less on individual components and more on integrated hardware and software assemblies that ease manufacture and reduce design complexity.

The main goal is to design vehicles in a way that can more easily take advantage of rapid developments in software and allow easy updates, without compromising safety or reliability. Automakers haven’t completely settled on what architecture will do this best, but the era of software-defined vehicles is certainly coming closer.

hackaday.com/2026/07/12/softwa…

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

youtube.com/embed/nDe06uY5C40?…

hackaday.com/2026/07/11/portin…

As unique the Nintendo Wii U Gamepad may appear to be, at its core it’s pretty much just a tablet with game controls stuck on it. Now that the communication between the Wii U and the Gamepad have been fully reverse-engineered and poured into easy to use software, this opens the possibility of using other tablets with suitable controls on them for Wii U Gamepad purposes, like the Windows-capable Samsung tablet that [Bringus Studios] decided to experiment on.

Originally designed to run Windows XP Tablet PC Edition, the Samsung Q1 series of ultra-mobile PCs (UMPC) was first released in 2007, featuring a 900 MHz Celeron M CPU. Amusingly [Bingus] mixes up mAh and mWh when comparing battery capacities, as the Li-ion battery pack for this UMPC is an 11.1V one, whereas a smartphone battery is 3.7V nominal.

To turn this UMPC into a Wii U Gamepad, first 32-bit Debian 12 is installed along with the Vanilla Wii U Gamepad project. The main challenge then is to find a Wi-Fi adapter that works for this purpose, as the connection uses a slightly non-standard handshake. Naturally the TP-Link USB WiFi adapter that [Bingus] used changed from its previous and better supported Mediatek chipset to a Realtek one with typical poor Linux support, requiring manual driver compiling.

After more troubleshooting, it’s unfortunately found that the 900 MHz Celeron M in this UMPC just isn’t up to the task, with the decoding of the compressed HDMI stream correspondingly pegging the CPU at 100% with all the frame dropping. It’s likely that this is due to a lack of h.264 hardware decoding support, as this would push this burden onto the CPU. The system uses the Intel 915GMS chipset with the GMA 900 iGPU, which appears to just provide hardware acceleration for MPEG 2.

youtube.com/embed/Rrvrl_Oe5lA?…

hackaday.com/2026/07/11/trying…

Online publications sometimes work with sponsors. Over at the Autopian, they landed a sponsorship deal with eBay, but due to an unguarded comment, fulfilling the sponsor’s requirements turned out to be something of a handful. Build a brand-new, completely WW2-spec Jeep using only parts sourced from the auction site, and drive it to Moab for an event. [David Tracy] set to work, and the resulting write-up is a build of epic proportions.

Of course, many Jeeps have been built since the war, not least by Willys and its successors, but also by enthusiasts. You can even buy a modern-day visible derivative of the original made in America by the Indian company Mahindra, which has been licensed to build Jeeps since the 1940s. So his claim of making the first new WW2-spec Jeep since the war may be difficult to substantiate, but it’s certain that his attention to period detail is exceptional. For example, most people would either use a more modern engine or find a second-hand original. Instead, he sources a brand new block from France and builds a new engine from scratch. And is that the infamously flawed early Jeep steering system we spy? The vehicle uses second-hand parts for other major drive train components, but the chassis and body are made in the Philippines.

An early Jeep is a simple vehicle, but following his build, you realise the power of the manufacturing industry, as so many individual parts and assemblies must come together to make the finished machine. Some of us have had old cars in our lives, so we appreciate this very well. The moment of completion comes with very little testing time to spare, and he’s off on the long drive from LA to Moab. That in itself could make an epic write-up, and yet again, we recognise the combination of willpower and worry. All of this has made us idly want one of these wildly impractical but seductive vehicles, but we know it will pass. If you aren’t interested in authenticity, you can always meld a Jeep with a Prius.

hackaday.com/2026/07/11/the-fi…

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their leage in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [FabianKuebler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites be bounced at a blistering 0.8 fps on the simulated PPU. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port– if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense– the kind of micros you run MicroPython on can emulate the SNES.

Thanks to [Fabian] for the tip!

hackaday.com/2026/07/11/microp…

Giving machines the ability to communicate nonverbally has real value, and [Drew Smith] clearly thinks your robot deserves better than an emoji. He shared a very interesting approach with his project Kindalive.

Kindalive is a simulated dot-matrix robot face that responds believably to input text, modeling and expressing both short-term and long-term moods. It’s pure Python and modular enough to invite using it elsewhere, but that’s not the really interesting part.

What sets [Drew]’s project apart is the way he models eight key neurochemicals (including dopamine and cortisol) as the foundation from which to derive emotional states. That’s an approach we certainly haven’t seen before.

Conventional sentiment analysis uses a large language model (LLM) to apply discrete labels to communication, but Kindalive doesn’t do that. It even goes so far as to model the decay and interplay between its simulated neurochemicals to derive emotional states on the fly. It’s more fluid and organic, and reflects both short-term and long-term mood changes.

Physical representation of the emotional mix is done by altering twelve key facial movements (brow raise, lip corner pull, mouth open, and others of that nature) known as the Facial Action Coding System (FACS). These twelve elements combine to express emotion nonverbally with facial expressions. It’s what drives the simulated dot-matrix robot face seen in the image above, and could easily be used to drive a real LED matrix, or servos on an animatronic face.

Much of communication is nonverbal. Humans even weigh nonverbal higher when there’s a mismatch between the content of verbal and nonverbal communication. So, there’s clear value in having robots able to express themselves as such.

Importantly, a realistic and human-like face is entirely unnecessary — something every Star Wars fan already knows. Cartoon eyes and basic sounds are enough to make robots easier to relate to and work with, even if blinking is also important but hard to get just right.

hackaday.com/2026/07/11/to-bui…

Di Corinto presenta Guerra Profonda a RadioRai

È partita Open Ai che ha lanciato la nuova famiglia di Gpt, la 5.6, con versioni pensate per la ricerca avanzata e per l’uso quotidiano. Poi Elon Musk ha risposto con Grok 4.5, il suo modello a costi più bassi. Quindi è toccato ad Anthropic che ha rimesso in pista Claude Fable5, il sistema precedentemente bloccato dalla Casa Bianca per motivi di sicurezza, molto efficace nella scrittura di codice. Infine, Meta, che ha aggiornato il suo Muse Spark, per creare immagini e video su Instagram e Facebook. Insomma, una raffica di novità sull’intelligenza artificiale accaduta in appena 48 ore. E a permettere tutti questi rilasci c’è sempre stato lui, l’occhio vigile del governo americano, che concede o stoppa. Perché ormai la competizione tecnologica non si gioca più solo tra aziende. Ma irrompe nel campo della politica, tra regole, sicurezza e interessi nazionali. Ne parliamo nel nuovo episodio di Eta Beta. Ospite al microfono di Massimo Cerofolini: Arturo Di Corinto, giornalista e autore di Guerra profonda. Hacker, bugie e l’architettura segreta dei nuovi conflitti. Con un’intervista a Sanjay Rodrigues, fondatore di Phenomeal Ai. Regia di Cecilia Mosetti.

raiplaysound.it/audio/2026/07/…

dicorinto.it/guerra-profonda/a…

[Jenny] and I were talking about [Bitluni]’s experiment in scale, where he will take 65,536 cheap microcontrollers, network them all together, and give each one an RGB pixel. From there, antics will surely ensue. Right now, he’s only got 8,192 of them up and running, and already the novel problems and opportunities are rearing their heads.

We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.

Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.

On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.

So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2026/07/11/when-c…