Vintage Programmer Gets Modern Chip Adapter

January 8, 2019 by 8 Comments

While trying to revive a Donkey Kong Jr arcade board, [Jelmer Bruijn] found himself in the market for an EPROM programmer and became the proud owner of a 1990’s era Dataman S4. Despite its age, it’s a fairly nice tool which allows you to read and write a laundry list of different EPROM types, all without being tied to a computer. The only catch is that a few types of chips need an adapter to work in the Dataman S4, some of which are unsurprisingly no longer available.

After some above and beyond support from the current crew at Dataman set him on the right track, [Jelmer] decided to try his hand at reverse engineering how the old adapters worked so he could build his own. His ultimate goal was to read 40 pin EPROMs on the 32 pin Dataman S4, but in the end he says the information he gathered should be applicable for building other adapters if you ever find yourself in need of such things.

As you might expect, there’s a bit more to the project than a simple pin adapter. [Jelmer] assumed some kind of shift register or latching arrangement would be required to make up for the shortage of pins on the Dataman S4’s ZIF socket. It was just a matter of figuring out how it all went together.

Luckily, [Jelmer] found that the programmer would happily attempt to perform operations on a 16 bit EPROM even though no adapter was physically present. This gave him a chance to probe around with a logic analyzer to figure out what it was trying to accomplish. The trick turned out to be splitting the 16 bit bus into two 8 bit buses which are requested sequentially.

With careful observation, close studying of 16 bit chip datasheets, and much brow furrowing, he was eventually able to come up a design that used five 74xx573 latches and put a schematic together in Eagle. There were a few kinks to iron out when the boards finally arrived, but ultimately the design worked on the first try. [Jelmer] says the same technique should work for 42 pin EPROMs, but as Dataman still actually sell adapters for those he decided not to supply schematics for it.

[Jelmer] tells us that he was inspired to send this success story our way after reading how our very own [Elliot Williams] took the long away around to erase a couple UV EPROMs recently While this isn’t the first time we’ve seen somebody have to hack support for 16 bit EPROMs into their programmer, it’s good to see that the manufacturer at least had the customer’s back in this case.

Bad Apple!! Via The Arduino Mega

January 8, 2019 by 13 Comments

The Arduino Mega is a useful tool for the maker. Generally, once one has come up with plans for blinking LEDs that require more IO than is available on the Arduino Uno, one graduates to the Mega and goes for broke. However, it’s not typically what we’d consider as our first choice for video work. [Stephane] begs to differ, and coded this Bad Apple!! demo for the Arduino Mega 2560.

For those unfamiliar, video on the Arduino is actually somewhat of a solved problem – merely requiring a pair of resistors and some nifty code. The real meat of this hack is the video storage itself. It’s been done before, but by streaming data off an SD card or serial link. [Stephane] was determined to store everything on the Arduino itself, and thus the hack begun. Video data is stored as 1 bit per pixel, as it’s a simple black and white video as per the original inspiration. LZ77 compression was used to cram the data down without requiring too much RAM, which is a limited resource on the Mega. It’s video only, as the Mega is tapped out handling 3 minutes and 39 seconds of video storage, but future work may include syncing with a second Arduino to deliver the soundtrack.

It’s a hack that shows off [Stephane]’s ability to get impressive performance out of limited platforms. We’ve seen this before, with his excellent Star Fox port to the Arduboy. Video after the break.

Continue reading “Bad Apple!! Via The Arduino Mega” →

Irène Joliot-Curie And Artificial Radioactivity

January 8, 2019 by 41 Comments

When Marie and Pierre Curie discovered the natural radioactive elements polonium and radium, they did something truly remarkable– they uncovered an entirely new property of matter. The Curies’ work was the key to unlocking the mysteries of the atom, which was previously thought to be indivisible. Their research opened the door to nuclear medicine and clean energy, and it also led to the development of nuclear weapons.

Irène Joliot-Curie, her husband Frédéric, and many of their contemporaries were completely against the use of nuclear science as a weapon. They risked their lives to guard their work from governments hell-bent on destruction, and most of them, Irène included, ultimately sacrificed their health and longevity for the good of society. Continue reading “Irène Joliot-Curie And Artificial Radioactivity” →

