рендер битмапа+DMA для переброски. Наверное так.

Это относительно известный хак. Проблема одновременного доступа к тайлам решается в лоб — использованием двухпортовой памяти, т.е. памяти, которая даёт два полноценных канала для доступа к её содержимому, не мешающих друг другу. В староглиняные времена это было непозволительной роскошью, а сейчас вполне доступно.

Не знал, спасибо! Оказывается, на NGS есть DMA доступ.

Ну понятно же, что любители запрещать использование технологий XXI века сами себе ни в чём отказать не могут :)

я не согласен с таким термином.
А по сути это недо-GBC.

Да нечего там особо переосмысливать — это немного расширенный 8080 с аппаратными глюками. Там даже банальный инкремент регистровых пар надо использовать с осторожностью, т.к. он может приводить к порче списка спрайтов при определённых условиях. А 8080 по любому менее гибкий, чем Z80 — мало регистров, нет индексных.

А вот интересно — у Амстрада z80 работает по-другому. Это недо-z80?
у Mattel Aquarius нет прерываний IM2 — это недо-z80?
у 8080 похожий набор команд — что недо- тогда?
КР580ВМ80, копия 8080 — это недо 8080?
кстати, порча спрайтов при инкременте пар неясно чей глюк — процессора или конструкции?

привычка называть что-то «недо» — от «НедоПиСи».
традиция, пожалуй.

но явно не моя.

Z80 всё же всегда работает как Z80 соответствующей версии, а не по-другому.

Есть расхожее заблуждение, что процессор GB — урезанная версия Z80 или полноценный Z80; также местной аудитории легче ориентироваться относительно Z80; в формате новости лишний абзац с пояснением, что же там за процессор, не очень уместен. Поэтому вот так.

Я не согласен и всё потому, что мне интересно думать в терминах демокодинга.

Демокодинг на Z80 приучает к некотором стандартным общим образам мысли: «стеком быстрее», «перекладывать байты эффективнее, если задействовать ldi» — базовые эвристики выглядят примерно в этом духе. А на GBC команды чтения и записи байтов с автоинкрементом настолько эффективны, что всякие решения, обычно отметаемые на Z80 становятся снова актуальными. Нужно заново продумывать на уровне эвристик, даже базовые операции.

Разумеется, багов процессора это всё не касается…

у GBC есть свои особенности — запись в видеопамять недоступна напрямую, а после:

lcd_WaitVRAM: MACRO
        ld      a,[$FF41]       ; <---+
        and     2;STATF_BUSY      ;     |
        jr      nz,@-4          ; ----+
        ENDM

поэтому используется DMA. А если копнуть в демо, то найдутся и трюки со стеком и прочие.

introspec, мы недавно рассматривали в чате проц гб.
gb cpu, посмотри.
я лично восторгов при первом рассмотрении не нашёл. очень порезано. но есть милейший маппинг :)

Немного бестолковое руководство в том разрезе, о котором я говорил. Вот таблица с времянками команд.

Примеры интересных команд: мы привыкли, что ld a,(hl): ld (de),a: inc hl: inc de — слишком медленно, нужно либо делать ldi/ldd, либо, как минимум, пытаться экономить на инкрементах (всякие спрайты раскранченные чтобы ходить по ним inc h или inc l, рисование змейкой и т.д. и т.п.). А на GBC у нас есть ldi a,(hl) — за 8 тактов всего, с бесплатным инкрементом!!!

Или, мы привыкли что заливать стеком — эффективнее всего. push hl работает 11 тактов, т.е. заливает по 5.5 такта на байт. А на GBC push hl — это уже целых 16 тактов, считай что ldi (hl),a даёт тебе ту же скорость, что и стек.

Или, мы привыкли, что JR занимает меньше памяти, но работает чуть помедленнее чем JP (12 тактов против 10). Т.е. оптимизация по скорости — это почти всегда JP, оптимизация по памяти — почти всегда JR. А на GBC JR работает за те же 12 тактов, в то время как JP — целых 16!

Т.е. мораль такая: наши привычки с Z80 во-многом неприменимы более. Я могу себе представить заливку стеком на GBC, но моё ощущение сейчас такое, что опытный GBC кодер вряд ли будет делать это автоматически стеком, как мы привыкли у себя.

И ещё есть ощущение, что процессор у GBC более сбалансирован. Т.е. сам факт, что для пересылки команд поэффективнее всё же использовать команды для пересылки команд, или что локальные переходы пошустрее, он говорит о том, что кодирование не настолько через жопу, как у нас, где заливают стеком, ходят по экрану дикой комбинацией стека и ldi, и т.д. и т.п. Чисто на идеологическом уровне.

Вообще, существует мнение, что GB изначально делался под 6502. Остальное железо очень сильно похоже на NES. Кто-то из железячников где-то говорил, что внешняя шина у процессора GB по устройству близка или совпадает с 6502, а не 8080/Z80. Но в какой-то момент разработки процессор предположительно был заменён, по неизвестным соображениям. Возможно, у Sharp для была лицензия на 8080/Z80, но не было на 6502, или они решили применить свой уже существующий промышленный контроллер, который проще интегрировался с драйвером LCD.

Не знаю, исходя из опыта написания кода для 8080/Z80 и 6502/65816/SPC700, я ничего особенно интересного в системе команд не заметил, никакой особенной парадигмы. Может она и есть, но мне кажется, что итоговый дизайн скорее следствие спешки, чем продуманных решений.

Так ты отказался от затеи что-либо написать? Есть еще один нюанс: модификация кода не прокатит ибо ROM.

Я и не собирался писать для GBC. Мне на спектруме хватает проектов!

Мало нам, больше от тебя спектрума хотим! =)

такты посчитал и отказался от затеи?(:

Да не было никакой затеи. Прочёл что там не Z80, а что-то другое, похожее, залез и посмотрел что именно. Запомнил, было прикольно разобраться. Но это никакая не идея для проекта. Это просто общее образование.

Короче, не разобрался, не зная железа и возможностей.

Нет, просто ты и я понимаем под «затеей» (я бы сказал, под «проектом») совершенно разные вещи.

Для тебя, как я это понимаю, совладать с новой железкой — уже проект. А мне это не кажется интересным достижением. Мне нужно сказать что-то за пределами чисто технического результата. И у меня сейчас нет совершенно ничего такого, что я бы не мог сказать на спектруме, но смог бы на GBC. Поэтому осваивать GBC кажется мне глубоко бессмысленной затеей.

Нет, прсто интересно, чтобы вышло, если бы ты к gbc применил свой подход к созданию дем.

совладать — не проект. Скорее всего интерес к ретрокомпам. Сделать что-то посерьезнее «Hello.world!» — это затея(:

да все верно, интересно.
и замусолить тему тоже интересно :)

Решение интересное, но всё равно читерство :-) Если покопаться, то можно много похожих найти. Например, на GBA был официальный картридж Play-Yan от Nintendo, который играл mp3 и MPEG-4 видео, для чего использовался хардварный декодер VideoCore VC01.

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

Да и Badd Apple тоже (:

Классический пример сопроцессора для обработки видео в картридже это SuperFX, специализированный 16-битный RISC-процессор (корни его можно отследить в современной архитектуре ARC). Чип этот разработал, кстати говоря, Ben Cheese, который в свое время трудился и у Синклера.

Готовый ARM это, конечно, не так интересно, как разработка собственной архитектуры. Я бы больше порадовался чему-нибудь специализированному на, например, Xilinx Spartan 6 (LX4 стоит не дороже многих ARM-микроконтроллеров).

Так тем более на YouTube играть не очень выйдет.

я бы поиграл