Да, именно так. Вопрос в том, заработает ли в реальном векторе ядро T80 (для начала в режиме 8080). В рамках v06cc я включал z80 просто изменением одной настройки (Mode), шина оставалась 8080 и все работало. Для реала, как мне представляется, придется доработать только один момент - адресацию портов, продублировав в верхней половине ША нижнюю половину.Сообщение от KTSerg
Прикинул, если упаковать в одну команду вывод одного спрайта на экран, то даже для вывода одного спрайта 8х8х4, потребуется порядка 260 тактов...
А если верить даташиту i8080, то проверка запроса прерывания происходит в последнем цикле каждой команды.
Значит, скорее всего при выполнении такой "модифицированной" команды (вывода спрайта одной командой), запрос на прерывание скорее всего будет потерян. Что не есть зер гуд...
Так там и нет команд вывода спрайтов. А при реализации в плис никто не может помешать проверять запрос прерывания например после каждой записи байта в память.
- - - Добавлено - - -
Насчет потери прерываний. Насколько я понимаю схему вектора, там ничего не потеряется, даже если будет команда на 20000 тактов. Другое дело, что к тому времени пройдет интервал пригодный для всяких темных делишек типа опроса клавиатуры и программирования палитры, скорее вот это ограничивающий фактор.
Я об этом думал. Но не уверен, что после возврата из прерывания удастся вернуть состояние всех потрошков в тот вид, который был у них в момент прерывания процесса. Для модификации команд ведь приходится, что-то "корявить". В Векторе вроде нет специальной команды, которая завершает прерывание. А если в программе используется для этих целей не просто "ret", а "pchl" к примеру... тогда понять, что нужно вернуться к продолжению прерванной операции, будет ещё сложнее, если вообще возможно.
Это не техническая сложность, не принципиальная проблема, это вопрос аккуратной разработки. Адрес откуда читаем (или два адреса, если графика и маска отдельно), адрес куда пишем, счетчик. Приход прерывания во время такой долгой команды должен приводить к помещению в стек ее (этой команды) адреса, состояние регистров - как обычно, если обработчик прерывания корректный, то он сохраняет то, что сам меняет. И возврат приведет к корректному продолжению.
Не совсем так.
Возврат из прерывания это команда, когда она закончится, процессор должен будет прочитать новую команду, а как ему объяснить, что команду вот именно сейчас читать не нужно, что она уже выполнялась, и что её нужно просто продолжать выполнять, причём с определённого места.
В крайнем случае. Можно подумать о дополнительном флаге (для модифицированной команды) выполнения команды. Если модифицированная команда читается, но флаг был не сброшен (предыдущим штатным окончанием выполнения этой команды), значит её выполнение было прервано, и нужно продолжить выполнять с текущего состояния счётчиков. А "РС" держать с самого начала на повтор этой команды, и только после успешного окончания переводить его на следующую команду.
Нужно перевариваь...
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Я описал вариант, при котором ничего ему не надо специально объяснять. Он после прерывания читает команду "как в первый раз", но в регистрах уже текущие значения, поэтому продолжит выполнять дальше. Т.е. выполнение команды разобьется на две части - до прерывания и после.
Я прикидывал, что именно в первом цикле команды, когда считывается код команды, происходит инициализация (дополнительных счетчиков, флагов, признаков), и чтение характеристик спрайта.
Если выполнение команды, разрывалось прерыванием, и после возврата из прерывания, снова выполнится чтение кода команды, то без дополнительного указателя, снова произойдёт инициализация вывода спрайта, только уже в новых адресах, в текущих указателях hl, de, bc.
Когда речь пошла о команде, то я воспринял это примерно как навороченный LDIR с соответствующими выводами.
Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.
Ну, подобие LDIR я первым делом реализовал. Выше скриншот теста скорости вывода спрайта 24х24х3 это именно с этой командой.
Варианты с DMA я пока морально не готов рассматривать.Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.
Предполагался некий вариант LDIR, который не ограничивается одним байтом за раз, а выполняется пока не обработает весь спрайт с учетом строения экрана Вектора. Это ускоряет процесс как минимум на 25-30%% , так как не требуется чтения кода команды, для обработки следующего адреса.
Но при этом возникают "заморочки" с прерываниями.
Пока отложу эту версию, до переваривания.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
