Это ТЗ на интерфейс :) - Я хочу именно так графикой управлять. Нужно же, чтобы программисту удобно было писать, а не железячнику схему разводить.

Мне вот например нравится предложение captain cobalt. Очень удобно вообще, и для спрайтов, хранимых вертикально в частности. При 256 линиях и 4х3 получается горизонталь 340.

Это предложение мне тоже нравится, только как же 340-то?
256x256 ибо не влезает 340 в 8-мибитный регистр :) .

Горизонталь 340 точек - это всего 42.5 :) байта в битплановом режиме.
384 точки - это всего 48 байт. 352 - 44 байта.

А в линейных режимах всяко придется банками щелкать (номер банка хранится отдельно).

А и плевать, что 340 в байт не влезает. Оно при таком раскладе и не особо нужно. При расположении данных в памяти вертикально, получается вплоне себе линейная адресация. Причём байт из столбца может быть как на знакоместо, так и на другие величины, на 1,2,4 пиксела например. Но тут уж памяти надо много. И для переброса 340х256@256цветов экрана за прерывание потребуется навскидку мегагерц эдак 50.
Я бы не хотел работать с битпланами, но если приглядеться преимущества могут быть и тут. Например изменяющееся число этих самых планов. ТЕ хотим ЧБ - 1, 4 цвета 2 и тд вплоть до 32бит =)

Это я прогнал :(

Да работать с 85к видеоданных в 64к адресного пространства тяжеловато :)

Если битпланы экрана расположить в разных страницах, то работать с ними можно, только быстро не получится.

Я, вот, предлагал экраны наиболее близкие к стандартному, с которыми можно работать доволно быстро, и открывать почти с произвольного места. Последнее, учитывая желание иметь многозадачную ОС на спектруме, просто не заменимо. Так каждая задача может открыть свой собственный экран, а не перекидывать данные туда-обратно в #4000 или #C000.

У меня появились некоторые соображения насчет видеоадаптера.
Многие говорили, что на спектруме удобнее перемещаться от строчки к строчке и от столбца к столбцу простым INC/DEC H/L. А что если в видеоадаптер ввести порты указателя начальной точки. затем подавать команды видеоадаптеру аналогичные INC/DEC H/L, данные записывать тоже аутом, при этом ВК будет знать в какую сторону ему перемещаться после записи данных. Также предлагаю ввести еще одну команду аналогичную PUSH POP для координат и регистры размера загружаемой области. Таким образом мы получаем чудовищное быстродействие... записав в ВК размер пересылаемой области и её координаты на экране (и указав номер видеоэкрана) мы делаем простой LDIR и данные прорисовываются быстро и красиво :-) также можно ввести регистр прозрачного цвета. и при копировании прозрачные точки будут игнорироваться. Еще можно прикрутить вместо LDIR более шуструю весч и пересылать данные еще быстрее...
Как будут работать PUSH POP: мы указываем начальную координату и кидаем в стек. потом занимаемся прорисовкой чего либо. достаем координаты со стека смещаем их куда нада опять кладем на стек рисуем дальше и так далее.
Также подумываю над тем, чтобы впиндюрить в ВК алгоритм прорисовки линий, многоугольников и окружностей, еще можно подумать над их заливкой.
Хотелось бы узнать Ваши предложения и пожелания.

P.S. работа над клоном и ВК идет полным ходом... макетная плата запаяна, байтбластер работает. Позавчера получил на мониторе 640*480*60Гц (другой кварц не нашел) и цветные полосочки :-) было приятно. По возможности скоро выложу фотки девайка и экрана который получил :-) Скорее всего это будет уже после НГ как отосплюсь.

LD (rr),A - 7T
LD (HL),r - 7T
+INC rr - 6T
Это в сумме 13Т
OUT (C),r - 12Т + автоинкремент - разница невелика, а удобство сомнительно. По поводу "PUSH/POP" - это же DMA! По остальным соображениям получается блиттер с колоркеем. Но многим нравится делать всё в софте.

стек будет организован в самом ВК :-)

Или после настройки палитры - например два слоя по 4 цвета.

