I'd be interested in access to real drives capable of reading real tapes, to get archival data off my tapes. And, DAT format.
If the emulation aides in FPGA or small device coding to make modern interface bindings to older devices and so drops the entry cost to get an older SCSI or firewire drive working, I'd be delighted.
If this is emulation of the command set aimed at "driving" a software emulated tape drive, It's for another purpose. It won't help me recover old media.
(cheapskate: there are competent, expensive companies which specialise in this kind of data recovery. The problem is cost/benefit, not actual capability at any price)
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).
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.
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.
Yes, I understand, as perhaps someone who has a museum and has to keep things working with very little resources, and I imagine there are many more reasons. Different people may have the same hobbies on the surface for different reasons and so on.
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.
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.
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.
If the emulation aides in FPGA or small device coding to make modern interface bindings to older devices and so drops the entry cost to get an older SCSI or firewire drive working, I'd be delighted.
If this is emulation of the command set aimed at "driving" a software emulated tape drive, It's for another purpose. It won't help me recover old media.
(cheapskate: there are competent, expensive companies which specialise in this kind of data recovery. The problem is cost/benefit, not actual capability at any price)
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.
I don’t see the appeal either, but perhaps the person using takes something else from their retrocomputing use.
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.
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.
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.