When [Mike] fired up his PCjr webserver back in March, he probably wasn’t expecting it to go viral. 2640 hours later, here we are! Not only has his machine run continuously for over 110 days, it also is surviving a global hug of death. All of this is thanks to some very special software.
We see lots of old machines here on Hackaday. We also see lots of minimal web servers. But we don’t see many that can run for thousands of hours, offering up to 8 simultaneous connections. Curious if jr is still up? Check brutmanlabs.org. The whole website is hosted on the 40-year-old machine. If you want to be a bit more kind, here’s a direct link to the text-only status page. While many of those hours were idle, currently lots of folks are hitting that little V20 CPU, so please give it a few seconds to respond.
The PCjr has a few upgrades — the aforementioned V20 CPU upgrade, a jrIDE sidecar, and a memory upgrade to 736 kB to name a few. Ethernet connectivity is via a Xircom parallel port adapter – which is circa 1993. The operating system is IBM PC DOS 5.02. One thing to note is that all these upgrades were possible back in the mid-1980’s when the PCjr was still current. [Mike] could run the system with an MFM hard drive, an ISA ethernet card (via an adapter), and use the original CRT monitor. Older DOS versions would work too — though partition sizes would be limited. The “modern” conveniences are just to keep from wearing out vintage hardware which is quickly becoming rare.
The real glue that holds this all together is [Mike’s] own software: mTCP. mTCP is a full set of tools for running internet applications on systems running MS-DOS or a compatible OS. We’ve seen quite a few mTCP projects over the years. [Mike] has worked tirelessly testing the software, ensuring that it is stable and reliable.
Software is never perfect though – one thing [Mike] didn’t implement is a log roller. Since he has logging turned on, the PCjr was slowly filling up its hard drive. Once the drive was full, mTCP would perform an orderly shutdown — but the uptime will be reset. [Mike] was able to go in and switch off logging with DOS’s DEBUG command. A live patch is not the way one would normally update software – but the fact that he was able to do it shows how deep [Mike’s] knowledge of the software goes.
[Mike] has even provided a live stream recording of the little PCjr handling requests from all over the globe.
Working towards automating a few things in a home often seems simple on the surface, but it’s easy for these projects to snowball into dozens of sensors and various servos, switches, and cameras strewn about one’s living space. The same sort of feature creep sneaks into some of the more popular self-hosted home server platforms as well, with things like openHAB requiring so much computing power that they barely function on something like a Raspberry Pi. [Paulo] thought there should be a more lightweight way of tackling a project like this, and set about building his own smart home server with help from some interesting software.
The project is based around the Dirigera hub from Ikea, partially because [Paulo] is planning to use other smart home devices from Ikea as he can easily find them where he is, and also because these devices tend to use Zigbee, a non-proprietary communications standard. This means that if he ever wants to swap out the hub for another one in the future, it won’t be difficult to do. From here the major hurdle is that using the default software from these devices is fairly limiting, so [Paulo] reached for a Raspbee 2 Zigbee gateway for use with a Raspberry Pi and an extremely lightweight and customizable web server called Mako to make this happen. Using Lua as the high-level language to tie everything together he was able to easily deploy the server to control the Ikea hub and devices and automate them in any way he sees fit.
While it is true that software like openHAB and others already exists to do virtually any home automation task that could be imagined, if you’re looking to do something with a bare minimum of computing power something like [Paulo]’s solution is likely going to be the fastest and most reliable method of getting a few things automated around the home. If you’re looking for something completely open source and built from the ground up, though, we have seen a few alternative smart home solutions like this one which don’t rely on any proprietary hardware or software, but do take a little bit more effort on the user’s part.
The C64 is running Contiki OS, an operating system for 6502-based computers. It’s built with an eye to networking, requiring ethernet hardware for full functionality. In [naDDan]’s case, he’s outfitted his C64 with an ETFE network adapter in the cartridge port to get it online. It serves up the HTML file off a 1541C floppy drive, with the drive buzzing away every time someone loads up the page.
The page itself is simple, showing some basic information on a simple blue background. There is some scrolling text though, as is befitting the 8-bit era. It’s also available in four languages.
[naDDan’s] server can be found here, according to his video, but at the time of writing, it was down for the count. Whether that’s due to a dynamic DNS issue or the simple fact that an 8-bit 6502 isn’t up to heavy traffic is up for debate. Regardless, try for yourself and see how you go. Video after the break.
Hackaday readers fit into two broad categories: those who experienced the wild and woolly early days of the Internet, and those who are jealous that they missed it. And it’s safe to say that both groups will get something out of this aggressively Web 1.0 retro experience, courtesy of a server that was actually part of it.
This comes to us via The Serial Port, a virtual museum dedicated to 90s technology, where curators [Mark] and [Ben] managed to find a pair of Cobalt RaQ 3 servers from the late 1990s. The RaQ was the first true “Internet appliance,” designed to be as simple as possible to set up and operate. If you wanted to get your small business online, machines like these were just the ticket. They were designed to be as plug-and-play as possible, and they did a pretty good job of it, at least for the time.
The machines that showed up were quite the worse for the wear, which is understandable given the decades since they were last relevant, but that just makes it all the more fun to get them going again. One didn’t even come close to booting, but the other showed more promise.
The video below is the first of a three-part series, and has a nice introduction to the RaQ and its important place in the early Internet, as well as a peek inside the two machines. That revealed some leaky caps that needed replacement in Part 2; after that minor surgery and a little persuasion, the 300-MHz screamer was ready for a test run. It worked, and The Serial Port put it right to work in Part 3 hosting a gloriously retro home page. Hit the link at the top of the article and enjoy the 90s all over again — the visitor counter, the mixed fonts, the “Under Construction” animated GIF, and the reminder to bookmark this page in your browser, which was probably Netscape Navigator. We love the guestbook, too. But — no marquee?
Nice job, [Mark] and [Ben], and kudos for keeping this little slice of computing history alive.
At first glance, the Raspberry Pi Pico might seem like a bit of a black sheep when compared to the other offerings from the Raspberry Pi Foundation. While most of the rest of their lineup can run Linux environments with full desktops, the Pico is largely limited to microcontroller duties in exchange for much smaller price tags and footprints. But that doesn’t mean it can’t be coerced into doing some of the things we might want a mainline Pi to do, like run a web server.
The project can run a static web page simply by providing the Pico with the project code available on the GitHub page and the HTML that you’d like the Pico to serve. It can be more than a static web page though, as it is also capable of running Python commands through the web interface as well. The server can pass commands from the web server and back as well, allowing for control of various projects though a browser interface. In theory this could be much simpler than building a physical user interface for a project instead by offloading all of this control onto the web server instead.
The project not only supports the RP2040-based Raspberry Pi Pico but can also be implemented on other WiFi-enabled microcontroller boards like the ESP8266 and ESP32. Having something like this on hand could greatly streamline smaller projects without having to reach for a more powerful (and more expensive) single-board computer like a Pi 3 or 4. We’ve seen some other builds on these boards capable of not only running HTML and CSS renderers, but supporting some image formats as well.
The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.
[Tomaž] uses the “hello world” example from ESP8266WebServer to explain. In it, the main loop essentially consists of calling server.handleClient() forever. That process checks for incoming HTTP connections, handles them, sends responses, exits — and then does it all over again. A simple web server like this one spends most of its time waiting.
A far more efficient way to handle things would be to launch server.handleClient() only when an incoming network connection calls for it, and put the hardware to sleep whenever that is not happening. However, that level of control just isn’t possible in the context of the Arduino’s ESP8266WebServer library.
So what’s to be done? The next best thing turns out to be a simple delay(1) statement right after each server.handleClient() call in the main loop.
Why does this work? Adding delay(1) actually causes the CPU to spend the vast majority of its time in that one millisecond loop. And counting microseconds turns out to be a far less demanding task, power-wise, than checking for incoming network requests about a hundred thousand times per second. In [Tomaž]’s tests, that one millisecond delay reduced idle power consumption at 3.3 V from roughly 230 mW to around 70 mW — about 60% — while only delaying the web server’s response times by 6-8 milliseconds.