BASICODE: software distribution by radio broadcast in the 1980s

▼ In 2009, I started an effort to digitize all my cassette tapes. As my last computer that still has a line in port is facing retirement, I decided to finally finish that project. Perhaps more about this later. Turns out some of these old cassettes have weird things on them, including radio broadcasts that contain computer programs.

Back in the 1980s, home computers didn’t come with any storage. But a Commodore 64 floppy drive cost the same as the computer itself here in Europe. So it was common to use a cheap cassette drive to store programs and data. You could of course buy commercial software and/or exchange copies with friends. But without a modem, which didn’t appear until around 1990, there was no good way to exchange data with larger likeminded groups. It also didn’t help that there were many different home computers and they were all different.

Both these problems were addressed with BASICODE. This was a lowest common denominator subset of the BASIC programming language that all home computers came with. For the essential functions missing from the common BASIC subset, BASICODE provided a set of standardized subroutines. So if you wanted to run BASICODE programs, all you had to do is make the subroutines for clearing the screen, setting the cursor position, et cetera for your specific computer, and you could run all BASICODE programs.

But you still had to get these programs. Solution: a standardized cassette data format. BASICODE for a certain computer model would typically be able to read and write BASICODE from/to cassette. There were also little adapters that plugged into the serial port. These days, we can use the program minimodem to decode BASICODE from WAV files. I pulled pvtmert/minimodem from Docker and used the following to decode my recordings:

docker run --rm -ti -v /Volumes/video/rips:/rips pvtmert/minimodem minimodem -f /rips/basicode.wav --rx -q -S 1200 -M 2400 --stopbits 2 1200 |LC_ALL=C tr '200-377' '000-177' >basicode.txt

(The tr command strips the high bit that is set to 1 in the BASICODE protocol.)

In addition to broadcasting a selection of various user-submitted BASICODE programs, the radio program Hobbyscoop also broadcast a weekly newsletter in the form of a BASICODE program. Turns out I have a recording of the 250th one, from 1989. This is how the program came off of the tape.

After cleaning it up wanted to run the program on my C64 Mini, but for the life of me I couldn’t find the C64 BASICODE subroutines. So I made my own. Get the .prg file here if you want to try for yourself. Or try it here with a Javascript BASICODE interpreter.

Then I decided to see how hard it would be to make BASICODE run in Python. Have a look at the resulting code here. Turns out that with some small syntax differences a lot of BASIC statements are basically the same in Python, and it’s easy enough to implement most missing ones with a few lines of code. The big difference is that in BASIC, you mostly need to structure programs yourself using GOTO statements, while modern languages like Python are much more structured and don’t have GOTO. Also, in BASIC all variables are global. So the porting is easy, but not entirely trivial.

The hardest part was getting reading the cursor position to work properly. In xterm you do this by sending an ANSI escape sequence to the terminal, and then you get one back that you read from standard in. Strangely, this was also the hardest part on the Commodore 64, where I eventually had to call a KERNAL (system) routine to do this.

Permalink - posted 2020-07-04 - 🇳🇱 Nederlandse versie

Transitioning the Mac from Intel to ARM CPUs

▼ There have been rumors that Apple will transition the Mac from Intel CPUs to ARM CPUs designed by Apple itself have been around for some years, and now they've come to a head: apparently, Apple will announce the transition at their WWDC conference a week and a half from now.

CPU transitions are nothing new for Apple. Back in 1984, the original Mac had a Motorola 68000 CPU. This was an advanced CPU at the time, running 32-bit software when cheap computers still used 8-bit 6502 or Z80 CPUs and PCs used 16-bit 8086 CPUs. Still, ten years later the 68000 family had run out of steam and Apple transitioned the Mac to PowerPC CPUs made by Motorola and later IBM.

However, PowerPC CPUs use a completely different instruction set than the one used by the 68K series. Apple largely solved that issue by including an emulator in the system that lets the PowerPC CPU execute 68000 code. Of course new software would be written for the PowerPC CPU. But apparently a good amount of 68000 code persisted for years in classic MacOS. A decade later, it became apparent that the PowerPC was no longer competitive with the Intel and AMD CPUs used in PCs. So in 2005, Apple announced that it would transition to Intel x86 CPUs. (Descendants of the 8086.) Again, Apple provided a way to keep old code running, this time using the Rosetta "dynamic binary translator". However, Rosetta was only used for PowerPC applications, not for parts of the system. These were all 100% x86.

Applications built using Apple's (still new) Xcode development environment would ship as "fat binaries" that contain both PowerPC and x86 code, so the app would run at maximum speed on both types of Macs. In fact, the last PowerPC G5 CPUs and the Core 2 Duo Intel x86 CPUs that Apple started shipping in 2007 were 64-bit CPUs. So a fat binary could even contain 32-bit PowerPC, 64-bit PowerPC, 32-bit x86 and 64-bit x86 code.

The transition from PowerPC to x86 was more complex than the one from 68K to PowerPC because 68K and PowerPC are both "big-endian" while x86 is "little-endian". What that means is that when the CPU stores the 16-bit binary value 11111111000000 in memory at location 3500, in big-endian, location 2000 holds 11111111 and 3501 holds 00000000. In little-endian, the lower part of the number comes first, so 00000000 in 3500 and 11111111 in 3501.

Shortly after announcing the transition to Intel CPUs, Apple allowed developers to buy/rent a development machine with an Intel CPU to test their applications. After the transition, they had to return that system to Apple.

So now, a decade and a half later, it looks like Apple is doing it again.

