PrintStar's Blog
Ramblings of a Fortran Nut
October 25, 2016 by Jeff

Figuring Out Some Networking

In order to bring this Retrochallenge static blog online, I first need to figure out the specifics of networking.  Obviously the Rainbow will be located in my house as opposed to a data center, so I had to devise a way to make it accessible to the world at large.  In the past I had used Dyn’s old dynamic DNS solutions, but I really dislike configuring those setups.  In addition, it reveals my home IP, which I suppose could be dangerous.

Clearly the Rainbow has to connect to a modern-ish machine to act as its gateway.  There is no generally available ethernet card for the Rainbow (although a Univation device is rumored to exist in at least a prototype form), so the Rainbow has to speak serially with a machine with a true network connection.  For this challenge, it will be a brand new Raspberry Pi 3:

The Raspberry Pi will connect to the Rainbow eventually using a USB-to-Serial adapter.  While the Raspberry Pi does have a “serial port” built in, there are a lot of caveats that come along with it (3.3v, no hardware flow control, etc.).  The USB-to-Serial adapters are definitely preferable, in my opinion.

To access the Raspberry Pi, I’ve configured a VPN between it and a Digital Ocean droplet that is able to use nginx to reverse-proxy certain URL patterns over the VPN back to the Raspberry Pi.  The Raspberry Pi will then, in turn, forward these requests to the Rainbow’s address once the SLIP address is established.

While there appears to be many layers, there should be no confusion: the Rainbow will ultimately be serving web pages itself with its own, true HTTP server, albeit through a pair of reverse proxies.

  •   •   •   •   •
January 7, 2014 by Jeff

Prism Improvements and Fixes

Since I don’t have much time tonight, I decided to pop back into the Prism source code to add revision options.  I wanted to be able to diff a working copy against any revision in the repository.  The addition was actually rather simple, and it’s now integrated into the code.  Furthermore, I needed to be able to revert to a specific revision.  The -r switch does that as well when using the revert command.  Awesome!

In the process of checking if these two changes worked, however, I noticed something odd.  In my repository’s database file, I noticed one hash had an extra, extended ANSI character sitting at the end of it.  This mystery character is a sure sign of improper string handling somewhere in the code!  Turns out that, during commit, I don’t zero out the memory for the new hash prior to copying the bytes into it.  The final effect is an unterminated string.  Oops! I went back through the code this evening and sorted out the last of the leaky hashes.

Everything should be good and tight now.  A new executable is provided below:

All fixed!  And a bit better!

  •   •   •   •   •
January 6, 2014 by Jeff

Prism: Local, Nearly Awesome Source Control

After some nasty work, I finally have a workable version control program running on MS-DOS.  Prism now supports my basic requirements: users can add files to be committed, commit code with a message, clear the queue of files to be committed, revert to the previous revision, and perform a diff.  The whole thing is packed into a single, monolithic executable that should work delightfully well on most MS-DOS systems, including Rainbow 100s.

The last bits that needed to be added were reverting changes and performing diffs.  The first bit, allowing to revert local changes, was relatively simple.  The file is just retrieved from storage and extracted on top of the current working copy.  Ideally the user should be able to specify which revision to pull, but it isn’t supported just yet.  It would be a simple change that I just need to get to.

The second bit, performing a diff against the repository, was far nastier.  In keeping with the old “I only want one executable” paradigm, however misguided, I needed to find a clean diff implementation to build into Prism.  After significant searching, I basically realized that:

  1. The only straightforward diff program is GNU’s.
  2. Even the MS-DOS port of GNU diff isn’t simple to compile.

The MS-DOS port of GNU diff was ported to Microsoft C, but lately I prefer working with Open Watcom for MS-DOS development.  Pulling in the diff source and building resulted in plenty of failures.  Additionally, GNU diff is made up of a number of C files that I wasn’t really interested in flipping through in order to fix the port.

I had basically given up when I came across a link to a PDF that provided a diff algorithm from the 1970s.  I opened it and was baffled by much of the theory (in that I couldn’t see immediately how to apply it).  Just before I gave up, though, I saw that it contained the actual source code in C for a working diff program!  The fantastic PDF, a paper by Miller and Myers, can be seen at http://tx0.org/7eq.

After some modifications, I had a diff function built into Prism.  It is not a particularly great diff subprogram, though.  It doesn’t output in the same format as GNU, and it doesn’t include lines surrounding changes.  It does, however, work, which is the most important feature.

So now Prism can diff the working copy against its own repository.  At this point, it should be good enough to use for Retrochallenge.  If you’d like to try it out, have a look:

There’ll probably be more changes this month as I find more points of failure.

  •   •   •   •   •
January 3, 2014 by Jeff

Half of a Version Control Solution

This morning of the third day of the Retrochallenge I committed the third commit of a new program called Prism.  This ridiculous side project is designed to provide basic versioning for source control on MS-DOS, all to support writing what will most likely be a single-file BASIC program.

The goal of Prism is to provide a git-like experience on MS-DOS.  I had a few requirements for the versioning system:

  1. It can’t use timestamps.  Most DEC Rainbow’s do not contain a battery-backed clock chip.  Checking when a file was modified on a Rainbow will inevitably return some date in 1984.
  2. It should be a monolithic executable.  I like having only one command, like “git” or “svn.”
  3. It has to run on an 8088 efficiently-ish.

The above requirements are a bit odd.  Notice that they do not contain branching or any mention of support for subdirectories.  Both of these things will not be supported for now.

To get around the whole “time stamp” issue, I decided to use an MD5 hash of every file to determine if it changed.  It seemed a very git-ish thing to do.

How does Prism work?

To get started with Prism, the user just needs to navigate to their target directory and run:

    prism init

The executable then generates a directory PV in the current directory that contains two files, db.txt and messages.txt.  The first file, db.txt, contains the meat of the versioning system.  The first line contains the revision number, zero immediately following initialization.  All subsequent lines represent a single tracked file, one line each, containing:

  1. A file id number
  2. The last revision committed
  3. An md5 hash of the file from the last revision
  4. The file’s name

So where do the file contents live?  That’s the fun part.

Similar to git, files to be committed must be staged, or, in Prism-speak, queued.  The command

    prism add file.c

queues the file “file.c” for committing.  Files that are queued are added to another file in the PV directory: queue.txt.  You can add the file multiple times; Prism doesn’t particularly care.  Once files are queued, the commit can be made:

    prism commit

When the commit is initiated, the queue is opened and inspected.  A hash is computed for each file to be committed, and, if the file is already tracked in db.txt, it is checked to see if the hash had indeed changed.  If so, or if the file has not yet been tracked, the commit proceeds.

First, Prism adds or updates a line in db.txt. Next, the new file is GZip’d to a file with the format <file_id>.<revision> within the PV directory.  Notice that the filename is not used because of MS-DOS naming restrictions.  We can eliminate the whole issue of having 8+3 filenames in the PV directory by just using the file id numbers.  It does restrict us to 0xFFF revisions under MS-DOS, but that should be enough for most applications for now.  Finally, the commit is confirmed to be complete, and the file is marked as tracked.

When a file changes, Prism will always store a complete, compressed version of the file in its PV directory.  Prism knows nothing of deltas or diffs, so it is reasonably inefficient.  However, it is also extremely simple.  That’s a big plus when it’s only a side project for Retrochallenge.

At this point, Prism only accepts commits.  You can’t yet revert to a previous version because, well, I haven’t gotten to it yet.

Why the name Prism?

A prism refracts light into it’s component wavelengths (effectively, whatever…).  Similarly, Prism stores all the component changes of your programming work.  It’s a loose metaphor.  More importantly, though, it does relate to rainbows which is the namesake of my computing platform of choice.

When will it be ready?

Basically, as soon as Prism supports reverting and, possibly, deleting files, it will be ready for use.  It still lacks a diff utility, but that shouldn’t be too hard to add.  If I’ve missed anything that modern version control should have, please tweet!

I’ll also post some executables here shortly for others to try out.  It actually will work on other platforms (Windows, Linux, etc.), so everyone can give it a go.  Right now it won’t, though; it assumes MS-DOS directory separators…

  •   •   •   •   •
February 6, 2013 by Jeff

Building Python Extensions with Simply Fortran

Aside from maintaining Simply Fortran, I spend a good deal of my time working in Python.  As one might guess, I also spend most of my time working on various versions of Windows these days.  Many (many, many…) people online complain about the difficulties in working with Python on the Windows platform.  Generally speaking, though, I encounter few issues on the Windows platform with the exception of C extensions.

Python modules that incorporate C extensions (or Fortran or C++) require a compiler to be present obviously.   On GNU/Linux systems, there usually isn’t an issue as most distributions either already have or make it trivially simple to install the GNU Compiler Collection.  On Windows, however, the issue  is a bit more complicated.

