Як такі пристрої, як Game Boy Advance, досягають частоти кадрів?

Я розробляв власний портативний ігровий пристрій на основі мікроконтролера AVR та невеликого OLED-дисплея.

Я почав з монохромного дисплея 128х64 пікселів і можу зручно звертатися до нього зі швидкістю понад 60 кадрів в секунду.

Нещодавно я переробив його, щоб використовувати OLED-RGB, 128x128 пікселів, не надто замислюючись, щоб знайти лише 4 FPS. Після деякої думки та ретельного рефакторингу я можу отримати це до ~ 12 кадрів в секунду, якщо мені не дуже важливо робити щось інше!

Моє запитання - як такий пристрій, як GBA (Game Boy Advance), досягнув частоти кадрів майже 60 кадрів в секунду? Я думав про те, щоб мати окремий «графічний процесор», але зрозумів, що все одно перебуваю у вузькому місці, передаючи дані дисплея на це.

Мені також було цікаво використовувати вестигіальний 8-бітний паралельний інтерфейс, який має більшість цих екранів, що може привести до 8-кратного прискорення, за винятком того, що сучасні MCU не мають апаратних паралельних інтерфейсів, як це робиться для послідовних і бітових- стукання, швидше за все, з'їсть велику швидкість.

Які ще існують варіанти?

В даний час я використовую ATmega1284P, підключений до SSD1306 OLED-контролеру через USART-SPI. Ось монохромний варіант.

Кольоровий екран був SSD1351, спочатку не підключений до апаратного SPI. Я не був переконаний, що це матиме достатньо значення, загалом це занадто повільно

Я знаю, що можу отримати швидші MCU, але я хочу знати, які ще варіанти я міг би вивчити - процесор GBA набагато повільніше, ніж мій 1284!

Інші відповіді досить добре висвітлюють ваше запитання на абстрактному рівні (апаратне забезпечення), але, маючи фактичний досвід роботи з GBA, зокрема, я подумав, що більш детальне пояснення може бути вартим.

У GBA було багато режимів малювання та налаштувань, які можна було використовувати для управління тим, як графічний процесор інтерпретував відео оперативну пам'ять, але одне було неможливе: частота кадрів. Графічний процесор малював на екрані майже (докладніше про це нижче) постійний цикл. (Це, мабуть, найбільш релевантний біт для вашого питання.)

Він намалював би одну лінію за один раз, зробивши дуже коротку перерву між кожним. Після нанесення останнього рядка для кадру знадобиться перерва, приблизно приблизно дорівнює часу, щоб провести 30 ліній. Потім почніть знову. Час кожного рядка та час кожного кадру були заздалегідь визначені та встановлені в камені. Багато в чому графічний процесор справді був господарем цієї системи, і вам потрібно було писати свої ігри навколо його поведінки, тому що він буде продовжувати робити те, що робив, чи ви готові чи ні.

Приблизно 75-80% часу активно натискали на екран. Яку частоту кадрів ви могли б досягти, якби ви робили те саме?

Ці 80% часу були також те, що процесор повинен був обробляти введення користувача, обчислювати стан гри та завантажувати спрайти / плитки в області VRAM, які наразі були поза екраном (або, принаймні, не включені до поточного рядка, що малюється).

20% між кадрами - це все, що процесор повинен був налаштувати параметри відео чи оперативної пам’яті, що вплине на весь наступний кадр.

Наприкінці кожного рядка графічний процесор надсилатиме переривання синхронізації рядків до процесора. Це переривання може бути використане для налаштування параметрів на декількох спрайтах або декількох фонових шарах (саме так ви можете отримати ефект, подібний конічному прожектору, змінивши розмір і розташування однієї з прямокутних масок між кожним намальованим рядком. що стосується обладнання, всі ці регіони є прямокутними.). Ви повинні бути обережними, щоб ці оновлення були невеликими і закінчилися, перш ніж графічний процесор почне малювати наступний рядок, або ви зможете отримати негарні результати. Будь-який час, витрачений на обробку цих переривань, також скоротив 80% процесорного часу ...

Для ігор, які отримали максимум використання цієї системи, ні процесор, ні графічний процесор ніколи не брали справжньої перерви; кожен переслідував іншого навколо циклу, оновлюючи те, на що не дивився інший.

Ключовою особливістю всіх ігрових консолей, що відрізняли їх від ранніх ПК та практично всіх домашніх комп'ютерів (1), були апаратні спрайти .

Пов'язаний посібник з програмування GBA показує, як вони працюють з точки зору основного процесора. Растрові карти, що представляють гравця, фону, ворогів тощо, завантажуються в одну область пам'яті. Ще одна область пам’яті вказує розташування спрайтів. Тому замість того, щоб перезаписувати весь відео оперативну пам’ять кожного кадру, який вимагає безлічі вказівок, процесору просто необхідно оновити розташування спрайтів.

Потім відеопроцесор може працювати піксель за пікселем, щоб визначити, який спрайт малювати в цій точці.

Однак для цього потрібна оперативна пам’ять з двома портами, яка поділяється між двома, і я думаю, що в GBA відеопроцесор знаходиться на тому ж мікросхемі, що і основний процесор ARM та вторинний процесор Z80.

(1) Помітний виняток: Аміга

