В плане разрешающей способности — я думаю, что не столько важно количество точек, сколько цветовое разрешение. Скажем, если брать тот же C64, при формальном разрешении 320x200, фактически используемое в большинстве картинок — обычно 160x200 (не считая спрайтов) и никого это особо не беспокоит, поскольку в 160x200 с цветами довольно неплохо (4 цвета на знакоместо из 16-ти доступных, в отличии от 320x200, где вроде два из 16). При этом, если вспомнить платформы с разрешением 320x200 и честным «цвет на точку» (например, PC EGA), то уровень графики там в среднем невысок. Другими словами, это уже слишком много. Я думаю, что идеалом было бы что-то типа 256x256 квадратных точек при четырёх цветах на знакоместо из 16 доступных (т.е. слева и справа рамки, картинка «высокая»). 256 — потому что в байт влезает, в отличии от 320. В жизни такое разрешение не использовалось, поскольку неоптимально для текстовых применений — практически тот же объём памяти выгоднее использовать для 320x200, чтобы получить хотя бы 40 столбцов в текстовых редакторах.
Трудно не согласится! Любое ограничение играет в пользу творческого процесса. Можно по взрослым платформам лицезреть как доступность ресурсов работает против них… черт возьми снова законы диалектики :) Было бы интересно увидеть размышления на тему полезного ограничения в разрешающей способности видеоадаптеров для платформы 64К. Есть ли золотая середина?
Мне представляется, что [естественное] ограничение в 64к для восьмибитных платформ, по теперешним временам — это плюс, а не минус. Это примерно из той же серии, что ограничения в 256b, 4k, 640k и т.д. в intro/demo конкурсах. Если не хватает 64к, есть абсолютно доступные PC, Mac, смартфоны.
К слову — даже если посмотреть на Амигу, снятие ограничений пошло, на мой взгляд, ей непосредственно во вред. В среднем качество софта (демо и интро в первую очередь) сильно ниже, чем таковое у 8-битных платформ (того же C64).
Потому что адекватный человек (даже, хе-хе, демомейкер) не будет САМ СЕБЕ создавать сложности — он будет полностью использовать те возможности, которые ему даёт платформа. Это касается и памяти и отсутствий ограничения на число цветов на знакоместо и лёгкость проигрывания сэмплов и пр. Счастье, кстати, что REU для C64 не были широко доступны в своё время и не стали стандартом. Сейчас иногда делают демки для REU (ram expansion unit, до 512K обычно) но, как правило, бросается в глаза, что они написаны просто чтобы как-то использовать REU. Ну там картинку большего размера покрутить, к примеру. Или не возиться с непрерывной подгрузкой с диска, а загрузить сразу всё в буфер.
Хорошее замечание, включу в пример, часть кода. LINK — это регистр в который попадает значение IP для следующей инструкции, в случае записи в IP. То есть в случае с переходом (записью адреса перехода в IP) следующая инструкция на которую будет указывать IP это туда куда надо вернутся.
#label -> IP ; Переход на адрес label и запись адреса следующей инструкции в LINK
R1 -> ALU.A
.........
label:
..............
LINK -> IP ; возврат на команду R1 -> ALU.A
Можно сохранять LINK как и в случае с LR в ARM либо в ОЗУ, либо один из регистров общего назначения. Допустим R4 это стек.
; push LINK
R4 -> ADDR
LINK -> DATA ; LINK 16 битный регистр, будет записан в память как слово за два такта
R4 -> ALU.A
#2 -> ALU.B
ADD -> R4 ; R4 += 2
; pop LINK
R4 -> ALU.A
#-2 -> ALU.B
ADD -> R4
ADD -> ADDR
DATA -> IP ; IP - 16-битный регистр, буден считан за два такта
А вот очень хороший пример! Действительно либо адрес в 16бит и борьба за каждый байт (ЕМНИП, Стив Возняк неплохо это показал запихнув в 256 байт монитор для Apple-I), либо 24/32 бита — «счастье всем и никто не уйдет обиженным». Адресного пространства так много что ARM выделяет в нем области для манипуляцией битами. :)
Недавно были опубликованы исходники порта Doom на SNES созданного Рэнди Линденом считай что своими силами (id software вообще поначалу не была в курсе): gbx.ru/?showtopic=142214
По ссылке я новость написал с минимумом технических подробностей (но история сама, имхо, интересная), но сам же заинтересовался чипом SuperFX — это 16-битный процессор с архитектурой созданной под влиянием идей RISC который на 16-битной SNES позволял эффективно рисовать 3Д-графику — у ЦП SNES с этим есть ряд проблем. А у SuperFX прям как у Z80Next есть команда PutPixel и много прочего. Чип SuperFX впаивался в картридж SNES аки маппер в денди и рулил и педалил 3Д-графоний на 16 битах.
Думаю краткий обзор архитектуры SuperFX станет предметом моей следующей статьи, но тут распишу идею из него которая мне тоже понравилась и которую в таком виде нигде не видел.
Опкоды там как правило однобайтовые, но бывают префиксы.
Шестнадцать 16-битных регистров во многих инструкциях кодируются в четырёх битах как в статье: 0xAB, где A — код инструкции, а B — код регистра. Из этого правила есть немало исключений, но рассмотрим, например, операцию сложения:
ADD R5
В своей первичной форме она рассматривает R0 как аккумулятор и к нему прибавляет указанный в инструкции регистр R5. Т.е. берёт аккумулятор и R5, складывает их и результат записывает обратно в аккумулятор. Окей.
Однако можно временно на одну эффективную инструкцию сменить что будет являться приёмником операции — это делает инструкция TO:
TO R4
ADD R5
Здесь эффект будет таков, что сумма R0 и R5 будет записана в R4. После выполнения ADD приёмник по умолчанию опять станет R0.
Точно так же есть однобайтовая инструкция FROM которая так же меняет временно какой регистр будет служить первым операндом:
FROM R3
TO R4
ADD R5
Выполнит следующее: сумма R5 и R3 запишется в R4, а аккумулятор окажется вообще не при делах.
Для еще больше краткости есть однобайтовая же инструкция WITH которая сразу выставляет и FROM и TO в один и тот же указанный регистр.
Но и это еще не всё — WITH взводит еще один внутренний флаг который модифицирует поведение инструкций FROM и TO если они встречаются после неё. В SuperFX отсутствует специализированная команда MOVE, зато если после WITH сразу же идёт FROM, то происходит копирование из регистра указанного во FROM в регистре запомненном в WITH. И наоборот — инструкция TO скопирует из регистра запомненного по FROM в регистр указанный в себе.
FROM Rn ; код 0xBn - выставляет Sreg в n
TO Rn ; код 0x1n - выставляет Dreg в n
WITH Rn ; код 0x2n - выставляет и Sreg и Dreg в n
Довольно забавная система команд — байтово-ориентированная, но постоянно на каких то полухаках, префиксах и сменах текущих целей и назначений.
Каждый боролся за плотность кода как мог. :)))
Ахаха:D А всё началось с того, что я попросил Виктора впилить ldix и lddx как хоть какую-то альтернативу блиттеру, который они наотрез отказались делать. А дальше всё вышло из под контроля:D
Ну если не лезть внутрь ЦП, то это вполне реальный путь и он всё-равно будет теоретически намного быстрее обычного калькулятора, т.к. процессору останется исполнить ну десяток-два максимум инструкций.
Но вообще надо аккуратно исследовать вопрос — ведь калькулятор это в сути своей пресолиднейший кусок ROM, т.к. он и есть все функции бейсика включая USR которая должна обратно вывалиться в режим процессора.
Калькулятор держит стек в памяти как и ряд переменных в basic vars позволяющих определить где он заканчивается. Поэтому технически можно было бы обставить это дело таким образом, что код в RST 28 каким то образом запускает процесс калькулятора как нечто внешнее (накормив тем же адресом откуда надо выполнять инструкции), а по сигналу завершения берёт HL из известных переменных бейсика как он в общем то и делает скорее всего в оригинале.
Это как? Внешний доступ к памяти возможен, к регистрам — нет, а ведь в них по итогу калькуляторных процедур определённые значения ожидаются. Разве что обманом заставить проц по im0 выполнить команды загрузок, да еще нужные значения им подсунуть. Твой аух сумеет разве такое?
Последнее достаточно забавно, и мне даже нравится. В качестве FPU можно использовать AYX-32 (про который тут когда-нибудь будет статья). Самое простое — код по $0028 поменять на вызовы команд по портам АУ.
Ну насколько я понимаю, пока DMA перебрасывает данные процессор остановлен и прерывание тоже не приходит. Отличие в том, что во время переброски данных z80DMA всегда DI на Z80, а это очень неудобно. И я думаю в zxnDMA более упощенный, хотя не проверял, но вряд ли там всё возможности реализованы.
Это если развернуть фразу — значит в оригинальном z80DMA — этого делать нельзя?? хмм… И в чем же проявляется отличие, если на пальцах?
Так то я все демки для z80DMA написанные пересмотрел, работают в большинстве своем наверное правильно, как авторы задумывали. Но большинство работает и в режиме zxnDMA, иногда даже лучше, чем в нативном.
В эмулях работает DMA пока плоховато :( Хотелось бы поточнее эмууляцию.
К слову — даже если посмотреть на Амигу, снятие ограничений пошло, на мой взгляд, ей непосредственно во вред. В среднем качество софта (демо и интро в первую очередь) сильно ниже, чем таковое у 8-битных платформ (того же C64).
Потому что адекватный человек (даже, хе-хе, демомейкер) не будет САМ СЕБЕ создавать сложности — он будет полностью использовать те возможности, которые ему даёт платформа. Это касается и памяти и отсутствий ограничения на число цветов на знакоместо и лёгкость проигрывания сэмплов и пр. Счастье, кстати, что REU для C64 не были широко доступны в своё время и не стали стандартом. Сейчас иногда делают демки для REU (ram expansion unit, до 512K обычно) но, как правило, бросается в глаза, что они написаны просто чтобы как-то использовать REU. Ну там картинку большего размера покрутить, к примеру. Или не возиться с непрерывной подгрузкой с диска, а загрузить сразу всё в буфер.
Можно сохранять LINK как и в случае с LR в ARM либо в ОЗУ, либо один из регистров общего назначения. Допустим R4 это стек.
И еще по вашему процессору я не понял как делается CALL — LR вроде есть, но непонятно что в него записывать.
P.S. Статья про SuperFX будет крайне интересна!
По ссылке я новость написал с минимумом технических подробностей (но история сама, имхо, интересная), но сам же заинтересовался чипом SuperFX — это 16-битный процессор с архитектурой созданной под влиянием идей RISC который на 16-битной SNES позволял эффективно рисовать 3Д-графику — у ЦП SNES с этим есть ряд проблем. А у SuperFX прям как у Z80Next есть команда PutPixel и много прочего. Чип SuperFX впаивался в картридж SNES аки маппер в денди и рулил и педалил 3Д-графоний на 16 битах.
Думаю краткий обзор архитектуры SuperFX станет предметом моей следующей статьи, но тут распишу идею из него которая мне тоже понравилась и которую в таком виде нигде не видел.
Опкоды там как правило однобайтовые, но бывают префиксы.
Шестнадцать 16-битных регистров во многих инструкциях кодируются в четырёх битах как в статье: 0xAB, где A — код инструкции, а B — код регистра. Из этого правила есть немало исключений, но рассмотрим, например, операцию сложения:
В своей первичной форме она рассматривает R0 как аккумулятор и к нему прибавляет указанный в инструкции регистр R5. Т.е. берёт аккумулятор и R5, складывает их и результат записывает обратно в аккумулятор. Окей.
Однако можно временно на одну эффективную инструкцию сменить что будет являться приёмником операции — это делает инструкция TO:
Здесь эффект будет таков, что сумма R0 и R5 будет записана в R4. После выполнения ADD приёмник по умолчанию опять станет R0.
Точно так же есть однобайтовая инструкция FROM которая так же меняет временно какой регистр будет служить первым операндом:
Выполнит следующее: сумма R5 и R3 запишется в R4, а аккумулятор окажется вообще не при делах.
Для еще больше краткости есть однобайтовая же инструкция WITH которая сразу выставляет и FROM и TO в один и тот же указанный регистр.
Но и это еще не всё — WITH взводит еще один внутренний флаг который модифицирует поведение инструкций FROM и TO если они встречаются после неё. В SuperFX отсутствует специализированная команда MOVE, зато если после WITH сразу же идёт FROM, то происходит копирование из регистра указанного во FROM в регистре запомненном в WITH. И наоборот — инструкция TO скопирует из регистра запомненного по FROM в регистр указанный в себе.
Довольно забавная система команд — байтово-ориентированная, но постоянно на каких то полухаках, префиксах и сменах текущих целей и назначений.
Каждый боролся за плотность кода как мог. :)))
Но вообще надо аккуратно исследовать вопрос — ведь калькулятор это в сути своей пресолиднейший кусок ROM, т.к. он и есть все функции бейсика включая USR которая должна обратно вывалиться в режим процессора.
+ еще загрузить корректный указатель стека кроме HL
как-то не особо «просто» уже всё это
Так то я все демки для z80DMA написанные пересмотрел, работают в большинстве своем наверное правильно, как авторы задумывали. Но большинство работает и в режиме zxnDMA, иногда даже лучше, чем в нативном.
В эмулях работает DMA пока плоховато :( Хотелось бы поточнее эмууляцию.
И надо сказать он во многих очень важных вещах отличается от данного, но проясняет некоторые моменты. Такое ощущение что переводчики с японского были сильны в разных предложениях.