Теоретический вопрос по железной начинке ZX Spectrum

На фоне обсуждений последних двух дней у меня родился вот какой вопрос:
Возможно ли было в чипах ULA спектрума сделать дёшево и сердито вот какую концепцию:
а) запись в некие два порта вывода X и Y координаты пикселя генерировали бы на входе трёх других портов ввода:
б) верхний байт адреса полоски пикселей в массиве пикселей видеопамяти
в) нижний байт адреса полоски пикселей в массиве пикселей видеопамяти
г) верхний байт адреса атрибута этой полоски пикселей
(нижний байт адреса атрибута тут не нужен, т.к. мы уже знаем, что он совпадает с (в) после предыдущих тем)
На уровне проводов это просто разброска линий и их перемешивание, что мы видели в предыдущих темах.
Так не было ли бы это возможным сделать без весомых затрат на самом старте?
(сразу обозначу — это чисто теоретический вопрос и статью я по нему писать не собираюсь. просто очень интересно.)

114 комментариев

avatar
а нахрена?
вообще можно конечно прилепить МК какой (УЛА тут и не нужен), который будет слушать порты и плевать ответы. но:
1. это уже будет не совсем спектрум
2. 2 OUT + 3 IN — 48 тактов, это без учета установки регистра C
avatar
*60 тактов
avatar
Т.е. в принципе сдвигами или таблицей выборки получилось бы быстрее, чем через порты ввода-вывода?
avatar
ну типа того, да.
avatar
Иными словами, вычислять экранный адрес по двум координатам?
Это не имеет смысла, так как он и так быстро вычисляется по таблице 512 байт, если расположить её в памяти с адреса кратного 256:

ld h, htable ; 7
ld l, y      ; 4
ld a, (hl)   ; 7
inc h        ; 4
ld h, (hl)   ; 7
add a, x     ; 4
ld l, a      ; 4
avatar
«Иными словами, вычислять экранный адрес по двум координатам?»

Не только экранный адрес, но и адрес цвета. Там же просто перемешать биты определенным образом и готово и то и другое за нулевое машинное время — ни складывать ни вычитать не надо. Но есть возня с портами дольше даже, чем перемешивание бит, то… вот как раз и хотелось спросить про это.
avatar
ld h, htable ; 7
ld l, y      ; 4
ld a, (hl)   ; 7
inc h        ; 4
ld h, (hl)   ; 7
add a, x     ; 4
ld l, a      ; 4

37 тактов и 512 байт памяти

LD BC, port  ; 10
out (c), reg ; 12
in l, (c)    ; 12
inc b        ; 4
out (c), reg ; 12
in h, (c)    ; 12

62 такта, что к следующему порту можно перейти так.

или в случае 8-битых портов
ld a, reg      ; 4
out (port), a  ; 11
in a, (port)   ; 11
ld l, a        ; 4
ld a, reg      ; 4
out (port), a  ; 11
in a, (port)   ; 11
ld h, a        ; 4

60 тактов

Но дело в другом, такое не принято исходя из соображений здравого смысла. Проблемы вычислений адреса — это по-логике проблемы процессора, проблемы даже алгоритма, а не аппаратуры. Такого не было, даже на PC-шных EGA/CGA/VGA видекартах с их чумовейшими битпланами, на амигах/атарях, на консолях или на монструозных arcade game board.
Однако это не значит что данный подход плох или не работает. Работает, и такая идея и меня давно посещала также, и для вычисления адреса, и позже — для выполнения умножения/деления, либо для более генеральных вещей — для общения с «сопроцессором». Подобное весьма активно использовалось на NES/SNES, в дополнительных RISC-микропроцессорах стоящих на картридже игры, только работало не через OUT, а через запись в ячейки памяти и/или DMA.
avatar
ld h, htable; 7
ld l, y; 4
ld a, (hl); 7


Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
avatar
P.S.

Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
avatar
P.P.S.
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
avatar
Это не locate pixel, это locate byte, допустим для вывода спрайта.
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса

Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
avatar
ааааа, ненавижу gamedev.ru в плане поиска — просто редиректит на гугл с site:gamedev.ru и нихрена толком не ищет.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
avatar
Посмотрел, нашел screen_inc.asm, посмотрел locate_pixel и другие вещи. Всё красиво, всё молодец. Могу тебе рассказать дальше, в чём беда подобных вещей. Потому что когда-то, очень-очень давно пришлось пройти по этим граблям. С подобного разумного, организованного (библиотечного) подхода, (типичного для PC/ассемблера x86) начинают многие. Эта «разумность» и «организованность» и подводит. К сожалению, подобный поход не работает на ZX Specrum в практическом плане, потому что оказывается слишком медленным. Тут парадигма программирования (приводящая к успеху) несколько иная. Могу рассказать, если есть интерес.
avatar
Лично мне было бы очень интересно почитать как ты думаешь о программировании на спектруме. Потому что стилей очень много, а вот задокументированных стилей осталось всего ничего: мне в голову приходят какие-то обрывочные комментарии Робуса, а так же некоторые статьи Flying — например, его заметка про Memory Management Library или, допустим, уникально компактные заметки Exploder.
avatar
Мне сначала надо бы ознакомиться с упомянутыми тобой материалами (жел-но со всеми). Затем нужно получить побольше информации, я должен более расширенно понять, что тебя интересует. А то есть риск написать не то что тебе интересно.

Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
avatar
Вот очень известный пример заметки Exploder: zxpress.ru/article.php?id=1101
Вот заметка Flying, которая меня в своё время удивила: zxpress.ru/article.php?id=3614
Про Robus у меня не так много очевидных ссылок; ну вот можно например глянуть прямо у нас на Хайпе: hype.retroscene.org/blog/demo/830.html

