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.

CD+Graphics was a format that never really caught on. It let music discs pack some graphics, maybe liner notes, and mostly song lyrics into the otherwise empty space on a CD. It was never intended for displaying full-motion video, but that didn’t stop [Adam Gashlin] from getting a Bad Apple, with lyrics, running on any device that will play CD+G.

The main challenge is that CD+G gives you 300 screen commands per second, which is plenty for updating text on the 48×16 blocks as the lyrics scroll by. But if you want to send custom blocks and draw images, that’s 2.5 seconds per screen: a lousy framerate.

[Adam]’s first trick is to drop the resolution way down, which gets him into the 8 FPS range. Only update the blocks that change pushes this up to a respectable 17-20 FPS. But you can see the updates, and that’s distracting. It really needed buffering.

If you don’t know Bad Apple, it’s in black and white. And like many old graphics engines of the day, CD+G uses a dynamic palette of colors. [Adam] uses this to pack four frames into one, switching between them using palette swapping. (Absolutely check out his “rainbow” version of the video to see how the palette-swapping trick works.)

In the end, his demo has audio, triple-buffered video, and lyrics at 16.3 FPS. It’s slower than the fastest video-only version, but it looks so good, and [Adam]’s explanation of all of the graphics tricks he uses to get there is the real star of the show.

If you want to see Bad Apple running on yet more minimal hardware, how about a 16×2 LCD? Or a much more ridiculous implementation? How’s regexes in Vim for absurd? Got any Bad Apple hacks of your own? Let us know in the comments or the tips line. You can never have too many.

We are absolutely stoked to announce that the Hackaday Superconference is taking place this year November 6th through 8th in glorious Pasadena California, and we want to see you there!

If you’ve been to any of the previous nine Supercons, you know that it’s a fantastic gathering of the most motivated and interesting hackers around — but it’s also been a relatively small gathering. And while we love the very high signal-to-noise ratio of folks who show up, we’re always a little bit sad when the tickets sell out because it represents hackers who couldn’t be there.

So this year, we’re celebrating Supercon Ten by expanding out of our traditional location at the Design Lab so that we can accommodate 20% more hackers, while still keeping the cosy nature of the event intact. So if you’ve been wanting to come to Supercon, but procrastinated the ticket sales every year, this year is looking 20% better.

Call for Proposals

If you want to give a talk to an interested audience of hackers just like you, now is your chance. Fill out the Call for Participation form before Wednesday, Aug 12th to put your hat in the ring. Presenters not only get to share their work with a like-minded audience, but they get in the door free! Presenting really is the best way to attend a conference like this – it’s the ultimate ice-breaker. (Plus, did we mention free?)

We will have two tracks of talks on two stages, and both are a mix of shorter 20-minute talks and longer 40-minute sessions, so whatever the size of your ideas, we have the slot for you. As always, we like to hear about your projects: hardware, software, creation, destruction, or anything in-between. In short, if you have a talk that would interest the readers of Hackaday, it fits. Check out last year’s slate if you’re curious, but bear in mind that we like to see new stuff, so don’t feel constrained by precedent. If you’re into it, there’s a good chance that many of us are too!

All you need is an abstract, a title, and a solid general idea of how the talk is going to go. First time speaker, or grizzled veteran: get your proposal in now.

Plus ça Change…

Supercon Ten starts out as usual with a casual badge-hacking day at Supplyframe HQ on the morning of Friday Nov 6th. We love this day because there’s “nothing” to do! It’s the perfect way to ease into the conference: the doors open, and the food and coffee starts flowing. As the solder melts, brought-along hacks get demoed, friendships form, and plans get hatched. We go on well into the night, with music and festivities to keep you motivated or distracted – the choice is yours.

Saturday and Sunday are chock-full of talks, workshops, challenges, and other events. This year, we’ll be a few blocks south at the ArtCenter South Campus, which means that we’ll be relocating our traditional back-alley ambiance to significantly fancier digs. But of course, we’ll have space for hacking, mingling, and watching the talks.

Sunday evening comes too soon, and at the end of this second day of talks, we’ll let you showcase all of the badge hacks that you’ve been working on before spilling out into the town and falling far too late into bed.

Just because enough is never enough, we’ll probably also meet up informally sometime Thursday night if you’re already in town. And if you’re able to finagle a half-day Monday into your schedule, you’ll find that a bunch of folks have off-schedule side trips that are always popular.

Get Excited!

We know that we’re announcing late this year. The new venue, combined with a late Hackaday Europe, made for a lot more planning to be done. But now that all of our ducks are in a row, we’re very much looking forward to November. And of course, we can’t wait to see what you all are going to bring with you to Supercon. After all, it’s the Hackaday community that makes it great.

Get your talk proposals in now, and in the next few weeks, we’ll open up ticket pre-sales. Tell your friends, neglect to mention it to your enemies, and start making your Supercon plans today.

[Jenny] and I were talking about [Bitluni]’s experiment in scale, where he will take 65,536 cheap microcontrollers, network them all together, and give each one an RGB pixel. From there, antics will surely ensue. Right now, he’s only got 8,192 of them up and running, and already the novel problems and opportunities are rearing their heads.

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.

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?