Meatloaf turns your C64 into a network-attached disk drive with nested URL paths

What Meatloaf actually is

Meatloaf is an ESP32-based device that plugs into the IEC serial port of a Commodore 64, 128, VIC-20, or Plus/4. It emulates a disk drive, so LOAD"$",8 and LOAD"*",8 work without any software changes on the Commodore side. The README is blunt: it pretends to be a disk drive, and existing software does not know the difference. The device can answer on device IDs 4 through 30 simultaneously, each with its own mounted image, which means it can act as 26 separate drives on one bus. It also includes a printer, a clock, and a WiFi modem, plus a web app called the Meatloaf Manipulator for browsing and swapping disks from a phone or laptop. The intended user is a Commodore enthusiast who wants to load software from network sources without fiddling with SD cards or physical media. The project is written in C, licensed GPL-3.0, and is not archived, but the last push date is unknown and no releases were retrieved, so you should check the repository directly for current status.

The nested URL trick that makes remote disks work

The core mechanism is path parsing from right to left. Every component of a Meatloaf path can be a container, so a disk image inside a ZIP archive on a remote server is just a longer filename. The README gives this example: LOAD"HTTP://SERVER.COM/FILES/GAME.ZIP/DISK.D64/START.PRG",8. That resolves to FileStream(D64Stream(ZipStream(HttpStream))). The ZIP is decompressed on the fly, the D64's directory is read from the decompressed bytes, and the PRG is streamed to the C64. No unpacking step, no temporary files, nothing to copy to an SD card. The composition works to any depth and across every protocol the device supports. This is the single most distinctive feature of Meatloaf compared to other IEC drives like SD2IEC, which typically only read from local storage. It turns the entire internet into a floppy drive, as the project tagline says. The right-to-left parsing is what makes it composable, and it is a clever design choice because it avoids the need for a separate mount command or a preloaded directory listing.

Supported formats: from flux to tape to modern archives

The format list is extensive. For CBM disk images, it covers D64, D71, D81, D80, D82, DNP, CMD FD2000/FD4000, CMD HD, IDE64 hard disks, MMC2IEC index files, BackBit, and DreamLoad. Write support is limited: SAVE, S: scratch and unscratch work in D64, D71, D81, DNP, and CMD HD partitions, with real CBM block allocation, BAM updates, and 72,DISK FULL on overflow. Flux and bit-level images like G64, G71, G81, NIB, P64, and P81 are supported for reading copy-protected originals, but P64/P81 are explicitly read-only. Tape images include TAP, DMP, HTAP, T64, TCRT, and CSM, decoded by a vendored TAPClean engine with roughly 90 loader scanners for things like Cyberload, Visiload, US Gold, Novaload, Freeload, and Turbo Tape 64. The scanners fold turbo-loader boot stubs into their payloads so the listing shows game names rather than loader stubs. Modern archives are handled by libarchive, including ZIP, RAR, 7z, tar, and compressed files. The 7z caveat is important: LZMA dictionary does not fit comfortably in ESP32 RAM, so listing works but extraction of large entries may not. The reader is selected by extension rather than content probing, because probing across every format would cost tens of kilobytes of reads, about 180 network round trips on a slow HTTP source. An unrecognised extension still falls back to probing.

Network protocols and the cloud drive idea

Meatloaf can load from any URL, not just local flash or SD. The README shows HTTP, SMB, and FTP examples: LOAD"HTTP://C64.MEATLOAF.CC/GAMES/H.E.R.O.PRG",8 loads a PRG directly from a web server. LOAD"SMB://STORAGE/C64/FAVORITES/PIRATES/PIRATES_A.D64/*",8 loads from a Windows/Samba share. Even a single program out of a D81 on a website works, like LOAD"HTTP://C64.MEATLOAF.CC/COLLECTION/BACKBIT/M/MARS SAGA.D81/START.PRG",8. The README says it is a cloud disk drive, and that it is more than just another SD2IEC clone because it loads files from any URL without additional software. The network protocols section was truncated in the material I have, but the examples already show HTTP, SMB, and FTP. The device also acts as a network adapter: you can open a URL like a file and talk to REST APIs from unmodified BASIC v2, with a JSON parser built into the drive. That is a significant capability, because it means a C64 program can fetch live data from a web service without any extra hardware or software. The Meatloaf code is also used in the Commodore FujiNet firmware, and some FujiNet code is used in Meatloaf, so there is cross-pollination, but Meatloaf remains focused on Commodore.

Getting started: hardware and flashing

