Reconstructing Data From A Corrupt Apple ][ Floppy Disk

January 27, 2021 by Maya Posch 47 Comments

Back in 1990 [Benjamin Zotto] wrote – while in elementary school – a dog racing game called Wonderland 2. The BASIC source code and images for the game were stored on a single ProDOS formatted, soft-sectored 5.25″ floppy disk. Fast-forward thirty years to today and [Benjamin] found to his dismay that ProDOS could no longer read the floppy, giving an I/O error. Not deterred, he set about to recover the data, as documented in this Twitter thread.

Applesauce visualization of the patterns on the corrupted disk, with soft-sectoring spiral arms.

The gist of the story is that the floppy disk’s surface could still be scanned with help from the aptly named Applesauce Floppy Drive Controller, which got the following visualization of the magnetic patterns on the disk surface:

This data could then be analyzed sector by sector, with the bad sectors and the cause for ProDOS flaking out with its reading attempts here marked in red.

Checking the data recovered so far confirmed that it was a ProDOS disk. It also confirmed that the sector containing the directory listing was shot. This required diving into the technical reference manual for ProDOS and its filesystem to figure out how to reconstruct the directory layout. This required figuring out the offsets and sizes of the files, assisted by knowing what was likely on the disk, and having some bits and pieces of the original volume listing still intact. This allowed for the directory volume to be rebuilt, one byte at a time.

Sectors on the disk, with bad sectors in red.

At the end of that arduous and highly educational journey success waited, and [Benjamin] was once again able to relive his memories of 1990s BASIC and hand-drawn bitmap graphics.

NASA Challenge Offers Prizes For Sprouting Astronaut Food Systems

January 25, 2021 by Maya Posch 53 Comments

Humans have unfortunately not yet evolved the ability to photosynthesize or recharge from an electricity source, which is why astronauts well into the future of spaceflight will need to have access to food sources. Developing ways to grow food in space is the focus of the new Deep Space Food Challenge that was just launched by NASA and Canada’s Space Agency (CSA).

With a total of twenty $25,000 USD prizes for US contestants and ten $30,000 CAD prizes for the Canucks in Phase 1 of the challenge, there’s some financial incentive as well. In Phase 2, the winning teams of the concept phase have to show off their kitchen skills, and in the final Phase 3 (deadline by Fall 2023) the full food growing system has to be demonstrated.

The possible systems here would likely involve some kind of hydroponics, aeroponics or even aquaponics, to save the weight of lugging kilograms of soil into space. None of this is truly new technology, but cramming it into a package that would be able to supply a crew of four with enough food during a three-year mission does seem fairly challenging.

The NASA rules are covered in their Phase 1 Rules PDF document. While international teams are also welcome to compete, they cannot receive any prizes beyond recognition, and Chinese citizens or companies with links to China are not to allowed to compete at all.

Porting Firefox To Apple Silicon: Tales From The Trenches

January 22, 2021 by Maya Posch 16 Comments

For any smaller and larger software product that aims to be compatible with Apple’s MacOS, the recent introduction of its ARM-based Apple Silicon processors and MacBooks to go with them came as a bit of a shock. Suddenly one of the major desktop platforms was going to shift processor architectures, and with it likely abandon and change a number of APIs. Over at Mozilla HQ, they assumed that based on past experiences, Apple’s announcement of ‘first Apple Silicon hardware’ would also mean that those systems would be available for sale.

Indeed, one week after the November 10th announcement Apple did in fact do so. By then, Mozilla had worked to ensure that the Firefox codebase could be built for Apple Silicon-based MacOS. Fortunately, through the experiences of running Firefox on Windows-on-ARM, they already had gained a codebase that was compatible with 64-bit ARM. Ultimately, the biggest snag here was the immature Rust language and dependency support for Apple Silicon, which set back the first release.

When it came to the distributing of Firefox on Intel- and ARM-based Macs, the decision was made to package both versions of the application into a so-called Universal Binary. While this pads out the size of the installer, it also means easier distribution and would not affect the built-in updater in Firefox. This also allowed for an easy fix for the Google Widevine DRM module, for which no Apple Silicon version was available at first, allowing the same module for Intel to be used with either Firefox version via the Rosetta 2 binary translator in MacOS (as we covered previously).

After this it was more or less smooth sailing, with some Rosetta 2-based glitches and MacOS Big Sur-related bugs that spoiled some of the fun. What this experience shows is that porting even a big codebase like Firefox to Apple’s new platform is fairly straightforward, with lack of support from toolchains and other dependencies the most likely things that may trip one up.

The Rosetta 2 feature, while helpful, also comes with its share of gotchas as the Firefox developers found out, and of course there is a lot more optimization that can (and should) be done for such a new platform.

Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411

January 20, 2021 by Maya Posch 79 Comments

For many years now, the so-called ‘Blue Pill’ STM32 MCU development board has been a staple in the hobbyist community. Finding its origins as an apparent Maple Mini clone, the diminutive board is easily to use in breadboard projects thanks to its dual rows of 0.1″ pin sockets. Best of all, it only costs a few bucks, even if you can only really buy it via sellers on AliExpress and EBay.

Starting last year, boards with a black soldermask and an STM32F4 Access (entry-level) series MCUs including the F401 and F411 began to appear. These boards with the nickname ‘Black Pill’ or ‘Black Pill 2’. F103 boards also existed with black soldermask for a while, so it’s confusing. The F4xx Black Pills are available via the same sources as the F103-based Blue Pill ones, for a similar price, but feature an MCU that’s considerably newer and more powerful. This raises the question of whether it makes sense at this point to switch to these new boards.

Our answer is yes, but it’s not entirely clearcut. The newer hardware is better for most purposes, really lacking only the F103’s dual ADCs. But hardware isn’t the only consideration; depending on one’s preferred framework, support may be lacking or incomplete. So let’s take a look at what it takes to switch. Continue reading “Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411” →

The (Probably) Most Thoroughly Commented Linker Script For The SAM D21 MCU

January 19, 2021 by Maya Posch 5 Comments

Linker scripts are one of those things which nobody who does software development really wants to deal with, but like many things in life sometimes they are inevitable to make things work. Although one could keep pretending linker scripts do not exist and let IDEs handle such pesky details, some of us suffer from this unfortunate condition called ‘curiosity’ and just have to know. People like [Thea].

Recently, [Thea] wrote a blog post on exactly what the linker script generated by the Microchip IDE for a Cortex-M-based SAM D21 project does. The result is a nicely annotated overview of the file’s contents, accompanied by links to the Arm and GCC documentation as well as other references where appropriate. The entire linker script (.ld file) can be viewed on GitHub. With the SAM D21 being a popular choice for Arduino and Arduino-compatible board, this article is a good starting point to understanding what a linker script does and how it affects one’s project.

For other (Cortex-M) MCUs this linker script is also useful as a starting point. Especially knowing which sections are required and what changing them affects in the final (ELF) binary and the firmware that is ultimately written to the MCU. We recently covered linker scripts for Cortex-M as well, along with the concept of memory-mapped I/O.

NVMe Blurs The Lines Between Memory And Storage

January 13, 2021 by Maya Posch 50 Comments

The history of storage devices is quite literally a race between the medium and the computing power as the bottleneck of preserving billions of ones and zeros stands in the way of computing nirvana. The most recent player is the Non-Volatile Memory Express (NVMe), something of a hybrid of what has come before.

The first generations of home computers used floppy disk and compact cassette-based storage, but gradually, larger and faster storage became important as personal computers grew in capabilities. By the 1990s hard drive-based storage had become commonplace, allowing many megabytes and ultimately gigabytes of data to be stored. This would drive up the need for a faster link between storage and the rest of the system, which up to that point had largely used the ATA interface in Programmed Input-Output (PIO) mode.

This led to the use of DMA-based transfers (UDMA interface, also called Ultra ATA and Parallel ATA), along with DMA-based SCSI interfaces over on the Apple and mostly server side of the computer fence. Ultimately Parallel ATA became Serial ATA (SATA) and Parallel SCSI became Serial Attached SCSI (SAS), with SATA being used primarily in laptops and desktop systems until the arrival of NVMe along with solid-state storage.

All of these interfaces were designed to keep up with the attached storage devices, yet NVMe is a bit of an odd duck considering the way it is integrated in the system. NVMe is also different for not being bound to a single interface or connector, which can be confusing. Who can keep M.2 and U.2 apart, let alone which protocol the interface speaks, be it SATA or NVMe?

Let’s take an in-depth look at the wonderful and wacky world of NVMe, shall we?

Continue reading “NVMe Blurs The Lines Between Memory And Storage” →

Visualizing Ionizing Radiation With DIY Plastic Scintillators

January 12, 2021 by Maya Posch 16 Comments

Although most types of radiation are invisible, except for the visible part of the EM spectrum, there are many ways that we can make various types of radiation visible. One of these methods is called ‘scintillation’, which can be used to make ionizing radiation visible. Recently [Lukas Springer] demonstrated how to make scintillators out of what is essentially plastic: bisphenol-A (E45, ‘epoxy’) resin with hardener and other additives.

The essential principle of operation behind a scintillator is its sensitivity to ionizing radiation, along with the tendency to absorb the energy and re-emit it in the form of light, i.e. luminescence. This is akin to the luminescence of LEDs, except that in their case the underlying principle is that of electro-luminescence. In the case of a plastic scintillator, the scintillating material is suspended in the solid polymer matrix base.

As [Lukas] points out, plastic scintillators are hardly ideal when it comes to their sensitivity to ionizing radiation, but they compensate for this by being easy to shape and produce, while being very durable. For this experiment, he used regular epoxy as the scintillator matrix, p-Terphenyl as primary scintillator and Coumarin 102 as the wavelength shifter. These three compounds act as a reaction chain, with the matrix absorbing the radiation and transferring it to the primary scintillator, which in turns emits the energy as light.

As the primary scintillator tends to radiate in the deep UV part of the EM spectrum, a wavelength shifter (i.e. secondary scintillator) which ‘shifts’ the emitted UV radiation into the visible part of the spectrum.

After producing a batch of plastic scintillators following the above recipe, [Lukas] irradiated them with gamma radiation, and found them to perform worse than some already not remarkable Russian PS-based scintillators. [Lukas’s] guess is that the matrix may be absorbing the primary scintillator’s output, or a mismatch between the primary and second scintillator.

While tricky to get right, it does seem like a fun hobby if one has some interesting in chemistry. [Lukas] (@GigaBecquerel on Twitter) provides a basic recipe as well as many other compounds to use for the primary and secondary scintillator, as well as the matrix compound. Enough to get started with.