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).

Doesn't this bring us closer to that?

It removes the fun of figuring things out by yourself and the learning how to learn things. Also the lower complexity these systems usually have vs what we use today.

I don’t see the appeal either, but perhaps the person using takes something else from their retrocomputing use.

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.

There are many ways you could make a principled argument in that direction and I would agree in lots of cases. But retro-computing is a varied field with lots of different interests. Many of those are simply enthusiast curiosity.

So I will say this. Back in the days of 80x25 terminals, I was adamant that larger screens made you more productive. I don't remember anything but outright derision and skepticism in this regard. The saying "the monitor is the computer" meant a lot to me. The limitations of the day were defining but as developers we always wanted the best technology and tools available.

Then so do emulators, flash drives instead of 1541's, etc. Nobody forces you to use generative models to get older hardware to do its thing, you're still free to try to get the actual hardware to run, free to build interfaces to get QIC drives connected to whatever you want them connected to, etc.

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.