PrintStar's Blog
Ramblings of a Fortran Nut
January 7, 2013 by Jeff

Python 3.3 on an Atari: Part 1

Back in 2011, I successfully attempted to get Python 2.7 running on the Atari platform, culminating in a PyOhio presentation demonstrating the port. I pointed out during that presentation that my ultimate goal was to bootstrap Python 3.x on the Atari, but my successful compilation of the interpreter yielded an executable that didn”t seem to do anything. After having a subsequent talk rejected from PyCon (twice, actually, and I”m starting to think nobody cares about Python on the Atari…), I let the project simply fade.

Over the last few weeks, however, I decided to give it a shot once again for fun. I recompiled the latest ARAnyM emulator for two of my desktops and set out again on this adventure in retrocomputing.

About the Atari

My goal was to compile Python 3.3 for the FreeMiNT operating system running on the Atari ST/TT/Falcon line of computers. The last Atari-built computer was probably manufactured in the early to mid nineties, making the platform somewhat dated. The machines ran on the Motorola 68k series of CPUs. The FreeMiNT operating system, originally known as MiNT, then MultiTOS, then MiNT again, and finally FreeMiNT, is an odd concept to people unfamiliar with the Atari platform. Basically, the operating system provides a BSD kernel with full preemptive multitasking for the Atari machines. The odd part is that FreeMiNT doesn”t actually replace the entirety of the Atari”s operating system in ROM, TOS; rather, it simply replaces the parts that need replacing to allow multitasking. It”d be as if the Linux kernel could boot from DOS, but allow DOS sound drivers to manage sound cards or something equally as odd.

FreeMiNT is normally beefed up with a significant number of add-ons. Basically, my current install on the ARAnyM virtual machine boots into a Atari TOS-compatible GUI comprised of a replacement Virtual Device Interface (fVDI) and Application Environment Services (XaAES). Additionally, using TosWin2, I can open a bash prompt on the machine, where it behaves similar to most UNIX-y free operating systems, the big difference being that it continues to maintain full compatibility with the bare Atari TOS (more or less, but let”s not stroll down that path).

Since I can get to a bash prompt, one might think that the only step involved in building Python on the Atari is a pair of commands: configure and make. There is, of course, far more involved.

Compiling on the Atari

Under FreeMiNT, the de facto compiler continues to be GCC 2.95.3. There are more modern versions available for the platform, but only 2.95.3 is packaged for the SpareMiNT distribution, an RPM-based FreeMiNT installation and arguably the only one still maintained. Using 2.95.3 from SpareMiNT also has the added bonus of allowing prebuilt binary libraries to be used rather than having to manually build Python”s meager dependencies.

There are ports of the GCC 4 series to compile Atari software. However, most ports are cross compilers, requiring the software to be built on a PC. Anyone familiar with building CPython should know that cross compiling Python is basically never suggested. Additionally, the Atari line of computers are desktop systems, not embedded devices; having to cross compile software for them feels dirty and pointless.

To build Python, in this case, I decided on sticking with GCC 2.95.3 as planned. So now I can just type configure and make, right? You can, but you”ll immediately get some errors. Actually, using the stock Python distribution, you”ll get relatively far before encountering an error in a Python header file itself. Before we dig into what”s wrong with Python, though, we first need to discuss the problems surrounding mintlib.

Although FreeMiNT mostly relies on GCC as its compiler, it does not use the GNU Libc standard library. Rather, it uses a C runtime library called mintlib. This C runtime library is a mishmash of standard C functions as one would expect with some of the historically lesser used functions grafted on from various other implementations. Different portions are governed by different licenses, including old and new BSD and the GNU GPL. I”m not sure mintlib is actually conforming to some of the licenses, but it”s obscure enough that probably nobody will care.

During my work porting Python 2.7, I encountered some missing standard library calls related to wide characters. The Atari runtime library did not contain wcschr() and wcsrchr() functions. I threw together a little library containing these function from their FreeBSD implementations, allowing me to build Python 2.7 to completion. I also needed to do this when I attempted to build Python 3.2 during that same period, but, as I said, the resulting executable was completely nonfunctional.

I decided to do the same thing here to get Python 3.3 booting. Basically, I built a little library containing the two functions above and wcstok(), another missing function, to get the build to progress. Although I was able to get the build to complete (with some other changes I'll explain in a later post), I ended up with a completely nonfunctional executable once again. My first reaction was to give up, but I decided to continue my quest for Python 3.3 on an Atari machine.

  •   •   •   •   •

Leave a Reply