Вектор-06Ц, 580хх на ПЛИС

[KTSerg]

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

Не совсем так.
Возврат из прерывания это команда, когда она закончится, процессор должен будет прочитать новую команду, а как ему объяснить, что команду вот именно сейчас читать не нужно, что она уже выполнялась, и что её нужно просто продолжать выполнять, причём с определённого места.
В крайнем случае. Можно подумать о дополнительном флаге (для модифицированной команды) выполнения команды. Если модифицированная команда читается, но флаг был не сброшен (предыдущим штатным окончанием выполнения этой команды), значит её выполнение было прервано, и нужно продолжить выполнять с текущего состояния счётчиков. А "РС" держать с самого начала на повтор этой команды, и только после успешного окончания переводить его на следующую команду.
Нужно перевариваь...

[Advertiser]

[ivagor]

Когда речь пошла о команде, то я воспринял это примерно как навороченный LDIR с соответствующими выводами.
Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.

[KTSerg]

Когда речь пошла о команде, то я воспринял это примерно как навороченный LDIR с соответствующими выводами.

Ну, подобие LDIR я первым делом реализовал. Выше скриншот теста скорости вывода спрайта 24х24х3 это именно с этой командой.

Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.

Варианты с DMA я пока морально не готов рассматривать.
Предполагался некий вариант LDIR, который не ограничивается одним байтом за раз, а выполняется пока не обработает весь спрайт с учетом строения экрана Вектора. Это ускоряет процесс как минимум на 25-30%% , так как не требуется чтения кода команды, для обработки следующего адреса.
Но при этом возникают "заморочки" с прерываниями.
Пока отложу эту версию, до переваривания.

[ivagor]

Оффтопный пример про то, насколько ускоряется выполнение всей задачи при оптимизации одной команды

Решил сравнить в рамках вектора, что даст быстрое умножение шринклеру (на примере распаковки теста устройств). Для этого добавил в z80 (emu80) команду MULUW HL,BC из R800. Оригинальный распаковщик для z80 - 1 минута 11 секунд. Распаковщик для R800 - 25 секунд. Т.е. ускорение распаковки в 2.84 раза, при том что умножение быстрее более чем на два десятичных порядка (MULUW не стал тормозить до 36 тактов как в R800, сделал 8 тактов).

[свернуть]

[KTSerg]

Как-то так получилось:
https://disk.yandex.ru/i/QVrF9rpCvF-VnA
96 символов, если не сбился.
Без использования стека.

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

[svofski]

Как-то так получилось:
https://disk.yandex.ru/i/QVrF9rpCvF-VnA
96 символов, если не сбился.
Без использования стека.

По одной фотке не совсем понятно -- на что именно мы смотрим? Это работает ПЛИС-ный 8080 с какими-то дополнительными инструкциями?

[KTSerg]

По одной фотке не совсем понятно -- на что именно мы смотрим? Это работает ПЛИС-ный 8080 с какими-то дополнительными инструкциями?

Да, инструкции читают, накладывают маску, складывают с данными спрайта, записывают обратно, сдвигают указатели.
Для упрощения, две инструкции. Одна со смещением указателей вверх, вторая - вниз.

- - - Добавлено - - -

Хороший результат, стоит посчитать и достижимый максимум. Пусть в символе 8 строк и шрифт хранится внутри ПЛИС, 2 Кб не так уж много. На одну строку 2 чтения и 2 записи VRAM. Плюс на каждый символ одно чтение кода символа. ((2+2)*8+1)*4=132 такта/символ, за прерывание 453 двухцветных символа в режиме высокого разрешения.

Намекаешь на эксперимент с разворачиванием всех циклов в линейный код?
Чтение кода символа в 1 цикл - это жесткач если учитывать, что даже "inr r" - это 8 тактов.
Единственный выход это типа "add a,r" - держать один регистр для "1".
Плюс смещение позиции на экране.
В одно знакоместо может и получится 453, но идентифицировать результат не получится.

[ivagor]

Хороший результат, стоит посчитать и достижимый максимум. Пусть в символе 8 строк и шрифт хранится внутри ПЛИС, 2 Кб не так уж много. На одну строку 2 чтения и 2 записи VRAM. Плюс на каждый символ одно чтение кода символа. ((2+2)*8+1)*4=132 такта/символ, за прерывание 453 двухцветных символа в режиме высокого разрешения.

[ivagor]

Пардон, я привел расчет только для удобного случая. Для неудобных будет ((4+4)*8+1)*4=260 тактов. "Удобных" 6/8, неудобных - 2/8 (это если 80 символов в строке), поэтому 132*6/8+260*2/8=164 такта/символ в среднем. Уточненный максимум - 365 символов за прерывание.

- - - Добавлено - - -

Намекаешь на эксперимент с разворачиванием всех циклов в линейный код?

Это теоретический максимум исходя из пропускной способности шины. Способы достижения могут быть разные, например "высокоинтеллектуальный DMA-сопроцессор".

- - - Добавлено - - -

Если в плисине есть еще 16 Кб под копию VRAM, то убираем с внешней шины процессора чтение VRAM и получаем 713 символов/прерывание, это абсолютный максимум, быстрее не получится.

[KTSerg]

Хотелось развёрнутых циклов...
Распишитесь в получении:
https://disk.yandex.ru/i/_o63DMADDFux1A
Что тут... 225 символов получилось.

Это без модификации текущего ПЛИС.
Просто в тестовой программе, только вывод символов, без подпрограмм, ветвлений, проверок.
Минимальная обвязка только смещение координат на экране, увеличение кода символа.

Да, ещё, не стал в одну команду пикать вывод всего спрайта. Соответственно, выбрал самый затратный, но простой для реализации вариант - одна команда на один байт. Соответственно, только на чтение/запись одного символа тратится не 32 (или 64) цикла, а с командой 48 (или 96) циклов (если в подсчётах не ошибся).