Some people love Amazon, while others think it has become too big and invasive. But you have to admit, they build gigantic and apparently reliable systems. Interestingly, they recently released a library of white papers from their senior staff called the Builder’s Library.
According to their blog post:
The Amazon Builders’ Library is a collection of living articles that take readers under the hood of how Amazon architects, releases, and operates the software underpinning Amazon.com and AWS. The Builders’ Library articles are written by Amazon’s senior technical leaders and engineers, covering topics across architecture, software delivery, and operations. For example, readers can see how Amazon automates software delivery to achieve over 150 million deployments a year or how Amazon’s engineers implement principles such as shuffle sharding to build resilient systems that are highly available and fault tolerant.
The Amazon Builders’ Library will continue to be updated with new content going forward.
Inkjet printers are cheap to buy, but expensive to run. Replacement cartridges can easily cost double the price of the hardware itself, leading many to decry the technology entirely. However, the hackers of the world have the problem licked – enter the continuous ink system.
[cprossu] wanted an affordable color printing solution for the hackerspace. A cheap printer was sourced from a thrift store. The model chosen was selected for its lack of cartridge DRM and the availability of kits on eBay for conversion to a continuous ink system. This involves running large refillable tanks of ink instead of small individual cartridges which must be thrown away when empty.
[cprossu] discusses both the challenges you’ll likely face in a general build, as well as the specific work required to handle the conversion on an Epson Artisan 725. There’s also excessive label-maker abuse, which always brings a smile to our face. It’s a conversion well worth considering if you find yourself regularly purchasing expensive cartridges. We’ve even seen similar builds as far back as 2009, right from the ground up!
You’ve probably seen a few of these miniature arcade games online or in big box retailers: for $20 USD or so you get scaled-down version of a classic arcade cabinet, perfect for a desk toy or to throw up on a shelf as part of your gaming collection. Like any good Hackaday reader, you were probably curious about what makes them tick. Thanks to [wrongbaud], we don’t have to wonder anymore.
Over the course of several blog posts, [wrongbaud] walks readers through the hardware and software used in a few of these miniature games. For example, the Rampage cabinet is using a so-called “NES on a Chip” along with a SPI flash chip to hold the ROM, while Mortal Kombat is using a Genesis emulation solution and parallel flash. It wouldn’t be interesting if they didn’t throw you a few curves now and again, right?
But these are more than simple teardowns. Once [wrongbaud] gives an overview of the hardware, the next step is reading the respective flash storage and trying to make sense of the dumped data. These sort of games generally reuse the hardware among a number of titles, so by isolating where the game ROM is and replacing it, they can be made to play other games without hardware modification. Here, this capability is demonstrated by replacing the ROM data for Rampage with Yoshi’s Cookie. Naturally it’s one of those things that’s easier said than done, but it’s an interesting proof of concept.
The Mortal Kombat cabinet is a newer addition to the collection, so [wrongbaud] hasn’t progressed quite as far with that one. The parallel flash chip has been dumped with the help of an ESP32 and a MCP23017 I/O expander, and some Genesis ROM headers are identifiable in the data, but there’s still some sifting to be done before the firmware structure can be fully understood.
Even if you’re not in the market for a diminutive arcade experience, the information that [wrongbaud] has collected here is really phenomenal. From understanding protocols such as I2C and SPI to navigating firmware dumps with a hex editor, these posts are an invaluable resource for anyone looking to get started with reverse engineering.
If you hadn’t noticed, we had a bit of an FPGA theme running at this year’s Superconference. Why? Because the open-source FPGA toolchain is ripening, and because many of the problems that hackers (and academics) are tackling these days have become complex enough to warrant using them. A case in point: David Williams is a university professor who just wanted to build a quadruped robotics project. Each leg has a complex set of motors, motor drivers, sensors, and other feedback mechanisms. Centralizing all of this data put real strains on the robot’s network, and with so many devices the microcontrollers were running out of GPIOs. This lead him to become, in his words, “FPGA-curious”.
If you’re looking for a gentle introduction to the state of the art in open-source FPGAs, this is your talk. David covers everything, from a bird’s eye view of hardware description languages, through the entire Yosys-based open-source toolchain, and even through to embedding soft-CPUs into the FPGA fabric. And that’s just the first 18 minutes. (Slides for your enjoyment, and you can watch the talk embedded below the break.) Continue reading “David Williams Is “FPGA-Curious””→
What does Pluto — not the dog, but the non-Planet — have in common with the Vikram lunar lander launched by India? Both were found by making very tiny comparisons to photographs. You’d think landing something on the moon would be old hat by now, but it turns out only three countries have managed to do it. The Chandrayaan-2 mission would have made India the fourth country. But two miles above the surface, the craft left its planned trajectory and went radio silent.
India claimed it knew where the lander crashed but never revealed any pictures or actual coordinates. NASA’s Lunar Reconnaissance Orbiter took pictures several times of the landing area but didn’t see the expected scar like the one left by the doomed Israeli lander when it crashed in April. A lot of people started looking at the NASA pictures and one Indian computer programmer and mechanical engineer, Shanmuga Subramanian, seems to have been successful.
Hackaday editors Mike Szczys and Elliot Williams talk over the last three weeks full of hacks. Our first “back to normal” podcast after Supercon turns out to still have a lot of Supercon references in it. We discuss Raspberry Pi 4’s HDMI interfering with its WiFi, learn the differences between CoreXY/Delta/Cartesian printers, sip on Whiskey aged in an ultrasonic jewelry cleaner, and set up cloud printing that’s already scheduled for the chopping block. Along the way, you’ll hear hints of what happened at Supercon, from the definitive guide to designing LEDs for iron-clad performance to the projects people hauled along with them.
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!
On Star Trek, all Kirk and friends had to do was snap the button on the always conveniently located intercom panel, start talking, and the intended recipient would immediately respond no matter where they were in the ship. How did it work? Who knows. In spite of, or perhaps even because of, the lightly-explained nature of the technology, the cherry-red wall intercoms still hold a certain charm for fans of the groundbreaking show.
A viewer sent [Fran Blanche] a scaled down replica of the intercom from ThinkGeek, and while it certainly looks fairly close to the original prop, it has a couple of annoying design elements. When triggered by the side-mounted motion sensors, the panel will play either the iconic swoosh of the automatic doors or the “Red Alert” sound effect. It’s a cute idea for a kid’s bedroom maybe, but not exactly ideal for somebody who regularly records YouTube videos.
Peak 23rd century technology
So the first order of business was to cut the motion sensors out of the circuit and replace them with a push button. [Fran] draws up a quick diagram to explain how these sensors work, and shows that they can easily be bypassed with a momentary switch since they normally bring the line high when triggered. She then converted the indicator light on the right side of the panel into a button to enable the alert sound effect, which is more accurate to how it worked in the show anyway.
The other issue, and perhaps the most egregious to Star Trek fans, is that the “Red Alert” indicator on the top of the panel didn’t actually flash like it did in the show. To design and build this panel and not put a few LEDs behind that piece of frosted plastic seems a bit like producing a Matchbox car and forgetting to make the wheels spin. With a couple of red LEDs and a bit of new wiring, the oversight was quickly rectified.
While it might not be perfect, at least ThinkGeek actually produced a functional product this time. It could have ended up like one of their April Fool’s “products” that never get put into production, forcing a desperate Trekkie to begrudgingly build his own version.