An Electronic Love Letter To The Wind

January 8, 2019 by 9 Comments

Home weather stations are a great way for hackers and makers to put their skills to practical use. After all, who wants to hear the current conditions for the whole city when they could setup their own station which drills that information down to their very own street? Such a setup doesn’t need to be any more complex than a temperature sensor wired up to a microcontroller, but then not all of us are quite the weather fanatic that [Richard] clearly is.

The system he’s built to monitor the wind over his home is, to put it mildly, incredible. We might not all share the obsession [Richard] apparently has with the wind, but we can certainly respect the thought and design that went into this comprehensive system. From his scratch built anemometer to the various ways he’s come up with to display the collected environmental data throughout his home, if this build doesn’t inspire you to hack together your own weather station then nothing will.

At the heart of the system is the anemometer itself, which makes use of several scavenged parts such as the bottom halves of plastic Easter eggs as wind cups. The cups spin on a short length of M5 threaded rod inside of a 635ZZ bearing, which ultimately rotates a “light chopper” placed between a red LED and a OPL550A optical sensor. In a particularly nice touch, [Richard] has even included a few power resistors arranged around the moving parts to use as a heater which keeps the device from freezing up when the temperature drops. The sensor creates eight digital pulses per revolution, and feeds data into the base station though a 30 meter (98 feet) cable.

From there, the base station uses an ESP8266 to upload wind and temperature data to ThingSpeak and Weather Underground to be viewed through their respective web interfaces and applications. The project really could have ended here and still been impressive in its own right, but the station also includes 433 MHz and NRF24L01 transmitters to send the data to the other display devices which [Richard] has designed.

The 433 MHZ display is built into the frame of a lantern, and shows the current time and temperature on an LED readout as well as historical wind and temperature graphs on a 2.2 inch ILI9341 TFT screen which [Richard] has rotated into a portrait layout. There’s a red light on top that blinks whenever a signal is received to show that the system is working, and even a touch sensor which can be used to turn off the TFT screen at a tap if you’re not interested in seeing the full charts.

The other display, which [Richard] calls the “picture frame” utilizes a dizzying array of single LEDs, a handful of digital LED readouts, and even an OLED screen for good measure. They all work together to show the current wind speed as well the averages for the past day in three hour segments. As this display features a real time display of current wind conditions and averages for as short a period of two minutes, it uses the NRF24L01 receiver to get data from the base station at a rate of 3 Hz.

In the past we’ve seen 3D printed weather stations, and of course some pretty simple affairs using little more than an ESP8266 board and some sensors. But few have ever put so much thought into how to present the collected data to the user. If you’re serious about knowing what it’s like outside the confines of your bunker, [Richard] has got some tricks to show you.

Continue reading “An Electronic Love Letter To The Wind” →

Goodbye Chevy Volt, The Perfect Car For A Future That Never Was

January 8, 2019 by 164 Comments

A month ago General Motors announced plans to wind down production of several under-performers. At the forefront of news coverage on this are the consequences facing factories making those cars, and the people who work there. The human factor associated with the closing of these plants is real. But there is also another milestone marked by the cancellation of the Volt. Here at Hackaday, we choose to memorialize the soon-to-be-departed Chevrolet Volt. An obituary buried in corporate euphemisms is a whimper of an end for what was once their technological flagship car of the future.

Continue reading “Goodbye Chevy Volt, The Perfect Car For A Future That Never Was” →

Being An SPI Slave Can Be Trickier Than It Appears

January 8, 2019 by 10 Comments

Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.

The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.

But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.

Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.

Arduino Fights Fire With… Water?

January 8, 2019 by 3 Comments

We don’t think we’d want to trust our fire safety to a robot carrying a few ounces of water, but as a demonstration or science project, [Tinker Guru’s] firefighting robot was an entertaining answer to the question: “What do I do with that flame sensor that came in the big box of Arduino sensors I bought from China?” You can see a video of the device below.

You can see, it is a pretty standard two-wheel robot with the drive wheels to the rear and a skid plate up front. There are a flame sensor and a water pump up forward, as well. You can probably guess, the device notices a flame and rushes to squirt water on it.

Continue reading “Arduino Fights Fire With… Water?” →