Простенькая видеокарта для 8 бит поделок.

[Totem]

основа тут менеджер памяти
который отключает доступ процессору(худший/простой случай) к основной памяти, в СPU0 -1, ( с градацией 8-16-24-32КБ) , т.е сами выбираем сколько у нас под видео память из младших 32K, видяхе "говорим", отображать VRAM1, она отключает VRAM0 от своих шин и включает в адресное пространство процессора. Все, процессор пишет/читает VRAM0, не трогая основную память, (ROM мы тоже отключили (BLK)).
Нарисовали, "говорим видяхе", сделать страницу VRAM0 отображаемой. та ОК, и включает для CPU VRAM1.
Самый интересный случай, когда 256x192 16 цветов 24КБ памяти, нужно место под графику.
хорошо, "говорим менеджеру" мы будем только читать из СPU0, "видяхе" мы будет только писать и включаем в СPU0 одну из 8 страниц расширенной памяти, куда уже загрузили графику, ну или наоборот
собственно сам менджер для понимания

.потому "простата" (гусары, молчать!)

Упс

достаточным "навсегда" явился бы девайс со своей видеопамятью на 16-битной шине (одно слово на один пиксель),

16 бит шина, эта замечательно, но сколько ее должно быть и какая? sdram это pll значит - опять циклоп. без CPLD/FPGA тут делать нечего.
DRAM это "рефрешь" и 8-10 Mгц без ожидания GPU, ну fast page или edo чуть лучше и быстрее, все одно по строкам работать и меньше ног.
как хранилище для графики пойдет . из 2 sram 8 бит делаем одну 16 бит. получаем по 64КБ 2 VRAM- 320x240x256. и DRAM EDO для
графики и блитера.
мало?
Или берем циклоп 2-3 набиваем его до отказа sram 16 бит ? или SDRAM ?

У меня пока нет мыслей кроме ULA,как улучшить графику для ZX, достаточно простым и не дорогим решением.
отслеживать запись в видео озу ZX? делать "микс" из атрибутов и уже заготовленной в VRAM карты 16 бит "поллитре."?

Адресация должна быть переключаемой. Формат данных (пикселей) тоже. Причём "на ходу" и без потери картинки.

да это идеальный вариант.

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

чет сам я уже запутался с ZX графикой, вообщем так, пока отложим сей щепетильный момент.

[Lethargeek]

16 бит шина, эта замечательно, но сколько ее должно быть и какая? sdram это pll значит - опять циклоп. без CPLD/FPGA тут делать нечего.
DRAM это "рефрешь" и 8-10 Mгц без ожидания GPU, ну fast page или edo чуть лучше и быстрее, все одно со строкам работать и меньше ног.
как хранилище для графики пойдет . из 2 sram 8 бит делаем одну 16 бит. получаем по 64КБ 2 VRAM- 320x240x256. и DRAM EDO для
графики и блитера.
мало?
Или берем циклоп 2-3 набиваем его до отказа sram 16 бит ? или SDRAM ?

в обсуждениях еще лет 10 тому назад помню, лучшим вариантом признали статику (и объём - насколько хватит адресных ног)))

У меня пока нет мыслей кроме ULA,как улучшить графику для ZX,

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

достаточно простым и не дорогим решением.

это относительные понятия на что не жальче тратить время и денежки
на простое и дешёвое без софта или посложнее-подороже, но развлекательней

отслеживать запись в видео озу ZX?

и не только, игры часто в буфер сперва рисуют

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

основа тут менеджер памяти
который отключает доступ процессору(худший/простой случай) к основной памяти, в СPU0 -1, ( с градацией 8-16-24-32КБ) , т.е сами выбираем сколько у нас под видео память из младших 32K, видяхе "говорим", отображать VRAM1, она отключает VRAM0 от своих шин и включает в адресное пространство процессора. Все процессор пишет/читает VRAM0, не трогая основную память, (ROM мы тоже отключили (BLK)).
Нарисовали, "говорим видяхе", сделать страницу VRAM0 отображаемой. та ОК, и включает для CPU VRAM1.
Самый интересный случай, когда 256x192 16 цветов 24КБ памяти, нужно место под графику.
хорошо, "говорим менеджеру" мы будем только читать из СPU0, "видяхе" мы будет только писать и включаем в СPU0 одну из страниц 8 расширенной памяти, куда уже загрузили графику, ну или наоборот
собственно сам менджер для понимания

