Reverse Engineering Keeps Early Ford EVs Rolling

With all the EV hype in the air, you’d be forgiven for thinking electric vehicles are something new. But of course, EVs go way, way back, to the early 19th century by some reckonings. More recently but still pretty old-school were Ford’s Think line of NEVs, or neighborhood electric vehicles. These were commercially available in the early 2000s, and something like 7,200 of the slightly souped-up golf carts made it into retirement communities and gated neighborhoods.

But as Think aficionado [Hagan Walker] relates, the Achille’s heel of these quirky EVs was its instrument cluster, which had a nasty habit of going bad and taking the whole vehicle down with it, sometimes in flames. So he undertook the effort of completely reverse engineering the original cluster, with the goal of building a plug-in replacement.

The reverse engineering effort itself is pretty interesting, and worth a watch. The microcontroller seems to be the primary point of failure on the cluster, probably getting fried by some stray transients. Luckily, the microcontroller is still available, and swapping it out is pretty easy thanks to chunky early-2000s SMD components. Programming the MCU, however, is a little tricky. [Hagan] extracted the code from a working cluster and created a hex file, making it easy to flash the new MCU. He has a bunch of other videos, too, covering everything from basic diagnostics to lithium battery swaps for the original golf cart batteries that powered the vehicle.

True, there weren’t many of these EVs made, and fewer still are on the road today. But they’re not without their charm, and keeping the ones that are still around from becoming lawn ornaments — or worse — seems like a noble effort.

Continue reading “Reverse Engineering Keeps Early Ford EVs Rolling”

The IBM PC: Brainchild Of A Misfit

We’ve read a number of histories of the IBM PC and lived through that time, too. But we enjoyed [Gareth Edwards’] perspective in a post entitled The Misfit who Built the IBM PC. The titular character is Don Estridge, a decidedly atypical IBM employee who was instrumental in creating the personal computer market as we know it.

It’s not that IBM invented the personal computer — far from it. But the birth of the PC brought personal computers to the mainstream, especially in offices, and — much to IBM’s chagrin — opened up the market for people to make add-on cards for printers, videos, and other accessories.

IBM was a computer juggernaut in the late 1970s. Its divisions were the size of other companies, and some have compared it to a collection of mafia families. The company was heavily invested in big computers, and management was convinced that personal computing was, at most, an avenue to video games and most likely a fad.

Known as a conservative company, the PC project drew from a number of corporate misfits who had been technically successful but often punished for coloring outside the lines. They developed a prototype. The post quotes one of the people involved as saying, “The system would do two things. It would draw an absolutely beautiful picture of a nude lady, and it would show a picture of a rocket ship blasting off the screen. We decided to show the Management Committee the rocket ship.” Wise choice.

That’s just the kind of tidbit in this post, and if you have any interest in computer history of the 1980s, you’ll definitely want to check it out. Estridge died in 1985, so he didn’t get to see much of the result of the market he opened up. Of course, there were many other players who appear in this story. The PC has many parents, as you might expect.

We’ve done our own recounting of this story. However, we tend to obsess more over the internals.

Hackaday Podcast Episode 274: Capstan Robots, Avionics Of Uncertain Purpose, And What The Frack?

What do capstans, direct conversion receivers, and fracking have in common? They were all topics Hackaday editors Elliot Williams and Al Williams found fascinating this week. If you wonder what makes an electrical ground a ground, or what a theodolite is, you should check it out.

This week, the hacks came fast and furious. Capstans, instead of gears, work well for 3D-printed mechanisms, a PI Pico can directly receive radio signals, and the guys saw a number of teardowns and reverse engineering triumphs. You’ll also find solid-state heat pumps, flying wings, spectroscopy, and more.

The can’t miss articles this week? Learn about theodolites, a surveying feat from ancient Greece, and how fracking works.

Check out the links below if you want to follow along, and as always, tell us what we’ve mispronounced — or any other thoughts on the episode — in the comments!

Download an archival copy for your personal collection.

Continue reading “Hackaday Podcast Episode 274: Capstan Robots, Avionics Of Uncertain Purpose, And What The Frack?”

Comparing X86 And 68000 In An FPGA

[Michael Kohn] started programming on the Motorola 68000 architecture and then, for work reasons, moved over to the Intel x86 and was not exactly pleased by the latter chip’s perceived shortcomings. In the ’80s, the 68000 was a very popular chip, powering everything from personal computers to arcade machines, and looking at its architecture and ease of programming, you can see why this was.

Fast-forward a few years, and [Michael] decided to implement both cores in an FPGA to compare real applications, you know, for science. As an extra bonus, he also compares the performance of a minimal RISC-V implementation on the same hardware, taken from an earlier RISC-V project (which you should also check out !)

