Быстрая видеокарта "METEOR-2013"

[Nesser]

Nesser, Captain Drexx

длина кодового блока - 10271 байт
это без буферов и уровней, без музык, график и прочей херни
но, естественно, с dup-ами, текстами и переменными

- - - Добавлено - - -

zst, ходят слухи что в фениксе ZX-BUSа нету

Ого, дефендер, не видел если честно

Нууу с видеокартой то DUPы не нужны даже если кодовый блок+текст+переменные и будет на 16 кБ этого точно хватит, тем более в прямом доступе то 48 кБ
Я уж и не знаю что можно запихать в 48 кБ если графика, звуки и музыка находятся в теневых страницах

[Sayman]

уж и не знаю что можно запихать в 48 кБ если графика, звуки и музыка находятся в теневых страницах

запихнуть можно много чего. например, если игрулина аля Вольф (например, как версия для АТМы), то только для каждого масштаба (64 масштаба) своя отдельная процедура (т.е. 64 процедуры в случае с версией для АТМ которые занимают 14801 байт). ну и остальной код тоже там довольно не малый. И если карта сама не умеет в масштабы, то и 48кб может быть очень и очень впритирочку...

[Nesser]

запихнуть можно много чего. например, если игрулина аля Вольф (например, как версия для АТМы), то только для каждого масштаба (64 масштаба) своя отдельная процедура (т.е. 64 процедуры в случае с версией для АТМ которые занимают 14801 байт). ну и остальной код тоже там довольно не малый. И если карта сама не умеет в масштабы, то и 48кб может быть очень и очень впритирочку...

Зачем такой шнягой CPU напрягать, да ещё и кучу видов одного и того же спрайта хранить ?
Масштабирование это проблема видеокарты, всё равно уже стоит ПЛИС, для справки скажу что все видеокарты изначально разрабатываются на ПЛИС и когда уже всё обкатано тогда уже переводят на штамповку.
Если начали делать так делать надо уже нормально.
Изначально нужна КОНЦЕПЦИЯ, то есть для чего вообще делать то видеокарту, не надо гнаться за суперпупер цветами и разрешениями, надо простое и уникальное решение для СЛАБОГО процессора, без всяких SDK, RISC и прочей дребедени.

Все эти масштабирования примитивно решаются в логике, крутить углы по сути тоже фигня, и портянку с текстурой можно вывести X1,Y1,X2,Y2, не сложно же реализуется.

И да, не вижу ничего зазорного если Z80 сделать на плис в виде 40 ногой панельки, поменять можно в любом zx-spectrum, одно время даже некоторые заводы (на заказ) шлёпали кристаллы плис в любой корпус, так же пихали и в 40 DIP, сейчас не знаю, наверное не выгодно.
Разве это плохо если LDIR будет не 21 такт а 1-2 такта? а в дополнение к ADD и SUB будет MUL и DIV ?

Я не работал с ПЛИС но на рассыпухе могу собрать что угодно, надеюсь скоро окончу текущие "проекты" с PICами (надо для заработка) и сяду ПЛИСины курить, не думаю что там всё сложно.
Но здесь же есть уже готовые спецы по ПЛИСинами, скажите, разве нельзя наваять всё это и что бы программно это обслуживалось как можно проще?
тс-конф перехватывает команды CPU, отлично, это правильное направление, в плис напихали и видео и ВСЁ ОСТАЛЬНОЕ.....это НЕПРАВИЛЬНО, видео должно быть ПОЛНОЦЕННЫМ, если надо 24 ноги для цап значит должно быть 24 ноги а не 6.
ВСЁ ОСТАЛЬНОЕ должно быть в ДРУГОЙ плис.
Нууу и так далее, вся система должна быть собрана в одну КУЧУ, а сейчас это кубик рубик который априори в правильное положение НЕ СОБИРАЕТСЯ.
Одной только видеокартой ничего не исправить.
Нужна концепция и пробы пробы пробы.

[Hacker VBI]

Nesser, с-конф НЕ перехватывает команды CPU.
в тс-конф - отдельные порты на всё необходимое.

[Nesser]

Nesser, с-конф НЕ перехватывает команды CPU.
в тс-конф - отдельные порты на всё необходимое.

Значит я ещё с чем то намешал
В какой то штуке LD H,H LD L,L и подобное вроде перехватывалось.
Но опять же, тс-конф это плис, всегда можно доработать, вот только видеоDAC уже не полноценным получился, материнку надо править

[Hacker VBI]

Nesser, вDAC решает заложенную в архитектуре проблему вывода цвета, не более.

[Sayman]

Nesser, ты не понял. 64 масштаба не спрайтов, это 64 процедуры. 1 процедура выдаёт тебе 1 масштаб для текстуры/спрайта. нет потребности хранить 64 копии в разных масштабах на 1 текстуру. чтобы честно видяхой это делать, она должна уметь делать сама масштабирование. для спринтера есть конфа с аппаратным масштабированием (хз как её подключать, не разобрался).

тс-конф перехватывает команды CPU

команды умеет перехватывать Спринтер, а не ТС. именно так и работает аксель.

LD H,H LD L,L

ld h,h - это "удвоение байта" (должно было быть, может и есть, не проверял)
ld l,l - копирование...

[Nesser]

-----------------------------
Ээээээээ погодите ка, по поводу метеора.

А как вы собрались буфер вывода делать? Типа сканер выводит изображение на экран и я в это же время там всё перерисовываю и двигаю? а как же временный буфер на 1 кадр?

- - - Добавлено - - -

Nesser, ты не понял. 64 масштаба не спрайтов, это 64 процедуры. 1 процедура выдаёт тебе 1 масштаб для текстуры/спрайта. нет потребности хранить 64 копии в разных масштабах на 1 текстуру. чтобы честно видяхой это делать, она должна уметь делать сама масштабирование. для спринтера есть конфа с аппаратным масштабированием (хз как её подключать, не разобрался).

команды умеет перехватывать Спринтер, а не ТС. именно так и работает аксель.

ld h,h - это "удвоение байта" (должно было быть, может и есть, не проверял)
ld l,l - копирование...

-----
Ааа теперь понятно, это у меня всё в голове намешалось видимо потому что нет нормально оформленной документации и на то и на то.

Да если такой мешок логики уже поставили на плату то естественно все масштабирования должна делать эта логика, иначе какой смысл ставить тысячи микросхем логики в 1 корпусе и продолжать всё делать программно, зачем

У нас процессор CISC, значит и всё что навешиваем должно быть сделано по такому же принципу, пусть не быстро но уверенно.

[zx-kit]

Описание концепции, характеристик, переменных видеокарты собрал в 1 пост.

[Smalovsky]

Мои соображения насчёт новых регистров и блиттера. Ошибки в тексте есть)).
Предлагаю следующие регистры:
accel_mode - выбор аппаратного ускорения: 0 - через регистр данных, 1 - БЛИТТЕР.

out_mode - режим вывода: 0 - вывод через регистр данных или блиттер, 1- режим ластика;
В режиме ластика при выводе через регистр данных запись любого значения в регистр данных приводит к к заполнению области вывода цветом очистки, при выводе блиттером область вывода заполняется цветом очистки.
out_control - регистр контроля. При выводе через блиттер, значение нулевого бита: 0 - пересылки нет( устанавливается после пересылки), запись 1 - начать пересылку; значение первого бита: 0 - данные из памяти брать последовательно, 1 - данные из памяти выравнивать в соответствии с регистрами dxl, dxh, dyl, dyh, alignment_value( этот режим работы блиттера полезен, когда нужно переслать подготовленную в памяти компьютера теневую область). При выводе через регистр данных, значение нулевого бита устанавливается и сохраняется значение 1 при последовательной записи значений в регистр данных, запись 0 приведёт к сбросу последовательного вывода и дальнейшее заполнение области вывода будет происходить сначала; значение первого бита игнорируется.
Пары регистров clear_color_1_h:clear_color_1_l .. clear_color_1_h:clear_color_1_l - двубайтное значение цвета очистки для каждого слоя с учётом значений прозрачности.
data_format - формат данных для вывода через регистр данных или блиттер:
0 - двуцветный вывод двумя первыми служебными цветами;
1 - двуцветный вывод двумя первыми служебными цветами с учётом маски;
2 - вывод служебными цветами;
3 - ВЫВОД ДВУБАЙТНЫМ ЗНАЧЕНИЕМ ЦВЕТА С УЧЁТОМ ПРОЗРАЧНОСТИ. Запись в регистр данных при таком формате последоватиельна - побайтово передаётся значение цвета.
alignment_value - значение ширины строки по которому происходит выравнивание данных блиттером при считывании данных из памяти.
bl_status - статус пересылки данных блиттером: 0 - пересылка закончена, 1 - пересылка идёт.
Пары регистров bl_addr_h:bl_addr_l - задают начало пересылаемой блиттером области данных внутри страницы( для регистра bl_addr_h биты 7 и 6 игнорируются).
bl_num_page - номер страницы в которой начинается область данных пересылаемой блиттером.
Адрес назначения во внутренней памяти видеокарты при пересылке блиттером вычисляется автоматически исходя из значений регистров xl, xh, yl, yh. Блиттер сам выравнивае выводимые данные в области вывода и определяет количество пересылаемых байт используя значения регистров dxl, dxh, dyl, dyh. Другими словами - со стороны памяти компьютера данные можно брать с выравниванеием или последовательно, а со стороны области вывода данные выводятся с выравниванием автоматически.
Соглашение о выводе через регистр данных:
Последовательная запись значений в регистр данных приводит к последовательному заполнению области вывода, определяемую регистрами xl, xh, yl, yh, dxl, dxh, dyl, dyh. Перезапись одного из перечисленных регистров приводит к началу последовательного вывода в начало новой области вывода. Что бы сделать сброс последовательного вывода и вернуться к выводу в начало области вывода не переопределяя последнюю - необходимо воспользоваться регистром out_control.

- - - Добавлено - - -

Если блиттеру дать команду скопировать область размером 224*256*2=114688 байт - экран в непосредственном режиме данных, то сколько времени будет происходить копирование?