Еще как получится, лишь бы руки откуда надо росли.

Ну прям себя год назад вспомнил... :)

OUT суксь, он регистр BC сожрет, да и делать сможет немногое. А INC/DEC тем и хороши, что в любой момент можно сменить направление, юзать любой динамически вычисляемый шаг, выборочное стирание/заливка текстурой, выборочное чтение с экрана с проверками итд - что в башку взбредет.

Всего лишь небольшой прирост за счет оптимизации работы с регистрами (меньше сохранений/перезагрузок). Да и то еще не факт.

Зачем тут ldir? Куда он писать будет половину рабочего времени?
Тогда уж давать команду ВК схавать N следующих байт с ШД (кроме циклов M1), загнать в SP указатель на блок и N/2 раз выполнить POP.

DMA называется. В продвинутом варианте - правильно, блиттер.

Зачем обратно вытаскивать-то? Хто "смещает"? При перекачке данных чисто процессором смысла не вижу. Вот для блиттера была бы полезная штука, но только там не стек нужен, а очередь (и какой-то стандартный формат блиттерных команд).

Даже куча реализованных "в железе" возможностей не оправдают неудобную раскладку экрана и разрешение "от фонаря". На блочных пересылках и векторной графике свет клином не сошелся, Спек - не приставка.

Попробуй начать с простого игрового режима.
Игровой режим можно особо не выдумывать, берёшь режим P1 из
даташита по v9990. Только под своё разрешение 640*480*256@60,75-85Гц.
В P1 отображается 2 тайловых слоя, +спрайты.

Потом уже можно и о примитивах (с заливкой) подумать.

Ребят,
чего-то я никак не уразумею, о чём вы здесь толкуете. Какое отношение разрешение 640x480x256 имеет к Спектруму?!

Вот ещё новогодний вопросик ... :)
Что с Basic делать? Нужен ли он?

Только как картридж для совместимости

новогодний юмор:

Изначально не задумывался басик как токовой. Должен быть тапе лоадер и всё. А потом подумали, и решили, что если у человека нет ни одной кассеты что ему делать с эти спектрумом. И придумали Басик. поскольку остались неиспользование кнопки не клавиатуре (не порядок) придумали еще команды CAT MOVE ERASE и.т. Для чего они были нужны никто еще пока не знал, но всё равно решили оставить. Прошли годы, пользователи начали задавать вопрос. а для чего все эти команды. и тогда придумали Interface 1 и TR-DOS. Снова проходят годы, прикручивают 128 КБ памяти и Басик 128 с тейп лоадером. Люди в недопонимани. Если есть уже TR-DOS и Интерфейс 1, зачем басик и Тапе лоадер?
Настали наши дни. Прикручивают уже всё что угодно к бедному спектруму... и 4 МБ Рамы и HDD и видеокарты с 512к и более... а тапе лоадер и басик остался? вопрос:
Кто еще грузит игрушки объёмом 600К с кассеты на LOW?
Может кто-то грузит CP/M с кассеты?
Или кто-то доастал 120часовую аудиокассету, записал туда Демо видео от NedoPC Group и смотрит?
Кому-то еще нужен супер медленный Басик, для написания таких же реактивных демок?

Никакого. Так же как и Спек к чему либо кроме игр (с таким то экранчиком).

Первые шажки :-)
 

НГ позади и сегодня великий день :-) на экране монитора сформирован растр 512/384. на картинках - фотки девайса и полученной "радуги" :v2_clapp:. Продолжаю рабоать... процесс пошел.

(соори за карявые фотки... больше фоткать пока нечем :v2_cry: )

Похоже парни заигрались, а писишка не дает им покоя (как вариант пытаются переманить оттуда когонить... ) .. если нужны навороченные видеорежимы, то круче Спринтера у них не получится.. а то что предлагают - концептуальная ошибка и к спектруму не относится.. получится скорее "мы воткнули вместо пня Z80 и тормознули..."

