Итого 10+16+10+20+10+16 = 82 такта точка без расчетов ! Ого го я бы сказал, добавить математику и музыку и что же это, пара линий по 100 точек и все демо...
Вид для печати
как человек, когда-то патчивший графику "элиты", не могу промолчать :)
во-1, кадр в "элите" рисуется не на экране, а в буфере (и потом чересстрочно перебрасывается в экран)
во-2, никто в здравом уме не будет рисовать отрезки по координатам следующего пикселя
вычисляют сразу соседний адрес (байтовая маска на Спеке - как бы часть адреса)
именно ради ускорения и упрощения вычислений
у меня получилось емнип около 80 тактов на пиксель в среднем для финальной отрисовки без отсечения
это в цикле, а применив таблицы или развернув код (и без ксора) можно рисовать примерно вдвое быстрее
(а с альтернативной раскладкой буфера или нового экрана - еще быстрее и гораздо короче)
:v2_scare: жуть кошмарная для "быстрой видеокарты" (c)
а вот как эти же два пикселя можно вывести на стандартном медленном Спектруме:
ld hl,$4000
set 7,(hl)
set 6,(hl)
40 тактов!!
самая (?) же быстрая процедура установки точки по произвольным новым координатам - только 58 тактов
уж извини, но вывод спрайтов тоже запланирован неудачно :v2_dizzy_no:
неудобен ни для написания новых, ни для улучшения старых игр
и цвета урезаны неоправданно
Так вот и я говорю, ставить гигантскую плис с быстрой памятью что бы получить ещё медленее чем было.
Почему нельзя тупо сделать переброску спрайтов с помощью дма, пусть даже и в 4-8 слоёв экрана, а с цветовой компонентой я до сих пор ничего не понял, что то типа древнего CGA 35-летней давности ?
Почему пиксель так сложно рисовать? почему нельзя выставить цвет и потом только координаты кидать?
LD A,color
LD (meteor_pix_color),A
LD H,y
LD L,x
LD (meteor_pix_coord),HL
inc l
LD (meteor_pix_coord),HL
inc l
.....
по сути пиксель ставится за 16 тактов - LD (nn),HL
а цвет уже заранее выставлен и его всегда можно поменять
с спрайтами та же байда, можно уложиться в 30-40 тактов на спрайт размером с экран
--------------------------
Кстати мысля, пиксель по LD (nn),HL можно предусмотреть в любой видеокарте, по сути достаточно только адрес порта в памяти указать а процедура вывода изображения растровой графики будет работать на любой видеокарте.
и так ли уж координаты нужны, по мне лучше уж привычные адреса плюс возможность на ходу раскладки менять
тогда уж за 7 тактов ld (hl),reg - и легко пропатчить старые процедуры, и новые работать быстрее будут
больше двух цветов (один прозрачный) для векторов и спрайтов в спектрумовском духе просто не нужно
для многоцветных спрайтов - блиттер или недокод на девайсе, перебивающий z80-команды в нужных местах
а также для модернизации старых игр вообще без правки старого кода (только приписать спецзагрузчик)
а три цвета - это же ни рыба ни мясо: и со старым кодом не сочетается, и картинку не особенно улучшает
Имея карту с таким гигантским объемом памяти частотами и ресурсами ! Вообще лучший вариант загрузил сразу всю графику в карту, картинки, спрайты, шрифты, и прочее, а дальше команду в окне регистров карты
Nesser, Lethargeek зачем так все сложно зачем мучить одно место (моск:D) ,не надо слои, и остальной огород, например режим карта с 256X192 и 8 битным цветом на точку, это экран 48 кб для такой карты мелочь, пример для переделки игр, что скажете ?
Вся графика уже загружена в карту и мирно там лежит все время по полочкам (банкам) -
банки имеют размер 64кб этого всегда хватит даже для картинки размером в полный экран 48кб , а в поле 64кб очень удобно работать одной регистровой парой !
;---------------------------------------------------------------------;
сохранили стек
LD SP,sprite ;установили стек в массив команд карты
POP HL
LD (#3A00),HL ;регистр карты который задает в экране карты адрес начала вывода спрайта (либо если сделать два режима по адресам или точкам будет задавать по точкам 256 на 192 как раз будет старший байт координата по точкам X , младший байт Y)
POP HL
LD (#3A02),HL ;регистр карты который задает номер банка памяти (1 например) в карте в которой загружена наши графика
POP HL
LD (#3A04),HL ;регистр карты который задает где лежит спрайт в памяти карты (можно задавать банки 1,2,3 и т.д.) в карте, банк будет размером 64кб удобно!
POP HL
LD (#3A06),HL ;регистр карты который задает размер спрайта X,Y
POP HL
LD (#3A08),HL ;регистр карты который задает команду карте перекинуть спрайт из памяти карты в экран карты
восстановили стек
sprite DEFB
#0000 адрес в экране карты куда будет перекинут спрайт
#0001 номер (1) банка размером 64кб где лежит наш спрайт с которым сейчас работаем
#8000 адрес спрайта в банке 1 памяти карты
#0808 размер спрайта X,Y
#0001 1- команда перекинуть спрайт
;------------------------------------------------------------------;
Учитывая частоты карты, спрайт мгновенно на экране.
А еще более изумительный вариант, будем считать что выше написанное это кидать не в экран, а в буфер экрана карты, а потом по команде в какой то регистр подготовленный буфер перекидывается в экран,
КРАСОТА, СКОРОСТЬ, ПРОСТОТА !!! Именно для переделки старых игр, так как мы освободим память ZX и код игры в плане управления координат графики в старой игре не надо трогать, в нужном месте только поставить то, что я привел ! Сказка для переделки старых игр c новой графикой ! Надо только загрузчиком загрузить с диска новую графику в карту, в игре минимум изменений и они очень очень простые !
Что то подобное и для точек, линий. Та же элита , на этапе когда мы получили в игре код координат линии на экране X,Y , мы в коде где должна рисоваться эта линия ставим свой код типа вышеприведенного но для работы с линиями а не спрайтами, и задаем новый цвет и т.д. и вот новая раскрашенная элита !
ZST что скажите, зачем спеку с 3.5мГц экран фул шд ? Это тогда надо называть карта для статической графики. А если концепт изменению не подлежит, скажите, вам голову не будут морочить.
PS правил по мере мыслей.
Большая FPGA нужна чтобы влезли все регистры и схемы управления. Объем FPGA не такой уж большой. В ней всего 4602 LE, то есть 4602 однибитных триггра. Этого хватит только на 575 восьмибитных регистров. А их для управления режимами Метеора может понадобиться много. Кроме этого для работы видеокарты надо много LE.
Приведу пример Alone Coder:
В приведенном примере надо учесть длительность команды DEC D. Тогда длительность будет 58 + 4 = 62.Код:по координатам,заданным
в регистрах L=y, E=x, в произвольном месте
экрана(и даже за экран)за 58(!)тактов ста-
вится точка.Регистр C равен старшему байту
адреса таблиц('TABLE), регистр D=C+2.
LD H,C
LD A,(DE);x/8 \
INC D |-даёт младший байт
OR (HL);L(y) /
INC H
LD H,(HL);H(y)
LD L,A
LD A,(DE);byte(x)
(X)OR (HL);метод постановки точки
LD (HL),A
Если вместо последних 2 команд вставить
AND (HL),то это будет функция POINT. Чтобы
процедура работала многократно, в конце её
поставьте DEC D.
Так как в этом примере координаты уже загружены в регистры, то и в моем их считать не надо. Тогда 82 - 10 - 10 = 62.
Скорость такая же, но точки рисуются произвольными цветами без клешинга атрибутов.
Скорость будет зависеть от оптимизации команд. В моем примере использовались команды для рисования спрайтов.
Если мы добавим команду для рисования точками, то будет намного быстрее.
Согласен. Если добавить новую команду, которая сразу будет рисовать точку при загрузке координат и координаты однобайтовые, то будет 16 тактов. При этом цвет можно менять в произвольный момент и рисование будет происходить без клешинга.Цитата:
Почему пиксель так сложно рисовать? почему нельзя выставить цвет и потом только координаты кидать?
LD A,color
LD (meteor_pix_color),A
LD H,y
LD L,x
LD (meteor_pix_coord),HL
.....
по сути пиксель ставится за 16 тактов - LD (nn),HL
а цвет уже заранее выставлен и его всегда можно поменять
Только это уже скорее аппаратная точка получается. Добавил регистры:
point_x — координата X при рисовании точки. Координата однобайтная.
point_y — координата Y при рисовании точки. Координата однобайтная. После записи координаты Y точка рисуется/стирается текущим инструментом.
- - - Добавлено - - -
Да, это будет удобно и быстро. Если банки будут по 64 К, то двумя байтами можно указать адрес начала спрайта в банке.
В Метеоре каждый слой состоит из двух частей/буферов. Пока один изображается на другом можно рисовать. А по прерыванию их можно менять местами. Адресация, вернее координатыы при этом не меняются.Цитата:
Учитывая частоты карты, спрайт мгновенно на экране.
А еще более изумительный вариант, будем считать что выше написанное это кидать не в экран, а в буфер экрана карты, а потом по команде в какой то регистр подготовленный буфер перекидывается в экран,
Тут одна трудность - графику надо найти и скопировать. Если отдельно загружать, то увеличится размер игры. Но может это как вариант использовать.Цитата:
КРАСОТА, СКОРОСТЬ, ПРОСТОТА !!! Именно для переделки старых игр, так как мы освободим память ZX и код игры в плане управления координат графики в старой игре не надо трогать, в нужном месте только поставить то, что я привел ! Сказка для переделки старых игр c новой графикой ! Надо только загрузчиком загрузить с диска новую графику в карту, в игре минимум изменений и они очень очень простые !
FULL HD для точного изображение пикселов на экране. Это не так важно. Можно остановиться на VGA 640x480 60 Hz.Цитата:
Что то подобное и для точек, линий. Та же элита , на этапе когда мы получили в игре код координат линии на экране X,Y , мы в коде где должна рисоваться эта линия ставим свой код типа вышеприведенного но для работы с линиями а не спрайтами, и задаем новый цвет и т.д. и вот новая раскрашенная элита !
ZST что скажите, зачем спеку с 3.5мГц экран фул шд ? Это тогда надо называть карта для статической графики. А если концепт изменению не подлежит, скажите, вам голову не будут морочить.
Разумные предложения обсуждаются и применяются. Обычно только критика и слишком сложные предложения. Надо все делать просто и удобно для программирования.
Это на мой взгляд упрощение переделки старой игры, а не усложнение, вот смотрите есть спрайтовая игра, из нее естественно выдираются родные спрайты и раскрашиваются, далее мы эти спрайты компонуем одним файлом, и делаем простой загрузчик который грузит это все в карту перед запуском игры, нам не надо тратить огромное количество времени на впихивание этой графики в игру, да и не получится это у нас, не хватит ZX памяти на новую графику. А остаток переделки игры вставить короткие участки кода, что я приводил выше, когда игра посчитала координаты для родного спрайта мы их берем за основу и закидываем в карту , и как по мне это просто удовольствие в переделке игры а не мучение:v2_dizzy_coder:
Пример с использованием стека и одного регистра HL еще избавляет нас каждый раз запоминать все регистры, просто перед процедурой запомнили HL, запомнили адресс родного стека игры, после отправки данных в карту восстановили.
- - - Добавлено - - -
PS и еще в такой реализации мы разгрузим на 90% процессор !!! Ему же не надо самому заниматься перекидыванием спрайтов из памяти в экран, а карта из своей памяти в свой экран может делать это элементарно, согласны ?
- - - Добавлено - - -
PPS такой концепт на мой взгляд может привлечь потенциальных разработчиков/передельщиков игр своей простотой переделки и программирования
Может быть так будет лучше. В играх спрайты хранятся по разному. После преобразования спрайты можно привести к единому формату. Тогда понадобится одна процедура копирования спрайта в FPGA. Не обязательно даже перекрашивать спрайты. Просто перекодировать из формата 2 бита на точку в 16 битов на точку с сохранением цветов. Раз цвета у нас уже в спрайтах, то в программе их указывать не надо будет.
Совершенно верно, но я бы еще предусмотрел 8 бит на точку и экран 256x192 , это надо для простоты написания новых программ, игр, демо ! для режима карты в которую мы не будем предварительно ничего загружать, а будем например real time рисовать сами, так как оперировать в этом случае с цветами 8 бит проще аккумулятором (A) , при 16 бит на точку все очень усложнится для real time
Кстати правильно ли я рассуждаю что мы фактически освободим процессор если карта будет иметь предварительно загруженную график в свою память ?
- - - Добавлено - - -
PPS готов помочь более детальным концептом, что бы хорошие идеи не остались на бумаге...
- - - Добавлено - - -
А если нам вообще оставить один стандарт экрана (8 бит 256x192) то аппаратно мне видится все так - память экрана одна микросхема SRAM 64кб , память графики одна, две SRAM 512кб и FPGA, естественно цена сразу минимальна, более широкий рынок покупателей и сборщиков если будет комплект для сборки.
- - - Добавлено - - -
Потратив на комплектующие 5$ лучше больше взять за свою работу, нежели потратить 50$ на железо и 5$ добавлять за свою работу (сборку);)
- - - Добавлено - - -
Ну и как всегда добавлю на всякий случай, для меня это хобби, мне с этого ничего не надо кроме удовольствия)))
- - - Добавлено - - -
Совсем ориентировочный концепт, мечта программиста ZX на мой взгляд.
Вложение 58369
- - - Добавлено - - -
Это будет по истине быстрая карта, которая разгрузит практически весь процессор , что можно даже процессором будет MOD играть !
Также имея аппаратную линию и точку не только по адресации через память как и раньше в ZX экране, но еще и через X,Y эффекты с точками можно рисовать очень быстро, ведь Z80 не надо пересчитывать координату X,Y в адреса экрана.
- - - Добавлено - - -
На счет клешинга я бы сделал так - старая игра рисует фон нашими новыми красивыми 256 цветными спрайтами, далее к примеру на поле с травой она должна вывести спрайт героя , мы карте говорим через определенный регистр какой спрайт нарисовать сверху фон или героя , и каким методом - XOR,OR,AND , и все, без всяких слоев в памяти и прочих заморочек.
Вот пример со спрайтом сена на левой ноге по вышеописанному принципу -
Вложение 58370 Вложение 58371 Вложение 58372
- - - Добавлено - - -
Естественно XOR,OR или AND делает сама карта при переброска спрайта, линии, или точки из SRAM графики в SRAM экрана, быстро и просто, а Z-80 отдыхает ну или свои дела делает )
так я сам всегда был против слоёв (но за 16-битные пиксели по ряду причин) и за чистый блиттер для рисования
только это надо сделать необязательным, чтоб не переделывать, когда лень или двух цветов объектам достаточно
для удобства переделки в старый код лучше не вставлять ничего (там и места может не оказаться)
помечаем несколько адресов, где старый z80 код непосредственно пишет или читает графику
при выборке команды с этого адреса видеокарта параллельно выполняет свою команду
причем значения на шине данных и шине адреса Спека может применить как параметры
не на мой) блиттер хочется уметь настраивать тоньше
и зачем память видеодевайса делить на части?
На банки по 64 кб для того что бы можно было работать одной регистровой парой для адресации я же выше писал.
А при наличии отдельной SRAM данных и SRAM экрана очень простая аппаратная реализация, и финансово такая карта будет стоить баксов 10, и память в старых играх в этом случае освободится, мы же графику теперь держим в SRAM данных карты, нам не нужны старые спрайты и процедуры их вывода на экран, код работы с спрайтом старой игре нужен до момента X,Y спрайта на экране.
Очень простая и программная и аппаратная реализация, при которой процессор совершенно свободен !
- - - Добавлено - - -
Альтера + 2 штуки SRAM = 15$ Но я бы даже альтеру не применял в этой карте, можно спокойно на STM (2$) +SRAM (3$) сделать
для этого не нужно делить на банки, задаёшь отдельно длинный начальный адрес, и работай после со смещениями короткими
и блиттер должен быть универсальным, работать с источником и приёмником, расположенными по любым адресам
и внутри экрана, и внутри графического набора, и между ними перебрасывать в обе стороны
а не затачиваться под один отдельный частный сценарий
- - - Добавлено - - -
про переделки вечером подробнее напишу
Мне почему-то кажется, что для начала можно допилить какой либо эмулятор, чтобы все обращения к шине(R/W, адрес, данные) он собирал в UDP-пакеты и передавал в Ethernet на какой либо multicast-адрес. А далее можно делать программу, которая будет эти пакеты принимать, смотреть чего происходило на шине, и строить по ним картинку, которую должен выдать метеор. В этом случае можно будет сразу попробовать различные алгоритмы рисования спрайтов/точек/линий, оценить насколько это удобно для Z80, добавить/переделать какие-либо возможности, а после смотреть лезет оно в ПЛИС или нет.
На мой нубский взгляд для старта можно сделать так, карта перехватывает все адресное пространство видео, формируется несколько экранов, через регистры настраивается взаимодейстивие экранов (порядок наложения и правила сложения) а дальше игра рисует в обычном видео режиме но добавляется небольшой код выбора экрана через регистр. А дальше уже расширять количество цветов, апаратные блитеры и остальные примочки для написания новых программ.
Ёмаё, я и говорил что слои и всё прочее это неактуально, всё должно работать АППАРАТНО.
Зачем 2 раздельные видеопамяти? сканер видео-строчек по сути готовый регенератор памяти, достаточно 1 микросхемы на 16 бит данных, 8Мб по 16 бит или что-то в этом роде (по сути 8Мб по 16 бит это уже 16 мбайт - 24 бита адреса), с ПЛИС на всякий случай можно вытащить 1,2 или 4 ноги для нескольких микросхем (дешифратор старших адресов). ПЛИС же в состоянии работать с памятью на стандартной частоте 133 МГц ?
В этой памяти прекрасно уместятся и все видеоданные и шрифты и 2 экрана. По сути к любому компу эту приблуду можно подключить при помощи 8 проводов данных и 2-3 адресов.
Сделать графический редактор специально для этой шняги, спрайтовый файл, в начале файла описатели спрайтов, 4 байта положение в файле + 1 байт ширина спрайта + 1 байт высота спрайта + 2 байта что нибудь связанное с банкой поллитры (для одинакового спрайта но разных цветов).
Кидаешь карте номер спрайта и куда вывести, по сути можно даже задавать и адрес якобы экрана, DMA кинет так как будто по этому адресу экран, всё нашвыряли, наложили, подтёрли, а потом готовое после кадрового синхроимпульса скопировали на экран, DMA всё равно перебрасывает быстрее чем сканер выводит точки, синхронизация сама собой отпадает, по сути все видеокарты так и работают.
И вообще че мы велосипед придумываем, принципы работы давно уже отработаны, достаточно реализовать в ПЛИС в минимальной необходимости, только нелинейный DMA перекидывающий данные с учётом размерности экрана.
А экран по факту сделать 8 или 16 бит на точку, преобразование из 1, 2, 4 бита на точку может сделать и сам DMA при переброске.
Когда уже ваш МЕТЕОР-2013 станет МЕТЕОР-2016?
HardWareMan, в процессе становления как раз
Затем, что тогда не нужны частоты по 100мгц , плис можно не использовать, а обойтись контроллером, регенерацию памяти не надо реализовывать, и еще много мелочей.
Аппаратно намного проще и быстрее построить такую карту, 3 микросхемы, и дешевле.
К чему спеку 8 или 16 мегабайт памяти, почему ни кто не пишет как ее использовать, реально без фантазий ?, вам 20 дискет надо будет прочитать с картинками что бы ее заполнить! Я считаю от реалий, диск 640кб, 512кб видеопамяти данных с головой:)
- - - Добавлено - - -
Пример отличного, простого и недорогого использования SRAM и контроллера это ZX-AVR, исходя из этого проекта могу сказать, что можно построить эту карту на двух SRAM и AVR;) и не нужны ни плисины ни мегабайты, с ними нечего будет делать.
- - - Добавлено - - -
16 байт цвета на точку тоже, к чему ? Карта должна работать на базовой конфигурации ZX 128кб , значит на телевизоре, зачем на телике 64 тысячи цветов:v2_dizzy_facepalm:
- - - Добавлено - - -
Я бы не уходил от таких картинок, это же наше, это 8 бит !!! - http://www.pixel-issue.net/2010/12/o...ng-with-html5/
да , идея с двумяSRAM и AVR мне лично импонирует
в дип корпусах
долой гигагерцы и хиколор
и еще инструмент , типа раскрасчик
или методику для тупых
чтобы я смог любимую игрушку за месяц раскрасить
ну и фишки для тру программеров , на ваше усмотрение-)
zx_, раскрашивать элементарно даже в paint.net , хотя есть и поудобнее инструменты.
А переделка весьма проста, если новая графика будет загружаться в память карты, не надо километры кода в старых играх переписывать.
пример чего? как на Спеке в память (на которую отобразили порты) записать 3-4 байта, что ли?
да как хошь задавай начальный адрес в памяти карты, например $123456 (хоть по одному байту в любом порядке)
отдельно для источника и приёмника, потом бегай парой-смещением (например $789A - тогда полный адрес $123456+$789A=$12ACF0)
а скорее даже удобней будет бегать по старшим битам адреса спрайтов (их размеры явно будут больше чем сотня пикселей)
неудобно! банки это восьмибитный каменный век, подгоняй под их размеры потом, не пересекай границы, да ну их нафиг
снова наступаем на те же грабли :v2_dizzy_facepalm:
сделать из говна и палок приблуду как удобно железячнику, а не кодеру
а потом на форумах горевать, почему ж никто софта на неё не пишет
потому что выгодно по многим причинам (в том числе для адаптации старых игр)
и на телеке прекрасно видно столько цветов (и не 64, а 32 с признаком палитровости)
долой жалкую пародию на приставки тридцатилетней давности!!!
(а кому хайколор не нравится - не используйте)
- - - Добавлено - - -
+500 (аж на секунду показалось, что пост был мой) :v2_dizzy_biggrin2: :v2_cheer:
Мы не к амиге карту делаем ))) У нас 35 летнее железо из каменного века.Что тут подгонять экран 48кб.
Если это карта для ZX 128, разговор один, а если с мечтами что потом цеплять к пентагону 32мб оперативы что бы эта новая карта красиво показывала 1920x1080 то это совсем другое кино, которое уверяю никогда не случится, есть tsconf и не морочить голову с плисами и 16 мб памятью которые на zx-128 нечем заполнять.
Карта для zx 128 должна быть такой же простой как и он сам, исходная точка отправления 640кб диск, 128 RAM.
А то что вам хочется это прицепить к велосипеду дом на колесах, удобно, но не поедет...
Конечно если нет плисины, линеек с памятью и платы как тапок то это *****)))
Программирование карты в 6 строчек кода на асме и все прерывание процессор ваш это горе для программиста ? Ну ну...
- - - Добавлено - - -
Примеры хорошо бы, я когда о чем то пишу примеры сразу конкретные даю, с 16 битами при восьми-битном аккамуле сказа работать , мечта программиста ))))
можно посмотреть на реализацию? железо безвозмездно вышлю
Надо сначала сделать дешевую версию "Метеор-1" для ZX-BUS. Обкатать идеи. Цена конструктора 2000-3000 руб. будет доступна большинству ?
Уменьшить количество памяти до 2 микросхем SRAM по 512К. Одну под спрайты. Вторую под 2 слоя новой графики.
Видеовыход просто RGB, но разъем VGA.
Слои остаются. Кому не надо - не используют. В каждом слое два буфера/экрана размерами 256 x 256 точек по 16 бит на точку.
В одном рисуем, другой отображаем.
Для синхронизации подаем 14 MHz с клона. С видеокарты "Метеор-1" на клон подаем INT.
С оригинального ZX придется подавать 14 MHz припайкой провода. Но для оригиналов надо будет уточнить потом. Пока будем подключать к клонам.
Предусмотреть несколько джамперов для выбора режима работы. Может будет меняться частота кадров 48/50 Hz. Потом уточним.
R-2R с платы "Метеор-1" переносим на набольшую плату с разъемом VGA для крепления на заднюю стенку компьютера в удобном месте.
Соединение плат шлейфом IDC-20.
Если потребуется вывод на монитор, то подключать внешний китайский видеоконвертер или через шлейф IDC-20 видеоконвертер "VGA Sputnik", который будет делать 60 Hz FULL HD с увеличением точек в 4 раза или VGA 640x480 60 Hz.
Размер игры ограничиваем размером диска 640К. На спрайты 512К. Остальное - код, заставка и т.п.
zst, А в концепт впишется 8 бит точка ? И правильно ли я понимаю, что разделяете предложенное изменение концепта -
Было - берем графику из памяти zx и кидаем LDI через окно чем занимаемся все прерывание и ничего не успеваем.
Стало - грузим графику через окно в SRAM данных карты, даем команды через регистры, что куда рисовать и все прерывание делаем что душа желает, и имеем всю память zx под наши нужды.
На счет аппаратной точки и линии, будите реализовывать ? Если дадите более подробный концепт постараюсь помочь сделать.
- - - Добавлено - - -
Если родится приблизительно в описанном виде, это прекрасно !
Спасибо, спасибо :)
------------------------
AVR это обычный микроконтроллер, мощность его значительно меньше чем у голых CPU, эмуляция чахлого Z80 в чахлом AVR это что-то с чем то, это то что надо :D раньше так на МК-57 делали.
ПЛИС с лёгкостью работает с микросхемами памяти на частоте 133 МГц, то есть на ихней родной частоте, в основном эти микросхемы имеют объёмы 2-16 Мб, а покруче на 128 Мб, такой объём памяти обусловлен не желанием запихать аж 8-16 Мб в Спектрум а потому что эти микросхемы производятся нынче на заводах, можно конечно поставить и мешок РУ5, вот только их 15 лет как не производят, остались только на складах, и то 90% из них бракованные.
А вообще по моему, ZX-EVO сделан почти так как надо, только ПЛИСину надо отдать под систему а ПЛИСину под видео сделать на отдельной плате с нормальным DAC. Тогда и с видео проблем не будет, можно модернизировать как угодно.
Только надо саму материнку сделать нормально, может даже поставить PL-2303.
И делать "Метеор" под слот сколько влезет :)
Ну да ну да, зачем мы вообще этих древним хламом занимаемся... - автору респект - http://zx-pk.ru/threads/23671-avr-zx-spectrum-v2_0.html
- - - Добавлено - - -
У ZX есть ресурсы для заполнения этой памяти ? Есть полноценная операционка ? Я расписал достаточно подробно концепт карты с объяснением - почему, распишите свой так же подробно, думаю много желающих будет обсудить. Стандарт хранения данных ZX 640 кб, усё, пожизнено, потому, что гладиолус:v2_wink2:
Ресурсы для заполнения этой памяти ЕСТЬ :) только они не реализованы и раскиданы по разным платам, какая там карта mp3 воспроизводит?
Полноценная (и не очень) операционка может быть только если система это позволяет, на данный момент весь ассортимент Спектрум-совместимых и приблуд к ним выглядит хуже чем ассортимент периферии к PC.
ХАОС ! никакого стандарта, о какой операционке тогда может идти речь? :) каждый делает под себя.
Сделать надо ОДИН стандарт, а всё старое запускать на этом стандарте с помощью дешифрации портов, PC так в своё время и сделала, результат был успешным.
Вплоть до того что сканер экрана оставить в системной ПЛИС а видеокарту априори только в слот, то есть сама материнка в состоянии выводить и стандартный экран и с разным разрешением и цветами, тупо занести разрешения, развёртки и компоненту VGA, видеоэкран получается тогда в общей линейной памяти в которой проц плавает банками 4 по 16 кб, в этой же памяти и скопированные из флеш ПЗУ барсика, доса, а всякой шняги, ПЗУ слишком медленные против ОЗУ, в данном случае задержек по скорости нет, сам Z80 напрямую завести в ПЛИС, все запросы к памяти и портам обрезать до 1 такта что бы проц собой не держал общую шину, пусть он там 21 такт разбирается внутри себя с командой но при запросе к памяти будет потрачен всего 1 такт из шины (это в принципе некоторые уже сделали - кеш). Монитор или ТВ в таком случае всегда подключается к материнке.
А на слотовой карте уже стоит ПЛИС который имеет доступ к памяти материнки в которой и данные и экран помещает и выводит сама материнка, КАРТЕ выпадает задача только обрабатывать все данные и кидать их обратно в мать откуда та уже и выводит на экран. Видео ЦАП получается всегда на материнке, его можно сделать немного подороже. Видеокарта в слот по сути из себя представляет просто плату с ПЛИС, материнка и без неё всё стандартное будет показывать, фотки и старые игры все будут работать.
Нууу как то такая мысля.
п.с. Z80 работает на 24 МГц, а кто нибудь пробовал его ускорять свыше во время внутреннего выполнения ? так же как ВГ ? я сделаю большие круглые глаза если он во время внутреннего выполнения схавает частоту ещё больше.
8 бит на точку подразумевает дополнительно палитру. А это дополнительный режим графики надо делать. Для начала бы 15 стандартных цветов сделать. Для рисования точки другим цветом можно выбрать другой инструмент с другим цветом.
Да.Цитата:
И правильно ли я понимаю, что разделяете предложенное изменение концепта -
Было - берем графику из памяти zx и кидаем LDI через окно чем занимаемся все прерывание и ничего не успеваем.
Стало - грузим графику через окно в SRAM данных карты, даем команды через регистры, что куда рисовать и все прерывание делаем что душа желает, и имеем всю память zx под наши нужды.
Да, для аппаратной точки добавил регистры в первый пост.Цитата:
На счет аппаратной точки и линии, будите реализовывать ?
Для начала попробуй найти спрайты в игре THREE WEEKS IN PARADISE и прикинуть, как их оттуда достать, преобразовать и печатать из видеокарты. Что изменить в программе. Кусок дизассемблированного текста есть в теме "игры без клешинга атрибутов для видеокарты Метеор". Надеюсь никто не будет против, если мы доработаем эту игру для Метеора ?Цитата:
Если дадите более подробный концепт постараюсь помочь сделать.
- - - Добавлено - - -
Метеор-1 планирую на Циклоне 4.
Память DDR2 самый оптимальный вариант, их FPGA поддерживает гораздо лучше чем не DDR.
То что их реально трудно найти меньше 64мб, не вопрос, много памяти не бывает
Цирк, SRAM это дорогая медленная память, да еще и безумно диких размеров
10 ns - достаточно быстро. 100 MHz. Объем в микросхемах обычно по 512К. Для 1М надо 2 микросхемы. Зато произвольный доступ к ячейкам за 1 такт. Можно аппаратный скроллинг делать и копирование с точностью до пиксела.
Посчитали, что 512К хватит на спрайты и 512К на 2 слоя. Один для фона, один для спрайтов.
Да простит меня автор темы за оффтоп.
Стандарт ZX 15625/50H , только в нем и только на телевизоре или старом мониторе спек показывает динамично эффекты в одно прерывание, ни на TFT,LCD и прочем этого получить нельзя, или полукадры складываются или линии и т.д. , все нет динамики, поэтому я и большинство людей получающих удовольствие от игр и работ на ZX от этого не уйдут, это 99,9%
Далее стандарт ввода флоп или эмуль флопа 640кб , все пишут под него, только под него и ничего кроме него, какое MP3 процессор не играет его, без вариантов, а аппаратное это уже не ZX так как это плеер прикрученный изолентой к ZX,
Золотой стандарт это Pentagon-128 это навсегда, другого не будет поверьте, он бы уже родился если бы был востребован ZX обществом, кто не готов смирится милости просим на эшафот:D Лучшие доработки которые были делались всегда одной двумя микросхемами логики, это смогло прижиться, или взять немо, великолепная доработка 6 микросхем, простота, гениальность.
Вы предлагаете не доработать, а сделать совершенно новый компьютер, который мало что имеет общего с ZX, который я не подключу к телевизору по скарт и не увижу все любимое красиво, и для этого придумана эва, открытая книга со всеми исходниками, переписал плис, и новый комп, но эву я не покупаю потому, что и у нее в последней ревизии отобрали RGB 15625/50H
Теперь к теме, я описал почему карта должна быть в такой аппаратной реализации, это дает нам возможность очень просто переделывать старые игры, а концепты что я описываю идут от наработок с VMG еще в середине 90x, тогда зарождались с появлением симов идеи отдельной памяти для графики, и 20 лет назад эти идеи массово рождались из опыта вот ALEX RAIDER рассуждает об этом 1997 (спасибо Hacker VBI напомнил)http://hype.retroscene.org/blog/misc/336.html а в реализациях которые предлагаете вы на это будут уходить месяцы, да и стоить ваш набор железа будет не 2000p. Сделайте опрос, сколько людей ее купят ?
Я за творчество, идея автора хорошая, я предложил ее улучшить в разы упростив в разы и полностью разгрузив CPU, и хорошо, что автор ведет конструктивное обсуждение, я стараюсь отвечать тем же, и с радостью готов помочь. Если автор так же принимает ваши идеи и реализовавает я только за ! Больше конкретики !
- - - Добавлено - - -
Конечно и на дискету в 640кб это все, давайте пример !
- - - Добавлено - - -
Хорошо, я попробую, связь через ЛС.
- - - Добавлено - - -
Ага 3 бакса на али за 2 штуки по 512кб, как бы не разориться....
- - - Добавлено - - -
Размер SRAM 2 на 1 сантиметр))) Огрмная )))
- - - Добавлено - - -
s_kosorev, Вы уж извините но это элементарная не компетентность с вашей стороны в обсуждаемом вопросе... так абы написать...