This is floppy.museum:

Obsolete hardware running obsolete software documenting obsolete media

About this project

Some time in 2019, I started assembling what has become a sizable collection of retro PC hardware, mostly of the late 1980s to mid-90s vintage. As 2020 hit, with pandemic and lockdowns and whatnot, this collection continued to grow.

Fast-forward to September of 2022, when I stumbled across the Museum of Obsolete Media, more specifically the Floppy Disk Museum on a floppy. Having spent some time recently obsessing about squeezing as much usefulness (yes, I know, liberal use of the term) as possible onto a floppy, the idea of making the museum run entirely from a floppy was born.

After a bit of fiddling, and some help from Jason at The Museum of Obsolete Media to reduce the museum size ever so slightly, I had a 1.44MB bootable 90mm (~3.5") floppy image containing:

• MS-DOS 6.22 boot loader, IO.SYS and MSDOS.SYS,
• Norton DOS (a scaled-down version of 4DOS, because COMMAND.COM is torture),
• The excellent HTTPSERV from mTCP,
• Network packet drivers for a few common ISA network cards, and finally
• This website.

It has developed quite a bit since then, but the core remains the same.

I decided early on to target 16-bit CPUs, which in my case means the Intel 286 and compatibles. Save for the DesqVIEW multitasker, it should run on anything from an IBM XT upwards. I would not recommend running it without enough RAM to copy the site itself to a RAM disk, though - if for no other reason than to save your precious floppy drive from wear and tear.

I'll try to detail the project as best I can here - but be aware that the below may (will) be an approximation at any given time. The hardware is old, largely untested over longer periods of time or under any kind of load (but see this nugget), and components will be replaced as need arises. This page is unlikely to keep pace, but I'll try to update it whenever I've made significant changes.

Note: The below is accurate as of October 2025. For a better chance of knowing the current state of affairs, read the event log.

The configuration

TL;DR: Boots DOS, unpacks ZIPs from the floppy to a RAM disk, runs DesqVIEW with a startup script firing up all the services. The End.

To recreate this floppy disk, you will need:

• The latest distribution of the "Floppy Disk Museum on a Floppy"
• The software listed in The software table below
• My local config files:
  • config.sys - for this hardware, probably needs modifications
  • autoexec.bat - uses my "init" system for DOS, see below
  • ndos.com - the Norton command.com replacement
  • httpd.bat - startup "script" for DESQview and HTTPServ, copies files to RAM disk
  • system.zip - the system directory, containing the "init" system
  • net.zip - the net directory, containing network drivers, IRC server, and mTCP
  • uttl.zip - various utilities used during boot, including those listed below
  • dv.zip - a stripped-down DESQView w/startup script
• Patience
• Beer (or equivalent beverage)
• A pillow to cry into when you realise what you're spending your precious time on..

The httpd.bat file attempts to allow for the absence of DESQview. As part of the start-up, it will unpack the HTML files and patch them to include the header that you can see on all the pages (except this one..).

During startup, the script will create ZIP files (the ones linked above) and place them in the /files/ subdirectory of the web server. As you can see from httpd.bat, certain files are excluded - like those containing passwords or other configuration that isn't suitable for public consumption. The ZIP files require sufficient space on the RAM drive, about 3MB should do. IFF your RAM drive is large enough you can simply have it copy/create the files there; otherwise edit httpd.bat to have it skip the whole copying/ZIPping entirely. Either way, modify autoexec.bat to make the RAM drive as large as you can, but be sure to leave a couple hundre KB for NDOS and DV to thrive.

The config.sys should present a menu on boot, offering to go straight to DESQview/HTTPServ, or boot to DOS (with or without copying files to RAM disk). DESQview only really makes sense if you have a 386 or better CPU, or a 286 with hardware EMS like the C&T SCAT chipset. The NEAT chipset, and others, may also work - but will require significant fiddling and drivers for the respective chipsets. And the EMS driver needs to support "backfilling", i.e. the software (DESQview) must be able to map EMS memory into conventional memory, otherwise it cannot "multitask".

Most executables and .SYS files (drivers) on the disk are compressed using UPX, which compresses and adds a small self-extract header to the files. In the interest of saving disk space, though, I'm UPXing everything I can - with the notable exception of XCOPY.EXE which breaks in funky ways with any compression applied to it.

The configuration for HTTPServ is in httpd.bat and in the configuration file referenced by the MTCPCFG environment variable. Additionally, a HTACCESS.--- file is copied to the root of the HTML directory, which enables the status and clients pages.

Bootup takes a long time, since all files are copied to RAM disk prior to running anything. This is partially to reduce the wear and tear on the actual floppy drive and the floppy, and partially to make visiting the site a bearable experience. Once running, however, it should be stable for weeks on end. :)