я в таких схемах ничего не пойму но для кодера удобно может оказаться по-разному
например, перезадавать два цвета и печатать байтами как на Спеке по 8 пикселей, но без клэшинга
или 16-цветные палитры переключать, а в байте по два хайколорных пикселя упакованы
или на 16кб ПЗУ отобразить окно 128x128x256c по координатам и внутри попиксельно рисовать

[Totem]

в обсуждениях еще лет 10 тому назад помню, лучшим вариантом признали статику (и объём - насколько хватит адресных ног)))

да, но их никак не хватает, если позволить процессору самому все делать, изначально все задумывалось под ez80, как говорят в нашей деревне "их у нас есть"-включая отладочный набор и CPU на вес и о 240' ногий циклоп 3 и куча sram 16 бит.
и "карта и блитер и моща". но это лирика и просто безумно теперь дорого.
С "ножками" у нас "проблемка", но можно поправить -"мультиплексор" самой "широкой" адресной шины для памяти спрайтов/тайлов/окон блитера.
выбор CPLD тут не велик 3256 144 имеем в "товарных количествах", FPGA старые доступны, но цена... и опять мах2 . EPF8820A-160 относительно еще удобно, Мick уже использовал в реальном проекте.

это относительные понятия на что не жальче тратить время и денежки
на простое и дешёвое без софта или посложнее-подороже, но развлекательней

это дело конечно, личное. Но если железо в стиле ретро есть его нужно "употребить" с пользой, тем более, что часть я просто раздарил, часть еще есть.

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

если я не записал нужную мысль, я ее просто забуду

и не только, игры часто в буфер сперва рисуют

это самый интересный вариант, можно подменять вызовы, своими.
P.S.
копал я давно старые java игрушки с телефонов, бери не хочу графику, если уж не художник.

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

я в таких схемах ничего не пойму но для кодера удобно может оказаться по-разному
например, перезадавать два цвета и печатать байтами как на Спеке по 8 пикселей, но без клэшинга
или 16-цветные палитры переключать, а в байте по два хайколорных пикселя упакованы
или на 16кб ПЗУ отобразить окно 128x128x256c по координатам и внутри попиксельно рисовать

тут все просто, есть основная память RAM, ee 128К одной микросхемой, последние 16К расширены как в ZX (7FFDh)
там где у нас ПЗУ -СPU0, делаем так (1FFDh BLK), отключаем ПЗУ, у нас свободная страница 16K в основной памяти, но, в этом варианте , ты можешь запретить к ней доступ и оставить ее под свои нужды, вместо нее включим одну из 2х страниц VRAM видео контроллера. и будем работать с ней. если очень нужно, можно масштабировать в 256 x256 x256 на экран, это нужно? или 512x512x256
за рамки стандарта ZX вообщем не выходит, просто в стандартом клоне ZX страница СPU0 будет "попорчена".

[Totem]

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

В этой реализации, нет проблем с "базовой", это всем знакомая до боли в "простате" , архитектурa классики 48/128, без "видео контролера", расширенная за счет идей }{ имеры, теоретически, если в слот поставить "видяху" Михаила
http://micklab.ru/ZXMVideoCard.htm
получим ZX, но без RAM диска и TR-DOS. Т.е. "воровать" код есть где, пока смысл простой, расширить возможности самоделки 8 бит с ее ограничениями в 64К, на доступной/практически бесплатной сейчас элементной базе и ее узнать эффективность.
Ввязываться в "религиозные войны" видео режимов "с клэшем без", задачи не стоит. Если сможем найти, достаточно приемлемый подход в процессе, в плане адаптации софта/цены/полезности для ZX, будет хорошо, но для самоделки, "связку" части ZX и видео, вижу так.