Lobsters

Amiga screens: a primer

Amiga 화면의 작동 원리와 그래픽 하드웨어

Amiga의 ‘screen’은 해상도와 색상 수가 서로 다른 그래픽 영역이며, 여러 화면을 겹치거나 빠르게 전환할 수 있습니다. 글은 비트플레인과 Copper, 듀얼 플레이필드 같은 OCS 그래픽 기능이 메모리를 아끼면서 멀티태스킹과 게임 그래픽을 구현한 방식을 설명합니다.

AI 요약

Amiga 운영체제에서 ‘screen’은 그래픽을 그리는 영역을 뜻합니다. 현대 컴퓨터처럼 하나의 고정 해상도 화면에 창을 쌓는 방식과 달리, Amiga 프로그램은 해상도와 색상 깊이가 서로 다른 화면을 여러 개 열 수 있습니다. 화면 크기와 색상 수를 용도에 맞게 정하는 방식은 메모리가 비쌌던 시절의 제약에 대응하면서, 여러 작업을 동시에 실행하는 데도 쓰였습니다.

팔레트와 비트플레인

원문은 주로 OCS(Original ChipSet)를 기준으로 설명합니다. Amiga는 픽셀마다 색상값을 직접 저장하기보다, 화면별 색상 팔레트에서 색상 인덱스를 고릅니다. 색상 인덱스는 비트플레인(bitplane)을 조합해 표현합니다. 비트플레인 하나면 2색, 두 개면 4색을 나타내며, OCS에서는 최대 다섯 개를 써 32색을 표현합니다. AGA(Advanced Graphics Architecture)에서는 최대 여덟 개로 256색까지 다룹니다.

비트플레인은 픽셀마다 필요한 비트만 저장하므로 메모리를 아낍니다. 화면마다 필요한 색상 깊이를 다르게 지정할 수도 있습니다. 예를 들어 두 색만 필요한 텍스트 편집기는 적은 메모리를 쓰고, 동시에 실행하는 그래픽 프로그램은 더 많은 비트플레인을 사용할 수 있습니다. 화면의 크기와 위치도 자유롭게 정할 수 있어, 실제 표시 영역의 일부만 사용하는 화면을 만들 수 있습니다.

PAL 기준 OCS의 저해상도는 320×256 픽셀이고, 인터레이스를 쓰면 세로 해상도가 512픽셀로 늘어납니다. 이 모드에서는 최대 32색을 씁니다. 고해상도는 640×256 픽셀이며 최대 16색을 표현합니다. 오버스캔으로 표시 영역을 조금 넓힐 수 있지만, 모든 모니터나 TV에서 가장자리가 보장되지는 않습니다. 저해상도 모드에서는 여섯 번째 비트플레인을 HAM(Hold-And-Modify)에 써 4096색을 활용하거나, EHB(Extra Half-Brite)로 기존 32색의 절반 밝기 색을 더할 수 있습니다.

화면을 섞는 그래픽 하드웨어

Amiga는 화면 위치를 빠르게 바꾸고 전체 화면을 스크롤할 수 있습니다. Copper라는 보조 프로세서는 화면을 그리는 하드웨어와 동기화해 작동합니다. 화면 갱신 중 특정 시점에 해상도와 색상 깊이를 바꾸거나, 색상 레지스터 값을 조정하는 작업을 맡습니다. 색상값을 줄마다 바꾸면 Copper gradient 또는 Copper bars라고 부르는 효과를 만들 수 있습니다. 팔레트 인덱스 수를 늘리지 않고도 화면에 더 많은 색이 나타나는 것처럼 보이게 합니다.

서로 다른 해상도와 팔레트를 쓰는 화면을 한 번에 표시할 수도 있습니다. 게임은 게임 영역에 32색을, 상태 표시 영역에 별도의 32색을 배정해 동시에 더 많은 색을 보여줄 수 있습니다. Dual Playfields는 앞쪽 화면의 색상 인덱스 0을 투명하게 취급해 뒤쪽 화면이 드러나도록 합니다. 각 화면은 별도로 스크롤하거나 그림을 그리고 팔레트를 바꿀 수 있습니다. 하드웨어 스프라이트를 화면 사이에 배치하면 여러 그래픽 층을 조합할 수도 있습니다.

사용자 경험과 멀티태스킹

