Modern video games are nothing short of amazing. My son and I were playing through the one of the latest Zeldas, which involve a mix of combat and puzzle-solving that’s pretty much the hallmark of the franchise. But the most recent open-world Zelda is simply massive. Made by around 1,000 people at a development expense of $150,000,000, it takes probably 60-80 hours to play through if you’re not rushing, and more if you’re taking it easy. It has layers of game mechanics, and worlds in the sky, on land, and underground. It’s big in every way.
Contrast the games of my youth, which were a lot smaller. Written by a pair of people or maybe a handful, with playtimes in the single-digit hours, and of course fitting in the limited computing resources of the time. But the low-stakes nature of the early phases of the industry meant that software developers could take risks, and many of the games were consequently kinda idiosyncratic in this more innocent time.
I think there’s something to be said for small games. They don’t require a lifestyle commitment just to get through. They can still be fun, without taking all of your time. And honestly, when you’re done with a game quickly, you have more time for other stuff. Granted, some of this spirit lives on in the small indie games of today, but even so, game developers have the big studios’ products in the backs of their minds when they are working on their smaller oeuvres.
We were talking about preserving old games for posterity around Hackaday and on the podcast, and our conversations reminded me of a couple of educational games that, despite their rudimentary graphics, are still pretty good today. Both were electronics related, and both are still playable today thanks to efforts on emulation and software preservation. To get a feel for the 1980’s, give Rocky’s Boots a try. (I like the TRS-80 Color Computer version the best, but that may just be nostalgia.) Most of you grownups out there will get through it in an hour or so.
And if you want a challenge, try Rocky’s harder sequel: Robot Odyssey. If you already have a background in digital circuits, you’ll find it doable. Younger me hit a wall about two-thirds of the way through.
Both of these games stick with me because they taught me something, but also because they were simply quirky in a way that a game can only be when it’s written by a small team of folks who are just having fun programming it. If you pitched “a puzzle game about a raccoon who builds logic circuits to activate robot boots”, the boardroom would look at you like you’re out of your mind. But it’s just exactly the quirkiness and individuality of some of these early games that I cherish the most.
If you find yourself knee-deep in an endless modern game, take a side-quest off into a more naive time, and you’ll appreciate why people are putting efforts into archiving them.
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!
We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.
Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.
On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.
So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.
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!
In the sweltering temperatures of an unusually hot European heatwave, I found myself having a chat with a friend of mine from my university days. After discussing the health of his cat who had solved the problem of a fur coat on a hot day by flattening himself out on the concrete floor in the coolest place in the house, we moved on to tech matters. We’ve known each other for not far short of four decades, so this is familiar territory for us. The problems that come with taking a prototype to manufacturing, a process which even the most seasoned of engineers can slip up on.
The Difference Between Making, And Making For Manufacture
If you’ve ever taken a project and replicated it, you will know the progression. If you’re making five or ten widgets, you can debug and rework as needed, tweak things, and get things going. If you’re making more then this, the process consumes a greater proportion of your time, until a point at which manufacture becomes impractical. Maybe that’s around fifty boards, sometimes more or less.
This rework on the SHA2017 badge was caused by counterfeit parts rather than bad design, but the work it created was very costly for the team.
The skill a professional engineer picks up here is designing for manufacture. It’s something I picked only progressively over the years, and learned with a bang when I became peripherally involved in the production of electronic conference badges. You learn to be much more exact in your PCB design to avoid those reworks and bodge wires, you pick your parts with much greater care, and pay far more attention to power supplies, decoupling, thermal issues, impedances, and ground isolation. Something that works has to become something that always works, first time. You go from having several spins of the prototype PCB to having maybe a couple, and you reach a point at which you can order 5000 boards and have less than 50 of them that need attention. My friend describes himself as more of a software expert than hardware, but he’s learned this process over the decades far more than I have.
One comment he made hit the mark so well that it prompted me to start writing this: that when hiring recent graduates they would design things that could not be volume manufactured, while the new hire apprentices’ designs could. This fit so well with our common experience when we came through an engineering education that it posed the question, were we failed by it? We both attended the University of Hull, on England’s north-east coast, but this isn’t specific to Hull or even our generation as the problem of inadequate preparation applies to so many other institutions. Last year I talked about a couple of young engineers wrestling with an analagous experience here in the 2020s, and they were a long way from the Humber.
Do Universities Secretly See Their Job As Training More Academics?
Hull University Electronic Engineering Department, where I learned most of what I know about electronics (except how to make things for manufacture). Hullian111, CC BY-SA 4.0.
My overwhelming memory of my degree course was shared by my friend, that about half of it was composed of useful stuff, and the other half of it was either trying to teach you to be an electronic engineering academic like the people delivering the lectures, or a course that seemed only to be there because they had someone who could teach it.
My Achilies’ heel was the mathematics, something I was later told improved in later years when the engineering department wrested its students away from the maths department. We had a very small amount of practical work, including simple transistor circuits, digital logic using real 74-series chips, laying out a PCB using crêpe paper tape on acetate film, and oddly considering it was outdated even in the early 1990s, wire-wrapping.
It’s easy to sit here and say that a university course teaches too much theory and not enough practice, but the fact is that universities aren’t there to teach you to solder. Indeed, while it’s a super-useful thing to be able to do and I’d urge every electronic engineer to learn it, soldering your own projects is not what makes you an engineer. Instead there has to be an exploration of where the boundary lies between the theoretical and the practical, and education should straddle that line rather than stay only on one side of it. It’s in deciding where that straddling point stops that the key lies.
There are university courses that manage that boundary by splitting it entirely. They combine time in industry with time studying, and a student on one of those courses would in theory learn the skills of a real-world engineer in their work placements. There are also industry sponsorship schemes placing students into industrial environments, but they are so few and the competition for them so fierce, that they might as well not exist for most students. Even the world of hackerspaces which gives the students a rare chance to mix with professional engineers in their off-time, is actively discouraged by universities. For a student in a full-time, study-based course, the challenge comes in how to bridge that gap into real-world manufacturing despite all these challenges, and learn something useful without the luxury of a real-world environment.
Torturing The Students With Diabolical Designs
The temptation for most courses is to start yet another group project. A team of six students are tasked with getting something working together, and learn stuff. The trouble with group projects though is that they either completely don’t work like our early 1990s assignment to make a telephone exchange from a Transputer link adapter chip, or a few participants end up doing all the hard work like my two young friends mentioned earlier. Group projects are inexpensive for an institution, but they look better than they really are.
Component pinouts like this one from the NXP BAV23 datasheet are a spectacularly evil trick to play on an unsuspecting student.
The hardware hacker world has been marked by a series of epochs, as new technologies bring with them a flowering of creativity. There’s one of those that I think has the potential to delover something impossible back in the 1990s when I was a student, and allow individual students to learn the art of manufacture without a group project in sight. I’m talking about inexpensive PCB manufacture, which allows multiple spins of a design to be completed with a bearable wait, and for not a lot of money.
So if I wanted to teach a bunch of students about designing for manufacture, I’d give them a ready made small project in software form, as EDA files, and as a BOM with a board assembly house. Of course, the project would be fatally flawed but fixable with probably two or maybe three spins, but I wouldn’t tell them that. Instead their first task would be to send the files off and receive a ready-made PCB, or if I was feeling charitable I could give them that first spin ready-made, and tell them to get on with it.
I would throw everything I could at this unfortunate design, a wrong-but-plausible footprint, badly thought out earthing, an accidental oscillator, and all the really annoying things which we’ve all in our time found. I am sure you could think of more diabolical but superficially plausible features. Their task would involve diagnosing the board and redesigning it before sending the files off to the assembly house. A week later they’d have that next spin, they’d have to hunt down any remaining bugs and repeat it all, and so on. I learned this process with my friends in the making of an event badge for 5,000 people, and I think it’s possible that you could learn it as a single trainee engineer with a much smaller board.
It may be unfair to throw all that is wrong with engineering education at the door of universities, even though it’s certain that there are some extremely low hanging fruit. But arriving in the workplace completely lacking an essential skill is perhaps the point at which something should be said. The question is, when it comes to designing for manufacture, is anyone listening?
Watching [sprite_tm]’s build of a handheld 486-based gaming computer, we got to thinking about retro computers and the eternal questions of how much of the computer needs to be actually “old” for it it be retro. Where is the soul of a retro computer? The CPU? The old yellowing plastic case? Maybe it depends on what you’re trying to get out of the hobby.
There is of course a spectrum of people playing around with old computers. For some people, let’s call them “vintage computer enthusiasts”, half of the fun is in keeping the actual old hardware running. This group tends to know what teletype lubricant smells like, and how to tell which capacitors need replacing.
For others, “team retro”, the joy is in using the machine itself, whether that be teaching the old dogs new tricks, or simply loading up nostalgic video games. Team retro is more content with emulations or emulations that are wrapped up neatly in hardware workalikes. They know which registers need POKEing, and whether or not Commander Keen is running at the right framerate.
I think [sprite_tm]’s project falls in with yet another camp, the retro-reengineers. Here, the idea is to step through the engineering lessons of the past by re-designing something from a bygone era. So when [sprite_tm] went with a period 486 CPU backed up by a modern FPGA, perhaps ironically borrowing code from the modern MiSTer project, it makes sense for his goals. Retro-reengineers know the bus architecture and the memory timings, and they are reinventing the wheel as a learning experience. Or in the case of [Voja Antonic]’s imaginary four-bit machine, it’s a teaching experience.
How you work often reflects what you’d like to get out of the project, and at Hackaday, of course, we love all of the above! We’ve identified at least three broad schools of fooling around with old computers. Are we missing any?
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!
Office of Management and Budget director Russell Vought testifies during a Senate Appropriations Committee hearing on the rescissions package on Capitol Hill, Wednesday, June 25, 2025, in Washington. (AP Photo/Mariam Zuhaib)
Near the end of May, the Office of Management and Budget (OMB) proposed a new rule that would govern how the federal government handles the grants it issues, including those that fund the vast majority of scientific research in the US.
If formalized, the rule would make political priorities the prime determinant of what science gets funded and sideline the opinions of scientific experts. Grants could be canceled due to political whims, and new layers of bureaucracy would inhibit basic scientific activities like publishing papers and attending conferences. Unlike the executive orders it echoes, it would have the force of law behind it and be significantly harder to challenge in court.
Before coming into force, however, the proposal must go through a process that includes public feedback and (potentially) changes in response. The deadline for that feedback—Monday, July 13—is rapidly approaching.