"Моє запитання - як пристрій на зразок GBA досягнув частоти кадрів майже 60 кадрів в секунду?"

Щоб відповісти лише на запитання, вони зробили це з графічним процесором. Я впевнений, що Game Boy використовував графіку спрайту. На найвищому рівні це означає, що графічний процесор завантажує такі речі, як зображення фону, зображення Маріо та зображення принцеси Персик тощо. Тоді головний процесор видає команди типу "показати зміщення фону цим багато в x і y, накладення зображення Маріо №3 в цьому положенні x, y "і т. д. Отже, головний процесор абсолютно позитивно не стосується малювання кожного пікселя, а графічний процесор абсолютно позитивно не пов'язаний з обчисленням стану гра. Кожен оптимізований для того, що йому потрібно робити, а результат - досить гарна відеоігра, не використовуючи велику обчислювальну потужність.

У GBA був досить повільний процесор. ARM7 дуже приємний; вони просто повільно бігали і давали поруч без жодних ресурсів.

Є причина, чому багато ігор Nintendo в той момент і раніше були бічними прокрутками. ТЕХНІКА Це все робиться апаратно. У вас було кілька шарів плиток плюс один або кілька спрайтів, і апаратне забезпечення робило всю роботу, щоб витягти пікселі з цих таблиць і керувати дисплеєм.

Ви будуєте плитку, встановлену спереду, а потім мали невелику пам’ять, яка була плитковою картою. Хочете, щоб нижня ліва плитка була плиткою 7? Ви ставите 7 у цьому місці пам'яті. Хочете, щоб наступна плитка була плиткою 19? У наборі плиток ви помістите туди 19 і так далі для кожного увімкненого шару. Для спрайту ви просто встановите адресу x / y. Ви також можете зробити масштабування та обертання, встановивши деякі регістри, а апаратне забезпечення піклується про інше.

Режим 7, якщо я добре пам’ятаю, був піксельним режимом, але це було схоже на традиційну відеокартку, де ви вкладаєте байти в ці кольори для пікселя, а апаратне забезпечення дбає про оновлення відео. Я думаю, ти міг би пінг-понг або принаймні, коли у тебе був новий кадр, ти можеш їх перевернути, але я не пам'ятаю правильно. Знову ж таки, процесор був досить розбитим на той день і вік і не мав занадто багато швидких ресурсів. Тому, хоча деякі ігри були в режимі 7, багато було бічних скролерів на основі плитки ...

Якщо ви хочете вирішити високу частоту кадрів, вам потрібно розробити це рішення. Ви не можете просто взяти будь-який старий дисплей, який ви знайдете, і поговорити з ним через SPI або I²C чи щось подібне. Покладіть принаймні один фреймбуфер перед ним, в ідеалі два, і по можливості керуйте рядками та стовпцями над цим екраном.

На ряді дисплеїв, на які я підозрюю, що купуєте, є на них контролер, з яким ви насправді спілкуєтесь. Якщо ви бажаєте виконати тип GBA / консолі, ви створите / реалізуєте контролер. Або ви купуєте / будуєте за допомогою GPU / відеочипа / логічного блоку та використовуєте HDMI або інший загальний інтерфейс у моніторі запасів.

Тільки тому, що на велосипеді є шини, а ланцюг і передачі не означає, що він може їхати так швидко, як мотоцикл. Вам потрібно розробити систему, щоб відповідати вашим потребам в продуктивності, від кінця до кінця. Ви можете поставити це велосипедне колесо на цей мотоцикл, але воно не буде працювати як слід; всі компоненти повинні бути частиною загальної конструкції.

Астероїди теж працювали таким чином; знадобилося лише одне 6502. Векторна графіка робилася з окремою логікою; 6502 надіслав крихітний рядок даних на контролер векторної графіки, який використовував ПЗУ, і ці дані для того, щоб зробити графік xy променя та z, вмикати / вимикати ... Деякі резервні пристрої мали окремі процесори для обробки аудіо та відео окремо від процесор, що обчислює гру. Звичайно сьогодні відео опрацьовує кілька сотень, якщо не тисячі процесорів, відокремлених від основного процесора ...

як пристрій на зразок GBA досягнув частоти кадрів майже 60 кадрів в секунду?

Обладнання

У нього є графічна пам'ять, яка може або не може використовувати таку ж шину, що і пам'ять програми / даних ... Але важливим бітом є те, що у неї є графічний процесор, який зчитує пам'ять 60 разів в секунду і передає дані на РК за допомогою оптимізований інтерфейс, який призначений зробити це ефективно.

Можна зробити те ж саме з будь-яким сучасним мікроконтролером, оснащеним периферійними пристроями "РК-інтерфейс", наприклад, LPC4330, хоча це може бути надмірним. Звичайно, вам знадобиться сумісна РК-панель.

З сучасними швидкими мікроконтролерами (тобто ARM не AVR) та таким крихітним екраном вам, напевно, не знадобляться спрайти або блистер для прискорення графічних операцій. З 8-бітовим AVR це може бути повільним.

Але незалежно від процесора, трохи бити інтерфейс на дисплей буде смоктати.

Я вважаю, що Atari 2600 використовував розрядний процесор для надсилання зображення на телевізор. Це трохи застаріло.