1993년 PC 데모를 x86 리컴파일로 브라우저에서 네이티브 실행, 사이클 타이밍까지 대조 검증
- 클래식 PC 데모를 x86 에뮬레이터로 돌리면서 CPU가 실제 실행한 코드 블록을 전부 기록하고, 그 기록을 원본 명령어 하나하나에 에뮬레이터의 정확한 사이클 타이밍까지 붙여 C 코드로 변환함
- 변환 결과는 에뮬레이터와 이벤트 단위로 대조 검증되어 인터럽트, 포트 접근, 프레임이 에뮬레이션 시간상 같은 지점에서 일치함
- HN 논평에 따르면 Future Crew 데모는 2.5MB에 1993년 PC(당시 RAM 최대 8MB)에서 돌았는데, 브라우저에서 다시 돌리면 메모리를 20배 이상 씀
- 논평에서 출력문에 LLM의 테스트 절차 문서가 그대로 새어 나온 흔적을 지적했고, 최근 AI 디컴파일/리컴파일 프로젝트가 모두 이 방식을 쓴다는 관찰이 나옴
- 사이클 정확 에뮬레이션은 최적화를 막아 비용이 크고, 1993년 PC 성능 편차가 386SX-16에서 Pentium 66MHz까지 20배가 넘어 이 시대 데모에는 이점이 작다는 반론이 나옴
Hacker News opinions
데모 전체에서 CPU가 실제 실행한 코드 블록을 기록해 C로 옮기고 사이클 타이밍까지 맞췄다는데, 사이클 정확 에뮬레이션 대신 이렇게 하는 이유가 뭐임? 컴파일러 최적화로 더 빨라지려는 거겠지. 근데 LLM이 테스트 절차 문서를 사용자 출력에 흘리는 건 진짜 웃김.
사이클 정확 에뮬레이션이 1993년 PC 데모에는 별 도움 안 됨. 그 시절 하드웨어 편차가 386SX-16부터 Pentium 66MHz까지 20배가 넘었음.
그 테스트 문서가 새어 나오는 거랑 계속 싸워야 함. 근데 요즘은 대부분 지우지도 않고 제대로 된 사용자용 문서도 안 만듦.
이 방식은 선택해서 쓰는 게 아님. 최근에 본 AI 디컴파일/리컴파일 프로젝트가 다 이렇게 함. AI로 무식하게 포팅하는 쉬운 방법일 뿐임.
사이클 정확은 최적화를 막아서 비용이 큼. 그런데 설명대로면 AOT로 사이클 정확을 하는 건가? CPU 쪽과 그래픽/사운드 쪽을 나눠서 프레임 타이밍 기준으로 load/store 순서를 맞추는 문제랑 비슷함.
나도 옛 전략 게임 몇 개 포팅했는데 Claude가 거의 혼자 해줌. Panzer General II랑 Imperialism II였음.
근데 그 두 게임은 DOS가 아니라 Windows 전용으로 나왔음. DOS용이었으면 DOSBox-X에서 원본 바이너리를 돌리는 게 훨씬 나았을 거임. MCP를 붙이는 쪽이 게임을 다시 구현하는 것보다 작업량이 훨씬 적음.
이거 좀 슬펐음. 데모씬은 머리만으로 기계를 한계까지 몰아붙이는 게 전부였는데, 이제 그 창작 방식 자체가 AI에 먹혔음.
이 네 개 데모는 모르겠고, 그 시절 기계 제약 안에서 푸는 게 도전의 일부였음. Future Crew 데모가 2.5MB에 1993년 PC에서 돌았으니 RAM이 8MB 정도였을 텐데, 브라우저에서는 메모리를 20배는 씀. 다시 볼 수 있는 건 좋지만 만든 정신은 좀 사라짐.
그냥 지나갈지도. 사람들이 지치면 비전 없이 만든 프로젝트는 커뮤니티에 해롭다는 결론이 나고, 그때는 모더레이션 문제로 다루거나 보증과 신고 시스템을 만들면 됨.
다음에 유럽에서 하는 데모파티에 누가 오겠음? 68k 어셈블리를 손으로 짜고 4k 데모를 만들면서 명령어 하나하나까지 꿰고 있는 사람이.
그건 좀 과함. 클래식 데모를 브라우저로 포팅한 건 꽤 멋진 거고, AI 슬롭 프로덕션은 눈총받거나 금지됨. 사이즈코딩, 올드스쿨, 와일드 카테고리에서는 여전히 손으로 짬.
나도 같은 생각임. AI가 유일한 길이라고 하는 소리 듣지 말고 자기 공간을 만들면 됨. 나는 386부터 펜티엄까지 MS-DOS용 데모랑 게임을 취미로 만드는데, 지금 EGA 프로덕션 작업 중임. Ferraro 책 펴놓고 CRTC 이해하면서 커스텀 비디오 모드를 만들고 있음.
C64 씬은 아직도 놀랄 만큼 활발함. 제한된 하드웨어에서 불가능해 보이는 걸 해내고, BASIC 화면을 페이드아웃하는 방법만 해도 얼마나 많은지. 나는 오래전부터 C64만 봄.
데모 다시 보려면 AI 필요 없음. pouet.net 가면 됨. 데모씬은 지금도 활발함.