Godot’s New Contributing Policy Adds Barriers For AI Slop

Like so many large and popular open source projects these days, the Godot game engine struggles with an influx of pull requests. The situation has become increasingly dire due to the advent of AI-generated code. More specifically, the issue involves the inverse relationship between PR code quality and the number of PRs, which wastes a lot of time on the side of a limited number of (volunteer) reviewers. This has now forced the project to update its contribution policy.

An interesting point raised in the announcement article is that of the demoralizing effect of AI-generated PRs on reviewers. Often the human behind such a PR isn’t interested in being educated, or may even be an automated agent which isn’t capable of productive discussion on pros and cons of certain coding approaches — never mind in becoming a more permanent maintainer for the project.

This problem has led to new rules being instated, which include a ban on autonomous AI agents and vibe coding, a ban on substantial AI generating of code, and a ban on AI-generated text in human-to-human communication. It also codifies the requirement that all PRs are to be reviewed and approved by a human being before merging.

In many ways this new policy is similar to that of the Mesa project, which demands code comprehension on the side of the submitter, although it doesn’t go as far as NetBSD, which just outright treats LLM-generated code as ‘tainted’ due to potential licensing and other concerns. Other projects like the Linux kernel opt to make the human submitter responsible for any AI tool usage by forcing them to declare it.

Meanwhile there are also indications that such ‘AI tool’ usage is reducing useful interactions with open source projects. What the future will bring here remains to be seen, but at least as far as open source projects go these tools are clearly increasingly being banished.

Modern E-Ink Dashboards, Kindle And Otherwise

People have been attempting to turn Kindles into more than e-readers since the first devices came out nearly two decades ago. The e-ink displays are low-power and great for displaying information that doesn’t refresh too often, and with Amazon continuing their trend of bricking their older devices there will be more of these devices available. [Hemant] built a weather dashboard with one of his, but since then had requests for other types of e-reader dashboards and has a guide for making more general-purpose use of an old Kindle.

The first approaches outlined here involve the installation of a dashboard client on the Kindle and pointing it at a server that hosts a PNG image of whatever information needs to be displayed. The client simply displays that image and refreshes it at predetermined intervals. There are a number of options for creating that server as well, including using Home Assistant for those who already have a home automation system deployed. The benefit of using Home Assistant is that it’s much more straightforward to gather data for the dashboards from sensors and other peripherals that are already installed.

Installing a client like this might seem straightforward, and it can be, provided that the Kindle involved is jailbroken or capable of being jailbroken. An Amazon update recently broke many modern devices’ ability to execute the jailbreak, so not every Kindle can do this anymore. But [Hemant] goes into detail about this and also outlines some methods for using generic e-ink displays instead, and also dives into the hardware and software behind building a server to host the dashboard images for those without Home Assistant already running. It’s a great overview for those who have always wanted something like this but never knew where to start.

Porting The Legend Of Zelda: Twilight Princess To The 3DS

After the Nintendo 3DS saw various Nintendo 64-era titles like Super Mario 64Ocarina of Time and Majora’s Mask ported to it, there was a lot of speculation that the GameCube/Wii title of Twilight Princess might soon make its way to this handheld gaming system too. Unfortunately no official release happened, but with the recently decompiled source code of the game in hand, [Tobi] set out to see whether such a port was realistic.

Compared to the somewhat scruffy Nintendo DS and DSi handhelds, the 3DS hardware is decidedly more beefy, both in the processor department as well as in terms of RAM with 128 MB of FCRAM (Fast Cycle DRAM). This puts it within batting distance of the game’s original two consoles.

In the video the current status of the porting effort is demonstrated, with the game actually running surprisingly well despite the early state of the porting project. Even with the rather impressive graphical glitches and overall instability that one would expect at this early stage, the game is essentially already playable.

As noted by [Tobi], the next steps will involve fixing these bugs and above all actually optimizing the so far quick-and-sloppy port. Along with the possibility of actually having Twilight Princess rendered in 3D, this is a rather exciting development that demonstrates that an official version of the game for the 3DS would have been easily possible.

Continue reading “Porting The Legend Of Zelda: Twilight Princess To The 3DS”

Chain-of-Thought Spoofing Targets Reasoning AI Models

Researchers [Charles Ye], [Jasmine Cui], and [Dylan Hadfield-Menell] have shown that AI Large Language Models (LLMs) can fail to correctly distinguish between different instruction sources because they prioritize writing style over metadata tags, and this role confusion leads to a powerful attack called CoT (Chain of Thought) Forgery. We’ll explain exactly how it works after a bit of background review.

