libbgi: NOT_PUT тоже через акселератор + изыскания по виду Тени

NOT.  У акселератора нет режима «инвертировать буфер»: буфер меняется
только на ЧТЕНИИ и только опкодами AND/OR/XOR (HL) (драйвер MAME,
update_accel_buffer), а `CPL` автомат вообще не распознаёт — инвертируется
регистр CPU, не буфер.  Зато ~src = src XOR #FF, поэтому NOT собирается из
уже имеющегося: буфер := src, XOR-burst по константному блоку единиц
(common/_bgi_ones256.c), запись.  Ядра _bgi_blit_{rows,cols}_not_raw.c;
между burst'ами меняется HL, поэтому каждая смена — под СТОПом (иначе fetch
операнда перезапустит burst).  В колоночном варианте второй OUT Port_Y не
нужен: op-burst идёт по блоку единиц горизонтально, а Port_Y шагает только
вертикальный.

Наружу — тем же op-параметром (GFX_OP_NOT), диспетчер один раз на вызов, в
цикл по полосам/колонкам не заходит.  putimage лишился попиксельного пути
ЦЕЛИКОМ: все пять операций BGI идут через акселератор и клиппируются
одинаково.  tests/accop дополнен T9/T10 (NOT строками и колонками) —
10/10 PASS в MAME; tests/bgi_img P1/P2 по-прежнему PASS.

tests/convbench (новый) — замер побайтной конвертации атласа
«прозрачный #FF -> 0x00» (источник для XOR-блита): 145.3 такта/байт, то
есть 2.5× от 59 номинальных T-states цикла.  0.11 с на страницу 16 КБ,
3.2 с на все 28 страниц, 1.3 с по фактическому объёму данных (186 КБ).

applications/PoP/docs/shadow_render.md — вид Тени (два блиттера OR+XOR)
ОТЛОЖЕН по решению пользователя: пока рисуем обычной копией атласами Кида.
В документе собрано, почему в лоб не выходит (XOR несовместим с
прозрачностью #FF; операция читает ОЗУ-копию, поэтому два прохода
оригинала вырождаются в один XOR — нужен однопроходный композит
s | bg ^ s(сдвиг)), замер стоимости источника и четыре варианта.  Ключ к
выбору — список кадров, которыми тень реально пользуется; снимать по факту,
когда пойдут уровни 5/6/12.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-11 15:41:06 +03:00
parent a823e7ee9c
commit 860468f3c5
15 changed files with 616 additions and 35 deletions
+1
View File
@@ -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) | Запасные генераторы, если упрёмся в бюджет кадра |
+160
View File
@@ -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-цветной палитры.
+16
View File
@@ -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 уровень уже проходится, потому
что сюжетно достаточно прыгнуть сквозь зеркало.
+2 -1
View File
@@ -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
1 # Эталон размеров _CODE (байт); обновление: python3 toolchain/size_check.py --update
2 accfill
3 accop
4 argv
5 assrtest
6 atlas
20 cblwav
21 conio
22 conio2
23 convbench
24 dec_test
25 errno
26 fbench
+15
View File
@@ -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
+88
View File
@@ -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;
}
+102
View File
@@ -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;
}
+53
View File
@@ -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
};
+15
View File
@@ -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);
+8 -2
View File
@@ -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();
}
+15 -25
View File
@@ -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);
}
+8
View File
@@ -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,
+19 -7
View File
@@ -1,6 +1,7 @@
/*
* accop — регресс БЛОЧНЫХ ЛОГИЧЕСКИХ ОПЕРАЦИЙ акселератора (AND/OR/XOR)
* в libbgi: приёмник = приёмник <op> источник, строками и колонками.
* accop — регресс БЛОЧНЫХ ЛОГИЧЕСКИХ ОПЕРАЦИЙ акселератора
* (AND/OR/XOR/NOT) в libbgi: приёмник = приёмник <op> источник, строками
* и колонками.
*
* ЧТО ПРОВЕРЯЕТСЯ (по байтам, а не глазами — 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 (;;) { }
}
+3
View File
@@ -0,0 +1,3 @@
PROJ_ROOT := $(abspath $(CURDIR)/../..)
EXAMPLE := convbench
include $(PROJ_ROOT)/app.mk
+111
View File
@@ -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 <stdint.h>
#include <stdio.h>
#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 (;;) { }
}