Интересно узнать, кто как представляет себе графический режим? Чтобы с ним можно было нормально работать на новом железе. Могу попробовать реализовать это в новой конфигурации. И с паяльником лезть никуда не нужно :)
Вид для печати
Интересно узнать, кто как представляет себе графический режим? Чтобы с ним можно было нормально работать на новом железе. Могу попробовать реализовать это в новой конфигурации. И с паяльником лезть никуда не нужно :)
Осталось теперь только автора Speccy2010 уломать :)
alone, Для того, что бы получить объективную картину, надо спрашивать не сферической возможности расширенных режимов!
Во первых указать конкретные модели, с совершенно конкретными расширениями:
ATM-Turbo или ZXEvo(BaseConf) - 320x200
ZXEvo(TSConf) - 360x288
Profi 512x240 (?)
Scorpion GMX - 640x200 (?)
Ещё модели?
А во вторых делать чекбоксы, а не радиобаттоны! У многих людей есть по несколько клонов сразу!
512 х 256 байт или полбайта на точкуЦитата:
Сообщение от vlad
плюсы:
widescreen
идеален для программирования на 8-мибитных машинах
или 384 х 256 - как облегчённый вариант .
breeze, голосование нельзя изменить. Ты можешь создать своё, сравним результаты. Хотя, конечно, этот форум недостаточно репрезентативен - юзеры ZX Evo в основном зависают на длкорпе, недопц форуме и тслабс форуме.
Я понимаю. Я просто высказал свою точку видения.Цитата:
Сообщение от alone
Моё отношение, как программиста, к этому вопросу очень простое. Люди вроде меня всё ещё программируют на спектруме потому, что это простая, на 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/Цитата:
Сообщение от introspec