Claude × retrocomputing: emulating a QIC-117 tape drive

Depending on how old/exotic the format is, universities or libraries might have drives that you might be able to access (retrocomputing groups too, of course, but those aren't as common).

Personally, I just think that LLMs are an artificial line to draw based on current personal preference.

I'm not an AI maximalist, but I really can't see the issue with using it to preserve this hardware (especially into RTL for FPGA), if it's highly accurate.

These machines are dying in real time, and having cycle and operationally accurate emulation options is more important than the bad taste the Glorified Copymachine leaves in my mouth, to be honest.

Honestly, by quantity alone, I've seen more impressive and quality reverse-engineering and documentation work of these platforms done in the last year than i have in the last 20.

[dead]

You couldn't be more off-base in that opinion. Now there's nothing with a ROM in it that can't be understood and brought back to life. Data formats, communication protocols, and command languages that were poorly documented or completely undocumented can now be reverse-engineered and put back to work, to say nothing of license keys that haven't been issued by the manufacturer for 20+ years.

I'm part of a group of collectors/users of HP and Tektronix test gear from the same eras that the retrocomputing fans are typically focused on, and LLM-guided ROM disassembly has already solved some longstanding (if admittedly obscure) problems in our community.

I've a retrocomputing project which has been gathering dust since before I used an LLM. The idea is to render an isometric view with Quake-style lightmaps; if scrolling is slow enough I only need to render a small slice of the screen each time. I got as far as a proof of concept on a simulated 286 which indicates the pixels-per-second I can achieve is fast enough. Testing on a real 286 would be the next step.

All the assembly code, and the C harness which loads the textures etc, was hand done by me, and period correct. That's where the fun is!

Outside of that, there are so many anachronisms. I actually built the test geometry as a quake map, and processed it using Quake's BSP/lightmap tools. That's 1996 vintage.. except I'm using a newer Quake editor (Trenchbroom, 2013) and modern forks of the tools. All natively on a modern system with a 4K monitor. Building and non-performance testing of the DOS code happens in a Windows XP (2001) VirtualBox (2007) using its' Shared Folder feature.

I might have time to pick this up again soon. My post-processing of the Quake .bsp presently only handles axis-aligned 64x64 surfaces with some hardcoded texturing assumptions. I'll want a full .bsp-to-isometric-data "renderer" - either written from scratch or somehow derived from Quake's source. But this is all just to enable the 286 assembly code noodling, which is what I want to spend time on!

So I'll probably use Claude to assist with the tooling side. By "assist" I mean "do as much as possible to produce the file format I specify". It doesn't seem much worse to me than all the other modernisms I'm already relying on outside of the core task.