If you used almost any form of networked PC in the late 1980s or the 1990s, the chances are that you will at some point have encountered the Novell NE2000 network card. This 16-bit ISA card became a de facto standard for 16-bit network cards, such that very few “NE2000” cards were the real thing. A host of clones filled the market, some of which followed the spec of the original rather loosely. It’s something [Michal Necasek] examines as he takes the reader through the history of the NE2000 and why it gained something of a bad reputation. An interesting read for ’90s PC veterans who battled with dodgy Windows 3.1 network drivers.
The Novell line of network cards were not a primary product of the network server OS company but an attempt to spur the uptake of networked computers in an age when few machines were supplied from the factory with a network card installed. They were largely an implementation of the reference design for the National Semiconductor DP3890 Ethernet interface chipset, and for simplicity of interfacing and drivers they used an I/O mapped interface rather than DMA. The problem with the NE2000 wasn’t the card itself which would work with any NE2000 driver, but the host of “NE2000 compatible” cards that appeared over the decade as that magic phrase became a key selling point at the bottom end of the market. Sure they might contain a DP3890 or its clones, but even minor differences in behaviour would cause them not to work with all drivers, and thus they gained a bad name. The piece reveals the original card as one that might have been slow and outdated towards the end of its reign as a standard card, but maybe one not deserving of the ire directed at it.
If you own an Apple product you probably live in a world with a few proprietary interfaces, but by and large your displays and desktop peripherals will use familiar ports such as USB and DisplayPort. For the Mac owner of yore though it was a different matter, as [Dandu] is here to tell us with the tale of a vintage Apple monochrome CRT monitor and a modern Mac.
There are no handy VGA ports to be found in this screen, instead it has a 15-pin D connector following a proprietary interface. With the right adapter it’s easy enough to produce VGA from the modern machine, but while it is in theory possible to map VGA pins to Apple pins there’s a snag with this particular model. Instead of using separate sync pins, it demands a composite sync of the type you might find in an analogue TV set that contains both horizontal and vertical sync pulses. The solution came through a simple transistor circuit, and then with the requisite settings on the modern Mac to deliver the 640×480 resolution it was possible to see a MacOS Catalina desktop on something more suited to a Mac II.
The whole idea behind virtual reality is that you don’t really know what’s going on in the world around you. You only know what your senses tell you is there. If you can fake out your vision, for example, then your brain won’t realize you are floating in a tank providing power for the robot hordes. However, scientists in Japan think that you can even fool your feet into thinking they are walking when they aren’t. In a recent paper, they describe a test they did that combined audio cues with buzzing on different parts of the feet to simulate the feel of walking.
The trick only requires four transducers, two on each foot. They tested several different configurations of what the effect looked like in the participant’s virtual reality headgear. Tests were performed in third person didn’t cause test subjects to associate the foot vibrations with walking. But the first-person perspective caused sensations of walking, with a full-body avatar working the best, compared to showing just hands and feet or no avatar at all.
Making people think they are walking in VR can be tricky but it does explain how they fit all that stuff in a little holodeck. Of course, it is nice if you can also sense walking and use it to move your avatar, but that’s another problem.
The build is based on the FRDMK64F development board, packing a powerful 120 MHz ARM chip. This has enough grunt to decode MP3s on the fly, using the Helix MP3 decoder library. The MP3s themselves are streamed off an SD card, using the faster SDIO access method rather than relying on slower SPI. Once decoded, the resulting PCM audio data is shifted out via a DAC using the chip’s DMA hardware, allowing for smooth, glitch-free playback. Output to a big woofer is via a 15 W class D amplifier, with the whole rig powered from a USB powerbank.
With all the electronics piled on the back of a big woofer speaker with lashings of hot glue, the final result is quite imposing; all the more so when installed neatly inside a clay pot acting as a bass reflex enclosure. We’ve seen some concrete cast speakers before, but not nearly enough hacker projects in clay. Please rectify this, and inform us once you’ve done so. Thanks in advance — video after the break!
Usually when we post a Fail Of The Week, it’s a heroic tale of a project made with the best of intentions that somehow failed to hit its mark. The communicator that didn’t, or the 3D-printed linkage that pushed the boundaries of squirted plastic a little bit too far. But today we’re bringing you something from a source that should be above reproach, thanks to [Boldport] bringing us a Twitter conversation between [Stargirl] and [Ticktok] about a Texas Instruments datasheet.
The SN65220 is a suppressor chip for USB ports, designed to protect whatever the USB hardware is from voltage spikes. You probably have several of them without realising it, the tiny six-pin package nestling on the PCB next to the USB connector. Its data sheet reveals that it needs a resistor network between it and the USB device it protects, and it’s this that is the source of the fail.
There are two resistors, a 15kO and a 27O, 15k ohms, and 270 ohms, right? Looking more closely though, that 27O is not 270 with a zero, but 27O with a capital “O”, so in fact 27 ohms.
The symbol for resistance has for many decades been an uppercase Greek Omega, or Ω. It’s understood that sometimes a typeface doesn’t contain Greek letters, so there is a widely used convention of using an uppercase “R” to represent it, followed by a “K” for kilo-ohms, an “M” for mega-ohms, and so on. Thus a 270 ohm resistor will often be written as 270R, and 270 kilo-ohm one as 270K. In the case of a fractional value the convention is to put the fraction after the letter, so for example 2.7kilo-ohms becomes 2K7. For some reason the editor of the TI datasheet has taken it upon themselves to use an uppercase “O” to represent “Ohms”, leading to ambiguity over values below 1 kilo-ohm.
We can’t imagine an engineer would have made that choice so we’re looking towards their publishing department on this one, and meanwhile we wonder how many USB devices have gone to manufacture with a 270R resistor in their data path. After all, putting the wrong resistor in can affect any of us.
The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.
Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.
Or take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!
So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
Sometimes bad software is all that is holding good hardware back. [Michael Melchior] wanted to scavenge some motors and propellers for another project, so he bought an inexpensive quadcopter intending to use it for parts. [Michael] was so surprised at the quality of the hardware contained in his $100 drone that he decided to reverse engineer his quadcopter and give the autopilot firmware a serious upgrade.
Upon stripping the drone down, [Michael] found that it came with a flight management unit based on the STM32F405RG, an Inertial Measurement Unit, magnetic compass, barometric pressure sensor, GPS, WiFi radio, camera with tilt, optical flow sensor, and ultrasonic distance sensor, plus batteries and charger! The flight management unit also had unpopulated headers for SWD, and—although the manufacturer’s firmware was protected from reading—write protection hadn’t been enabled, so [Michael] was free to flash his own firmware.
We highly recommend you take a look at [Michael]’s 10 part tour de force of reverse engineering which includes a man-in-the-middle attack with a Raspberry Pi to work out its WiFi communication, porting the open-source autopilot PX4 to the new airframe, and deciphering unknown serial protocols. There are even amusing shenanigans like putting batteries in the oven and freezer to help figure out which registers are used as temperature sensors. He achieves liftoff at the end, and we can’t wait to see what else he’s able to make it do in the future.