요약
6502 CPU로 만든 노트북 LT6502b가 더 얇은 본체와 큰 화면을 갖추고 완성됐습니다.
전자 공작과 신시사이저 이야기를 블로그에 올리는 폴라 매덕스가 자작 레트로 노트북 LT6502의 두 번째 버전을 마쳤다고 알렸습니다. 코드와 회로 기판 설계 파일은 Codeberg에 공개했습니다.
왜 중요한가
- 오래된 8비트 CPU로도 큰 화면과 무선 통신, 내장 배터리를 갖춘 휴대용 컴퓨터를 혼자 만들 수 있음을 보여 줍니다.
- 설계 파일과 코드가 공개돼 있어 다른 취미 개발자도 구조를 살펴보고 따라 만들어 볼 수 있습니다.
핵심 내용
- 화면은 9인치 800×480에서 10.1인치 1024×600 IPS로 바꿔 명암이 좋아지고 한 화면의 글자 줄도 늘었습니다.
- 반투명 주황색 케이스는 1호기의 절반 두께이고, 날렵하게 만들려고 확장 슬롯을 뺐습니다.
- 클럭은 8MHz에서 10MHz로 올렸고, SID(레트로 컴퓨터의 음원 칩) 에뮬레이터와 와이파이 모뎀을 달았습니다.
- 배터리 용량은 1호기와 비슷해 사용 시간도 비슷할 것으로 봤습니다.
- 약한 나사 고정부, 느리고 불안정한 와이파이 모뎀, 빈약한 스피커는 다음에 고칠 점으로 꼽았습니다.
HN 반응
- 6502가 1024×600 화면을 어떻게 그리는지 묻는 댓글에, 다른 이용자들은 메모리를 내장한 RA8889 디스플레이 컨트롤러가 화면을 맡는다고 설명했습니다.
- 사용자 RAM이 46KB에 그치는 이유로 ROM이 주소 공간을 차지한다는 설명이 나왔고, 뱅크 전환(메모리 묶음을 바꿔 끼우는 방식)으로 늘릴 수 있다는 논의가 이어졌습니다.
https://codeberg.org/TechPaula/LT6502b
사양:
10MHz로 동작하는 65C02
사용자 RAM 46KB
자체 확장 기능을 넣은 EhBASIC 22p2
eWOZMON
저장 장치는 컴팩트플래시
내장 배터리(현재 7400mAh)
USB-PD 충전 지원
10.1" 화면, 1024x600, 256색
와이파이 모뎀(이 프로젝트 기반 - https://github.com/dhansel/WifiModem )
사운드는 nanoSwinSID(비프음 포함)
"멋있어 보이는지 한번 보자. 멋있어 보이는 게 아주 중요하니까!"
결과는 굉장히 멋지네요. 이렇게 인상적인 디자인일 줄은 몰랐어요.
흥미로운 사양이네요. 왜 최소 64K(페이징 없이 쓸 수 있는 주소 공간 전체)가 아니라 48K RAM으로 했을까요?
옛날에 (Z80 기반) ZX 스펙트럼은 값싼 "불량" 메모리를 쓰려고 등급을 나눠서 48K를 쓰기도 했거든요. 설마 요즘 RAM 가격이 그렇게까지 미친 건 아니겠죠? :P
ROM이 주소 공간을 차지하는데 뱅크 전환이 없어서 그런 거 아닐까요? 앞으로의 목표 중 하나가 ROM과 RAM을 복사해 두고 주소 공간에서 ROM을 빼내는 거라고 하네요.
적어도 스펙트럼은 그랬습니다. RAM은 64K였지만 아래쪽 16K가 항상 ROM에 매핑되어 있었어요[0].
ROM을 페이지 아웃해서 나머지 16K에 접근하게 해 줬다면 재미있었을 겁니다. 테이프에서 자체 테이프 로딩 루틴이 든 작은 루틴을 불러오고, ROM을 빼낸 다음, 나머지 앱을 로드하면 끝이죠. 물론 리셋할 때 ROM을 다시 넣는 약간의 꼼수는 필요했겠지만요.
[0] http://www.breakintoprogram.co.uk/hardware/computers/zx-spectrum/memory-map
제가 알기로 싱클레어는 4116 8개와 4532 8개로 48K를 만들었습니다. 4532는 기본적으로 64K비트짜리 4164인데 칩의 절반만 정상 동작하는 물건이었고요.
BBC 마이크로의 사이드웨이즈 RAM 시스템 같은 건가요? 좋네요.
https://en.wikipedia.org/wiki/Sideways_address_space
RAM 비용을 25%나 아낀 거라고요!
비디오 부분을 이해해 보려고 하는데요, 데모 화면은 꽤 높은 해상도의 컬러로 나오고 사양에도 1024x600, 256색이라고 적혀 있잖아요. 6502로는 엄청난 건데, 그 시절에 제가 본 어떤 기기보다 훨씬 많은 픽셀을 구동하는 셈이라 화면 버퍼나 그래픽 칩 역할을 하는 다른 칩이 있을 줄 알았거든요...
그런데 보니까 LCD를 CPU 데이터 버스로 직접 비트뱅잉하는 것 같더라고요. 8비트 데이터 버스가 버퍼 IC를 거쳐 곧장 LCD로 가는 게 보입니다.
그렇게 큰 화면 버퍼가 들어갈 공간이 메모리 맵 어디에 있는지도 모르겠고요. 그러면 그래픽 처리를 전부 직접 짜고 메모리에서 쓸 위치도 직접 골라야 하는 건가요?
이전 글들을 보면 디스플레이 커넥터가 스마트 LCD 컨트롤러인 RA8889로 연결되는 것 같습니다. https://www.maddox.pro/?p=429
설명(https://www.raio.com.tw/en/RA8889.html 에서 가져왔습니다):
> RA8889는 강력한 디스플레이 기능과 내장 SDRAM 메모리를 갖춘 저전력 TFT 컨트롤러입니다. 디스플레이 메모리로 화면 내용을 빠르게 갱신할 수 있도록 병렬 8080/6800 8/16비트 MCU 인터페이스뿐 아니라 3/4선 SPI와 IIC 직렬 인터페이스도 제공합니다. 다중 디스플레이 버퍼, 화면 속 화면(PiP), 투명도 제어, 회전 및 미러링 표시, 내장 JPEG 및 AVI 디코더 등 강력한 기능이 많이 들어 있습니다.
저도 같은 게 궁금했는데, 문자 생성기와 기하 도형 기본 요소 등을 갖춘 CMOS 호환 고수준 TFT 드라이버를 쓰는 것 같네요. https://www.raio.com.tw/en/RA8889.html
1024 × 600에 256색이면 600kB입니다. 흑백이어도 64kB가 넘고요.
20Hz로만 갱신해도 초당 천만 픽셀 넘게 써야 해서 픽셀당 CPU 사이클이 1 정도밖에 안 됩니다. 이 CPU로는 절대 불가능해요.
아주 흥미로운 프로젝트입니다. 실제로 동작하는 영상과 만든 사람이 염두에 둔 용도를 볼 수 있으면 좋겠네요. 다른 글의 사진을 보면 48k RAM 칩이 있고 그 바로 근처에 1기가바이트짜리 SD 카드가 있는데, 대비가 극적입니다. 저장 장치에 RAM 내용을 21,845번이나 담을 수 있다는 얘기죠. 요즘 8GB 노트북이 같은 비율의 저장 공간을 갖는다면 174TB짜리 디스크가 되는 셈입니다.
'lt6502b' 태그로 찾아보면 메인보드 사진이 있는 다른 글들이 나옵니다. https://www.maddox.pro/?cat=65 (추가: codeberg 링크에 관련 사진이 다 있습니다)
레트로 세계에서는 "RAM 64k 대 저장 공간 8GB"라는 앞뒤 안 맞는 상황을 이미 수십 년 동안 겪어 왔습니다.
LOCI를 단 제 Oric Atmos에는 Oric용으로 나온 소프트웨어가 전부 8GB USB 스틱에 들어 있는데도 여유 공간이 말 그대로 약 8GB 남아 있습니다. 사용한 공간은 이제 오차 범위 수준이에요.
이게 바뀌었으면 좋겠지만요! ;)
오래된 컴퓨터는 죽지 않습니다. 죽는 건 사용자들이죠!
Paula의 의도는 컴퓨팅을 다시 친근하게 만드는 것이라고 생각합니다. 수많은 신시사이저 설계에 옛 기술에 대한 향수 어린 장난기가 담겨 있고, 교육용으로 로직 칩만 써서 본격적인 CPU 프로젝트도 만들었으니까요. 게다가 제가 알기로 그분은 UFO(TV 시리즈)의 열렬한 팬이라, 대안 컴퓨팅 쪽에도 창의적인 잠재력을 상당히 쏟고 있습니다.
저도 레트로 덕후로서 언젠가 이 노트북이 실제로 동작하는 모습을 보고 싶습니다. Oric-1/Atmos ROM이 올라간 모습이면 정말 멋질 거예요..
목표는 AI가 돌아갈 수 없으면서도 간단한 계산 작업에는 여전히 쓸모 있는 시스템을 만드는 겁니다. 나머지는 전부 이 진실을 가리는 포장이고요.
맞아요, 정말 그렇습니다. 이 기계 자체가 목적이에요. 그분의 설계는 전부 뚜렷한 목표를 향해 의도적으로 만들어졌다는 게 보입니다.
AI를 돌릴 수 없는 시스템을 만든다는 목표는 사실 무어의 법칙 덕분에 늘 저절로 달성되어 왔습니다. 특이점을 향해 가는 동안에는 우리가 AI를 못 돌렸으니까요. 그게 지금 중요한지, 아니 예전에는 중요하지 않았던 적이 있는지는 결과를 어떻게 보느냐에 달린 문제입니다. AI를 걱정해야 하는 건 지금일까요, 20년 전일까요?
저는 Paula Maddox 같은 사람이 세상에 충분히 있다는 것만으로, 대단한 일을 하는 데 AI는 필요 없고 대단한 사람들이면 된다는 게 증명된다고 생각합니다.
6502는 사실 그 이상은 주소 지정을 못 합니다. 게다가 요즘 SD 카드에 내장된 플래시 컨트롤러가 6502보다 훨씬 강력할 거예요. 그렇게 작은 SD 카드를 아직도 살 수 있다는 게 놀랍네요!
뱅크 전환을 쓰지 않는다면 그렇죠. 역사적으로 6502 기계들은 뱅크 전환을 많이 썼습니다(Apple III/IIe/IIc, BBC Master 128, Commodore 128, Commodore CBM-II 등).
참고로 뱅크 전환을 한다고 CPU가 64K보다 많은 메모리를 "주소 지정"할 수 있게 되는 건 아닙니다. 기계가 64K보다 많은 메모리를 "가질" 수 있게 될 뿐이고, CPU가 한 번에 주소 지정할 수 있는 건 그중 64K뿐이에요.
MOS 6509는 MOS 8722 같은 외부 MMU 칩이 아니라 CPU 안에 뱅크 전환 하드웨어를 내장하고 있습니다.
CBM-II의 6509와 C128의 8502+8722 조합은 근본적으로 뭐가 다른가요? 그리고 그 둘은 8086/8088의 세그먼트 방식과 근본적으로 뭐가 다른가요?
6502에서 뱅크 전환으로 수 메가바이트 RAM을 관리하는 게 얼마나 고통스러울지 상상이나 되세요!
뱅크 전환은 거의 모든 주요 컴퓨터와 게임기가 64k보다 큰 카트리지와 메모리를 다룬 방법입니다.
C64는 실제로 RAM 64K, 장치(그래픽, 사운드 등) 4k, ROM 16K를 갖고 있었어요.
다른 글의 사진을 보면 48k RAM 칩이 있고 그 바로 근처에 1기가바이트짜리 SD 카드가 있는데, 대비가 극적입니다
그러고 보니 지난 10년 사이의 저가 MP3/MP4 플레이어는 RAM 수백 KB, 수십 MHz짜리 8비트 CPU, 낸드 플래시 몇 GB로 구성되어 있었습니다. https://en.wikipedia.org/wiki/S1_MP3_player
80C51은 절대 사라지지 않네요? 사라질 이유도 없긴 하지만요.
8051은 특허 등이 전부 만료돼서 사실상 '공짜'나 마찬가지입니다. 그래서 "이 문제에 마이크로컨트롤러를 조금 붙여야겠다" 싶을 때 1페니도 안 되는 소자를 집어 들 수도 있고, FPGA나 ASIC 한구석에 무료 또는 저렴한 8051 IP를 살짝 넣어서 50년 넘게 쌓인 경험, 도구, 예제를 그대로 쓸 수도 있어요. ARM이나 RISC-V만큼 멋지진 않아도 제 몫은 합니다.
6502는 너무 원시적이라 RAM이 128바이트뿐인 아타리에서도 돌아갑니다.
네, 128바이트요. 코드, 데이터, 비디오, 나머지 전부를 거기에 넣습니다.
(그래도 64KB까지 주소 지정은 됩니다)
너무 원시적이라 정수 곱셈도 못 합니다. 곱하려면 알고리즘을 직접 짜야 해요.
아타리 2600 콘솔(VCS) 얘기시죠? 거기에는 6507이라는 제한된 버전의 CPU가 들어갑니다. 주소 공간이 16KB로 줄어 있어요.
이 기계에 RAM이 128바이트뿐인 건 맞지만, 코드와 데이터는 카트리지에 있고 카트리지에는 최대 64KB ROM이 들어갈 수 있습니다(뱅크 전환으로 한 번에 4KB씩 노출). 또 그래픽은 TV 화면에서 그때그때 만들어 내는 방식("빔 레이싱")이라 소중한 RAM을 프레임버퍼에 쓸 필요가 없습니다.
NES나 C64처럼 이후에 나온 6502 기반 기기들에 비하면 게임을 개발하기 쉬운 플랫폼은 분명 아니었지만, 말씀하신 것만큼 지옥은 아니었습니다.
"빔 레이싱"이라는 발상 자체가 광기를 증류해 놓은 것 같아요. 프레임버퍼도 없이 RAM 128바이트만으로 어떻게 그림을 그리고 모든 것의 위치를 추적하죠? 이 댓글 하나만 해도 그보다 더 많은 RAM을 쓰는데요.
https://youtu.be/sJFnWZH5FXc
요약(tl;dw) - 배경은 20비트로 정의하고, 이걸 반복하거나 좌우 대칭으로 펼쳐 배경을 만듭니다(예: 00000000111111110000은 배경을 0000000011111111000000000000111111110000으로 만들 수도 있고 0000000011111111000000001111111100000000으로 만들 수도 있음). WSYNC($D40A)에 쓰면 프로세서가 다음 스캔라인이 시작될 때까지 멈춥니다. 그다음 머신 사이클을 세어서 적절한 타이밍에 배경을 바꿔야 양쪽 절반이 서로 달라집니다. 이걸 스캔라인마다 반복해 배경 전체를 정의합니다. 엄밀한 의미의 "프레임버퍼"는 없습니다
그래픽 비트맵 데이터는 ROM에 있었고, CPU가 그걸 한 줄씩 TIA의 그래픽 또는 플레이필드 데이터 레지스터에 곧바로 복사했습니다. RAM에 중간 복사본을 둘 필요가 없었어요.
그래도 ROM의 어느 바이트를 복사할지 정하는 카운터(인덱스)는 필요했습니다. 그래픽 비트맵 데이터를 페이지 시작 위치(예: $FD00)에 두면 포인터에서 1바이트만 증가시키면 되고 다음 바이트로 올림이 넘어가는 걸 신경 쓸 필요가 없어서, 아마 그렇게 배치하고 싶었을 겁니다.
가로 해상도는 160이었고 보통 255줄 미만의 그래픽을 생성했으니, X와 Y 위치를 추적하는 데는 2바이트면 충분했고 메타데이터용으로 몇 바이트 더 썼을 정도입니다.
코드는 전부 ROM에 있고, 에셋도 마찬가지입니다. 그래서 예측할 수 없게 움직이는 스프라이트만 추적하면 되는데, 2600 게임 대부분은 그런 게 아주 적었어요. 팩맨이나 스페이스 인베이더 같은 게임도 활동하는 객체가 매우 적고 그마저 움직임에 엄격한 제약이 있었습니다.