Комментарии 40
В отладке кода для ZX Spectrum вас ждет сюрприз — компилятора под него всего два: binutils-z80 и z88dk
Справедливости ради — у speccy был/есть ещё компилятор "HiSoft C".
Спасибо, видимо, пропустил. Быстрый гугл показал, что это компилятор для спектрума, на спектруме. Не совсем то, что нужно.
HiSoft C самый известный, но я точно помню, что помимо него были ещё и другие.
https://worldofspectrum.org/archive/software/utilities/c-compiler-kamasoft
https://worldofspectrum.org/archive/software/utilities/softek-super-c-compiler-softek
А ещё есть IAR z80 компилятор, код генерит не хуже чем sdcc.
IAR ещё. Тот хоть и старый, но в своё время разрабатывался для «серьёзных дел».
Даже CGA-палитра не настолько кошмарна.
И соглашусь, и не соглашусь одновременно. В детстве я был впечатлен игрушками того времени, а сейчас — любопытно обходить его ограничения. Например, посмотрите "The Lyra II Megademo", или "slightly magic" или другие диззи-подобные игры. Или, например, Зеркало (гуглить Zerkalo zx spectrum)
А мне именно палитра нравится. Выглядит замечательно. Хотя мне и герои меча и магии 4 нравятся больше остальных частей вместе с российскими микроконтроллерами. Возможно это связано.
Скорее дело было не в палитре, а клэшинге, когда экран был поделён на знакоместа и одно знакоместо (8 на 8 пикселов) могло, стандартно, иметь одновременно только два цвета и всё (говорим тут о цветном режиме, а не монохроме). А это сильно ограничивало красочность игр. Потом, конечно, появилась такая штука как мультиколор, но использовалось это в демках, да и то, по причине разных таймингов, на разных моделях спектрума работало это не одинаково.
Ср. Commodore 64 и Amstrad CPC:
Мультиколор, кстати, почти такое же древнее явление как и сам спектрум, в играх встречалось тоже, навскидку - заставка Action Force II. И более современные, напр. Old Tower, где вся игра - один большой мультиколор.
https://youtu.be/yHXx3orN35Y
Демка на CGA, например.
Вот уж где была самая отвратительная палитра, так это на БК 0010.
Есть эмуляторы в которых можно переназначить палитру. И по моему были электронные примочки, которые меняли палитру. Я поменял в эмуляторе, чтобы было похоже на палитру c64. И игры реально стали выглядеть гораздо лучше.
Жалко скриншоты не сохранились. Например exolon вообще офигенно смотрелся с коммадоровской палитрой.
А клэшинг это была расплата за дёшево и сердито. Зато существенная экономия памяти на графике, больше помещается в 48 килобайт ОЗУ, процессор гораздо быстрее отрисовывает графику, и наверно самое важное - игра быстрее загружается с кассеты! Ради такого можно и потерпеть клэшинг.
Формально ничего не мешало сделать на спектруме 2ой режим — когда атрибут был не на каждое знакоместо (8х8), а на каждый байт (8х1). Требования к пропускной способности памяти это бы не изменило (ULA в спектруме и так фетчит каждый атрибут 8 раз подряд для каждого из байтов знакоместа), а картинки бы стали лучше выглядеть. Такое делали для многочисленных клонов: https://speccy.info/%D0%90%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D1%83%D0%BB%D1%8C%D1%82%D0%B8%D0%BA%D0%BE%D0%BB%D0%BE%D1%80
новые режимы заставляли бы переделывать так или иначе код и на такое мало кто подпишется, а вот добавление нескольких процессоров как в zx-poly решало вопрос с обратной совместимостью
У c64 приятная палитра. Цвета сочетаются друг с другом. Чувствуется, что палитру художник составлял. За основу палитры взят коричневый цвет, как на картинах Леонардо и Рембрандта. Выбор разумный, в такой палитре легко нарисовать портрет человека, землю, поля, скалы, каменистые планеты, стволы деревьев, деревянные и каменные строения, деревянную же мебель, осеннюю листву.
Очень неплохо для всего лишь 16 цветов.
Все в точности наоборот - палитра отличная, у многих компов с гораздо большими возможностями цвета куда как хуже(привет эплу), а в спек втиснули аж всю радугу.
То что нельзя каждую точку раскрасить - ну посчитайте сколько на это уйдет памяти и проца, для прикладного ПО не останется ресурсов.
В первую очередь, опытным разработчикам, которым хотелось бы встретить вызов: всего лишь ~40кб памяти, включая код программы.
Разработчики не могут написать нетормозящий браузер, и это при охулиардах ОЗУ, куче ядер и ССД.
Как ни оптимизируй, разработчики веб-страничек всё одно уронят производительность в ноль.
А вот почему до сих пор так и не смогли написать нетормозящий просмотрщик PDF, для меня действительно загадка.
M4 FORTH (ZX Spectrum, Z80)
Простой компилятор FORTH, созданный с помощью макросов M4.
Создает читаемый и аннотированный код в ассемблере Z80. Пузырьковая oптимизация (peephole) не используется, но для некоторых часто связанных слов создается новое слово с оптимизированным кодом. Например, для dup <число> <условие> else. Небольшая библиотека среды выполнения для печати чисел и текста предназначена для компьютера ZX Spectrum. Несмотря на свою примитивность, M4 FORTH производит более короткий код и в 2-4 раза более быстрый, чем zd88k, вероятно, лучший компилятор для Z80.
В примерах проекта, приведены пока два демо примера — игра змейка и реализация «игры» имитации «Жизнь».
Автор проекта, также использовал разные тесты для оценки времени их выполнения и сравнения с другими реализациями Форт работающими на разнообразном железе.
P.S. По запросу словосочетания Forth Z80 на Github находятся ещё разныe Форт-системы, в том числе и под разработку для использования с ZX-Spectrum и кросс компиляции.
Вообще, выполнение кода в эмуляторе может дать много возможностей, которые невозможно или сложно получить на реальном железе. Это позволит перевести разработку с ручного ковыряния в байтах на более высокий уровень. Вот что приходит мне в голову:
- профайлинг кода с точностью до такта
- сбор метрик и телеметрии. Например, мы можем в игре собирать статистику, сколько спрайтов отображается на экране, сколько времени это отняло. И естественно, отлавливать случаи, когда пропускается кадр из-за нехватки времени. Более того, мы можем написать скрипт, который будет проходить по уровню и замерять производительность каждого экрана в игре. Затем строить тепловую карту. Это поможет увидеть "тяжелые" места в игре и может быть, что-то поменяв, мы сможем от них избавиться.
- возможность выполнять юнит-тестирование кода
- возможность расстановки ассертов вроде assert HL >= 0x2000. Такие ассерты могут найти ошибку.
- возможность реализовать защиту памяти при косвенной адресации (вроде LD (HL), A) и косвенных переходах. Например, мы можем указать, что эта команда LD (HL), A пишет только в буфер экрана и если программа из-за ошибки попытается произвести запись в другую ячейку, это будет обнаружено.
А что касается ручной отладки, то я gdb не люблю. Я им пользовался несколько раз, но команды каждый раз забываю и гуглю. Неудобно. Мне как-то привычнее "отладка через printf".
Спасибо за статью-комментарий. Натолкнули меня сделать такую пожжержку в fuse, чтобы gdb показал стек на падении. Но, своей задаче — свой инструмент, программа, которую я сейчас отлаживаю, очень завязана на UI и я могу делать printf только или через сеть, или через экран, что не идеально.
Вообще, gdb позволяет при срабатывании брейкпойнта вывести значение переменной и продолжить выполнение автоматически. Это довольно удобная опция.
Но я себе это представляю немного по-другому: мы просто в исходном коде ставим аннотацию Log(HL) и эмулятор, когда доходит до этого места, выводит в консоль значение HL. При этом это именно аннотация, то есть она не создает кодов команд в объектном файле, и не тратит циклы процессора. Аналогично должна работать аннотация assert HL > 0x2000 — она отсутствует в бинарном файле и присутствует только в метаданных к файлу. Аннотации используются только эмулятором и игнорируются на реальном железе.
Аналогично с помощью аннотаций можно собирать метрики и размечать код для профайлинга.
Раз уж все равно кросс-разработка, то положение стека может отслеживать эмулятор, пользуясь для этого отладочной информацией. Не надо тормозить и раздувать программу для этого. Второй плюс - эквивалентность бинарного кода исключит часть ошибок вида "в дебаге работает, в релизе не работает", связанных, например, с выравниванием.
Это исключит возможность реализовать хардварный дебаг без эмулятора, что так же в планах. Ну или создаст необходимость работы над двумя версиями отладчика. Также, gdb, на самом деле, мало что знает про эмулятор и то что он может отслеживать, ему неизвестно, или нужно реализовывать на недокументированном протоколе. Ломать протокол — ломать другие отладчики.
еще когда то был компилятор micro-c, я его лет 20+ назад под Z80 адаптировал (в спековских фидошных эхах он распространялся как PC110) и игру в качестве примера написал
В эмуляторе ZXMAK2 свой gdbserver есть уже лет 10 как
Отладка C на ZX Spectrum