Опытным путём на обчном CRT были получены стандартные спектрумовские видеорежимы. При этом кадрова частота была от 50 до 150 гц.
Это даёт некоторую писчу для размышлений...
Вобще должен заметить что LG StudioWorks 575N выводит любую картинку, если его кадровые и строчные частоты находятся в диапазоне допустимых значений!

завтра попробую получить на экране какуюнить картинку (отличную от полосочек и квадратов...

To be continued!

P.S. 2 CHRV память пришлось подключать к 3.3В, на 5В сильно грееца!

Также и Error404.
Согласен на 150%, точнее и не скажешь. Я-то по простоте душевной думал, что, наконец-то, хорошую шуструю и удобную машинку склепают.
А тут... 300кБ видеоданных гонять на Z80 с 64кБ адресного пространства?! Похоже ребята живут где-то за пятым кольцом Сатурна, если не дальше. Я разочарован :v2_cry:
Ну ничего, у меня тут знакомый схемотехник скоро освободится от диссертации, - будем своё с нуля делать.

Интересно, а что Вы планируете делать на 256х192? Опять играться? Зачем тогда городить огороды - берите Ленинград1 и играйтесь. А экран, кстати, не обязательно должен быть ТОЛЬКО многоплоскостным и, соответственно, требовать перекачивания больших объемов графики. Можно сделать и режим с атрибутами - область цвета единожды покрасить (и изредка подкрашивать при открывании окошек), а в области графики (к примеру, 512х384=16к) организовать нормальный текстовый экран, а не спектрумовский недоделанный.

Эээ... вам нужен стандартный Spec только ускоренный на 500%? Берем PC + EMuzWin, делаем ускорение 500% и вуаля получаем, что хотели.

P.S.
Вообще хотелось бы машинку не хуже, чем Sinclair QL, а может и лучше, иначе варить всю эту кашу нет никакого смысла.

http://www.q40.de/q40.dedownload.html

http://q40.de/download/Q60.jpg

Ребяты!!! 640 на 480 - это макс. Если вы считаете что ваше приложение будет на нем работать без тормозов - используйте, если нет - тогда уменьшайте.
Посмотрите на многие аркадные игрушки: Экран статический, подвижной графики менее 20% экрана. В графическом редакторе работать тоже можно. Если это разрешение вы считаете не нужным - не используйте, вот и всё.
Что вы привязались к 640 на 480. Есть и другие режимы забавные. например: 320х240, 320х200, 256х192 как 1,2,4,8 бит на пиксель, с палитрой/без, с атрибутами и без них... я делаю гибкую систему. Можно задавать свои видеорежимы например 64х64 пиксела :-) с бордюром по 288 208 по горизонтали и вертикали соответсвенно. Как фантазии хватит и как позволит ваше логическое мышление. Теоретически (еще не проверял) можно получить видеоразрешение (максимально возможное) 1024х1024х8Бит но это жесть :-)

Конечно 256 на 192 это слабый режим, но не стоит забывать что и расчитывался он на ТВ :) а я, достаточно плотно сталкиваясь с интерактивными ТВ приставками и разрешениями до HDTV и разработкой под них, :) нахожу что это разрешение было вполне неплохим выбором.. Что же касается идей витающих здесь, то я нахожу их жизнеспособными, но.. некрасивыми... специальный видеоконтроллер это некрасиво имхо.. списывать что сам Z80 не справится, ну значит надо сделать так что бы справился иначе теряется прозрачность платформы, разработчики завязываются как на писишке на дядю-доброго разработчика "видеокамня", да и повторяемость на "железной" логике такого решения сомнительна

На ТВ например замечательно вписывается и 384х288... точто также как и на VGA монитор. У меня например нет ни телевизора, ни монитора с ТВ развёрткой. А рас уж делается клон под VGA монитор, то почему бы докучей не пульнуть туда и 640х480... мало ли пригодиться... хотябы картинки смотреть точно можно.
А вот текстовый режим реально лучше смотрица на VGA нежели на ТВ, я имею ввиду 80*25.

В том то и прикол, что если сделать отдельную карту (со своей быстрой памятью) то в режиме 640*480 вполне можно отображать 2 тайловых слоя, +спрайты.
Мало того, такая карта может работать паралельно со спеком.