Python’s distutils module does provide support for a  handful of compilers: Microsoft Visual C++ (the default), Cygwin’s GCC, Borland C/C++ (really?), and MinGW32′s GCC.  Using Microsoft’s compiler introduces some complexity, especially what version to install.  Cygwin usually isn’t desirable as it introduces dependencies on Cygwin’s DLL.  I personally don’t know anyone who uses Borland’s products any longer.  That leaves MinGW as a sensible compiler.

At this point, I’ll assume that the reader has installed Simply Fortran.  The package includes a fully configured and complete version of the MinGW-w64 GNU C, C++, and Fortran compilers.  Additionally, the compilers will be added to the path, so typing gcc –version or gfortran –version at the Windows command prompt should present some compiler version information.  Just having the compilers on the path overcomes one of the larger hurdles in setting up an environment for building Python extensions.

Next, let’s assume that the reader will be working with 32-bit Python on Windows.  64-bit Python on Windows is problematic in that the only supported compiler is Visual C++, adding some additional trouble.  There is currently an enhancement ticket to support MinGW-w64 in the core Python bug tracker, but, at this time, it simply isn’t usable without some annoying steps.  For most purposes, 32-bit Python should be sufficient (at least at the time of writing this post).

The first step is to direct Python’s distutils to always use Simply Fortran’s compiler.  By default, building an extension via python setup.py build is going to result in a cryptic error about a batch file that implies something about Visual C++.  To permanently direct Python to use Simply Fortran’s compiler, you’ll need to either create or edit a file at <Python Installation>\Lib\distutils\setup.cfg, adding the following:

[build]
compiler=mingw32

This little addition directs Python to try to use MinGW32 compilers by default.  However, some users may have noticed a discrepancy.  In the setup.cfg file, we have instructed Python to use MinGW32′s GNU C compiler, but Simply Fortran provides a version of the MinGW-w64 GNU C compiler.  The default output of Simply Fortran’s compiler will be 64-bit code, but we need to build 32-bit code in this described configuration.

The next step is to modify some of distutils code to account for our 64-bit compiler.  The configuration of the MinGW32 compiler can be found in the file <Python Installation>\Lib\distutils\cygwinccompiler.py.  Personally, I would suggest opening it with Simply Fortran as it understands Python code quite well.  Next, search for “-mno-cygwin” in this file.  This text is a somewhat dated compiler flag that instructs GNU compilers to avoid dependencies on Cygwin.  MinGW-w64 compilers (and modern MinGW32 compilers, I believe) don’t understand this compiler option.  In our case, though, we need to instruct the Simply Fortran compilers to build 32-bit code every time.  This search gives us the opportunity to add the flag “-m32” to the compiler flags.  My suggestion is to replace every occurrence of ”-mno-cygwin” with ”-m32” in cygwinccompiler.py.  In Python 3.3, for example, there should be exactly five occurences, all in lines 296 through 300, in cygwinccompiler.py.

Before closing this file, one more change is necessary.  The default configuration also instructs the compiler to link with the Microsoft Visual C runtime that matches with the version used to build the Python interpreter.  Attempting to do this with Simply Fortran’s compiler will almost certainly fail.  Instead, search for the following in cygwinccompiler.py:

self.dll_libraries = get_msvcr()

Change the above line to be:

self.dll_libraries = [] #get_msvcr()

This change just removes the attempted linking with the Visual C++ runtime.  Save cygwinccompiler.py and close the file.

Python should now be configured to build extensions.  As a test, I suggest downloading the Python source archive and attempting to build the example in  PC\example_nt.  Type python setup.py build and watch as Simply Fortran’s compiler builds the C extension module.  For a self-contained non-trivial example, try the crc16 module.

Readers might now be wondering about building NumPy or SciPy extensions (or SciPy itself).  NumPy, however, has its own distutils configuration that requires modification.  If you attempt to build a NumPy extension, things might seem to go well for a while, but it won’t exactly work.  Setting up NumPy is a whole other article.

  •   •   •   •   •
February 4, 2013 by Jeff

Updates to Open Watcom Make

As part of Simply Fortran, I maintain a minor fork of Open Watcom‘s Make utility, which anyone can see on my GitHub account.  Oddly, wmake, the abbreviated name for the utility, does occasionally allow interaction with the user on certain errors.  I’ve seen the occasional error asking if a file should be deleted after compilation fails.  The strangest part of the error is that the behavior is erratic at best.

I decided to change wmake’s default behavior to never interact with the user.  If interaction should ever be allowed, a new switch, -g, can be used.  After implementing it, however, I noticed that a switch to force deleting targets whenever an error occurred.  The -e switch instructs wmake to delete files on errors without a prompt.  I find it odd that the original Open Watcom developer decided to make interaction the default.

