Open A Portal To An NES Emulator

The Portal games were revolutionary not only for their puzzle-based, narrative-driven gameplay, but also for their unique physics engine, which let players open portals anywhere and conserve momentum and direction through them. They’re widely regarded as some of the best video games ever made, but even beyond that they have some extra features that aren’t talked about as much. Namely, there are a number of level editors and mods that allow the in-game components to be used to build things like logic gates and computers, and this project goes even further by building a working NES emulator, all within Portal 2.

The main limitation here is that Portal 2 can only support a certain number of in-game objects without crashing, far lower than what would be needed to directly emulate NES hardware. The creator of the project, [PortalRunner], instead turned to Squirrel, the Portal 2 scripting language, and set about porting an existing NES emulator called smolnes to this scripting language. This is easier said than done, as everything in the code needs to be converted eight bits and then all of the pointers in smolnes need to be converted to use arrays, since Squirrel doesn’t support pointers at all. As can be easily imagined, this led to a number of bugs that needed to be sorted out before the game would run at all.

For those interested in code golfing, porting, or cross-compatibility, this project is a master class not only in the intricacies of the Portal 2 scripting language but in the way the NES behaves as well, not to mention the coding skill needed to recognize unique behaviors of the C language and the Squirrel scripting language. But eventually [PortalRunner] is able to get Super Mario Bros. running in Portal 2, albeit with low resolution and frame rate. Since we heard you like games within games, someone else put DOOM inside DOOM so you can DOOM while you DOOM.

Continue reading “Open A Portal To An NES Emulator”

How A DIY Chicken Coop Door Opener Went From Simple To Complex

How hard could it be to make a chicken coop door that can be configured to open and close automatically using a straightforward interface? That’s the question that [Jeff Sandberg] set out with, after three years of using a more basic off-the-shelf unit that offered no remote access nor a convenient user interface. The use case for [Jeff] was rather straightforward: the door would be open during the day and closed at night to keep the hens safely inside the coop.

The commercial solution offered an RTC-backed programmable interface as well as a light sensor, but the latter wasn’t always reliable in inclement weather and making simple changes to the programming when e.g. the hens had to stay inside a day due to work on the yard, was much more complicated than needed, plus had to be done on the spot. The new system would solve all these ills.

That said, the existing door mechanism was doing a fine job and could be kept. This just left making a new box with electronics to control it, starting with an ESP32C3 with the ESPHome firmware that is hooked into the local Home Assistant system, along with a motor to lift and lower the door and with magnetic contact sensors.

So far so easy. The hard part came with the installation, which involved trenching to the hen house for mains power, repairing the damage from this, and troubleshooting a power issue that turned out to be due to a dodgy power adapter. The payoff is that now the chicken coop is also part of the smart home and their owner never has to trudge through a soggy garden again to adjust the programming on a dim LC display with far too few buttons.

Mousa rotary dial and circuit

Adapting An Old Rotary Dial For Digital Applications

Today in old school nostalgia our tipster [Clint Jay] wrote in to let us know about this rotary dial.

If you’re a young whippersnapper you might never have seen a rotary dial. These things were commonly used on telephones back in the day, and they were notoriously slow to use. The way they work is that they generate a number of pulses corresponding to the number you want to dial in. One pulse for 1, two pulses for 2, and so on, up to nine pulses for 9, then ten pulses for 0.

We see circuits like this here at Hackaday from time to time. In fact, commonly we see them implemented as USB keyboards, such as in Rotary Dial Becomes USB Keyboard and Rotary Dialer Becomes Numeric Keypad.

Continue reading “Adapting An Old Rotary Dial For Digital Applications”

Taking A One Handed Keyboard To The Next Level

When a wrist mounted keyboard floated past in the Hackaday feed, a mental image surfaced, perhaps something like a Blackberry keyboard mounted on a wrist cuff, maybe with some kind of display. It’s impressive indeed then to open the link and see [AdamLeBlanc]’s Schist01. It’s a wrist mounted keyboard, but with its bracket curving in front of the had to support a custom ergonomic chording keyboard, it’s definitely a break from the norm.

The wrist mount has clearly taken a lot of thought, and despite looking something like the arm of a Star Trek Borg, appears comfortable. It’s extremely adjustable, and can be demounted into several different parts. Meanwhile the keyboard itself has been formed to his hand by a trial and error process involving keycaps and a clay model. there’s even a thumb-operable touchpad.

We like this peripheral a lot, for the huge attention to detail that has gone into its design, for its boldness, and because we can’t help seeing ourselves using it as the input device for a futuristic head-mounted display. For now though we don’t have any futuristic silver clothing in the wardrobe, so that will have to wait. If you’d like to see more, there’s a video.

Continue reading “Taking A One Handed Keyboard To The Next Level”

Attack Of The Beepy Clones