Amiga에서는 화면 오른쪽 위의 버튼이나 시스템 단축키로 실행 중인 화면을 전환합니다. 화면 제목 표시줄을 아래로 끌어내리면 뒤에 있는 다른 화면을 드러낼 수도 있습니다. 글쓴이는 화면을 끌어내리는 기능이 자신의 작업 흐름에서 자주 쓰이지는 않는다고 덧붙입니다. 다만 1985년에는 멀티태스킹과 컬러 그래픽을 함께 다루는 경험이 흔치 않았습니다. 글에서 소개한 영상은 7MHz Amiga 600에서 음악을 재생하면서 텍스트 편집기와 Deluxe Paint를 실행하고 화면을 전환하는 모습을 보여줍니다.

글은 이런 화면 방식이 단순한 옛날식 창 관리에 그치지 않는다고 설명합니다. 낮은 해상도에 맞춘 전체 화면 작업은 파일 관리자나 터미널처럼 화면 가장자리를 조작에 활용하는 프로그램과 잘 어울립니다. 반면 현대 와이드 모니터에서는 80×24 문자 터미널이나 정사각형에 가까운 파일 관리자 화면을 같은 방식으로 쓰기 어렵습니다. Amiga의 화면 기능은 제한된 메모리와 그래픽 성능 안에서 여러 작업을 이어가고, 게임에서는 스프라이트와 블리터(blitter)를 활용해 그래픽을 빠르게 그리는 기반이 됐습니다.

