A ChatGPT client running on an IBM Portable PC

MS-DOS Client Brings ChatGPT To The IBM PC

AI-powered chatbots are clearly the future of computing, and it’s only a matter of time before you’ll see them appear on every internet-connected gadget. If you thought you were safe from this by sticking to an ancient MS-DOS PC though, think again: [Yeo Kheng Meng] has recently written a ChatGPT client that runs on DOS.

[Yeo Kheng Meng] didn’t cheat by simply running MS-DOS on a modern PC, either: he tested the client on a real 1984 vintage IBM 5155 Portable PC. This semi-portable PC/XT model sports a 4.77 MHz 8088 CPU, 640 kB of RAM and a CGA video card with a built-in monochrome monitor. An NE2000 ISA network card, running in 8-bit mode, enables the Portable to connect to the internet.

Running the client couldn’t be simpler: just run doschgpt.exe and type in your question. [Yeo Kheng Meng] developed this program using the Open Watcom C/C++ compiler, which was the compiler of choice for most DOS game developers back in the day. Networking support was provided by an era-appropriate packet driver together with MTCP, a TCP/IP stack developed by [Michael Brutman] for DOS-based internet applications.

Connecting to the ChatGPT API and parsing the results was pretty straightforward, but implementing the required TLS encryption was not. Even if there was a library available for MS-DOS, the 5155 wouldn’t have enough CPU power to run it in real time, so [Yeo Kheng Meng] decided to run that bit of the networking stack on a modern PC and send an unencrypted HTTP stream to the DOS client.

The end result is a delightful retro-futuristic setup that seems to have come straight out of a 1980s science fiction movie. We can already picture it together with a Commodore 64 reporting the news and an IRC server running on an IBM PC. Continue reading “MS-DOS Client Brings ChatGPT To The IBM PC”

Building MS-DOS From Scratch Like It’s 1983

Building a complete operating system by compiling its source code is not something for the faint-hearted; a modern Linux or BSD distribution contains thousands of packages with millions of lines of code, all of which need to be processed in the right order and the result stored in the proper place. For all but the most hardcore Gentoo devotees, it’s way easier to get pre-compiled binaries, but obviously someone must have run the entire compilation process at some point.

What’s true for modern OSes also holds for ancient software such as MS-DOS. When Microsoft released the source code for several DOS versions a couple of years ago, many people pored over the code to look for weird comments and undocumented features, but few actually tried to compile the whole package. But [Michal Necasek] over at the OS/2 Museum didn’t shy away from that challenge, and documented the entirely-not-straightforward process of compiling DOS 2.11 from source.

The first problem was figuring out which version had been made available: although the Computer History Museum labelled the package simply as “MS-DOS 2.0”, it actually contained a mix of OEM binaries from version 2.0, source code from version 2.11 and some other stuff left from the development process. The OEM binaries are mostly finished executables, but also contain basic source code for some system components, allowing computer manufacturers to tailor those components to their specific hardware platform.

Compiling the source code was not trivial either. [Michal] was determined to use period-correct tools and examined the behaviour of about a dozen versions of MASM, the assembler likely to have been used by Microsoft in the early 1980s. As it turned out, version 1.25 from 1983 produced code that most closely matched the object code found in existing binaries, and even then some pieces of source code required slight modifications to build correctly. [Michal]’s blog post also goes into extensive detail on the subtle differences between Microsoft-style and IBM-style DOS, which go deeper than just the names of system files (MSDOS.SYS versus IBMDOS.COM).

The end result of this exercise is a modified DOS 2.11 source package that actually compiles to a working set of binaries, unlike the original. And although this does not generate any new code, since binaries of DOS 2.11 have long been available, it does provide a fascinating look into software development practices in an age when even the basic components of the PC platform were not fully standardized. And don’t forget that even today some people still like to develop new DOS software.

A computer green screen image of an IRC message of the day

IRC Server For MS-DOS

The recent flurry of projects based around Internet Relay Chat (IRC) should be a fair indication that the beloved protocol is not going anywhere. Now, thanks to [Mike Chambers], you can add to the IRC ecosystem by hosting your very own MS-DOS based IRC server.

This port of ngIRCd (Next Generation IRC Daemon) has already been spun up on 8088-based PCs running at just 4.77MHz, but you’ll still need at least 640KB of RAM. If your vintage IRC server takes off, you might want to think about dropping in an 10MHz V20 for a bit of a performance boost. Even so, it’s impressive that this server can get up on the 40-year-old IBM 5150, and should absolutely scream on an AT-class system.

The limitations of the 16-bit platform means that SSL and ZLIB are unsupported, and Mike has capped total connections at 50 in his port (however, this limitation can be adjusted by rebuilding from source, should you want to find out how far 640KB of RAM can take you). You’ll also need a few other things to get your server up and running, such as a packet driver for your network card and an mTCP configuration file.

