• avatar Shiru
  • 1
Официальные доки очень давно доступны как минимум для Atari 2600, Atari 7800, Sega Genesis, SNES, Neo-Geo.
  • avatar aa-dav
  • 1
P.S.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030
  • avatar aa-dav
  • 1
Тем не менее для демосцены он довольно любопытный зверь — тут вмешивается фактор портативности. т.к. он портативен и должен питаться от батареек, то серьёзно отстаёт своим нутром от своих лет. фактически он реально что-то типа i386 без сопроцессора и Doom в убогом разрешении еле шевелится. При этом пикантности добавляет то, что «давить соки» реально можно — разные виды памяти с разной шириной шины заставляют проворачивать такие трюки, как пропихивание быстро работающих куском ARM32-кода в 32-битное внутреннее ОЗУ и так далее — это довольно всё любопытно с точки зрения демосцены.
Например вот:

  • avatar aa-dav
  • 2
SMS мне понравилась тем, что в отличие от всех остальных 8/16-битных консолей можно нагуглить: официальную документацию от производителя (а не изучать только доки создателей эмуляторов). И что характерно — в документе, то есть как бы полном описании всего «API» консоли от ввода и графики до звука — всего 44 страницы из которых последние 14 — это приложения и примеры тестового кода. У DirectX под XBox One этого наверное и на оглавление то не хватит…
он 2001 года, а в плане фрога по очищению русской демосцены до 1991 года платформы
  • avatar VBI
  • 2
автор до сих пор выпускает новые версии (преимущественно не под вин, но последнюю версию под винду он специально компилировал для меня), посмотри плиз на этот счёт его страницу
  • avatar Shiru
  • 2
Рекомендую также обратить внимание на Sega Game Gear. Это почти то же самое, но ещё плюс сотня-другая игр. Только придётся заморочиться с расширением отображаемой части уровня, но это многократно делалось любителями, они нередко адаптировали игры, в обе стороны.

WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).
  • avatar sq
  • 0
Прикольно!

Кажется, у нас новая платформа-кандидат на победу в ZX Spectrum 640k demo compo 2019!
  • avatar VBI
  • 0
нашёл видео за эту систему:
  • avatar Shiru
  • 2
Меня никогда не интересовало программирование само по себе — красота кода и прочие подобные штуки. Программирование для меня всегда остаётся просто необходимым инструментом — хочу делать игры, значит надо писать код. Вероятно поэтому разные процессоры не доставляют мне особых проблем, и я не заморачиваюсь размышлениями, где что лучше и где проще-сложнее, просто пишу на том, что есть. Сложность кода вообще штука такая — если для решения задачи нужен какой-то трюк (чтение стеком на Z80 или 16-битное сравнение со знаком на 6502), это не сложность и не неудобство, это один раз научился и дальше применяешь по необходимости, а то и просто заворачиваешь в макрос и забываешь. Сложность кода начинается скорее на алгоритмическом уровне, а на уровне реализации алгоритма на ассемблере это одинаково не сложно и не просто, это просто есть как есть.

Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.

Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):

Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):
ld sp,#5b00		;10
 ld hl,#0000		;10
repeat 3456
 push hl		;11*3456
endrepeat

=38036t (92 lps), 3462b

lda #0			;2
repeat 6912,N
 sta $4000+N		;4*6912
endrepeat

=27650t (63 lps), 20738b

Разница в скорости на треть. В размере очень большая, что ожидаемо — код на 6502 всегда заметно многословнее.

Зарисовка:
ld sp,#5b00		;10
repeat 3456
 ld bc,NNNN		;10*3456
 push hl		;11*3456
edup

=72586t (48 lps), 13827b

repeat 6912,N
 lda #NN		;2*6912
 sta $4000+N		;4*6912
endrepeat

=41472t (42 lps), 34560b

А вот в копировании разница уже не такая большая, всего 6 условных единиц.

Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.
Я не помню каких-то особых сложностей с 6502. Запомнились только программные проверки на коллизии из-за того что экран по горизонтали больше чем 256 и Х координата не влезвет в 8-бит :) Да и то нашёл решение в инете, самому лень было писать
  • avatar aa-dav
  • 0