Но вообще чем больше ты будешь писать под меня или под кого-то ещё, тем, мне кажется, выйдет неинтереснее. Интересно как лично ты видишь программирование на спектруме. Вот Flying сел писать такую заметку и у него вышел рассказ про библиотеку менеджмента памяти. Он ведь много что накодил, а болел получается именно этим. Вот интереснее всего и выходит когда рассказывают о том, что наболевшее в каком-то смысле.
avatar
Угу, особенно мне в этой статье нравится список амижных эффектов, которых никто, кроме Эксплодера, не то, что накодить в те годы не мог, а даже и не знал, как они выглядят :) У этой статьи, кстати, продолжение есть: zxpress.ru/article.php?id=1115
avatar
Ага, в те годы если ты был амижник ты был на коне :) Exploder с RST7 декомпиляли амижные эффекты, с годами всё тайное стало явным. :)
avatar
ой вряд ли «декомпиляли». всё обычным образом — увидел, догадался, решил как у нас можно — и закодил подобное :)
avatar
Я абсолютно 100% уверен что «драли». Гхм, собственно, в некоторых случаях нужно говорить — конверсия эффекта на ZX Spectum, настолько они узнаваемы в некоторых Amiga-интро, когда сейчас смотришь.
А то как ты говоришь — этим занимался, как раз, ваш покорный слуга :))) (скрежеща зубами :) потому что ни PC, ни Amiga у меня не было). Почему я 100% уверен что драли? Ассемблерный код, разумеется, не перенесешь, но переносили нетривиальную основу (задумку) и математику эффекта.
А в некоторых эффектах и задумка и внутренняя реализация совпадает на 100% с оригиналом. Касаемо Codebusters/RST7 — какие там могут быть сомнения что «драли», если используется выдранный с Amiga/MSX контент… Первое же что вспоминается, кораблик из заставки MSX-игры Gradius(Nemesis) или туннель из Amiga Stardust.
Ну а касаемо Лёхи Exploder'а, не будем забывать что он несколько раз брал призы на Assembly в амижных демках…
avatar
Влезу в ваш разговор, с вашего позволения…
Думаю, что если провести опрос у всех кодеров, кто реализовал что-то известное на ZXе, то выяснится, что не «драли». Имеется в иду повторяли визуально, а не декомпилили. Что касаемо RST7, то он повторял визуально. Не забывайте, что он сперва кодер, а потом уже график/музыкант. Поэтому совершенно очевидно, что ради примера он брал уже готовую картинку, в данном случае из игры. Из разговоров с TITUSом я понял, что они вдвоём любили общаться друг с другом в ключе — «вон смотри там есть эффект», и в итоге его повторяли. Судя по всему RST был жуткий генератор всего, что видел вокруг себя, а то как он это генерировал сделало тем кем он стал. К сожалению не все могут реализовать свои идеи по очень разным причинам, начиная от — «нет времени», кончая — «демки это дурь, круть только игры». А ведь у каждого не сбывшегося есть идеи, но никто он них не узнает, по скольку сработал триггер «НЕ».
Из того, что я могу судить, то «декомпилить» по факту нет смысла. Я не могу свой код перетащить фактически не на один компилятор, ведь я знаю, что тысячи макросов генерируют результат в виде «мяса». Из чего появляется главный вопрос, который я постоянно задаю сам себе — «зачем вообще нужна процедура самой быстрой точки» ??? Она, конечно, нужна, но исключительно как пример мастерства кодинга в конкретном случае, и этот случай только один — «SUPER FAST POINT». Ведь каждый из вас понимает, что из этой процедуры можно нарисовать только то, что очевидно, и мало того это уже нарисовано много-много-много лет тому назад. А вот если вы будете обсуждать комплекс решений, не саму точку, а то, что хотите получить в конце, вот тогда это очень полезно. Вот в данной статье добавьте самое главное, — «автомат», который даст мне рисовать группу точек по тем или иным параметрам. И даю вам гарантию, что этот «автомат» обязательно используют не по назначению, и в итоге вы будете смотреть на какой-нибудь эффект и задаваться вопросом — «а как?». Ведь в этом же смысл всех эффектов? Да? Ведь когда вы впервые смотрели на эффект RST7 с мультиколором, уверен, что не было ни одного вопроса типа — «о… этот корабль так прекрасен, кто же его нарисовал?», за то точно все задались вопросом — «я вижу цветную картинку, которая летает вверх-вниз по-пиксельно, а квадратиков нет, КАК?». Так что, — не важно от куда эта картинка, важно, что она тут, и в таком, вот, крутом виде.
Идеи… Идеи это самое интересное. Я видел очень много разных людей и могу с уверенностью сказать, что чистые идеи могут появиться только у гениев. Все остальные всегда-всегда-всегда-всегда-всегда-всегда и ещё раз всегда, что-то за кем-то повторяют. Конечно же улучшая! Хотя не всегда улучшая, не спорю, но как правило мы обращаем внимание на тех, кто улучшает. Посудите сами, вы же не будете своего ребёнка упрекать, что он подобно вам научился говорить, хотя, в принципе, он мог по ходу взросления взять и придумать свой язык. Далее он вырастит и научиться ещё чему-то, например кодить. Уверен, что вы будете им гордиться, хотя могли бы сказать, а чего-то это ты пишешь на том, чём папка писал, неее… — давай свой язык придумывая, а заодно и компьютер придумай. — Ребёнок повторяет за вами улучшая вас. Не спорю, он может родиться гением, и построить что-то сверх крутое, ну тогда будете ещё больше гордиться. Так, что повторять что-то за кем-то не есть плохо, главное, — что ты вносишь нового в чужую идею, делая её уникальной, а значит своей.
Снова про идеи, только с другой стороны. Чем хороши группы? В них идеи распределяются по мере мастерства каждого участника. Кодер фактически не может увидеть какова будет картинка или какой будет звук. Поэтому он сделает свою часть максимально изощрённо, и если у него не будет графика, то всем будет казаться, что эффект украден. Точно так же график видит чего накодит кодер и рисует к этому своё видение. По сути в реалиях — кодер работает с «рефференсом», если я правильно вспоминаю слова из классического построения современных задач. И прекрасна та команда(группа), которая находится в симбиозе. Вот последний человек в моём творчестве, который подхватывал мои идеи, — был Screen Killer, я ему постоянно отдавал все свои эффекты, которые он оформлял. Первый раз я это ощутил, когда делал эпилог для демки Virtual, где придумал совершенно идиотскую идею запустить титры по изогнутому листочку, который представлял себе помятым пергаментом. Всё что я сделал это нарисовал в ART-STUDIO, контур листочка в проекции, и запустил по ним титры. А он взял фотографию монитора и сказал, сейчас мы его расплавим и наложим на твой контур. И всё стало другим, всё стало лучше в разы. Этим и прекрасны коллективные работы, в них много идей, и как их не копируй, всё равно оригинал будет лучше.
И опять про идеи… Но истории о группе были очень давно. Очень очень давно… Каждый уже давно пошёл по своему пути. У меня есть файл в который я постоянно добрасываю идеи эффектов, и идеи игр так же, и идеи видео. Много там идей, их там сотни две — точно есть. Фактически все эти идеи есть последствие того, что я вижу в других работах, причём как демки, так и фильмы, картины, театр, да вообще всё что меня окружает. Я их сажусь и описываю, как понимаю сам и ни одна идея не была реализована так как я её описал. Многими идеями делюсь с Вовкой, надеюсь ещё не надоел со своими звонками… Многие идеи реализовал, и они лежат в виде кусков неприглядного кода. Есть куча музыки, которая вызовет очень много вопросов, от чего её не использую. Хотя я не знаю, до конца, как её вообще воспримут. Но я точно знаю, что большинство моих идей нельзя решить классическим путём, как в области кодинга, так и в области музыки и графики. Но мы все очень разные и как правило жутко упёртые. Хотя, наверное, упёртый я, а не остальные.
Лично я, фактически, никогда не декомпилил чужой код, хотя умудрился написать в 1995 году для этого декомпилятор — «DISDEV», так ни разу не использовал его по назначению, за-то декомпилировал ПЗУшку, получил море удовольствия и геморроя узнав как можно использовать команду «JP(HL)».
avatar
Литературно текст прекрасен, впечатлило, благодарю.
Однако я останусь при своем мнении по массе причин.

1. Дискуссия заведомо обречена, потому что в обсуждении будут появляться, в основном те, кто спешит заявить что он никогда не изучал чужой код. Обратное писать не спешат. :)

