[ Phillip Heller is a member of the Prodigy Preservation Project. Here, he writes about his progress since Part 1 in January. –Benj ]

Reverse engineering Prodigy is not without challenges. Though the patent describes the communications protocol and the TBOL language well, it lacks detail of the application protocols – that is, the communications between the Reception System and the server-side applications like Logon, Enrollment, Messaging, and so on.

The progress made last time was to implement the communications protocols and to get the reception system to think it was connecting to the server. Now, we need to move beyond that.

After several months on other projects, I’ve freed up some time, made some significant progress, including successful Reception System login, which I’ll detail below.

Reception System Progress

First, I’ve adjusted my testing environment to use the oldest available Reception System (herein also “RS”). It’s likely closest to the patent source and offers the greatest chances for initial success. Also, it interpreted only TBOL, whereas later RS major versions also interpret a successor language, PAL, about which less is known.

Second, I started sending random responses to the login request, determining that the RS hangs on responses too small, immediately errors on responses too large, and gives an API 17 error upon a 31 byte response. Digging into the patent source, I found the error indicated an invalid system date/time. Further search of the source suggests that the server response included date and time in the form HHMMSS MMDDYY (or vice versa). Yet further experimentation led to the RS entering “online enrollment”!

At this point, I had implemented TCS and DIA as described before, but further had to implement TOCS (Trintex Object Caching Subsystem). This is the mechanism the reception system uses to retrieve “objects”, which could be TBOL programs, NAPLPS images, other related elements, or combinations of these things. From the patent source, I discovered how to identify and respond to such requests, either with the requested object, or with a message indicating that the client already has the latest version. I have also determined how usually static objects can be version checked and updated.

After this was a trial and error procession through online enrollment, finding which “error” and “help” message objects were in any of the collected STAGE.DAT files I have. Sadly, some were missing, but I was able to decipher the format and synthesize placeholders for the messages. At the conclusion of enrollment, the RS sends a message to a different DIA destination, containing all the data provided during enrollment. More on this later. With this, the RS expects an enrollment response that looks much like the logon response, and it then requests TLOT0011.PG, which turns out to be the “Highlights” page. Since this content was relatively volatile, it was likely never marked cacheable. I synthesized a minimal version of this, to continue further.

There is still a great deal of work left before the service could be used again, but I am very optimistic.  In order to preserve the sense of discovery when this is made publicly accessible, I will share just a small visual teaser of the reception system in actual operation.  Beyond what you see in the animated GIF above, there is partial functionality of other aspects of the service, but I will save those details for a future post.

Other Developments

In early September, I also renewed my efforts to contact former employees and solicit more historical artifacts.  I contacted Carol Kopp who put me in touch with Peggy Miller. Peggy had a sizable archive of historical documentation and artifacts collected by another former employee, Kurt Steinwascher.  With Kurt’s permission, Peggy shipped me a 15lb box of CD-ROMs, printed materials, and one VHS cassette. Another huge thanks to Les Briney who has patiently answered many questions about decisions made over 3 decades ago.

I’ve yet to inspect the VHS cassette, but I’ve inspected the CD-ROMs and …. wow!  Among the trove is thousands of pages – largely internal communications from Prodigy’s intranet (the IBM Professional Office System; “Notes” was equivalent to email), but also of some documents of varying technical depth.  Among the technical documents are ~ 30 pages of TBOL source excerpts, some application design documentation (e.g., “Messaging”, its windows, fields, actions, etc.), and the “Application Developers Reference Manual (ADRM).” Also included was some documentation of the “Household” and “User” profiles that would be stored in the Server database, including a unique numeric column identifier (these columns being known within Prodigy as “TACS”).  Incidentally, the column identifiers are present in the request sent by the reception system at the conclusion of enrollment, preceding each value.

The ADRM is definitely the golden nugget, but the diamond is the ~ 8 hour video of another former employee, the late Richard Merritt, giving what was internally called “The TBOL class.” This class is essentially an annotated version of the ADRM. Together, these materials cover what is in the patent, but with a little more depth, and greater context.

With this additional detail, and the help of several volunteers who transcribed a great deal of the patent source, I was able to understand a few things that remained confusing in TBOL. As a result, I constructed a TBOL disassembler that produced this excerpt from the TBOL application TLPI1010.PGM, which processes the logon response:

Note the observation about TPF returning a 2-digit year. I’ve not yet looked into the login programs from subsequent Reception System versions, but this very well might be evidence of the reason given for the shutdown of Prodigy Classic.

What’s Next

• Implement more DIA protocol headers and packet serialization / deserialization (FM4, FM9, FM64)
  • these are necessary to communicate status and errors between the server and reception system as well as enable communication from the reception system applications that expect the server component to be external to Prodigy – Eaasy Sabre or Dow Jones, for example.
• Implement TCS supervision (handle WACK / RXMIT / related timers)
• Implement a persistence layer that exposes the database columns via the TACS column identifiers, and stores objects
• Implement a TOCS micro-service that consults the database for version checks and content, and dynamically synthesizes the Reception Contol Object
• Build a tool to manipulate objects in the database and regenerates the jumpword primary and secondary indices
• Build micro-services that interact with the database for Logon, Enrollment, and Messaging
• Refactor the server to dispatch communications to these micro-services as appropriate based on the DIA Destination ID
• Continue to synthesize more content
• Longer term, further troubleshoot the RS8+ issues with the current TCS implementation (it reports CRC errors for object responses that exceed a single packet in length.)
• Clean up and organize the materials I’ve received and share them
• Plan for public accessibility, launch the service, and share the server source code.

Where We Can Use Help

• We are still interested in any artifacts, especially STAGE.DAT from C:\PRODIGY (or from floppies, as the client was distributed before having a hard disk was expected)
• Technical help to do the implementation work described above
• Artistic and Design help in synthesizing the visual content

If you have any Prodigy-related material to contribute, please email either myself (Phil Heller) or Benj Edwards. More updates to come!

Tags: modems, online, online services, Phillip Heller, Prodigy, Prodigy Preservation Project

This entry was posted on Friday, December 17th, 2021 at 2:07 pm and is filed under BBS History, Computer History, Everything Else, Internet History, News & Current Events, Vintage Computing. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.