Можно прикинуть сдвиг всего экрана на 1 точку. 256 х 192 байт /56 МГц = 878 мкс.
Для управления мелкими объектами надо оптимизировать интерфейс с Z80.
Вид для печати
Он будет пытаться работать со скоростью 112 Мбайт в секунду, но его иногда будут отвлекать сканер для вывода на телевизор и Z80 с загрузкой команд команд. То есть скорость будет около 56 Мбайт в секунду.
Теоретически можно еще немного ускорить работу. 14 МГц * 4 = 56 МГц, 14 МГц * 6 = 84 МГц, 14 МГц * 8 = 112 МГц. Но больше 100 МГц память работать не сможет.
---------- Post added at 22:29 ---------- Previous post was at 21:40 ----------
Скорее всего вы пишете 1,2,3 не сразу в первый атрибут, а сначала 1 во второй и т.д. Вы ведь не пишите команды типа:
LD #5800,1
LD #5800,2
LD #5800,3
Если запись была в другой адрес, или следующее число не равно ожидаемому в последовательности - автомат включения нового режима должен сбрасываться в исходное состояние. Но я исправил числа на рекомендуемые вами.
А почему?
То есть, машины с 3,5 Мгц и 7 Мгц идут лесом?
Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.
Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.
Имелась ввиду частота кварца в компьютере, которая выводится на шину ZX-BUS для тактирования видеокарты, исправил - частота кварца в клоне должна быть ровно 14 МГц. Нам ведь надо на телевизор сигнал кратно этой частоте формировать. А если будет 16 МГц, как у некоторых клонов, то синхронизации не будет.
Лучше порты не занимать - их итак свободных не осталось. Почти нет программ, которые запишут подряд в одну ячейку по адресу атрибутов три нужных байта. Это бессмысленно, так как человек не успеет заметить такое быстрое изменение цвета. Да и сканер при выводе на TV сможет прочитать только один из трех в заданный момент.Цитата:
Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.
Возврат к стандартному экрану можно сделать при записи другой последовательности байтов в эту же ячейку. Чтение из видеокарты не планировалось, чтобы не конфликтовать с памятью и портами компьютера. В крайнем случае через порт #FF, так как он будет формироваться видеокартой только для стандартного экрана ZX SPECTRUM.Цитата:
Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.
Не знаю... Как-то не по уму оно, через память. Спонтанная мысль: может, через последоватетельность хитрых out'ов в #7ffd при включенном экране-1 (+ память)? Если через ZX-BUS можно "заблокировать" блокировку #7ffd, было бы вообше рульно, например, карта переходит в нужный видеорежим если при включенном экране-1 блокируется порт #7ffd. :)
Кстати, видеокарта должна стать единственным видеовыходом компа же, так? Значит, второй экран 128-го будет тоже на ней?
В принципе,
можно и обойтись без чтения z80 из ОЗУ видео-карты.
Так что это не смертельно.
Но некие статусные биты, z80 должен уметь читать.
Например,
бит занятости блитера (занят/не занят)
(Т.к. выдавать новую команду блитеру, можно будет только тогда, когда блитер не занят.)