Lobsters 반응

  • @icefox — 화면 전환이 얼마나 빠른지 보여주려고 짧은 영상을 준비했습니다. Amiga 600에 연결한 평면 모니터를 촬영했으며, 이 기계는 7MHz, 즉 0.007GHz로 작동하고 1985년 오리지널 Amiga 1000과 기본적으로 같은 하드웨어를 바탕으로 합니다. 음악을 재생하면서 텍스트 편집기와 Deluxe Paint를 실행하고 화면 전환과 끌어내리기도 합니다. 요즘 기준으로 영상이 대단해 보이지 않을 수 있지만, 고해상도 그래픽을 CPU로 렌더링해 본 적이 있다면 7MHz로 이걸 해내는 일이 얼마나 놀라운지 감이 올 겁니다. RAM도 1~6MB였을까요? 요즘은 프레임버퍼가 우리를 너무 편하게 만들었습니다. 1985년에 이런 모습을 직접 보지는 못했지만, 정말 마법처럼 느껴졌을 것 같습니다.
    • @m_eiman — 영상이 정말 인상적이었습니다. 그 시대를 살지 않은 사람에게 얼마나 대단했는지 전달하기 어렵다는 점이 아쉽습니다. A500은 RAM 512kB로 출시됐고, 확장에 따라 9MB에서 138MB까지 늘릴 수 있었습니다.
    • @koala — 1985년 IBM PC가 어땠는지 나란히 보여주는 게 좋겠습니다. PC가 Amiga를 언제 앞섰는지는 확실하지 않지만, 1985년에는 Amiga가 다른 제품과 비교해 정말 대단했습니다.
    • @jfb — 1985년 IBM PC가 어땠는지 나란히 보여주는 게 좋겠습니다. PC가 Amiga를 언제 앞섰는지는 확실하지 않지만, 1985년에는 Amiga가 다른 제품과 비교해 정말 대단했습니다. VGA가 나올 때까지는 아니었던 것 같습니다. 그러면 PS/2 시기였을까요? 그때도 PC는 Amiga와 비교해 원시적이었습니다. 하지만 대량 보급에는 그 나름의 힘이 있습니다.
    • @koala — 네, 그 시기쯤이었을 겁니다. SVGA도 얼마 지나지 않아 나왔습니다. AGA는 1992년에 나왔지만, 그때는 PC가 이미 Amiga를 앞질러 가고 있었다고 생각합니다. 제 생각에 Windows 95는 Workbench보다 훨씬 발전했고 생산성 면에서도 Amiga를 앞섰지만, Amiga와 완전히 동떨어진 수준은 아니었습니다. 집에서 쓰는 컴퓨터 시스템에 큰 도약이 있었다고 보는 건 Windows NT 계열, 즉 2001년의 XP, OS X, Linux부터입니다.
    • @m_eiman — 시간을 들이고 프로그래머가 기지를 발휘하면 오리지널 PC도 인상적인 결과를 낼 수 있었습니다. 하지만 당시 나온 제품 가운데 눈에 띄는 게 있었을지는 모르겠습니다. ‘8088 MPH’ 데모를 못 봤다면 꼭 보세요.
    • @koala — 맞습니다. 다만 반대 방향으로도 그렇습니다. ‘Dread’와 ‘Grind’는 기본 A500에서 작동하는 Doom 스타일 게임입니다. 당시에는 그런 그래픽을 구현할 수 있다고 생각하지 못했습니다. 오래된 시스템을 가져와 수십 년 동안 아무도 찾아내지 못한 방법을 알아내는 사람들을 보면 늘 놀랍습니다.
    • @classichasclass — 음악도 한 번도 끊기지 않는군요.
    • @jfb — 정말 마법처럼 보였습니다. Amiga를 보고 정말 감탄했지만, 안타깝게도 우리는 PC를 썼고 나중에는 Mac을 썼습니다.
  • @dzwdz — 각 비트플레인은 메모리에서 따로 저장되며, 픽셀의 색상 인덱스를 바꾸려면 각 평면의 비트를 바꿔야 합니다. 그래서 비트플레인 하나면 2색, 두 개면 4색을 나타내고, 오리지널 Amiga에서는 최대 다섯 개로 32색, AGA에서는 8개로 256색까지 표현합니다. 픽셀 하나의 상태를 메모리 여러 곳에 나눠 저장하면 작업하기 불편해 보입니다. 실제 프로그래밍은 어땠는지 궁금합니다.
    • @spc476 — 맞습니다. 픽셀 하나를 바꾸는 일은 꽤 불편했지만, 그런 작업은 드물었습니다. 오리지널 Amiga에는 화면 어디든 놓을 수 있는 하드웨어 스프라이트 8개가 있었고, 기본적으로 8색이었던 것 같습니다. 한 스캔라인에는 스프라이트를 8개까지만 표시할 수 있었지만, 스프라이트가 화면에 그려진 뒤에는 아래쪽 다른 위치에서 재사용할 수 있었습니다. 블리터 하드웨어도 있었는데, CPU가 설정만 해주면 논리 연산 AND, OR, XOR 등을 써서 다색 그래픽 데이터를 비트플레인에 빠르게 옮길 수 있었습니다. DMA도 풍부해 CPU가 메모리 복사 작업을 맡지 않아도 됐습니다. Amiga 500을 썼고 직장에서는 거의 혼자 SGI를 사용했는데도, Amiga 프로그래밍이 더 재미있었습니다.
    • @dzwdz — 블리터가 비트플레인을 추상화해줬나요, 아니면 각 비트플레인마다 연산을 반복해야 했나요?
    • @kornel — RAM이 느려 모든 픽셀을 실시간으로 갱신하기 어려웠습니다. 그래서 한 번에 8픽셀의 비트 하나를 바꾸는 방식이 유용했습니다. 타일 그래픽에서 특히 그랬습니다. 예를 들어 비트플레인 하나에만 그리면 팔레트 인덱스의 최상위 비트가 바뀌어 색이 이동합니다. 반투명과 비슷한 효과를 낼 수 있었습니다. 실제 반투명은 사치에 가까웠습니다. RGBA 버퍼도 없었고 곱셈을 처리할 성능도 없었습니다. 부동소수점 연산을 하려면 확장 카드를 사야 했습니다. 미리 계산한 팔레트 조회 테이블을 만들기도 빠듯했습니다. 배경에 4비트, 전경에 4비트를 배정하고 비트플레인의 시작 주소를 바꿔 각각 따로 스크롤할 수도 있었습니다. 비트플레인 방식은 5비트와 6비트, 즉 64색 모드도 가능하게 했습니다. 아니면 다른 색 깊이 방식만큼 힘든 정도였을 겁니다. 하지만 픽셀 단위로 그래픽을 그릴 때는 병목이 됐습니다. 한동안 데모신은 chunky-to-planar 변환 알고리즘을 계속 최적화했습니다. 이런 오버헤드는 Amiga의 몰락을 부른 여러 요인 가운데 하나였습니다.

원문: Data Gubbe / 번역·요약: Trawling