Utilizing their ‘Java Grinder’ application (also pretty awesome, especially the retro console support), a simple Mandelbrot fractal generator was used as a non-trivial workload to produce binaries for each architecture, and the result was timed. Unsurprisingly, for CISC architectures, the 68000 and x86 code sizes were practically identical and significantly smaller than the equivalent RISC-V. Still, looking at the execution times, the 68000 beat the x86 hands down, with the newer RISC-V speeding along to take pole position. [Michael] admits that these implementations are minimal, with no pipelining, so they could be sped up a little.

Also, it’s not a totally fair race. As you’ll note from the RISC-V implementation, there was a custom RISC-V instruction implemented to perform the Mandelbrot generator’s iterator. This computes the complex operation Z = Z2 + C, which, as fellow fractal nerds will know, is where a Mandelbrot generator spends nearly all the compute time. We suspect that’s the real reason RISC-V came out on top.

If actual hardware is more your cup of tea, you could build a minimal 68k system pretty easily, provided you can find the chips. The current ubiquitous x86 architecture, as odd as it started out, is here to stay for the foreseeable future, so you’d just better get comfortable with it!

Continue reading “Comparing X86 And 68000 In An FPGA”

This Week In Security: Recall, Modem Mysteries, And Flipping Pages

Microsoft is racing to get into the AI game as part of Windows 11 on ARM, calling it Copilot+. It’s an odd decision, but clearly aimed at competing with the Apple M series of MacBooks. Our focus of interest today is Recall, a Copilot+ feature that not only has some security problems, but also triggers a sort of visceral response from regular people: My computer is spying on me? Eww.

Yes, it really sort of is. Recall is a scheme to take screen shots of the computer display every few seconds, run them through character recognition, and store the screenshots and results in a database on the local machine hard drive. There are ways this could be useful. Can’t remember what website had that recipe you saw? Want to revisit a now-deleted tweet? Is your Google-fu failing you to find a news story you read last week? Recall saw it, and Recall remembers. But what else did Recall see? Every video you watched, ever website you visited, and probably some passwords and usernames you typed in.

Continue reading “This Week In Security: Recall, Modem Mysteries, And Flipping Pages”

Close-up of the mod installed into the HDMI switch, tapping the IR receiver

Interfacing A Cheap HDMI Switch With Home Assistant

You know the feeling of having just created a perfect setup for your hacker lab? Sometimes, there’s just this missing piece in the puzzle that requires you to do a small hack, and those are the most tempting. [maxime borges] has such a perfect setup that involves a HDMI 4:2 switch, and he brings us a write-up on integrating that HDMI switch into Home Assistant through emulating an infrared receiver’s signals.

overview picture of the HDMI switch, with the mod installed

The HDMI switch is equipped with an infrared sensor as the only means of controlling it, so naturally, that was the path chosen for interfacing the ESP32 put inside the switch. Fortunately, Home Assistant provides the means to both receive and output IR signals, so after capturing all the codes produced by the IR remote, parsing their meaning, then turning them into a Home Assistant configuration, [maxime] got HDMI input switching to happen from the comfort of his phone.

We get the Home Assistant config snippets right there in the blog post — if you’ve been looking for a HDMI switch for your hacker lair, now you have one model to look out for in particular. Of course, you could roll your own HDMI switch, and if you’re looking for references, we’ve covered a good few hacks doing that as part of building a KVM.

A3 Audio: The Open Source 3D Audio Control System

Sometimes, startups fail due to technical problems or a lack of interest from potential investors and fail to gain development traction. This latter case appears to be the issue befalling A3 Audio. So, the developers have done the next best thing, made the project open source, and are actively looking for more people to pitch in. So what is it? The project is centered around the idea of spatial audio or 3D audio. The system allows ‘audio motion’ to be captured, mixed and replayed, all the while synchronized to the music. At least that’s as much as we can figure out from the documentation!

The system is made up of three main pieces of hardware. The first part is the core (or server), which is essentially a Linux PC running an OSC (Open Sound Control) server. The second part is a ‘motion sampler’, which inputs motion into the server. Lastly, there is a Mixer, which communicates using the OSC protocol (over Ethernet) to allow pre-mixing of spatial samples and deployment of samples onto the audio outputs. In addition to its core duties, the ‘core’ also manages effects and speaker handling.

The motion module is based around a Raspberry Pi 4 and a Teensy microcontroller, with a 7-inch touchscreen display for user input and oodles of NeoPixels for blinky feedback on the button matrix. The mixer module seems simpler, using just a Teensy for interfacing the UI components.

We don’t see many 3D audio projects, but this neat implementation of a beam-forming microphone phased array sure looks interesting.