Software Development

696 Articles

Driving An OLED Screen With A 6502 Single-Board Computer

October 24, 2023 by 12 Comments

Twenty years ago, if you wanted an LCD for a project, you’d probably end up with something salvaged from a mobile phone or an HD44780 character display. These days, little OLEDs can be had for a few bucks and they’ve taken the maker world by storm. [Anders Nielsen] has recently been experimenting with driving these displays from the vintage 6502 CPU, and he’s even got scrolling operation down pat.

The best part is that [Nielsen] is doing all this on a single-board computer running his own assembly code. That’s right – there’s no compilers here. It’s bare metal coding at it’s best. The build uses a 6507 chip running at 1 MHz, paired with a 6532 RIOT and just 128 bytes of RAM—a similar setup to the Atari 2600.

The video explains how the code stacks up and drives the display, achieving the scrolling effect. It makes a huge difference to usability, especially compared to chunking pages at a time to the postage stamp-sized screen. He demonstrates a legitimate usage case too, using the setup as a serial terminal for a Raspberry Pi.

The 6502 architecture still looms large in the collective consciousness; we’ve been talking about programming it in assembly for years. Video after the break.

Continue reading “Driving An OLED Screen With A 6502 Single-Board Computer” →

Linux Fu: Customizing Printf

October 24, 2023 by 13 Comments

When it comes to programming in C and, sometimes, C++, the printf function is a jack-of-all-trades. It does a nice job of quickly writing output, but it can also do surprisingly intricate formatting. For debugging, it is a quick way to dump some data. But what if you have data that printf can’t format? Sure, you can just write a function to pick things apart into things printf knows about. But if you are using the GNU C library, you can also extend printf to use custom specifications. It isn’t that hard, and it makes using custom data types easier.

An Example

Suppose you are writing a program that studies coin flips. Even numbers are considered tails, and odd numbers are heads. Of course, you could just print out the number or even mask off the least significant bit and print that. But what fun is that?

Here’s a very simple example of using our new printf specifier “%H”:

printf("%H %H %H %H\n",1,2,3,4);
printf("%1H %1H\n",0,1);

When you have a width specification of 1 (like you do in the second line) the output will be H or T. If you have anything else, the output will be HEADS or TAILS.

Continue reading “Linux Fu: Customizing Printf” →

Linux Fu: Deep Git Rebasing

October 17, 2023 by 22 Comments

If you spend much time helping people with word processor programs, you’ll find that many people don’t really use much of the product. They type, change fonts, save, and print. But cross-references? Indexing? Largely, those parts of the program go unused. I’ve noticed the same thing with Git. We all use it constantly. But do we? You clone a repo. Work on it. Maybe switch branches and create a pull request. That’s about 80% of what you want to do under normal circumstances. But what if you want to do something out of the ordinary? Git is very flexible, but you do have to know the magic incantations.

For example, suppose you mess up a commit message — we never do that, of course, but just pretend. Or you accidentally added a file you didn’t want in the commit. Git has some very useful ways to deal with situations like this, especially the interactive rebase.

Continue reading “Linux Fu: Deep Git Rebasing” →

LabVIEW Abandons Mac After Four Decades

October 15, 2023 by 52 Comments

When National Instruments (NI) released LabVIEW in 1986 it only targeted the Macintosh, with ports to other platforms coming later on in the 1990s. Now, NI has announced that with the next version in 2024, LabVIEW will only be released for Linux and Windows, leaving behind Apple’s software platform after nearly four decades. The news was covered by Apple Insider, which cites a forum thread on the NI website in which the details of LabVIEW for macOS are discussed. This news comes on the heels of the announcement of Valve dropping macOS support with Counter Strike 2.

In both cases the issue at hand appears to be both a combination of a low user count (less than 1% of CS:GO players) and the complexity of using proprietary APIs (Cocoa, Metal, etc.) that have led to the decision to terminate the macOS releases. Not that macOS users aren’t used to app-related bloodbaths after losing all 32-bit applications back in 2019, but the trend of more high-profile applications and games not supporting the OS does seem to be ramping up.

Perhaps the only positive news here for people who bought into the Apple hardware ecosystem here is that Windows runs on M1/M2 Macs, and there is even an experimental Linux distribution in the form of Asahi Linux to conceivably dual-boot into for those applications that just don’t want to run on Apple’s OS.

Close To The Metal

October 14, 2023 by 81 Comments

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

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!

Debian Bookworm Comes To The Raspberry Pi, And Wayland Is Now Default

October 13, 2023 by 48 Comments

It must have been a busy week for the PR department at Raspberry Pi, with the launch of their latest single-board computer, the Pi 5. Alongside the new board comes something else, an updated Raspberry Pi OS version.

This is built from Debian 12 “Bookworm”, and supplants the previous “Bullseye” version. As well as the new OS base it comes with a pile of Pi-specific upgrades including an optimsied version of Mozilla Firefox. Probably most important is that henceforth (at least on 64-bit boards) its desktop will use the Wayland compositor rather than X11 to draw and manipulate windows. This is a development that has been in the works for a very long time — it must be almost a decade since the first Raspberry Pi blog entry about Wayland — so it’s welcome at last to see it.

The new tweaks as well as Wayland are supposed to deliver a much faster Pi experience, so we thought we’d break out the stopwatch and do some rough real-world tests. The bench 8GB Pi 4 here has a vanilla 64-bit Bullseye installed, so off we went to measure boot time, Chromium browser opening time, and Hackaday load time. It was time to download the new 64-bit Bookworm image and do the same. Have we just downloaded a power-up?

Both tests were done with an everyday boot, after the first-time OS set-up, and with all browser caches emptied. First up was a significant boost, with Bookworm booting in 37.14 seconds to Bullseye’s 53.5, but the Chromium opening was a little more disappointing. On Bullseye it took 7.15s, while Bookworm’s Chromium managed a more pedestrian 9.13s. The new Firefox takes only 7.95s to open. Both Chromium browsers load Hackaday in about 1.8s, while the new Firefox did the same job in a shade over 3s.

So allowing for our stopwatch reaction time and the ad-hoc nature of the test, this is a faster-booting OS, but the underlying hardware is still the limiting factor. We’re disappointed to see that there’s no update for the x86 version of the Raspberry Pi Desktop, and we hope they’ll be able to rectify this in the future.

Decoding The 8088

October 9, 2023 by 2 Comments

There is a lot to like about open software, and in some areas, a well-thought-out piece of software can really make a huge impact. A great example of this is the Sigrok project. Creating simple devices that act like a logic analyzer is relatively easy. What’s hard is writing nice software for such a setup including protocol decoders. Sigrok has done it and since it is open, you can add your device and decode your protocol. [GloriousCow] had done the hardware part of interfacing to the 8088 in an IBM PC using an off-the-shelf logic analyzer that uses a customized version of Sigrok. But the output was a CSV file you had to process in a spreadsheet program. The next step: write a decoder for Sigrok to understand 8088 bus cycles.

The post covers the details of writing such a plug-in for Pulseview, the Sigrok GUI. It will also work for the command line interface if you prefer that. The code is in Python.

Continue reading “Decoding The 8088” →