Shaos wrote:Ну, если это все равно символный экран, т.е. маленький, можно и портами... Чтобы проводков меньше было.
Ну тогда можно и к NI-15 его присобачить
Примерный расклад такой - имеем 4 порта:
#B0 - порт управления (пока мыслится один бит 0 - обычный шрифт "0" или псевдографика "1")
#B1 - порт координаты X (допустимые значения 0...79)
#B2 - порт координаты Y (допустимые значения 0...24)
#B3 - код символа в указанных координатах (прочитать или записать)
Все порты функционируют и на запись, и на чтение. Ввиду того, что схема не будет тормозить центральный проц в случае занятости, центральный проц должен будет переспрашивать значение символа после каждой записи, чтобы убедиться, что он действительно записан:
Code: Select all
PRINT: ; B-x, C-y, D-code
MOV A,B ;5t
OUT #B1 ;10t
MOV A,C ;5t
OUT #B2 ;10t
PRINT1:
MOV A,D ;5t
OUT #B3 ;10t
IN #B3 ;10t
CMP D ;4t
JNZ PRINT1 ;10t
RET;10t
Время выполнения подпрограммы - 40+39*N тактов, где N - количество попыток записи. Вывод одного символа в лучшем случае займёт 40+39=79 тактов (или 25316 символов в секунду при 2 МГц), но с учётом того, что в пределах кадра будут "мёртвые зоны", внутри которых видеопамять будет недоступна внешнему процессору, реальная скорость будет меньше (будет больше неудачных попыток записи) - предположительно "мёртвые зоны" будут занимать 6% всего времени (это для PAL, а для NTSC больше - 7.2%).
P.S. В будущих версиях можно прикрутить автоматический инкремент координат по чтению или успешной записи символа (будет устанавливаться двумя битами в порту управления).
P.P.S. Кроме того в будущем можно вообще избавиться от "мёртвых зон" тщательно подсчитав тактирование так, чтобы заведомо более медленный центральный проц всегда попадал своими запросами на свободную видеопамять (причём без насильственного торможения центрального проца).
Для упрощения можно разрешить на чтение и запись только порт символа - остальные только на запись. К видеопамяти можно обращаться не по координатам, а по адресу в микросхеме - в этом случае не придётся ставить лишний сумматор, на вычисление адреса из координат - хотя сумматор(ы) всё равно будет, чтобы в процессе отрисовки считать смещение в видеопамяти 80*y+x = (y<<6) + (y<<4) + x. Ну и скролл можно добавить - для круглоты например поддержав 64 строки, замкнутые в кольцо (это 5Кб) и на экран выводится 25 строк идущие подряд по указанному в порту управления смещению плюс флаг разрешения записи (чтобы можно было спокойно 3 байта один за другим заполнить не вызывая порчу данных на экране по неполным координатам):
#B0 - порт управления (7й бит - разрешение записи в видеопамять, 6й бит - обычный шрифт "0" или псевдографика "1", ну и 6 младших битов - смещение экрана в строках)
#B1 - старший байт адреса видеопамяти (#00...#14 т.е. 3 старших бита остаются неиспользуемыми - поддержать в будущем цвет?)
#B2 - младший байт адреса видеопамяти
#B3 - код символа по указанному адресу (прочитать или записать)
Адрес видеопамяти из координат X и Y можно получить так (Offset это вертикальное смещение для скрола):
BigY = Y + Offset (6-битный сумматор)
Address = X + BigY<<4 + BigY<<6 (один 10-битный сумматор с 11-битным выходом и один 12-битный сумматор с 13-битным выходом)
По идее этот сложный тройственный сумматор можно реюзать и для вывода, и для записи, т.е. в портах B1 и B2 могут быть действительно координаты (причём сразу в пределах видимой области) - или слишком сложно выходит? С другой стороны наличие возможности писать и читать за пределами области прокрутки используя полный адрес позволит хранить в видеопамяти дополнительные данные (в случе 8Кб микросхемы ОЗУ это будет аж 3Кб дополнительной памяти)...
