Блиттер добавим потом. Сначала надо реализовать стандартный экрана + устранение клешинга.
Вид для печати
Блиттер добавим потом. Сначала надо реализовать стандартный экрана + устранение клешинга.
Цитата:
Сообщение от zst
чтобы получилось "проще с устранением клешинга" (и прочие хотелки в первой цитате) - с блиттера надо было начинатьЦитата:
Сообщение от zst
и вопроса "почему в жирный плис не лезет" не возникало бы :rolleyes:
Возьмем более жирную FPGA на 6272 триггеров. С таким количеством триггеров мы уж точно сможем модернизировать старые игры простыми способами. Но придется освоить сложную SDRAM и вывод на мониторы с разверткой FULL HD.
Новые режимы можно будет использовать не только на Спектруме, но и на других компьютерах, где можно добавить один параллельный порт на запись и два сигнала записи. Этого будет достаточно, чтобы записывать параметры в регистры FPGA и память SDRAM.
блиттер кстати очень уживаются с Sdram, блочные операции, с которыми sdram работают просто и быстро
для простой модернизации старых игр нужно не большее количество лишних триггеров, а простая схема модернизацииЦитата:
Сообщение от zst
ты говоришь так, будто несколько видеорежимов - это что-то хорошее :pЦитата:
Сообщение от zst
лучше бы всё было наоборот - чтоб в одном режиме можно было имитировать режимы других компов
Упрощение уже произошло - теперь видеокарте на надо знать, как формируется изображение внутри компьютера и тратить на это свои триггеры и время. Она будет брать готовый цвет RGBI и синхросмесь. А новые слои накладывать поверх готового изображения с компьютера.Цитата:
Сообщение от Lethargeek
А программист будет знать, как формируется изображение в старом режиме и как добавить новые возможности в новом. Часть изображения в игре будет изображаться в новом режиме, а остальное останется в старом. Они будут одновременно на экране. Степень модернизации будет выбирать программист. На любом этапе модернизации будет изображение на экране. А дальше результат зависит от творческих способностей программиста.
То есть будет неэффективно тратить свои ресурсы на убогие и ограниченные слои, на различные схемы чтения и интерпретации содержимого видеобуфера в различных режимах и, кстати, также на соответственные им режимы работы блиттера (если всё-таки захочется сделать блиттер). И при этом в результате будет пригодна лишь для улучшения софта в рамках одной платформы, а не облегчать еще и портирование софта меж любых платформ на совместимых процессорах.Цитата:
Сообщение от zst
Ну, и необходимость втыкать карту еще и в RGB-выход я бы не назвал упрощением :)
А не слишком ли много программисту придётся знать с нынешним нагромождением слоёв и разных режимов? Вообще не пойму, зачем тебе понадобились слои, только цветность ограничивают зазря и усложняют пользование устройством. Можно обойтись прекрасно без них, одним-единственным примитивным растровым массивом, но зато максимальной глубины цвета и максимального размера (в рамках развёртки) и с гибкой схемой записи группы пикселей. Что позволит модернизировать игрушки НАМНОГО проще - так, в простейшем случае (но достаточном, чтобы полностью избавить игру от клэшинга!) программисту нужно знать ТОЛЬКО лишь как выбирать два активных цвета для рисования (неважно даже, на экране или в теневом буфере). Остальных настроек хватит дефолтных.Цитата:
Сообщение от zst
В любом случае, для "модернизации" старья, это же самое старьё придётся ещё и дизасмить, на что далеко не каждый согласится. А некоторые игры принципиально не получится зацветить, только если перерисоввывать всю графику. Так то всяких извратных решений хватает, тот же 16с или вон, ТС конфа или атм3 конфа. Не очень-то заметны тонны адаптированных игрушек под эти режимы.
В "железе" то есть эта "железяка"? Тема уже давно, теории много, но нет главного! " Желёзки".
Соглашусь, что код придется смотреть... Предположим кто-то решил разукрасить игру из прошлого… Потребуется:
1) Переписать загрузочную часть, которая должна определять конфиг компа перед стартом и отравлять в некую видео-карту цветную графику
2) Скорее всего переписать часть основного кода программы, чтобы как-то привязать расширенную графику к нему для управления (без наличия видео-карты действительно сейчас сложно понять, как все будет работать)
При адаптации нужно будет понимать, что куча программ написана очень плотно в памяти… часто то, что было в 48к скорее всего будет проблематично адаптировать. При работе с картой желательно минимизировать количество команд для обслуживания самой видео-карты и работы с ней… Поясню… Любая команда в памяти занимает место, и в некоторых старых играх места для новых команд управления графикой может быть НУ ОЧЕНЬ МАЛО или вообще не оказаться… Так что команды должны быть короткими. Иначе нам придется переписывать код для работы в 128к и более (ну сейчас это типа не проблема … все-таки не конец 80х …), но это значит опять «шкодить» в основном блоке проги…
Мне лично интересно как развивается и ТС-Конфа и другие творческие проекты, но вот что касается TS_Labs и VDAC2… вот ведь как заворачивается история – в самом начале VDAC2 темы там уже промелькнула карточная реализации под Zx-bus… значит вопрос стандартизации начал беспокоить «самоделкиных» :) Но обратившись опять же к истории других платформ, мы увидим, что практически на каждой был период обкатки или даже «ветка эволюции» какой-то конкретной графической карты/чипа. И далеко не все они были совместимы между собой :) Разве что DOS/Windows/Workbench отображались одинаково… ;)
Слои не убогие, они позволят стирать и рисовать часть изображения при передвижении объектов на разных планах.Цитата:
Сообщение от Lethargeek
Особой обработки не надо. Кадр изображения с компьютера надо сохранить до вывода на монитор. Как изображение получается, какие порты использует, какой экран 128K отображается и так далее уже не важно. Есть готовые сигналы RBGI. Мы их берем и записываем в буфер VGA. При этом игра продолжает работать, а ГГ можно изобразить в верхнем слое без клешинга. Ты вроде раньше и писал про простоту доработки игр. Я это и предлагаю.Цитата:
на различные схемы чтения и интерпретации содержимого видеобуфера в различных режимах
. Давай забудем пока про блиттер. Первая ступень - устранение клешинга. Упростим задачу.Цитата:
кстати, также на соответственные им режимы работы блиттера (если всё-таки захочется сделать блиттер).
А то что я предлагаю сделать видеокарту выносной - это не облегчит перенос ее на другие компьютеры ?Цитата:
И при этом в результате будет пригодна лишь для улучшения софта в рамках одной платформы, а не облегчать еще и портирование софта меж любых платформ на совместимых процессорах.
Это проще, чем дублировать формирование стандартного экрана в видеокарте. Сигналы то уже готовые.Цитата:
Ну, и необходимость втыкать карту еще и в RGB-выход я бы не назвал упрощением :)
Для начала можно сделать один дополнительный слой. Там как раз будет массив из точек. А закрашиваться они будут внутри видеокарты в те два или три цвета, которые указаны в палитре рисования. При этом спрайты в игре останутся те же. А видеокарта из байта спрайта и байта маски сама нарисует в массиве новые 8 точек. По-моему идея простая и будет работать эффектно.Цитата:
А не слишком ли много программисту придётся знать с нынешним нагромождением слоёв и разных режимов? Вообще не пойму, зачем тебе понадобились слои, только цветность ограничивают зазря и усложняют пользование устройством. Можно обойтись прекрасно без них, одним-единственным примитивным растровым массивом, но зато максимальной глубины цвета и максимального размера (в рамках развёртки) и с гибкой схемой записи группы пикселей. Что позволит модернизировать игрушки НАМНОГО проще - так, в простейшем случае (но достаточном, чтобы полностью избавить игру от клэшинга!) программисту нужно знать ТОЛЬКО лишь как выбирать два активных цвета для рисования (неважно даже, на экране или в теневом буфере). Остальных настроек хватит дефолтных.
- - - Добавлено - - -
Дизассемблировать игру в отладчике - это достаточно легко. Это намного легче, чем спроектировать, закодировать, отладить игру. Нужно поставить ловушки на запись в экранную область, посмотреть как происходит запись, откуда берется байт спрайта и маски ГГ и записать их по другим адресам. Перед этим выбрать палитру для рисования. Для начала спрайты остаются те же.Цитата:
Сообщение от Sayman
- - - Добавлено - - -
Да, медленно. Каждый день думаю о железе, что-то делаю, прорабатываю режимы, улучшаю элементную базу, конструкцию, доказываю свою правоту на форуме.Цитата:
Сообщение от ZXFanat
- - - Добавлено - - -
Так для этого режимы и прорабатываются, чтобы можно было убрать лишние команды в игре и спрайты оставить те же, чтобы не делать лишнюю работу и не увеличивать объем программы.Цитата:
Сообщение от Lopital
При работе с новым слоем нам не нужны вычисления адреса на экране, чтение оттуда или из буфера, команды or, xor, and с байтом спрайта и маски, запись результата в буфер или на экрана. Нам надо для рисования спрайта главного героя (ГГ) один раз записать координаты в видеокарту и выбрать палитру. Затем читать в цикле байты спрайта и маски и записывать в видеокарту. Ну как - это же намного проще, чем до этого было ?
Убогие! Окно 256x192 c при 1-4 бита на пиксель - это убого!Цитата:
Сообщение от zst
Почему не 16 бит на пиксель в полном PAL-экране 360x288?
(или "круглые" 360x256, что ближе к VGAшному 360x240)
ииии что? С ЛЮБОЙ структурой видеопамяти можно "стирать и рисовать часть изображения"Цитата:
Сообщение от zst
всего-навсего переключать синхронно две своих видеостраницы, куда мы рисуем вывод в страницы СпекаЦитата:
Сообщение от zst
с готовыми глюками и наводками :)Цитата:
Сообщение от zst
Ты предлагаешь НЕУДОБНО и НЕКРАСИВО. Я вот хочу просто рисовать ЛЮБЫМИ цветами, не заморачиваясь переключением слоёв и подбором палитровых цветов. Пусть даже тупо затирая фон - ну и что, Спек же успевал в оригинале фон восстанавливать - значит, и я успею так же в новом режиме, если восемь пикселей можно напечатать с такой же скоростью. Чтобы просто побороть клэшинг, быстрей не нужно (да и не дают слои заметного ускорения, потому что спрайты и в слоях приходится обнулять)Цитата:
Сообщение от zst
И не всё так просто, как тебе кажется. Часто игры сначала рисуют в буфер и фон, и спрайты, а потом всё копируют в экран, аккуратно избегая пересечений с лучом. Нельзя вот так просто взять и независимо несинхронно спрайты кинуть в отдельный слой, рискуя получить мерцание и обрезки. Такой буфер надо как одну цельную картинку формировать.
Непредусмотрительность в отношении блиттера как раз ее усложняет. Давай лучше упростим задачу, выкинув слои и палитры (то есть кучу лишних регистров), и сделаем всего один тупой хайколорный слой.Цитата:
Сообщение от zst
Я вообще-то говорил об упрощении переноса СОФТА с одних компьютеров на другие (например, с Амстрада на Спек)Цитата:
Сообщение от zst
Ничего не надо явно дублировать, будет получаться само собой при дефолтных установках для рисования. А вот как раз "кадр изображения с компьютера сохранить" - это лишний функциональный блок.Цитата:
Сообщение от zst
Но ЗАЧЕМ? Зачем искусственно ограничивать? Почему не рисовать в единственном слое те же 8 точек, но в хайколоре?Цитата:
Сообщение от zst
Вот тут полностью согласен, только адреса оставить оригинальные, пусть их карта пересчитывает сама.Цитата:
Сообщение от zst
- - - Добавлено - - -
так они и неудобны для адаптацийЦитата:
Сообщение от Sayman
Хорошо, оптимизируем графику.Цитата:
Сообщение от Lethargeek
Поверх стандартного экрана дополнительный слой графики размером 256x192 точек по 16 бит на цвет точки. Старший бит - признак прозрачности точки.
Для рисования восьми точек надо записать в видеокарту два байта. На каждую точку получится по 2 бита на цвет - 4 цвета. Для указания цвета для каждой комбинации надо 8 регистров.
Регистры координат:
XL, XH, YL, YH
Регистры цвета:
COLOR_00_L, COLOR_00_H,
COLOR_01_L, COLOR_01_H,
COLOR_10_L, COLOR_10_H,
COLOR_11_L, COLOR_11_H,
Регистры спрайта:
SPRITE_BYTE,
MASK_BYTE
zst, хоть убей, не понимаю, каким образом карточка прикрученная к RGB выходу будет выгребать отдельно спрайт ГГ и отдельно весь остальной уровень игрушки?!
при разрешении 256*192 достаточно одного 16битного регистра (или двух по 8), т.к. максимальные координаты по XY не выходят за пределы 8 бит.Цитата:
Регистры координат:
XL, XH, YL, YH
а почему? что там такого неудобного? как для тебя (или по твоему мнению) было бы удобнее для адаптации старых игр? Было бы, конечно, интересно увидеть цветного, скажем, exolon`а. Есть его ПЦшный ремейк - exolon dx, но это для пц, а значит уже немного не то. Были бы цветные спрайты в доступе для него, уже бы под спринтера переложил его.Цитата:
так они и неудобны для адаптаций
Мне кажется, что самое простое управление графикой как раз у спринтера. Но возможно мне это только кажется. Не требуется вообще никаких расчётов координат на экране в адрес (кроме разве что x_coord+screen_start_adr). За координату Y работает порт. Экран в любоей окно проца втыкается. Для программиста, как я думаю, проще уже некуда. АТМ и профи (и судя по мануалам и ТС конфа) по строению экрана выглядят просто монстрами какими-то. Даже 128й экран)))
Вот в таком случае и приходит на помощь еще один слой. Сначала отображается первый слой, а во втором рисуется ГГ. По INT первый слой выключается, а второй включается.Цитата:
Сообщение от Lethargeek
Кроме RBGI мы подаем с компьютера еще 8 битов данных и 2 сигнала записи. Стандартная графика просто загружается для дальнейшего отображения на VGA. В основном это фон и второстепенные персонажи. ГГ рисуется в новой графике.Цитата:
Сообщение от Sayman
Я просто подумал о будущем. Вдруг захочется рисовать на всем экране 1920x1080 или части размером 320x240.Цитата:
при разрешении 256*192 достаточно одного 16битного регистра (или двух по 8), т.к. максимальные координаты по XY не выходят за пределы 8 бит.
Да не нужен никакой "стандартный" экран! RGB может быть испорчен, нестандартно сдвинут по тактам, или вообще не предусматриваться в компе (например, в новом клоне, задуманном как раз для работы только с внешней видеокартой). И опять мелкое окошко в центре экрана! Не, надо в полном цвете рисовать по всему экрану телевизора/монитора, а растр Спектрума при желании отображать на нём с любым смещением.Цитата:
Сообщение от zst
Ничего не понял, почему опять "2 бита - 4 цвета", если выше пишешь про хайколорный слой.Цитата:
Сообщение от zst
Давай так. Чтоб понятней было, я сперва опишу схему совместимости с экраном без атрибутов. То есть монохром 256x192 (типа Спек без атрибутов) или быкашные постоянные 4 цвета в режиме 256x256 итд; и чтоб картинка с карты после резета ничем не отличалась от картинки через стандартный выход, хотя пиксели на самом деле там хайколорные.
Итак, видеобуфер карты - простой массив (например, размером 360x256); один пиксель - одно 16-битное слово. Для отображения читается в жёстком цикле. Никаких других режимов, слоёв, палитр. Тут всё максимально просто, как только можно.
Конкретная физическая раскладка памяти видеокарты нам не важна. Мы рисуем на виртуальном логическом экране, а не по физическим адресам. У видеокарты есть блок-транслятор, который пересчитывает адрес каждой группы из 8 (или 4 в случае двухбитного цвета) пикселей в логической раскладке (которая может совпадать со стандартным видеобуфером компа, а может и не совпадать, это совершенно неважно, имитировать мы сможем любой экран) в физический адрес 16-битного пикселя, геометрическое раположение которого на экране совпадает с расположением левого края этой группы (с учетом сдвига виртуального экрана, как нам захочется).
Соответственно, при записи байта в адреса виртуального экрана изменяются несколько (до 8 для монохрома) хайколорных пикселей физического. Изменяются в соответствии с заданной "активной палитрой" (прошу не путать с физической палитрой, это скорей таблица для распаковки) из 2 (или 4 итд) "активных цветов". Причём один из них можно задавать и "прозрачным" (да хоть все, только смысла в этом особо нет), чтобы не менять физический пиксель.
После резета все цвета "активной палитры" совпадают со стандартными системными цветами, а раскладка виртуального экрана соответствует стандартной раскладке, потому при работе старого софта картинка ничем не будет отличаться от картинки со стандартного выхода. До тех пор, пока мы не нарисуем что-нибудь в другой раскладке и/или с другими цветами, причем старое изображение не испортится (кроме пикселей, которые мы целенаправленно перекрасим).
Времени свободного очень мало. В следующий раз расскажу, как выкручиваться при наличии атрибутов, изменение которых приводит сразу к смене цвета десятков пикселей. Но хотя бы это сейчас понятно?
В игре, которую мы дорабатываем для устранения клешинга, есть спрайты с маской.Цитата:
Сообщение от Lethargeek
Для рисования 8 точек используется 2 байта. Это 8 * 2 = 16 битов.
На одну точку приходится 16 / 8 = 2 бита.
2 бита дают 4 комбинации: 00, 01, 10, 11.
Каждой комбинации ставим в соответствие 16-битный цвет.
0, 1 или 2 цвета из четырех можно выбрать прозрачными. Это дает разные способы закрашивания.
Этими активными цветами закрашиваются 8 текущих точек в слое с 16-ти битными цветам.
Два из четырех цветов выбираем прозрачными.
Они устраняют клешинг.
Теперь понял ?
Можно эти цвета назвать палитрой для рисования.Цитата:
Соответственно, при записи байта в адреса виртуального экрана изменяются несколько (до 8 для монохрома) хайколорных пикселей физического. Изменяются в соответствии с заданной "активной палитрой" (прошу не путать с физической палитрой, это скорей таблица для распаковки) из 2 (или 4 итд) "активных цветов". Причём один из них можно задавать и "прозрачным" (да хоть все, только смысла в этом особо нет), чтобы не менять физический пиксель.
- - - Добавлено - - -
Разрешение монитора 1920*1080. Если масштаб х4, то будем рисовать на экране размером 480х270 точек ? А как рисовать ГГ поверх старого экрана, если у них координаты начала не совпадут ?Цитата:
Сообщение от Lethargeek
- - - Добавлено - - -
Да я почти тоже самое и предлагаю, только не портить стандартный экрана, а новую графику добавить поверх старой.Цитата:
Сообщение от Lethargeek
что то я не понимаю, планируется захватывать экран и выводить поверх картинки свою графику? это блин стремное решение, мало каких аппаратных глюков в компьютере к которому подключают.Цитата:
Сообщение от zst
Да и банально, нельзя таким способом адекватно фон разукрасить, а такой огород ради спрайта ГГ, извините, но блин смешно
Эх, кто бы присоединил к Z80 вместо графики графический модуль на базе самого недорогого но достаточно мощного процессора ARM :) ценою рублей в 200 при заказе в мелком пакете из Китая.
ARM за 200р видео на тв/монитор выводить не умеет
Меня сбило с толку "4 цвета", когда на самом деле "2 плюс прозрачный". Эта схема непригодна для случаев, когда маска выводится отдельно в оригинале (иногда вообще у разных спрайтов бывает общая). Лучше вывести два раза "цвет + прозрачный", а для настоящих трёхцветных спрайтов хранить по 4 пикселя в байте (всё равно тогда их надо перерисовывать).Цитата:
Сообщение от zst
Вообще как-то странно слово "палитра" употреблять для непалитрового режима...Цитата:
Сообщение от zst
Ты что, делаешь девайс для одного конкретного монитора? :rolleyes:Цитата:
Сообщение от zst
Рисовать мы будем на (почти) всей площади zx-экрана вместе с бордюром.
А режим апскейла конечный юзер сам себе по вкусу пусть выбирает.
А что мешает рисовать ГГ относительно адреса начала спектрумовского окна?Цитата:
Сообщение от zst
Однократно вычислив этот адрес для любой логической раскладки координат ГГ.
А когда рисуем ВСЁ в стандартной раскладке, то и вычислять ничего не надо.
Или даже в нестандартной, но совпадающей в начальной точке с zx-экраном.
Как же ты не будешь "портить стандартный экран", если перестанешь рисовать в него спрайты, и он станет отличаться от оригинала из немодернизированной игры? Если ты хотел сказать "не портить ФОН", то какой сакральный смысл не портить его, если даже оригинальная игра на оригинальном медленном Спеке успевала этот фон восстанавливать, а ты вместо фона портишь уже слои? Зато отказавшись от подложки стандартного экрана в пользу формирования его хайколорной копии, мы получим доступ к старой картинке в памяти видеокарты (чтобы, например, иметь возможность кусок скопировать и провести над ним любые манипуляции).Цитата:
Сообщение от zst
Тогда будем называть "активные цвета".Цитата:
Сообщение от Lethargeek
Да, для разрешения 1920х1080.Цитата:
Ты что, делаешь девайс для одного конкретного монитора? :rolleyes:
После сброса координаты нового и старого экрана совпадают.Цитата:
Рисовать мы будем на (почти) всей площади zx-экрана вместе с бордюром.
А режим апскейла конечный юзер сам себе по вкусу пусть выбирает.
А что мешает рисовать ГГ относительно адреса начала спектрумовского окна?
Однократно вычислив этот адрес для любой логической раскладки координат ГГ.
А когда рисуем ВСЁ в стандартной раскладке, то и вычислять ничего не надо.
Или даже в нестандартной, но совпадающей в начальной точке с zx-экраном.
Фон лучше не портить. Рисовать в своем слое. Не надо будет разбираться, как рисуется фон. Других задач хватит во время доработки игры.Цитата:
Как же ты не будешь "портить стандартный экран", если перестанешь рисовать в него спрайты, и он станет отличаться от оригинала из немодернизированной игры? Если ты хотел сказать "не портить ФОН", то какой сакральный смысл не портить его, если даже оригинальная игра на оригинальном медленном Спеке успевала этот фон восстанавливать, а ты вместо фона портишь уже слои? Зато отказавшись от подложки стандартного экрана в пользу формирования его хайколорной копии, мы получим доступ к старой картинке в памяти видеокарты (чтобы, например, иметь возможность кусок скопировать и провести над ним любые манипуляции).
- - - Добавлено - - -
Можно ограничиться стандартным экраном вместе с бордером 320х240 точек. Тогда на мониторе это займет 1280х960 пикселей.
Увеличение х1, х2, х3, х4 можно будет выбирать в экранном меню видеокарты.
Без правильного схемного обрамления и firmware конечно не сумеет :)Цитата:
Сообщение от s_kosorev
А что скажете про использование Z80 в качестве видеоконтроллера? Или такого тоже не бывает?
http://mdesk.ru/zx-next/
А про электронные книжки, которые много чего умеют?, в них как раз 200рублевые ARM вовсю и использованы.
Примечательно что на этих чипах китайцы ставят свою маркировку S200.
Сумеет или уже хоть что-то умеет ? :
https://sohabr.net/post/211753/
http://we.easyelectronics.ru/STM32/g...tovleniya.html
Исправь ник Lethargeek'а ;-)Цитата:
Сообщение от zst
Внимательно читаем, я написал о выводе на тв/монтор, которые кардинально отличаются от вывода на матрицы со своим фреймом, армы за 200р, на tft матрицы, если полное обновление экрана, хорошо если 5гц фреймрейт выжмутЦитата:
Сообщение от perestoronin
И в чём смысл видеокарты такой тогда, если к ней что хочется не подцепишь?Цитата:
Сообщение от zst
Ну, и в общем, неправильно подгонять логические режимы под (не всеми) любимые физические параметры.
Уже раз исторически Спек разработан под телевизор, то нужно думать, как стандартный PAL получше отобразить.
И что такого? Для виртуального логического экрана после сброса даже адресация совпадает!Цитата:
Сообщение от zst
Ты выдумал "проблему", которой нет. Обоснуй, ПОЧЕМУ "фон лучше не портить", ЕСЛИ ОН ВСЁ РАВНО ПОРТИЛСЯ В ОРИГИНАЛЬНОЙ ИГРЕ.Цитата:
Сообщение от zst
Никакого "разбираться, как рисуется фон" НЕ НАДО, как он раньше оригинальной процедурой рисовался, так пусть и будет.
Нет стандартного бордюра = НЕТ СОВМЕСТИМОСТИЦитата:
Сообщение от zst
А можно обойтись без чрезмерных, лишних ограничений? Почему хотя бы не 360x256/225?Цитата:
Сообщение от zst
(что впишется в распространённые 1280x768 и 1440x900, а 360x240 вообще VGA-стандарт)
Чтоб хоть строка с бордюром влезала полностью.
Нафига уродовать стандартный экран и херить совместимость ради апскейла? (кратного, чтоб заметней были пиксельные ступеньки))) Нафига прибивать апскейл гвоздями к этому несовместимому инвалиду? Ни апскейл, ни конвертер 50/60гц, вот это всё, что полностью "снаружи" можно приделать - не должны ни на совместимость, ни на новые программы влиять никак.Цитата:
Сообщение от zst
В Reverse и Unreal стандартный экран с бордюром имеет размер 320х240 точек и выглядит достаточно хорошо:
http://savepic.ru/9511474m.png
Сначала я собирался использовать разрешение VGA выхода 1280х1024 пикселов. Но при тесте выяснилось, что монитор и телевизор с разрешением 1920x1080 растягивают и портят изображение. Пикселы получаются нечеткие разной яркости. А цель сделать пикселы четкими одинакового размера. Если подавать родное разрешение монитора, то все четко.
В ZX Spectrume экран состоит из 6144 байта пикселов и 768 байтов атрибутов + цвет бордюра из порта FE. Массива 320х240 из точек независимого цвета нет. Цвет каждой точки (цифровые сигналы RGBI) формируется в момент вывода на телевизор синхронно с разверткой телевизора.
Видеокарта будет вместо телевизора принимать эти 4 бита станадартной графики и синхросмесь SYNC и преобразовывать по определенному закону в цвет из 16 битов. Затем она будет анализировать 16-ти битный цвет точки в этом же месте экрана из слоя с новой графикой. После простой операции результирующие 16 битов точки записываются в буфер VGA. Там просто массив 15-ти битных точек - результат наложения новой и стандартной графики. Из этого буфера с заданным пиксельклоком по 15 битов на точку данные будут выводиться ЦАП по схеме R-2R по 5 битов на каждый канал RGB, а с него три аналоговых сигнала RBG и два KSI_VGА и SSI_VGA подаются на монитор через разъем VGA.
Все виды видеоустройств и все разрешения предусмотреть сложно. Выбран аналоговый выход через разъем VGA на мониторы и телевизоры с родной разверткой FULL HD 1920х1080 60 Hz. Это наиболее распространенная развертка на данный момент. Дополнительное разрешение потребует дополнительный вход PLL в FPGA для формирования требуемого пиксельклока и усложнит видеокарту.
- - - Добавлено - - -
Стандартный экран остается, стандартный INT остается. Увеличение выбирается в ЭКРАННОМ МЕНЮ ВИДЕОКАРТЫ с помощью кнопок на корпусе видеокарты. 60 Hz и разрешение для монитора делаются аппаратно видеокартой.Цитата:
Сообщение от Lethargeek
- - - Добавлено - - -
Сигналы будут использоваться цифровые, как в VGA&PAL.Цитата:
Сообщение от s_kosorev
Раз у нас при вводе 4 бита перекодируются в 16 битов - мы добавим команду для замены стандартной аппаратной палитры на свою для перекодирования 16 стандартных цветов в другие.Цитата:
Да и банально, нельзя таким способом адекватно фон разукрасить, а такой огород ради спрайта ГГ, извините, но блин смешно
речь к примеру о таких нюансах как, тут много можно найти тем про наладку, где атрибуты и пискели расходятся, величина расходжения разнаяЦитата:
Сообщение от zst
надо ремонтироватьЦитата:
Сообщение от s_kosorev
Для тупых загрузочных полосок - может, и "достаточно хорошо", а для текста или эквалайзера на бордере - НЕдостаточно!Цитата:
Сообщение от zst
И как много ты проверил разных мониторов и телевизоров? И почему решил что всем понравится только то же самое, что тебе? Мне вот нравится, как мой телек апскейлит PAL, а как раз в эмуляторах без сглаживания с кратным увеличением слишком резкая картинка и неприятная.Цитата:
Сообщение от zst
А ничего, что в оригинале даже через RGB пикели на ТВ были заметно смазанные?Цитата:
Сообщение от zst
И часто графика бывает на то рассчитана.
Это РАСТР ВИДЕОБУФЕРА состоит из 6144 байтов пикселей и 768 байтов атрибутов, а ЭКРАН состоит из растра и ПОЛНОГО БОРДЮРА (кстати, разного размера в разных моделях, даже фирменные 48 и 128 не совпадают, уж не говоря про всякие клоны)Цитата:
Сообщение от zst
А также RGB даже у фирменных компов тоже разные (bright может (не) быть отдельным, и синхры тоже)Цитата:
Сообщение от zst
Да я понял, ЧТО ты собираешься сделать, только не пойму НАФИГА.Цитата:
Сообщение от zst
Ненадёжно и неинтересно для программиста.
Именно, и поэтому нужно соответствовать PAL стандарту, а не подгонять под первые попавшиеся устройства.Цитата:
Сообщение от zst
Телевизоры прекрасно понимают 50гц и апскейлят PAL даже в более чёткую картинку, чем когда-то было на CRT.Цитата:
Сообщение от zst
В новых телевизорах, а не в тех, которые не жалко переквалифицировать в ретромоник.Цитата:
Сообщение от zst
Во всяком случае, представительной статистики у нас нет.
Ты апскейлером усложняешь карту намного больше.Цитата:
Сообщение от zst
Нет, неправда, остаётся только его ОБРЕЗОК (притом не лучший из возможных обрезков)Цитата:
Сообщение от zst
Ага, и стандартный растр, гуляющий по вертикали и горизонтали в разных моделях))Цитата:
Сообщение от zst
Но зачем к нему в нагрузку пихать нестандартное несовместимое разрешение?Цитата:
Сообщение от zst
Получается, что хвост виляет собакой.
Ты о чём, в них как раз аналоговые сигналы))Цитата:
Сообщение от zst
Снова ограниченное решение, смысл имеет в качестве простенькой отдельной примочки.Цитата:
Сообщение от zst
да нечего там ремонтировать, они от рождения кривые, зависят от серий микросхем итд, конденсаторами потом сигналы ровняют, идельно не выровнятьЦитата:
Сообщение от zst
Если все так криво - надо подать RGBI и SYNC через триггер TM9 или регистр ИР23. На тактовый вход подать 7 МГц. И будет все ровно.Цитата:
Сообщение от s_kosorev
- - - Добавлено - - -
Что-то ты видишь одни недостатки. Я не могу сделать идеальный вариант, который подойдет всем и по всем параметрам.Цитата:
Сообщение от Lethargeek
Я хочу сделать один из вариантов, который подойдет определенному кругу любителей Спектрума.
А "VGA&PAL" - это видеоконвертер/скандаблер.
Можно окно для ZX Spectrum сделать 360х270 точек. При увеличении в 4 раза будет закрашено 1440х1080 точек из 1920х1080.
Тогда уж 360х264, чтобы было кратно 8 (и по вертикали).Цитата:
Сообщение от zst
Николай.
Давайте 360x256.Цитата:
Сообщение от Lethargeek
не, я вижу перспективы прежде всего, потому бесперспективные решения мне не нравятся :)Цитата:
Сообщение от zst
но! ведь можно хоть примерно его представить - "идеальный" окончательный вариант!Цитата:
Сообщение от zst
пускай полностью его ты сделать не сможешь, пускай даже после не доделают до него
но к нему всегда следует стремиться и выбирать пути, к нему приближающие
а не тупиковые варианты и решения, в будущем способные помешать
Цитата:
Сообщение от zst
360x256 - это растр видеобуфера, все хранимые статичные пиксели (часть которых ради совместимости может притворяться бордюром)Цитата:
Сообщение от zst
но никто не мешает нам дополнять экран до целого PAL-кадра пустыми (динамически окрашенными) бордюрными строками, если место есть
и напротив, растр слегка обрезать, когда нет места (хотя по мне - пусть устройство занимается обрезкой и масштабированием)
также растр в перспективе можно без проблем расширить горизонтально (адреса у старых пикселей будут прежние)
Скрытый текст
надо сказать, что c горизонтальным разрешением реала полной ясности нет
в фирменном ZX-48 в строке 48+256+48=352 видимых пикселя на 224 такта:
http://www.worldofspectrum.org/faq/r...htm#ZXSpectrum
у ZX-128 уже 228 тактов в строке, но неясно, шире ли видимый бордюр
хотя, зачем иначе понадобилось удлинить строку ровно на 4 такта = 8 пикселей
может, так Спектрум подтянули к PAL стандарту 720x576i (= 360x288 @50гц) ?
у Скорпиона отображается 368 пикселей, у Пентагона вообще 384:
http://www.worldofspectrum.org/rusfaq/[свернуть]
- - - Добавлено - - -
о "расширенных" атрибутах и бордюре напишу позже (завтра или послезавтра, как время будет)
у 48ой модели два кварца, у 128 (для улучшения качества изображения) один.Цитата:
Сообщение от Lethargeek
размеры экрана как-то связаны с-этим моментом
При смене частоты кварца изменили количество точек в строке для того, чтобы частота строк осталась близкой к стандарту для телевизора.
Вопрос в том, что растягивают эти 4 такта - рамку слева, справа, обе поровну или промежуток гашения? И как это может отразиться на совместимости. Я так понимаю, лишь бы совпадала частота строк и начало спектрумовского растра приходилось на определённые такты, а что пикселей в строке покажем немного больше - почти не важно (в крайнем случае, процедура сброса видеокарты может тупо чёрным закрасить лишние).
У всех компьютеров это сделано по-разному. Например, в ATM, ZX-EVO, PENTAGON-128. Надо предусмотреть процедуру центровки экрана. В стандартном экране сделать бордюр другого цвета, а в режиме новой графики нарисовать рамку размером 256х192 точки. И кнопками сдвигать стандартный экран в окне 360х256 до совмещения рамки и бордюра.Цитата:
Сообщение от Lethargeek
В принципе рамку можно нарисовать в экранном меню видеокарты. А атмега затем должна будет запомнить это смещение в своей EEPROM.