See also the IRC and message boards sections for details on how those are implemented.

Maintenance

TL;DR: Updating HTML, ANSI and some parts of the configuration can be done remotely via FTP thanks to DesqVIEW, PKTMUX and mTCP FTPSRV.

In an attempt to make the site maintainable in other ways than 1) removing the floppy, 2) making changes and 3) rebooting, I've been trying to get DESQView to multitask the IRCd and the mTCP HTTPServ and FTPSRV programs. Unfortunately, this cunning plan was foiled by the fact that packet drivers have no concept of multiple applications using them at the same time. Luckily I raised this to the mTCP author, who pointed me to PKTMUX: A packet driver multiplexer!

Originally written to allow the use of TCP/IP applications alongside IBM 3270 terminal emulator TSRs, this software takes over the software interrupt handler from the packet driver itself, attempts to peek into the ethernet packets to find the IP header, and forwards the packet to the correct application via a "virtual" packet driver of which there is one copy running for each application.

Using PKTMUX and DESQView I now (as of 2023-03-01) have a remotely-maintainable site! The updated floppy is still fully self-contained, and boots into DESQView with IRCd, HTTPServ and FTPSRV running. And there's still enough memory to run IRCjr from the same machine! (Yes, I've done this.)

IRC - Internet Relay Chat

TL;DR: Point an IRC client to floppy.museum:6667.

Since 2023-06-04 there's been an IRC server running on the machine!

That's right: On the same 286 and floppy that already contains and runs an operating system and multi-tasker, a web server, an FTP server, and this whole website -- there is now a fully operational IRC server too!

Given memory constraints (and other limitations), it's currently configured to accept a maximum of 28 simultaneous users. To compensate, as of 2023-06-21 the server is now clustered (see the event log) with another 286 of equal configuration, and together they can handle 56 clients! So don't hesitate, join now!

How to connect

Point any bog-standard IRC client at this server, on port 6667: floppy.museum:6667. Note that there is no fancy TLS or other protections here, so please do not rely on it for any kind of privacy.

You can find me on the #FloppyMuseum channel as Ltning, e-Ltning, or some variation thereof.

Message Boards

TL/DR: Telnet to floppy.museum:8023 with a client that speaks CP437 or 850. Leave a message. Also see User messages and SysOp messages.

I'm experimenting with message boards on the system, which are occasionally reachable via Telnet on port 8023. In addition to the usual PKTMUX tricks, another utility has entered the fray: RLFOSSIL.

RLFOSSIL is a virtual FOSSIL driver, which uses a resident packet driver and WATTCP to listen for inbound Telnet (or rlogin or raw) connections. In the other end, it simulates a Hayes-compatible modem on the virtualized COM port, which applications can interact with using the INT14 FOSSIL interface.

Normally, a BBS is the typical program to use here: It will listen to calls from the "modem" and establish connections with the caller. Sadly, the same limitations that apply to everything else - CPU, memory, storage - also apply here, so there aren't really any BBS programs that fit within the narrow confines of about 340KB RAM and a very, very slow CPU. Luckily there are other crazy people on the Internet, including fusion (of #os2warez fame) who put together a tiny wait-for-call program which simply accepts these "calls" and passes control to a "BBS door".

Several door programs have been tested: some "wall" doors, which lets you leave a simple message for other visitors, and "The Reader", a full-blown message base. Unfortunately, nothing seemed to work quite right. Luckily, fusion wasn't done, and wrote just enough of a message board system to do what I wanted: Allow me to post messages about the museum, and allow visitors to post messages about whatever.