2. Никакой разумной причины скрывать хакинг нет. Более того, пытаясь сочинить для instrospec запрошенную статью, я напрямик советую смотреть как организован чужой код. Я абсолютно не сомневаюсь в том что сильные «кодеры», прежде всего сильные хакеры. Раньше как-то и не принято было ничего скрывать, хакерство было частью сцены и если не очевидным, то особо не скрывалось. (Пример — девушка из Lyra, сэмплы, картинки, музыка...).
3. Идея о том что не требуется смотреть/знать реализацию эффектов совершенно несостоятельна. Тривиальные вещи, такие как разнообразные скроллинги (мнущиеся, кривые, косые, с разными скоростями и зумом), атрибутную анимацию, спрайты итд смотреть нечего. Но дело в том что существуют advanced эффекты, для которых не зная know-how ты их не реализуешь, сколько ты не смотри. Просмотр знания не заменит. Сходу вспоминается water, rotozoom, bump mapping, fake phong mapping, texture mapping или там kefrens dots (я забыл реальное название, но однажды с introspec'ом обсуждали эффект из Insult — это всё он же). В некоторых случаях требуется знать не математику/алгоритм, а организационно-алгоримтический трюк (грубо говоря, «почему это прокатывает»).
4. Сходство некоторых эффектов на Amiga заметно глазами. Я выше применил достаточно грубый термин «драть», «выдирать» итд. Обычно он соответствует прямому копированию. Нет, я это в виду не имел. Реально достаточно только глянуть одним глазком ;), чтобы узнать как это работает, чтобы затем реализовать в коде нечто подобное.
5. Я не думаю что все всё и всегда смотрят. Многие сложные вещи приятнее сделать быстрыми самому.
avatar
«Уникально компактные» — это когда из 2кб статьи 1кб уходит на «Ну это я не буду объяснять, это вы и так знаете, а если не знаете, то вы тупой идиот и нечего вам тут делать!» :)
avatar
Саша, возможно ты не заметил, но там этого не написано :) Да, там поясняется формат данных под чанки под «леймов», но там и сам текст назван шит, и вообще очень много ни к чему конкретному не привязанной бравады.

Т.е. я не знаю, м.б. Exploder и очень сложный и даже неприятный человек, я же не знаю. Но на основании одного предложения в заметке примерно на пару кб текста, в основном на ассемблере, тебе не кажется, что ты немного скоропалительно приходишь к выводам?
avatar
С Exploder'ом (Алексей Вересов) я был знаком примерно в ~2006? 7? (много общались удаленно). Мне он показался весьма неплохим человеком. А «бравада» — просто по молодости, может быть в то время ему реально казались крутыми те результаты (по оптимизации), которых он добился.
Хотелось бы его найти, пообщаться. Если у кого есть зацепки — дайте знать. :)
avatar
его сайт сейчас онлайн. там есть куча контактов.
avatar
«Могу рассказать, если есть интерес.»

Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
avatar
P.S.
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
avatar
P.P.S.
Глянул документацию по SjASMPlus — и интуиция не подвела. Там есть для этих оптимизационных целей ключевое слово IFUSED. Прикольно, прикольно…
avatar
P.P.P.S.
Потестировал этот IFUSED — а фиг то там, он не умеет разруливать зависимости изнутри самих IFUSED, то есть применим довольно узко в сравнительно простых случаях.
avatar
На NES всё же сопроцессоров не было, а работа с дополнительным железом через память на NES/SNES просто потому что на семействе 6502 нет портов в принципе. Аппаратные непрограммируемые вычислялки, типа описанной в топике, на приставках и комьпютерах встречались крайне редко, навскидку вспоминается только аппаратный MUL/DIV на SNES, и до какой-то степени DSPx (программируемый, но программу нельзя менять). Более универсальные сопроцессоры делали заметно чаще, и на ZX, можно сказать, тоже был — GS/NeoGS.
avatar
Всё так, всё так.
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips
avatar
1) на z80 возня с портами неудобна, медленна и, как следствие, обычно невыгодна
2) даже если был бы небольшой выигрыш, всё равно адрес по координатам объекта (спрайта, конца отрезка) вычисляется однократно, и в % от всего объекта будет уж совсем незначительным
3) не решает основную проблему нелинейной раскладки — медленный и неудобный down_hl, который нужен многократно на весь объект
4) в оригинальной юле, насколько помню, места не осталось уже совсем; добавлять вторую = удорожать комп; а если уж удорожать, то не для такой ерунды, а чего-нибудь намного полезнее (например, автоматического пересчета удобного логического адреса произвольного окна в неудобный физический адрес экрана, не отказываясь от экономии памяти)
avatar
down_hl, как раз, занимает всего лишь 4 такта при правильной готовке. И выполняется так с вероятностью 7/8, то есть 87.5%
Это не делает его удобнее или быстрее чем при постолбцовой раскладке где столбцы 256 байт, но ситуация не так уж и печальна. Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.
avatar
down_hl, как раз, занимает всего лишь 4 такта при правильной готовке. И выполняется так с вероятностью 7/8
и с высокой вероятностью занимает уже сотни байтов, если не килобайтов

Это не делает его удобнее или быстрее чем при постолбцовой раскладке
делает значительно неудобнее

но ситуация не так уж и печальна.
для 128k разве что (и то, лучше бы отдать экрану часть этой памяти)

Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.
при ошибочном целеполагании
avatar
> и с высокой вероятностью занимает уже сотни байтов, если не килобайтов
Пчму? Пример сотен байтов-килобайтов?

> при ошибочном целеполагании
Объясни, о чем ты, в чем ошибочность, итд
avatar
Пример сотен байтов-килобайтов?
Быстрое рисование отрезка, нешто забыл? Твой же код жрёт больше трёх килобайт даже без таблиц. А уже если радикально оптимизировать под короткие отрезки, как завещал Алоний, то хорошо, если всё в страницу поместится. Вопрос знаю, как раз на днях нашлись мои старые наработки, будет время, доведу до конца:
zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444
Вывод спрайтов может обойтись в сотни лишних байтов вместе с обвязкой.

Объясни, о чем ты, в чем ошибочность, итд
в том, что минимальный размер экрана не означает экономного расходования памяти
avatar
У меня есть линия с похожими характеристиками, так что думаю я понимаю как ты её сделал. Но мне кажется, что это всё же охота на блох, в том смысле, что по-настоящему интересно будет только в том случае, если ускорить линию в 2-3 раза. С моей точки зрения ускорение на 20-30% на практике никто не заметит.
avatar
Каких нафиг 2-3 раза, даже в теории? У меня по диагонали сейчас выходит на пиксель в среднем ~37 тактов в основном цикле. Так ведь 15 тактов нужно только чтобы поставить точку, минимум 4 на ступеньку, минимум 11 проверка ступеньки без перехода. Без учёта вспомогательных операций для группы точек. А еще на запуск накладные расходы и завершение — то единственное, что еще осталось оптимизировать, чтобы на коротких снизить потери. Что еще там можно придумать? Разве что выбирать готовые фрагменты за счёт совершенно невменяемого размера. И то сомневаюсь, что заметный выигрыш может выйти.

30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).
avatar
Ну вот поэтому, грубо говоря, люди и сидят на линии из эксперта до сих пор.
avatar
Сидят те, кто не может сделать лучше, или не хочет. А кто смог — не делятся исходниками))
avatar
Господи, сколько понтов. Было бы ещё чем делиться.

	set 7,(hl) : dec c : ret z
	sub d : jp nc,HD_L0P6
	add e : inc h
Если делать с ловушкой, можно выкинуть dec c: ret z (на коротких линиях это довольно плохая идея). Если делать DDA вместо Брезенхэма, можно выкинуть одну из sub d / add e, но придётся делить в преамбуле. Всё, приехали. Дальше начинаются разные циклы для разных углов наклонов, группировка пикселов вместе и прочая вакханалия. Дело же не в том, что никто не знает как делать быстрые линии, мягко говоря не новая тема для исследований. Дело в том, в реальной жизни никогда нет 16К на процедуру рисования линии. И даже 8К обычно тоже нет на самом деле. А на масштабе 3-5К примерно одно и то же и выходит.
avatar
Если делать с ловушкой, можно выкинуть dec c: ret z (на коротких линиях это довольно плохая идея)
и так можно, для хвоста отдельный лучше кусок (а на вертикали и не был нужен)

Если делать DDA вместо Брезенхэма, можно выкинуть одну из sub d / add e, но придётся делить в преамбуле.
ну вот видишь, ты подумал, что приехал, и успокоился
хотя делить там совершенно необязательно

