Hackaday editors Mike Szczys and Elliot Williams sort through the hacks you might have missed over the past seven days. In FPGA hacking news, there’s a ton of work being done on a newly discovered FPGA dev board. Kristina has a new column on input devices, kicking it off with tongue-actuated controllers. We wax philosophical about what data you need to backup and what you should let go. Plus Audacity is helping tune up CNC machines, copper tape is the prototyper’s friend, and fans of Open should take note of this laptop project.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
In the modern age, when you hear “component tester” you probably think of one of those cheap microcontroller-based devices that can identify components and provide basic measurements on an LCD screen. However, in the past, these were usually simple circuits that generated an XY scope plot. The trace would allow an experienced operator to identify components and read a few key parameters. [Thomas] tears down an old Hameg device that uses this principle in the video below.
The unit is in a nice enclosure and has a feature that controls the amount of current the unit uses in the excitation signal. It plugs into the wall, and you can connect the component under test with either test leads or a socket. The output, of course, is a pair of BNCs for the scope’s X and Y inputs.
We always thought the older console games looked way better back in the day on old CRTs than now on a modern digital display. [Stephen Walters] thinks so too, and goes into extensive detail in a lengthy YouTube video about the pros and cons of CRT vs digital, which was totally worth an hour of our time. But are CRTs necessary for retro gaming?
The story starts with [Stephen] trying to score a decent CRT from the usual avenue and failing to find anything worth looking at. The first taste of a CRT display came for free. Left looking lonely at the roadside, [Stephen] spotted it whilst driving home. This was a tiny 13″ Sanyo DS13320, which, when tested, looked disappointing, with a blurry image and missing edges. Later, they acquired a few more displays: a Pansonic PV-C2060, an Emerson EWF2004A and a splendid-looking Sony KV24FS120. Some were inadequate in various ways, lacking stereo sound and component input options.
A large video section discusses the reasons for the early TV standards. US displays (and many others using NTSC) were designed for 525 scan lines, of which 480 were generally visible. These displays were interlaced, drawing alternating fields of odd and even line numbers, and early TV programs and NTSC DVDs were formatted in this fashion. Early gaming consoles such as the NES and SNES, however, were intended for 240p (‘p’ for progressive) content, which means they do not interlace and send out a blank line every other scan line. [Stephen] goes into extensive detail about how 240p content was never intended to be viewed on a modern, sharp display but was intended to be filtered by the analogue nature of the CRT, or at least its less-than-ideal connectivity. Specific titles even used dithering to create the illusion of smooth gradients, which honestly look terrible on a pixel-sharp digital display. We know the differences in signal bandwidth and distortion of the various analog connection standards affect the visuals. Though RGB and component video may be the top two standards for quality, games were likely intended to be viewed via the cheaper and more common composite cable route.
Smartphones have replaced a desktop calculator for most folks these days, but sometimes that tactility is just what you need to get the mathematical juices flowing. Why not spruce up the scientific calculator of yore with the wonders of modern microcontrollers?
While you won’t be able to use Sci-Calc on a standardized test, this classy calculator will let you do some pretty cool things while clacking on its mechanical choc switches. Is it a calculator? Obviously. Is it an Arduboy-compatible device that can play simple games like your TI-84? Yes. Is it also a macropad and ESP32 dev board? Why not? If that isn’t enough, it’s also takes both standard and RPN inputs.
[Shao Duan] has really made this device clean and the menu system that rewrites main.bin based on the program selection is very clever. Escape writes main.bin back into the ROM from the SD card so you can select another application. A few classic games have already been ported, and the process looks fairly straightforward for any of your own favorites.
If you’re hankering for more mathy inputs, checkout the Mathboard or the MCM/70 from 1974.
The Raspberry Pi has been around for over a decade now in various forms, and we’ve become plenty familiar with the Pi Pico in the last three years as well. Still, these devices have a great deal of potential if you know where to look. If you wade beyond the official datasheets, you might even find more than you expected.
Kumar is presently a software engineer with Google, having previously worked for Analog Devices earlier in his career. But more than that, Kumar has been doing a deep dive into maxing out the capabilities of the Raspberry Pi and the Pi Pico, and shared some great findings in an excellent talk at the 2023 Hackaday Supercon.
Battery management is a tedious but necessary problem that becomes more of a hassle with lithium-ion technology. As we’re all very aware, such batteries need a bit of care to be utilized safely, and as such, a huge plethora of ICs are available to perform the relevant duties. Hackaday.IO user [Erik] clearly spent some time dropping down the same old set of ICs to manage a battery in their applications, so they created a drop-in castellated PCB to manage all this.
The 3DConnexion Space mouse is an interesting device but heavily patent-protected, of course. This seems to just egg people on to reproduce it using other technologies than the optical pickup system the original device uses. [John Crombie] had a crack at building one using linear Hall effect sensors and magnets as the detection mechanism to good — well — effect.
Using the SS49E linear Hall effect sensor in pairs on four sides of a square, the setup proves quite straightforward. Above the fixed sensor plate is a moveable magnet plate centred by a set of springs. The magnets are aligned equidistant between each sensor pair such that each sensor will report an equal mid-range signal with zero mechanical displacement. With some simple maths, inputs due to displacements in-plane (i.e., left-right or up-down) can be resolved by looking at how pairs compare to each other. Rotations around the vertical axis are also determined in this manner.
Tilting inputs or vertical movements are resolved by looking at the absolute values of groups or all sensors. You can read more about this by looking at the project’s GitHub page, which also shows how the to assemble the device, with all the CAD sources for those who want to modify it. There’s also a detour to using 3D-printed flexures instead of springs, although that has yet to prove functional.
On the electronics and interfacing side of things, [John] utilises the Arduino pro micro for its copious analog inputs and USB functionality. A nice feature of this board is that it’s based on the ATMega32U4, which can quickly implement USB client devices, such as game controllers, keyboards, and mice. The USB controller has been tweaked by adjusting the USB PID and VID values to identify it as a SpaceMouse Pro Wireless operating in cabled mode. This tricks the 3DConnexion drivers, allowing all the integrations into CAD tools to work out of the box.