Hacker News • 32일 전

Claude로 QIC-117 테이프 드라이브 에뮬레이션 구현

IMP

4/10

핵심 요약

한 개발자가 Claude Opus 5를 활용해 86Box 에뮬레이터에 QIC-117 테이프 드라이브 에뮬레이션 기능을 추가했습니다. QIC 테이프의 이진 이미지를 디지털 보존하고 실제 DOS·초기 Windows용 백업 소프트웨어로 가상 테이프를 읽을 수 있게 한 사례로, 레트로컴퓨팅과 디지털 아카이빙, AI 코딩 활용에 관심 있는 실무자에게 흥미로운 내용입니다.

번역된 본문

다음은 LLM의 사소한(?) 활용법으로, 에뮬레이션된 테이프 드라이브를 만들어 보겠습니다! 요약: 86Box 에뮬레이터가 이제 플로피 컨트롤러나 병렬 포트에 연결된 QIC-117 테이프 드라이브를 에뮬레이션할 수 있게 되었고, 실제 DOS 및 초기 Windows 시대의 백업 소프트웨어를 사용해 가상 테이프 이미지로 "백업"을 만들 수 있습니다.

저는 예전부터 에뮬레이터에 상당히 집착해 왔습니다. 거의 모든 버전의 DOS, Windows, Mac System, Amiga OS, 각종 Unix, 그리고 그 외 더 생소한 OS들을 담은 부팅 가능한 디스크 이미지 컬렉션을 대량으로 보유하고 있어서, 아이콘 클릭 한 번으로 언제든 실행할 수 있습니다. DOS와 초기 Windows 기반 시스템을 에뮬레이션하는 제가 가장 좋아하는 에뮬레이터 중 하나는 훌륭했던 PCEm 에뮬레이터의 후속격인 86Box입니다. 86Box는 매우 "저수준" 에뮬레이터로, 다양한 칩셋의 BIOS ROM을 실제로 실행하고 수많은 장치와 주변기기를 매우 충실하게 에뮬레이션합니다. 또한 86Box는 개발 및 확장이 놀라울 정도로 쉽습니다.

한동안 제 머릿속에는 두 가지 집착거리인 에뮬레이션과 테이프 미디어를 결합하고 싶다는 생각이 있었습니다. 가상 테이프 카트리지를 넣고 가상 테이프 이미지 파일에서 읽는 테이프 드라이브를 에뮬레이션할 수 있다면 멋지지 않을까요? 제가 아는 한, 현재 QIC 테이프 드라이브(구체적으로 QIC-80과 QIC-3020 같은 후속 규격)를 에뮬레이션하는 에뮬레이터는 존재하지 않습니다.

저는 QIC 테이프에서 데이터를 복구하는 일을 정기적으로 하고 있습니다. 그리고 디지털 보존에 관심이 있는 사람으로서, 항상 테이프의 완전한 이진 이미지를 확보하도록 합니다. 그래야 원래 백업 소프트웨어가 기록했던 그대로 다른 테이프에 이미지를 재현할 수 있기 때문입니다. (참고로 진정한 의미의 "제대로 된" 테이프 보존은 상위 수준의 이진 바이트가 아니라 실제 자기 변화(flux transition)를 저장하는 것이지만, 이는 나중에 다룰 주제입니다.)

그래서 이진 테이프 이미지가 손에 있으니, 에뮬레이터 안에서 원래의 백업 소프트웨어가 실제 테이프 드라이브와 통신한다고 믿게 만들어 이 테이프를 읽게 함으로써 "순환을 완성"할 수 있다면 정말 좋을 것입니다.

