We think of the Internet extending to small devices as a modern trend, but it actually is a good example of how everything makes a circle. Today, we want the network to connect to our thermostat and our toaster. But somewhere between the year 1990 and the year 2010, there was a push to make the Internet accessible to the majority of people who didn’t own a computer. The prototypical device, in our mind, was Microsoft’s ill-fated WebTV, but a recent video from [This Does Not Compute] reminded us of another entry in that race: The Audrey from 3COM. Check out the video, below.
Many devices, like the WebTV, wanted to take over your TV set to save on a display. That doesn’t sound bad today, but you have to remember, the typical TV set in those days was not the high-resolution digital monster you have today, so the experience of surfing the Web on one was suboptimal. The Audrey actually had a cute little screen and a compact keyboard.
The PDP-11, the Altair 8800, and the IMSAI 8080 were some of the heroes of the computer revolution, and they have something in common — front panel switches, and a lot of them. You probably have a fuzzy idea about those switches, maybe from reading Levy’s Hackers, where the painful process of toggling in programs is briefly described. But how exactly does it work? Well thanks to [Dave Plummer] of Dave’s Garage, now we have a handy tutorial. The exact computer in question is a reproduction of the IMSAI 8080, the computer made famous by a young Matthew Broderick in Wargames. [Dave] managed to score the reproduction and a viewer saved him the time of assembly.
The example program is a Larson Scanner, AKA making an strip of lights push a pulse of light across the strip. [Dave] starts with the Assembly code, a scant 11 lines, and runs it through an assembler available online. That gives us machine code, but there’s no hex keypad for input, so we need those in 8-bit binary bytes. To actually program the machine, you set the address switches to your start-of-program location, and the data switches to your first byte. The “deposit” switch sets that byte, while the “deposit next” switch increments the address and then stores the value. It means you don’t have to key in an address for each instruction, just the data. Get to the end of the program, confirm the address is set to the start, and flick run. Hope you toggled everything in correctly. If so, you’re rewarded with a friendly scanner so reminiscent of 80s TV shows. Stick around after the break to see the demonstration! Continue reading “Bootstrapping The Old Fashioned Way”→
We generally think of 3D printed components as being hard bits of plastic, because for the most part, that’s what we’ve got loaded up in our desktop machines. But outside of the normal PLA, PETG, and ABS, you can also print with various flexible filaments such as TPU. This can be handy for producing custom seals, or rugged enclosures.
But what if you want to make very thin rubberized parts? In that case, the 0.4 mm nozzle on most desktop machines will be your limiting factor. But not so with the method [Daniel Bauen] demonstrates in his latest Engineerable video. The trick here is that the printer isn’t producing the final product — it’s making a water-soluble plug that has been slightly undersized for the application at hand.
Once the plug has been printed, [Daniel] sprays it with several coats of Plasti Dip. This builds up a rubberized coating on the printed part, and once it’s reached the desired thickness, the whole thing gets tossed into an ultrasonic cleaner to break up the filament. What you’re left with is a silicone-like part that has the same shape as your original print, but is far thinner than anything you could have extruded normally.
So what is [Daniel] looking to accomplish with this technique? We’ll admit the shape of the object is rather suggestive, but in that case, the dimensions just leave us with more questions than answers. Perhaps we’ll learn more in the next video, which we’re told will see the plugs get dipped into latex.
When Frank Drake began his astronomy career in the late 1950s, this was an incredibly exciting time for the field. Humanity was beginning to unlock the secrets of the Universe using ever more powerful radio frequency and optical telescopes, including the tantalizing prospect of space-based telescopes. Amidst the ramping up Space Race between the US and USSR, there was an ever-growing excitement about humankind’s future among the stars.
As concrete plans for landings and colonies on the Moon, Venus and Mars were proposed and put into action, it also brought to the forefront many existing and new questions about humanity’s place in the Universe. During Frank Drake’s 92 years on planet Earth – until his passing on September 2nd of this year – he was one of the driving forces behind the search for extraterrestrial intelligence (SETI), along with other legends like Carl Sagan.
Although to the average person the acronym SETI is most likely to bring to mind popcorn movies about little grey – or green – men, Drake’s Project Ozma, as well as the SETI Institution and the ongoing Breakthrough Listen project are just some of the attempts made by Drake and his colleagues over the decades to answer that one question that may affect the very course of humankind’s future: are we alone in the Universe?
This week, Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos had a lot of fun discussing the best of the previous week’s hacks in spite of Elliot’s microphone connectivity troubles. News-wise, we busted out the wine and cheese to briefly debate whether a Colorado man should have won an art competition by entering an image created by AI. Afterward, we went around a bit about floppies, which are being outlawed in Japan.
Then it’s on to the What’s That Sound Results Show, but since Elliot can’t find a 14-sided die, he pulled on the Internet for our random number needs. Congratulations to our big winner [D Rex], who will receive one our coveted Hackaday Podcast t-shirts (Ed. note: Heck, I don’t even have one! That’s how special these babies are).
Afterlife for dead floppies.
Make shoes out of this.
Kristina’s Cyberdeck Thoughts
Is the food-safety-of-3D-printing debate over once and for all? It is as far as Elliot’s concerned. You know what else is over? The era of distributed, independent email servers. Bah! We’re not kidding about that last one — and we discuss a lie-detecting app that may or may not prove our innocence.
Finally, we talk active foot cooling, heat barriers for hot shops, and big, strong magnets. What are they for? Fixing floppies, fool!
[Vuong Nguyen] clearly knows his way around artificial intelligence accelerator hardware, creating ztachip: an open source implementation of an accelerator platform for AI and traditional image processing workloads. Ztachip (pronounced “zeta-chip”) contains an array of custom processors, and is not tied to one particular architecture. Ztachip implements a new tensor programming paradigm that [Vuong] has created, which can accelerate TensorFlow tasks, but is not limited to that. In fact it can process TensorFlow in parallel with non-AI tasks, as the video below shows.
A RISC-V core, based on the VexRiscV design, is used as the host processor handling the distribution of the application. VexRiscV itself is quite interesting. Written in SpinalHDL (a Scala variant), it’s super configurable, producing a Verilog core, ready to drop into the design.
A Digilent Arty-A7, Arducam and a VGA PMOD is all you need
From a hardware design perspective the RISC-V core hooks up to an AXI crossbar, with all the AXI-lite busses muxed as is usual for the AMBA AXI ecosystem. The Ztachip core as well as a DDR3 controller are also connected, together with a camera interface and VGA video.
Other than providing an FPGA-specific DDR3 controller and AXI crossbar IP, the rest of the design is generic RTL. This is good news. The demo below deploys onto an Artix-7 based Digilent (Arty-A7) with a VGA PMOD module, but little else needed. Pre-build Xilinx IP is provided, but targeting a different FPGA shouldn’t be a huge task for the experienced FPGA ninja.
Ztachip top level architecture
The magic happens in the Ztachip core, which is mostly an array of Pcores. Each Pcore has both vector and scalar processing capability, making it super flexible. The Tensor Engine (internally this is the ‘dataplane processor’) is in charge here, sending instructions from the RISC-V core into the Pcore array together with image data, as well as streaming video data out. That camera is only a 0.3 MP Arducam, and the video is VGA resolution, but give it a bigger FPGA and those limits could be raised.
This domain-specific approach uses a highly modified C-like language (with a custom compiler) to describe the application that is to be distributed across the accelerator array. We couldn’t find any documentation on this, but there are a few example algorithms.
The demo video shows a real-time mix of four algorithms running in parallel; one object classification (Google’s Tensorflow mobilenet-ssd, a pre-trained AI model) canny edge detection, a Harris corner detection, and Optical flow which gives it a predator-like motion vision.
[Vuong] reckons, efficiency wise it is 5.5x more computationally efficient than a Jetson Nano and 37x more than Google’s TPU edge. These are bold claims, to say the least, but who are we to argue with a clearly incredibly talented engineer?
A couple weeks ago we talked about in-app browsers, and the potential privacy issues when opening content in them. This week Microsoft reveals the other side of that security coin — JavaScript on a visited website may be able to interact with the JS embedded in the app browser. The vulnerability chain starts with a link handler published to Android, where any https://m.tiktok[.]com/redirect links automatically open in the TikTok app. The problem here is that this does trigger a redirect, and app-internal deeplinks aren’t filtered out. One of these internal schemes has the effect of loading an arbitrary page in the app webview, and while there is a filter that should prevent loading untrusted hosts, it can be bypassed with a pair of arguments included in the URI call.
Once an arbitrary page is loaded, the biggest problem shows up. The JavaScript that runs in the app browser exposes 70+ methods to JS running on the page. If this is untrusted code, it gives away the figurative keys to the kingdom, as an auth token can be accessed for the current user. Account modification, private video access, and video upload are all accessible. Thankfully the problem was fixed back in March, less than a month after private disclosure. Still, a one-click account hijack is nothing to sneeze at. Thankfully this one didn’t escape from the lab before it was fixed.
UPnP Strikes Again
It’s not an exaggeration to say that Universal Plug and Play (UPnP) may have been the most dangerous feature to be included in routers with the possible exception of open-by-default WiFi. QNAP has issued yet another advisory of ransomware targeting their devices, and once again UPnP is the culprit. Photo Station is the vulnerable app, and it has to be exposed to the internet to get pwned. And what does UPnP do? Exposes apps to the internet without user interaction. And QNAP, in their efforts to make their NAS products more usable, included UPnP support, maybe by default on some models. If you have a QNAP device (or even if you don’t), make sure UPnP is disabled on your router, turn off all port forwarding unless you’re absolutely sure you know what you’re doing, and use Wireguard for remote access. Continue reading “This Week In Security: One-click, UPnP, Mainframes, And Exploring The Fog”→
