Решение интересное, но всё равно читерство :-) Если покопаться, то можно много похожих найти. Например, на GBA был официальный картридж Play-Yan от Nintendo, который играл mp3 и MPEG-4 видео, для чего использовался хардварный декодер VideoCore VC01.
Впрочем, соглашусь, что для хоббийного уровня это очень мощный проект.
Я не люблю такие решения из-за узкой аудитории. Мне интересно кодить чтобы другие могли посмотреть. Конечно, всегда можно записать youtube, как это делает тот же lft, но ты фактически гарантируешь, что это только на youtube и будут смотреть. А при таком раскладе возня с железом и т.д. становится слишком уж абстрактным упражнением на мой вкус.
Ну т.е., возвращаясь к деме Alone Coder для NGS — что, не прикольно? очень прикольно. Но я сразу прикидываю кол-во работающих железок реальное, вспоминаю какие проблемы всякий раз запустить, даже в эмуляторе, и понимаю, что упражнение слишком академическое.
Т.е. люди на TS-Conf ругаются, что не тру, а между прочим, куда демократичнее по железу выходит, нежели NGS.
Ключевое слово — «дешевый» — меня очень сомневает. Я думаю даже как любительский проект стило это не дешево, возможно он привлекал сторонние ресурсы, на работе или еще как. Ну а если он такой фанат что это на досуге делал… массу времени затрачено…
Мне кажется несколько попроще было бы просто присобачить экран и джойстик, от того-же GBC
Вообще, существует мнение, что GB изначально делался под 6502. Остальное железо очень сильно похоже на NES. Кто-то из железячников где-то говорил, что внешняя шина у процессора GB по устройству близка или совпадает с 6502, а не 8080/Z80. Но в какой-то момент разработки процессор предположительно был заменён, по неизвестным соображениям. Возможно, у Sharp для была лицензия на 8080/Z80, но не было на 6502, или они решили применить свой уже существующий промышленный контроллер, который проще интегрировался с драйвером LCD.
Не знаю, исходя из опыта написания кода для 8080/Z80 и 6502/65816/SPC700, я ничего особенно интересного в системе команд не заметил, никакой особенной парадигмы. Может она и есть, но мне кажется, что итоговый дизайн скорее следствие спешки, чем продуманных решений.
Примеры интересных команд: мы привыкли, что 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, и т.д. и т.п. Чисто на идеологическом уровне.
Лично мне показалось это спорным, но весьма занимательным решением (было столько аналогичных фантазий, а тут реально сделано), поэтому и запостил сюда. Судя по активной реакции на пост в самом непопулярном разделе сайта, не зря.
Z80 всё же всегда работает как Z80 соответствующей версии, а не по-другому.
Есть расхожее заблуждение, что процессор GB — урезанная версия Z80 или полноценный Z80; также местной аудитории легче ориентироваться относительно Z80; в формате новости лишний абзац с пояснением, что же там за процессор, не очень уместен. Поэтому вот так.
introspec, мы недавно рассматривали в чате проц гб. gb cpu, посмотри.
я лично восторгов при первом рассмотрении не нашёл. очень порезано. но есть милейший маппинг :)
Я не согласен и всё потому, что мне интересно думать в терминах демокодинга.
Демокодинг на Z80 приучает к некотором стандартным общим образам мысли: «стеком быстрее», «перекладывать байты эффективнее, если задействовать ldi» — базовые эвристики выглядят примерно в этом духе. А на GBC команды чтения и записи байтов с автоинкрементом настолько эффективны, что всякие решения, обычно отметаемые на Z80 становятся снова актуальными. Нужно заново продумывать на уровне эвристик, даже базовые операции.
А вот интересно — у Амстрада z80 работает по-другому. Это недо-z80?
у Mattel Aquarius нет прерываний IM2 — это недо-z80?
у 8080 похожий набор команд — что недо- тогда?
КР580ВМ80, копия 8080 — это недо 8080?
кстати, порча спрайтов при инкременте пар неясно чей глюк — процессора или конструкции?
Да нечего там особо переосмысливать — это немного расширенный 8080 с аппаратными глюками. Там даже банальный инкремент регистровых пар надо использовать с осторожностью, т.к. он может приводить к порче списка спрайтов при определённых условиях. А 8080 по любому менее гибкий, чем Z80 — мало регистров, нет индексных.
Это относительно известный хак. Проблема одновременного доступа к тайлам решается в лоб — использованием двухпортовой памяти, т.е. памяти, которая даёт два полноценных канала для доступа к её содержимому, не мешающих друг другу. В староглиняные времена это было непозволительной роскошью, а сейчас вполне доступно.
Впрочем, соглашусь, что для хоббийного уровня это очень мощный проект.
Ну т.е., возвращаясь к деме Alone Coder для NGS — что, не прикольно? очень прикольно. Но я сразу прикидываю кол-во работающих железок реальное, вспоминаю какие проблемы всякий раз запустить, даже в эмуляторе, и понимаю, что упражнение слишком академическое.
Т.е. люди на TS-Conf ругаются, что не тру, а между прочим, куда демократичнее по железу выходит, нежели NGS.
Мне кажется несколько попроще было бы просто присобачить экран и джойстик, от того-же GBC
и замусолить тему тоже интересно :)
Не знаю, исходя из опыта написания кода для 8080/Z80 и 6502/65816/SPC700, я ничего особенно интересного в системе команд не заметил, никакой особенной парадигмы. Может она и есть, но мне кажется, что итоговый дизайн скорее следствие спешки, чем продуманных решений.
Примеры интересных команд: мы привыкли, что 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 — урезанная версия Z80 или полноценный Z80; также местной аудитории легче ориентироваться относительно Z80; в формате новости лишний абзац с пояснением, что же там за процессор, не очень уместен. Поэтому вот так.
gb cpu, посмотри.
я лично восторгов при первом рассмотрении не нашёл. очень порезано. но есть милейший маппинг :)
традиция, пожалуй.
но явно не моя.
решение — отличное.
стоимость — мизерная.
результат — впечатляющ.
Давайте холиварить?
Я за такие расширения. оригинальная машина + дешёвый специализированный апгрейд.
который:
1. Защита от копирования
2. позволяет сделать именно то что задумано.
3. всё в результате — крайне дёшево.
поэтому используется DMA. А если копнуть в демо, то найдутся и трюки со стеком и прочие.
Демокодинг на Z80 приучает к некотором стандартным общим образам мысли: «стеком быстрее», «перекладывать байты эффективнее, если задействовать ldi» — базовые эвристики выглядят примерно в этом духе. А на GBC команды чтения и записи байтов с автоинкрементом настолько эффективны, что всякие решения, обычно отметаемые на Z80 становятся снова актуальными. Нужно заново продумывать на уровне эвристик, даже базовые операции.
Разумеется, багов процессора это всё не касается…
у Mattel Aquarius нет прерываний IM2 — это недо-z80?
у 8080 похожий набор команд — что недо- тогда?
КР580ВМ80, копия 8080 — это недо 8080?
кстати, порча спрайтов при инкременте пар неясно чей глюк — процессора или конструкции?
как то это… неправильно