The "correct" way of assmebling these parts would be something like

1. Start packet driver (PKTDRV instance)
2. Invoke DesqVIEW with RLFOSSIL (rlfossil 0 2 dv.com)
3. Run BBS program in one or more DV sessions

While this works in theory, there are bugs in various parts of this stack of old software, so the whole thing would stop working at random intervals. So instead, I'm now doing the Wrong Thing(TM): Running the packet driver, rlfossil and the message board all in a DV session, in a loop:

1. Unload any PKTDRV instances (pktdrv 63 /e /u)
2. Start new PKTDRV (pktdrv 63 /!l /lt23)
3. Run the message board (rlfossil 0 1 "bbs_exit.exe 1 bbs42.cfg")
4. Stop the PKTDRV (pktdrv 63 /u)
5. GOTO #1

It's neither pretty nor optimal, but it does seem to work .. somewhat. :D

How to connect

Find yourself a telnet program that can handle 8-bit ASCII, codepage 437 or 850 or something close enough, and ANSI color. Anything expecting UTF-8 won't work right. Additionally, some modern implementations may fail to negotiate properly and end up in line mode, which will prevent some functionality from working right.

The Museum, being a "cluster", has two instances of the message boards: Rebo and Zooty (Zooty, zoot zoot!). You'll know when you connect which one you've reached.

Note that you shall not experience speed when talking to the boards. It will feel much like talking over a slow modem line to an equally slow and busy system - which is as it should be. And after you disconnect, it has to look at the message base, see if anything new has been posted, and produce HTML files and assemble the message pages (see below, or menu at the top/bottom).

Therefore: try not to reconnect too frequently, and if you get a connection refused or the connection drops immediately, give it a couple of minutes before you try again. Either someone is keeping the "line" busy, or you've caught the server(s) at a particularly bad time. If it keeps failing, contact me!

Tested clients include:

• mTCP TELNET
• SyncTERM
• FreeBSD telnet with luit to do character set conversion, e.g.:
  luit -encoding CP437 telnet floppy.museum 8023
  (Hit the escape character and type mode character to make it work right)

Please stop by and say hi! :) And visit the User messages and SysOp messages pages to browse what's already there!

The hardware

Motherboard	JC Information Systems Corporation JCS286/SCAT
Chipset:	Chips&Technologies 82C235 "SCAT" (single-chip successor of NEAT)
BIOS:	AMI/C&T
CPU:	Intel 80286-16MHz
FPU:	Intel 80287-8MHz ("military grade")
RAM:	8MB 70ns FPM DRAM (1x 72pin SIMM)
Expansion	Just making Netscape 2.02 for OS/2 happy..
Graphics+FDD controller:	Viglen HDD+FDD+VGA+I/O combo card, WDC90C30-LR VGA chip and C&T F82C712 Super I/O
Network:	RealTek RSET8019-based 8-bit Ethernet controller
Storage	Just making Netscape 2.02 for OS/2 happy..
Floppy drive A:	Sony 90mm (~3.5") HD
Floppy drive B:	None
Hard Disk drive C:	None
Power	Just making Netscape 2.02 for OS/2 happy..
Power supply	Mini-Box PicoPSU-120 12v, 120W DC-DC
Power safety	Milk Factory Computing Programmable AT Fuse

The software

Contact

My name is Eirik Øverby, I'm of 1977 vintage, and we (this server and myself) are located in Oslo, Norway. You can (usually) find me on IRC (this server, Libera, EFNet) as Ltning, or in the fediverse as @ltning@anduin.net.

If you want to contact me via email, I'm sure you can deduce my email address from the above.

Note: This page hand-coded and optimized for Netscape Navigator 2.02 for OS/2. Also viewable in IBM WebExplorer 1.1h. May be compatible with newer user agents.

+-------------------------------------------------+--+
|  meow                                           |.X|
+-------------------------------------------------+--+
|  This page is a part of  --<The Hacker Webring>--  |
|    <-- prev    |    - random -    |    next -->    |
+----------------------------------------------------+