The source tree has two points where interaction is occurring.  I’d say there is no harm in defaulting to never talking with the user.  The -e flag, however, will be added to Simply Fortran’s default call to wmake.

Release

I was under the impression that “Release” archives could be uploaded to GitHub.  Apparently the feature was deprecated at the end of last year, though.  For that reason, I’ll post the released binaries here if anyone at all is interested:

If anyone finds any bugs, leave an issue on my GitHub account.  These binaries are provided merely for convenience.

  •   •   •   •   •
January 29, 2013 by Jeff

Python 3.3 on an Atari: Part 3

I ended my last post noting that I had seemingly successfully overcome the disaster that was the Atari’s wide-character support.  There were a few additional hiccups along the way of finalizing the wide-character support.  After having replaced almost every wide-character source file in the MiNTLib, I was still having issues with paths, for example.  It turned out that I had failed to replace the function mbstowcs() since it lived in a file I hadn’t expected.  Finding that gem led to implementing most of musl’s multibyte functionality as well.  With mbstowcs() implemented properly, my Python interpreter was finally reading in actual Python code from its standard library.

The MiNTLib was also missing two minor definitions.  The first was sched_yield(), which appeared defined in a header file, but kept popping up as undefined during the linking phase.   Searching the library didn’t reveal any actual function, so I dropped in a simple stand-in that basically asked the program to sleep for a very brief moment.  The second was nl_langinfo(), a simple function for retrieving a specific aspect of the locale.  Since the Atari’s support of locale’s was pretty minimal in most respects, a basic implementation would suffice.  After these last two bugs, I was able to compile.

I finally found myself faced with a nasty little error.  The interpreter would complain about an ImportError of some sort upon startup.  The most annoying aspect of this particular ImportError was that it was reported by the interpreter as “Could not import runpy module.”  Doesn’t seem particularly useful, right?  Having never heard of such a module, I looked in the standard library for the offending code.  There was a runpy module, but there was no obvious reason why it couldn’t be imported.  I next tried a search to hunt down where the error was issued from.  It turns out that the error originated in the interpreter startup code in Modules/main.c.  I was annoyed to find that, if the import of this module failed for whatever reason, it would spit out this short, vague message and exit.  An error was available, and I still don’t know why the developer who authored this code didn’t spit out the resulting exception.  To fix the issue, I decided to dump the Python error to stdin.

The source of the error appeared to be a failure to import the imp module, which provides much of the necessary infrastructure for, well, importing modules.  The source of the failure was a line where some functions from the _imp module were imported.  The _imp module, in turn, is a C module compiled into Python itself.  I had actually encountered it earlier when trying to figure out the wide-character mess, mistakenly assuming the C _imp module was actually the imp module, which was failing to load thanks to the MiNTLib (in fact, the _imp module internally thinks it is named the imp module…).

The error occurred because the imp module was attempting to load the function load_dynamic from the _imp module.  This function is linked to a pure-C function, imp_load_dynamic(), that is only compiled on platforms where shared libraries are supported.  Because Atari computers effectively have no true shared objects, I disabled all shared libraries during the build, meaning imp_load_dynamic() was never defined.  Becuase it wasn’t defined, the imp module was throwing an error during import.

This bug was reported on the core Python bug tracker after revealing itself.  The simple fix is to either not import load_dynamic at all, which works dandy for the Atari, or to set load_dynamic to None if not present, which is the suggested fix.  By fixing this minor issue, the interpreter was able to spring to life, presenting me finally with a fully function Python 3.3 prompt:

Python 3.3 on the Atari!

  •   •   •   •   •
January 8, 2013 by Jeff

Python 3.3 on an Atari: Part 2

In my previous post about bringing Python 3.3 to the Atari, I mentioned that the end result was yet another completely nonfunctional Python 3.3 executable. In an effort to find out what had gone terribly wrong, I fired up GDB on the ARAnyM virtual machine to sort out what had occurred.

I started with letting the interpretter run to see if an error that I could understand had occurred.  The problem with starting this way is that the Python interpretter is anything but simple.  I don’t mean this description in a bad way, just that blindly walking into what is occurring is somewhat daunting.  In the end, I couldn’t figure a thing out.

The interpretter was crashing with two major symptoms.   First, it complained about the environment and ‘<prefix>’ directories not being defined properly.  This crash seemed particularly odd since it shouldn’t be looking for environment settings; the crash was occurring as  a step in the Python build process after the executable was built but before the system was installed.  Second, it threw an import error complaining it couldn’t import the imp module.  Not loading the imp module concerned me greatly as this was necessary to import anything else.