The README is emphatic about hardware: use an ESP32-S3-WROOM-1-N16R8 dev module for all new builds. The wiring is a little different from older builds, but a video by Deadline is still referenced as a guide. You can flash using the web flasher instead of compiling the firmware yourself, which lowers the barrier for users who do not want to set up an ESP-IDF toolchain. The project is written in C, so compiling from source requires the ESP-IDF environment, but the web flasher is the recommended path. The README does not provide a specific command to build, but the repository layout includes a docs folder with howisitpossible.md, which explains the architecture. For a user who just wants to try it, the web flasher is the entry point. The device then plugs into the IEC serial port of the Commodore, and you can start using LOAD"$",8 immediately. The Meatloaf Manipulator web app is accessible from a phone or laptop, so you can search and swap disks while the Commodore keeps running.

Limitations and failure modes

The most obvious limitation is the 7z LZMA dictionary issue. The README states that listing works, but extraction of large entries may not, because the dictionary does not fit comfortably in ESP32 RAM. That is a hard constraint of the hardware, not a software bug. Another limitation is that flux images like P64 and P81 are read-only, so you cannot write back to copy-protected originals. The extension-based reader selection is a deliberate trade-off: it avoids the cost of probing every format, which the README estimates at about 180 network round trips on a slow HTTP source, but it means that a misnamed file will fail to load until the fallback probing kicks in. The tape loader scanners, while numerous, are not universal; the README says roughly 90 scanners, so obscure loaders may not be covered. The device also requires the specific ESP32-S3-WROOM-1-N16R8 module; using a different module may break wiring and potentially the firmware. The README does not mention power requirements, but an ESP32 with WiFi and an IEC bus should be powered externally, not from the Commodore's port, though that is my inference, not stated in the material.

Alternatives and how Meatloaf differs

The README explicitly names SD2IEC as a comparison point: Meatloaf is just another Commodore IEC serial floppy drive similar to SD2IEC and its clones, but it loads not only local files but also files from any URL. That is the core difference: SD2IEC reads from SD cards only, with no network capability. The other major alternative is FujiNet, which is mentioned as sharing code with Meatloaf. FujiNet is a broader platform that supports multiple computer systems, while Meatloaf is focused on Commodore. The README says Meatloaf features that make sense will be merged into FujiNet, so the two are not rivals but rather siblings. If you need a multi-system device, FujiNet might be the better choice, but if you want the deepest Commodore-specific format support, Meatloaf is the one. The nested URL scheme is unique to Meatloaf as far as I know; SD2IEC and FujiNet do not offer right-to-left composable paths that resolve a PRG inside a D64 inside a ZIP on an HTTP server. That is the deciding factor for users who want to stream from network shares without pre-copying files.

Maintenance, licensing, and upgrade cost

The repository is GPL-3.0, which means any derivative work you distribute must also be under GPL-3.0 and provide source code. That is a standard copyleft license, but it has implications if you plan to embed Meatloaf in a commercial product: you would need to release your changes. The README does not mention a maintenance cadence, and the last push date is unknown, so you should check the commit history on GitHub to see how active the project is. The code shares with FujiNet, so fixes may flow both ways, but there is no guarantee of regular releases. The upgrade cost is moderate: reflashing the ESP32 via the web flasher is straightforward, but if you modify the firmware, you need to set up the ESP-IDF toolchain and handle the wiring differences for the S3 module. The documentation includes a howisitpossible.md file, which likely explains the architecture in depth, but it is not included in the material I have. Before adopting, verify that the specific tape loaders and disk formats you care about are in the supported list, and test the 7z extraction with your largest archives to see if they fit in RAM.

Editorial conclusion

Adopt Meatloaf if you own a C64, VIC-20, C128, or Plus/4 and want to load software from network sources without copying files to an SD card first. Its nested URL scheme is genuinely novel: a single LOAD string can resolve a PRG inside a D64 inside a ZIP on an HTTP server, with no intermediate steps. Avoid it if you need write support for copy-protected images (G64, P64 are read-only) or if you expect to extract large 7z entries on the ESP32, where LZMA dictionary size is a real constraint. Before buying hardware, verify you have an ESP32-S3-WROOM-1-N16R8 module: the README explicitly warns that wiring differs from older builds and that the web flasher is the recommended path over compiling firmware. Check the docs/howisitpossible.md file for the full architecture explanation, and confirm that the 90 tape loader scanners cover the specific loaders you care about. Meatloaf is GPL-3.0, so if you modify and distribute, you must share source; the code also feeds into FujiNet, so expect cross-pollination but not identical features.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases