Новый графический режим для игр

[Valen]

Да и метр статики это две микросхемы.

А если 512КБ статики, меньше чипов ?

Наверно лучше сделать карту немного помедленнее, без статики. Да и метр статики это две микросхемы. Громоздко было бы. И портировать на Speccy2010 и ReVeRse было бы труднее. А так, если у ReVeRse входные такты тоже 20 МГц, как у Speccy2010, то и на видеокарту надо поставить тоже самое.
Возможности закрасить экран три раза за кадр должно хватить. Не так быстро, зато останется совместимость.

ИМХО, какая-то "мифическая" совместимость.
Получается сами себе порезали возможности карты.


Вообщем, решать конечно автору.
Может он и прав.
Схема то точно будет попроще, если без статики.

[zx-kit]

Надо, чтобы была максимальная совместимость, иначе 30 быстрых карт, которые я смогу сделать будут без программного обеспечения. Желательно, чтобы была совместимость и с TS-LABS. Надеюсь он не будет сильно разгонять свою видеокарту, чтобы не остаться один.
Если есть совместимость. можно будет писать новые игры в эмуляторе и она будет работать на перечисленных компьютерах и видеокартах. Должен быть какой-то стандарт. И этим стандартом я предлагаю сделать новый режим графики.

[Valen]

Надо, чтобы была максимальная совместимость

Хорошо.

SDRAM будет один чип или два ?
На какой частоте ?

[zx-kit]

Сколько байтов нужно для адресации точки в SDRAM 8Mбайт ? Нам понадобится группировать тайлы и спрайты одинакового размера в банки по 256 шт. У каждого банка есть описание: адрес начала, ширина спрайта, высота спрайта и номер. Тогда при печати тайлов травы надо выбрать определенный банк. После этого не надо будет указывать размер и достаточно будет однобайтного номера тайла в банке тайлов.

---------- Post added at 17:08 ---------- Previous post was at 17:05 ----------

Хорошо.

SDRAM будет один чип или два ?
На какой частоте ?

SDRAM один чип. Частота 84 MГц. Может быть максимум 112 МГц. Желательно кратно 14 МГц. Если будет ПЛИС, то можно будет поставить PLL как в ZX-EVO. Если FPGA - то кварцевый генератор, например, на 100 МГц. Надо спросить у специалистов: MVV, TS-LABS.
Если ПЛИС - EPM1270ATC144, если FPGA - EP2C5Q208.

---------- Post added at 17:32 ---------- Previous post was at 17:08 ----------

Для адресации до 16 M хватит трех байтов адреса.

[MVV]

zst, за 2к сделать что-то быстрее и лучше чем ordroid-w вряд ли получится, уже проще его и прикручивать через gpio, но здравого смысла в этом нет, т.к. делать всё за спек он умеет сам.
Идея сделать новую видео карту/видео режим, сама по себе не плохая, по крайней мере можно чему-то да и научиться, а иначе зачем всё это?
В начале всегда трудно определиться и решить с чего начать. Возможность реализации видео режима на zx-evo, speccy2010, reverse, de1... это уже хорошее начало.
Вот, на мой взгляд простое железо карты:
Слот подключения: ZX-Bus, Nemo-Bus, uBUS. Transceiver 74LVC16245A (опция)
Видеоинтерфейсы: VGA, HDMI (опция)
Память: SDRAM 4 Mбайт х 16 бит (опция)
FPGA: EP4CE6E22C8N (опция)
Конфигурация: M25P40 (опция)
GPIO: PS/2, SPI, SD Card, Delta sigma stereo (опция)

Универсальность: DivMMC, TurboSound, GeneralSound, SounDrive, Z-Controller...

[zx-kit]

zst, за 2к сделать что-то быстрее и лучше чем ordroid-w вряд ли получится, уже проще его и прикручивать через gpio, но здравого смысла в этом нет, т.к. делать всё за спек он умеет сам.
Идея сделать новую видео карту/видео режим, сама по себе не плохая, по крайней мере можно чему-то да и научиться, а иначе зачем всё это?
В начале всегда трудно определиться и решить с чего начать. Возможность реализации видео режима на zx-evo, speccy2010, reverse, de1... это уже хорошее начало.
Вот, на мой взгляд простое железо карты:
Слот подключения: ZX-Bus, Nemo-Bus, uBUS. Transceiver 74LVC16245A (опция)
Видеоинтерфейсы: VGA, HDMI (опция)
Память: SDRAM 4 Mбайт х 16 бит (опция)
FPGA: EP4CE6E22C8N (опция)
Конфигурация: M25P40 (опция)
GPIO: PS/2, SPI, SD Card, Delta sigma stereo (опция)

Универсальность: DivMMC, TurboSound, GeneralSound, SounDrive, Z-Controller...

Я тут прикидывал, если во 2 циклоне 142 I/O, то -90 = 52. Вывести их на гребенки. Может получится какой-нибудь контроллер SD-CARD подключить. Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?

Можно ли сделать в ReVeRse выход VGA с частотой точек 14 МГц ?

[MVV]

Я тут прикидывал, если во 2 циклоне 142 I/O, то -90 = 52. Вывести их на гребенки. Может получится какой-нибудь контроллер SD-CARD подключить. Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?

Я бы в начале попробовал бы всё как можно оптимально ужать. Не делать же новый speccy2010? Наличие sd card, delta-sigma, ps/2... вкус не испортят, на то она и опция. Узкое место это VGA(18 выводов) и ZX-Bus/Nemo-Bus (без оптимизации нужно 43 вывода FPGA). Можно отказаться от VGA в пользу HDMI (минимально нужно 8 выводов всего, разница впечатляет - 24bpp против 15bpp).

Можно ли сделать в ReVeRse выход VGA с частотой точек 14 МГц ?

Можно.

[ZX_NOVOSIB]

Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?

ага, ограничение TR-DOS дискеты 640 кб. Если применить нестандартный формат, то вроде бы можно еще несколько десятков кб выиграть.

---------- Post added at 19:29 ---------- Previous post was at 19:27 ----------

хотя игра Черный Ворон вообще на двух дискетах шла, и никто не возражал ))

[Lethargeek]

Когда Диззи переходит в другое место надо нарисовать картинку/фон, а потом Диззи. На приведенной картинке видно, что она рисуется из нескольких типов маленьких картинок-квадратиков размером 8х8 точек.

Из картинки это не очевидно. Не скажу именно за Диззи, но часто и прямоугольники разного размера сразу печатают.

Нарисуем на черновике область размером 32х24 клетки и пронумеруем каждую клетку номером тайла. Теперь нам надо изобразить эти тайлы на экране...

Ну зачем такое, не понимаю. Почему ты упорно хочешь блиттер кастрировать? Зачем жёстко сетка и мелкотайлы зафиксированного размера? Зачем делать неуниверсально и явно то, что само получается неявно по общей схеме?

Нужно определиться с количеством байтов на каждый параметр. LY, LX, К - по одному байту, Y, X, N - по два (YH, YL, XH, XL, NH, NL). Тут все понятно.

Блиттеру простому для переброски произвольного прямоугольного блока нужны только следующие параметры:
- способ наложения (или код прозрачного в простом случае)
- длина общая перебрасываемого блока
- длина "строки" блока
- приращение в конце строки для источника
- приращение в конце строки для приёмника
- адрес источника
- адрес назначения
Все параметры прошлой операции запоминаются, все записи параметров идут в буфер, а переброска может запускаться автоматически при получении полного адреса приёмника (или проще - только старшего байта). Так что если захотелось всё-таки порисовать мелкотайлами одинакового размера, после первого (с полным описанием всех параметров) можно только адреса-параметры изменять. В том числе, возможно, и процедурой, номера преобразующей в адреса. Но, по-моему, экран в формате списка пар "параметр, значение" в общем случае места занимать будет меньше и отрисовываться быстрее. И само собою, лучше смотреться.

Но нужно проработать эффективную систему для записи команд в видеокарту. Мы можем выделить 256 разных адресов для разных команд или подавать их все через один адрес, чередую КОМАНДУ и ДАННЫЕ или передавать КОМАНДЫ и ДАННЫЕ с помощью команды LDIR через область 256/512 байт. Какой способ лучше ?

Чередуя, ты "командой" выбираешь адрес порта фактически. То же самое, как записью в разные адреса, только медленней и не запоминаешь в обычной памяти. Лдиры, кстати, не нужны при правильной организации отрисовки, часто шевелить необходимо только несколько байт.

И повторю, для простой и быстрой переделки существующих игрушек нужно, чтоб стандартный спектрумовский экран незаметно и "прозрачно" для оригинального кода отображался в новый цветной экран (что позволит переделывать игры постепенно до любой степени). А не разные видеорежимы несовместимые с обязательной полной перекраской-перерисовкой.

[Sayman]

Блиттеру простому для переброски произвольного прямоугольного блока нужны только следующие параметры:

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