A graph visualising approximation errors - the specific principle pictured is described well by the linked article

Time And Accuracy In Las ATMegas

January 31, 2022 by Arya Voronova 4 Comments

Do you ever have to ensure that an exact amount of time passes between two tasks in your microcontroller code? Do you know what’s the difference between precision and accuracy? Today, [Jim Mack] tells us about pushing timers and interrupts to their limits when it comes to managing time, while keeping it applicable to an ever-popular ATMega328P target! Every now and then, someone decides to push the frontiers of what’s possible on a given platform, and today’s rules is coding within constraints of an Arduino environment. However, you should check [Jim]’s post out even if you use Arduino as a swearword – purely for all of the theoretical insights laid out, accompanied by hardware-accurate examples!

This will be useful to any hacker looking to implement, say, motor encoder readings, signal frequency calculations, or build a gadget processing or modifying audio in real time. To give you a sample of this article, [Jim] starts by introducing us to distinctions between precision and accuracy, and then presents us with a seemingly simple task – creating exactly 2400 interrupts a second. As much as it might look straightforward, problems quickly arise when clock crystal frequency doesn’t cleanly divide by the sampling frequency that you have to pick for your application! This is just a taste of all the examples of hidden complexity presented, and they’re accompanied with solutions you can use when you eventually encounter one of these examples in your hacker pursuits. In the end, [Jim] concludes with links to other sources you can study if you ever need to dig deeper into this topic.

Keeping our projects true to the passage of time can be an issue, and we’ve been at it for ages – calibrating your RC oscillator is a rite of passage for any ATTiny project. If you ever decide to have an interrupt peripheral help you with timing issues, we’ve gone in-depth on that topic in the past, with a three-part series describing the benefits, the drawbacks and the edgecases of interrupts. Going for a more modern target? Our piece on using interrupts with STM32 is a great path for trying out tools of the modern age.

Apollo Guidance Computer Gets The Rust Treatment

January 29, 2022 by Tom Nardi 8 Comments

Seems like all the cool kids are rewriting legacy C programs in Rust these days, so we suppose it was only a matter of time before somebody decided to combine the memory-safe language with some of the most historically significant software ever written by way of a new Apollo Guidance Computer (AGC) emulator. Written by [Felipe], the Apache/MIT licensed emulator can run either ROM files made from the computer’s original rope core memory, or your own code written in AGC4 assembly language.

It’s worth noting that the emulator, called ragc, needs a bit of help before it can deliver that authentic Moon landing experience. Specifically, the code only emulates the AGC itself and stops short of recreating the iconic display and keyboard (DSKY) module. To interact with the programs running on the virtual AGC you’ll need to also install yaDSKY2, an open source project that graphically recreates the panel Apollo astronauts actually used to enter commands and get data from the computer.

Of course, the next step would be to hack in support for talking to one of the physical recreations of the DSKY that have graced these pages over the years. Given the limitations of the AGC, we’d stop short of calling such an arrangement useful, but it would certainly make for a great conversation starter at the hackerspace.

Thanks for the tip, [CJ].

Code Wrong: Expand Your Mind

January 29, 2022 by Elliot Williams 24 Comments

The really nice thing about doing something the “wrong” way is that there’s just so much variety! If you’re doing something the right way, the fastest way, or the optimal way, well, there’s just one way. But if you’re going to do it wrong, you’ve got a lot more design room.

Case in point: esoteric programming languages. The variety is stunning. There are languages intended to be unreadable, or to sound like Shakespearean sonnets, or cooking recipes, or hair-rock ballads. Some of the earliest esoteric languages were just jokes: compilations of all of the hassles of “real” programming languages of the time, but yet made to function. Some represent instructions as a grid of colored pixels. Some represent the code in a fashion that’s tantamount to encryption, and the only way to program them is by brute forcing the code space. Others, including the notorious Brainf*ck are actually not half as bad as their rap — it’s a very direct implementation of a Turing machine.

So you have a set of languages that are designed to be maximally unlike each other, or traditional programming languages, and yet still be able to do the work of instructing a computer to do what you want. And if you squint your eyes just right, and look at as many of them all together as you can, what emerges out of this blobby intersection of oddball languages is the essence of computing. Each language tries to be as wrong as possible, so what they have in common can only be the unavoidable core of coding.

While it might be interesting to compare an contrast Java and C++, or Python, nearly every serious programming language has so much in common that it’s just not as instructive. They are all doing it mostly right, and that means that they’re mostly about the human factors. Yawn. To really figure out what’s fundamental to computing, you have to get it wrong.

An Up-To-Date Development Environment For The Nokia N-Gage

January 27, 2022 by Jenny List 18 Comments

One of the brave but unsuccessful plays from Nokia during their glory years was the N-Gage, an attempt to merge a Symbian smartphone and a handheld game console. It may not have managed to dethrone the Game Boy Advance but it still has a band of enthusiasts, and among them is [Michael Fitzmayer] who has produced a CMake-based toolchain for the original Symbian SDK. This is intended to ease development on the devices by making them more accessible to the tools of the 2020s, and may serve to bring a new generation of applications to those old Nokias still lying forgotten in dusty drawers.

