Translate Your CP/M Code To 8086, And Leave The 1970s Behind!

June 13, 2021 by Jenny List 34 Comments

“Bring our home computing out of the 1970s and into the 1980s and beyond” is the irresistible promise made by the creator of 8088ify, a piece of software which translates CP/M executables from their 8080-based originals to assembler code that should run on an 8088 under MS/DOS. How can we resist such a futuristic promise here in 2021, even though the code wasn’t written to the sound of Donna Summer or the Village People back in the day but here in 2021 for PCjam, a celebration of the original IBM PC’s 40th anniversary.

As the writer of this code [ibara] points out that Intel intended the 8088 to be a ready upgrade path for the 8080, and designed its instruction set while not directly compatible, to make translation between the two a straightforward process. There was commercial software for the task at the time, but to this day there remained nothing with an open-source licence. It’s written in ANSI C for portability across platforms and compilers, and can even be compiled under CP/M itself.

PCjam is well worth a look, and if any of you fancy a go at writing for the earliest MS-DOS machines we’d like to suggest you create something for it. Meanwhile if you’d like to explore CP/M, you can run a bare metal emulator on the Raspberry Pi.

Header: Thomas Nguyen, CC BY-SA 4.0.

An Emulator That Only Plays One Game

June 7, 2021 by Matthew Carlson 1 Comment

[Ben Smith] had previously implemented a GameBoy Color emulator but decided to make a new emulator that to play just one game called pokegb. The game is, of course, the popular blue edition of Pokemon. While this emulator could play other GameBoy games, the way it was implemented was to support only the opcodes and features that Pokemon Blue used. What’s perhaps even more amazing is that this full emulator is just 582 lines of C++ (using SDL for graphics and input). There is also an obfuscated version that comes in at just 68 lines and in the shape of three Pokeballs. All the code for pokegb can be found on GitHub.

[Ben] goes through a detailed listing of each opcode of the processor, memory, the graphics unit (PPU), and how it interacts with a modern operating system. We love the idea of implementing each opcode one by one and gradually seeing the emulator make it farther and farther through the ROM. The only feature that’s noticeably absent is sound, which would require a significant amount of code to emulate properly.

If you’re interested in a deep dive into the audio chips inside a Gameboy Color, [Ken Shirriff] has already done the research for you.

Not All SpaceX Software Goes To Space

June 1, 2021 by Roger Cheng 13 Comments

SpaceX has always been willing to break from aerospace tradition if they feel there’s a more pragmatic solution. Today this is most visible in their use of standard construction equipment like cranes in their Starship development facility. But the same focus on problem solving can also be found in their software parts we don’t see. Recently we got two different views behind the scenes. First, a four-part series about “software in space” published by StackOverflow blog, followed quickly by an Ask Me Anything (AMA) session on SpaceX Reddit.

Some of the StackOverflow series cover ground that has been previously discussed. Mostly in the first part dealing with their workhorse Falcon and Dragon vehicles, and some in the second part discussing Starlink whose beta program is reaching more and more people. Both confirmed that spaceflight software has to meet very stringent requirements and are mostly close to the metal bespoke C++ code. But we receive fascinating new information in part three, which focuses on code verification and testing. Here they leverage a lot of open source infrastructure more common to software startups than aerospace companies. The fourth and final component of this series covers software to support SpaceX hardware manufacturing, which had been rarely discussed before this point. (Unfortunately, there was nothing about how often SpaceX software developers copy and paste code from StackOverflow.)

The recent Reddit AMA likewise had some overlap with the SpaceX software AMA a year ago, but there were new information about SpaceX work within the past year. There was Crew Dragon’s transition from a test to an operational vehicle, and the aforementioned Starship development program. Our comments section had a lot of discussion about the practicality of touchscreen interfaces in real spacecraft, and here we learn SpaceX put a lot of study into building something functional and effective.

It also showed us that essentially every Sci-Fi Movie Interface was unrealistic and would be unreadable under extreme conditions.

In the course of this research, they learned a lot of pitfalls about fictional touch interfaces. Though to be fair, movie and television spacecraft UI are more concerned about looking cool than being useful.

If the standard AMA format is not to your liking, one of the contributors compiled all SpaceX answers alongside their related questions in a much more readable form here. And even though there’s an obvious recruiting side to these events, we’re happy to learn more about how SpaceX have continued to focus on getting the job done instead of rigidly conforming to aerospace tradition. An attitude that goes all the way back to the beginning of this company.

Spell Checking Your Programming From The Linux Command Line

May 29, 2021 by Al Williams 17 Comments

