Это ТЗ на интерфейс :) - Я хочу именно так графикой управлять. Нужно же, чтобы программисту удобно было писать, а не железячнику схему разводить.

Мне вот например нравится предложение captain cobalt. Очень удобно вообще, и для спрайтов, хранимых вертикально в частности. При 256 линиях и 4х3 получается горизонталь 340.

Это предложение мне тоже нравится, только как же 340-то?
256x256 ибо не влезает 340 в 8-мибитный регистр :) .

Горизонталь 340 точек - это всего 42.5 :) байта в битплановом режиме.
384 точки - это всего 48 байт. 352 - 44 байта.

А в линейных режимах всяко придется банками щелкать (номер банка хранится отдельно).

А и плевать, что 340 в байт не влезает. Оно при таком раскладе и не особо нужно. При расположении данных в памяти вертикально, получается вплоне себе линейная адресация. Причём байт из столбца может быть как на знакоместо, так и на другие величины, на 1,2,4 пиксела например. Но тут уж памяти надо много. И для переброса 340х256@256цветов экрана за прерывание потребуется навскидку мегагерц эдак 50.
Я бы не хотел работать с битпланами, но если приглядеться преимущества могут быть и тут. Например изменяющееся число этих самых планов. ТЕ хотим ЧБ - 1, 4 цвета 2 и тд вплоть до 32бит =)

Это я прогнал :(

Да работать с 85к видеоданных в 64к адресного пространства тяжеловато :)

Если битпланы экрана расположить в разных страницах, то работать с ними можно, только быстро не получится.

Я, вот, предлагал экраны наиболее близкие к стандартному, с которыми можно работать доволно быстро, и открывать почти с произвольного места. Последнее, учитывая желание иметь многозадачную ОС на спектруме, просто не заменимо. Так каждая задача может открыть свой собственный экран, а не перекидывать данные туда-обратно в #4000 или #C000.

У меня появились некоторые соображения насчет видеоадаптера.
Многие говорили, что на спектруме удобнее перемещаться от строчки к строчке и от столбца к столбцу простым INC/DEC H/L. А что если в видеоадаптер ввести порты указателя начальной точки. затем подавать команды видеоадаптеру аналогичные INC/DEC H/L, данные записывать тоже аутом, при этом ВК будет знать в какую сторону ему перемещаться после записи данных. Также предлагаю ввести еще одну команду аналогичную PUSH POP для координат и регистры размера загружаемой области. Таким образом мы получаем чудовищное быстродействие... записав в ВК размер пересылаемой области и её координаты на экране (и указав номер видеоэкрана) мы делаем простой LDIR и данные прорисовываются быстро и красиво :-) также можно ввести регистр прозрачного цвета. и при копировании прозрачные точки будут игнорироваться. Еще можно прикрутить вместо LDIR более шуструю весч и пересылать данные еще быстрее...
Как будут работать PUSH POP: мы указываем начальную координату и кидаем в стек. потом занимаемся прорисовкой чего либо. достаем координаты со стека смещаем их куда нада опять кладем на стек рисуем дальше и так далее.
Также подумываю над тем, чтобы впиндюрить в ВК алгоритм прорисовки линий, многоугольников и окружностей, еще можно подумать над их заливкой.
Хотелось бы узнать Ваши предложения и пожелания.

P.S. работа над клоном и ВК идет полным ходом... макетная плата запаяна, байтбластер работает. Позавчера получил на мониторе 640*480*60Гц (другой кварц не нашел) и цветные полосочки :-) было приятно. По возможности скоро выложу фотки девайка и экрана который получил :-) Скорее всего это будет уже после НГ как отосплюсь.

LD (rr),A - 7T
LD (HL),r - 7T
+INC rr - 6T
Это в сумме 13Т
OUT (C),r - 12Т + автоинкремент - разница невелика, а удобство сомнительно. По поводу "PUSH/POP" - это же DMA! По остальным соображениям получается блиттер с колоркеем. Но многим нравится делать всё в софте.

стек будет организован в самом ВК :-)

Или после настройки палитры - например два слоя по 4 цвета.

Еще как получится, лишь бы руки откуда надо росли.

Ну прям себя год назад вспомнил... :)

OUT суксь, он регистр BC сожрет, да и делать сможет немногое. А INC/DEC тем и хороши, что в любой момент можно сменить направление, юзать любой динамически вычисляемый шаг, выборочное стирание/заливка текстурой, выборочное чтение с экрана с проверками итд - что в башку взбредет.

Всего лишь небольшой прирост за счет оптимизации работы с регистрами (меньше сохранений/перезагрузок). Да и то еще не факт.

Зачем тут ldir? Куда он писать будет половину рабочего времени?
Тогда уж давать команду ВК схавать N следующих байт с ШД (кроме циклов M1), загнать в SP указатель на блок и N/2 раз выполнить POP.

DMA называется. В продвинутом варианте - правильно, блиттер.

Зачем обратно вытаскивать-то? Хто "смещает"? При перекачке данных чисто процессором смысла не вижу. Вот для блиттера была бы полезная штука, но только там не стек нужен, а очередь (и какой-то стандартный формат блиттерных команд).

Даже куча реализованных "в железе" возможностей не оправдают неудобную раскладку экрана и разрешение "от фонаря". На блочных пересылках и векторной графике свет клином не сошелся, Спек - не приставка.