Microsoft BASIC For The Dragon 64 Recovered

There are a great many pieces of software of yesteryear that are no longer readily accessible. It’s now possible to cross Microsoft BASIC for the Dragon 64 off that list, with the source code now posted for all to enjoy on GitHub.

The repository concerns the Microsoft 16K BASIC Interpreter as built for the Motorola 6809, as used in the Dragon 64 computer. This is also known as BASIC-69 or Extended Color Basic.

Hilariously, the source code was recovered from 340 pages of fan-fold tractor paper stored in four bundles. The output of a Motorola assembler was printed back in 1983 at Dragon Data’s R&D facility in Wales, and was recently recovered after being stored in an attic for much of the last four decades. The paper was carefully scanned at the 2022 Dragon Meetup, before passing the resulting images through OCR software. The output was then manually corrected and the source code was complete for both the 32K and 64K mode ROMs. There are some differences between the scanned source and what Microsoft shipped, which is outlined in the repository.

We’ve seen other heroic retrocomputer recovery efforts before, too, like the work to save the Polish CROOK OS. If you’ve been working on similar feats, be sure to let us know.

Fire-breathing dragon head, side view

Flame-Spitting Dragon Head Heats Up Halloween

Halloween is looming, and [Jonathan Gleich] decided that an ideal centerpiece would be a flame-spitting dragon’s head. It started with an economical wall-mount dragon’s head, combined with a variety of off-the-shelf components to become something greater.

Dragon head with arc ignitor lit
Spark from high-voltage ignitor, right at the torch opening.

The fire comes from a kind of propane torch sold as a weed killer set, which looks a little like a miniature tiger torch. The flow of propane is limited by a regulator (which keeps the flame short and fixed), and controlled with a gas-rated 12 V solenoid valve. Ignition is done with the help of a spark igniter that fires up on demand, fed by a high-voltage ignition coil. The two combine at the Dragon’s mouth, where the flame originates, but the electrical components are otherwise isolated from the gas elements as much as possible.

The dragon head is made of acrylic, and if exposed to enough heat acrylic will first melt, then burn. To help avoid a meltdown, the dragon breathes fire only intermittently.  [Jonathan] also gave the mouth area a heat-resistant barrier made from generous layers of flame-blocking mortar and sealants from the hardware store. The finishing touch comes in the form of bright red LEDs in the eyes, which give the head a bit more life.

Watch the ignitor in action and see the head spewing flames in the two short videos embedded below. The head should make for some good pictures come Halloween, and is a good example of how repurposing off-the-shelf items can sometimes be just what is needed for a project.

Interested in something smaller, but still fiery? Check out this pet fire-breathing dragon project for all your robotic animal companion needs. Continue reading “Flame-Spitting Dragon Head Heats Up Halloween”

Not All SpaceX Software Goes To Space

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.

A New Era Of Spacecraft Delivers Science On Time

When the Space Shuttle Atlantis rolled to a stop on its final mission in 2011, it was truly the end of an era. Few could deny that the program had become too complex and expensive to keep running, but even still, humanity’s ability to do useful work in low Earth orbit took a serious hit with the retirement of the Shuttle fleet. Worse, there was no indication of when or if another spacecraft would be developed that could truly rival the capabilities of the winged orbiters first conceived in the late 1960s.

While its primary function was to carry large payloads such as satellites into orbit, the Shuttle’s ability to retrieve objects from space and bring them back was arguably just as important. Throughout its storied career, sensitive experiments conducted at the International Space Station or aboard the Orbiter itself were returned gently to Earth thanks to the craft’s unique design. Unlike traditional spacecraft that ended their flight with a rough splashdown in the open ocean, the Shuttle eased itself down to the tarmac like an airplane. Once landed, experiments could be quickly unloaded and transferred to the nearby Space Station Processing Facility where science teams would be waiting to perform further processing or analysis.

Atlantis is towed from the runway for payload processing.

For 30 years, the Space Shuttle and its assorted facilities at Kennedy Space Center provided a reliable way to deliver fragile or time-sensitive scientific experiments into the hands of researchers just a few hours after leaving orbit. It was a valuable service that simply didn’t exist before the Shuttle, and one that scientists have been deprived of ever since its retirement.

Until now. With the successful splashdown of the first Cargo Dragon 2 off the coast of Florida, NASA is one step closer to regaining a critical capability it hasn’t had for a decade. While it’s still not quite as convenient as simply rolling the Shuttle into the Orbiter Processing Facility after a mission, the fact that SpaceX can guide their capsule down into the waters near the Space Coast greatly reduces the time required to return experiments to the researchers who designed them.

