Cloned Memory Module Fixes Broken Scopemeter

June 17, 2021 by Dan Maloney 9 Comments

Finding broken test gear and fixing it up to work again is a time-honored tradition among hackers. If you’re lucky, that eBay buy will end up being DOA because of a popped fuse or a few bad capacitors, and a little work with snips and a soldering iron will earn you a nice piece of test gear and bragging rights to boot.

Some repairs, though, are in a class by themselves, like this memory module transplant for a digital scopemeter. The story began some time ago when [FeedbackLoop] picked up a small lot of broken Fluke 199C scopemeters from eBay. They were listed as “parts only”, which is never a good sign, and indeed the meters were in various states of disassembly and incompleteness.

The subject of the video below was missing several important bits, like a battery and a power connector, but most critically, its memory module. Luckily, the other meter had a good module, making reverse engineering possible. That effort started with liberating the two RAM chips and two flash chips, all of which were in BGA packages, from the PCB. From there each chip went into a memory programmer to read its image, which was then written to new chips. The chip-free board was duplicated — a non-trivial task for a six-layer PCB — and new ones ordered. After soldering on the programmed chips and a few passives, the module was plugged in, making the meter as good as new.

While we love them all, it’s clear that there are many camps of test gear collectors. You’ve got your Fluke fans, your H-P aficionados, the deep-pocketed Keithley crowd — but everyone loves Tektronix.

Continue reading “Cloned Memory Module Fixes Broken Scopemeter” →

Four Servo Fingers Play Simon Better Than You Ever Could

May 10, 2021 by Dan Maloney 10 Comments

Remember Simon? We sure do. Simon — as in “Simon says…” — from the leading edge of electronic games in the 1970s, which used four buttons, colored lights, and simple tones as the basis for a memory game. Players had to remember the specific sequence of lights and replay the pattern in order to advance to the next round. It was surprisingly addictive, at least for the era.

For those who never quite got into the Simon groove, fear not — the classic game has now been fully automated. While there were plenty of approaches that could have taken to interfacing to the game, [ido roseman] went with the obvious — and best, in our opinion — technique and simulated a human player’s finger presses with servo-controlled arms. Each arm carries a light-dependent resistor that registers the light coming from the key it’s poised above; the sequence of lights is sensed and recorded by an Arduino, which then drives the servo fingers’ replay attack. The fingers aren’t exactly snappy in their response, which might cause problems — if we recall correctly, Simon is somewhat picky about the speed with which the keys are pressed, at least at higher levels of play.

On the whole, we really like this one, not least for the nostalgia factor. We’ve had a lot of recreations of Simon over the years, including a Dance Dance Revolution version, but few attempts to automate it. And a crazy idea: wouldn’t it be fun to replace the replay attack with a machine learning system that figures out how to play Simon by randomly pressing keys and observing the results?

Continue reading “Four Servo Fingers Play Simon Better Than You Ever Could” →

Embedded Rust Hack Chat

May 10, 2021 by Dan Maloney 18 Comments

Join us on Wednesday, May 12 at noon Pacific for the Embedded Rust Hack Chat with James Munns!

Programming languages, like fashion, are very much a matter of personal taste. Professional developers often don’t have much say in which language they’ll use for a given project, either for legacy or team reasons, but if they did have a choice, they’d probably choose the language that works best with the way they think. Some languages just “fit” different brains better than others, and when everything is in sync between language and developer, code just seems to flow effortlessly through the keyboard and onto the screen.

One language that consistently scores at the top of developers’ “most loved” lists is Rust. For a language that started as a personal project and has only existed for a little more than a decade, that’s really saying something. The emphasis Rust puts on safety and performance probably has a lot to do with that. And thanks to its safe concurrency, its memory safety, and its interoperability with C and other languages, Rust has made considerable in-roads with the embedded development community.

To learn more about Rust in embedded systems, James Munns will stop by the Hack Chat. James is an embedded systems engineer, with a history of working on software for a wide range of systems, including safety-critical avionics, and rapidly prototyped IoT systems. He’s a founding member of the Rust Embedded Working Group, as well as a founder of Ferrous Systems, a consultancy focused on systems development in Rust, with a specialty in embedded systems development. James also used to write for Hackaday, so he must be a pretty cool guy. So swing by the Hack Chat and find out where Rust might be able to help you out with your next embedded project.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 12 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “Embedded Rust Hack Chat” →

Homebrew Relay Computer Looks Like It Could Be A Commercial Product

January 19, 2021 by Dan Maloney 21 Comments

You may not have noticed, but we here at Hackaday really love our clicky stuff. Clicky mechanical keyboards, unnecessarily noisy flip-dot displays, and pretty much anything made with a lot of relays — they all grab our attention, in more ways than one. So it’s with no small surprise that we appear to have entirely missed perhaps the clickiest build of all: a fully operational 8-bit computer using nothing but relays.

