Вид для печати
У palsw наверно.Цитата:
Сообщение от zst
Манипуляция с SD FAT16/32 уже не нужна, в новой версии загрузка с ROMS/ZXEVO.ROM на SDHC FAT32. А вот SD разъёмчик нужно будет припаять, или если по профессиональному то написать софт для МК и доработать конфигурацию и загрузчик до версии 0.4.2. Все исходники доступны. Если кого-то просить, то это время, а время...
Пока буду паять разъем и использовать старую прошивку.Цитата:
Сообщение от MVV
Давайте продолжим разработку видеокарты/видеорежима на FPGA и SDRAM. Одной из функций видеокарты является вывод информации о цвете точек на монитор. Благодаря MVV у нас уже настроены частоты и сформированы импульсы VGA развертки - кадровые и строчные синхроимульсы VGA, кадровые и строчные гасящие импульсы. Назовем их кратко KSI, SSI, KGI, SGI.
С частотой кадров 60 Гц нам надо выводить на монитор картинку из буфера экрана. Там она уже готова и имеет такой формат: 320х240 точек по 8 битов на точку. Картинка лежит в SDRAM. Для простоты будем считать, что с адреса 0. Чтобы вывести картинку на монитор надо ее считывать из SDRAM пакетами по 8 слов (16 точек).
Нам нужно подавать на SDRAM адреса точек. Для этого нам нужно два счетчика. Счетчик по-горизонтали будет обнуляться во время SGI=0 и считать когда SGI=1. Этот счетчик будет формировать младшие адреса. Для счета до 319 достаточно 9 битов. Увеличивать счетчик будем каждый 10 такт FPGA (126 MHz).
Счетчик по-вертикали будет обнуляться во время KGI=0 и считать когда KGI=1. Этот счетчик будет формировать старшие адреса. Для счета до 239 достаточно 8 битов. Увеличивать счетчик будем каждую вторую строку VGA.
Теперь нам нужно спроектировать буфер VGA. Для этого создадим в FPGA блок из 16 регистров по 8 бит. В эти регистры будем записывать данные из SDRAM. У нас уже есть счетчик тактов в цикле SDRAM. Используем его для формирования импульсов записи в соответствующие регистры в определенные такты в соответствии с пакетным режимом чтения.
Для записи 8 битов в регистр VGA нам потребуется мультиплексор, который выбирает данные с выходов одого из 16 регистров. Данные с 0 по 7 регистры поступают на входы мультиплексора напрямую, а с 8 по 15 через дополнительные 8 регистров с номерами 16 - 23 по 8 битов. На мультиплексор также подадим 4 младших бита счетчика по-горизонтали. Этот номер точки выбирает, с какого регистра брать данные. Также по фронту старшего из этих четырех битов загружаются данные из регистров 8 - 15 в регистры 16 - 23 и формируется запрос на загрузку следующих данных из SDRAM.
Модель конечно упрощенная. Потом доработаем. А пока будем выводить так. Следующая задача - обеспечить доступ Z80 к SDRAM.
Припаивай разъем, прошивай, возможно больше ничего и делать не нужно будет, там уже в ts-conf всё необходимое есть.Цитата:
Сообщение от zst
Для чтения данных из SDRAM в Z80 нам потребуются адреса с Z80. Для записи данных из SDRAM достаточно восьмибитного регистра. В соответствующий такт цикла SDRAM данные защелкиваются. Потом данные можно будет подать на Z80 через ZX-BUS или его программную модель в FPGA.
Для записи используем адреса и данные с Z80. В определенный такт цикла записи в SDRAM данные подаются на SDRAM. В другие моменты сигналы выбора старшего и младшего байтов в слове сделать неактивными.
Флаги запроса цикла обмена с SDRAM формировать на основе сигналов адреса, MREQ, RD и WR. Как только доступ осуществлен - флаги сбрасывать, чтобы можно было выполнять циклы доступа буфера VGA.
---------- Post added at 11:20 ---------- Previous post was at 11:16 ----------
Я больше люблю проектировать что-нибудь интересное, чем паять.Цитата:
Сообщение от MVV
---------- Post added at 11:31 ---------- Previous post was at 11:31 ----------
MVV, достаточно описанного для кодирования буфера VGA и диспетчера доступа к SDRAM ?
Жуть какая, зачем карте лазить в память компа и конфликтовать при этом с процессором (и какая к черту совместимость после такого)Цитата:
Сообщение от zst
Когда карта может просто следить за шиной и записи в экранную область тихо повторять себе в буфер.
Вот к чему приводит тайловое мышление. :v2_dizzy_facepalm: При том, что блиттер при любой палитре или без оной позволяет наложить маленький фрагмент другой раскраски поверх большого. Или маленький фрагмент другой формы. Или не поверх. Да пусть хоть причёсками отличаются!Цитата:
Сообщение от zst
Cам подход к определению видеорежимов нужен другой. Нужно разделять основу - "общий режим" (максимально близкий к физическому) - и порождаемые в этих рамках частные случаи. Например, PAL имеет 360x288 видимой области (размер точки как у Спектрума если брать) при большой практически доступной глубине цвета (hicolor, допустим). То есть, взяв битмап таких размеров и цветности, можно будет сэмулировать экраны почти всех ретрокомпов домашних или приставок. Нам осталось только решить задачу соответствия пикселей нашего битмапа пикселям экранов этих компов. А для этого понадобятся два блока: (1) транслятор адресов, отображающий адреса любого экрана (например, спектрумовского) в адреса нашего битмапа (при желании со сдвигом окна) и (2) транслятор данных, выполняющий определенные операции с точками битмапа при записи в эмулируемый экран (например, для имитации Спека - групповая запись восьми пикселей соответственно значению атрибута или просто сохранение атрибута). Тут в принципе достаточно только записи, потому что прочитать комп сможет из своей памяти (запись же туда проходит, как и положено). Бордюр можно также имитировать закраской каким-то цветом, при отображении заменяемым. Изменять режим работы этих трансляторов должно быть возможно в любой момент, оставляя старое изображение на экране. То есть, что-нибудь нарисовали в окошке Спектрума, а потом раскладку переключили и рисуем сверху векторную графику с адресами как у Специалиста. Или спрайт можем напечатать уже без клэшинга, по-другому задавая цвета для битов. И конечно, блиттер можно использовать, или даже б-гомерзкие тайлоспрайты (если уж ты кюшать без них не можешь))Цитата:
Сообщение от zst
Если прикручивать проц к SDRAM, и привязываться к синхронной архитектуре, то все пакеты SDRAM нужно выровнять на 142,8571428571429нс, тогда Z80@3.5MHz max, сейчас пакет 119,047619047619нс. Получается 23,80952380952381нс в пакете тупо простой. Делается окно доступа проц-видео-проц-видео... Когда запроса от проца нет, обрабатывается запрос от видео, если нет от видео то обрабатывается запросы DMA...
Можно сделать асинхронный обмен с SDRAM, с ожиданием данных или выборкой из кэш страницы, при их наличии (попадании).
Все мы знаем, как устроен стандартный режим графики. Видеокарта дожна взять байт пикселов, байт атрибутов и преобразовать в 8 точек определенного цвета. Адреса мы тоже знаем где. Не важно, дублируется ли память в видеокарте или основную память компьютера вообще вытащили. Картинка должна получиться одинаковая. Естественно проще разместить память в видеокарте. И она будет общая для Z80 и FPGA.Цитата:
Сообщение от Lethargeek
Проще нарисовать все спрайты с сумками, сапогами или другими предметами гардероба, а потом перекрашивать одной командой или сменой палитры, а не накладывать сверху спрайт сумки. А у спрайтов, соответственно и у сумок, может быть несколько углов поворота и фаз движения.Цитата:
Вот к чему приводит тайловое мышление. :v2_dizzy_facepalm: При том, что блиттер при любой палитре или без оной позволяет наложить маленький фрагмент другой раскраски поверх большого. Или маленький фрагмент другой формы. Или не поверх. Да пусть хоть причёсками отличаются!
Так я почти тоже самое и предлагаю. У нас например буфер экрана 320х240. Мы туда можем записать стандартную графику 192х256 с бордюрными эффектами, а потом вывести с нужной частотой развертки.Цитата:
Cам подход к определению видеорежимов нужен другой. Нужно разделять основу - "общий режим" (максимально близкий к физическому) - и порождаемые в этих рамках частные случаи. Например, PAL имеет 360x288 видимой области (размер точки как у Спектрума если брать) при большой практически доступной глубине цвета (hicolor, допустим). То есть, взяв битмап таких размеров и цветности, можно будет сэмулировать экраны почти всех ретрокомпов домашних или приставок. Нам осталось только решить задачу соответствия пикселей нашего битмапа пикселям экранов этих компов.
Вот каждый режим по-своему и заполняет буфер экрана. А из буфера экрана выводим на монитор. Это проще, чем делать все операции на лету, как при аппаратных спрайтах. И стандартный режим графики очень сложен для вывода и занимает много времени. раньше в играх рисовали почти перед лучем телевизора. Поэтому для совместимости нужно весь кадр со скоростью развертки телевизора выводить в буфер экрана. Только после этого останутся бордюрные эффекты после вывода из буфера экрана на монитор с частотой 60 Гц.Цитата:
А для этого понадобятся два блока: (1) транслятор адресов, отображающий адреса любого экрана (например, спектрумовского) в адреса нашего битмапа (при желании со сдвигом окна) и (2) транслятор данных, выполняющий определенные операции с точками битмапа при записи в эмулируемый экран (например, для имитации Спека - групповая запись восьми пикселей соответственно значению атрибута или просто сохранение атрибута). Тут в принципе достаточно только записи, потому что прочитать комп сможет из своей памяти (запись же туда проходит, как и положено). Бордюр можно также имитировать закраской каким-то цветом, при отображении заменяемым. Изменять режим работы этих трансляторов должно быть возможно в любой момент, оставляя старое изображение на экране. То есть, что-нибудь нарисовали в окошке Спектрума, а потом раскладку переключили и рисуем сверху векторную графику с адресами как у Специалиста. Или спрайт можем напечатать уже без клэшинга, по-другому задавая цвета для битов. И конечно, блиттер можно использовать, или даже б-гомерзкие тайлоспрайты (если уж ты кюшать без них не можешь))
---------- Post added at 12:21 ---------- Previous post was at 12:04 ----------
Да зачем? Поступил запрос от Z80 - следующий цикл работы с SDRAM его. 3.5 МГц хватит - видео же летать будет ! Процу нечем заниматься будет.Цитата:
Сообщение от MVV
---------- Post added at 12:25 ---------- Previous post was at 12:21 ----------
С этим согласен. Но каждый цикл SDRAM: чтение, запись, регенерация, простой - сделать своей длины.Цитата:
Когда запроса от проца нет, обрабатывается запрос от видео, если нет от видео то обрабатывается запросы DMA...
Я пока хочу допилить простое - это работа основного режима 640х480@60Hz 24bpp с SDRAM, дальше сделаю производный режим на его базе - 320х240 и заложить возможность работы конвейера с 24..1bpp. У меня сейчас один транслятор адресов - линейный, всё остальное меня пока не интересует.
Делай сразу вывод из буфера экрана в буфер VGA по предложенному мной алгоритму. Просто точки будут меняться через 5 тактов, а не через 10. Поставь счетчик. До какого числа считать (4 или 9) - брать из мультиплексора для соответствующего режима. Развертка та же, только счетчики точек побольше в два раза (вернее на 1 бит шире). 320х240 и 640х480 имеют общую развертку и очень похожи. Буфер экрана можно общий для обоих режимов взять.Цитата:
Сообщение от MVV
---------- Post added at 12:39 ---------- Previous post was at 12:32 ----------
Палитру 8 бит->9/15/24 бит добавляй после регистра VGA.
---------- Post added at 12:47 ---------- Previous post was at 12:39 ----------
Потом добавим команды для заполнения буфера экрана. Но вывод из буфера экрана на VGA менять уже не надо будет.
---------- Post added at 13:04 ---------- Previous post was at 12:47 ----------
Lethargeek, давай подробнее обсудим идею переделки старых игр для устранения клешинга атрибутов.
Я предлагаю добавить трехслойный режим с линейной адресацией экрана без ускорителя.
Адресация всех экранов с 0 адреса не затрагивает область памяти, где размещена игра. Даже добавляет 8 Кбайт памяти для новых подпрограмм. Этот блок можно будет подгружать дополнительно к игре как патч.
Место в игре, где вычисляюся адреса экрана и подпрограммы печати спрайтов найти можно. Заменить на свои.
Формат битов в байте атрибутов лучше оставить старой чтобы не переделывать графику.
Тайлы выводить в нижний слой.
Вывод спрайтов доработать. Если была маска - теперь вместо нее слой селектор - большая маска на весь экран. Нужно будет вывести прямоугольную область маски в слой селектор и прямоугольную область спрайта в верхний слой. На экране поверх фона будет спрайт произволной формы без порчи цветов фона.
При этом за счет линейной адресации и простого копирования спрайта и маски увеличится скорость вывода графики.
Может появятся и новые игры для этого режима. Графика остается почти такой же, только меняется формат маски для спрайта. Зато более простое вычисление адресов и копирование спрайтов. Даже возможен программный скроллинг двухцветного экрана на 1 линию вверх или вниз командой LDIR/LDDR.
Зачем считать? У тебя частота точек 25.2 почти равна с 25.175.Цитата:
Сообщение от MVV
Все параметры указаны в точках и строках. Такие и делать.
Будут стандартные KSI, SSI, KGI, SSI их подавать на VGA. Гасящие импульсы использовать для сброса/счета счетчиков адреса при выводе в буфер VGA. Что-то слишком сложный он у тебя. Упрости.
Когда мы подсчитали длительность различных циклов в тактах - дальше можно про ноносекунды забыть и не забивать себе голову лишними деталями. Все итак складывается удачно, частота 126 МГц идеально подошла. Погрешность минимальна. Для 3.5 MHz Z80 0%