In the Blackberry-keyboard-based project lineage story last week, I covered how a series of open-source projects turned into Beepy, a cool Linux PDA with a lively community. To me, it’s yet another demonstration of power that open-source holds, and more importantly, it shows how even a small pet project of yours could cause big moves in the hardware world, provided you publish it – just ask [JoeN], [WoodWorkeR] and [arturo182].

The journey didn’t end there. For all its benefits, Beepy had some flaws to take care of, some board-killing flaws, even. The 5 V boost regulator was never intended for 4.7 V input it gets when charger is connected, and would occasionally cook itself. A charging current resistor was undersized, leading people to either bodge resistors onto their Beepy boards, or have their battery charge for 30 hours until full. A power path diode was undersized, too, and has burned out on more than a few devices. Also, Beepy’s feature package left things to be desired.

Beepy never made it beyond v1. If I had to guess, partially because of BB Q20 keyboard sourcing troubles, but also definitely some sort of loss of interest. Which is a shame, as the plans v1.5 of the hardware were pretty exciting. In the meantime, other players decided to take up the mantle – here’s a tale of three projects.

Continue reading “Attack Of The Beepy Clones”

Cassette Data Storage From The 1970s

When home computers first appeared, disk drives were an expensive rarity. Consumers weren’t likely to be interested in punch cards or paper tape, but most people did have consumer-grade audio cassette recorders. There were a few attempts at storing data on tapes, which, in theory, is simple enough. But, practically, cheap audio recorders are far from perfect, which can complicate the situation.

A conference in Kansas City settled on a standard design, and the “Kansas City standard” tape format appeared. In a recent video, [Igor Brichkov] attempts to work with the format using 555s and op amps — the same way computers back in the day might have done it. Check out the video below to learn more.

These days, it would be dead simple to digitize audio and process it to recover data. The 1970s were a different time. The KC standard used frequency shift method with 2.4 kHz tones standing in for ones, and 1.2 kHz tones were zeros. The bit length was equal (at 300 baud), so a one had 8 cycles and a zero had 4 cycles. There were other mundane details like a start bit, a minimum stop bit, and the fact that the least significant bit was first.

The real world makes these things iffy. Stretched tape, varying motor speeds, and tape dropouts can all change things. The format makes it possible to detect the tones and then feed the output to a UART that you might use for a serial port.

There were many schemes. The one in the video uses an op-amp to square up the signal to a digital output. The digital pulses feed to a pair of 555s made to re-trigger during fast input trains but not during slower input trains. If that doesn’t make sense, watch the video!

The KC standard shows up all over the place. We’ve even used it to hide secret messages in our podcast.

Continue reading “Cassette Data Storage From The 1970s”

This Week In Security: The Localhost Bypass, Reflections, And X

Facebook and Yandex have been caught performing user-hostile tracking. This sort of makes today just another Friday, but this is a bit special. This time, it’s Local Mess. OK, it’s an attack with a dorky name, but very clever. The short explanation is that web sites can open connections to localhost. And on Android, apps can be listening to those ports, allowing web pages to talk to apps.

That may not sound too terrible, but there’s a couple things to be aware of. First, Android (and iOS) apps are sandboxed — intentionally making it difficult for one app to talk to another, except in ways approved by the OS maker. The browser is similarly sandboxed away from the apps. This is a security boundary, but it is especially an important security boundary when the user is in incognito mode.

The tracking Pixel is important to explain here. This is a snippet of code, that puts an invisible image on a website, and as a result allows the tracker to run JavaScript in your browser in the context of that site. Facebook is famous for this, but is not the only advertising service that tracks users in this way. If you’ve searched for an item on one site, and then suddenly been bombarded with ads for that item on other sites, you’ve been tracked by the pixel.

This is most useful when a user is logged in, but on a mobile device, the user is much more likely to be logged in on an app and not the browser. The constant pressure for more and better data led to a novel and completely unethical solution. On Android, applications with permission to access the Internet can listen on localhost (127.0.0.1) on unprivileged ports, those above 1024.

Facebook abused this quirk by opening a WebRTC connection to localhost, to one of the ports the Facebook app was listening on. This triggers an SDP connection to localhost, which starts by sending a STUN packet, a UDP tool for NAT traversal. Packed into that STUN packet is the contents of a Facebook Cookie, which the Facebook app happily forwards up to Facebook. The browser also sends that cookie to Facebook when loading the pixel, and boom Facebook knows what website you’re on. Even if you’re not logged in, or incognito mode is turned on.

Yandex has been doing something similar since 2017, though with a different, simpler mechanism. Rather than call localhost directly, Yandex just sets aside yandexmetrica.com for this purpose, with the domain pointing to 127.0.0.1. This was just used to open an HTTP connection to the native Yandex apps, which passed the data up to Yandex over HTTPS. Meta apps were first seen using this trick in September 2024, though it’s very possible it was in use earlier.

Both companies have ceased since this report was released. What’s interesting is that this is a flagrant violation of GDPR and CCPA, and will likely lead to record-setting fines, at least for Facebook.

Continue reading “This Week In Security: The Localhost Bypass, Reflections, And X”