It’s been an ongoing issue for years now. People who buy video games, especially physical copies, expect to be able to play that game at their leisure, no matter how old their console gets. This used to be a no-brainer: think about the SNES or Genesis/Mega Drive from the late 80s and early 90s. You can still buy one today and play the games without any issues. Not so with many modern, internet-connected games that rely on communication with servers the publishers own, whether or not the online features are necessary for gameplay. Stop Killing Games is a new initiative in the EU and worldwide to get enough valid petition signatures to force the issue to be brought up in parliaments all over the world, including the EU Parliament.

An increasing number of videogames are sold as goods, but designed to be completely unplayable for everyone as soon as support ends. The legality of this practice is untested worldwide, and many governments do not have clear laws regarding these actions. It is our goal to have authorities examine this behavior and hopefully end it, as it is an assault on both consumer rights and preservation of media.

StopKillingGames.com

Why now? Well, Ubisoft recently killed a popular videogame called The Crew by taking down the servers that support the game. Without these servers, the game is completely useless. France and many other European countries have strong consumer protection laws which, in theory, should prevent companies from pulling stunts like this, but this particular situation has never been tested in court. Besides this, the group are also petitioning governments around the world, including France (where Ubisoft is based), Germany, Canada, the UK, the US, Australia, and Brazil, and also options for anywhere else in the EU/world.

If you’re a gamer, and especially if you play video games which use online components, it’s definitely worth reading through their website. The FAQ section in particular answers a lot of questions. In any case, we wish them luck as the preservation of media is a very important topic!

[Thanks to Jori for the tip!]

There have been many computers that played a little jingle to greet you upon booting. The NEC PC-9800 is a famous example, though almost all the Macintosh computers played either the soothing “booting” chord or sometimes the Sad Mac “error” chord. And of course, consoles have long played music on startup, with the original PlayStation boot music heralding a whole new era of video games. But modern machines don’t do anything, except maybe a single beep if you’re lucky. So why not pop in this M.2 card (JP) and bring some quirky flair to your PC?

While this particular card is aimed at the Japanese market and specifically evokes the PC-9800, we hope to see some hackers creating projects bringing other custom boot sounds to laptops and PCs around the rest of the world! A simple microcontroller, DAC, speaker and flash storage for the waveform would be all that’s required. It could even be capacitively coupled into the system’s sound output for some extra nerd points. You could pull the ultimate prank and have your friend’s laptop play the opening notes to “Never Gonna Give You Up” upon boot. Or you could have your favourite hacker movie quote play – “I can trace her physical location by looking at the binary!”. Brilliant!

In the meantime, if you want one of these cards, you’ll likely have to use a Japanese mail forwarding service as the cards are only available from Japanese retailer Kadenken — though for only ¥2880, or just under $20 USD, which is a great deal.

[via Techspot]

We all love a nice strip or grid of addressable LEDs. It can add flair or an artistic touch to many projects, and it can make gaming computers look extra 1337. However, providing enough current to a long strip of addressable LEDs can sometimes be difficult. Often a separate voltage rail is needed to supply enough juice. At the same time, continually sending out data to animate them can often use 100% of the microcontroller’s CPU power, especially if the serial bus is being bit-banged. A crash or badly timed interrupt can leave the system in a weird state and sometimes with the LEDs not displaying the correct colours. Or you might just want to enter a power-saving mode from time to time on your main MCU? Well, the BAPPR is designed to address all of these problems.

[TheMariday] created the BAPPR and made it fully open-source. It’s a switch-mode power supply that can accept anywhere from 7 V to 17 V and converts it into a strong 5 V rail for typical addressable LEDs. It also has a “smart” mode where it monitors the data line going to the LEDs to see if there is activity. If for some reason the system stops sending data, the BAPPR can intervene and shut off the power to the LEDs, which can help prevent strange colour combinations from being displayed while the system recovers. Once data starts flowing again, power is restored and the light party can resume.

This is accomplished by directly rectifying and filtering the actual data line itself. As long as it remains active, enough charge will remain on C4 to keep the output alive. While this is a very simple and effective solution, it’s possible that a system might get stuck outputting VO_H and this would keep the system enabled. Adding a series coupling capacitor could be a way to change the behaviour if desired — that’s the beauty of open hardware! At the same time, it’s very simple to disable the LED system simply by outputting a low level on the data line, which allows quick and efficient power saving.

It’s easy to adjust the parameters of the “smart” mode by simply picking different values for the input resistor, storage capacitor, and draining resistor. This can either have it activate more quickly upon resumption of data, or you can increase the amount of time it waits before shutting the output off when the data line goes to zero. If you’ve got a project with lots of addressable LED strips, having local power supplies like the BAPPR allows you to increase the efficiency of the entire system by sending a higher voltage, perhaps 12 V – 18 V, to each module, reducing losses over potentially long cable runs.