Дело в том, в реальной жизни никогда нет 16К на процедуру рисования линии. И даже 8К обычно тоже нет на самом деле. А на масштабе 3-5К примерно одно и то же и выходит.
ничего не понял, почему нет, почему одно и то же, в каких масштабах…
avatar
ну вот видишь, ты подумал, что приехал, и успокоился
хотя делить там совершенно необязательно
Есть разница между «подумал что приехал» и «успокоился».
Ты придумал табличку? молодец. Я пока не придумал.
avatar
(Я хоть и отвечаю на твое сообщение, но на самом деле это «реплика в сторону»).
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…
avatar
Ну просто я вот не люблю понты впустую. Lethargeek выложил график своей новой линии. ОК, мне это интересно, я тоже иногда занимаюсь своей линией. Но график как он есть — это он выложил чисто подразниться. Я написал что думаю про его график. А он рисуется, наверное, думает, что его будут упрашивать.

Ты прав в одном, я никогда не буду работать в команде с Lethargeek. А он, наверное, примерно так же никогда не стал бы работать со мной. Потому что команда — это не просто несколько человек с интересом на похожие темы. Это ещё и… назовём это «совместимостью».
avatar
ну здрасьте, то ты говоришь неинтересно, то интересно, но рисуюсь я почему-то?!
график я там выложил, чтоб узнать, мб кто-то лучше с тех пор придумал, нах тогда мне париться с продолжением
благо тема именно об этом была такая, но походу все последние активные кодеры разбежались с «гяфа» за эти годы
avatar
и я не придумал)) да и незачем, табличка тоже необязательна 8)
avatar
Посмотрел твой код. Да, идея развести Брезенхема в 2 независимые ветки прикольная, но непрактичная, с моей точки зрения. Жизненные реалии для меня выглядят так: если пишешь 128К демо, очень желательно иметь весь код для выкладки в экран ниже 49152 (чтобы можно было пользоваться теневым экраном). При этом, если хочется поддержать классические спектрумы, крайне нежелательно класть код ниже 32768. У тебя грубо говоря есть 16К под код; на самом деле меньше, потому что есть такие вещи как резидентное ядро, и всякие данные, и, разумеется, код для чего-то ещё кроме рисования линий. Стандартная быстрая линия, как у Рейдера, или из Эксперта, занимает около 5кб. Думаю, что за пределы 7-8 килобайт выходить нельзя, если хочется реально практичных решений.

Твоё предложение фактически удваивает размер кода за 4 такта на точку. 4 такта — это из цикла где в лучшем случае тратится 26 тактов на итерации (на самом деле, в среднем тратится больше). 4/26 — это даже не 20% выигрыша. Думаю что DDA оправдать будет проще, потому что табличное деление можно втиснуть примерно в 100-150 тактов, и это выиграет относительно стандартного подхода для (100-150)/4 ~ 25-40 точек, т.е. для достаточно длинных линий.

Конкретно в деталях, ты там явно расписал не только Брезенхема в 2 ветки, ты также расписал и что-то другое. Мне было лень разбираться в подробностях, но процедура рисования линий длиной более 16К — это просто даже уже не очень и смешно.
avatar
Кроме того, забыл написать про оптимизацию преамбулы. Да, алон прав, в большинстве случаев преамбула оптимизирована неважно. Но, если честно, сделать оптимизацию преамбулы несложно, просто уже потому, что там нечего особенно оптимизировать. Ну да, на коротких линиях это важно и коротких линий обычно большинство. Поэтому мне понятен посыл, но не очень понятно что там по этому поводу можно обсуждать — у всех кто ставит перед собой такую задачу, преамбула эффективна.
avatar
Ну хз-хз, может быть, такой задачи там и не ставили, но в двух других примерах от call до постановки первой точки проходит ~400 и ~490 тактов, у меня в среднем ~330 (и это не старался еще особенно). Сам алон упоминал как рекорд около 270 емнип, но там, вероятно, цикл намного проще и медленней.
avatar
И еще. Как уже говорил на форуме, если сцена сложная, из большого кол-ва коротких линий, и в 25-50 fps заведомо не уложится, может оказаться выгоднее рисовать в буфере с удобной раскладкой и стеком перебрасывать на экран, что в итоге может получиться быстрее и по памяти примерно столько же вместе с буфером (и даже меньше, если вычесть второй экран)
avatar
Да, я это тоже понял. Но пока не решил для себя точно, какая схема меня привлекает больше.
avatar
Я не считал свою преамбулу отдельно. Я меряю просто среднюю скорость отрисовки линий фиксированной длины. Сейчас у меня в среднем 504 такта на линию из 5 точек, 983 такта на линию из 15 точек, 1703 такта на линию из 30 точек.
avatar
если так, то у меня сейчас (лучший случай/худший случай/среднее)
467/610/538; 774/1013/893; 1221/1609/1415
но средневзвешенное дб поменьше среднего, особенно для линий короче 9 точек
так как самый худший случай (и близкие) статистически довольно редки

также думаю поменять местами ветки на входе
не ускорит, так хоть сузит разброс немного
протестирую и выложу исходники после этого
avatar
Где ты там увидел 16k?? Чуть больше восьми, если точно — 8635 байт на саму процедуру линии (и даже вместе с демо-кодом нет и 9k). Из них вход 169 байт и 2k заняли таблицы, которые все можно сократить на четверть за счёт небольшого замедления входа, а на освободившееся место распихать рисующие куски. То есть можно в 8k утоптать вполне. И нет, размер не мог удвоиться хотя бы потому, что ветка без ступенек короче, а еще для хвоста часть кода можно объединить.
avatar
Пробежался бездумно по памяти и увидел :)
Короче, интересная идея. Скорее всего я пущу её в ход. Но хочется большего. Хочется линию в 2 раза быстрее, например. Вот это будет заметно.
avatar
в 2 раза не выйдет, и не мечтай)) даже в самом удобном буфере, без учёта времени переброски, без ограничений на размер кода, с рисованием set и одновременно с двух концов, с экономией проверки после ступеньки, без учёта дополнительных расходов на цикл и хвост — теоретический предел 23+ такта на пиксель (для вертикалей)
avatar
> в том, что минимальный размер экрана не означает экономного расходования памяти

Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.
avatar
Я же подразумеваю иное. Мой разговор и мои мысли строятся вокруг исходного вопроса статьи — почему в Sinclair сложилась именно такая архитектуру железа и экрана?
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.

Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.
avatar
я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management) и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)
avatar
Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество.
К сожалению вот только ответы давать не все хотят/умеют/могут…
avatar
Выражение «Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество. К сожалению вот только ответы давать не все хотят/умеют/могут…»
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
avatar
получается, тут наши самоделкины лучше выкрутились, чем буржуйские инженеры
несмотря на то, что по не зависящим от них причинам меньше «могли»
avatar
я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management)
Слова у меня в статье следующие:
«Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software». (выше я пояснял, что на самом деле биты можно было аранжировать иначе)
и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)

Я до сих пор ясно, чётко, внятно не услышал две вещи: 1. какие у тебя вопросы к дизайну Altwasser'а? 2. Что именно, что конкретно ты бы мог предложить? Может быть попробуешь сформулировать? А я попытаюсь тебя понять. Пока что мне удалось тебя понять так — основная твоя претензия в том что можно было бы сделать экран по-столбцам, а то неудобно писать программное обеспечение, код раздувается в объеме. Я верно тебя понял? Постарайся выразить мысль как можно полнее.
avatar
Слова у меня в статье следующие:
«Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software». (выше я пояснял, что на самом деле биты можно было аранжировать иначе)
Ё-моё. Ну вот с этими словами и не согласен я. С тем, ИМЕННО ТАКАЯ «аранжировка бит» была якобы «задана требованиями software». Потому что в тот момент никакого software не было, был (или планировался) firmware, по приказу руководства который драли, где возможно, с прошлой модели. А вот как раз для будущего software ИМЕННО ТАКАЯ «аранжировка» совсем НЕ требовалась, а лучше подошла бы совсем другая.

