코모도어 64 하드웨어 시뮬레이터: 칩과 핀을 고장 내고 결과를 확인하세요

AI 요약

c64-hw-sim은 Commodore 64의 ASSY 250407 메인보드를 부품 핀 단위로 시뮬레이션합니다. 칩 핀을 띄우거나 GND 또는 +5V에 연결하고, 소켓에서 칩을 빼거나 저항을 끊을 수 있습니다. 프로그램은 보드의 netlist와 각 칩의 핀 동작을 계산해 화면과 키보드, 보드 신호가 어떻게 변하는지 보여줍니다. 고장 난 C64 화면을 미리 정해 둔 것이 아니라 회로 동작에서 결과를 계산합니다.

핀 단위 시뮬레이션

예를 들어 컬러 RAM인 2114의 17번 핀 A7을 전원을 켜기 전에 들어 올리면 시스템은 정상적으로 부팅하고 화면도 깨끗하게 나옵니다. CPU가 쓰는 주소와 VIC가 읽는 주소가 같은 방식으로 잘못 바뀌면서 RAM 주소가 겹치기 때문입니다. 핀을 다시 연결하면 기록되지 않은 컬러 RAM 영역이 임의의 색으로 나타납니다. 저자는 실제 2114에서도 같은 현상이 생긴다고 설명합니다.

각 핀을 클릭하면 오실로스코프에 신호를 띄우고, 핀을 부유 상태로 만들거나 GND 또는 +5V에 연결할 수 있습니다. 칩을 클릭하면 소켓에서 제거하고 저항과 페라이트 비드, 크리스털은 연결을 끊을 수 있습니다. 신호는 높음, 낮음, 펄스, 부유 상태로 표시하며 두 출력이 충돌하면 별도 색으로 나타냅니다. 보드에는 216개 부품과 249개 net이 들어 있습니다.

회로 모델과 사용 방법

6510 CPU와 VIC-II, CIA, SID는 floooh의 cycle-accurate 칩 코어를 사용합니다. RAM과 ROM, PLA 등 나머지 부품은 핀 단위 모델로 구현했습니다. DRAM은 /RAS에서 행 주소를 저장하고 /CAS에서 열 주소를 저장합니다. 각 반 주기마다 주소 처리, /RAS 하강, /CAS 하강 순서로 회로를 안정화합니다. net을 구동하는 출력이 없으면 기존 전하를 유지하다가 시간이 지나면서 전압이 변합니다. TTL 입력이 연결된 선은 수 마이크로초 안에 약 1.4V로 이동하고 MOS 입력만 연결된 선은 1초보다 짧은 시간에 0V 쪽으로 이동하도록 모델링합니다. 이때 임계 전압과 잡음을 고려해 부유 신호가 불규칙하게 읽힐 수 있습니다.

프로그램은 macOS와 Linux에서 실행하며 그래픽에는 OpenGL을 사용합니다. 창에서 보드와 모니터, 제어판, 오실로스코프를 함께 볼 수 있고 .prg 파일을 DRAM에 직접 넣어 고장 난 보드에서도 프로그램을 불러올 수 있습니다. 창 없이 실행하는 모드도 제공하며 텍스트 화면을 읽고 이미지로 저장할 수 있습니다. 고장과 복구 시점을 지정하거나 KERNAL 읽기와 VIC 메모리 접근을 이상적인 메모리 맵과 비교하는 옵션도 있습니다. tests/faults.sh에는 시뮬레이터를 실행하기 전에 예상 증상을 기록한 일반적인 고장 31개가 들어 있습니다.

정확도와 한계

실제 C64 속도와 비교하면 Apple M3 Max에서 31%, AMD Ryzen AI Max+ PRO 495에서 39%, Apple M5 Max에서 48% 속도로 동작합니다. 모든 핀을 계산하기 때문에 게임을 실행하는 에뮬레이터가 아니라 회로 학습과 고장 분석을 위한 도구입니다. 신호의 부유와 전원 고장 모델은 동작 형태를 반영하지만 임계값과 전압 변화 시간, 누화 수치는 추정값입니다. 영상 출력과 SID 필터, 전원 공급 장치, dot clock PLL은 시뮬레이션하지 않습니다. DRAM 내부 셀 고장이나 두 net 사이의 브리지도 아직 구현하지 않았습니다. 비슷한 증상이 서로 다른 고장에서 생길 수 있어 시뮬레이션 결과는 진단 단서이지 확증은 아닙니다.

Hacker News 반응

