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.
When we talk about video games on an oscilloscope, you’d be pardoned for assuming the project involved an analog CRT scope in X-Y mode, with vector graphics for something like Asteroids or BattleZone. Alas, this oscilloscope Tetris (Russian language, English translation) isn’t that at all — but that doesn’t make it any less cool.
If you’re interested in recreating [iliasam]’s build, it’ll probably help to be a retro-oscilloscope collector. The target instrument here is a Tektronix TDS5400, a scope from that awkward time when everything was going digital, but CRTs were still cheaper and better than LCDs. It’s based on a Motorola 68EC040 processor, sports a boatload of discrete ICs on its main PCB, and runs VxWorks for its OS. Tek also provided a 3.5″ floppy drive on this model, to save traces and the like, as well as a debug port, which required [iliasam] to build a custom UART adapter.
All these tools ended up being the keys to the kingdom, but getting the scope to run arbitrary code was still a long and arduous process, with a lot of trial and error. It’s a good story, but the gist is that after dumping the firmware onto the floppy and disassembling it in Ghidra, [iliasam] was able to identify the functions used to draw graphics primitives on the CRT, as well as the functions to read inputs from the control panel. The result is the simple version of Tetris seen in the video below. If you’ve got a similar oscilloscope, the code is up on GitHub.
The Pixel Pump is an open source manual pick & place assist tool by [Robin Reiter], and after a long road to completion, it’s ready to ship. We first saw the Pixel Pump project as an entry to the 2021 Hackaday Prize and liked the clean design and the concept of a completely open architecture for a tool that is so valuable to desktop assembly. It’s not easy getting hardware off the ground, but it’s now over the finish line and nearly everything — from assembly to packaging — has been done in-house.
Because having parts organized and available is every bit as important as the tool itself, a useful-looking companion item for the Pixel Pump is the SMD-Magazine. This is a container for parts that come on SMD tape rolls. These hold components at an optimal angle for use with the pickup tool, and can be fixed together on a rail to create project-specific part groups.
A tool being open source means giving folks a way to modify or add features for better workflows, and an example of this is [Robin]’s suggestion of using a foot pedal for hands-free control of the interactive BoM plugin. With it, one can simply use a foot pedal to step through a highlighted list of every part for a design, an invaluable visual aid when doing hand assembly.
Some professional coders are absolutely adamant that learning to program in assembly language in these modern times is simply a waste of time, and this post is not for them. This is for the rest of us, who still think there is value in knowing at a low level what is going on, a deeper appreciation can be developed. [Philippe Gaultier] was certainly in this latter camp and figured the best way to learn was to work on a substantial project.
Now, there are some valid reasons to write directly in assembler; for example hand-crafting unusual code sequences for creating software exploits would be hindered by an optimising compiler. Creating code optimised for speed and size is unlikely to be among those reasons, as doing a better job than a modern compiler would be a considerable challenge. Some folks would follow the tried and trusted route and work towards getting a “hello world!” output to the console or a serial port, but not [Philippe]. This project aimed to get a full-custom GUI application running as a client to the X11 server running atop Linux, but the theory should be good for any *nix OS.
Hello World! In X11!
The first part of the process was to create a valid ELF executable that Linux would work with. Using nasm to assemble and the standard linker, only a few X86_64 instructions are needed to create a tiny executable that just exits cleanly. Next, we learn how to manipulate the stack in order to set up a non-trivial system call that sends some text to the system STDOUT.
To perform any GUI actions, we must remember that X11 is a network-orientated system, where our executable will be a client connected via a socket. In the simple case, we just connect the locally created socket to the server path for the local X server, which is just a matter of populating the sockaddr_un data structure on the stack and calling the connect() system call.
Now the connection is made, we can follow the usual X11 route of creating client ids, then allocating resources using them. Next, fonts are opened, and a graphical context is created to use it to create a window. Finally, after mapping the window, something will be visible to draw into with subsequent commands. X11 is a low-level GUI system, so there are quite a few steps to create even the most simple drawable object, but this also makes it quite simple to understand and thus quite suited to such a project.
We applaud [Phillip] for the fabulous documentation of this learning hack and can’t wait to see what’s next in store!
In the 1980s, [Mike] was working on his own RPG for the Commodore 64, inspired by dungeon crawlers of the era like Ultima IV and Telengard, both some of his favorites. The mechanics and gameplay were fairly revolutionary for the time, and [Mike] wanted to develop some of these ideas, especially the idea of line-of-sight, even further with his own game. But an illness, a stint in the military, and the rest of life since the 80s got in the way of finishing this project. This always nagged at him, so he finally dug out his decades-old project, dusted out his old Commodore and other antique equipment, and is hoping to finish it by 2024.
Luckily [Mike’s] younger self went to some extremes documenting the project, starting with a map he created which was inspired by Dungeons and Dragons. There are printed notes from a Commodore 64 printer, including all of the assembly instructions, augmented with his handwritten notes to explain how everything worked. He also has handwritten notes, including character set plans, disk sector use plans, menus, player commands, character stats, and equipment, all saved on paper. The early code was written using a machine language monitor since [Mike] didn’t know about the existence of assemblers at the time. Eventually, he discovered them and attempted to rebuild the code on a Commodore 128 and then an Amiga, but never got everything working together. There is some working code still on a floppy disk, but a lot of it doesn’t work together either.
While not quite finished yet, [Mike] has a well-thought-out plan for completing the build, involving aggregating all of the commented source code and doing quarterly sprints from here on out to attempt to get the project finished. We’re all excited to see how this project fares in the future. Beyond the huge scope of this pet project, we’d also suggest that this is an excellent example of thoroughly commenting one’s code to avoid having to solve mysteries or reinvent wheels when revisiting projects months (or decades) later. After all, self-documenting code doesn’t exist.
When we have two 3D printed parts that need to fit together, many of us rely on pins and holes to locate them and fix them together. [Slant 3D] has explored some alternative ideas in this area that may open up new avenues for your own designs.
Their first idea was to simply chamfer the pins and holes. This allows the object to be printed in a different orientations without compromising the fit. It also makes the features less brittle and creates a broader surface for gluing. Another alternative is using fins and slots, which again add robustness compared to flimsy pins. By chamfering the edges of the fins, they can be printed vertically for good strength and easy location without the need for support material.
Neither option requires much extra fuss compared to typical pin-and-hole designs. Plus, both are far less likely to snap off and ruin your day. Be honest, we’ve all been there. Meanwhile, consider adding folded techniques to your repertoire, too.
When we write about retrocomputers, we realize that back in the day, people knew all the details of their computer. You had to, really, if you wanted to get anything done. These days, we more often pick peripherals and just assume our C or other high level code will fit and run on the CPU.
But sometimes you need to get down to the bare metal and if your desire is to use bare metal on the RP2040, [Will Thomas] has a YouTube channel to help you. The first video explains why you might want to do this followed by some simple examples. Then you’ll find over a dozen other videos that give you details.
Any video that starts, “Alright, Monday night. I have no friends. It is officially bare metal hours,” deserves your viewing. Of course, you have to start with the traditional blinking LED. But subsequent videos talk about the second core, GPIO, clocks, SRAM, spinlocks, the UART, and plenty more.
As you might expect, the code is all in assembly. But even if you want to program using C without the SDK, the examples will be invaluable. We like assembly — it is like working an intricate puzzle and getting anything to work is satisfying. We get it. But commercially, it rarely makes sense to use assembly anymore. On the other hand, when you need it, you really need it. Besides, we all do things for fun that don’t make sense commercially.