What’s even more amazing about our failure to find and feature [Paul Law]’s excellent work is that he has been at it for the better part of a decade now. The first post on his very detailed and very well-crafted blog describing the build dates from 2013, when he was just testing LEDs in the arithmetic-logic unit (ALU). Since then, [Paul] has made incredible progress, building module after module, each containing a small portion of the computer’s functionality. The modules plug into card cages with backplanes to connect them, and the whole thing lives in an enclosure made from aluminum extrusion and glossy black panels for a truly sleek look. The computer is incredibly compact for something that uses 400+ DPDT relays to do its thinking.

In addition to the blog, [Paul] has a criminally undersubscribed YouTube channel with a quite recent series going over the computer in depth. We included the overall tour below, but you should really check out the rest of the videos to appreciate how much work went into this build. We’ve seen relay computers ranging in size from single-board to just plain ludicrous, but this one really takes the prize for fit and finish as well as functionality.

Continue reading “Homebrew Relay Computer Looks Like It Could Be A Commercial Product” →

Squeezing Every Bit From An ATMega

December 26, 2020 by Bryan Cockfield 16 Comments

While the ATMega328 is “mega” for a microcontroller, it’s still a fairly limited platform. It has plenty of I/O and working memory for most tasks, but this Battleship game that [thorlancaster328] has put together really stretches the capabilities of this tiny chip. Normally a Battleship game wouldn’t be that complicated, but this one has audio, an LED display, and can also play a fine rendition of Nyan Cat to boot, which really puts the Atmel chip through its paces.

The audio is played through a 512-byte buffer and an interrupt triggers the microcontroller when to fill the buffer while it works on the other processes. The 12×12 LED display is also fed through a shift register triggered by the same interrupt as the audio, and since the build uses so many shift registers the microcontroller can actually output four separate displays (two players, each with a dispaly for shots and one for ships). It will also eventually support a player-vs-computer mode for the battleship game, and also has a mode where it plays Nyan cat just to demonstrate its own capabilities.

We’re pretty impressed with the amount of work this small microcontroller is doing, largely thanks to code optimization from its creator [thorlancaster328]. If there’s enough interest he also says he will provide the source code too. Until then, be sure to check out this other way of pushing a small microcontroller to its limits.

Thanks to [Thinkerer] for the tip!

Visualizing Magnetic Memory With Core 64

November 11, 2020 by Adam Zeloof 17 Comments

For the vast majority of us, computer memory is a somewhat abstract idea. Whether you’re declaring a variable in Python or setting a register in Verilog, the data goes — somewhere — and the rest really isn’t your problem. You may have deliberately chosen the exact address to write to, but its not like you can glance at a stick of RAM and see the data. And you almost certainly can’t rewrite it by hand. (If you can do either of those things, let us know.)

These limitations must have bothered [Andy Geppert], because he set out to bring computer memory into the tangible (or at least, visible) world with his interactive memory badge Core 64. [Andy] has gone through a few different iterations, but essentially Core 64 is an 8×8 grid of woven core memory, which stores each bit via magnetic polarization, with a field of LEDs behind it that allow you to visualize what’s stored. The real beauty of this setup is that it it can be used to display 64 pixel graphics. Better yet — a bit can be rewritten by introducing a magnetic field at the wire junction. In other words, throw a magnet on a stick into the mix and you have yourself a tiny drawing tablet!

This isn’t the first time we’ve seen cool experiments with core memory, and not even the first time we’ve seen [Andy] use it to make something awesome, but it really illuminates how the technology works. Being able to not only see memory being written but to manually write to it makes it all so much realer, somehow.

Continue reading “Visualizing Magnetic Memory With Core 64” →

“Brain In A Vat” 6502

November 3, 2020 by Bryan Cockfield 39 Comments

The 6502 was a revolutionary processor for its time. Offered at a small fraction of the cost of other processors available when it was released, it became adopted in such iconic computers at the Atari 2600, the Apple II, the NES, and the Commodore 64. For that reason it’s still extremely popular among retrocomputing enthusiasts who will often go to great lengths to restore these computers or build them from scratch. [jamesbowman] had an idea to build a 6502-based computer with the processor only, leaving the rest of the computer up to an FPGA.

He describes the system as a “brain in a vat” since a real 6502 is used as the “brain” and all other functions are passed off to the FPGA. In his build he uses an FPGA board with built-in graphics abilities, but the truly interesting part of this build is how the FPGA handles memory. If a particular value is placed on the data bus of the 6502, it loops forever through the entire memory and executes all of the instructions it finds. This saved a lot of time getting this system up and running, and he is able to demonstrate it by showing a waveform on the video output of the device.

Of course you can take an FPGA and emulate an entire computer based on a 6502, but using the actual silicon in a build like this really ensures that the user can learn and understand the hardware involved without some of the other tedium of doing things such as converting old video signals to HDMI for example. It’s a great take on retrocomputing that we expect to see more of in the future.