1. какие у тебя вопросы к дизайну Altwasser'а?
НЕУДОБНАЯ для кодера адресация. И нет, требование соответствовать особенностям элементной базы его НЕ оправдывает. Потому что можно было И сделать лучшую раскладку, И соответствовать.

2. Что именно, что конкретно ты бы мог предложить? Может быть попробуешь сформулировать? А я попытаюсь тебя понять. Пока что мне удалось тебя понять так — основная твоя претензия в том что можно было бы сделать экран по-столбцам, а то неудобно писать программное обеспечение, код раздувается в объеме. Я верно тебя понял? Постарайся выразить мысль как можно полнее.
Да куда полнее-то, непонятно. В том, что касается конкретно темы твоей статьи, я вполне конкретно предложил столбцовую раскладку — тебе что, мало? Кстати, код не только лишь раздувается, но и раздутый, всё еще проигрывает по скорости коду для столбцовой раскладки.
avatar
Ё-моё. Ну вот с этими словами и не согласен я. С тем, ИМЕННО ТАКАЯ «аранжировка бит» была якобы «задана требованиями software». Потому что в тот момент никакого software не было, был (или планировался) firmware, по приказу руководства который драли, где возможно, с прошлой модели. А вот как раз для будущего software ИМЕННО ТАКАЯ «аранжировка» совсем НЕ требовалась, а лучше подошла бы совсем другая.

1. Опять сферические кони в ваккуме. :) «другая». Какая именно?
2. С выдумкой по ходу дела firmware/software это ты ловко. Подвела таксономия, firmware это часть software. И выдумывать не надо, о чем идет речь ясно 2мя предложениями выше.
НЕУДОБНАЯ для кодера адресация. И нет, требование соответствовать особенностям элементной базы его НЕ оправдывает. Потому что можно было И сделать лучшую раскладку, И соответствовать.

Опять «лучшую». Хардварную конкретику, плз. :)
Да куда полнее-то, непонятно. В том, что касается конкретно темы твоей статьи, я вполне конкретно предложил столбцовую раскладку — тебе что, мало?

Конечно мало. В этом-то всё и дело, дьявол таится в мелочах, когда начинаешь разбирать. Просто предложение иметь столбцы — это лишь наши с тобой мечты с дивана, не более. Столбцы, для начала, должны иметь высоту обязательно 256 байт, иначе с другими столбцами затея теряет смысл.
Дальнейшие вопросы.
Что насчет цвета? А то этот вопрос у тебя остался за кадром, спектрум получился монохромный как «Специалист».
Какова геометрия экрана? Сколько столбцов? Какой получается суммарный объем?
Пытаясь понять не пропустил ли я у тебя какие-то подробности, увидел http://hype.retroscene.org/blog/889.html#comment23546
Хотя в 8k вполне можно было уложить вектороподобную раскладку для page mode read (могла, правда, усложниться схема регенерации).

Как на 4116 (не на 4164) организовать page mode read страниц по адресам кратным 256? Напоминаю, у нее страница — 7 бит. Т.е. 128 байт.

Про чтение цвета также не забудь.

И еще, там aa_dav цитирует Chris Smith насчет якобы 320нс. У него в книжке единственная ссылка на NEC'овский Datasheet. 320 нс это у быстрых NEC µD416C-3, µD416C-5, а у Sinclair ставили разное, но в основном самое дешёвое, µD416C-2 и вообще разнобой, память с разным grade (по фото реальных плат). У µD416C-2 или у MOSTEK 4116P-2(3) цикл 375нс.
avatar
1. Опять сферические кони в ваккуме. :) «другая». Какая именно?
ZOMG, мне что, столбцы в каждом предложении поминать?

2. С выдумкой по ходу дела firmware/software это ты ловко. Подвела таксономия, firmware это часть software.
А человеки это часть человечества. Это же не повод сказать начальнику, что повышения зарплаты требует человечество.

И выдумывать не надо, о чем идет речь ясно 2мя предложениями выше.
«Выше» относительно чего, где? Теперь ты давай конкретику, процитируй.

Конечно мало. В этом-то всё и дело, дьявол таится в мелочах, когда начинаешь разбирать. Просто предложение иметь столбцы — это лишь наши с тобой мечты с дивана, не более. Столбцы, для начала, должны иметь высоту обязательно 256 байт, иначе с другими столбцами затея теряет смысл.
И в чём проблема? Значит, будет 256 байт. Что совсем не означает столько же пикселей.

Что насчет цвета? А то этот вопрос у тебя остался за кадром, спектрум получился монохромный как «Специалист».
Он остался у тебя, а не у меня, потому что ты в прошлый раз не соизволил пройти по ссылке:
hype.retroscene.org/blog/889.html#comment23547
где обсуждается, куда пихать атрибуты

Какова геометрия экрана?
Какая хочешь, при условии 256 байт на столбец.

Сколько столбцов?
Сколько влезет или меньше, сколько захочешь.

Какой получается суммарный объем?
Кол-во столбцов * 256 байт

Как на 4116 (не на 4164) организовать page mode read страниц по адресам кратным 256? Напоминаю, у нее страница — 7 бит. Т.е. 128 байт.
Кратность 256 не имеет отношения к «страницам» микросхем памяти. Для возможности применения видеоконтроллером page mode требование простое — из 14 бит адреса (2 самых старших не учитываем) у полоски пикселей и соответствующего атрибута должны совпадать 7 бит. И притом неважно каких, потому что всегда можно и на плате линии перепутать.

Поскольку атрибуты лежат в одном столбце с пикселями, то старший байт адреса один, то есть совпадают уже 6 бит. Последний совпадающий бит найти можно, например, если начинать распределять байты от средней линии. То есть центр столбца по высоте это младшие байты адреса для пикселей #7F и #80, соответствующих атрибутов — #00 и #FF. Сдвиг от центра на пиксельную линию — #7E и #81 против тех же #00 и #FF. Сдвиг на знакоместо — #77 и #88 против #01 и #FE. Совпадает старший бит младшего адреса. Все 7 нужных совпадающих бит нашли.

Единственное мелкое неудобство — номер линии растёт сверху вниз, а номер атрибута снизу вверх. Но всё равно для движения достаточно inc и dec. И конверсия адресов пикселей и атрибутов тоже выполняется очень просто:
P2A: sla a:sla a:sla a:xor #F
A2P: xor #F:add a:add a:add a
(это для атрибутов 8x8, но в данной схеме можно также регулировать их размер в связи с размером растра по вертикали)
avatar
Совпадает старший бит младшего адреса.
* старший бит младшего байта адреса, конечно же
avatar
sla a:sla a:sla a:xor #F
* sra, не sla (ну вот почему каменты править нельзя)
avatar
Дорогой Lethargeek.
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.

Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.

Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…

Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;

Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
avatar
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе.
Что здесь странного, если в тексте семантические ошибки и альтернативный русский язык? Даже раз, небось, прочесть поленился, отсюда перлы типа 14 бит, которые равны 16 килобитам))

Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне.
Даааааа? С чего бы? Текст ты написал НЕ СЕБЕ, а выложил на общее обозрение. И потому ТВОЯ задача писать его так, чтоб не было нечёткостей и ошибок. Я считаю, что моё прочтение текста согласуется с логикой и правилами русского языка.

Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Снова нелады с русским? Раз ЛЮБОЙ, то в том числе и такой, для которого раскладка Спектрума НЕУДОБНА.

Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
А теперь проблемы с логикой. Вот какая разница, КТО писал, если Я дал в качестве ОТВЕТА на твой вопрос. Или мне теперь и буквами не пользоваться, потому что их придумал кто-то другой?

