TechyMagThings

Since we last covered the way that the Linux Kernel project has been dealing with the influx of code created using LLM-based coding assistants, all the way back in April, things have changed a lot, with most recently the Linux maintainers deciding to fully drop the requirement to mark LLM-assisted commits with the Assisted-by tag.

While not a fully uncontroversial decision – as also reported by Phoronix – with key maintainers already having made this decision it seems certain to proceed. This is not the only change made fairly recently, with a ‘Sashiko’ bot introduced that is supposed to handle code reviews.

In a July LKML post [Linus Torvalds] defends this decision, with a follow-up post in August by [Jakub Kicinski] it being stated that budget has been secured for using Meta’s LLMs, using said LLM-based resources for reviewing patches, as well as creating and editing commit messages. As noted by [Jakub] they’re running multiple frontier models on each patch to try and weed out confabulations.

Whether this will prove to be the right decision remains to be seen. Whereas most open source projects have firmly banished or heavily curtailed LLM-based contributions on slop, copyright as well as licensing grounds, the Linux Kernel project may be an interesting experiment in what the outcome of the exact opposite approach will be.

If you want to play old Commodore games, there are C-64 emulators available for just about any platform– but most of them are so high level, they’re really meant for just that: playing games. [antirez] has a different goal with his c64-hw-sim project— it’s a lower-level emulation that simulates every chip and every connection on an ASSY 250407 motherboard, and all the chips on it, too. Ever wondered what happens when a specific chip is missing, or a random pin is shorted to ground or forced high? You can do all that in software, with no risk of harming antique hardware.

While that might be a fun bit of faffing about for a certain sort electronics sadist, the real utility is to learn about the hardware, both in the abstract and to help you troubleshoot a board you might have. It’s likely that many given failure modes reproduce the same effects– lots of things can knock out the display output, for example–but at least if you’ve reproduced a flaw in software you can try testing the hardware to see if that’s the cause of your problem. Assuming the simulation covers your hardware issue, anyway.

There’s cycle-accurate chip emulation for the processor, CIAs, SID and VIC-II via code by [Andre Weissflog], a.k.a. [flooh]. Meanwhile analog circuitry in the video, audio and power sections are not simulated so not everything fault will be replicable here. Still, it might be a neat tool– just don’t try and run any games on it, because even on high-end modern hardware it only runs at about one-third speed. That’s fast enough for diagnostics, but not so much for Maniac Mansion, never mind Elite. 

Speaking of Elite, did you know the source– both of the port and the original– is available with comments? If you want an emulator you can play, you can get it on everything from microcontrollers like Teensy to your personal computer.

Thanks to [Salvatore] for the tip!

Do you want to get an AI agent to do something to an iPhone? You could try and jailbreak the device and do some heavy software hacking, or… you could grab a microcontroller off the shelf and have it do the hard work. [Henry Yuan] explains how to achieve this with an ESP32.

The first step is getting an AI agent access to the current state of the phone screen—which [Henry] achieves with AirPlay screen mirroring and UxPlay. A Gstreamer pipeline is then used to feed the screen as a JPEG stream to the AI agent of your choice. Then comes control, which is achieved by an ESP32-S3 acting as a USB-HID device, emulating both USB mouse and keyboard. With iOS AssistiveTouch enabled, this gives the agent control over inputs to the device. From there, it’s up to the AI agent to figure out the actions to make to achieve the desired behavior, which is obviously very use-case specific.

It might sound a little convoluted, but this approach has benefits. There’s no requirement to have an Apple Developer Account, or XCode, or a Macintosh at all. You can just get your agent tinkering away on the phone without any of that fussy overhead. We’ve featured some other great iPhone hacks of late, as well. Video after the break.

Those of us who grew up in the 70s and 80s might be familiar with the Atari 2600 console and its now relatively unrecognizable (by modern standards) controller with only a single button and stiff whole-hand joystick. By comparison, the Steam Deck has somewhere around 24 buttons and two joysticks depending on how they are counted. But even the Atari might be providing more user inputs than are really necessary for quality gaming. Take a look at the Dinoboy, a handheld console with only a single button.

Part of what makes this system work is that it’s playing the classic dinosaur jumping game first included in Google Chrome which loads when the browser can’t connect to the Internet, and the user’s single input was the space bar. In this case, the handheld has its single button where the user’s thumb naturally rests. The console itself is in two parts, hinged where the button is placed. When unfolded, the top half reveals a wide screen and the bottom half is held by the hand. The screen supports two color formats, a black and white style and another which replicates the dot matrix display of the original Game Boy.

