diff --git a/applications/PoP/docs/README.md b/applications/PoP/docs/README.md index 3809363..3cadc18 100644 --- a/applications/PoP/docs/README.md +++ b/applications/PoP/docs/README.md @@ -14,6 +14,7 @@ | [`layout_plan_v2.md`](layout_plan_v2.md) | Раскладка кода по окнам/банкам/страницам + замеры скорости отрисовки | | [`room_model_plan.md`](room_model_plan.md) | `kid_room ≠ drawn_room` (straddle): сделан S1, остальное впереди | | [`host_tests_plan.md`](host_tests_plan.md) | Модульные тесты движка под ucsim_z80: два шва, регрессии из `bug_closed.md`, дифф против SDLPoP | +| [`shadow_render.md`](shadow_render.md) | **Вид Тени (OR+XOR)** — отложено: почему XOR несовместим с прозрачностью `#FF`, замер подготовки источника, четыре варианта | | [`ideas_backlog.md`](ideas_backlog.md) | Осознанно отложенные гипотезы (мышь, PRNG) | | [`prng_alternatives.md`](prng_alternatives.md) | Запасные генераторы, если упрёмся в бюджет кадра | diff --git a/applications/PoP/docs/shadow_render.md b/applications/PoP/docs/shadow_render.md new file mode 100644 index 0000000..af0a39b --- /dev/null +++ b/applications/PoP/docs/shadow_render.md @@ -0,0 +1,160 @@ +# Отрисовка Тени (charid_1_shadow) — изыскания, отложено + +Статус на 2026-08-11: **отложено по решению пользователя.** Тень пока +рисуется как обычный персонаж — простой копией из атласов Кида +(`pop_cdraw.c`, банк 0x5C, аппаратная прозрачность `#FF`). Вернуться к +«правильному» виду, когда будут сделаны все уровни: тогда будет известно, +какими именно кадрами тень вообще пользуется. + +Этот файл собирает всё, что уже выяснено, чтобы не переоткрывать. + +--- + +## 1. Как тень выглядит в оригинале + +Тень рисуется **двумя блитами ОДНОГО И ТОГО ЖЕ спрайта Кида** +(`seg008:1602`, `add_objtable`): + +```c +case 1: // shadow + add_midtable(obj_chtab, obj_id + 1, obj_xh, obj_xl, obj_y, blitters_2_or, 1); + add_midtable(obj_chtab, obj_id + 1, obj_xh, obj_xl + 1, obj_y, blitters_3_xor, 1); +``` + +OR на месте, XOR со сдвигом на пиксель вправо. XOR гасит совпавшее, +остаются края — отсюда «контурный» вид. Это ЗАМЫСЕЛ оригинала, а не +артефакт SDLPoP: подтверждено печатью из живого SDLPoP (метка `DBGMIRROR` +в `add_objtable`) — и тень, и отражение идут из `chtab=2` (собственные +спрайты Кида), `swordbits=0`, обычными кадрами: + +``` +type=4 chtab=2 img=40 dir=0 clipL=137 clipT=3 charid=0 frame=41 <- отражение +type=1 chtab=2 img=41 dir=0 clipL=137 clipT=3 charid=1 frame=42 <- тень +``` + +Единственное различие между отражением и тенью — блиттер. + +## 2. Чем мы располагаем + +Блочные AND/OR/XOR/NOT акселератора подняты в libbgi 2026-08-11 (полный +набор строками и колонками, `gfx_blit_op` / `gfx_blit_part_op` / +`gfx_blit_cols_op` / `gfx_blit_cols_part_wx_op`; регресс — `tests/accop`, +10/10 PASS). Механика и ловушки — memory `accel_block_ops` и шапка +`libbgi/common/_gfx_blit_full_op.c`. То есть примитивов достаточно, дело +не в них. + +## 3. Две причины, по которым «в лоб» не получается + +### 3.1 XOR несовместим с нашей прозрачностью `#FF` + +Аппаратная прозрачность (бит 3 видеобанка) подавляет запись байта `#FF`, +то есть смотрит на **результат** операции: + +| операция | прозрачный пиксель источника | итог | +|---|---|---| +| AND | `#FF & bg = bg` | работает даром | +| OR | `#FF \| bg = #FF`, запись подавляется | работает даром | +| XOR | `#FF ^ bg = ~bg`, подавления нет | **инверсия фона по всему футпринту** | + +Совпадение с «ничего не делать» у XOR получается только там, где фон равен +0 (`#FF ^ 0 = #FF` → подавляется). В DOS-оригинале прозрачный индекс = 0 — +нейтральный и для OR, и для XOR, поэтому там оба блиттера работают на одном +наборе спрайтов. У нас прозрачный `0xFF` (`pop_pack_kid.py`: `0 -> 0xFF`, +`i -> 0x70 + i`). + +Замаскировать `#FF` внутри операции нельзя в принципе: побитовые AND/OR/XOR +не умеют «выбрать по условию», а `#FF` — нейтраль только для AND. Значит +источнику XOR-прохода нужен **прозрачный `0x00`**, то есть отдельный набор +спрайтов. + +### 3.2 Операция читает ОЗУ-копию экрана, а не видео-ОЗУ + +Чтение страниц `#50..#5F` всегда отдаёт ОЗУ-копию (memory +`sprinter_vram_transparency`), а персонажи рисуются банком `0x5C` («не +писать в копию» — на этом держится даровой heal). Поэтому второй проход +**не увидит результат первого**: два блита оригинала выродились бы в +«просто XOR», контурного эффекта не будет. + +Лечится не банком `0x50` (он ломает heal — копия перестанет быть чистым +фоном), а **однопроходным композитом**: всё складывается в буфере +акселератора за один проход по колонке j футпринта + +``` +буфер := s[j] ; спрайт +буфер |= bg[j] ; вертикальное чтение экрана +буфер ^= s[j-1] ; тот же спрайт, предыдущая колонка = сдвиг на +1 px +запись ; вертикальная запись колонки +``` + +что **точно эквивалентно** двум блитам оригинала (крайние колонки: `x` — +только OR, `x+w` — только XOR) и вдобавок дешевле их: 4 burst'а на колонку +против 6. Такому композиту тоже нужен источник с прозрачным `0x00` — уже +на обоих шагах. + +## 4. Сколько стоит подготовить источник с прозрачным `0x00` + +Замер 2026-08-11 (`tests/convbench`, watchpoint по IO-записи в MAME, кадр = +430 080 тактов). Цикл безветвочный (`ADD A,A / SBC A,A / CPL / AND` — +маска из бита 7: прозрачный `#FF` отличается от цветов Кида `0x70..0x7F` +именно им), 59 номинальных T-states на байт, по факту **145.3 такта/байт** +(2.5× wait-state'ов ОЗУ): + +| объём | кадров | секунд | +|---|---|---| +| 1 страница атласа, 16 КБ | 5.5 | 0.11 | +| весь атлас Кида, 28 страниц × 16 КБ = 448 КБ | 155 | 3.2 | +| он же **по реальному размеру данных (186 КБ)** | 64 | **1.3** | + +Последняя строка — замечание пользователя: 28 атласов занимают 186 КБ, а не +448 КБ; обрабатывать по фактическому размеру ленты вместо целой страницы +даёт 2.4× (ценой проверки границы в цикле). Потолок разгона самого цикла — +ещё примерно вдвое (раскрутка убирает `djnz`, чтение через SP парами + +таблица 256 Б вместо арифметики), то есть **~0.7 с** на 186 КБ. Порядок +величины при этом не меняется. + +**Окна:** источник и приёмник — разные EMM-страницы, а окно под атласы одно +(W0), поэтому конвертация гоняется «страница-источник в W0 → +страница-приёмник в W3» целыми страницами; побайтно переключать окно нельзя. +EMM-бюджет: +28 страниц (448 КБ) из ~3440 КБ свободных — не проблема +(memory `sprinter_emm_budget`), и он одинаков в любом из вариантов. + +## 5. Варианты (когда вернёмся) + +1. **Конвертация в рантайме при загрузке уровня с тенью** (4, 5, 6, 12): + диск и упаковщик не трогаем, цена — 1.3 с (или 0.7 с после разгона) на + загрузку такого уровня. +2. **Лениво, постранично** — 0.11 с (5.5 кадра) при первом обращении тени к + странице; рывок один раз на страницу, суммарно меньше, чем вариант 1. +3. **Второй набор `.atl` от упаковщика** (`pop_pack_kid.py`, прозрачный + `0x00`): 0 с рантайма, +186 КБ на образе и вторая ветка в загрузчике + атласов. +4. **Только OR-проход** (то, чем можно обойтись бесплатно): OR с нашим + `#FF`-атласом работает как есть, тень получается сплошным силуэтом в + палитре Кида, без контурного эффекта. Расхождение с оригиналом — тогда + записью в `docs/impl_diff.md`. + +**Ключ к выбору — какие кадры тень вообще использует.** Предположение +пользователя: только бег, длинный прыжок (из зеркала), питьё зелья и +боёвка; прыжки с места и подтягивания — нет. Если так, конвертировать +(или паковать) нужно единицы страниц, а не 28, и разница между вариантами +почти исчезает. Список снимать по факту — когда уровни 5/6/12 будут +проходиться. + +## 6. Что ещё придётся проверить глазами + +Палитра. У нас индексы разложены группами по 16 (`pop_pack_bg.py`): +`0x30` VGA16, `0x40` chtab_1, `0x50` env, `0x60` wall, `0x70` kid, `0x80` +sword, `0x90` guard. Отсюда ожидания (аналитические, в MAME НЕ +проверялись): + +- OR-проход ложится удачно: `0x7X | 0x5Y = 0x7Z` — результат остаётся в + палитре Кида, а младший ниббл получается ровно тот же, что дал бы DOS + (там OR шёл по 4-битным индексам внутри одной палитры); +- XOR-проход уводит результат в группы `0x0Z` (поверх OR-результата) и + `0x2Z` (по чистому фону) — **обе группы палитры у нас не заполнены**, то + есть контур рискует оказаться просто чёрным. + +Значит к «посмотреть глазами» добавляется вопрос, чем заполнять `0x00..0x0F` +и `0x20..0x2F` — по сути это и будет выбор цветов тени. В DOS такого +вопроса не было: XOR двух 4-битных индексов всегда оставался внутри той же +16-цветной палитры. diff --git a/applications/PoP/roomtest/TASKS_OPEN.md b/applications/PoP/roomtest/TASKS_OPEN.md index f4769c2..d6971c2 100644 --- a/applications/PoP/roomtest/TASKS_OPEN.md +++ b/applications/PoP/roomtest/TASKS_OPEN.md @@ -798,6 +798,22 @@ loose-плиту (7, кол 4, ряд 0). колонки слева. Нужен либо новый примитив, либо сдвиг `bx` со срезом исходных колонок. Пока без него тень будет вылезать левее зеркала. +6. **ВИД ТЕНИ (два блиттера OR + XOR) — ОТЛОЖЕН 2026-08-11 по решению + пользователя.** Пока тень рисуется как обычный персонаж, простой копией + из атласов Кида — сюжетно уровень это не задерживает. Все изыскания + собраны в [`../docs/shadow_render.md`](../docs/shadow_render.md): + почему XOR несовместим с нашей прозрачностью `#FF` (нужен источник с + прозрачным `0x00`), почему два прохода оригинала не воспроизводятся в лоб + (операция читает ОЗУ-копию, а персонажи рисуются банком 0x5C) и во что + это выливается — однопроходный композит `s | bg ^ s(сдвиг)`. Там же + ЗАМЕР стоимости подготовки такого источника в рантайме (145.3 такта/байт: + 0.11 с на страницу, 1.3 с на реальные 186 КБ атласа) и четыре варианта. + Блочные операции акселератора для этого уже есть в libbgi + (`gfx_blit_cols_op` и семейство, `tests/accop` 10/10 PASS). + Вернуться, когда будут сделаны все уровни и станет известно, какими + кадрами тень реально пользуется (ожидание: бег, длинный прыжок из + зеркала, питьё зелья, боёвка — тогда готовить надо единицы страниц). + Порядок: 1 -> 2 -> 4 -> 5 -> 3. После 4 и 5 уровень уже проходится, потому что сюжетно достаточно прыгнуть сквозь зеркало. diff --git a/docs/size_baseline.tsv b/docs/size_baseline.tsv index cf1d3fe..ce45987 100644 --- a/docs/size_baseline.tsv +++ b/docs/size_baseline.tsv @@ -1,6 +1,6 @@ # Эталон размеров _CODE (байт); обновление: python3 toolchain/size_check.py --update accfill 3786 -accop 6501 +accop 7067 argv 3431 assrtest 3847 atlas 9193 @@ -20,6 +20,7 @@ cbltest 6613 cblwav 6681 conio 4605 conio2 3929 +convbench 3508 dec_test 860 errno 5966 fbench 8085 diff --git a/libbgi/_bgi.h b/libbgi/_bgi.h index fe3a261..ecec621 100644 --- a/libbgi/_bgi.h +++ b/libbgi/_bgi.h @@ -96,6 +96,21 @@ void _bgi_blit_rows_op_raw(const uint8_t *src, uint8_t *dst, uint8_t w, uint8_t h, int sstride, uint8_t y0, uint8_t op); +/* Операция NOT (приёмник = ~источник): у акселератора нет режима + * «инвертировать буфер», поэтому вторым burst'ом идёт XOR по блоку + * единиц _bgi_ones256. Отдельные ядра — цепочка не такая, как у + * AND/OR/XOR. bgi256/_bgi_blit_{rows,cols}_not_raw.c. */ +void _bgi_blit_rows_not_raw(const uint8_t *src, uint8_t *dst, + uint8_t w, uint8_t h, + int sstride, uint8_t y0); +void _bgi_blit_cols_not_raw(const uint8_t *src, uint8_t *dst, + uint8_t w, uint8_t h, + int sstride, uint8_t y0); + +/* Константный блок из 256 байт #FF — второй операнд NOT-цепочки + * (common/_bgi_ones256.c). */ +extern const uint8_t _bgi_ones256[256]; + /* КОЛОНОЧНАЯ специализация (column-major src -> экран): каждая колонка — * вертикальный accel-burst (LD A,A, Port_Y авто-шаг); dst +1/колонку, src * +sstride/колонку. Даёт бесплатный горизонтальный флип (sstride<0 + src diff --git a/libbgi/bgi256/_bgi_blit_cols_not_raw.c b/libbgi/bgi256/_bgi_blit_cols_not_raw.c new file mode 100644 index 0000000..d4c0965 --- /dev/null +++ b/libbgi/bgi256/_bgi_blit_cols_not_raw.c @@ -0,0 +1,88 @@ +/* + * _bgi_blit_cols_not_raw — accel-блит КОЛОНКАМИ операцией NOT: приёмник = + * ~источник (приёмник в операции НЕ участвует). Колоночный близнец + * _bgi_blit_rows_not_raw; про то, почему NOT делается XOR'ом по блоку + * единиц, а не `CPL`, — в его шапке и в common/_bgi_ones256.c. + * + * ЦЕПОЧКА НА КОЛОНКУ (три burst'а): + * OUT Port_Y = y0 + * LD L,L · LD A,(DE) ; ГОРИЗ: буфер := колонка src (смежная) + * LD B,B ; СТОП — разоружить перед сменой HL + * PUSH HL · LD HL,#ones · LD L,L · XOR (HL) ; ГОРИЗ: буфер = ~src + * LD B,B · POP HL ; вернуть адрес колонки экрана + * LD A,A · LD (HL),A ; ВЕРТ: буфер -> видео-колонка + * LD B,B + * В отличие от _bgi_blit_cols_op_raw, ВТОРОЙ OUT Port_Y здесь НЕ нужен: + * op-burst идёт по блоку единиц в ГОРИЗОНТАЛЬНОМ режиме, а Port_Y шагает + * только вертикальный. PUSH/POP выполняются под СТОПом (accel разоружён) + * — иначе обращение к стеку само стало бы триггером. + * + * ВХОД (__sdcccall(1)): src→HL, dst→DE; стек: w 4(ix), h 5(ix), + * sstride 6/7(ix), y0 8(ix) — как у _bgi_blit_cols_raw. Callee-pop 5 Б. + * Raw: без клипа, W3 замаплен снаружи, банк ставит вызывающий, src ВНЕ W3. + * Клоббер: AF/BC/DE/HL; IX сохраняется. + */ + +#include "../_bgi.h" + +void _bgi_blit_cols_not_raw(const uint8_t *src, uint8_t *dst, + uint8_t w, uint8_t h, + int sstride, uint8_t y0) __naked +{ + (void)src; (void)dst; (void)w; (void)h; (void)sstride; (void)y0; + __asm + push ix + ld ix, #0 + add ix, sp + ;; SMC: размер accel-блока <- h (высота колонки) + ld a, 5 (ix) + ld (cn_len_imm), a + ;; SMC: src-страйд между колонками (± на вызов — даёт флип) + ld a, 6 (ix) + ld (cn_slo_imm), a + ld a, 7 (ix) + ld (cn_shi_imm), a + ld b, 4 (ix) ; B = число колонок (0 => 256: djnz) + ld c, 8 (ix) ; C = y0 (Port_Y, константа) + ex de, hl ; HL = dst (видео), DE = src (ОЗУ) + di ; один DI на весь блит + ld d, d ; 0x52 — режим размера блока + ld a, #0 + cn_len_imm = . - 1 + ld b, b ; 0x40 — стоп + cn_col: + ld a, c + out (#0x89), a ; Port_Y = y0 (верх колонки) + ld l, l ; 0x6D — гориз. режим (колонка src смежна) + ld a, (de) ; read-burst : h байт src -> буфер + ld b, b ; 0x40 — стоп (разоружить перед PUSH/LD HL) + push hl ; спрятать адрес колонки экрана + ld hl, #__bgi_ones256 + ld l, l ; 0x6D — гориз. режим + xor a, (hl) ; op-burst : буфер ^= #FF... = ~src + ld b, b ; 0x40 — стоп + pop hl ; HL = адрес колонки экрана + ld a, a ; 0x7F — верт. режим + ld (hl), a ; write-burst: буфер -> видео-колонка + ld b, b ; 0x40 — стоп + ;; src += sstride (следующая колонка источника) + ld a, e + add a, #0 + cn_slo_imm = . - 1 + ld e, a + ld a, d + adc a, #0 + cn_shi_imm = . - 1 + ld d, a + inc hl ; dst += 1 (следующий x) + djnz cn_col + ei + pop ix + ;; callee-pop 5 байт (w,h,sstride:2,y0) + pop hl ; ret-адрес + pop af + pop af + inc sp + jp (hl) + __endasm; +} diff --git a/libbgi/bgi256/_bgi_blit_rows_not_raw.c b/libbgi/bgi256/_bgi_blit_rows_not_raw.c new file mode 100644 index 0000000..224124b --- /dev/null +++ b/libbgi/bgi256/_bgi_blit_rows_not_raw.c @@ -0,0 +1,102 @@ +/* + * _bgi_blit_rows_not_raw — accel-блит СТРОКАМИ операцией NOT: приёмник = + * ~источник (приёмник в операции НЕ участвует). Пара к + * _bgi_blit_rows_op_raw, вынесена отдельно, потому что цепочка другая. + * + * ПОЧЕМУ НЕ `CPL`. Буфер акселератора меняется только на ЧТЕНИИ и только + * опкодами AND/OR/XOR (HL) (драйвер MAME, update_accel_buffer); `CPL` + * (#2F) автомат не распознаёт вовсе — инвертируется регистр CPU, а не + * буфер, и запись выгрузит неизменённый блок. Зато ~src = src XOR #FF, + * поэтому NOT собирается из имеющегося: XOR-burst по константному блоку + * единиц (common/_bgi_ones256.c). + * + * ЦЕПОЧКА НА СТРОКУ (три burst'а, все горизонтальные): + * OUT Port_Y = y + * LD L,L · LD A,(DE) ; буфер := src + * LD B,B ; СТОП — разоружить перед сменой HL + * LD HL,#ones · LD L,L · XOR (HL) ; буфер ^= #FF... = ~src + * LD B,B ; СТОП + * LD HL,#dst · LD L,L · LD (HL),A ; запись строки + * LD B,B + * СТОП перед каждой загрузкой HL обязателен: под армированным accel fetch + * операнда `LD HL,nn` перезапустил бы burst (memory/ + * accel_operand_fetch_retrigger). Буфер и размер блока переживают LD B,B + * (docs/new/06-accel.md §6.3) — на этом всё и держится. + * Port_Y в горизонтальном режиме не шагает, сбрасывать его между + * burst'ами не нужно; dst фиксирован (строку выбирает Port_Y) и потому + * кладётся SMC-immediate'ом один раз на вызов. + * + * Прозрачности у NOT нет по определению (инвертируется КАЖДЫЙ байт, в том + * числе #FF -> 0x00) — это ровно семантика NOT_PUT из Turbo C BGI. + * + * ВХОД (__sdcccall(1)): src→HL, dst→DE (фикс); стек: w 4(ix), h 5(ix), + * sstride 6/7(ix), y0 8(ix). Callee-pop 5 Б. Raw: без клипа, W3 замаплен + * снаружи, банк ставит вызывающий, src ВНЕ W3. Клоббер: AF/BC/DE/HL. + */ + +#include "../_bgi.h" + +void _bgi_blit_rows_not_raw(const uint8_t *src, uint8_t *dst, + uint8_t w, uint8_t h, + int sstride, uint8_t y0) __naked +{ + (void)src; (void)dst; (void)w; (void)h; (void)sstride; (void)y0; + __asm + push ix + ld ix, #0 + add ix, sp + ;; SMC: размер блока <- w + ld a, 4 (ix) + ld (bn_len_imm), a + ;; SMC: src-страйд между строками + ld a, 6 (ix) + ld (bn_slo_imm), a + ld a, 7 (ix) + ld (bn_shi_imm), a + ;; SMC: адрес приёмника — фиксирован на весь блит (строку задаёт + ;; Port_Y), а HL по очереди занят то блоком единиц, то им + ld (bn_dst_imm), de + ld b, 5 (ix) ; B = счётчик строк (0 => 256: djnz) + ld c, 8 (ix) ; C = y + ex de, hl ; DE = src (читается LD A,(DE)) + di ; один DI на весь блит + ld d, d ; 0x52 — режим размера блока + ld a, #0 + bn_len_imm = . - 1 + ld b, b ; 0x40 — стоп (B=счётчик не тронут) + bn_row: + ld a, c + out (#0x89), a ; Port_Y = y + inc c + ld l, l ; 0x6D — гориз. режим + ld a, (de) ; read-burst : src -> буфер + ld b, b ; 0x40 — стоп (разоружить перед LD HL) + ld hl, #__bgi_ones256 + ld l, l ; 0x6D — гориз. режим + xor a, (hl) ; op-burst : буфер ^= #FF... = ~src + ld b, b ; 0x40 — стоп + ld hl, #0 + bn_dst_imm = . - 2 + ld l, l ; 0x6D — гориз. режим + ld (hl), a ; write-burst: буфер -> строка экрана + ld b, b ; 0x40 — стоп + ;; src += sstride + ld a, e + add a, #0 + bn_slo_imm = . - 1 + ld e, a + ld a, d + adc a, #0 + bn_shi_imm = . - 1 + ld d, a + djnz bn_row + ei + pop ix + ;; callee-pop 5 байт (w,h,sstride:2,y0) + pop hl ; ret-адрес + pop af + pop af + inc sp + jp (hl) + __endasm; +} diff --git a/libbgi/common/_bgi_ones256.c b/libbgi/common/_bgi_ones256.c new file mode 100644 index 0000000..a56611e --- /dev/null +++ b/libbgi/common/_bgi_ones256.c @@ -0,0 +1,53 @@ +/* + * _bgi_ones256 — константный блок из 256 байт #FF: второй операнд для + * блит-операции NOT (GFX_OP_NOT). + * + * ЗАЧЕМ. У акселератора нет режима «инвертировать буфер»: буфер меняется + * только на ЧТЕНИИ и только опкодами AND/OR/XOR (HL) (см. драйвер MAME, + * update_accel_buffer). `CPL` автомат не распознаёт вовсе — он + * инвертирует регистр CPU, а не буфер. Зато ~src = src XOR #FF, поэтому + * NOT собирается из уже имеющегося: буфер := src, потом XOR-burst по + * этому блоку, потом запись. + * + * Отдельным модулем — по правилу «общие статики в свой модуль»: блок + * нужен обоим ядрам (rows и cols), а программа без NOT его не линкует. + * const => живёт в _CODE, то есть вне W3 — как и требует accel (сторона + * ОЗУ на время операции не должна быть перекрыта видеобанком). + * Размер ровно 256 — максимальный размер accel-блока. + */ +#include "../_bgi.h" + +const uint8_t _bgi_ones256[256] = { + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF +}; diff --git a/libbgi/common/_gfx_blit_full_op.c b/libbgi/common/_gfx_blit_full_op.c index 119accb..377ae24 100644 --- a/libbgi/common/_gfx_blit_full_op.c +++ b/libbgi/common/_gfx_blit_full_op.c @@ -67,6 +67,21 @@ void _gfx_blit_full_op(int x, int y, const void *img, src += (uint16_t)sy * (uint16_t)img_w; dst = _gfx_addr_base + x; + /* NOT — не операция с приёмником, а инверсия источника, и цепочка у + * неё другая (XOR по блоку единиц вместо чтения приёмника), поэтому + * своё ядро. Ветка одна на вызов, в цикл по полосам не заходит. */ + if (op == GFX_OP_NOT) { + while (w > 256) { + _bgi_blit_rows_not_raw(src, (uint8_t *)dst, 0 /* =256 */, + (uint8_t)h, img_w, (uint8_t)y); + src += 256; + dst += 256; + w -= 256; + } + _bgi_blit_rows_not_raw(src, (uint8_t *)dst, (uint8_t)w, (uint8_t)h, + img_w, (uint8_t)y); + return; + } while (w > 256) { _bgi_blit_rows_op_raw(src, (uint8_t *)dst, 0 /* =256 */, (uint8_t)h, img_w, (uint8_t)y, op); diff --git a/libbgi/common/gfx_blit_cols_part_wx_op.c b/libbgi/common/gfx_blit_cols_part_wx_op.c index fa11ddd..47e83d4 100644 --- a/libbgi/common/gfx_blit_cols_part_wx_op.c +++ b/libbgi/common/gfx_blit_cols_part_wx_op.c @@ -89,7 +89,13 @@ void gfx_blit_cols_part_wx_op(int x, int y, const void *img, uint8_t flip, _bgi_begin(); dst = (uint8_t *)(_gfx_addr_base + (uint16_t)x); - _bgi_blit_cols_op_raw(src, dst, (uint8_t)w, (uint8_t)h, sstride, - (uint8_t)y, op); + /* NOT — инверсия ИСТОЧНИКА, приёмник в ней не участвует: своя цепочка + * (XOR по блоку единиц) и своё ядро. Ветка одна на вызов. */ + if (op == GFX_OP_NOT) + _bgi_blit_cols_not_raw(src, dst, (uint8_t)w, (uint8_t)h, sstride, + (uint8_t)y); + else + _bgi_blit_cols_op_raw(src, dst, (uint8_t)w, (uint8_t)h, sstride, + (uint8_t)y, op); _bgi_end(); } diff --git a/libbgi/common/putimage.c b/libbgi/common/putimage.c index dd7d3ad..c797e92 100644 --- a/libbgi/common/putimage.c +++ b/libbgi/common/putimage.c @@ -8,17 +8,16 @@ * с учётом текущего банка (gfx_set_bank: 0x58 даёт аппаратную * прозрачность 0xFF, 0x54/0x5C — временный вывод). * - * XOR/OR/AND_PUT — тоже через акселератор (gfx_blit_part_op, 2026-08-11; - * закрыт пункт 2d-1 docs/TODO.md): акселератор умеет блочные AND/OR/XOR - * между своим буфером и памятью приёмника, попиксельного цикла CPU больше - * нет. Клиппинг у них теперь ТОТ ЖЕ, что у COPY_PUT (раньше на этом пути - * клипа не было вовсе). Оговорки — в шапке common/_gfx_blit_full_op.c: - * операция читает ОЗУ-копию экрана (при банках 0x54/0x5C это чистый фон), - * а прозрачность #FF совместима с AND/OR, но не с XOR. + * XOR/OR/AND/NOT_PUT — тоже через акселератор (gfx_blit_part_op, + * 2026-08-11; закрыт пункт 2d-1 docs/TODO.md): у железа есть блочные + * AND/OR/XOR между буфером акселератора и памятью приёмника, а NOT + * выражается через XOR по блоку единиц. Попиксельного пути в putimage + * больше НЕТ ВООБЩЕ, и клиппинг у всех пяти операций теперь одинаковый + * (раньше на непрямом пути его не было вовсе). * - * NOT_PUT — по-прежнему по-пиксельно (пишем ~src): это не операция с - * приёмником, а инверсия источника, у акселератора такого режима нет. - * Клиппинга на этом пути НЕТ (per-pixel bounds-check только в safe). + * Оговорки — в шапке common/_gfx_blit_full_op.c: операция читает + * ОЗУ-копию экрана (при банках 0x54/0x5C это чистый фон, а не то, что + * нарисовано поверх), а прозрачность #FF совместима с AND/OR, но не с XOR. * * Буфер bitmap обязан лежать вне W3 (< 0xC000) — на время операции W3 * замаплен на видеобанк. @@ -28,7 +27,7 @@ void putimage(int left, int top, const void *bitmap, int op) { const uint8_t *p = (const uint8_t *)bitmap; - int w, h, x, y; + int w, h; uint8_t gop; w = p[0] | (p[1] << 8); @@ -36,23 +35,14 @@ void putimage(int left, int top, const void *bitmap, int op) if (w <= 0 || h <= 0) return; switch (op) { - case COPY_PUT: - gfx_blit_part(left, top, bitmap, 0, 0, w, h); - return; case XOR_PUT: gop = GFX_OP_XOR; break; case OR_PUT: gop = GFX_OP_OR; break; case AND_PUT: gop = GFX_OP_AND; break; - default: gop = 0; break; /* NOT_PUT — попиксельно ниже */ - } - if (gop) { - gfx_blit_part_op(left, top, bitmap, 0, 0, w, h, gop); + case NOT_PUT: gop = GFX_OP_NOT; break; + case COPY_PUT: + default: + gfx_blit_part(left, top, bitmap, 0, 0, w, h); return; } - - p += 4; - _bgi_begin(); - for (y = 0; y < h; y++) - for (x = 0; x < w; x++) - _bgi_plot_raw(left + x, top + y, (uint8_t)~(*p++)); - _bgi_end(); + gfx_blit_part_op(left, top, bitmap, 0, 0, w, h, gop); } diff --git a/libbgi/include/gfx.h b/libbgi/include/gfx.h index bfefbd6..2356c41 100644 --- a/libbgi/include/gfx.h +++ b/libbgi/include/gfx.h @@ -177,6 +177,14 @@ void gfx_blit_cols_part_wx(int x, int y, const void *img, uint8_t flip, #define GFX_OP_XOR 0xAE /* опкод `xor (hl)` */ #define GFX_OP_OR 0xB6 /* опкод `or (hl)` */ +/* NOT — приёмник = ~источник (сам приёмник в операции НЕ участвует). + * Тоже через акселератор, но другой цепочкой: у него нет режима + * «инвертировать буфер» (`CPL` автомат не распознаёт — инвертируется + * регистр CPU, а не буфер), зато ~src = src XOR #FF, поэтому вторым + * burst'ом идёт XOR по константному блоку единиц (common/_bgi_ones256.c). + * Значение выбрано вне диапазона опкодов операций — это НЕ опкод. */ +#define GFX_OP_NOT 0x01 + /* --- строками (row-major, как gfx_blit/gfx_blit_part) --- */ void gfx_blit_op(int x, int y, const void *img, uint8_t op); void gfx_blit_part_op(int x, int y, const void *img, diff --git a/tests/accop/accop.c b/tests/accop/accop.c index 825d2ef..3fdf231 100644 --- a/tests/accop/accop.c +++ b/tests/accop/accop.c @@ -1,6 +1,7 @@ /* - * accop — регресс БЛОЧНЫХ ЛОГИЧЕСКИХ ОПЕРАЦИЙ акселератора (AND/OR/XOR) - * в libbgi: приёмник = приёмник источник, строками и колонками. + * accop — регресс БЛОЧНЫХ ЛОГИЧЕСКИХ ОПЕРАЦИЙ акселератора + * (AND/OR/XOR/NOT) в libbgi: приёмник = приёмник источник, строками + * и колонками. * * ЧТО ПРОВЕРЯЕТСЯ (по байтам, а не глазами — getpixel читает ту же * ОЗУ-копию экрана, что и сам op-burst): @@ -13,7 +14,10 @@ * T7 колонками + flip (зеркало и операция должны быть ортогональны); * T8 прозрачность #FF при OR и банке 0x58: #FF | bg = #FF, запись * подавляется железом => обычный спрайтовый атлас годится для OR - * как есть (для XOR — нет, см. шапку _gfx_blit_full_op.c). + * как есть (для XOR — нет, см. шапку _gfx_blit_full_op.c); + * T9-T10 NOT (приёмник = ~источник) строками и колонками: у железа нет + * режима «инвертировать буфер», это XOR по блоку единиц — + * цепочка из трёх burst'ов со сменой HL между ними. * * Источник НЕ константный: пиксель = (col*IH + row) & 0x0F, то есть у * соседей по строке И по колонке разные значения — сдвиг на пиксель, @@ -85,6 +89,7 @@ static uint8_t want_op(uint8_t bg, uint8_t v, uint8_t op) { if (op == GFX_OP_OR) return (uint8_t)(bg | v); if (op == GFX_OP_XOR) return (uint8_t)(bg ^ v); + if (op == GFX_OP_NOT) return (uint8_t)~v; /* приёмник не участвует */ return (uint8_t)(bg & v); } @@ -156,7 +161,7 @@ static uint8_t run(int x0, int y0, uint8_t bg, uint8_t op, uint8_t kind) int main(void) { - uint8_t t[8]; + uint8_t t[10]; int i; initgraph(); @@ -183,6 +188,11 @@ int main(void) gfx_set_bank(GFX_BANK_NORMAL); t[7] = check_transp(232, 180, BG_OR); + /* T9/T10: NOT (приёмник = ~источник) — строками и колонками. Фон + * заведомо НЕ равен ~v, иначе проверка ничего не поймает. */ + t[8] = run( 8, 218, BG_XOR, GFX_OP_NOT, 0); + t[9] = run( 40, 218, BG_OR, GFX_OP_NOT, 1); + setcolor(WHITE); outtextxy(8, 8, "ACCEL block AND/OR/XOR test v1"); @@ -194,12 +204,14 @@ int main(void) say( 88, "T6 cols AND", t[5]); say(100, "T7 cols XOR flip", t[6]); say(112, "T8 rows OR transp", t[7]); + say(124, "T9 rows NOT", t[8]); + say(136, "T10 cols NOT", t[9]); - for (i = 0; i < 8; i++) + for (i = 0; i < 10; i++) if (!t[i]) break; setcolor(WHITE); - outtextxy(8, 136, i == 8 ? "ALL PASS" : "SOME FAILED"); + outtextxy(8, 152, i == 10 ? "ALL PASS" : "SOME FAILED"); - outtextxy(8, 160, "done"); + outtextxy(8, 164, "done"); for (;;) { } } diff --git a/tests/convbench/Makefile b/tests/convbench/Makefile new file mode 100644 index 0000000..ebaac3b --- /dev/null +++ b/tests/convbench/Makefile @@ -0,0 +1,3 @@ +PROJ_ROOT := $(abspath $(CURDIR)/../..) +EXAMPLE := convbench +include $(PROJ_ROOT)/app.mk diff --git a/tests/convbench/convbench.c b/tests/convbench/convbench.c new file mode 100644 index 0000000..699950a --- /dev/null +++ b/tests/convbench/convbench.c @@ -0,0 +1,111 @@ +/* + * convbench — сколько стоит на Z80 побайтная конвертация атласа + * «прозрачный #FF -> 0x00» (заготовка теневого набора спрайтов для + * XOR-блита, см. memory/accel_block_ops). + * + * Зачем: тень PoP рисуется XOR'ом, а XOR несовместим с аппаратной + * прозрачностью #FF (она смотрит на РЕЗУЛЬТАТ: #FF ^ bg = ~bg, не + * подавляется). Источник для XOR обязан хранить прозрачный пиксель как + * 0x00. Вопрос — можно ли готовить такой набор в рантайме, переписывая + * страницы атласа Кида при загрузке уровня. + * + * ОКНА: в бою источник и приёмник — РАЗНЫЕ EMM-страницы, а окно под + * атласы одно (W0), поэтому конвертация гоняется «страница-источник в W0 + * -> страница-приёмник в W3» целыми страницами по 16 КБ (переключать + * окно побайтно нельзя). На такты самого цикла это не влияет — обе + * стороны обычное ОЗУ, — поэтому здесь мерим в W2, на обычных массивах. + * + * Мерим сам горячий цикл, без обвязки: маркеры OUT в порт #FE (значение + * 0x01 до, 0x02 после) — снимаются в MAME watchpoint'ом по IO-записи с + * печатью totalcycles (memory/z80_profiling_method). Прогоняем + * BLOCKS раз по BLK байт, чтобы обвязка потерялась в шуме. + * + * Цикл — безветвочный (ветка на байт стоила бы дороже самой работы): + * прозрачный #FF отличается от цветов Кида (0x70..0x7F) битом 7, а маску + * из знакового бита даёт классическая пара ADD A,A / SBC A,A. + * + * ЗАМЕР 2026-08-11 (MAME, watchpoint по IO-записи в #FE, кадр = 430 080 + * тактов): 4 760 382 такта на 32 КБ = **145.3 такта/байт** — это 2.5× от + * 59 номинальных T-states цикла (wait-state'ы ОЗУ, memory/ + * sprinter_wait_states_2x). В пересчёте: + * 1 страница атласа (16 КБ) — 5.5 кадра = 0.11 с + * 28 страниц (весь атлас Кида) — 155 кадров = 3.2 с + * Потолок разгона этого цикла — примерно вдвое (раскрутка убирает djnz; + * чтение через SP по 2 байта + таблица 256 Б вместо ADD/SBC/CPL/AND), + * то есть ~1.5-1.7 с на весь атлас — порядок тот же. + */ + +#include +#include + +#define BLK 2048u /* байт за проход */ +#define BLOCKS 16u /* проходов (итого 32 КБ) */ + +static uint8_t src[BLK]; +static uint8_t dst[BLK]; + +/* Конвертировать pages×256 байт: #FF -> 0x00, остальные как есть. + * ВХОД (__sdcccall(1)): s→HL, d→DE, pages в A (4(ix)). Callee-pop 1 Б. + * + * Внутренний цикл — 256 байт через djnz, копия байта в C (стек стоил бы + * push/pop = 21 T на байт, недокументированные IXL/IXH не берём): + * ld a,(hl) 7 · ld c,a 4 · add a,a 4 · sbc a,a 4 · cpl 4 · and c 4 · + * ld (de),a 7 · inc hl 6 · inc de 6 · djnz 13 = 59 T/байт номинально. + * Счётчик блоков живёт в стек-слоте 4(ix) — трогается раз на 256 байт. */ +static void conv(const uint8_t *s, uint8_t *d, uint8_t pages) __naked +{ + (void)s; (void)d; (void)pages; + __asm + push ix + ld ix, #0 + add ix, sp + cv_page: + ld b, #0 ; B = 256 байт в блоке (0 => 256) + cv_loop: + ld a, (hl) ; 7 байт источника + ld c, a ; 4 копия (A нужен дважды) + add a, a ; 4 CF = бит 7 (1 = прозрачный #FF) + sbc a, a ; 4 A = #FF при CF, иначе 0x00 + cpl ; 4 A = маска «оставить байт» + and a, c ; 4 байт & маска -> 0 для #FF + ld (de), a ; 7 + inc hl ; 6 + inc de ; 6 + djnz cv_loop ; 13 + dec 4 (ix) ; блоков осталось + jr NZ, cv_page + pop ix + pop hl ; ret + inc sp ; callee-pop 1 байт (pages) + jp (hl) + __endasm; +} + +int main(void) +{ + uint16_t i; + + for (i = 0; i < BLK; i++) + src[i] = (uint8_t)((i & 3) ? (0x70 + (i & 15)) : 0xFF); + + __asm + ld a, #1 + out (#0xFE), a ; маркер «старт» + __endasm; + + for (i = 0; i < BLOCKS; i++) + conv(src, dst, (uint8_t)(BLK / 256u)); + + __asm + ld a, #2 + out (#0xFE), a ; маркер «стоп» + __endasm; + + /* Самопроверка: конвертация действительно сделала то, что обещала. */ + printf("conv %u x %u bytes\n", (unsigned)BLOCKS, (unsigned)BLK); + printf("src[0]=%02X dst[0]=%02X (want 00)\n", + (unsigned)src[0], (unsigned)dst[0]); + printf("src[1]=%02X dst[1]=%02X (want same)\n", + (unsigned)src[1], (unsigned)dst[1]); + for (;;) { } +}