[Hugh] has been going back through episodes of the Hackaday podcast, and Elliot mentioned in episode 67 that it can often be inspiring to go back through the archives of Hackaday to find ideas for new projects. Well, he did just that and came across a single-pixel camera made using an infrared photodiode. He decided to try and hack together his own single-pixel camera, but this time on the cheap and using an ever simpler component – a photoresistor!

His description of the project tickled me – “I’ve used an ESP32, MicroPython, two servos, a peanut butter jar lid, a toilet paper roll, a paper towel roll, magnets and scrap wood for this version.” That’s certainly a much simpler bill of materials than the original (which was written up by Hackaday way back in 2015), which used a nice metal frame to hold everything together. However, there’s absolutely nothing wrong with improvising with things you happen to have to hand.

In this case, the sensor is mounted at the back of a paper towel tube, with black tape covering the front and a tiny pinhole poked in the tape to act as the aperture. Similarly to the original, the sensor is scanned over the scene in an XY altitude/azimuth pattern to capture the samples one at a time. It takes just under eight minutes to capture 8100 “pixels” in a 90×90 grid. The servos are driven using a PCA9685 PWM/Servo driver, which makes motor control a lot easier. An important lesson [Hugh] learned during construction was that weak power supplies can cause all sorts of issues when motors or servos are involved. He had been encountering uneven rotation and random halting, but as soon as a beefier power supply was attached everything worked smoothly.

[Hugh] used a much more powerful ESP32 to do the actual gathering of the analog data, which is then sent over a serial port to a Python processing engine which uses Pandas, numpy and matplotlib to do the bulk of the image processing. The resulting processed photo is very recognizable, considering the differences in linearity and sensitivity between a photoresistor and the infrared photodiode used in the original project! It really is incredible what you can do with a few spare parts, some random construction materials, and a little bit of creativity.

The Motorola 6809, released in 1978, was the follow-up to their 6800 from four years earlier. It’s a powerful little chip with many 16-bit features, although it’s an 8-bit micro at heart. Despite its great improvements over the 6800, and even technical superiority over the Z80 and 6502 (hardware multiply, for example!), it never reached the same levels of success that those chips did. However, there are still some famous systems, such as the TRS-80 Colour Computer, which utilized the chip and are still being hacked on today. [Ted] is clearly a fan of the 6809, as he used a Teensy 4.1 to create a cycle-exact, drop-in 6809 emulator!

A small interposer board rearranges the Teensy pinout to match the 6809, as well as translating voltage levels from 3.3V to 5V. With careful design, the Teensy matches the cycle diagrams in the Motorola datasheet precisely, and so should be able to run any applications written for the chip! A great test was booting Extended Colour BASIC for the TRS-80 CoCo 2 and running some test BASIC programs. Any issues with opcode decoding or timing would certainly be exposed while running an interpreted language like BASIC. After this successful test, it was time to let the Teensy’s ARM Cortex-M7 rip and see what it could do.

Simply removing the dummy cycles between opcode fetches (necessary in the original chip) led to an immediate speedup of almost 100%. For many computers that used the 6809, this effectively doubles the clock speed from a typical ~1MHz to 2MHz, which is a noticeable and welcome speedup. Mirroring the ROM and RAM inside the Teensy (apparently overclocked to 800MHz!) led to a ridiculous 800% improvement, making many applications and games essentially unusable – though probably breaking the record for the world’s fastest CoCo in the process.

The real power of in-circuit emulators is for debugging both software and hardware. In-circuit emulators were essential tools back in the day of 8- and even 16-/32-bit microprocessors. Being able to control the processor from an external machine allows you to view the internal state of the chip while stepping a single cycle at a time if needed. This can help expose issues with hardware surrounding the MCU, although many engineers would also use a large, multi-channel logic analyzer at the same time. Common emulators back then would consist of a large box full of many boards packed with circuitry, all connected to a card inserted into an IBM PC or similar. This could also remove the slow process of burning EPROMs and then having to wait for them to be UV erased during prototyping, as many emulators would include SRAM to act as ROM.

All in all, we think [Ted] did a terrific job and we are hoping to see the project expand, possibly with PC software to control the emulator and show the internal state, just like back in the 80s!

[Scott] has a neat little closet in his carport that acts as a shelter and rest area for their outdoor cat, Rory. She has a bed and food and water, so when she’s outside on an adventure she has a place to eat and drink and nap in case her humans aren’t available to let her back in. However, [Scott] recently noticed that they seemed to be going through a lot of food, and they couldn’t figure out where it was going. Kitty wasn’t growing a potbelly, so something else was eating the food.

So [Scott] rolled up his sleeves and hacked together an OpenCV project with a FLIR Boson to try and catch the thief. To reduce the amount of footage to go through, the system would only capture video when it detected movement or a large change in the scene. It would then take snapshots, timestamp them, and optionally record a feed of the video. [Scott] originally started writing the system in Python, but it couldn’t keep up and was causing frames to be dropped when motion was detected. Eventually, he re-wrote the prototype in C++ which of course resulted in much better performance!

It didn’t take long to nab the thief — actually, thieves! It seemed quite a few different local animals had discovered Rory’s shelter and were helping themselves to her food. How rude! The first night detected a few different visitors. First, Rory’s local “boyfriend” stopped by to have a snack. Then within half an hour, an opossum (or possibly a small raccoon?) scarfed down what food was left. And within fifteen minutes of that visitor, a raccoon stopped by and was disappointed all the food was gone. Then, early in the morning. Rory arrives and is aghast that all her food is missing — again!

After analyzing all the footage, the solution, for now, is to feed Rory wet food twice a day and put just a little bit of kibble in her closet bowl in the morning for her to snack on throughout the day. In the future, [Scott] might use an RFID door to keep others out (though raccoons can be very smart and might be able to rip the door open), or possibly even something as simple as a magnetic collar and a Hall effect sensor to open the door or dispense food. Either way, the important thing is Rory is a happy cat and OpenCV rocks!

Ticketmaster is having a rough time lately. Recently, a hacker named [Conduition] managed to reverse-engineer their new “safe” electronic ticket system. Of course, they also had the recent breach where more than half a billion accounts had personal and financial data leaked without any indication of whether or not the data was fully encrypted. But we’re going to focus on the former, as it’s more technically interesting.

Ticketmaster’s stated goals for the new SafeTix system — which requires the use of a smartphone app — was to reduce fraud and ticket scalping. Essentially, you purchase a ticket using their app, and some data is downloaded to your phone which generates a rotating barcode every 15 seconds. When [Conduition] arrived at the venue, cell and WiFi service was totally swamped by everyone trying to load their barcode tickets. After many worried minutes (and presumably a few choice words) [Conduition] managed to get a cell signal long enough to update the barcode, and was able to enter, albeit with a large contingent of similarly annoyed fans trying to enter with their legally purchased tickets.

The real kicker here is that since the barcode rotates every 15 seconds, printing it out simply isn’t an option. This alienates anyone who doesn’t have a smartphone, which includes individuals who may not be able to physically operate one. So the problem isn’t simply that users were being forced to install yet another application on their device, but that the system reduces accessibility to entertainment. [Conduition] was dismayed and frustrated with this, and so the reverse-engineering effort began.

Decoding the barcode was actually quite simple. It is a standard PDF417 barcode, which contains a long Base64 string, two six-digit numbers, and a Unix timestamp all concatenated together with colons. The only parts of the string that seemed to change over time were the two six-digit numbers. Hmm, can we think of a common technology which generates six-digit numbers that update seemingly randomly on a fixed cycle? Of course — it’s just a Time-based one-time password (TOTP), the technology behind 2FA authenticator apps!

So where were the secret keys coming from? TOTP only requires two things: a static secret string, and the current time. [Conduition] checked the communication with the Ticketmaster servers and found a particularly interesting request that returned JSON-formatted data, inside which were of course the two secret keys. One seems to be unique per customer, and the other per ticket.

The Ticketmaster API documentation only briefly mentions this feature, but they do state that customers must refresh their ticket barcodes within 20 hours before an event starts. These two pieces of information were enough to allow [Conduition] to whip up a simple app that accepts the secret keys and the ticket ID and pops out the rotating barcodes. This would allow you to sell your tickets in the 20 hours prior to an event, or even just give them away to friends without having to give their personal data to Ticketmaster and allow you to take back control of your tickets.

Thanks to [Chrischi] for the tip!

[ZXGuesser] has pulled off a true feat of Meccano engineering: building a Meccano Hellschreiber machine. The design is a close replica of the original Siemens Feld-Hell machine as documented here. What is Hellschreiber, you might ask? It’s a very neat method of sending written messages over the air by synchronizing a printing wheel on the receiving end with pulses generated on the transmitter. By quickly moving the print wheel up and down, arbitrary figures can be printed out. If you want to learn more about Hellschreiber, check out this excellent Hackaday post from almost a decade ago!

The Mastodon thread linked above goes into more detail about the difficulty in building this behemoth — and the slight regret of sticking with the authentic QWERTZ keyboard layout! In order to use the Hellschreiber mode, you have to keep up a steady rhythm of typing at about 2.5 characters per second, otherwise, the receiving end will see randomly spaced gaps between each letter. So while having to type at a steady speed [ZXGuesser] also had to work with a slightly different keyboard layout. Despite this difficulty, some very good quality output was generated!

Incredibly, the output looks just like the output from the original, century-old design. We think this is an absolutely incredible accomplishment, and we hope [ZXGuesser] doesn’t follow through on disassembling this amazing replica — or if they do, we hope it’s documented well enough for others to try their hand at it!

Thanks [BB] for the tip!