Prompt injection was where “getting an LLM to do something it shouldn’t” started by exploiting the fact that LLMs communicate like people, but are much more obedient. For a while, simply telling an LLM “ignore all previous instructions and <do something funny>” yielded results no matter how transparently dumb the instructions were, and the reason it worked at all was because LLMs do not have separate data and instruction streams; it’s all one big lump of input. It’s up to the model to sort legit instructions from untrusted, user-provided data. One step towards mitigating this was the addition of roles. Continue reading “Chain-of-Thought Spoofing Targets Reasoning AI Models”

scantron

Bubbles, Belts, And Bulbs: How The Scantron Works

Many of us remember back in our school days taking tests and filling out answers on a Scantron sheet, those long rows of A, B, C, D, and E that had to be filled in with a #2 pencil. Ever wonder why it needed a #2 pencil, or what the point of using a Scantron was at all? That question is answered in the latest video from [SimonRetro], where he takes a look at the Scantron and how it works.

One of the more interesting things about the Scantron is that it’s such a standalone device. No software needed, no keypad to mess with just two rocker switches. The on/off switch is also the way you tell it to forget the last answer sheet and allow you to program in a new test. Upon booting, you feed in a Scantron sheet with some specific boxes filled in, and then it’s programmed and ready to take in and grade all the students’ answers. Opening up the Scantron reveals it’s pretty interesting inside: one control board with early-’90s-era chips. There’s also a lightbulb (no LEDs) shining through the six reading sections of the card, as well as an arrangement of belts and motors to move the card through the machine. The printer is a seven-pin printer used in conjunction with a pair of ink rollers to print out the results on the cards.

[SimonRetro] also went ahead and tried different ways to mark the sheets including pens, Sharpies, colored pencils, and different thicknesses of pencils besides the #2 to see which would and wouldn’t work in the Scantron. Thanks [SimonRetro] for exploring this machine from many of our childhoods and sharing its inner workings. Be sure to check out some of our other reverse engineering articles that explore how classic devices work.

Continue reading “Bubbles, Belts, And Bulbs: How The Scantron Works”

DIY SI5351 Radio Tunes In SW, MW, And More

There are plenty of radios you can buy that pick up MW and SW bands if that’s what you’re into. Or, you can follow [mircemk]’s example, and whip one up yourself instead.

The build employs an ESP32 as the brains of the operation. It’s hooked up to a rotary encoder and a small colour TFT screen, which displays an old-school style tuning dial for choosing the desired frequency. This setup is paired with an Si5351—a capable clock generator chip that can deliver just about any frequency from <8KHz up to 150+ MHz on command. There’s naturally a bunch of supporting analog hardware for the radio end of things, plus a NE612 mixer IC and a PAM8403 class D audio amplifier board, hooked up to a small 0.25W speaker for audio output. [mircemk] has set up the rig to act as a simple radio set, or, with the flick of a switch, it can be configured for SDR use with an attached computer.

It’s a handsome build, and one that likely proves a pleasant way to browse the MW and SW bands on a rainy afternoon. We’ve looked at other hardware in this category before, too. Video after the break.

Continue reading “DIY SI5351 Radio Tunes In SW, MW, And More”

An EInk, ESP32-based Game Boy

This is one of those projects that was both inspired and made possible by the absolute embarrassment of dev boards available to the modern hacker. In this case, the dev board was the M5Stack PaperS3, which as the name implies combines an ESP32-S3 with an e-ink panel. [Wenting Zhang] picked one up and was immediately inspired to try and make an e-ink Game Boy.

The M5Stack PaperS3 made this project possible by exposing the display with row/column control — parallel, some would call it, as opposed to the usual serial interface of SPI. That allowed [Wenting] to work some of the same e-ink magic he perfected on his Modos monitors to allow partial refresh at up to 60 Hz. That the ESP32-S3 is capable of emulating a Game Boy while driving the screen should surprise no one, since it can emulate an MSX while outputting VGA or even Windows 95 on a 386. In this case, he’s basing the actual Game Boy emulation on Crank Boy.

Of course the e-ink screen on the M5Stack is far larger and has a much higher resolution than what the Game Boy shipped with, which lets him implement touch controls and scale the image up 3X so he can fake a couple of shades of grayscale while actually outputting black and white. Even better, if he was actually playing this thing on the regular, once the high-refresh portion of the screen starts to wear out, he can flip the orientation and keep gaming on the virtually-unrefreshed control portion of the screen — doubling the lifetime of the system, something many of you raised as a concern when we last looked at a his e-ink monitor project.

The only real shortcoming of this hack is the sound. With one-bit beeps coming out of the M5Stack buzzer, it’s got nothing on Nintendo’s hardware. Of course, that’s partially down to using the hardware as-is. With the addition of an I2S sound chip like the one used in the MOD player project we featured recently, you’d just need to squeeze out enough processor cycles to make this sound as good as it looks.

Continue reading “An EInk, ESP32-based Game Boy”