ARM Programming By Example

The ARM processor is popping up everywhere. From Raspberry Pis, to phones, to Blue Pill Arduino-like boards, you don’t have to go far to find an ARM processor these days. If you program in C, you probably don’t care much or even think about it. But do you know ARM assembly language? Well, if you look at it one way, it can’t be too hard. The CPU only has about 30 distinct operations — that’s why it is called RISC. Of course, sometimes fewer instructions actually make things more difficult. But you can get a great starting tutorial with the 21 programs on the ARM Assembly by Example website.

You need a 32-bit ARMv6 or better — so Raspberry Pi will work here. The compiler, of course, is gcc and all the associated tools. if you have the right hardware, there are sections on using the floating point unit and the NEON co-processor, too.

Continue reading “ARM Programming By Example”

Building MS-DOS From Scratch Like It’s 1983

Building a complete operating system by compiling its source code is not something for the faint-hearted; a modern Linux or BSD distribution contains thousands of packages with millions of lines of code, all of which need to be processed in the right order and the result stored in the proper place. For all but the most hardcore Gentoo devotees, it’s way easier to get pre-compiled binaries, but obviously someone must have run the entire compilation process at some point.

What’s true for modern OSes also holds for ancient software such as MS-DOS. When Microsoft released the source code for several DOS versions a couple of years ago, many people pored over the code to look for weird comments and undocumented features, but few actually tried to compile the whole package. But [Michal Necasek] over at the OS/2 Museum didn’t shy away from that challenge, and documented the entirely-not-straightforward process of compiling DOS 2.11 from source.

The first problem was figuring out which version had been made available: although the Computer History Museum labelled the package simply as “MS-DOS 2.0”, it actually contained a mix of OEM binaries from version 2.0, source code from version 2.11 and some other stuff left from the development process. The OEM binaries are mostly finished executables, but also contain basic source code for some system components, allowing computer manufacturers to tailor those components to their specific hardware platform.

Compiling the source code was not trivial either. [Michal] was determined to use period-correct tools and examined the behaviour of about a dozen versions of MASM, the assembler likely to have been used by Microsoft in the early 1980s. As it turned out, version 1.25 from 1983 produced code that most closely matched the object code found in existing binaries, and even then some pieces of source code required slight modifications to build correctly. [Michal]’s blog post also goes into extensive detail on the subtle differences between Microsoft-style and IBM-style DOS, which go deeper than just the names of system files (MSDOS.SYS versus IBMDOS.COM).

The end result of this exercise is a modified DOS 2.11 source package that actually compiles to a working set of binaries, unlike the original. And although this does not generate any new code, since binaries of DOS 2.11 have long been available, it does provide a fascinating look into software development practices in an age when even the basic components of the PC platform were not fully standardized. And don’t forget that even today some people still like to develop new DOS software.

Oddball X86 Instructions

David Letterman made the top ten list famous. [Creel] has a top ten that should appeal to many Hackaday readers: the top 10 craziest x86 assembly language instructions. You have to admit that the percentage of assembly language programmers is decreasing every year, so this isn’t going to have mass appeal, but if you are interested in assembly or CPU architecture, this is a fun way to kill 15 minutes.

Some would say that all x86 instructions are crazy, especially if you are accustomed to reduced instruction set computers. The x86, like other non-RISC processors, has everything but the kitchen sink. Some of these instructions might help you get that last 10 nanoseconds shaved off a time-critical loop.

Continue reading “Oddball X86 Instructions”

Boot Sector Pong As A Crash Course In Assembly

Have you ever wanted to develop a playable game small enough to fit into a disk’s 512 byte boot sector? How about watching somebody develop a program in assembly for nearly two hours? If you answered yes to either of those questions, or ideally both of them, you’re going to love this project from [Queso Fuego].

Whether you just want to check out the public domain source code or watch along as he literally starts from a blank file and codes every line for your viewing pleasure, chances are good that you’ll pick up a trick or two from this project. For example, he explains how all of the “graphics” in the game are done in 80 x 25 text mode simply by setting the background color of character cells without printing any text to them.

We really like the presentation in the video after the break, which was recorded over the course of multiple days, judging by the changing light levels in the background. As he types out each line of code, he explains what its function is and gives any background information necessary to explain how it will fit into the larger program. If you’ve ever wondered if you had what it takes to program in ASM, watching this video is a great way to decide.

[Queso Fuego] mentions that this project, and his research into this sort of low-level programming, came about due to the social distancing boredom that many of us are feeling. While we’re certainly not advocating for him to kept locked in his home permanently, with projects like this, you’ve got to admit it seems like a win for the rest of us.

Continue reading “Boot Sector Pong As A Crash Course In Assembly”

Learn PDP-11 Assembly For Fun But Probably No Profit

Learning a new skill is fun, especially one that could land you a new job. We don’t think you’ll find too much demand for PDP-11 assembly language programmers, but if it still interests you, check out [ChibiAkumas’s] video that starts a series on that subject for “absolute beginners.”

The PDP-11 is a venerable computer, but you can still find simulators ranging from SIMH to browser-based virtual devices with front panels. If you want real hardware, there is a PDP-11 on a chip that is still around (or you can score the real chips, sometimes) and there are some nice hardware simulations, too.

Continue reading “Learn PDP-11 Assembly For Fun But Probably No Profit”

Dirty Tricks For 6502 Programming

We know the 6502 isn’t exactly the CPU of choice for today’s high-performance software, but with the little CPU having appeared in so many classic computers — the Apple, the KIM-1, The Commodores, to name a few — we have a real soft spot for it. [Janne] has a post detailing the eight best entries in the Commodore 64 coding competition. The goal was to draw an X on the screen using the smallest program possible. [Janne] got 56 bytes, but two entrants clocked in at 34 bytes.

In addition to the results, [Janne] also exposes the tricks people used to get these tiny programs done. Just looking at the solution in C and then 6502 assembly is instructive. Naturally, one trick is to use the existing ROM code to do tasks such as clearing the screen. But that’s just the starting point.

Continue reading “Dirty Tricks For 6502 Programming”

Getting To Know Every Bit Of An ATtiny13

We recently heard it said of a hacker who pulled off a particularly nice VGA hack on an 8-bit microcontroller: “He knows all the bits, personally.” High praise, indeed. If you want to get on a first-name basis with a ton of transistors, then have a look at [Heinz D]’s Vacation Course in ATtiny13 Assembler (original in German, translated into English by robots here).

But be warned, this isn’t the easy way to learn AVRs. Not content with simply stripping away every layer of abstraction, this month-long “course” in AVR assembly starts off programming the chip initially with just two pushbuttons in its native machine language of high and low voltages. But still, especially if you can get a few assignments done in one sitting, you’re writing in the relative splendor of assembly language and uploading code with a proper programmer before long, because there’s a real limit to how much code one can toggle in before going mad.

There’s a beautiful minimalism to this entirely ground-up approach, and maybe it’s an appropriate starting point for learning how the machine works at its lowest level. At any rate, you’ll be able to lord it over the Arduino crew that you were able to get blink.ino up and running with just a pair of mechanical contacts and a battery. Real programmers

And once you’ve mastered AVR assembly language, you can recycle those two buttons to learn I2C or SPI. What other protocols are there that don’t have prohibitive timeouts? What’s the craziest code that you’ve ever entered bit by bit?