Интересно узнать, кто как представляет себе графический режим? Чтобы с ним можно было нормально работать на новом железе. Могу попробовать реализовать это в новой конфигурации. И с паяльником лезть никуда не нужно
Интересно узнать, кто как представляет себе графический режим? Чтобы с ним можно было нормально работать на новом железе. Могу попробовать реализовать это в новой конфигурации. И с паяльником лезть никуда не нужно
Осталось теперь только автора Speccy2010 уломать
alone, Для того, что бы получить объективную картину, надо спрашивать не сферической возможности расширенных режимов!
Во первых указать конкретные модели, с совершенно конкретными расширениями:
ATM-Turbo или ZXEvo(BaseConf) - 320x200
ZXEvo(TSConf) - 360x288
Profi 512x240 (?)
Scorpion GMX - 640x200 (?)
Ещё модели?
А во вторых делать чекбоксы, а не радиобаттоны! У многих людей есть по несколько клонов сразу!
512 х 256 байт или полбайта на точкуСообщение от vlad
плюсы:
widescreen
идеален для программирования на 8-мибитных машинах
или 384 х 256 - как облегчённый вариант .
Последний раз редактировалось shurik-ua; 28.04.2013 в 14:49.
breeze, голосование нельзя изменить. Ты можешь создать своё, сравним результаты. Хотя, конечно, этот форум недостаточно репрезентативен - юзеры ZX Evo в основном зависают на длкорпе, недопц форуме и тслабс форуме.
Я понимаю. Я просто высказал свою точку видения.
Моё отношение, как программиста, к этому вопросу очень простое. Люди вроде меня всё ещё программируют на спектруме потому, что это простая, на 99.9% понятная архитектура, очень неплохо контролируемая программно. Кроме этого, это архитектура, в которой найден разумный баланс между доступным fillrate, размером экрана и объёмом памяти. Примерно по тому же принципу очень активно сообщество Atari 2600. Если брать расширительно, вот ещё один успешный вариант платформы такого рода: http://belogic.com/uzebox/index.asp
Удовольствие от программирования таких систем приходит от осознания ограничений и поиска решений для их обхода. Специально сказал очень широко, чтобы подчеркнуть, что атрибуты - это, конечно, безусловное зло, но ещё и стимул для работы дизайнеров - поиск раскладов экрана, схем выравнивания графики и т.п. Просто тупо добавить к архитектуре цветов - естественное решение на уровне человека, занимающегося железом, но с точки зрения дизайнера или программиста - это просто признание своего поражения. Понятно, что железо можно сделать больше цветов, но тогда делается непонятно, зачем ограничивать себя клоном старой машины, когда есть PC, Mac, совр. мобильные платформы и т.д. и т.п.
Я согласен с тем, что в то же самое время можно думать о развитии ретроплатформы. Ключ, мне кажется, должен заключаться в максимально жёсткой стандартизации. Главная проблема расширенных режимов на спектруме заключается в том, что их 100 разных и все друг с другом несовместимые. Если бы разработчики могли наконец договориться о стандарте на расширение графики и памяти, это могло бы сберечь программистам человеко-годы труда. Ближе других к этому стандарту подошёл пентагон. Есть две главные причины почему программисты подхватили пентагон, а не какой-либо другой клон. 1) отсутствие задержек, как процессора, так и памяти, т.е. наличие чёткой и хорошо предсказуемой времянки и 2) сравнительно большое количество тактов в кадре означает, что это самая мощная машина по fillrate. Очень просто.
Поэтому, задача номер 1: выработка стандарта расширений. Т.е. не просто воткнули ещё десять портов и супервидеорежим, а вводим порт, один для всех, чтение из которого говорит нам "я клон такой-то, версия такая-то". Короче, нам нужно что-то вроде VESA. Или (веса сложная) просто некая общая договорённость, что эти новые режим(ы) поддерживаются унифицированно. Программистов мало, никто не зарабатывает на этом денег, времени ни у кого нет. Решение должно быть простым как три копейки, иначе людям уже и так непросто приходится.
Попробую в порядке бреда набросать, что было бы здорово иметь на расширенной платформе.
В основном речь идёт о графике. Как я уже сказал, нельзя увеличивать цветовое разрешение безнаказанно. Компьютер тут же упрётся в fillrate и много интересного софта для него не напишется. Нельзя по любому поводу сидеть и ждать, пока придут alone coder с lvd и покажут всем что в четверном турбо режиме и с двумя гениальными программистами эту огромную картинку всё же можно расшевелить. Проблему нужно рассматривать в комплексе: видеорежим/процессор/память.
1) Формат графики: никакого полноцвета, растр+атрибуты - оптимальный вариант.
1) Разрешение: 256х192 должно остаться основным режимом. Т.к. у нас проблемы с fillrate, разрешение атрибутов должно быть можно менять плавнее: 8х8, 8х4, 8х2, 8х1. Даже 8х1 (таймекс) уже многовато. Если уж мы не можем делать честный полноэкранный скролл шести килобайт, зачем нам нужно 12 килобайт? Есть смысл подумать также об атрибутах 4х8 и 4х4, - и то и другое может помочь дизайнерам в борьбе с конфликтами цветов, и то и другое быстрее таймекса. Такая гибкость в видеорежимах позволит подбирать режим максимально соответствующий решаемой технической задаче.
2) Адресация: мне кажется, нужно оставить всё как есть. У линейного буфера нет никаких очевидных плюсов. Для конкретных видеорежимов можно (и нужно) думать о том, как сделать адреса атрибутов легко сопоставимыми с экранными адресами. Впрочем, я видел где-то на форуме доп. предложение о чтении экрана со сравнительно произвольных позиций в памяти - хорошая идея, которая будет полезна только при линейной адресации. Тут можно много думать и обсуждать.
3) Цвета. Во-первых, выкинуть идиотское мерцание и сделать честные 15 цветов. Во-вторых, сделать поддержку палитр, причём, желательно таких, которые можно бы было сравнительно "дёшево" менять на лету, скажем, загружать 10 палитр, а потом простой записью в порт включать текущую нужную. Это, например, позволит людям работать в 8х8 режиме с полутонами, а вокруг вешать менюшки в другой палитре. Бордюр должен работать с текущей палитрой.
4) Процессор. Турбо режим это замечательно, но турбо режим с задержками возвращает нас обратно в исходную точку. Поэтому или турбо без задержек или нафиг не нужно такое турбо. Окей, приму поправку, что для 3D турбо очень даже не помешает. В таком случае, турбо должно контролироваться программно, чтобы программа просто могла включить нужный для себя временной режим.
5) О задержках. Вообще, задержки зло. Но была одна полезная задержка в оригинальном спектруме. Было бы здорово, если бы кадровое прерывание придерживало процессор, так что выход из прерывания на halt _всегда_ округлял номер текущего такта до 4.
6) Привязки к отрисовке экрана. Люди использовали порт #FF не потому, что они извращенцы, а потому, что это давало им интересные возможности. Было бы здорово иметь новое прерывание, происходящее, скажем, в момент начала сканлинии содержащей первой пиксел экрана. Ещё лучше, если бы можно было настраивать это прерывание на любую сканлинию.
7) Память. Мне кажется, что более 2-4Мб смысла ставить нет. В принципе, память как таковая в современных клонах не проблема. Но, нужен разумный, с чистого листа, менеджер памяти, чтобы вставлять любую страницу в любую четверть и не вертеть для этого битами. Кроме того, нужно чтобы картинка отображалась с любой страницы, и не обязательно впечатанной в текущее адресное пространство процессора.
8) Самое главное. Запись какого-нибудь специального бита в какой-нибудь специальный порт должна отрубать все эти навороты нахрен до следующей перезагрузки!
https://sites.google.com/site/ulaplus/
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием