ZX Spectrum 42 символа в строке

[Lavr]

А твой старый проект ведь про программную генерацию видеосигнала на КР580ВМ80А?
Ты там можешь ведь сам только 6 битов от каждого символа выталкивать, не?

Нет, не могу... Придётся "месить", именно это я и хочу увидеть, как "месили" на Спектрум.
Пока я знаю только алгоритм от А.Волкова, который мы здесь на форуме разбирали и раскритиковали
как неоптимальный и довольно медленный...

Ну... А.Волкову, я думаю, простительно - он как тот пианист "играл как умел"... но мы-то в 2023 году уже"

[Shaos]

А где мы его здесь на форуме разбирали и раскритиковали? Я вообще не помню...

P.S. Вот сгенерил картинку с разными фонами в соседних знакоместах, чтобы было лучше видно "месилово" символов между знакоместами:

[Shaos]

Посмотрел внимательно алгоритм от Алоне - очень хитрый алгоритм, но скорее компактный, чем "быстрый":

Code: Select all

; DE - address
; A - character
; C - offset 7,5,3,1
     PUSH DE
     LD L,A
     LD B,C
     LD A,2
     RRCA
     DJNZ $-1
     LD (PRN+1),A
     LD H,'FONT
     LD B,8
PRGO PUSH HL
     LD L,(HL)
PRN  LD H,1
PR1  ADD HL,HL
     ADD HL,HL
     JR NC,PR1
     LD A,(DE)
     OR H
     LD (DE),A
     INC E
     LD A,L
     LD (DE),A
     DEC E
     INC D
     POP HL
     INC H
     DJNZ PRGO
     POP DE

Он придумал вращать символ сразу в 16-битном пространстве через ADD HL,HL !!!
Выводимый символ складывается с тем, что было на экране по OR (а второй байт просто копируется в следующее знакоместо, даже если символ полностью умещается в одном),
т.е. подразумевается, что экран был заранее очищен перед выводом (значит о выводе символа в произвольное место экрана речи не идёт).
Ну и кто-то снаружи должен вычислить закодированное смещение символа, записав его в регистр C перед каждым выводом очередной буквы.
И в одном месте программа даже модифицирует саму себя в зависимости от этого смещения
Менять значение C на входе предлагается так:

Code: Select all

     LD A,C
     SUB 6
     JR NC,$+5
     INC E
     AND 7
     LD C,A

т.е. 7 превращается в 1 потом в 3 (с инкрементом E), потом в 5 (тоже с инкрементом E) ну и потом снова в 7 (опять же с инкрементом E)
Ну и ещё надо со стороны притянуть код, превращающий экранные координаты в адрес видеопамяти (Алоне печатает в адрес, а не в координаты), например вот такой:

Code: Select all

   ;=========координаты -> scr adr========
   ;in: D - Y координата, E - X координата
   ;out:DE - screen adress
           LD A,D
           AND 7
           RRCA
           RRCA
           RRCA
           OR E
           LD E,A
           LD A,D
           AND 24
           OR 64
           LD D,A

Можно попробовать поработать с этим для получения чуть более расширенного компактного варианта, который пишет в произвольное место экрана со стиранием того, что там было...

[Lavr]

А где мы его здесь на форуме разбирали и раскритиковали? Я вообще не помню...

Железный Дровосек писал, видимо, он и снёс этот свой пост.
Но поскольку я сам тогда не разбирал процедуру вывода символа на экран, то прочитал внимательно.

Только сейчас структура экрана более близка к Спектруму, а не к Специалисту...


P.S. Я даже вспомнил где это было. Огрызок-цитата застряла здесь:
viewtopic.php?p=89033#p89033

[Shaos]

Дык тебе поди ещё и в кодах 8080 надо?

P.S. Наладил тест на скорость - буду мерять бордюром - мой алгоритм выводит 21 букву пока луч пробегает вдоль графического экрана (за весь фрейм должно быть порядка 35 т.е. весь экран выводится за чуть больше, чем полсекунды) - теперь надо замерять другие алгоритмы...

[Lavr]

Дык тебе поди ещё и в кодах 8080 надо?

Мне алгоритм интересен, а коды я и сам писать умею.

[Shaos]

Дык алгоритм зависит от системы команд - если какие-то инструкции z80 позволяют сделать что-то быстрее, то люди ради оптимизации будут использовать именно их - ухудшая понимабельность кода…

[Lavr]

Ты мне просто глаза открыл!

Я тебе отвечу взаимностью!

Алгоритм - вещь универсальная, а реализация его в кодах - аппаратно-зависимая...

[Shaos]

Не - алгоритм может быть совсем другим если скажем надо например заполнять память задом наперёд через PUSH вместо обычного заполнения от младших адресов к старшим…

[Lavr]

Не - алгоритм может быть совсем другим если скажем надо например заполнять память задом наперёд через PUSH вместо обычного заполнения от младших адресов к старшим…

Объясняю:"надо заполнить память задом наперёд" - это алгоритм, мы на понятном себе языке
уяснили задачу.