Уменьшить можно до 512*384. И то из соображений экономии памяти.

Я бы просто хотел объяснить свое видение такой платформы как ZX-Spectrum, что бы объяснить почему не вижу смысла в видеоконтроллерах и мегавидеорежимах которые несоменно приблизят к писишным качество графики с аппаратными ускорителями.. На данном этапе Спектрум не является общераспространенным и бытовым в "народном" смысле этого слова, это скорее компьютер любителей попрограммить на низком уровне, которых можно было бы сравнить с каякерами (это такие лодки для спуска по горным рекам) и в целом весь кайф программинга под спектрум лежит именно в том, что ты обходишь эти камни и выжимаешь из платформы не только то что она может, но и то чего она не может.. все кто любит комфорт и покой давно уже на писишке и это всех вполне устраивает, все же любители приделывать к спеку мощные процессора несовместимые с Z80 или видеопроцессора которые будут рисовать кучу линий аппаратно и делать заливку, сами того не осознавая, делают вещь которая не дает плюсов как таковая в более широком диапазоне нежели сиюминутный, тягаться в секторе бытовых компьютеров с PC нереально, а такие разработки призваны ускорить разработку именно "бытового" софта и снижение издержек на его производство, что в нашем случае бессмысленно.. так что прежде чем ставить на каяк мотор, парус и пытаться выводить его на поток без препятствий :) лучше тысячу раз подумать, так как "некоторые вещи сломаны, потому что они должны быть именно такими" :)

Щаз, два слоя 640x480 (еще и "+спрайты")!! Для независимого-то девайса многовато будет, даже с расширенной ШД и SRAM на 15ns (о чем я вам уже намекал)... "Отображать" оно конечно будет, но вот динамика - только и остается, что исключительно убогими плоскими тайлами ворочать... Вот нахрена из Спека тупую приставку делать? Если можно лучше (и проще).

А тут ваще человек планирует классический APA-mode, общую память на все (проц тоже должен когда-то работать), и есс-но ШД 8 бит, со всеми вытекающими. :sleep:

Карочи всё посчитано на калькуляторе... к карточке время доступа будет составлять примерно 30-50 нс... чего хватает для пары z80 работающих на частоте 28МГц

Сколько байт в кадре сканер вытаскивает?

614400 (на два слоя) при 640*480 без спрайтов.
Но сканер пока ничего путного не вытаскивает, т.к. Андер канстракшен :-).

:v2_scare: Дык на 28МГц в кадре всего 560000 циклов SRAM!! :v2_conf2:

Это ты сейчас что спросил???
640*480=307200 байт на 1 слой. умножаем на 2 так как 2 слоя, вот тебе и 614400.

28MHz / 50Гц = 560000 тактов на кадр
на 60Гц еще меньше, поменяй батерейки в калькуляторе :)

Ребяты... памать 16-ти битная... одновременно читаться будет 2 слоя.

Все равно не получиться 2 Z80 на 28МГц надо что бы без останова процов 37МГц память (я имею ввиду + видео еще 60Гц хотяб).

Вот считаем, сколько сканеру нужно вычитать за кадр:
2 тайловых слоя + 1 спрайтовый
640*480*3слоя = ~922КБ

Для комфортного режим 85Гц (сканер максимально загружен)
922 * 85 = 79МБ/сек

Реально цифра чуть побольше будет на 5-7%.

Такая видео-карта с 2 - 4 метрами памяти
уделает многие игровые консоли, включая сегу.

Главное не разрешение и магабайты а динамика.

Автор хотел разшарить память между ВК и процами.
А тут сам ВК съедает 80МБ/сек.

Ну ладно... Только, чтобы удобно было! О.К.? :smile:
А, вообще, по-моему, не стоило бы такую кучу видеорежимов городить (в этом утонуть можно), - лучше лишние элементы ПЛИС на другие полезные вещи потратить:
полноценный контроллер прерываний, конроллер ПДП, таймеры, качественный звук и т.п.
Желаю успеха!