2025 One Hertz Challenge: The Real-Time Clock The VIC-20 Never Had

August 8, 2025 by 6 Comments

Like many early microcomputers, the Commodore VIC-20 did not come with an interna real-time clock built into the system. [David Hunter] has seen fit to rectify that with an add-on module as his entry to the 2025 One Hertz Challenge.

[David]’s project was inspired by a product that Hayes produced in the 1980s, which provided a serial-port based real-time clock solution for computers that lacked one on board. The heart of the project is an Arduino Uno, which itself uses a Dallas DS3231 RTC module to keep accurate time. [David] then drew from an IEC driver developed by [Lars Pontoppidan] for the MM2IEC project. This enables the Arduino to report the time to the VIC-20 via its IEC port.

The project is a neat way to provide a real-time clock source to programs written in Commodore BASIC. It’s also perfectly compatible with the IEC bus, so it can be daisy chained along with printers and disk drives without issue. [David] hasn’t tested it with a Commodore 64, but he suspects it should work just as well on that platform, too.

If you’ve ever wanted to build something clock-based for the VIC-20 but didn’t know how, this is a great piece of hardware to solve that problem. Meanwhile, you might find joy in reading about real-time clock hacks for other systems like the Raspberry Pi. Meanwhile, if you’re working on your own nifty timekeeping projects, don’t hesitate to let us know!

2025 Hackaday One Hertz Challenge

Hackaday Podcast Episode 332: 5 Axes Are Better Than 3, Hacking Your Behavior, And The Man Who Made Models

August 8, 2025 by No comments

Elliot and Dan got together this week for a review of the week’s hacking literature, and there was plenty to discuss. We addressed several burning questions, such as why digital microscopes are so terrible, why computer systems seem to have so much trouble with names, and if a thermal receipt printer can cure ADHD.

We looked at a really slick 5-axis printer that COVID created, a temperature-controlled fermentation setup, and a pseudo-Mellotron powered by a very odd tape recorder. We also learned little about designing 3D printed parts with tight tolerances, stepping a PC power supply up to ludicrous level, and explored a trio of unique entries for the One Hertz Challenge.

And for the Can’t Miss section, we looked at what happens to planes when they get hit by lightning (and how they avoid it), and say goodbye to the man who launched a lot of careers by making model kits.

It was also exciting to learn that the first day of Supercon is Halloween, which means a Friday night sci-fi cosplay party. It’s gonna be lit.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast Episode 332: 5 Axes Are Better Than 3, Hacking Your Behavior, And The Man Who Made Models” →

Talking Robot Uses Typewriter Tech For Mouth

August 8, 2025 by 14 Comments

Many decades ago, IBM engineers developed the typeball. This semi-spherical hunk of metal would become the heart of the Selectric typewriter line. [James Brown] has now leveraged that very concept to create a pivoting mouth mechanism for a robot that appears to talk.

What you’re looking at is a plastic ball with lots of different mouth shapes on it. By pivoting the ball to different angles inside the head of a robot, it’s possible to display different mouth shapes on the face. By swapping mouth shapes rapidly in concert with recorded speech, it’s possible to make the robot appear to be speaking. We don’t get a great look at the mechanism that operates the ball, but Selectric typeball operation is well documented elsewhere if you seek to recreate the idea yourself.

The real benefit of this mechanism is speed. It might not look as fluid as some robots with manually-articulated flexible mouths, but the rapid mouth transitions really help sell the effect because they match the pace of speech. [James] demonstrated the finished product on Mastodon, and it looks great in action.

This isn’t the first time we’ve featured [James Brown]’s work. You may recall he got DOOM running on a tiny LEGO brick a few years back.

Thanks to [J. Peterson] for the tip!

This Week In Security: Perplexity V Cloudflare, GreedyBear, And HashiCorp

August 8, 2025 by 7 Comments

The Internet is fighting over whether robots.txt applies to AI agents. It all started when Cloudflare published a blog post, detailing what the company was seeing from Perplexity crawlers. Of course, automated web crawling is part of how the modern Internet works, and almost immediately after the first web crawler was written, one managed to DoS (Denial of Service) a web site back in 1994. And the robots.txt file was first designed.

Make no mistake, robots.txt on its own is nothing more than a polite request for someone else on the Internet to not index your site. The more aggressive approach is to add rules to a Web Application Firewall (WAF) that detects and blocks a web crawler based on the user-agent string and source IP address. Cloudflare makes the case that Perplexity is not only intentionally ignoring robots.txt, but also actively disguising their webcrawling traffic by using IP addresses outside their normal range for these requests.

This isn’t the first time Perplexity has landed in hot water over their web scraping, AI learning endeavors. But Perplexity has published a blog post, explaining that this is different!

