nedoPC.org

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

В каждые 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 при поиске нужного символа в шрифте по коду - просто сразу отступаем на код символа и печатаем плашки инкрементируя старший байт в адресе (похоже именно так шрифт у Алоне расположен в памяти, но в его статье про это ни слова).

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

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

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

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

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

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

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

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

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

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