Просмотр полной версии : Простенькая видеокарта для 8 бит поделок.
Сразу скажу,что "то что я придумал, давно придумано до нас", как итог, стараюсь донести следующие мысли.
Попытки прикрутить к 8 бит CPU, VIDEO - что то круче Циклопа 1,2 это безнадега, авторы пытаются снабдить 8 бит 64К , "адцким" количеством, цветов и "плюшек", самые приближенные к действительности оказались TS и Мick, отчасти создатели спринтера.
Что нужно программеру на 8битке, скажем ограниченном 64К(128 страничками по 16) 3,5 -8 МГц CPU? простата как в ZX, возможность проявить себя, остальным просто текстовый экран, но цветной для Басика и тд.
Далее буду говорить "в разрезе поделок на z180 и z80", в рамках 8 бит детского компа.
2(4) микросхемы VRAM 32К, раздельные шины адреса и данных (50 pins)(VGA 10 pins) , по задумке они "мапятся" у меня вместо ROM и RAM, для просты пока сразу 32К, причем процессор, может читать из них и писать в VRAM, так как я не ограничен страницами в 16К, (z180 ММU может делать станички с "грейдом" 4K практически в любом пространстве 64к из 1М) (для z80 есть "корка" ММU 180) то под код остается 28К), это приемлемо.
Вообщем имеем 2 независимые страницы VIDEO RAM, от 4К до 32К, в одну процессор пишет/читает/DMA, другая отображается, любым способом. Они друг другу не мешают.
Далее все зависит от частоты CPU (33Мгц в моем случае), где вполне вменяемо, можно обеспечить быструю графику 256х192x16c или более, но уже страничной VRAM, средствами только CPU, причем можно использовать оставшуюся память под атрибуты для 256с.
Для медленных СPU , ниже 8Мгц, тоже много возможностей.
8 бит VGA
16с -256c цветов.
Линейная адресация
1. 2(4) микросхемы VRAM (32K 15ns кеш с материнок)
2. CPLD или FPGA типа, EPM3256-144 или EPF8820A-160
3. VGA или SCART (далее если нужно, к0ньвертер в PAL)
Вообщем простой конструктор, который достаточно прост, доступен, дешев, который можно адаптировать под свои задачи. Существующие машинки типа ZX не на программируемой логике, увы резать.Но задача не в этом.
Вопросы, критика, пожелания?
простата как в ZX
Эээээ.... простАта? Она есть у ZX? о_О
- - - Добавлено - - -
А по делу - как противоположный вариант, для слабеньких машинок (или скромных запросов):
- символьный, 64(80)х25
- монохром (или +атрибут цвета)
Итого имеем окно в адресном пространстве 80*25= 2 килобайта, Карл!
А теперь можно подумать, как простым движением руки переключаться между крайними режимами.
Эээээ.... простАта? Она есть у ZX? о_О
а в чем сложность монохромной графике? с атрибутами и дурацкой адресацией екрана?
Линейная адресация
надеюсь, подразумевается не горизонтальный ZX-стайл, а аля-Орион/Специалист, адрес нарастает по вертикали.
надеюсь, подразумевается не горизонтальный ZX-стайл, а аля-Орион/Специалист, адрес нарастает по вертикали.
можешь делать что тебе угодно, этож CPLD/FPGA! C 2я независимыми "рамами" и кучей свободных пинов, готовый модуль.
Главное, что б , "чипсет материнки" умел отрубать ROM и RAM, как у }{imera, и пейсать в VRAM не дублируя в основную RAM ( в идеальном случае)
- - - Добавлено - - -
Эээээ.... простАта? Она есть у ZX? о_О
- - - Добавлено - - -
А по делу - как противоположный вариант, для слабеньких машинок (или скромных запросов):
- символьный, 64(80)х25
- монохром (или +атрибут цвета)
Итого имеем окно в адресном пространстве 80*25= 2 килобайта, Карл!
А теперь можно подумать, как простым движением руки переключаться между крайними режимами.
Лично мне нужна графика Карл!, для слабых машинок вариантов куча и тележка. а с модулем можно и графику с блиттером сделать...гы, и спрайтовой рамой, для совсем худых процов.
Вообщем имеем 2 независимые страницы VIDEO RAM, от 4К до 32К, в одну процессор пишет/читает/DMA, другая отображается, любым способом. Они друг другу не мешают.
Не совсем понял, что имеется ввиду. Как понять в одну пишется/читается, а другая отображается. А кто пишет во вторую.
Ты бы для нагядности структурную схему нацарапал бы что ты в итоге хотел "изобрести"
s_kosorev
02.09.2016, 09:39
[глумон]
И стандартный вопрос для видеокарт, что с клешингом и моралью ?
[глумофф]
Не совсем понял, что имеется ввиду. Как понять в одну пишется/читается, а другая отображается. А кто пишет во вторую.
Ты бы для нагядности структурную схему нацарапал бы что ты в итоге хотел "изобрести"
картинок я позже накидаю, так и понимать, пока процессор пишет/читает в одну страницу(микросхему VRAM1), карта отображает другую VRAM0, пишешь в порт видеокарты ( сменить страницу), теперь отображается страница та, с которой только что работал проц.(VRAM1) Для проца разницы нет, для него видеопамять всегда отображается скажем с 0000h.
Шины у VRAM раздельные.
- - - Добавлено - - -
[глумон]
И стандартный вопрос для видеокарт, что с клешингом и моралью ?
[глумофф]
:v2_clap2:
Клешинга нет, морали тоже
:v2_dizzy_dance:
В чем +
"быстрый" СPU - 180, еz80, мотороллер, и еже с ними, работает без wait'ов, не делит время с видео.
Сама "видяха" может иметь любой "пиксльклок" и разрешение экрана. "Схему отображения VRAM" мы можем тактировать, ну как пример ZX 28-14Mгц, или 25, для VGA, один быстрый мультиплексор и управление им. Главное помнить, что мы 8 бит, и памяти у нас нет под графику более 16с, 256с с 4 страницами по 16к.
Причем, теоретически в VRAM вместе с CPU может делить и "блитер" , но для этого нужна еще 1 "срамина" на которую пинов уже нет, в этом варианте.
Lethargeek
21.04.2017, 15:47
(часть относится к попыткам улучшения только Спектрума, часть и к 8-битным компам вообще)
Сразу скажу,что "то что я придумал, давно придумано до нас", как итог, стараюсь донести следующие мысли.
Попытки прикрутить к 8 бит CPU, VIDEO - что то круче Циклопа 1,2 это безнадега, авторы пытаются снабдить 8 бит 64К , "адцким" количеством, цветов и "плюшек", самые приближенные к действительности оказались TS и Мick, отчасти создатели спринтера.
Безнадёга - это вечные попытки "до нас" переделать Спектрум в какой-то новый несовместимый комп, программировать который надо по-новому. Будь то тайлы-спрайты или "профессиональные" видеорежимы из 90-х, соответственно пародии на денди или песюк. Сами по себе разрядность цвета и крутизна циклопов тут ни при чём.
Что нужно программеру на 8битке, скажем ограниченном 64К(128 страничками по 16) 3,5 -8 МГц CPU?
Кодеру на ретро-хобби-компе нужен максимально эффектный результат при минимальной трате нервов и времени...
простата как в ZX, возможность проявить себя, остальным просто текстовый экран, но цветной для Басика и тд.
...потому "простата" (гусары, молчать!) должна быть именно такой, "как в ZX", и такой, чтобы немного, но заметно улучшить графику можно было даже в старых игрушках (без исходников доступных, само собой) за пару вечеров под пивко (а при желании улучшить очень заметно, если времени/желания чуть побольше). Что автоматически означает еще более простую поддержку нового режима самим автором нового софта для стандартного и нерасширенного ZX (на который в основном и пишут весь новый софт). Подчеркну, что важно именно суммарное время на разработку версии для стандартной конфигурации И улучшения её под новый режим.
2(4) микросхемы VRAM 32К, раздельные шины адреса и данных (50 pins)(VGA 10 pins) , по задумке они "мапятся" у меня вместо ROM и RAM, для просты пока сразу 32К, причем процессор, может читать из них и писать в VRAM, так как я не ограничен страницами в 16К, (z180 ММU может делать станички с "грейдом" 4K практически в любом пространстве 64к из 1М) (для z80 есть "корка" ММU 180) то под код остается 28К), это приемлемо.
Нужен интерфейс стандартный прежде всего, а железные детали не так важны. Хотя, если хочешь знать моё мнение, то достаточным "навсегда" явился бы девайс со своей видеопамятью на 16-битной шине (одно слово на один пиксель), экономить на размере которой нынче не вижу смысла (графику же надо где-то новую и жирную размещать)
Далее все зависит от частоты CPU (33Мгц в моем случае), где вполне вменяемо, можно обеспечить быструю графику 256х192x16c или более, но уже страничной VRAM, средствами только CPU, причем можно использовать оставшуюся память под атрибуты для 256с.
От частоты CPU не должна графика новая зависеть! Девайс должен позволять оперировать базовой стандартной машине (3.5мгц в случае ZX) 8-16 битными пикселями нового режима в том же стиле и с той же скоростью, что и старыми (однобитными в случае ZX) пикселями классического экрана. А для скорости, превышающей возможности стандарта - нужен блиттер.
8 бит VGA
16с -256c цветов.
Маловато, как уже отмечено выше, и бессмысленно искусственно ограничивать без привязки к частоте CPU.
Линейная адресация
Адресация должна быть переключаемой. Формат данных (пикселей) тоже. Причём "на ходу" и без потери картинки. В идеале, чтобы имитировать возможно было любой режим с теми же параметрами развёртки, и без большого напряга портировать софт с других платформ на Z80.
1. 2(4) микросхемы VRAM (32K 15ns кеш с материнок)
2. CPLD или FPGA типа, EPM3256-144 или EPF8820A-160
3. VGA или SCART (далее если нужно, к0ньвертер в PAL)
Вообщем простой конструктор, который достаточно прост, доступен, дешев, который можно адаптировать под свои задачи.
По адаптации см. замечание выше. А простота-доступность, конечно, здорово, но главное - потенциал программной поддержки. Будет софт - будет смысл паять или покупать даже что-то менее простое или дешёвое. А софт будет, только если просто будет его писать одновременно под стандарт и новый режим, и работать сможет в любом режиме. Ну, по крайней мере, первое время, пока девайс не наберёт популярность.
Существующие машинки типа ZX не на программируемой логике, увы резать.
Лучше обойтись без резни, тем более, что для типичного хобби-применения (игры, демы) чтение памяти девайса необязательно.
- - - Добавлено - - -
UPD. Я, наверно, слишком сильно свожу всё к Спектруму. Для оригинальных новых поделок вроде бы вопрос совместимости с базовой "классической" конфигурацией отпадает, они сами базовые себе. Тем не менее, было бы весьма полезно, чтобы хотя бы новый софт для некоторых популярных ретрокомпов просто и легко переносился бы на новую машинку хотя бы автором.
http://i12.pixs.ru/thumbs/1/7/3/zx222jpg_9245273_25944173.jpg (http://pixs.ru/showimage/zx222jpg_9245273_25944173.jpg)
основа тут менеджер памяти
который отключает доступ процессору(худший/простой случай) к основной памяти, в СPU0 -1, ( с градацией 8-16-24-32КБ) , т.е сами выбираем сколько у нас под видео память из младших 32K, видяхе "говорим", отображать VRAM1, она отключает VRAM0 от своих шин и включает в адресное пространство процессора. Все, процессор пишет/читает VRAM0, не трогая основную память, (ROM мы тоже отключили (BLK)).
Нарисовали, "говорим видяхе", сделать страницу VRAM0 отображаемой. та ОК, и включает для CPU VRAM1.
Самый интересный случай, когда 256x192 16 цветов 24КБ памяти, нужно место под графику.
хорошо, "говорим менеджеру" мы будем только читать из СPU0, "видяхе" мы будет только писать и включаем в СPU0 одну из 8 страниц расширенной памяти, куда уже загрузили графику, ну или наоборот
собственно сам менджер для понимания
http://i12.pixs.ru/thumbs/0/0/9/elitejpg_5572245_25808009.jpg (http://pixs.ru/showimage/elitejpg_5572245_25808009.jpg)
.потому "простата" (гусары, молчать!)
Упс :)
достаточным "навсегда" явился бы девайс со своей видеопамятью на 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
21.04.2017, 19:28
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 по координатам и внутри попиксельно рисовать
в обсуждениях еще лет 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 будет "попорчена".
UPD. Я, наверно, слишком сильно свожу всё к Спектруму. Для оригинальных новых поделок вроде бы вопрос совместимости с базовой "классической" конфигурацией отпадает, они сами базовые себе. Тем не менее, было бы весьма полезно, чтобы хотя бы новый софт для некоторых популярных ретрокомпов просто и легко переносился бы на новую машинку хотя бы автором.
В этой реализации, нет проблем с "базовой", это всем знакомая до боли в "простате" :v2_lol:, архитектурa классики 48/128, без "видео контролера", расширенная за счет идей }{ имеры, теоретически, если в слот поставить "видяху" Михаила
http://micklab.ru/ZXMVideoCard.htm
получим ZX, но без RAM диска и TR-DOS. Т.е. "воровать" код есть где, пока смысл простой, расширить возможности самоделки 8 бит с ее ограничениями в 64К, на доступной/практически бесплатной сейчас элементной базе и ее узнать эффективность.
Ввязываться в "религиозные войны" видео режимов "с клэшем без", задачи не стоит. Если сможем найти, достаточно приемлемый подход в процессе, в плане адаптации софта/цены/полезности для ZX, будет хорошо, но для самоделки, "связку" части ZX и видео, вижу так. :v2_dizzy_indy:
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot