When the story of an invention is repeated as Received Opinion for the younger generation it is so often presented as a single one-off event, with a named inventor. Before the event there was no invention, then as if by magic it was there. That apple falling on Isaac Newton’s head, or Archimedes overflowing his bath, you’ve heard the stories. The inventor’s name will sometimes differ depending on which country you are in when you hear the story, which provides an insight into the flaws in the simple invention tales. The truth is in so many cases an invention does not have a single Eureka moment, instead the named inventor builds on the work of so many others who have gone before and is the lucky engineer or scientist whose ideas result in the magic breakthrough before anyone else’s.
The history of computing is no exception, with many steps along the path that has given us the devices we rely on for so much today. Blaise Pascal’s 17th century French mechanical calculator, Charles Babbage and Ada, Countess Lovelace’s work in 19th century Britain, Herman Hollerith’s American tabulators at the end of that century, or Konrad Zuse’s work in prewar Germany represent just a few of them.
So if we are to search for an inventor in this field we have to be a little more specific than “Who invented the first computer?”, because there are so many candidates. If we restrict the question to “Who invented the first programmable electronic digital computer?” we have a much simpler answer, because we have ample evidence of the machine in question. The Received Opinion answer is therefore “The first programmable electronic digital computer was Colossus, invented at Bletchley Park in World War Two by Alan Turing to break the Nazi Enigma codes, and it was kept secret until the 1970s”.
It’s such a temptingly perfect soundbite laden with pluck and derring-do that could so easily be taken from a 1950s Eagle comic, isn’t it. Unfortunately it contains such significant untruths as to be rendered useless. Colossus is the computer you are looking for, it was developed in World War Two and kept secret for many years afterwards, but the rest of the Received Opinion answer is false. It wasn’t invented at Bletchley, its job was not the Enigma work, and most surprisingly Alan Turing’s direct involvement was only peripheral. The real story is much more interesting.
If you entered the world of professional computing sometime in the 1960s or 1970s there is a high probability that you would have found yourself working on a minicomputer. These were a class of computer smaller than the colossal mainframes of the day, with a price tag that put them within the range of medium-sized companies and institutions rather than large corporations or government-funded entities. Physically they were not small machines, but compared to the mainframes they did not require a special building to house them, or a high-power electrical supply.
One of the most prominent among the suppliers of minicomputers was Digital Equipment Corporation, otherwise known as DEC. Their PDP line of machines dominated the market, and can be found in the ancestry of many of the things we take for granted today. The first UNIX development in 1969 for instance was performed on a DEC PDP-7.
DEC’s flagship product line of the 1970s was the 16-bit PDP-11 series, launched in 1970 and continuing in production until sometime in the late 1990s. Huge numbers of these machines were sold, and it is likely that nearly all adults reading this have at some time or other encountered one at work even if we are unaware that the supermarket till receipt, invoice, or doctor’s appointment slip in our hand was processed on it.
During that over-20-year lifespan of course DEC did not retain the 74 logic based architecture of the earliest model. Successive PDP-11 generations featured ever greater integration of their processor, culminating by the 1980s in the J-11, a CMOS microprocessor implementation of a PDP-11/70. This took the form of two integrated circuits mounted on a large 60-pin DIP ceramic wafer. It was one of these devices that came the way of [bhilpert], and instead of retaining it as a curio he decided to see if he could make it work.
The PDP-11 processors had a useful feature: a debugging console built into their hardware. This means that it should be a relatively simple task to bring up a PDP-11 processor like the J-11 without providing the rest of the PDP-11 to support it, and it was this task that he set about performing. Providing a 6402 UART at the address expected of the console with a bit of 74 glue logic, a bit more 74 for an address latch, and a couple of 6264 8K by 8 RAM chips gave him a very simple but functional PDP-11 on a breadboard. He found it would run with a clock speed as high as 11MHz, but baulked at a 14MHz crystal. He suggests that the breadboard layout may be responsible for this. Hand-keying a couple of test programs, he was able to demonstrate it working.
When you attend a very large event such as EMF Camp, there is so much going on that it is impossible to catch everything. It’s easy to come away feeling that you’ve missed all the good stuff, somehow you wasted your time, everyone else had complete focus and got so much more out of the event.
In an odd twist, one of the EMF 2016 talks people have been raving about is very relevant to that fear of inability to take in a festival programme. [Jessica Rose] gave a talk about imposter syndrome. A feeling of inadequacy compared to your peers and a constant anxiety at being exposed as a fraud that will probably be very familiar to many readers. As she points out, it’s a particularly cruel affliction in that it affects those people who do have all the skills while the real impostors share an inflated competence in their abilities.
This has significant relevance to many in our community and for a single presentation to get so many people talking about it at an event like EMF Camp means it definitely hit the mark. The full video is embedded below the break. At about half an hour long it’s well worth a look.
How many grown-up hardware hackers whiled away their youth playing Tetris or Mario on their Game Boy? Fond memories for many, but unless you are lucky your Game Boy will probably be long gone. Not for [Gautier Hattenberger] though, he had an unexpected find at his parents’ house; his Game Boy Classic, unloved and forgotten for all those years. Fortunately for us his first thought was whether he could use it as a controller for a drone, and better still he’s shared his work for all of us to see.
How to connect a drone and a Game Boy
Back in the day a would-be Game Boy hacker would have been deterred by Nintendo’s legal defences against game piracy, but with the benefit of a couple of decades the handheld console’s hardware is now an open book. Unfortunately for [Gautier], he seems to be the first to use one as a flight controller, so he had to plough his own furrow. His Game Boy Game Link serial port feeds an Arduino/FTDI combination that converts Game Link to USB, which is then sent to his laptop on which a small piece of software converts them to commands for the drone through the Paparazzi UAV framework.
All his code is in a GitHub repository, and he’s posted a video of his work which you can see below the break. For a child of the early ’90s, the mere thought that their handheld console could do this would have been mindblowing!
If you watch Pokémon Go enthusiasts, you may have noticed something of a community spirit among gamers congregating at busy in-game locations. [Spencer Kern] wanted to encourage this, so produced what he describes as a water cooler for Pokémon Go players, a Pokémon-styled charging station with multiple USB ports.
His build centres on a Yeti 400 solar power pack and a large multi-port USB hub, for which he has built a detailed wooden housing in the style of a Pokémon Center from the earlier Nintendo games. The idea is that gamers will congregate and plug in their phones to charge, thus bringing together a real-world social aspect to the game. We can see the attraction to gamers, however we suspect most Hackaday readers would join us in not trusting a strange USB socket and using only a USB cable not equipped with data conductors.
Still, the housing has seen some careful design and attention to detail in its construction. He started with a 3D CAD model from which he created a set of 2D templates to print on paper and from which to cut the wood. As many of his dimensions as possible were taken from common wood stock to save machining time, and the structure was assembled using wood glue before being sanded and filled. Finally, the intricate parts such as the Pokémon logo were 3D printed, and spray painted. The result is a pretty good real-world replica of the Pokémon Center that you’d recognise if you were a player of the original games, and he reports it was a hit with gamers in his local park.
If you have ever spent a while delving into the bare metal of talking to the I/O pins on a contemporary microprocessor or microcontroller you will know that it is not always an exercise for the faint-hearted. A host of different functions can be multiplexed behind a physical pin, and once you are looking at the hardware through the cloak of an operating system your careful timing can be derailed in an instant. For these reasons most of us will take advantage of other people’s work and use the abstraction provided by a library or a virtual filesystem path.
If you have ever been curious enough to peer under the hood of your board’s I/O then you may find [Ken Shirriff]’s latest blog post in which he explores the software stack behind the pins on a BeagleBone Black to be of interest. Though its specifics are those of one device, the points it makes have relevance to many other similar boards.
He first takes a look at the simplest way to access a Beagle Bone’s I/O lines, through virtual filesystem paths. He then explains why relying so heavily on the operating system in this way causes significant timing issues, and goes on to explore the physical registers that lie behind the pins. He then discusses the multiplexing of different pin functions before explaining the role of the Linux device tree in keeping operating system in touch with hardware.
For some Hackaday readers this will all be old news, but it’s safe to say that many users of boards like the BeagleBone Black will never have taken a look beyond the safely abstracted ways to use the I/O pins. This piece should therefore provide an interesting education to the chip-hardware novice, and should probably still contain a few nuggets for more advanced users.
If you had made it this far in your journey from project to kit, you would now have a box of electronic components, a pile of printed instructions, and a box of plastic bags, thin card boxes, or whatever other retail packaging you have chosen for your kit. You are ready to start stuffing kits.
It’s All In The Presentation
Label all your hard-to-identify components, your customers will appreciate it.
Your priorities when stuffing a kit are to ensure that your customer receives all the components they should, they can easily identify each component, and that the whole kit is attractively presented such that it invites them to buy or build it when they first see it. This starts before you have packed any components, you must carefully prepare each component into units of the required number and label them if they are otherwise not easy to identify. Pre-cut any components supplied on tape, and write the part number or value on the tape if it is not easily readable. You may even have to package up some difficult-to-identify components in individual labeled bags if they can not have their values written on them, though this incurs an extra expense of little bags and stickers. Some manufacturers will insist on using black tape on which an indelible pen doesn’t show up!
Take care cutting tapes of components, it is sometimes easy to damage their pins. Always cut the tape from the bottom rather than the side with the peelable film, and if necessary carefully bend the tape slightly to open up the gap between components for your scissors.
If you start by deciding how many kits you want to stuff in a sitting, list all the kit components and prepare that number of each of them in the way we’ve described. Then take the required number of packages or bags, and work through each component on the list, stuffing all the bags with one component before starting again moving onto the next. In time you will have a pile of stuffed kits ready to receive their instructions and labeling.
The next step will be to fold your instruction leaflet and pack it in the kit. Take a moment to consider how it can be most attractively presented. For example with a kit packaged in a click-seal plastic bag it makes sense to fold the leaflet such that the colour photo of a completed kit is visible from the front. And when you place it in the bag make sure that the PCB is visible top-outwards in front of it. A customer looking at your kit wants to immediately see what they are likely to create with it.
You can now seal the bag or box, the kit is packed. It only remains to give it a label that has all the pertinent information and is attractive to the customer. You will probably want to put your logo or web address on the label as well as any small print required, alongside the most important feature — the kit description. We’ve put a warning about small parts and curious children, you may also want to put any reglatory or compliance information here. For example in Europe you might have a CE mark and a WEEE logo. Once you have your design sorted you can run it up in your favourite label designing software – we used gLabels – and print as many as you like on sheets of sticky labels. We strongly suggest buying good quality branded labels, the extra money is well worth it when you consider that they will have much more reliable glue, and the extra cost per individual kit will be marginal. Pick a label size which fills a decent space and is easy to read on your packaging without being too big, we used 70mm x 37mm laser labels of which 24 can be had on a single sheet.
Your First Finished Product
If Hackaday made electronic kits, they might look a little like this.
It’s an exciting moment when you apply a label to your first fully packed kit and see for the first time what your customers will see: a finished product. You aren’t quite done though, because there is still the small matter of quality control. Take a kit or two from your batch at random, and count all their contents off against your list of what they should contain. This should help you ensure you are packing the kits correctly. Finally, give a completed kit to a friend who has never seen it before, and tell them to build it as a final piece of quality control. They are simulating your customer in every way, if they have no problems then neither should anyone who buys the kit.
Once you’ve built your batch of kits, you will now have the stock you will send out to your customers. Imagine yourself as a customer, if you order a kit you will expect it to arrive in pristine condition. You should therefore now take care of this stock of kits to ensure that it does not come to any harm, its packaging is as crisp and new when you send it out as when you packed it, and it has not attracted any dust while in storage. We would suggest having a separate plastic box for the stock of each kit in your range, and protecting the kits from dust with a lid, or by storing them inside a larger plastic bag.
As we’ve worked through this series of articles, we’ve tried to give you a flavour of the process of bringing an electronic kit from a personal project to the masses. We’ve looked at learning about the market for your kit, we’ve discussed turning a project into a product before writing the best instructions possible and now stuffing your first kits ready for sale. In the next article in the series we’ll talk about how you might sell your products, the different choices open to you for online shops, marketplaces, and crowdfunding.