Снова проигнорированы важные вопросы о геометрии экрана.
Где? Какие важные вопросЫ (теперь еще во множественном числе)? Что ты понимаешь под ГЕОМЕТРИЕЙ? Видимо, не ширину и не высоту, потому что на вопросы о ширине и высоте я ОТВЕТИЛ — они могут быть практически какими угодно (лишь бы влезло в тв-стандарт и в 256 байтов на вертикаль)

Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу,
СТОП! с чего доказывать вдруг надо именно ЭТО? Ни «8k», ни тем более «1/60сек» совершенно к делу отношения не имеют. Доказать нужно ТОЛЬКО то, что байт полоски пикселей и байт соответствующего ей атрибута можно прочитать в страничном режиме. А для этого достаточно совпадения любых 7 бит в 14-битных адресах этих двух байтов. Лично мне это очевидно.

Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;

Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
Ёжкин кот жеж. Совпадающие (то есть СТАРШИЕ 7 БИТ) выставить, естественно, в RAS. Я же русским языком написал, что в старшем байте адреса совпадёт 6 бит (то есть все, кроме двух старших и неучитываемых) и в младшем байте адреса совпадёт еще один (старший) бит. Ну, на в цифрах, если ты по-русски не понимаешь:

RAS: c13, с12, с11, с10, с9, с8,h7
CAS: h6,h5,h4,^3,^2,^1,^0 (a)
CAS: v6,v5,v4,v3,v2,v1,v0 (p)

c — столбцы экрана, инкремент слева направо
v — вертикаль пикселей, инкремент сверху вниз
^ — вертикаль атрибутов, инкремент снизу вверх
h — верхняя или нижняя половина (все биты h* равны)
avatar
О байтах и «русском языке».
Я тут пару сообщений назад все хотел тебе сказать:
в общепринятом смысле «байты» (октеты) в адресе видеоконтроллера,
выставляемого на DRAM отсутствуют,
поскольку ША видео-адреса, будучи представленной выводами счётчиков,
не пересекается с микропроцессорной ША, вот такая для тебя шокирующая новость.
Однако говорить о старшей и младшей части адреса можно.

c13, с12, с11, с10, с9, с8, h7, v6, v5, v4, v3, v2, v1, v0


14 бит, 2^14 = 16384.
У вас факапчик-с приключился с видеообластью объемом 16кб.

RAS: c13, с12, с11, с10, с9, с8,h7


Тут еще один факапчик из-за банального незнания как регенерируется DRAM.
К сведению: tREF по даташиту MAX 2 ms. Бит h7 — половина высоты растра. Сколько это ms?
Сорян, придется всё переделать, чтобы заработало в реальности.

avatar
в общепринятом смысле «байты» (октеты) в адресе видеоконтроллера,
выставляемого на DRAM отсутствуют,
поскольку ША видео-адреса, будучи представленной выводами счётчиков,
не пересекается с микропроцессорной ША, вот такая для тебя шокирующая новость.
это для меня совсем не новость, представь себе

Однако говорить о старшей и младшей части адреса можно.
ну и к чему тогда пустая придирка выше? Чтобы только показать вумность?

14 бит, 2^14 = 16384.
У вас факапчик-с приключился с видеообластью объемом 16кб.
Нет, здесь факапчик-с у тебя приключился. Ты не подумал, что 16k нужно было бы для всех теоретических 64 столбцов, но столько даже в тв-строку не влезает с квадратным пикселем. 32 столбца как на спеке — 8k. А хочешь 320 пикселей в ширину, как на всех нормальных компах обычно — 10k. И то, что эта схема НЕ ДИКТУЕТ единственно возможную ширину экрана, как у Альтвассера — жирный ПЛЮС.

Тут еще один факапчик из-за банального незнания как регенерируется DRAM.
К сведению: tREF по даташиту MAX 2 ms. Бит h7 — половина высоты растра. Сколько это ms?
Нет, еще один факапчик тут опять у тебя из-за привычки очень выборочно читать. К сведению: выше сказано, что могла усложниться схема регенерации. И дело даже не в h7, а в том, что не перебираются все столбцы. Переделывать ничего не требуется, а достаточно 1-2 «лишних» чтений на строку растра, что практически процессор не замедляло бы (но, возможно привело бы к удорожанию изделий на пару фунтов, если бы не влезло в юлу).
avatar
Нет, здесь факапчик-с у тебя приключился. Ты не подумал, что..

Я конечно видел много клоунады, но такую чтобы мой оппонент сначала что-то нарисовал или написал,
а потом, несмотря на четко нарисованные биты, заявил что я должен якобы представлять это не так (при том что написал/нарисовал — он всё вполне четко) — вот такую изворотливость я вижу впервые.
Поздравляю. Ведь если уменьшить количество столбцов, уменьшится количество бит (или диапазон пересчета) и будет происходить регенерация не всех строк DRAM.

И дело даже не в h7

Дело в том что у тебя нарушена регенерация памяти и железо не рабочее. Дело в этом.
И пустым птицебольством «выше сказано, что могла усложниться схема регенерации» — не отделаешься.

Дело за малым, жду от тебя столбцовую раскладку адресов, такую чтобы работало.
Приведи корректные биты адреса, идущие от контролера к DRAM 4116. Если это возможно в реальности, а не в диванных мечтах.
avatar
Я конечно видел много клоунады, но такую чтобы мой оппонент сначала что-то нарисовал или написал,
а потом, несмотря на четко нарисованные биты, заявил что я должен якобы представлять это не так (при том что написал/нарисовал — он всё вполне четко) — вот такую изворотливость я вижу впервые.
Клоунадой ты сейчас занимаешься. И нарисовано, и сказано было чётко: «c — столбцы». А то, что в этих битах непременно должны перебраться все комбинации — исключительно твои личные сексуальные фантазии. Я же ничего такого не утверждал.

Поздравляю. Ведь если уменьшить количество столбцов, уменьшится количество бит (или диапазон пересчета) и будет происходить регенерация не всех строк DRAM.
иииииишто? Кто сказал из религиозных авторитетов, что регенерация должна осуществляться именно чтением растра для отображения и никак иначе?

Дело в том что у тебя нарушена регенерация памяти и железо не рабочее. Дело в этом.
И пустым птицебольством «выше сказано, что могла усложниться схема регенерации» — не отделаешься.
Дурачок? Если нет, то прекращай включать дурачка. Даже в спектруме есть огромный промежуток в регенерации в 152 строки развёртки, почти полкадра. То есть достаточно делать один лишний доступ во время hblank, последовательно перебирая RAS от 0 до 127 — промежуток даже меньше получится. Можно даже применить для этого штатный счётчик строк видеоузла (но тогда на один hblank могут понадобиться два доступа, если промежуток в 184 строки слишком долгий).

Дело за малым, жду от тебя столбцовую раскладку адресов, такую чтобы работало.
Всё рабочее. Заканчивай клоунаду. От тебя жду формулу «коэффициента извратности перестановок»
avatar
Клоунадой ты сейчас занимаешься. И нарисовано, и сказано было чётко: «c — столбцы». А то, что в этих битах непременно должны перебраться все комбинации — исключительно твои личные сексуальные фантазии. Я же ничего такого не утверждал.

