!!! ìÉÎÅÊÎÁÑ ÁÄÒÅÓÁÃÉÑ ÜËÒÁÎÎÏÊ ÏÂÌÁÓÔÉ
ZXNet echo conference «real.speccy»
RA> - переход на соседнее знакоместо осуществляется инкрементом старшего
RA> байта, на линию ниже - увеличением младшего байта. Такая адресация
RA> совмещает в себе достоинство стандартной и линейной адресации, при
RA> этом адресация линейна не по столбцам, а по строкам.
А что будет с удобством для прокручивания, по сравнению с линейной? Блочные
комманды идут лесом, и нужны ли они для графики вообще? С мелкими спрайтами, я
так понимаю - всё в порядке.
КИА
On Thu, 24 Jun 04 17:05:58 +0400, Ivan Kuvshinov wrote:
IK> А что будет с удобством для прокручивания, по сравнению с линейной?
Куда прокручивания? Вверх-вниз всего экрана? Сейчас это
192-8 вызова 32-х LDI.
IK> Блочные комманды идут лесом, и нужны ли они для графики вообще?
Да ну? Теперь только они не со строками работают, а со столбцами.
А так не велика разница...
IK> С мелкими спрайтами, я так понимаю - всё в порядке.
Геморой с проверкой на пересечение трети экрана.
KF> Геморой с проверкой на пересечение трети экрана.
Я так понял, что человек и предложил избавиться от этих третей, а в остальном
оставить примерно также.
Я всё же думаю, что лучше линейной адресации ничего не придумаешь. Hикакие
смещения адреса экрана на speccy также не нужны, не на столько большое у него
адресное пространство чтобы видео в память распаковывать и экранчиком по нему
бежать :). А вот если делать новый экранный режим, то он обязательно должен
быть с буферизованным выводом, чтобы не копировать на вывод, а сразу строить по
экранным адресам и избавиться от торможения памяти, да ещё и получим халявную
по времени очистку экрана, то бишь ClrScr. А сделать что бы отображалась та же
страница буфера, что и доступна на запись - завсегда можно, только сначала надо
решить вопрос с плодящимися как грибы управляющими портами, в страничку их что
ли загнать, на БК, кажеться такое изначально, а несколько оставить в адресном
пространстве навсегда, что бы теже странички щёлкать записью в память.
Да, кстати, в 128 режиме так же и есть с буфером, да (а то у меня 48 только
был, я этот момент как-то упустил)? Только народ недоволен, что долго
перещёлкивать?
КИА
IK> Я так понял, что человек и предложил избавиться от этих третей, а в
IK> остальном
IK> оставить примерно также.
Да...
IK> бежать :). А вот если делать новый экранный режим, то он обязательно
IK> должен
IK> быть с буферизованным выводом, чтобы не копировать на вывод, а сразу
IK> строить по
IK> экранным адресам и избавиться от торможения памяти, да ещё и получим
IK> халявную
Что куда копировать??? Сейчас есть два экрана. Один строишь, другой
показываешь.
Какие ещё торможения памяти? Их у советского спектрума, за редким
исключением, и не было никогда...
IK> по времени очистку экрана, то бишь ClrScr.
CLS не нужен. Вообще...
IK> А сделать что бы отображалась та же
IK> страница буфера, что и доступна на запись - завсегда можно, только сначала
IK> надо
IK> решить вопрос с плодящимися как грибы управляющими портами, в страничку их
IK> что
IK> ли загнать, на БК, кажеться такое изначально, а несколько оставить в
IK> адресном
О чём вообще речь? Я уже окончательно утерял мысль.
IK> (а то у меня 48 только был, я этот момент как-то упустил)?
Похоже на то...
IK> Только народ недоволен, что долго перещёлкивать?
Экран? 12 тактов.
KF> Поясни свою мысль. В частности, ЧЕМ в данном случае линейная
KF> адресация хуже или лучше? Как было (192-8+23)*32 LDI, так и
KF> останется...
а что же делать с лучем?
До свиданья, пишите письма.
IK>> расходоваться много, всегда есть чем загрузить процессор, даже
IK>> если речь идёт о банальном выводе текста.
KF> Поясни свою мысль. В частности, ЧЕМ в данном случае линейная
KF> адресация хуже или лучше? Как было (192-8+23)*32 LDI, так и
KF> останется...
Хорошо. Я собственно хотел сказать, что всякие "новые формулы", как правило,
бывают хороши в специальных случаях, коих не очень много. Линейная адресация
проверенна на многи машинах и никто не жаловался. Я думаю, что спектрумовский
экран хоть и хорошо придуманн, но не очень удобен, по крайней мере для
скроллинга и со своими делениями на три части. Возможно, что предложенная
модель будет чуть удобней линейной - пускай так, тогда я за, но только потому,
что она также "проверенна" на спектруме и тоже довольно удобна, хотя я и считаю
что всё равно надо на этот счёт узнать мнения других.
KF> Что куда копировать??? Сейчас есть два экрана. Один строишь, другой
KF> показываешь.
Понятно. Только ни как не пойму зачем понадобилось человеку адрес экранной
области менять произвольно, я думаю что с двумя страничками по одному адресу
очень удобно - пока выводиться строй себе что хочешь, счёлкнул потом и порядок?
RA> это можно реализовать.
Пока что интерес в такой штуке ещё не появился.
А по поводу графики на Speccy есть пара слов. Я считаю что нельзя, да просто
нельзя, слишком наворачивать ему графические возможности, не зависимо от того
будет ли это суперпупер примочка за два бакса на шести процессорах Pentium Pro
или рассыпуха для 800x600 TrueColor.
Если посмотреть на так не любимую платформу PC, в ретроспективе, то можно
очень хорошо увидеть, что как только появились, можно сказать традиционные
разрешения, то объём программ, и в частности игр, вырос на порядки и на столько
же выросли системные требования. Причём и сейчас графика является основным
"двигателем" прогресса. Если при 256 цветах были вполне разумные пределы -
40МГц, 4-8МГб ОЗУ, 1-20МГб программа, то дальше: 233МГц, 4-8МГб Видео!,
150-640МГб программа. Для того чтобы спектрум смог ворочить такими объёмами его
надо так переделать, что от него ничего не останется. :(
Я считаю, что поднять разрешение всё же надо, но 512x384 и байт цвета на байт
вполне достаточно, что бы не страдали текстовые возможности и было получше с
цветами, но далее это уже бред. Достаточно взглянуть на размер адресуемого
пространства, что бы не возникало желания превращать z80 в сопроцессор по
перещёлкиванию страничек к супер крутому графическому акселератору.
Да и вообще большинство наворотов - не нужны. Hу зачем нужен DMA? Я так
понимаю, что с помощью него собираются байтики по памяти гонять? Мало LDIR,
тогда разведите на какой-нибудь Altera, Crusoe или что там такое, сам процессор
и будет 40МГц, а появится другая микруха, так туже прошивку и пожалуйста - 200.
И будет хватать, и на другие нужды можно будет использовать, зато архитектура
останется прежней, только не надо зарываться и сам процессор совершенствовать,
в том числе и по тактам на комманду. Hа логическом уровне всё должно оставаться
как можно ближе к оригиналу, в том числе я против добавления разрядности для
адресации большей памяти.
КИА
VK> а что же делать с лучем?
1. Забить (в текстовом редакторе).
2. Использовать двойную буферизацию в 2 экрана.
3. Выводить слева-направо и сверху-вниз, как и положено:
ld (hl), x
inc h
ld (hl), x
inc h
...
ld (hl), x
ld a, h
and 0xe0
ld h, a
inc l
...
Да, возникают неудобства с использованием LDI. Так что можно ещё
поспорить о том, какой экран выгодней.
25 июн 04 03:23, you wrote to Kirill Frolov:
IK> адресации ничего не придумаешь. Hикакие смещения адреса экрана на
IK> speccy также не нужны, не на столько большое у него адресное
IK> пространство чтобы видео в память распаковывать и экранчиком по нему
IK> бежать :). А вот если делать новый экранный режим, то он обязательно
немного не соглашусь - получатся очень красивые полноэкранные скроллеры с очень
небольшой загрузкой процессора. как на ATARI 800 например.
/_*───────────────────────────────────────────────────────────────[80`s]────*_/
IK> Речь о банальной вещи - когда делаются какие-то несовместимые доработки,
IK> они
IK> должны быть отключаемыми, то есть должен быть конфигурационный порт или
IK> байт, в
Об этом тут уже с 1998 года разговоры идут. Для того EFF7 и был
придуман. Только, похоже, в нём уже биты закончились. Есть ещё порт
"отключателей" -- CFF7 (поддерживается MadROM). Hо с использованием
его битов никакой определённости вообще нет.
IK> памяти. Я вообще предложил сделать отображение портов на память и загнать
IK> их в
IK> отдельную страничку, тогда пользоваться ими можно будет как и обычной
IK> памятью.
Особенно, если это порт переключения памяти...
IK> Это может дать выгоду для таких критичных вещей, как быстрая пересылка
IK> данных
IK> через порт. Hо несколько наиболее важных портов сделать не в страничке, а
IK> в
IK> обычной памяти или что бы они не перещёлкивались вообще, например штук
IK> 256.
Зачем так сложно?
KF>
KF> 1. Забить (в текстовом редакторе).
скажи это -=LD=- с Dark'ом ;)
KF>
KF> 2. Использовать двойную буферизацию в 2 экрана.
можно и старым экраном обойтись
KF> 3. Выводить слева-направо и сверху-вниз, как и положено:
тогда вообще смысл теряется, push/pop идут лесом...
KF>
KF>
KF> Да, возникают неудобства с использованием LDI. Так что можно ещё
KF> поспорить о том, какой экран выгодней.
по-моему даже спорить не имеет смысла. Мне вот, кстати кажется, что еще будут
проблемы регенерацией памяти.
До свиданья, пишите письма.
VK> тогда вообще смысл теряется, push/pop идут лесом...
Вот. Совсем я упустил это. Серьёзный минус этой линеной адресации.
Действительно, не стоит и спорить...