Bringing the Rainbow Up Again

Posted on January 6, 2017

Last month I was finally able to debug the issues with uIP-FOSSIL when compiled with Turbo C 2.0 on a DEC Rainbow 100. I had started modifying the web server code to recognize that the client supported GZIP compression, and, if so, serve up a compressed version of the requested file. The modifications were a little complicated just because of how convoluted some of the uIP code is. However, my real goal was to finally compile the TCP/IP stack on an actual Rainbow.

Originally the issue was related to Turbo C 2.0's inability to cope with UNIX-style line endings. Any file that didn't use CRLF would compile, but the object file would be empty. Due to the oddness of the uIP codebase, Turbo C actually managed to create a completely nonfunctional executable without producing meaningful warnings. After the frustrating task of correcting line endings in every file, I had to start determining why uIP didn't actually work.

Debugging with "printf" can be frustrating, especially when compilation is handled on an 8088 CPU. I was able to determine that the web server was actually receiving correct headers, but it never seemed to send any information back. For a few frustrating weeks, I continued instrumenting the code until I finally narrowed it down to a single, messy statement. Apparently, Turbo C wasn't handling a bitwise AND properly, or, at least, in the expected manner. This commit fixed the miserable issue in the socket code.

So I've moved the blog back to a Rainbow. With GZIP support, pages should serve up nearly twice as fast, which is still painfully slow. It doesn't matter, of course, because serving pages of an 8088 machine is just cool...