Continue reading “A New Era Of Spacecraft Delivers Science On Time”

Displaying HTML Interfaces And Managing Network Nodes… In Space!

The touchscreen interface aboard SpaceX Crew Dragon is just one of its many differences from past space vehicles, but those big screens make an outsized visual impact. Gone are panels filled with indicator needles in gauges, or endless rows of toggle switches. It looked much like web interaction on everyday tablets for good reason: what we see is HTML and JavaScript rendered by the same software core underlying Google’s Chrome browser. This and many other details were covered in a Reddit Ask Me Anything with members of the SpaceX software team.

Various outlets have mentioned Chromium in this context, but without answering the obvious follow-up question: how deep does Chromium go? In this AMA we learn it does not go very deep at all. Chromium is only the UI rendering engine, their fault tolerant flight software interaction is elsewhere. Components such as Chromium are isolated to help keep system behavior predictable, so a frozen tab won’t crash the capsule. Somewhat surprisingly they don’t use a specialized real-time operating system, but instead a lightly customized Linux built with PREEMPT_RT patches for better real-time behavior.

In addition to Falcon rocket and Dragon capsule, this AMA also covered software work for Starlink which offered interesting contrasts in design tradeoffs. Because there are so many satellites (and even more being launched) loss of individual spacecraft is not a mission failure. This gives them elbow room for rapid iteration, treating the constellation more like racks of servers in a datacenter instead of typical satellite operations. Where the Crew Dragon code has been frozen for several months, Starlink code is updated rapidly. Quickly enough that by the time newly launched Starlink satellites reach orbit, their code has usually fallen behind the rest of the constellation.

Finally there are a few scattered answers outside of space bound code. Their ground support displays (visible in Hawthorne mission control room) are built with LabVIEW. They also confirmed that contrary to some claims, the SpaceX ISS docking simulator isn’t actually running the same code as Crew Dragon. Ah well.

Anyone interested in what it takes to write software for space would enjoy reading through these and other details in the AMA. And since it had a convenient side effect of serving as a recruiting event, there are plenty of invitations to apply if anyone has ambitions to join the team. We certainly can’t deny the attraction of helping to write the next chapter in human spaceflight.

[Photo credit: SpaceX]

NASA’s Long-Delayed Return To Human Spaceflight

With the launch of the SpaceX Demo-2 mission, the United States has achieved something it hasn’t done in nearly a decade: put a human into low Earth orbit with a domestic booster and vehicle. It was a lapse in capability that stretched on far longer than anyone inside or outside of NASA could have imagined. Through a series of delays and program cancellations, the same agency that put boot prints on the Moon and built the iconic Space Shuttle had been forced to rely on Russia to carry its astronauts into space since 2011.

NASA would still be waiting to launch its own astronauts had they relied on America’s traditional aerospace giants to get the job done. The inaugural flight of the Boeing CST-100 “Starliner” to the International Space Station in December was an embarrassing failure that came perilously close to losing the unmanned capsule. A later investigation found that sloppy software development and inconsistent testing had caused at least two major failures during the mission, which ultimately had to be cut short as the vehicle couldn’t even reach the altitude of the ISS, to say nothing of making a docking attempt. NASA and Boeing have since agreed to attempt another test of the CST-100 sometime before the end of the year, though a delay into 2021 seems almost inevitable due to the global pandemic.

But America’s slow return to human spaceflight can’t be blamed on the CST-100, or even Boeing, for that matter. Since the retirement of the Space Shuttle, NASA has been hindered by politics and indecisiveness. With a constantly evolving mandate from the White House, the agency’s human spaceflight program has struggled to make significant progress towards any one goal.

Continue reading “NASA’s Long-Delayed Return To Human Spaceflight”

Docking With ISS Isn’t As Easy As You Might Think

Complexity is a funny thing. In prehistoric times, a caveman might float across a lake on a log. That’s simple. But as you add a rudder, a sail, or even a motor, it gets more and more complex. But if you add enough complexity — a GPS and an autopilot, for example, it becomes simple again. The SpaceX Dragon capsule actually docks itself to the ISS. However, the crew on the station can take over manually if they need to. What would that be like? Try the simulation and find out. If you don’t make it on the first, try, [Scott Manley’s] video below might help you out.

This isn’t a flashy Star Wars-style simulator. Think more 2001. Movement is slow and it is easy to get out of control. The user interface is decidedly modern compared to the old Apollo era

Continue reading “Docking With ISS Isn’t As Easy As You Might Think”