다행히 우리는 한 사람의 백로그가 AI 에이전트의 최우선 과제가 될 수 있는 시대에 살고 있습니다. Colorado 250, Travan 같은 QIC 테이프 드라이브는 QIC-117이라는 특수 프로토콜을 통해 플로피 컨트롤러로 통신합니다. 이 프로토콜의 전체 사양은 웹에서 쉽게 구할 수 있습니다. 그러니 에뮬레이트된 드라이브가 QIC-117 사양 전체를 구현하기만 하면 모든 것이 잘 될 것이라고 생각할 수 있습니다. 안타깝게도 그렇지 않습니다. 표준 QIC-117 기능 외에도, 사양은 제조사별 "진단" 명령을 허용하는데, 이는 사실상 제조사가 원하는 완전히 임의적인 동작을 사양에 허용하는 것입니다. 그리고 실제로 제조사들은 이러한 진단 명령을 아주 적극적으로 사용합니다. 특히 호스트 드라이버가 연결된 드라이브의 유형을 확인하려는 감지 단계에서 그렇습니다.

Claude Opus 5가 단 3~4개의 프롬프트만으로 순수 QIC-117 사양만 구현했을 때, MS-DOS용 백업 유틸리티 중 단 하나만이 드라이브를 감지하고 읽는 데 동의했는데, 그것은 HP Colorado Backup 7(QBACKUP)이었습니다. 이것이 실제로 제가 처음 시도한 유틸리티였는데, 처음에는 헛된 희망을 안겨주었습니다. 이후 서로 다른 유틸리티들이 이 드라이브를 감지하는 방식이 극적으로 다르다는 사실을 깨달았고, QBACKUP은 우연히 제조사별 트릭을 가장 적게 사용하는 쪽이었던 것입니다. 예를 들어 Windows 95용 Microsoft Backup 같은 도구를 사용해 보면, 드라이브를 진단 모드로 전환하고 제조사별 명령을 내리려는 시도가 보였습니다. 제가 Colorado 드라이브를 에뮬레이션하고 있었기 때문에(QIC-117 사양은 드라이브가 미리 정의된 알려진 제조사 목록의 "벤더 코드"로 응답하도록 요구함), MS Backup은 분명히 그 어디에도 문서화되지 않은 Colorado 전용 작업을 드라이브에 수행하려 했던 것입니다. 이 진단 명령의 실체를 밝혀낼 수 있는 방법에는 두 가지가 있습니다.

원문 보기

원문 보기 (영어)