? Ты нарисовал 7-бит часть адреса DRAM идущую по сигналу строба RAS:
RAS: c13, с12, с11, с10, с9, с8,h7
CAS: h6,h5,h4,^3,^2,^1,^0 (a)
CAS: v6,v5,v4,v3,v2,v1,v0 (p)
Если это 7 бит адреса, стробируемые RAS и передаваемые в микруху, то какие требования предъявляет микросхема 4116?
Почему ты считаешь что это «я» с тебя требую, а не DRAM 4116?
Ты до сих пор не понял, чем (а не кем) обусловлено такое требование?

иииииишто? Кто сказал из религиозных авторитетов, что регенерация должна осуществляться именно чтением растра для отображения и никак иначе?

Значит рисуй заново.

Дурачок? Если нет, то прекращай включать дурачка. Даже в спектруме есть огромный промежуток в регенерации в 152 строки развёртки, почти полкадра. То есть достаточно делать один лишний доступ во время hblank, последовательно перебирая RAS от 0 до 127 — промежуток даже меньше получится. Можно даже применить для этого штатный счётчик строк видеоузла (но тогда на один hblank могут понадобиться два доступа, если промежуток в 184 строки слишком долгий).

1. Нужно не писать чушь, что выше, а знать что 4116 в отсутствие ULA рефрешит Z80.
2. Не надо переходить тонкую грань между шутками и оскорблением.

В сухом остатке.
Предложенная тобой схема столбцов — не работает.
Или ты дизайнишь столбцовый access к 4116 хотя бы расписав в виде циклов и адресов. Или затея иметь столбцовый растр не состоятельна, провалилась при практической реализации.
Ч.Т.Д.
avatar
? Ты нарисовал 7-бит часть адреса DRAM идущую по сигналу строба RAS:
RAS: c13, с12, с11, с10, с9, с8,h7
CAS: h6,h5,h4,^3,^2,^1,^0 (a)
CAS: v6,v5,v4,v3,v2,v1,v0 (p)
Если это 7 бит адреса, стробируемые RAS и передаваемые в микруху, то какие требования предъявляет микросхема 4116?
Почему ты считаешь что это «я» с тебя требую, а не DRAM 4116?
Ты до сих пор не понял, чем (а не кем) обусловлено такое требование?
КАКОЕ «такое»? Это что еще за обращение к телепату? «Предъявляет требования» К ЧЕМУ? К силе тока, температуре и напряжению? За этим в даташит. Если ты про частоту рефреша, то к частному вопросу о подборе адресов для отдельно взятого page mode цикла это никакого отношения НЕ ИМЕЕТ. Если ты про комбинацию 7 бит, то в одном отдельно взятом доступе микросхема к ней не предъявляет НИКАКИХ требований. Допустима ЛЮБАЯ комбинация, и прочитана будет корректная информация. Вот такая для тебя шокирующая новость (c)

Значит рисуй заново.
С чего «значит»? Ты совсем не можешь в логику, ни на бит?

1. Нужно не писать чушь, что выше, а знать что 4116 в отсутствие ULA рефрешит Z80.
2. Не надо переходить тонкую грань между шутками и оскорблением.
Но ведь ты действительно, мягко говоря, неумён, если сам не понимаешь, что следует и что не следует из твоих же собственных слов и сечёшь себя хуже унтер-офицерской вдовы. Ну, рефрешит юла медленную память в спеке, И ЧТО ИЗ ЭТОГО? Вот с чего ты делаешь странный вывод, что в принципе рефрешить её может ТОЛЬКО юла? И притом еще ЕДИНСТВЕННЫМ способом, только чтением строго пикселей и атрибутов, ничего больше? Тогда как в нашей унылой реальности без летающих розовых слонов для рефреша нужен только доступ к каждому ряду с частотой не ниже оговоренной, и кто будет обеспечивать эти доступы — пдп, процессор, юла, волчок, диаболо, слинки или йо-йо — для микросхемы совершенно НЕ ВАЖНО.

В сухом остатке.
Предложенная тобой схема столбцов — не работает.
В сухом остатке: ты тупишь, а схема вполне рабочая.
avatar
Понятно.

Я с тобой до этой поры не пересекался. Поэтому не знал что у тебя за натура, верил в лучшее.
Народ тут уже намекнул, что я опозорился самим этим фактом разговора с «летаргичкой».
Засим пока, позориться мне дальше вряд ли стоит.

https://www.youtube.com/watch?v=IA_evL-1F0w&t=33
avatar
Бедненький, если бы не пересёкся со мной, до сих мог бы на умного походить. А теперь каждый может убедиться, какой ты на самом деле www.youtube.com/watch?v=IYtVFNhDdVo
avatar
Поскольку атрибуты лежат в одном столбце с пикселями, то старший байт адреса один, то есть совпадают уже 6 бит.
Последний совпадающий бит найти можно, например, если начинать распределять байты от средней линии.

Инженеры не пользуются подобной терминологией, в электронике сложно представлять «средние». Именно этот образ мышления, терминология и форма выражения мысли поначалу вводит в полный ступор.

То есть центр столбца по высоте это младшие байты адреса для пикселей #7F и #80, соответствующих атрибутов — #00 и #FF.
Сдвиг от центра на пиксельную линию — #7E и #81 против тех же #00 и #FF.
Сдвиг на знакоместо — #77 и #88 против #01 и #FE. Совпадает старший бит младшего адреса.
Все 7 нужных совпадающих бит нашли.

Не удивительно, что я долгое время не мог ничего понять, у меня даже мысли не работают подобным извращенно-искривленным образом, чтобы я смог до такого додуматься. Смеялся я дооолго...
Ндаа… и эти люди раскритиковали Sinclair ZX Spectrum!

Объясняю, что тут такое придумано.
Lethargeek предлагает чтобы layout (адресация) была такой:


Address |  Type   |   Comm.
--------------------------------
#xx00    Attrs     Начало столбца из 256 байт, байт атрибутов   <--+
#xx01    Attrs     Следующий адрес атрибутов                       |
#xx02    Attrs     И так далее, байт атрибутов                     |
...                                                                | Соответствие
...                                                                | центр.пикс = край атр.
#xx7E    Pixels                                                    |
#xx7F    Pixels    <- Пиксель -1 по вертикали от центра         <--+

                                   --- условная линия разделяющая экран по высоте ------
                                   
#xx80    Pixels    <- Пиксель +1 по вертикали от центра         <--+
#xx81    Pixels                                                    |
                                                                   |
...                                                                |
#xxFD    Attrs                                                     |
#xxFE    Attrs    Предпоследний байт в столбце, байт атрибутов     |
#xxFF    Attrs    Последний байт в столбце, байт атрибутов      <--+


То есть, в центре столбцов — пиксели, а по краям столбца сверху и снизу атрибуты.
При этом лежащие ближе к центру столбца (по-вертикали) байты пикселей соответствуют атрибутам ближе краю (по-вертикали) экрана.
Т.е. в начале адресов #xx00..#xx0F лежат атрибуты, далее с адреса #xx10 до адреса #xxEF идут пиксели, затем по адресам #xxF0..#xxFF снова лежат атрибуты.

Адресация такова:
двигаешься по пикселям вверх, адрес атрибутов спускается вниз.
двигаешься вниз, адрес атрибутов идёт вверх.
Высота экрана 224 строки (#E0).

Lethargeek должен быть внесен в анналы спектрумистов как выдумщик
самого наибольшего hardware-извращения, какое только можно представить.
За сим нарекаю справедливо заслуженным титулом «хардварный Петросян». :)))))
avatar
Инженеры не пользуются подобной терминологией, в электронике сложно представлять «средние». Именно этот образ мышления, терминология и форма выражения мысли поначалу вводит в полный ступор.
а при чём тут электроника? когда это нужно было представлять в ГЕОМЕТРИИ )))

