친구의 게임이 너무 느려서, 6809의 스택 명령으로 화면을 복사한 이야기
A great old-timey game-programming hack (2013)
1980년대 8비트 PC에서 친구가 만든 사이드스크롤 게임이 너무 느려 플레이가 불가능했다. 코드는 이미 루프 언롤링과 오프셋 주소 지정으로 60%까지 최적화된 상태였다. 저자는 6809 매뉴얼을 뒤져 PSHS 같은 특이한 명령을 찾아내고, 결국 하드웨어 스택을 화면 복사에 악용하는 기상천외한 해킹으로 문제를 해결한다.
그래픽 하드웨어는 아무 일도 하지 않았다. 그 PC에서 화면에 뭔가를 그리려면 바이트 하나하나를 직접 옮겨야 했다. 텍스처 매퍼도, 블리터도 없이. 그저 바이트뿐이었다.
HN 토론
54- mikewarot
MS-DOS 시절, 내 친구 Ward Christensen은 IBM의 기술 영업 지원 부서에서 일했습니다. 그들은 판매하는 모든 제품을 PC에서 읽을 수 있는 형식으로 나열한 파일을 비공식적으로 유지하고 있었죠. 그는 텍스트 편집기로 그 파일을 검색하는 데 정말 능숙했지만, 동료들이 쉽게 검색할 수 있도록 MS-DOS 기반의 독립 실행형 프로그램을 원했습니다. 그렇게 해서 PCxREF가 탄생했는데, 이는 내가 작성한 Turbo Pascal 기반 프로그램으로 검색 기능을 포함하고 있었습니다.
처음에는 내장된 문자열 매칭을 사용한 순진한 검색 방식이었습니다. 파일 크기와 PC 속도 때문에 검색에 30초 이상 걸리는 경우도 있었죠. Ward는 더 빠르기를, 훨씬 더 빠르기를 원했습니다.
결국 나는 검색하려는 텍스트를 특별한 종류의 비트 마스크 테이블로 변환하는 알고리즘을 고안했습니다. 256바이트 길이의 테이블로 0으로 초기화되었죠. 검색하려는 문자열의 첫 문자가 D라면, 대소문자 구분을 처리하기 위해 $44와 $64 마스크의 첫 비트가 설정됩니다. 와일드카드 *는 길이가 1자에 불과했지만 해당 문자에 대한 모든 비트를 설정했습니다. 그런 다음 8088 XLAT 명령어와 아주 작은 루프를 사용하여 검색 대상 텍스트의 문자를 읽고, 이를 마스크 테이블의 인덱스로 사용한 다음 다른 레지스터의 기존 플래그와 AND 연산하고, 시프트하여 CARRY(일치!)를 확인하고 0이 아니면 루프를 반복했습니다.
전체 파일이 RAM에 로드된 경우 검색 시간이 3초 미만으로 줄었습니다. 그 얇은 […]
- taspeotis
다소 관련된 내용 [1]:
> 몇 년 전, 나는 지금은 사라진 비디오 어댑터 제조사인 Video Seven에서 VGA 클론 개발을 돕고 있었습니다. Video Seven의 VGA 칩을 설계하던 Tom Wilson은 VGA를 최대한 빠르게 만들기 위해 몇 달 동안 밤낮으로 일했고, 성능을 거의 최대치로 끌어올렸다고 확신했습니다. 그러나 Tom이 칩 설계를 마무리하던 중, 경쟁사인 Paradise가 FIFO를 추가하여 개발 중인 클론의 성능을 끌어올렸다는 소식이 사방에서 전해졌습니다.
그가 아는 것은 그게 전부였습니다. 어떤 종류의 FIFO인지, 얼마나 도움이 되었는지 등에 대한 정보는 전혀 없었죠. 그럼에도 불구하고 평소 온화하고 느긋한 성격이던 Tom은 카페인을 너무 많이 섭취한 사람처럼 눈이 퀭하고 불안한 표정으로, 절망적으로 부족한 정보에서 Paradise가 무엇을 했는지 알아내려고 애썼습니다. 결국 그는 Paradise가 시스템 버스와 VGA 사이에 쓰기 FIFO를 넣었을 것이라고 결론지었습니다. 그래서 CPU가 비디오 메모리에 쓸 때 쓰기가 즉시 FIFO로 들어가고, CPU가 디스플레이 메모리에 쓸 때마다 지연되는 대신 계속 처리할 수 있게 했다는 것이죠.
Tom은 완전한 FIFO를 구현할 게이트나 시간이 없었지만, 1단계 깊이의 FIFO는 구현할 수 있었고, CPU가 VGA보다 한 번의 쓰기를 앞설 수 있게 했습니다. 얼마나 잘 작동할지 확신은 없었지만 그게 그가 할 수 있는 전부였기에, 그것을 넣고 칩을 테이프아웃했습니다.
그 1단계 깊이 FIFO는 결국 […]
- green_wheel
멋진 글입니다. 항상 남의 떡이 커 보이는 법이지만, 그 시절의 코딩은 정말 멋져 보입니다. 오늘날은 온통 패키지 매니저니 툴체인이니 하는 것들뿐이죠. 우리는 실제로 코드를 실행하는 것과 너무 멀리 추상화되어 있습니다. 이런 글을 읽으면 CPU가 "나에게로 돌아와어어어"라고 외치는 소리가 들리는 것 같습니다.
- pjc50
6509가 실제로 어떤 컴퓨터에 들어갔는지 알아내려고 하는 중입니다. Dragon이나 Tandy가 후보인 것 같네요?
이런 종류의 일 때문에 Amiga가 코프로세서 모음을 추가하여 엄청난 성공을 거둔 것입니다: https://en.wikipedia.org/wiki/Amiga_Original_Chip_Set
각 코프로세서는 RAM에서 바이트를 이동하고 변환하는 제한적이지만 전용 기능을 가지고 있었습니다. 특히 블리터는 타일과 스프라이트 렌더링을 위해 메모리를 옮기는 데 전념했습니다.
- Agentlien
이런 종류의 이야기는 항상 읽기에 너무 멋집니다. 이런 커뮤니티에서는 종종 그 시절과 그들이 제시했던 도전들에 대해 아쉬운 꿈을 꾸곤 합니다.
저는 그 시절을 직접 겪지 않을 만큼 젊지만, 어릴 때부터 프로그래밍을 해왔고 지난 15년 동안 그래픽 작업을 해왔습니다.
이런 종류의 흥분은 제가 처음 C와 C++를 배울 때 느꼈던 감정입니다. 내부에서 어떻게 작동하는지 정말로 이해하려고 노력하는 것이죠.
지금 직장에서 저수준 그래픽과 성능 작업을 할 때도 여전히 그런 느낌을 받습니다. 사실, 텍스처 메모리 손상이 발생했을 때 이 기사는 제가 최근에 텍스처 메모리 레이아웃에 관한 글을 쓰도록 영감을 준 사건들과 섬뜩할 정도로 비슷하게 느껴졌습니다 ( https://agentlien.github.io/texture ).