• @NikolaNovak — 정말 멋집니다. 지난주 아들과 놀고 저도 파고들려고 Commodore 64 Ultimate를 샀습니다. 직장에서 AI를 더 많이 쓸수록 직접 코드를 짜고 하드웨어를 온전히 이해하던 즐거움이 더 그립습니다. 지난 주말에는 35년 만에 BASIC 프로그램을 썼습니다. 아들 생일에 이름을 입력하면 생일 케이크 PETSCII 그림이 나오는 Wordle 버전입니다. 전기 회로 수준까지 하드웨어를 파고든 적은 거의 없어서 재미있게 써보겠습니다. C64 커뮤니티에도 AI가 만든 엉터리 콘텐츠가 넘치지만 이런 보석도 나오니 균형이 맞기를 바랍니다.
• @dwheeler — 정말 대단합니다. 아쉽게도 강력한 실제 하드웨어에서도 실시간으로 실행하지 못하네요. 코드를 최적화해서 실시간으로 돌릴 수 있을지 궁금합니다.
  • @rzzzt — README에 나온 floooh 구현은 조금 더 단순합니다. 완전한 netlist가 없어서 작은 TTL glue 칩은 고려하지 않지만 실시간으로 동작합니다. 에뮬레이션 칩끼리 공통 인터페이스로 64비트 정수를 사용하고, 각 비트가 특정 시뮬레이션 단계의 논리 상태를 나타냅니다.
• @clhodapp — 정말 멋지지만, 언젠가는 도체 내부 간섭과 유도, 무선 신호 송수신도 시뮬레이션해야 하지 않을까요?
  • @AmazingEveryDay — 그렇다면 시뮬레이터를 실행하는 하드웨어의 특성도 측정하고, 그 하드웨어의 전도와 유도, RF까지 고려해야 하지 않을까요?
  • @LocalH — 시뮬레이션이 느리게 동작할수록 그런 부분은 덜 중요하다고 봅니다. 시뮬레이션한 RF는 실제보다 훨씬 느린 시간 축으로 움직일 테고, 시뮬레이터가 원래 기기와 같은 속도로 동작하면서 실제 주변 장치와 연결하려 할 때까지는 호스트의 RF가 큰 영향을 주지 않을 것 같습니다.
  • @anonymous_user9 — 시뮬레이션된 컴퓨터는 현실 세계에 존재하지 않으니 호스트의 물리적 특성은 호스트 컴퓨터를 오작동하게 만들 때만 시뮬레이션에 영향을 줍니다.
• @varispeed — M3 Max에서도 C64 속도의 31%밖에 못 낸다는 점이 핵심입니다. 겉보기에는 간단한 데이터 처리 작업도 실시간으로 처리하려면 FPGA가 여전히 유용한 이유입니다.
  • @rfgplk — 아니요. 이 구현은 최적화가 아주 나쁩니다. 소스만 훑어봐도 간단한 수정으로 100배 성능을 낼 수 있습니다. SIMD나 SWAR가 없고 시뮬레이션할 필요가 없는 것까지 계산합니다. CPU 에뮬레이션은 거대한 명령 분기 구조로 처리하고 명령 재정렬이나 추측 실행 최적화가 전혀 없습니다. 캐시도 계속 망가뜨리고 멀티스레딩도 없습니다.
  • @tombert — antirez는 Redis를 비롯한 여러 도구를 효율적으로 만든 사람이라서 100배 향상이 쉽게 가능하다는 주장에는 회의적입니다. 다만 Claude를 이용해 만든 코드라면 손볼 부분이 있을 수는 있습니다.
  • @flohofwoe — 그렇게 말했으니 같은 저수준 개념을 유지하면서 100배 빠른 구현을 보여줘야 할 것 같습니다. 코드 품질이 정말 나쁘다면 2~3배는 가능할 수 있지만 100배는 아닙니다. 이 시뮬레이터는 CPU와 CIA, SID, VIC-II 밖에서 일어나는 주소 디코딩과 메모리 접근까지 트랜지스터 netlist에 가까운 방식으로 계산합니다. 메모리 접근마다 큰 비용이 듭니다. 100배 빠르면 실제 C64보다 30배 빠른 셈이라 3GHz 호스트에서 C64 주기마다 100개 정도의 호스트 클록만 쓸 수 있습니다. 다섯 개 칩을 계산해야 하고 주소 디코딩과 메모리 접근 비용은 별도입니다. 칩을 스레드로 나눠도 매 에뮬레이션 클록마다 동기화해야 하므로 큰 도움이 되지 않습니다. 덧붙이자면 저는 이 시뮬레이터가 사용하는 핀 기반 칩 에뮬레이터의 저자입니다.
  • @LocalH — 성능을 더 높인 다른 에뮬레이터도 있습니다. 이건 에뮬레이터라기보다 시뮬레이터에 가깝습니다.
• @linker3000 — C64 보드 고장 진단과 수리에 쓸 수 있겠습니다. 진단 카트리지를 실행하는 기능도 있으면 좋겠습니다. 250407 보드에서는 PLA 교체 부품의 타이밍 문제를 겪었습니다. /CASRAM 선에 약 100pF 커패시터를 달아 신호를 조금 늦추는 게 해결책인 경우가 있습니다. 이 커패시터를 켜고 끄거나 값을 바꿔 효과를 볼 수 있으면 좋겠습니다.
• @Lerc — REU처럼 시뮬레이션한 카트리지를 연결하면 메모리 전송 기법도 동작할 만큼 정확한가요? 카트리지를 설계하려는데 실제 C64에 연기를 피우기 전에 시험할 수 있다면 좋겠습니다.
• @sssilver — 특정 결과가 나왔을 때 어떤 부품이 고장 났는지 역으로 찾아내는 기능도 가능할지 궁금합니다.

원문: GitHub / 번역·요약: Trawling