Ну вот я в своё время искал как раз про это — мне не понравилось. :) Сложение 16-битных обязательно через CLC/ADC/ADC (8-битные), при том что расположение аргументов выше zero-page — нехорошо раздувает код (как всегда, впрочем), копирование произвольного региона памяти в два 8-битных цикла через медленную на этой платформе косвенную индексацию (поэтому если адреса регионов заранее известны или менее 256 байт, то нужно оптимайзить). Вкусовщина или нет, но на меня такое навевает уныние.
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.
Да просто начни делать :) Я когда писал Alter Ego под комод через какое-то время просто грохнул исходник и со второго раза сделал так что заработало. Но тот первый раз вот и был поиском решений стандартных для игры задач. А в целом всё как aa-dev описал выше. Я использовал kickass IDE, там сразу и бэйсик стартер есть, редактор спрайтов, тайлов и.т.п. Один минус — большинство примеров под комод не под синтаксис kickasm, но это не особо страшно.

Жмах
Вот это в общих чертах я знаю и сам, а интересует меня всё же конкретика, типовые для данного процессора эффективные решения стандартных задач.
  • avatar aa-dav
  • 1
6502 намного ближе к «бессистемному» программированию 60-х, когда всякие абстракции типа структурного программирования только формировались и завоёвывали. стек крохотен и рудиментарен. второй аргумент операции почти всегда берется из памяти и там нельзя боятся лазить в память и сохранять в неё промежуточные результаты, экономя на перекладывании в регистры (их там почти нет просто) — напротив хранить всё в памяти и сохранять сразу после выполнения операции — норма жизни. 256 байт нулевой страницы это эдакая область глобальных переменных быстрого доступа — так как почти все регистры 8-битные, то даже косвенная адресация любого байта в памяти делается через слово лежащее в нулевой странице. к нулевой странице поэтому особое отношение.
Ширу, мне было бы интересно подумать над z80/6502, в первую очередь чтобы врубиться в мышление 6502. Ты продумывал какие-то типовые задачи, которые раскрыли бы как первую, так и вторую платформу?
  • avatar tsl
  • 0
Посчитали:
Реги спрайтов: 4*32*20=2560 бит
Пикс. буфер: 9*320*2=5760 бит

Sergey, [26.09.18 10:40] А буфер строки можно на драме сделать

Помню, я смотрел видеощупом сигналы на видеопамяти (на обоих портах) и были они очень странные, логику я понять не смог.
  • avatar Shiru
  • 1
Про во-первых я отвечу так: комьюнити разработчиков на SMD и особенно на SNES крайне небольшие, там все всех знают много лет. ОК, закончим на этом.
  • avatar aa-dav
  • 1
Ну во первых я далеко не только чтец, а во вторых разговор уже приобретает черты холивара и я не хочу в этом учавствовать. :)
Но не ради холивара, а ради прикосновения к красивому — в комментариях к этой же статье моей на другом ресурсе проскочила демка на SMD:

от прошлого года и в титрах авторы явно подзадоривают к «proper SNES competition» :)
там же привели и пару демок от SNES, но они страдали в сравнении как раз низкой цветностью слоёв с динамическим рендером — и я склонен считать что это из-за многократно уже оговоренных проблем с раскладками памяти и прочим.
Еще раз повторюсь — не холивара ради, но было бы интересно посмотреть бест оф зе бест.
  • avatar Shiru
  • 2
Я предполагаю, что теоретически для фиксированной проекции каждой конкретной точке экрана должен однозначно соответствовать конкретный статичный вектор. Т.е. если мы смотрим на точки ближе к центру, там линия стены идёт под острым углом к зрителю, а у точек ближе к углам экрана линия идёт в направлении угла. Значит по экранным координатам угловой точки всех восьми вариантов углов стен нижнего слоя можно однозначно определить, какую линию надо нарисовать.

Можно заготовить карты тайлов с заранее нарисованными фиксированным набором графики всеми возможными углами, размером типа 4x4 тайла для четверти всех возможных случаев (т.к. три четверти экрана можно отзеркалить), и каждый кадр дорисовывать в карту тайлов каждый угол. Т.е. нужен массив размером в четверть экрана с индексами нужных тайлов (8 бит), это будет порядка 128*112=14 килобайт, плюс набор карт тайлов углов (256 карт 4x4 займёт 4К, 256 углов определённо должно хватить) — по меркам платформы это совсем немного для такого киллер-эффекта.

В общем, идеи есть, и наверное мой вариант сработает и будет достаточно быстрым, но я не уверен, что в Red Zone сделано именно так. Это такой эффект, где надо поэкспериментировать и предусмотреть много разных мелочей. Его реализация не читается однозначно по визуальному анализу, в отличие от большинства приставочных эффектов.