In much of the public imagination, the invention of the smartphone came with the release of the first Apple iPhone in 2007. Hackaday readers will of course trace the smartphone back much further than that to an original IBM prototype, and will remind any doubters that the Nokias which the iPhone vanquished were very successful smartphones without any of Cupertino’s magic in sight. Nokia’s tragedy was that they appeared not to understand what they had in Symbian, and released a bewildering array of devices intended to satisfy every possible market without recognizing that the market they needed to serve was their customers being easily able to run the apps of their choice on the things.

Symbian itself has long ago become a piece of abandonware, but during its chequered history there was a period in which an open-source version was released. It would be nice to think that projects such as this one might revive interest in this capable yet forgotten operating system, as with the passage of a decade the cost of hardware which might run it has fallen to the point of affordability. Does anyone want to relive the 2000s?

Header image: Evan-Amos, Public domain.

Web-Centric Gabuino Has Compiler, Will Travel

January 23, 2022 by Tom Nardi 16 Comments

Arguably the biggest advantage of the Arduino platform is its ease of use, especially when compared to what microcontroller development looked like before the introduction of the open source board and its associated software development environment. All you need to do is download the IDE for your platform, plug in your Arduino, and you can have code running on the hardware with just a few clicks.

But can it get even easier? [Gabriel Valky] certainly thinks so, which is why he’s developed the cloud-based Gabuino platform. As of right now it only supports the DS213 pocket oscilloscope and LA104 logic analyzer, but he says the code is lightweight enough that it should work with any STM32 board that has the appropriate bootloader. Using Gabuino requires no software to be installed on the computer, just plug in the board, and you’re already half way there.

Gabuino processing data from digital calipers.

The trick is that the code editor and compiler have been moved into the cloud, and are accessed through the host computer’s web browser. The web interface also integrates an impressive “Console”, which [Gabriel] likens to the Serial Monitor and Plotter functions of the Arduino IDE, but is actually far more capable. The Gabuino Console is not only bi-directional, but through the use of libraries such as Three.js and WebGL, it’s able to render video output from code running on the microcontroller.

[Gabriel] takes us through some of the capabilities of Gabuino in the video below, and we have to say, it looks pretty impressive. We especially liked the built-in debugging capabilities that let you set breakpoints and examine variables. This plug-and-play approach certainly holds promise for students or beginners, though we think the hardware compatibility will need some work before the project really takes off.

Incidentally, this isn’t the first time [Gabriel] has written some code for the LA104. Last year we covered his very impressive custom firmware for the ~$100 USD gadget, which should sweeten the deal considerably if you end up getting one to experiment with Gabuino on.

Continue reading “Web-Centric Gabuino Has Compiler, Will Travel” →

Reverse Engineering The SEGA Mega Drive

January 19, 2022 by Bryan Cockfield 16 Comments

With the widespread adoption of emulators, almost anyone can start playing video games from bygone eras. Some systems are even capable of supporting homebrew games, with several having active communities that are still creating new games even decades later. This ease of programming for non-PC platforms wasn’t always so easy, though. If you wanted to develop games on a now-antique console when it was still relatively new, you had to jump through a lot of hoops. [Tore] shows us how it would have been done with his Sega Mega Drive development kit that he built from scratch.

While [Tore] had an Atari ST, he wanted to do something a little more cutting edge and at the time there was nothing better than the Mega Drive (or the Genesis as it was known in North America). It had a number of features that lent the platform to development, namely the Motorola 68000 chip that was very common for the time and as a result had plenty of documentation available. He still needed to do quite a bit of reverse engineering of the system to get a proper dev board running, though, starting with figuring out how the cartridge system worked. He was able to build a memory bank that functioned as a re-writable game cartridge.

With the hard parts out of the way [Tore] set about building the glue logic, the startup firmware which interfaced with his Atari ST, and then of course wiring it all together. He was eventually able to get far enough along to send programs to the Mega Drive that would allow him to control sprites on a screen with the controller, but unfortunately he was interrupted before he could develop any complete games. The amount of research and work to get this far is incredible, though, and there may be some helpful nuggets for anyone in the homebrew Mega Drive community today. If you don’t want to get this deep into the Mega Drive hardware, though, you can build a cartridge that allows for development on native Sega hardware instead.

Make Your Python CLI Tools Pop With Rich

January 19, 2022 by Matthew Carlson 6 Comments

It seems as though more and more of the simple command-line tools and small scripts that used to be bash or small c programs are slowly turning into python programs. Of course, we will just have to wait and see if this ultimately turns out to be a good idea. But in the meantime, next time you’re revamping or writing a new tool, why not spice it up with Rich?

Rich is a python library written by [Will McGugan] that offers text formatting, colors, graphs, progress bars, markdown, syntax highlighting, charts, and more through the power of ANSI codes. The best part is that it works with macOS, Windows, and Linux. In addition, it offers logging solutions that work out of the box. One of the best features of Rich is the inspect functionality. You can pass in an object, and it will use reflection to print a beautiful chart detailing what exactly the object is, helpful in debugging. The other feature is the traceback, which shows a formatted and annotated snapshot of relevant code on the stack during exceptions.

The source itself is well-written python with comments and typing information. There’s a good chance you’ll pick up a trick or two reading through it. Rich is used to build Textual (also by [Will]), which aims to be a GUI API that runs in the terminal. It served as an excellent example of what Rich is capable of. It is incredible how long these protocols have been around. [Will] even ran Rich on a Teletype Model 33. If you’re working with a bit more of a constrained environment, why not bring some color to your Arduino serial terminal?