Реализация алгоритма для 8080:
1 вариант: Через MOV M,A; DCX H
2 вариант: Через PUSH ...; DCX ...

Для z80 есть еще варианты...

[Shaos]

Ну суть в том, что на процессоре, где Пуш не быстрее побайтового копирования, работать с памятью задом наперёд ненужно - т.е. там нужен будет другой (обычный) алгоритм. Я про то, что универсальных алгоритмов в общем случае небывает - надо смотреть на конкретную систему команд процессора и уже от неё плясать. Даже если речь идёт о языках высокого уровня типа Си - например в конце 90х все знали, что цикл for(i=0;i<10;i++) работает на x86 чуть медленнее, чем for(i=9;i>=0;i—) т.к. там была единая инструкция вычесть 1 и проверить на 0 (как собственно и в z80) - отсюда была необходимость менять алгоритм, если нужно…

[Lavr]

Я совсем о другом говорю - сначала нужно точно представлять конкретный алгоритм.
Т.е. чтобы самому было понятно что нужно сделать и как.

А потом дополнительно оценить ещё и обстоятельства аппаратные.

Но что-то мне писать всё неохота ибо это написано в известных книжках:

Элфринг Г. Программирование на языке ассемблера для микроЭВМ. Издательство: Радио и связь Год: 1987 Страниц: 170

Л. Левенталь, У. Сэйвилл Программирование на языке ассемблера для микропроцессоров 8080 и 8085. Перевод с английского А.А. Батнера. Москва: Издательство «Радио и связь», 1987 Страниц: 448

В данный момент алгоритм вывода 42 символа в строке с учетом аппаратных особенностей
я представляю довольно смутно.

[Shaos]

Ну что тут непонятного то?

Code: Select all

|1111 1122|2222 3333|3344 4444|

В каждые 3 байта умещается 4 символа в разрезе - соответственно надо уметь сдвигать знаки по горизонтали в 4 разные позиции:
1. буква прижата к левому краю - символ целиком влазит в знакоместо (обычно это копия буквы из шрифта как есть);
2. буква сдвинута вправо на 6 пикселов от левого края и разрезана на две части в 2 и 4 пиксела, занимая 2 знакоместа;
3. буква сдвинута вправо на 4 пиксела от левого края и разрезана на две части в 4 и 2 пиксела, занимая 2 знакоместа;
4. буква сдвинута вправо на 2 пиксела от левого края - символ целиком влазит в знакоместо.

Вращать символ можно в пределах 8 битов вправо через RRCA (4 такта на пиксел), беря затем по маске 2 части если буква расползается на 2 знакоместа (как в моём примере).
Также можно вращать символ в пределах 16 битов влево через ADD HL,HL (11 тактов на пиксел), печатая получившиеся 2 байта в видеопамять по OR (как у Алоне).
А можно сразу держать в памяти 4 копии шрифта где буквы уже повёрнуты на нужное количество бит (так я хочу сделать).

Ещё один способ ускорения (подсмотренный в одной из статей ZXDN) заключается в расположении знакогенератора в памяти не по буквам по 7 байт каждая (как в моём примере), а по разрезам - сначала первые плашки всех 256 символов, потом вторые плашки, потом третьи и т.д. до 7й плашки - в этом случае не придётся умножать на 7 при поиске нужного символа в шрифте по коду - просто сразу отступаем на код символа и печатаем плашки инкрементируя старший байт в адресе (похоже именно так шрифт у Алоне расположен в памяти, но в его статье про это ни слова).

[Lavr]

Ну что тут непонятного то?

Да я и не говорю, что непонятное что-то там, просто я пока занят аппаратной частью и программу ни одну не смотрел ещё.
За развёртку алгоритма - спасибо.

Просто у меня ещё будет трудность с позиционированием графических образов в экранном ОЗУ.
Развёртка же для упрощения программно-аппаратная, поэтому структура ОЗУ не сплошная
ну или нелинейная.
Каждый третий параграф видео-ОЗУ не отображается на экране, а формирует строчный гасящий импульс.

Я поэтому и говорю, что в целом я всю процедуру пока ещё плохо представляю.

[Lavr]

А насчёт реализации алгоритма я вот что хотел сказать.

У А.Волкова в оригинале - одна ПЗУ 2048 байт.

В ней сразу большое место занимает знакогенератор - самый обычный, на кусочки не порезанный.

Там же у него - процедура вывода символа на экран, и там же - ввод с магнитофона. Обе процедуры сложные.

Очистка видео-ОЗУ у него тоже есть, поскольку при старте в видео-ОЗУ случайные значения.

Ввод с магнитофона - это заполнение области ОЗУ байтом из порта (грубо).
Очистка видео-ОЗУ - это заполнение области ОЗУ байтом 00Н или 0FFH.
При ограниченном объёме памяти я бы, пожалуй, совместил в этих задачах указанную процедуру.

Хотя, безусловно, через PUSH ... PUSH очистка видео-ОЗУ работает быстрее, но под неё может банально
места не хватить в ограниченных условиях.