For most of us who didn’t do well in high school English class, spell checkers are a real game-changer. Sure, you can still swap a “to” and a “too,” but a spell checker will catch a lot of typos. But what about in your source code? You usually don’t spell check source code and even if you did, the rules are funny. After all, “my_proejct” is a perfectly fine variable name, but you probably meant “my_project.” That’s where a program called typos comes in. It aims to be a spell checker for source code that is fast enough and with a low enough false positive rate that you can run it against changed code and reject spelling problems.

Sure, if “my_proejct” is a one-time typo, the compiler or interpreter will probably catch it. But it won’t catch comments and it also won’t catch something you spell wrong consistently. For that you need something like typos.

Continue reading “Spell Checking Your Programming From The Linux Command Line” →

Web Assembly, Music Synthesis, And The Beauty Of Math

May 28, 2021 by Al Williams 9 Comments

The electronics hobby has changed a lot since the advent of the microprocessor. Before that — and with the lack of large-scale integrated circuits — projects in magazines tended to be either super simple or ultra complex. However, one popular type of project dealt with music synthesis. Fairly simple circuits could combine to make a complex synthesizer so it was sort of the best of both worlds. Nowadays, you are more likely to tackle a music synthesizer in software like [Tim] did when he created Abelton in Web Assembly and C++. Along the way, he learned a lot about the relationship between math and music.

[Tim] covers what he learned about the Nyquist theorem and how to keep synthesis data flowing in real time with buffers. However, there are some problems trying to do all this in a cross-browser context. The AudioWorklet class appears to have widespread support, though, and [Tim] managed to get that working.

Continue reading “Web Assembly, Music Synthesis, And The Beauty Of Math” →

Simple MicroPython Game Is A 30 Minute Game Dev Course

May 25, 2021 by Donald Papp 7 Comments

Sometimes, it’s really useful to watch a project’s parts come together one piece at a time in order to get a complete understanding and mental picture of the whole, and we found that to be the case with this simple, retro-inspired sample game from [ezContents]. (Video, embedded below.) The code is on GitHub but if you’re at all interested in what goes on behind the scenes in a game like that, don’t miss the video.

In the video, each game element and function is illustrated, showing exactly what gets done and why. This part is collision detection (click to enlarge.)

These sprite-based games are mostly about moving a small graphical object (a sprite) around a screen in response to user input, and managing what happens when collisions are detected between the player’s sprite and other sprites like enemies, projectiles, and so forth. The development process is wonderfully documented and demonstrated in a video, as each separate part of functionality gets built and explained one piece at a time.

The simple game is made using ArduPy (which is MicroPython combined with Arduino APIs) using Seeed Studios’ Wio Terminal, a small microcontroller development board with integrated screen, sensors, and button inputs including a little directional clicker that [ezContents] uses as a joystick.

The video of the whole process is embedded below; give it a watch and you’ll maybe come away with inspiration, but you’ll definitely have a much better understanding of how these types of games are developed, even if you’re not using the same hardware or development environment.

Continue reading “Simple MicroPython Game Is A 30 Minute Game Dev Course” →

Running Modern Linux From A Single Floppy Disk

May 24, 2021 by Tom Nardi 34 Comments

There was a time when booting Linux from a floppy disk was the norm, but of course, those days are long gone. Even if you still had a working 3.5 inch drive, surely the size of the modern kernel alone would far exceed the 1.44 MB capacity of the disks, to say nothing of all the support software required to create a usable operating system. Well that’s what we thought, anyway.

But then [Krzysztof Krystian Jankowski] dropped Floppinux, a live Linux OS that boots from just a single floppy. There’s even a few hundred KB left over on the disk, allowing the user to tuck a few of their own programs and scripts onboard before booting it up. But most impressively, the project doesn’t rely on ancient software releases like so many other embedded systems do. Every component of Floppinux is pulled directly from the cutting edge, including version 5.13.0-rc2 of the Linux kernel which is literally just a few days old.

Of course some concessions had to made in order cram the latest Linux kernel and build of BusyBox into slightly north of 1 MB, so Floppinux certainly isn’t what anyone would call a daily driver. The kernel is stripped down the absolute minimum, and is targeted for the decidedly poky i486. [Krzysztof] had to be very selective about which programs actually made the cut as well, so once the system is booted, there’s not a whole lot you can do with it outside of writing some shell scripts. But then, that was sort of the goal to begin with.

If you’re wondering how [Krzysztof] pulled it off, you don’t have to. He walks you though the entire process, down to the commands he used to do everything from pull down and compile the source code to creating the final disk image. Even if you don’t own a floppy drive, it’s well worth following his guide and booting the image up in QEMU just to say you’ve officially built a Linux system from scratch. It’s good for more than just bragging rights; learning how all the components of a minimal install like this fits together will no doubt come in handy the next time you find yourself poking around inside an embedded Linux device.