заголовок Wav ;)

Всмысле слить в одну статью? Ну я начинал делать на жж где есть ограничение на размер поста и мне кажется тут оно тоже должно быть.

может я невнимателен, но — почему просто не отрезать заголовок вавки и потом читать их в массив?

Тем не менее, если смотреть в доки от самого ARM, то там написано: infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/CACBCAAE.html
"...ideally suited to embedded applications with restricted memory bandwidth, where code density and footprint is important". Поэтому я нисколько не отклоняюсь от официальной точки зрения на вопрос. :)

Всё же термин «плотность кода» относится к размеру довольно крупных осмысленных фрагментов, а не размеру опкодов отдельных команд; первое со вторым необязательно сильно связано, и необязательно однозначно положительно во всех случаях. Thumb понадобился не для уменьшения статического размера кода (для чего эффективнее программные методы), а в основном, действительно, во избежание двукратной потери скорости на 16-битной шине, весьма распространённой в нише встроек и мобилок (особенно в те года). Вот для Thumb-2 уже соображения экономии размера кэша играли роль.

Божественная эстетика.

Проблема теста из этой главы в том, что он использует вещественное деление чтобы вычислить фпс, а это на данной платформе чрезмерно щедрый шаг, могущий это самое фпс уронить. Насколько — мне уже правда неинтересно, ибо 3Д на этой платформе был как раз ровно в той эпохе (по мощности аппаратуры) когда даже захудалое 2D уделывало даже крутое 3D по эстетике. А 2D здесь разумнее реализовывать через «аппаратно ускоренные» тайловые видеорежимы о которых следующая глава. На GBA реально были 3D-игры в пиксельных видеорежимах, но они были не очень в принципе все.

Ну естественно, вещественными лучше не пользоваться, они ж там программные. Не пойму, правда, какая связь sincos и заливки. Как пример, вот на что способен был ARM2 8мгц в двухмерных игрушках без какой-либо аппаратной помощи:
www.youtube.com/watch?v=t4hfPKWM4Mk

Doom в уменьшенном примерно до gba-шного размера окошке сносно шевелился на 386DX40. По моему опыту, уже самые первые армы примерно в 2+ раза эффективней по тактам были. Так что в «ужасном качестве» я склонен виноватить кривые ручки (программистов Дума, компилятора, или разработчиков железа геймбоя). В архимедовских демах, вон, даже воксельный ландшафт бодро бегал:
www.youtube.com/watch?v=bLdpCIfOqmw (с 17:50)

Когда я дошёл до вращающихся фонов и спрайтов, то обнаружил, что вычисление двух sincos не пролазит в стабильные 60 кадров в секунду. Вещественными лучше вообще не пользоваться и картинка должна несколько улучшится. Но в любом случае — например Doom на этой платформе шевелится еле-еле в ужасном качестве.

можем наглядно увидеть, что пиксельные видеорежимы 16-мегагерцовым ARM-ом GBA заливаются довольно медленно и их реальное применение в играх очень сильно ограничено

Что-то здесь не то. Такой арм, навскидку, должен в кадре успевать залить такой маленький экранчик несколько раз. А тут либо компилятор сосёт, либо дикие задержки доступа к видеопамяти. Во всяком случае, причина явно не в 16 мегагерцах.

Доку на SMD нагуглить очень легко, её ещё HWM переводил на русский лет 15 назад. Называется Genesis Technical Overview, в любительских кругах наиболее известна под названиями sega2.doc в оригинале и Sega Tech в переводе:

www.genny4ever.net/g4e_modules2/download.php?file=genesis_technical_overview
tv-games.narod.ru/hard/Sega_Tech_Rus_1_5b.rar

До кучи:

segaretro.org/Mega_Drive_official_documentation

Дока для SNES более редкая, долгое время её передавали из под полы, вероятно боясь гнева Nintendo. Состоит из двух книг, циркулирующих под названиями snes_book1.pdf и snes_book2.pdf. В одной описана сама SNES, в другой сопроцессоры:

archive.org/details/SNESDevManual

Касательно вхождения на рынок, ну, 99% всех европейских разработчиков не являлись разработчиками под игровые автоматы, да и вообще опытными разработчиками. В интернете множество интервью с ними, тем более сейчас, и узнать, как создавались игры, несложно. Не знаю, например самое известное:

games.greggman.com/game/programming_m_c__kids/
dutycyclegenerator.com/

А есть ссылки на офдоки от SMD и SNES? Вот реально гуглил много и часто, но не видел.
До сих пор грызёт любопытство как же в 80-х эти игры создавались, даже после прочтения пары статей на эту тему.
Такое ощущение, что шансы войти в этот рынок тогда не являясь разрабом под игровые автоматы был минимальным.

ничоси жесть

Спасибо за ссылку!

Официальные доки очень давно доступны как минимум для Atari 2600, Atari 7800, Sega Genesis, SNES, Neo-Geo.

P.S.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030

Тем не менее для демосцены он довольно любопытный зверь — тут вмешивается фактор портативности. т.к. он портативен и должен питаться от батареек, то серьёзно отстаёт своим нутром от своих лет. фактически он реально что-то типа i386 без сопроцессора и Doom в убогом разрешении еле шевелится. При этом пикантности добавляет то, что «давить соки» реально можно — разные виды памяти с разной шириной шины заставляют проворачивать такие трюки, как пропихивание быстро работающих куском ARM32-кода в 32-битное внутреннее ОЗУ и так далее — это довольно всё любопытно с точки зрения демосцены.
Например вот:

SMS мне понравилась тем, что в отличие от всех остальных 8/16-битных консолей можно нагуглить: официальную документацию от производителя (а не изучать только доки создателей эмуляторов). И что характерно — в документе, то есть как бы полном описании всего «API» консоли от ввода и графики до звука — всего 44 страницы из которых последние 14 — это приложения и примеры тестового кода. У DirectX под XBox One этого наверное и на оглавление то не хватит…

он 2001 года, а в плане фрога по очищению русской демосцены до 1991 года платформы

автор до сих пор выпускает новые версии (преимущественно не под вин, но последнюю версию под винду он специально компилировал для меня), посмотри плиз на этот счёт его страницу