For my next trick frivolous use of LLMs, I'm building an emulated tape drive! TLDR : The 86Box emulator now allows you to emulate a QIC-117 tape drive connected to the floppy controller, or to a parallel port, and make "backups" to virtual tape images using actual DOS and early Windows-era backup software. I've always been rather obsessed with emulators. I have an extensive collection of bootable disk images that contain virtually every version of DOS, Windows, Mac System versions, Amiga OS, various Unixes, and other more obscure OSes, all ready to run at the click of an icon. One of my favorite emulators for emulating DOS and early Windows-based systems is 86Box , which is an evolution of the great PCEm emulator. 86Box is a very "low-level" emulator that actually executes the BIOS ROM of various chipsets, and emulates a plethora of devices and peripherals very faithfully. 86Box also happens to be refreshingly accessible for developing and extending. For a while I've had this idea in the back of my mind to combine two of my obsessions: emulation and tape media. Wouldn't it be neat if we could emulate a tape drive, with a virtual tape cartridge, reading from a virtual tape image file? As far as I know, there are no emulators currently available that emulate a QIC tape drive (specifically QIC-80 and its later cousins like QIC-3020). I deal with recovering data from QIC tapes on a regular basis. And as someone who cares about digital preservation, I always make sure to obtain a complete binary image of the tape, so that it might be possible to reproduce the image onto a different tape, exactly as the original backup software would have written it. (Side note: a truly "proper" preservation of a tape would be to save the actual flux transitions, instead of the higher-level binary bytes, but that's a subject for a future post.) And so, with the binary tape images in hand, it would be great to "close the loop" by allowing the original backup software, running in an emulator, to read these tapes by believing that it's communicating with a real tape drive. Fortunately we are living in a time when one person's backlog can become their AI agent's top priority. These QIC tape drives, such as the Colorado 250, Travan, and so on, communicate over the floppy controller using a special protocol called QIC-117. The complete specification of this protocol is readily available on the web. You would think, therefore, that all that's necessary is for our emulated drive to implement the entire QIC-117 spec, and all will be well. Sadly that's not quite the case. In addition to all the standard QIC-117 functions, the spec allows for manufacturer-specific "diagnostic" commands that basically open the spec up to completely arbitrary behavior that the manufacturer desires. And indeed, the manufacturers make generous use of these diagnostic commands, particularly in the detection phase of when the host driver wants to determine the type of drive that is connected. With just the bare QIC-117 spec implemented, which took Claude Opus 5 just three or four prompts to complete, only a single backup utility for MS-DOS would agree to detect and read from the drive, namely HP Colorado Backup 7 (QBACKUP). This was actually the first utility I tried, which initially gave me false hope, because afterwards I started realizing that different utilities employ wildly different ways of detecting these drives, and QBACKUP happened to employ the least manufacturer-specific trickery. When I tried using tools like Microsoft Backup for Windows 95, for example, I noticed it putting the drive into diagnostic mode and attempting to issue manufacturer-specific commands. Since I was emulating a Colorado drive (the QIC-117 spec requires the drive to reply with a "vendor code" from a predefined list of known vendors), MS Backup was clearly trying to do Colorado-specific things with the drive, which are not documented anywhere. There are two ways we could uncover what the diagnostic functions do: we could connect a real Colorado drive and attempt to monitor the traffic that goes across a real floppy controller, or… We could unsolder the ROM chip from the drive, perform a disassembly of the ROM, and get a complete understanding of all the commands that the drive supports, including all the diagnostic bits! Armed with nothing more than a dump of the ROM and a photo of the PC board, I told Claude to "see what you can do with this", and it obediently disassembled the ROM and laid out exactly what custom commands the drive supports, and exactly how the drive deviates from the spec for certain standard commands. Have a look at the repo where I put the resulting analysis of the ROM disassembly from the Colorado drive, as well as a few other related drives in my collection. You'll find all of these rather interesting tidbits in the repo: A FINDINGS.md document with an extremely detailed breakdown of all the commands supported by the drive, including some very interesting possibilities for future work in enabling the drive to read tapes that were previously believed to be unreadable, as well as enabling a custom controller, such as a Greaseweazle, to control the drive and read the raw flux transitions, for truly proper digital preservation. Disassembler (written in Python) for the Intel 8051 processor, which is the main IC that controls the drive. There is also a disassembler for the Zilog Z8 processor, used by a couple of the other drives. Both of these disassemblers were thrown together by the LLM as an effortless prerequisite for its work. This filled in all the missing pieces necessary to complete the emulated QIC-117 drive , now usable in 86Box: Afterwards, for the sake of completeness, I also implemented support for a parallel port version of these drives (LPT port with EPP), which emulates an Iomega Ditto drive. This drive is actually a QIC-117 drive internally, but contains an extra chip that allows it to communicate over the parallel port using a protocol called Backpack , developed by MicroSolutions. The Iomega Ditto 2GB drive in particular is one of my go-to drives for reading QIC cartridges, because of its excellent backwards compatibility with older cartridges, being able to read not only the first-party Ditto cartridges, but other smaller-capacity tapes like Travan, QIC-3020, all the way down to QIC-2080. All of these are now supported as emulated cartridges in 86Box, when configuring your emulated Ditto drive on the parallel port. One minor quirk is that Ditto cartridges always came pre-formatted, and there's no way for the end user to format a completely blank tape image. Therefore I made a repository of pre-formatted tape images for you to download and use for yourself. The repository also contains a Python script that lets you generate a tape image with your desired capacity and custom label. Have fun! Share: Twitter Facebook Pin It WhatsApp LinkedIn Buffer

에뮬레이션 레트로컴퓨팅 Claude 디지털 보존 86Box