There are of course many questions. One is whether Apple will transition the entire Mac line, or maybe use ARM for the laptops and keep using Intel for the high end desktops, most notably the Mac Pro. Apple is leading the industry with its high performance ARM CPUs that it uses in the iPhone and iPad. In benchmarks such as Geekbench they often out-perform Intel CPUs, especially for single core tasks. However, I'm not sure how reliable Geekbench is. Also, running very fast for a few seconds is one thing, but doing the same for many minutes is very different and requires a good cooling system.

Also, does it make sense for Apple to compete with Intel and AMD for the highest performance CPUs? Apple doesn't sell too many of these high end systems, so it would be hard to recoup any investments. Still, the rumors indicate that the whole line will transition. But I still expect the non-pro laptops to adopt ARM first and the pro desktops to be the last.

Another big question is whether there will be some kind of emulation or translation this time, so existing x86 apps can run on the new ARM Macs. On the one hand, Apple is a forward-looking company that doesn't like bending over backwards to maintain the status quo. But they're also pragmatic if they need to be. For instance, they only shipped 32-bit Intel CPUs for about a year, but they didn't wait for 64-bit ones and subsequently had to support 32-bit CPUs for a good number of years.

All in all, I think they'll skip emulation and translation. They killed off 32-bit applications last year with MacOS 10.15 Catalina. There's probably still a few applications that are built with other tools than Apple's Xcode, but those must be very rare. Obviously Xcode will make it as easy as possible to create a fat binary with 64-bit x86 and 64-bit ARM code. So any application under active development, which of course includes Apple's as well as the big ones from Microsoft and Adobe that are sold as subscriptions, should be available as fat binaries that run on ARM Macs quickly, if not immediately. And that's probably enough for a good swath of Mac users.

I do wonder how many changes are necessary for existing apps to compile for and run on ARM. As ARM is little-endian like x86, and hand-crafted assembly code that was still common in the 1990s is barely used anymore, I believe "porting" applications to ARM will be very easy.

But what about testing? Do developers need an actual ARM system running MacOS to test their applications, or will the ARM versions behave the same as the x86 version so separate testing on ARM is unnecessary? (Obviously it helps to have an actual ARM system to test ARM-specific features and optimize performance.) Apple could sell/rent development machines like in 2005, but that seems difficult, with so many developers and all the current logistics/economics issues. I'm sure many people within Apple won't like the idea of using an iPad with a keyboard and a mouse or trackpad as an ARM development system. Then again, those iPads are already out there and can go back to being regular iPads after the transition is over, so it's a very pragmatic solution. Or perhaps emulation will work in the opposite direction this time around: a very precise ARM emulator so developers can test their applications without needing ARM hardware.

It's all very interesting, but at the same time I'm in no hurry to upgrade to an ARM Mac. I just hope that this transition will end the relentless push to change all kinds of things in MacOS and allow some time for consolidation and stability. With the Intel transition, I waited until 2007 and was pretty happy with the MacBook Pro I got then. So I'd be surprised if I ended up with an ARM Mac before mid-2022.

Permalink - posted 2020-06-12

RPKI tools and deployment

▼ Recently, Cloudflare launched Is BGP safe yet?. And they immediately answer their own question: No.

What they're getting at is RPKI deployment. RPKI is a mechanism that lets the owner of a block of IP addresses specify which network gets to use those addresses. (Which AS gets to originate a prefix, in BGP speak.) RPKI protects to some forms of (mostly accidental) address hijacking. But for RPKI to work, the address owner needs to publish a "route origination authorization" (ROA) and networks around the globe need to filter based on these ROAs.

Five years ago, I wrote that RPKI is ready for real-world deployment. So where are we now? The US National Institute of Standards and Technology (NIST) has a very nice RPKI deployment monitor, showing the following graph:

So globally, for just about 20% of all prefixes (address blocks) RPKI checks out (valid). For a little less than a percent, the way the address block is routed is not in agreement with the ROA (invalid). For the remaining nearly 80% of prefixes, no ROA is published (not-found). However, these numbers are different in various parts of the world:

• North America: 9% valid, 0.3% invalid, 91% not-found
• Europe: 34% valid, 1% invalid, 64% not-found
• Asia-Pacific: 18% valid, 1% invalid, 81% not-found
• Latin America: 30% valid, 1% invalid, 69% not-found
• Africa: 5% valid, 0.5% invalid, 95% not-found

These numbers show how many address owners are publishing ROAs. This is very easy to do. Here in the RIPE region, it's just a few clicks in the LIR portal. The harder part is filtering based on RPKI. For this you need validator software, for which there are now several choices, and then you need to hook up the validator to your routers, explained here for Cisco and here for Juniper.

For some time, I feared networks would hesitate to filter out prefixes with the RPKI state "invalid", because there's still several thousand prefixes that are invalid. However, it now looks like there are enough big networks doing this that the onus of working around the resulting breakage is correctly put on the address owners / networks that cause the "invalid" state rather than the networks doing the filtering.

Is BGP safe yet? as well as a RIPE labs RPKI test tell you if your ISP is filtering RPKI invalid prefixes, with Cloudflare also naming and shaming the big ones that don't.

The RPKI Observatory has a list of prefixes that have the RPKI invalid state and are therefore unreachable with RPKI filtering enabled. The Route Views collector now also has RPKI, letting you check the state of individual prefixes (telnet route-views.oregon-ix.net). Or use the NLNOG RING looking glass.

Permalink - posted 2020-05-04