Software Development

693 Articles

Roll Your Own Python Debugger

November 11, 2023 by 10 Comments

Debugging might be the one thing that separates “modern” programming from “classic” programming. If you are on an old enough computer — or maybe one that has limited tools like some microcontrollers — debugging is largely an intellectual exercise. Try a program, observe its behavior, and then try again. You can liberally sprinkle print statements around if you have an output device or turn on LEDs or digital outputs if you don’t. But with a debugger, you can get a bird’s-eye view of your program’s data and execution flow.

For some languages, writing a debugger can be hard — you usually use at least some system facility to get started. But as [mostlynerdness] shows, Python’s interpreter wants to help you create your own debugger, and you can follow along to see how it’s done. This is accessible because Python has a built-in debugging core that you can use and extend. Well, regular Python, that is. MicroPython has some low-level support, and while we’ve seen attempts to add more, we haven’t tried it.

Of course, you may never need to build your own debugger — most of the IDEs have already done this for you, and some of the code is, in fact, lifted from an open code base and simplified. However, understanding how the debugging plumbing works may give you a leg up if you need to create custom logic to trap an error that would be difficult to find with a generic debugger. Plus, it is just darn interesting.

Like many Python things, there are some version sensitivities. The post is in four parts, with the last two dealing with newer API changes.

We can’t promise that Python can debug your hardware, though. We always thought the C preprocessor was subject to abuse, but it turns out that Python has the same problem.

Learn Forth On The Commodore VIC-20

November 3, 2023 by 14 Comments

Although BASIC was most commonly used on home computers like the Commodore VIC-20, it was possible to write programs in other languages, such as Forth. Conveniently, all it took to set up a Forth development system was inserting the cartridge into the VIC-20 and powering it on, with the VIC-FORTH cartridge by [Tom Zimmer] being a popular choice for the Commodore VIC-20. In a recent video, the [My Developer Thoughts] YouTube channel covers Forth development using this cartridge.

In addition to the video tutorial, the original VIC-FORTH Instruction Manual is also available, together with the 1541 disk image. In an upcoming video, the Commodore 64 version of the cartridge will also be covered, which is called 64Forth, and which is also readily available to tinker with. For those interested in learning more about [Tom Zimmer] and his Forth-related work, a 2010 interview could be interesting. This covers the other platforms which he developed an implementation for.

As for why Forth might be interesting to developers and users, this comes mostly down to the much lower overhead of Forth compared to BASIC, while avoiding the pitfalls of ASM and resource-intensive nature of developing in C, as the entire Forth development system (compiler, editor, etc.) comfortably fits in the limited memory of the average 8-bit home computer.

(Thanks to [Stephen Walters] for the tip)

Continue reading “Learn Forth On The Commodore VIC-20” →

Most AI Content Is Trash, Just Like Everything Else

November 3, 2023 by 31 Comments

[Max Woolf] has been working in the AI space since 2015, and among other work has created numerous useful open-source tools. He also recently wrote a thoughtful blog post that attempts to put into words his feelings on the state of things in the wake of experiencing a bit of an AI backlash-related burnout. Essentially, people effortlessly creating vast amounts of bad AI content has caused a bigger problem than we may realize.

How so? Well, Sturgeon’s law (summarized as “ninety percent of everything is crud”) applies to AI as much as it does to anything else. Theodore Sturgeon was a science fiction author and critic (and writer of multiple Star Trek episodes) who observed in the 1950s that while Science Fiction — the hot new popular thing at the time — was often derided by critics as being little more than low quality pap, so was everything else. It was true that most Science Fiction was garbage. But most work in other fields was of similarly low quality, and thus Science Fiction was really no different. It’s all trash, except for the parts one likes. Just like anything else.

What makes this observation particularly applicable to the current AI landscape is that, according to [Max], the incredible ease of use makes AI’s “ninety percent crud” very large indeed, and the attached backlash is similarly big. The remaining ten percent of AI that is absolutely fantastic and full of possibilities? It’s practically invisible due to how quickly the industry is moving, the speed with which the big players are vying to control it, and how unfashionable it has become to admit one is using AI tools at all.

[Max] knows the scene better than most. One of his projects is simpleaichat, a tool aimed not just at enabling people to integrate AI into projects easier, but piercing the hype around AI to more easily reveal just how these tools actually work. Sadly, a general AI backlash has made developing these tools feel rather less rewarding than it once did.

Die of an Altera EPM7032 EEPROM-based Complex Programmable Logic Device (CPLD). (Credit: ZeptoBars, Wikipedia)

Using EPROMS And EEPROMs As Programmable Logic With Lisp

October 28, 2023 by 9 Comments

That EPROMs, EEPROMs and kin can be used as programmable logic should probably not come as a major surprise, but [Jimmy] has created a Lisp-based project that makes using these chips as a logic array very straightforward. All it takes is importing the package into one’s Lisp project and defining the logic, before the truth function generates the binary file that can be written to the target chip.

Suggested is the one-time-programmable AT27C512R EPROM (64k x8), but any 8-bit parallel interface (E)EPROM should work, with non-OTP chips being nice unless the chip has to go into a production device. A possible future improvement is the addition of 16-bit (E)EPROM support.

The use of EEPROMs is common with PLA-replacements, as with, for example, the Commodore 64, where the official PLA IC tends to go bad over time. Due to the complexity of the logic in these PLA ICs, here CPLDs are used, which internally are still EEPROM-based, but feature many more programmable elements to allow for more complex logic. If all you need is a bit of glue logic and you are looking for something in between a stack of 74-logic ICs and a CPLD, an EEPROM may be just be the solution, regardless of whether you prefer to create the binary image with Lisp or C.

Continue reading “Using EPROMS And EEPROMs As Programmable Logic With Lisp” →

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” →