The small handheld console has another trick up its sleeve too. [Paul], the system’s creator, built it as a way to stop doomscrolling so along with having this quick-deploying game on hand, there’s also an NFC tag hidden near the hinge which, when swiped passed a phone, also turns that phone’s airplane mode on. It’s a double-whammy of removing the gamer from the dark patterns and algorithms dominating the mainstream Internet. And, this isn’t [Paul]’s only dinosaur jumper console either. We recently featured a similar (but much larger) build of his housed in a classic arcade-style cabinet.

Generally the DVB-S and -S2 standards require a satellite somewhere in Earth orbit to provide a signal to receive, but you can also transmit your own DVB-S2 stream with any RF transmitter if you’re so inclined. Courtesy of recent breakthroughs in using the RF hardware of the ESP32 on a raw level, [SP8ESA] has created the ESP32-DATV project using which you can broadcast a DVB-S2 signal using an ESP32-C3.

While a host PC side application handles the heavy lifting of turning the input video signal into a DVB-S(2) compliant signal, it is the ESP32-C3 that prepares the samples for transmission before sending them off to its RF block, with no external hardware needed.

If this brings to mind the idea of using an off-the-shelf DVB-S2 receiver to play back the signal, the frequency range for DVB-S2 is 10.7 – 12.7 GHz, while the ESP32-C3 is limited to roughly 2.4 GHz courtesy of it targeting only 2.4 GHz Wi-Fi and Bluetooth signals.

Targeting frequencies as low as 100 MHz might be possible with some hardware tweaks, but for higher frequencies the ESP32’s RF block might need a complete overhaul.

Thanks to [ftg] for the tip.

Slow refresh, ghosting and low-contrast — wait, are we talking about passive matrix LCDs, or e-paper displays? That might be why e-paper Game Boy emulators are a thing: the limitations of the black-on-grey e-paper screens remind us of the grey-on-green LCDs Nintendo used in the 80s. In this case [Bo Made It] made it out of a Waveshare ESP32-S3-ePaper-1.54, and got 30 FPS from it. 

Now, regular readers might be thinking, “So, we’ve seen the 60 FPS e-paper monitor, how is this special?” It’s a fair question. The answer is that [Bo] is doing this on a randomly chosen dev board with a built in wavetable e-paper controller, rather than the bare inputs that allowed the [Wenting Zhang]’s project to work. On the other hand, [Bo] does credit [Wenting], particularly his e-ink PaperBoy project, with directly inspiring both the project and his implementation.

Again, the big difference is going through the blob of the controller, but it turns out you can still address individual pixels through it. [Bo] gave each pixel a ‘budget’ for up to 8 pulses it depending on how much it needs to change, speeding things up immensely. Our favorite part is how he achieves the Game Boy’s 4-bit greyscale by, in effect, deliberately ghosting the display. Pixels aren’t driven long enough to fully flip them if they’re going only one shade lighter or darker. This complicated matters, since going from black to ‘white’ now takes longer than ‘white’ to the next darker grey, and the exact timing needs to be worked out for each color transition. Getting that timing right took a lot of calibration, and we like how he used video to help automate the process.

That process is still ongoing, so there’s no GitHub link yet. [Bo] will open source everything when it’s ready, and we look forward to it. We also look forward to the PDA-like device he’s going to be using this display driver for. If this all sounds similar to a recent 20 FPS e-paper hack, that’s because it’s the same underlying technology.

We’ll give you three guesses what the most important bits of silicon in [LouD]’s USBSID-Pico are, and two don’t count. Yes, there’s a Raspberry Pi Pico, and a pair of the unforgettable SID chips from MOS– the sound chip of the C64, the die that launched a thousand chiptunes. Well, unless you build it with a hardware SID replacement, but the goal of this device is to get SIDs hooked up to modern hardware.

To that end, USBSID-Pico can be controlled via USB– obviously– in the form of CDC/WebUSB/WebSerial but also MIDI, and even ASID, which is a specific protocol for streaming SID register data over MIDI. You might be wondering the point, since surely you can get cycle-accurate SID emulation on an RP2040, right? Well, not everyone agrees that cycle-accurate emulation is accurate enough; like the people who swear by the subtle distortions tube amplifiers introduce into the sound, some say the chip’s own inaccuracies give the sound out of the physical device a unique vibe emulators don’t match. That’s a fight for others to litigate; we just appreciate the work that went into getting these old sound chips talking to modern hardware, and getting the project certified as Open Source Hardware.

This combination of old sound and new microcontroller makes the USBSID-Pico a good entry for our ongoing retrocomputing contest, particularly the retro-modern category. Just be aware of PAL and NTSC differences with these old chips, or your beeps and boops might be out of tune. They haven’t made them in decades, but there are more than a few modern replacements for the MOS 6581.