Это ТЗ на интерфейсСообщение от Sonic
- Я хочу именно так графикой управлять. Нужно же, чтобы программисту удобно было писать, а не железячнику схему разводить.
Это ТЗ на интерфейс
Мне вот например нравится предложение 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.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
У меня появились некоторые соображения насчет видеоадаптера.
Многие говорили, что на спектруме удобнее перемещаться от строчки к строчке и от столбца к столбцу простым 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 называется. В продвинутом варианте - правильно, блиттер.
Зачем обратно вытаскивать-то? Хто "смещает"? При перекачке данных чисто процессором смысла не вижу. Вот для блиттера была бы полезная штука, но только там не стек нужен, а очередь (и какой-то стандартный формат блиттерных команд).
Даже куча реализованных "в железе" возможностей не оправдают неудобную раскладку экрана и разрешение "от фонаря". На блочных пересылках и векторной графике свет клином не сошелся, Спек - не приставка.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