And there’s genuinely an interesting argument to be made,that robots.txt is aimed at indexing and AI training traffic, and that agentic AI requests are a different category. Put simply, perplexity bots ignore robots.txt when a live user asks them to. Is that bad behavior, or what we should expect? This question will have to be settled as AI agents become more common.

Continue reading “This Week In Security: Perplexity V Cloudflare, GreedyBear, And HashiCorp” →

Is It Time To Retire The TP4056?

August 8, 2025 by 30 Comments

The TP4056 is the default charge-controller chip for any maker or hacker working with lithium batteries. And why not? You can get perfectly-functional knockoffs on handy breakout boards from the usual online sources for pennies. Betteridge’s Law aside, [Lefty Maker] thinks that it may well be time to move on from the TP4056 and spends his latest video telling us why, along with promoting an alternative.

His part of choice is another TI chip, the BQ25185. [Lefty] put together his own charge controller board to show off the capabilities of this chip — including variable under- and over-charge protection voltages. Much of his beef with the TP4056 has less to do with that chip than with the cheap charge modules it comes on: when he crows about the lack of mounting holes and proper USB-PD on the knock-off modules, it occurs to us he could have had those features on his board even if he’d used a TP4056.

On the other hand, the flexibility offered by the BQ25185 is great to future-proof projects in case the dominant battery chemistry changes, or you just change your mind about what sort of battery you want to use. Sure, you’d need to swap a few resistors to set new trigger voltages and charging current, but that beats starting from scratch.

[Lefty Maker] also points out some of the advantages to making your own boards rather than relying on cheap modules. Namely, you can make them however you want. From a longer USB port to indicator LEDs and a built-in battery compartment, this charging board is exactly what [Lefty Maker] wants. Given how cheap custom PCBs are these days, it’s not hard to justify rolling your own.

The same cannot be said of genuine TI silicon, however. While the BQ25185 has a few good features that [Lefty Maker] points out in the video, we’re not sure the added price is worth it. Sure, it’s only a couple bucks, but that’s more than a 300% increase!

We’ve seen other projects pushing alternative charge controllers, but for now the TP4056 reigns as the easy option.

Continue reading “Is It Time To Retire The TP4056?” →

Exploring The TRS-80’s Color BASIC’s Random Number Function

August 8, 2025 by 6 Comments

Although these days we get to tap into many sources of entropy to give a pretty good illusion of randomness, home computers back in the 1980s weren’t so lucky. Despite this, their random number generators were good enough for games and such, as demonstrated by the [CoCo Town] YouTube channel.

The CoCo is the nickname for the TRS-80 Color Computer, which despite its name, shares absolutely nothing with the TRS-80. Its BASIC version is called Color BASIC, which like many others was based on Microsoft BASIC, so the video’s description should be valid for many other BASIC versions as well. In the video we’re first taken through a basic summary of what the floating point format is all about, before running through an example of the algorithm used by Color BASIC for its RND function, using a test program written in Color BASIC.

As described in the video, the used algorithm appears to be the linear congruential generator, which is a pseudo-random generator that requires minimal resources from the hardware it runs on. Of course, its main disadvantage is that it will fairly rapidly begin to repeat itself, especially with a limited number of output bits. This makes it a decent choice even today for something like simple game logic where you just want to get some variation without aiming for cryptographically secure levels of randomness.

Continue reading “Exploring The TRS-80’s Color BASIC’s Random Number Function” →

Light Transport And Constructing Images From A Projector’s Point Of View

August 7, 2025 by 6 Comments

Imagine you have a projector pointing at a scene, which you’re photographing with a camera aimed from a different point. Using the techniques of modelling light transport, [okooptics] has shown us how you can capture an image from the projector’s point of view, instead of the camera—and even synthetically light the scene however you might like.

The test scene used for the explanation of the work.

The concept involves capturing data regarding how light is transported from the projector to the scene. This could be achieved by lighting one pixel of the projector at a time while capturing an image with the camera. However, even for a low-resolution projector, of say 256×256 pixels, this would require capturing 65536 individual images, and take a very long time. Instead, [okooptics] explains how the same task can be achieved by using binary coded images with the projector, which allow the same data to be captured using just seventeen exposures.

Once armed with this light transport data, it’s possible to do wild tricks. You can synthetically light the scene, as if the projector were displaying any novel lighting pattern of your choice. You can also construct a simulated photo taken from the projector’s perspective, and even do some rudimentary depth reconstruction. [okooptics] explains this tricky subject well, using visual demonstrations to indicate how it all works.

The work was inspired by the “Dual Photography” paper published at SIGGRAPH some time ago, a conference that continues to produce outrageously interesting work to this day.

Continue reading “Light Transport And Constructing Images From A Projector’s Point Of View” →