Hiểu về thiết kế hệ thống video của Super Nintendo
(fabiensanglard.net)- Video của SNES được thiết kế trong giới hạn của TV CRT và tín hiệu NTSC đầu thập niên 1990, với màn hình 256x224, tốc độ khung hình 60.098Hz và các khoảng blanking phù hợp
- CRT không hoạt động theo lưới pixel mà vẽ các dòng quét bằng súng điện tử, tín hiệu RGB và HSYNC/VSYNC, còn progressive và interlace được phân chia theo khác biệt vị trí của tín hiệu đồng bộ
- Vì không thể có bộ dao động video riêng, SNES chia xung nhịp chủ 21.47727MHz để tạo ra dot clock 5.3693175MHz, và đạt 60.098Hz thay vì chuẩn NTSC 59.94Hz bằng tổ hợp 262 dòng · 341 dot
- Chế độ cơ bản gồm 224 dòng hiển thị và 38 dòng VBLANK trong tổng 262 dòng, cùng 256 dot hiển thị và 85 dot HBLANK trong tổng 341 dot, để đảm bảo thời gian cho PPU xử lý bộ đệm dòng sprite
- PAL SNES cung cấp bộ dao động khác và chế độ overscan 240 dòng để phù hợp môi trường 50Hz · 312.5 dòng, nhưng đa số game vẫn dựa trên 224 dòng nên thường xuất hiện dải đen và chạy chậm hơn 17%
Điểm mà TV CRT đã giới hạn thiết kế
- Mục tiêu đầu ra video mặc định của SNES là TV CRT tiêu chuẩn, và TV thời đó nhận tín hiệu phát sóng analog NTSC qua ăng-ten hoặc nhận video ngoài qua cổng AUX
- Cổng đầu vào phụ trên TV phổ thông thường gồm jack composite video màu vàng cùng jack âm thanh stereo màu trắng và đỏ
- Có thể xem CRT như một thiết bị vẽ dòng ở khoảng 15kHz, có khả năng vẽ khoảng 15.000 dòng mỗi giây
CRT hoạt động bằng dòng quét và tín hiệu, không phải pixel
- Bên trong CRT có ba súng điện tử, và electron bị bẻ hướng lên xuống, trái phải nhờ nam châm dọc và ngang
- Bản thân electron không có màu; mặt nạ sẽ hướng electron từ từng súng tới đúng dải phosphor màu tương ứng
- CRT không có pixel, và các khe cũng không phải pixel
- TV độ phân giải cao có khe nhỏ hơn, nên có thể thể hiện tín hiệu cùng màu theo phương ngang trung thực hơn
- CRT nhận năm tín hiệu qua bốn dây
- Tín hiệu Red, Green, Blue được nối trực tiếp tới từng súng điện tử
- Nếu ba dây RGB không có tín hiệu thì electron không được bắn ra, nên màn hình hiển thị màu đen
- Dây màu trắng là Composite Sync(CSYNC), truyền cả HSYNC và VSYNC cùng nhau
- CRT không tự tạo VSYNC mà nhận tín hiệu đồng bộ từ hệ thống bên ngoài để căn vị trí súng điện tử
Sự khác biệt giữa progressive và interlace
- CRT vẽ một dòng từ trái sang phải, rồi khi nhận HSYNC sẽ quay về mép trái màn hình tại X=0
- Khi nhận VSYNC thì nó trở về phía trên cùng tại Y=0
- Trong lúc di chuyển sang phải, súng điện tử đi theo quỹ đạo hơi nghiêng xuống dưới, nên dòng tiếp theo sau HSYNC được vẽ bên dưới dòng trước đó
- Nếu VSYNC xuất hiện đúng thời điểm với HSYNC cuối cùng thì các field được vẽ chồng đúng cùng vị trí, tạo thành quét progressive
- Nếu VSYNC xuất hiện giữa hai HSYNC thì các dòng của field kế tiếp sẽ chen vào giữa các dòng của field trước, tạo thành interlace
- Interlace giúp tăng gấp đôi độ phân giải dọc nhưng làm tốc độ cập nhật của từng dòng giảm còn một nửa
- NTSC gửi hai field ở khoảng 30Hz, nên CRT có khoảng cách dòng để phục vụ interlacing; khi vẽ progressive sẽ thấy các khoảng scanline màu đen
Thông số NTSC và giới hạn của phương án thiết kế đơn giản
- Thiết kế của SNES phải gần với các giá trị mà TV NTSC có thể xử lý
- Tỷ lệ khung hình: 4:3
- Số dòng mỗi field: 262.5
- Số dot mỗi dòng: 341.25
- Tần số field: 59.94Hz
- NTSC đen trắng ban đầu là 60Hz, nhưng NTSC màu đã giảm tần số đi 0.1% để thêm màu mà vẫn giữ tương thích ngược và tránh artifact
- Một phương án đơn giản là chọn progressive 262 dòng, 350 dot, 59.94Hz, từ đó cần dot clock 5,496,498Hz
- Nhưng thiết kế này không phù hợp với SNES thực tế
- Do giới hạn chi phí, không thể có bộ dao động dành riêng cho hệ thống video, và các phân hệ phải chia tần từ master oscillator
- Trong lúc CRT quay về vị trí hiển thị, súng điện tử vẫn có thể tiếp tục bắn nên cần xử lý overscan và blanking
Blanking và lựa chọn độ phân giải dọc
- Nếu súng điện tử tiếp tục bắn khi vị trí đang được reset theo chiều ngang hoặc dọc, sẽ xuất hiện artifact nhìn thấy được
- TV dùng overscan, tức hiển thị hình ảnh hơi lớn hơn màn hình, và mức độ này khác nhau tùy TV
- Sau VSYNC và HSYNC, vị trí súng điện tử dao động trong chốc lát, nên cần một khoảng ngừng bắn electron trước khi có được đường quét ổn định
- Khoảng ngừng bắn electron sau VSYNC là VBLANK
- Khoảng ngừng bắn electron sau HSYNC là HBLANK
- Các hệ thống cạnh tranh thời đó cũng dùng blanking
- Capcom CPS-1: 262 dòng, VBLANK 38 dòng, hiển thị 224 dòng, 59.6294fps
- Sega Genesis: 262 dòng, VBLANK 38 dòng, hiển thị 224 dòng, 59.9227fps
- Neo-Geo AES: 264 dòng, VBLANK 40 dòng, hiển thị 224 dòng, 59.18fps
- SNES chia 262 dòng thành 224 dòng hiển thị + 38 dòng blank
- 224 chia hết cho 16, rất phù hợp với pipeline đồ họa dựa trên tile 16x16
Độ phân giải ngang và 60.098Hz
- SNES chia xung nhịp chủ 21.47727MHz cho 4 để dùng dot clock 5.3693175MHz
- Tốc độ khung hình, số dòng, số dot mỗi dòng và dot clock liên kết chặt với nhau
- Nếu dùng mục tiêu 59.94Hz và 262 dòng thì mỗi dòng sẽ ra khoảng 342 dot, nhưng do artifact từ carrier của đầu ra composite nên kỹ sư Nintendo buộc phải dùng 341 dot
- Với tổ hợp này, tốc độ khung hình của SNES là 5.3693175MHz / (341 * 262) = 60.098Hz
- 60.098Hz khác với 59.94Hz của NTSC, nhưng vẫn nằm trong khoảng chấp nhận được của CRT
Vì sao 256x224 trở thành màn hình mặc định
- Không thể dùng toàn bộ 341 dot của một dòng làm vùng hiển thị, vì cần HBLANK để che rung, artifact và overscan của TV
- Với 224 dòng, chiều rộng hiển thị gần tỷ lệ 4:3 là 224 * 4/3 = 298 dot
- Pipeline tilemap dùng tile 16x16, nên các giá trị khả dĩ là 304, 288, 272, 256, 240...
- 304 dot là giá trị khá gần với màn hình ít méo nhất
- PPU còn bị ràng buộc phải nạp bộ đệm dòng sprite trong thời gian HBLANK
- Nếu chọn hiển thị 304 dot thì HBLANK chỉ còn 37 dot, khoảng 7µs
- Có thể như vậy là không đủ dài để nạp dữ liệu cho tối đa 128 sprite
- Lựa chọn cuối cùng là 256 dot hiển thị + 85 dot HBLANK
- PPU có khoảng 16µs trong HBLANK
- Tỷ lệ vùng hiển thị là 8:7 chứ không phải 4:3, nên khi hiện trên CRT sẽ có méo nhẹ
Sự đánh đổi của chế độ độ phân giải cao
- Cấu hình video SNES cơ bản là độ phân giải overscan 341x262, độ phân giải hiển thị 256x224, tốc độ khung hình 60.098Hz
- 99% game dùng cấu hình này, nhưng SNES vẫn có chế độ độ phân giải cao để tăng gấp đôi độ phân giải dọc hoặc ngang
- Độ phân giải dọc 448 dòng có thể đạt được bằng cách phát VSYNC ở vị trí nửa dòng sau HSYNC cuối cùng để tạo khung interlace
- Khi đó mỗi dòng chỉ được làm mới ở 30.049Hz = 60.098/2
- Hình sẽ nhấp nháy và không đẹp mắt, nhưng độ phân giải dọc cao hơn
- Tăng gấp đôi độ phân giải ngang còn khó hơn vì không có dot clock cần thiết
- SNES dịch field thứ hai sang ngang một chút để các điểm của nó nằm xen giữa các điểm của field trước
- Kết quả là tốc độ khung hình giảm một nửa và màu bị nhòe đáng kể
- fullsnes.txt tổng hợp nhiều ví dụ về cách các tựa game dùng chế độ độ phân giải cao
- Logo Nintendo trong Donkey Kong Country 1: 512x224, BgMode5
- Màn hình cài đặt của Seiken Densetsu 2: 512x224, BgMode5
- RPM Racing: intro và trong game 512x448, BgMode5+Interlace
- Trường hợp Ranma 1/2 thực ra là 256x224, nhưng interlace vô tình bị bật nên gây nhấp nháy không cần thiết
PAL, SECAM và vấn đề của SNES bản châu Âu
- TV châu Âu dùng PAL thay vì NTSC, còn Pháp cũng dùng SECAM
- Môi trường PAL yêu cầu chính xác 50Hz và 312.5 dòng mỗi field
- PAL SNES dùng bộ dao động 17.7344750MHz thay cho 21.4772700MHz của NTSC
- Chip S-CLK xử lý 6/5, rồi tiếp tục chia /4 để tạo dot clock 5.32034250MHz
- Nếu chỉ dùng đồ họa 224 dòng thì sẽ xuất hiện các dải đen lớn ở trên và dưới vùng hiển thị
- Để giảm vấn đề này, có chế độ overscan tăng số dòng hiển thị lên 240
- 16 dòng bổ sung tương ứng với chiều cao của một tile
- Trên thực tế, đa số tựa game được làm cho 224 dòng nên gần như không dùng chế độ này
- Chỉ có tổng cộng 12 tựa game sử dụng
- Super Mario World xử lý khác bằng cách tăng phạm vi quan sát theo chiều dọc trên PAL
- Cả NTSC và PAL đều dùng tỷ lệ 4:3, nên hình PAL bị nén theo chiều dọc hơn một chút so với NTSC
- Nhiều mã game không tính đến việc VSYNC chạy ở 50.00697891Hz thay vì 60.098Hz, nên kết quả là game chạy chậm hơn dự kiến 17%
Tín hiệu đầu ra và đầu nối AV
- Các tín hiệu RGB và đồng bộ ở trên là tín hiệu thuần có thể điều khiển CRT trực tiếp, nhưng phần lớn TV thực tế không thể nhận trực tiếp các tín hiệu đó
- Nhiều TV chỉ có đầu vào composite màu vàng ở phía sau, và một số mẫu cao cấp có đầu vào S-Video
- SNES chuyển đổi tín hiệu dành cho CRT sang cả composite lẫn S-Video
- Đầu nối AV không loại bỏ tín hiệu mà cung cấp nhiều kiểu đầu ra khác nhau
- Red, Green, Blue
- C-Sync
- S-Video dựa trên Luminance và Chrominance
- Composite Video
- +5V DC
- Ground
- Left Audio, Right Audio
- TV châu Âu, đặc biệt là TV Pháp, thường có đầu nối SCART, và kiểu này cho phép làm cáp đưa tín hiệu gần trực tiếp hơn vào CRT
- Kết quả là người dùng châu Âu có thể chơi game chậm hơn 17% và có dải đen, nhưng với độ trung thực hình ảnh cao
1 bình luận
Các ý kiến trên Hacker News
224 rất có thể không phải là một con số được chọn ngẫu nhiên. Nó chia hết cho 16 (224/16=14), nên rất khớp với tilemap trong pipeline render đồ họa
Hồi nhỏ, khi mày mò đủ thứ để học lập trình game, phải rất lâu sau tôi mới hiểu ra điều này, và lúc đó nó thật sự rất hợp lý. CGA/EGA/VGA thường có chế độ 320x200, còn NES và SNES là 256x224, về cơ bản gần như là do ràng buộc của TV
Trong khi đó, Pac-Man arcade lại là 288x224, nên các bản clone Pac-Man trên PC không bao giờ trông “đúng” được, và ngay cả bản Pac-Man cho NES do Namco làm cũng không khớp. Vì phải thỏa hiệp kiểu làm tile của bản đồ nhỏ lại khiến nhân vật trông khổng lồ, biến thành thế giới cuộn như bản Game Boy/Tengen, hoặc dùng bản đồ méo mó/không nguyên gốc, nên khi muốn chơi game “arcade” ở nhà thì cảm giác rất kỳ và bức bối
Sau khi học về cấu trúc máy và cách sprite hoạt động, tôi đi đến kết luận rằng rốt cuộc chẳng có lựa chọn nào khác, và đó là một khoảnh khắc vỡ lẽ lớn. Nếu tính cả việc pixel ở độ phân giải đó trên PC không phải là hình vuông thì mọi chuyện còn phức tạp hơn
Từ đó về sau, mỗi khi nhìn thấy một bản port hay clone Pac-Man, tôi lập tức xem xét kích thước thế giới, kích thước tile và kích thước sprite
Tuy nhiên mức overscan này khác nhau tùy TV, còn TV hiện đại hoặc emulator thường hiển thị toàn bộ 240 dòng
Độ phân giải dọc của SNES có thể đặt là 224 dòng hoặc 240 dòng như trong bài viết. Hầu hết game dùng 224 dòng, vì thời gian vertical blanking dài hơn, tạo thêm thời gian để truyền đồ họa tới PPU
Bài viết của Rodrigo Copetti về kiến trúc SNES cũng đáng xem kèm: https://www.copetti.org/writings/consoles/super-nintendo/
Đúng là 59,94Hz là một con số kỳ lạ, nhưng theo tôi biết thì không có lưới điện 30Hz nào cả. Bắc Mỹ và một số khu vực nơi NTSC được thiết kế dùng lưới điện 60Hz
https://en.wikipedia.org/wiki/Mains_electricity_by_country
Tần số cao nhất được tạo ra trong TV đen trắng là tần số quét ngang, vốn là bội số của frame rate. Khi tín hiệu màu NTSC dùng sóng mang 3,579545MHz được thêm vào, tần số cao nhất bên trong TV tăng lên nhiều, và để giữ phần cứng đơn giản, các tần số thấp hơn vẫn được chỉnh sao cho là ước của tần số cao nhất đó, tức sóng mang màu. Kết quả là frame rate trở thành 59,94 trường mỗi giây
Phần nói rằng ở khu vực PAL, trò chơi không được chỉnh cho khớp với VSYNC 50.00697891Hz nên chạy chậm hơn 17% so với chuẩn 60.098Hz thật sự rất thấm
Đây không phải chuyện riêng của Super Nintendo, nhưng nó làm tôi nhớ lần đầu thấy hoặc chơi Sonic the Hedgehog trên Mega Drive (Genesis). Tôi thấy nó ì và chậm hơn bản Master System nên không ấn tượng lắm; mãi sau khi YouTube nổi lên tôi mới biết chênh lệch tốc độ giữa NTSC và PAL là rất lớn. Không chỉ tốc độ game, mà nhạc trên PAL cũng nghe kinh khủng
Thời 16-bit tôi cũng biết về PAL và nhu cầu dùng “hộp đen”, nhưng không biết khác biệt lại lớn đến vậy. Tôi nhớ hồi đó hầu hết tạp chí console đều nói khác biệt trong đa số game là nhỏ; ngoại lệ là bản DooM trên SNES có khung hình bản NTSC lớn hơn
Hồi nhỏ tôi chơi Punch-Out bản NES khá giỏi, có thể hạ Mr. Dream hoặc Mike Tyson ngay vòng 1, nhưng giờ nghĩ lại thì tôi đã chơi bản PAL. Nếu tham gia giải ở Mỹ chắc tôi đã bị nghiền nát ngay vòng 1, và hẳn sẽ tin chắc rằng ai đó đã gài bẫy mình
Ví dụ, ở frame rate thấp hơn, Samus và đạn di chuyển nhiều pixel hơn trong một frame nên dễ xuyên qua vật thể hơn; glitch cổng này chỉ thực hiện được trên PAL: https://www.youtube.com/watch?v=RvyIwtO_qgM
Các hằng số vật lý và timing animation của Samus đã được chỉnh theo frame rate mới, nhưng kẻ địch, cutscene và các yếu tố môi trường khác thì không. Vì vậy trên PAL, Samus di chuyển cùng tốc độ như NTSC, còn phần còn lại của thế giới thì chậm hơn. Nhờ đó có thể nhặt Bombs rồi rời khỏi phòng ngay trước khi cửa khóa để bỏ qua miniboss: https://www.youtube.com/watch?v=R3t8TIIj7IM
Trên bản NTSC, cùng cú skip đó cần chuẩn bị phức tạp và hàng chục input liên tiếp chính xác theo từng frame; đến nay mới chỉ có một người làm được: https://www.youtube.com/watch?v=jcKUMk5g8Wk
Cũng có video so sánh speedrun có hỗ trợ công cụ ngắn nhất giữa NTSC (trái) và PAL (phải): https://www.youtube.com/watch?v=KD_-thqcB5s Hai lượt chạy dùng cùng lộ trình gần như đến cuối, và bản NTSC nhanh hơn ở hầu hết mọi phòng, nhưng phần chuẩn bị thực thi mã tùy ý lại hoàn toàn khác, nên cuối cùng PAL kết thúc trước. Lượt NTSC phải thực hiện một chuỗi tạm dừng/bỏ tạm dừng rất chậm để đi xuyên qua cửa mà không kích hoạt cửa, ra ngoài ranh giới và gây hỏng bộ nhớ. Trong khi đó, bản PAL có thể đạt thực thi mã tùy ý hoàn toàn trong màn hình bằng cách khai thác một race condition trong hệ thống animation của game. Đó là cuộc đua giữa bộ đếm thời gian knockback của gai và animation tiếp đất của Samus; chỉ timing của Samus được chỉnh cho PAL còn gai thì không, nên trên PAL xuất hiện timing chỉ có thể khai thác trong ngữ cảnh này
Khi Dreamcast ra mắt, lần đầu tiên có những game cho phép chuyển giữa 50Hz và 60Hz miễn là TV hỗ trợ. Ngoài ra, với những game không phản ánh đúng khác biệt này, có thể quay về 50Hz để khiến game dễ hơn; tôi nhớ Crazy Taxi dễ hơn nhiều ở 50Hz
Việc những game khác nhau đến thế lại được bán nguyên như vậy nghe có vẻ kỳ lạ, nhưng tôi hoàn toàn hiểu vì sao lựa chọn đó được đưa ra. Hồi nhỏ tôi mặc nhiên nghĩ Mario ở đâu cũng là Mario, Sonic ở đâu cũng là Sonic
Tôi tự hỏi liệu những khác biệt như vậy có chấm dứt vào thời console 3D không. Từ lúc đó, rendering và logic game phần lớn không còn bị buộc chặt hoàn toàn với nhau nữa
Có vẻ bản gốc có lỗi đánh máy. Họ nói tỉ lệ khung hình là 8:6, nhưng như vậy giống 4:3, còn theo tính toán thì 8:7 mới đúng
Có vẻ phần 256x224, tức độ phân giải đầu ra 8:7, bị kéo giãn thành khoảng 4:3, chính xác là ảnh 64:49, đã bị bỏ qua
Tốc độ dot của SNES khoảng 5.37MHz, chậm hơn tốc độ pixel vuông khoảng 6.13MHz do chuẩn ATSC định nghĩa. Chính xác là chậm hơn 8/7, nên pixel bị kéo ngang 8/7, và độ phân giải 8:7 được kéo thành (8/7)(8/7)=64/49, gần với 64:48=4:3
Phép tính “để có tỉ lệ gần 4:3 thì cần 224(4/3)=298 dot nhìn thấy được” nếu tính yếu tố trên thì hệ số trở thành (4/3)/(8/7)=7/6. Khi đó cần 224*(7/6)=261.33... dot nhìn thấy được, gần hơn nhiều với con số 256 thực tế được chọn
Tôi dùng một hộp chuyển mạch nối vào đầu ra RF để luân phiên chọn giữa SNES và ăng-ten TV
Về sau khi trở thành kỹ sư video thì tôi có thể cười về chuyện đó, nhưng tôi mừng là hồi đó đứa trẻ là tôi không biết chất lượng hình ảnh ấy kinh khủng đến mức nào
Tỷ lệ khung hình artwork 8:7 cũng xuất hiện trong các bản port sang nền tảng khác của SFC/SNES như ROCKMANX3 / Mega Man X3
Các bản PSX/Saturn/PC giữ nguyên artwork gốc thay vì kéo giãn, và để khớp 8:7 vào 4:3 thì thêm khoảng trống dọc tùy theo màn chơi. Vì đã quen với bản gốc nên khi chơi khá khó chịu, và nhìn ảnh chụp màn hình bản Saturn có thể thấy mọi thứ trông hơi quá gầy: https://segaretro.org/Mega_Man_X3
Không biết Fabien mất bao lâu để viết những bài như thế này. Chi tiết thật sự rất nhiều và được sắp xếp gọn gàng
Không biết trong độ phân giải của SNES, bao nhiêu phần là cố định trong phần cứng console, và bao nhiêu là vùng mà cartridge có thể điều khiển
Ví dụ, nếu một cartridge có bộ đồng xử lý riêng nên không cần tải sprite, và cũng có xung nhịp onboard, thì về lý thuyết liệu nó có thể xuất ra hơn 256 pixel ngang trên mỗi dòng không?
Nếu có bộ đồng xử lý, nó có thể tự render khung hình rồi đặt vào vị trí bộ nhớ nơi tile của dòng tiếp theo sẽ được đọc. Có vẻ SuperFX đã làm gần như vậy
Nhưng rốt cuộc thứ thực sự vẽ pixel và xử lý số lượng màu, v.v. vẫn là PPU, nên cuối cùng vẫn bị ràng buộc bởi các giới hạn của PPU