Setting up your own IRC server is arguably a right rite of passage for most hackers and tinkerers, but getting this up and running on a decades-old beige box would make for a fun weekend project. [Mike] has all the juicy details on GitHub, and you can check out a test server running the latest build over at irc.xtulator.com.

Also, don’t forget to visit the #hackaday IRC channel over on irc.libera.chat.

[Thanks Sudos for the hot tip]

Translate Your CP/M Code To 8086, And Leave The 1970s Behind!

“Bring our home computing out of the 1970s and into the 1980s and beyond” is the irresistible promise made by the creator of 8088ify, a piece of software which translates CP/M executables from their 8080-based originals to assembler code that should run on an 8088 under MS/DOS. How can we resist such a futuristic promise here in 2021, even though the code wasn’t written to the sound of Donna Summer or the Village People back in the day but here in 2021 for PCjam, a celebration of the original IBM PC’s 40th anniversary.

As the writer of this code [ibara] points out that Intel intended the 8088 to be a ready upgrade path for the 8080, and designed its instruction set while not directly compatible, to make translation between the two a straightforward process. There was commercial software for the task at the time, but to this day there remained nothing with an open-source licence. It’s written in ANSI C for portability across platforms and compilers, and can even be compiled under CP/M itself.

PCjam is well worth a look, and if any of you fancy a go at writing for the earliest MS-DOS machines we’d like to suggest you create something for it. Meanwhile if you’d like to explore CP/M, you can run a bare metal emulator on the Raspberry Pi.

Header: Thomas Nguyen, CC BY-SA 4.0.

35C3: A Deep Dive Into DOS Viruses And Pranks

Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.

So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.

We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.

Continue reading “35C3: A Deep Dive Into DOS Viruses And Pranks”

Tiny Ray Tracer Fits In 64 Bytes

Throughout human history, people try to make the biggest, the fastest, and — sometimes — the smallest. [Hellmood] falls into the latter category and proves it with a 64 byte interactive 3D raycasting application for MSDOS.

Why MSDOS? We suppose why not? The .COM file format is lean, and you can take over everything without a lot of work. If the program were huge, it wouldn’t be very impressive. There are 64 shades of gray which is odd looking these days, however there are versions that use various color palettes and each one fits in 64 bytes or less. There’s even mouse control and you can see the results in the video below.

Continue reading “Tiny Ray Tracer Fits In 64 Bytes”

Recovering Data From A Vintage MFM Drive

Even if you aren’t a vintage computer aficionado, you’re probably aware that older computer hard drives were massive and didn’t hold much data. Imagine a drive that weighs several pounds, and only holds 1/1000th of what today’s cheapest USB flash drives can. But what you might not realize is that if you go back long enough, the drives didn’t just have lower capacity, they utilized fundamentally different technology and relied on protocols which are today little more than historical footnotes.

A case in point is the circa 1984 Modified Frequency Modulation (MFM) drive which [Michał Słomkowski] was tasked with recovering some files from. You can’t just pop this beast into a USB enclosure; copying files from it required an interesting trip down computing’s memory lane, with a sprinkling of modern techniques that are sure to delight hackers who still like to dip their toes into the MS-DOS waters from time to time.

The drive, a MiniScribe 2012, has its own WD1002A-WX1 8-bit ISA controller card. [Michał] is the kind of guy who just so happens to have an ISA-compatible AT motherboard laying around, but he didn’t have the correct cooler for its Pentium processor. He stuck a random heatsink down onto it with a rubber band and set the clock speed as low as possible, which worked well enough to get him through the copying process.

Not wanting to fiddle with floppies, [Michał] then put together a setup which would let him PXE boot MS-DOS 6.22 under Arch Linux. He used PXELINUX, part of the syslinux package, and created an entry for DOS in the configuration file under the pxelinux.cfg directory. He then installed netboot which combines a DHCP and TFTP server into one simple package, and configured it for the MAC address of the AT machine’s 3com 3C905C-TXM network card.

With the hardware and operating system up and running, it was just a matter of getting the files off of the MFM drive and onto something a bit more contemporary. He tried to copy them to a secondary IDE drive, but it seemed there was some kind of conflict as both drives wouldn’t operate at the same time. So he pulled another solution from his bag of tricks: using a USB mass storage device on MS-DOS. By emulating a SCSI drive, he was able to get a standard flash drive plugged into a PCI USB card working, which ultimately dragged these ~35 year old files kicking and screaming into the 21st century.

We love keeping old hardware alive here at Hackaday, and documented methods to not only PXE boot DOS but use USB storage devices when you get it up and running will hopefully inspire some more hackers to blow the dust off that old 386 in the attic.