И, похоже, это правильный ответ! :) www.zxdesign.info/harlequinDRAM.shtml
Почитал интернеты по этим ключевым словам и да — похоже это была главная причина.
Поясню для тех кому некогда читать это вкратце. Сперва напомню как работает DRAM — этот дешевый вариант памяти требует периодического обновления своего содержимого — во времена спектрума для этого некий внешний чип должен был инициировать чтение (или запись) памяти. Но не каждой ячейки, а каждой страницы памяти — память состояла из страниц довольно большого объёма. По факту при чтении байта из заданного адреса чип DRAM извлекал во временный буфер содержимое всей страницы памяти, брал из него нужный байт и перезаписывал/обновлял содержимое всей страницы. При этом важно заметить, что селектор страницы в микросхемах применяемых в памяти спектрума содержался в нижнем байте адреса, а селектор байта внутри страницы — в верхнем (даже в семи битах, но неважно).
Это и является ключём к режиму page mode — залочив память на чтение с адреса можно было получив результат не снимать лок, а требовать отдать еще один байт, при условии что он лежит внутри той же страницы памяти — пока она удерживалась во временном буфере можно было значительно сэкономить на операции чтения.
А далее — магия — организация видеопамяти спектрума такова, что у адресов битового паттерна знакоместа и его атрибута один и тот же нижний байт адреса!
Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на чтение двух разрозненных байт из памяти.
То, что раскладка получилась удобной для текстового вывода являлось логичным следствием этой оптимизации, но не причиной всего этого безобразия. Сама причина — скорость извлечения памяти. Спасибо за наводку!
Ну, имхо, дело не в самом редакторе бейсика, а в том, что вывод текста был обозначен как приматив.
А вывод текста в основном опирается на print_string и именно для print_string как раз легко делать и вывод одного символа и переход к следующему за ним символу. Я писал процедуры вывода текста на спектруме и нашёл, что и то и другое легко делать при данной раскладке видеопамяти. То что экран побит на трети замедляет переход к следующему символу крайне редко.
А по поводу (2) — я не понимаю чем оно вообще могло бы быть полезно.
Неужели не понравилась? Имхо, это лучшая игра от Telltale и одна из лучших в жанре сторителлинга как такового (ну понятно что это не игра в целом, а скорее интерактивный фильм). Как раз сюжет и юмор там — огонь!
Ну такое может дать сбой на том или ином файле/редакторе. Тот же Audacity старается вставить блок с информацией об исполнителе и т.п., оно либо встанет перед и исказит заголовок, либо после и исказит данные.
Ааа… У WAVE не заголовок — там RIFF-формат у которого замороченная древовидная структура может быть со всякими опциональными блоками типа названия авторов и тому подобное — сам код парсящий вынужден быть потому рекурсивным в обработке этих блоков.
Тем не менее, если смотреть в доки от самого 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". Поэтому я нисколько не отклоняюсь от официальной точки зрения на вопрос. :)
Проблема теста из этой главы в том, что он использует вещественное деление чтобы вычислить фпс, а это на данной платформе чрезмерно щедрый шаг, могущий это самое фпс уронить. Насколько — мне уже правда неинтересно, ибо 3Д на этой платформе был как раз ровно в той эпохе (по мощности аппаратуры) когда даже захудалое 2D уделывало даже крутое 3D по эстетике. А 2D здесь разумнее реализовывать через «аппаратно ускоренные» тайловые видеорежимы о которых следующая глава. На GBA реально были 3D-игры в пиксельных видеорежимах, но они были не очень в принципе все.
Когда я дошёл до вращающихся фонов и спрайтов, то обнаружил, что вычисление двух sincos не пролазит в стабильные 60 кадров в секунду. Вещественными лучше вообще не пользоваться и картинка должна несколько улучшится. Но в любом случае — например Doom на этой платформе шевелится еле-еле в ужасном качестве.
А есть ссылки на офдоки от SMD и SNES? Вот реально гуглил много и часто, но не видел.
До сих пор грызёт любопытство как же в 80-х эти игры создавались, даже после прочтения пары статей на эту тему.
Такое ощущение, что шансы войти в этот рынок тогда не являясь разрабом под игровые автоматы был минимальным.
P.S.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030
Тем не менее для демосцены он довольно любопытный зверь — тут вмешивается фактор портативности. т.к. он портативен и должен питаться от батареек, то серьёзно отстаёт своим нутром от своих лет. фактически он реально что-то типа i386 без сопроцессора и Doom в убогом разрешении еле шевелится. При этом пикантности добавляет то, что «давить соки» реально можно — разные виды памяти с разной шириной шины заставляют проворачивать такие трюки, как пропихивание быстро работающих куском ARM32-кода в 32-битное внутреннее ОЗУ и так далее — это довольно всё любопытно с точки зрения демосцены.
Например вот:
SMS мне понравилась тем, что в отличие от всех остальных 8/16-битных консолей можно нагуглить: официальную документацию от производителя (а не изучать только доки создателей эмуляторов). И что характерно — в документе, то есть как бы полном описании всего «API» консоли от ввода и графики до звука — всего 44 страницы из которых последние 14 — это приложения и примеры тестового кода. У DirectX под XBox One этого наверное и на оглавление то не хватит…
Ну вот я в своё время искал как раз про это — мне не понравилось. :) Сложение 16-битных обязательно через CLC/ADC/ADC (8-битные), при том что расположение аргументов выше zero-page — нехорошо раздувает код (как всегда, впрочем), копирование произвольного региона памяти в два 8-битных цикла через медленную на этой платформе косвенную индексацию (поэтому если адреса регионов заранее известны или менее 256 байт, то нужно оптимайзить). Вкусовщина или нет, но на меня такое навевает уныние.
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.
6502 намного ближе к «бессистемному» программированию 60-х, когда всякие абстракции типа структурного программирования только формировались и завоёвывали. стек крохотен и рудиментарен. второй аргумент операции почти всегда берется из памяти и там нельзя боятся лазить в память и сохранять в неё промежуточные результаты, экономя на перекладывании в регистры (их там почти нет просто) — напротив хранить всё в памяти и сохранять сразу после выполнения операции — норма жизни. 256 байт нулевой страницы это эдакая область глобальных переменных быстрого доступа — так как почти все регистры 8-битные, то даже косвенная адресация любого байта в памяти делается через слово лежащее в нулевой странице. к нулевой странице поэтому особое отношение.
Ну во первых я далеко не только чтец, а во вторых разговор уже приобретает черты холивара и я не хочу в этом учавствовать. :)
Но не ради холивара, а ради прикосновения к красивому — в комментариях к этой же статье моей на другом ресурсе проскочила демка на SMD:
от прошлого года и в титрах авторы явно подзадоривают к «proper SNES competition» :)
там же привели и пару демок от SNES, но они страдали в сравнении как раз низкой цветностью слоёв с динамическим рендером — и я склонен считать что это из-за многократно уже оговоренных проблем с раскладками памяти и прочим.
Еще раз повторюсь — не холивара ради, но было бы интересно посмотреть бест оф зе бест.
P.P.S.
Посмотрел сейчас еще в тайлы угловых стен — да, они не перерисовываются динамически, а построены заранее.
Есть два одинаковых набора — в одном два разных цвета (внутренние стены), в другом один из цветов прозрачный (внешние стены). В каждом изображены линии под разными углами — судя по всему растиражированы почти все возможные углы от 0 до 45 градусов, а дальнейшее получается зеркалированием по горизонтали/вертикали. С другой стороны, если приглядываться к итоговой картинке, то нередко заметно, что линия не является идеальных Брезенхемом, нередко видны «шероховатости» видимо на стыках, то есть прямо все возможные пиксельные комбинации возможно даже не покрыты для краткости. Общий паттерн же таков, что берется пиксель вдоль одной стороны и из него проводится линия ко всем пикселям на противоположных сторонах. Есть еще подозрение, что с помощью палитр еще сокращается число нужных комбинаций. Но так да — с ходу трудно придумать как этим теперь рисовать, такую задачу мне тоже еще не доводилось решать.
«На практике и там и там одинаково сложно сделать игру типа GH»
Имхо, напротив, ожидаю увидеть на SNES всякие трюки с переходом к 8.8 как в статье и всякие таблицы с xor-ами для выдавливания соков из-за дурацких раскладок против абсолютно прямолинейного ремесленного кода на SMD в 16 РОН и адресацией любого куска памяти через base+size*offset. То что внешне можно добиться схожей картинки как раз не показатель. Но тут смысла нет препираться особо пока не будет реальных сравнительных опенсорцных тестов это всё «личные мнения».
Почитал интернеты по этим ключевым словам и да — похоже это была главная причина.
Поясню для тех кому некогда читать это вкратце. Сперва напомню как работает DRAM — этот дешевый вариант памяти требует периодического обновления своего содержимого — во времена спектрума для этого некий внешний чип должен был инициировать чтение (или запись) памяти. Но не каждой ячейки, а каждой страницы памяти — память состояла из страниц довольно большого объёма. По факту при чтении байта из заданного адреса чип DRAM извлекал во временный буфер содержимое всей страницы памяти, брал из него нужный байт и перезаписывал/обновлял содержимое всей страницы. При этом важно заметить, что селектор страницы в микросхемах применяемых в памяти спектрума содержался в нижнем байте адреса, а селектор байта внутри страницы — в верхнем (даже в семи битах, но неважно).
Это и является ключём к режиму page mode — залочив память на чтение с адреса можно было получив результат не снимать лок, а требовать отдать еще один байт, при условии что он лежит внутри той же страницы памяти — пока она удерживалась во временном буфере можно было значительно сэкономить на операции чтения.
А далее — магия — организация видеопамяти спектрума такова, что у адресов битового паттерна знакоместа и его атрибута один и тот же нижний байт адреса!
Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на чтение двух разрозненных байт из памяти.
То, что раскладка получилась удобной для текстового вывода являлось логичным следствием этой оптимизации, но не причиной всего этого безобразия. Сама причина — скорость извлечения памяти. Спасибо за наводку!
А вывод текста в основном опирается на print_string и именно для print_string как раз легко делать и вывод одного символа и переход к следующему за ним символу. Я писал процедуры вывода текста на спектруме и нашёл, что и то и другое легко делать при данной раскладке видеопамяти. То что экран побит на трети замедляет переход к следующему символу крайне редко.
А по поводу (2) — я не понимаю чем оно вообще могло бы быть полезно.
"...ideally suited to embedded applications with restricted memory bandwidth, where code density and footprint is important". Поэтому я нисколько не отклоняюсь от официальной точки зрения на вопрос. :)
До сих пор грызёт любопытство как же в 80-х эти игры создавались, даже после прочтения пары статей на эту тему.
Такое ощущение, что шансы войти в этот рынок тогда не являясь разрабом под игровые автоматы был минимальным.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030
Например вот:
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.
Но не ради холивара, а ради прикосновения к красивому — в комментариях к этой же статье моей на другом ресурсе проскочила демка на SMD:
от прошлого года и в титрах авторы явно подзадоривают к «proper SNES competition» :)
там же привели и пару демок от SNES, но они страдали в сравнении как раз низкой цветностью слоёв с динамическим рендером — и я склонен считать что это из-за многократно уже оговоренных проблем с раскладками памяти и прочим.
Еще раз повторюсь — не холивара ради, но было бы интересно посмотреть бест оф зе бест.
Посмотрел сейчас еще в тайлы угловых стен — да, они не перерисовываются динамически, а построены заранее.
Есть два одинаковых набора — в одном два разных цвета (внутренние стены), в другом один из цветов прозрачный (внешние стены). В каждом изображены линии под разными углами — судя по всему растиражированы почти все возможные углы от 0 до 45 градусов, а дальнейшее получается зеркалированием по горизонтали/вертикали. С другой стороны, если приглядываться к итоговой картинке, то нередко заметно, что линия не является идеальных Брезенхемом, нередко видны «шероховатости» видимо на стыках, то есть прямо все возможные пиксельные комбинации возможно даже не покрыты для краткости. Общий паттерн же таков, что берется пиксель вдоль одной стороны и из него проводится линия ко всем пикселям на противоположных сторонах. Есть еще подозрение, что с помощью палитр еще сокращается число нужных комбинаций. Но так да — с ходу трудно придумать как этим теперь рисовать, такую задачу мне тоже еще не доводилось решать.
Имхо, напротив, ожидаю увидеть на SNES всякие трюки с переходом к 8.8 как в статье и всякие таблицы с xor-ами для выдавливания соков из-за дурацких раскладок против абсолютно прямолинейного ремесленного кода на SMD в 16 РОН и адресацией любого куска памяти через base+size*offset. То что внешне можно добиться схожей картинки как раз не показатель. Но тут смысла нет препираться особо пока не будет реальных сравнительных опенсорцных тестов это всё «личные мнения».