I started with trying to figure out the failure to import imp. Looking through the builtin C modules, I noticed the import module was trying to call itself  imp. However, a bit further down the road, it was actually assigned the name _imp. In the Lib directory, however, there was an imp.py, which was actually what was necessary.  I spent some time making sure it actually wanted to load the pure-Python file via a combination of GDB and some printf statements.

If this basic module was failing to be pulled in, I though that perhaps something was wrong with the bootstrap process.  At startup, most of the Python fun kicks off with importlib._bootstrap.  I noticed that this Python file existed in the Lib directory, and I decided to throw a few clever print() statements into the code to see where things were going wrong.  Changing this file, however, changed nothing.

Back in the Python C code, I added a few more printf statements to try and track down the issue.  When I rebuilt the executable, though, I was met with an entirely new build error.  An executable named freeze_importlib had caused a nasty error.  This error had obviously never occurred before because I always arrived at a complete, but not working, executable.  Examining the command calling this executable, it was clearly reading in importlib._bootstrap and writing out a header file.

Firing up GDB, I ran freeze_importlib with the same arguments as the Makefile provided.  After a bit of tracing, I found that the failure came when it attempted to compile the Python to bytecode.  I was at a loss.

There were a number of points, though, that I had to keep in mind:

  1. The build didn’t work on the Atari platform – it worked just fine almost everywhere else, though
  2. Python 2.7 did work on the Atari platform – there was some massaging, but nothing extreme
  3. Python 3.x uses Unicode for almost everything – or that was my understanding at least, while Python 2.7 did not

Looking at these three points, I suspected the issue stemmed from mintlib’s embarrassingly incomplete support for wide character functions.  Recall that I had grafted on three functions, wcschr, wcsrchr, and wcstok, from FreeBSD just to get Python to compile.  I had to do a similar procedure with Python 2.7, but I never tested any Unicode functions under that interpretter.  I decided to go out looking for some proper wide character support.

Obviously I wasn’t going to bother looking at GNU libc’s implementations.  I was concerned that those might be a bit confusing.  Using Wikipedia,  I searched for some C standard library implementations that weren’t GNU libc.  I ended up downloading a handful of them and examining their support for wide characters.  The musl implementation, though, seemed the smallest, simplest, and most straightforward.  I especially liked that it was, “Designed from the ground up for static linking,” since there’d be no dynamic linking under FreeMiNT on the Atari.

I didn’t want to replace all of mintlib with musl, just every bit of wide character support.  In the mintlib build tree, I deleted every mintlib mention of wide character functionality, and I created some dynamic links back to the musl library’s directory tree.  After a few speedbumps and editing a list of C files in mintlib, I successfully built a new mintlib with every wide character function replaced.

Back in the Python directory, I decided to reattempt building the Python executable against my new mintlib.  I cleaned and restarted the build process (slow even with ARAnyM on a relatively quick Athlon-based system) and waited expectantly.  I had not un-modified the print() additions in importlib._bootstrap, however, meaning that the freeze_importlib executable would be run again.  When the Makefile reached the freeze step, I smiled as it progressed happily past building the necessary header file, continuing on with the build process.

My smile didn’t last long, though, as the Python executable was launched by the make process.  Once again, an ImportError popped up saying the interpretter couldn’t import imp.  Something was still amiss…

  •   •   •   •   •
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.

  •   •   •   •   •
July 18, 2011 by Jeff

A Long Time Without Updates

As usual life is getting in the way of RetroChallenge. I’m just coming off a busy weekend with a visit from my sister and her husband, and I’m ready to get back into the challenge. Leading up to this past weekend was plenty busy, so I was forced to sacrifice my posting in favor of actual progress towards my goal.

If you look at gempy’s GitHub page, you’ll notice that some significant progress has been achieved. At this point, I’ve implemented wrappers for all the AES (Application Environment Services) calls that I plan to for this challenge, along with a select grouping of useful extras. If I am to re-implement GEM Worm under Python, I’ll still need to wrap a selection VDI (Video Device Interface) calls. However, with some AES functionality present in theory, now is a great time to stop and begin testing.

My first compile attempt since my Pythonic code organization was decided upon was not successful. Most of the errors, I’m hoping, are simply typos and lazy programming. I don’t believe I have any showstoppers at this time, but time is not on my side. I have approximately two weeks remaining, and I still need to author and practice a presentation for PyOhio. I think everything is still possible, but it’ll be tight.

  •   •   •   •   •