Не удивительно, что я долгое время не мог ничего понять, у меня даже мысли не работают подобным извращенно-искривленным образом, чтобы я смог до такого додуматься. Смеялся я дооолго…
Ндаа… и эти люди раскритиковали Sinclair ZX Spectrum!
Нет, у ТЕБЯ они работают таким образом, если ты извращённо-искривлённый спектрум считаешь лучше. Это же именно на спектруме приходится извращаться для такой простой операции, как сдвиг по вертикали экранного адреса. Да и для вычисления по координатам самого адреса.

Соответствие | центр.пикс = край атр.
Ты неправильно используешь слово «край». У закольцованной структуры нету краёв. У фрагментов же внутри такой структуры край считается по выходу за фрагмент.

Lethargeek должен быть внесен в анналы спектрумистов как выдумщик
Если что, я не претендую на единоличное авторство))
Это всё результат одного давнего коллегиального обсуждения.

самого наибольшего hardware-извращения, какое только можно представить.
За сим нарекаю справедливо заслуженным титулом «хардварный Петросян».
Ладно, понимаю, со стороны софта у тебя мозги могли быть безнадёжно искривлённо-извращены многолетним программированием на спеке. Но вот с чего ты в hardware извращение усмотрел? Применяется ведь тот же самый приём, что в спектруме — перепутывание адресных линий. А теперь ВНИМАНИЕ, ВОПРОС: ПОЧЕМУ ОДНО ПЕРЕПУТЫВАНИЕ ТЫ СЧИТАЕШЬ ИЗВРАЩЁННЕЙ ДРУГОГО? Ведь у тебя наверняка есть какие-то СЕРЬЁЗНЫЕ основания (раз уж ты такой серьёзный Непетросян)) Напиши, пожалуйста, нам здесь серьёзную формулу для вычисления КОЭФФИЦИЕНТА ИЗВРАТНОСТИ по заданной комбинации 14 неповторяющихся номеров! :|
avatar
Lethargeek
ПОЧЕМУ ОДНО ПЕРЕПУТЫВАНИЕ ТЫ СЧИТАЕШЬ ИЗВРАЩЁННЕЙ ДРУГОГО?
Ведь у тебя наверняка есть какие-то СЕРЬЁЗНЫЕ основания (раз уж ты такой серьёзный Непетросян))
Напиши, пожалуйста, нам здесь серьёзную формулу для вычисления
КОЭФФИЦИЕНТА ИЗВРАТНОСТИ
по заданной комбинации 14 неповторяющихся номеров!

Зигмунд Фрейд
avatar
Вот напишешь формулу, и тогда сможешь смело встать у подножия пьедестала этого специалиста по извращениям)))
avatar
Ты неправильно используешь слово «край». У закольцованной структуры нету краёв. У фрагментов же внутри такой структуры край считается по выходу за фрагмент.

Закольцованный экран без края?
Ват зе… Прям слышно как трещит мой шаблон...
Я всё понял. Страшный ты человек, зря я с тобой связался...
Пацаны, бегите… :)))
avatar
Закольцованный экран без края?
снова смысловые галлюцинации? где там было сказано, что ЭКРАН?

Закольцованный экран без края?
Ват зе… Прям слышно как трещит мой шаблон…
Я всё понял. Страшный ты человек, зря я с тобой связался…
Пацаны, бегите… :)))
Не паясничай. И ты еще смеешь обвинять меня в клоунаде…
avatar
Любопытный тред. Спасибо. Надо будет сходить на zx.pk.ru, давно там не был. Мне интересно, как ты измеряешь время/производительность/такты чтобы выстроить график. Научи?
avatar
так это, смотрю в эмуле на счётчик тактов до/после call
график мой неточный, ломаной по нескольким точкам
поверх старых точных графиков топикстартера
и накинул щедро 500 тактов сверху на вход еще
по завершении должно получиться немного меньше
avatar
Руками, значит. В эмуле Unreal Speccy?
avatar
в xpeccy или в zxspin, они поудобней
avatar
> zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444

Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
avatar
Вопрос в самом деле хороший, но, глядя на обсуждение, хочется надеятся, что всё придет если даже и не к написанному коду или какому-то реально ощутимому проекту, то хотя бы к новому способу борьбы с клэшингом.
avatar
Мороз, руки прочь от клешинга!)
avatar
Это не поможет.
Поможет — ZX Evolution (+TSConf), ZX Next, Reverse.
А также навеска FT812, v9990…
avatar
это неспектрумы :P
avatar
Простите за резкость и чёткость.
Приделать к оригинальному спектруму аппаратное ЧТО-ЛИБО ВООБЩЕ, это как к сельскому деревянному толчку приделать лцд экран с тачпадом для общения в соцсетях.
Формально — нужно переставить в адресе 2 группы по 3 бита, концептуально — такое бы в голову не пришло никому.
Алсо, для подобных «удобств» в свое время сделали аж целую команду z80 — DAA.
  • tsl
  • +1
avatar
переставить биты — это не соцсети приделать, это как переместить гвоздик для бумаги или щеколду
avatar
Я специально выбрал такой пример, чтоб подчеркнуть не сложность фичи, а то, что авторы думали настолько «на отъебись», что ни за что не сделали бы ничего подобного.
avatar
А, и да: вообще то это не баг, а фича by design.
avatar
DAA?
avatar
@tsl, походу в этом треде жгут вообще поголовно все!

Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.

Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
avatar
Лёш, про стек наверное в 89 так же говорили) Команды PUSH и POP нужны для того, чтобы сохранять и восстанавливать значения! Не надо придумывать для них странное применение, зачем помещать стек в экранную область? ЕРЕСЬ СЖЕЧ!
avatar
(Это шутка, если что!)
avatar
Я сейчас не помню кто первым изобрёл копирование буфера в экран стеком. Но точно помню что это было раньше, что-то типа 1985 или 1986; думаю к 1989, которых не клали в экран стеком, просто уже увольняли по профнепригодности :)
avatar
Чистка стеком применяется много где. Да хотя бы в той же Elite 1985 года. Но вот на пример именно копирования буфера, чтобы стеком и чтение, и запись осуществлялись, могу вспомнить только Wec le Mans от 1988
avatar
В той же Элите вместе с чисткой экрана стеком делается и копирование буфера стеком.
avatar
Elite вышла на спектруме в конце 1985 года — обзоры в журналах датированы ноябрём или декабрём. Для сравнения, обзоры на Starion вышли в мае-июне, когда спектрумовская элита хорошо ещё если уже планировалась.
avatar
нет, ldi-ldi-ldi
avatar
Да, я ошибся, в голове отложился код переноса буфера стеком, почему-то ассоциировался с Элитой. Сейчас проверил две версии Элиты, в обоих LDI. Странно, потому что я другие игры особо не копал.
avatar
Православный ассемблер на русском: PUSH и POP — ВСУНЬ, ВЫСУНЬ (И это лучше чем ПИХ, ВЫПИХ!)
avatar
А мне абсолютно норм! Вышел tsl, крикнул первую попавшуюся команду, и ушел в туман. Чего еще? Самое то, всё по закону жанра. По идее, он может еще где-то из-за кулис крикнуть: «прерывание вам всем в кернель!» После этого стреляет пушка и появляется VBI :)))
avatar
Про DAA: это просто пример апп. костыля для узкой задачи. Не имеет ничего общего с экраном 6912 =)
avatar
А я просто написал: Даа? Удивился сильно прост. По-английски. =)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.