Теоретический вопрос по железной начинке ZX Spectrum
На фоне обсуждений последних двух дней у меня родился вот какой вопрос:
Возможно ли было в чипах ULA спектрума сделать дёшево и сердито вот какую концепцию:
а) запись в некие два порта вывода X и Y координаты пикселя генерировали бы на входе трёх других портов ввода:
б) верхний байт адреса полоски пикселей в массиве пикселей видеопамяти
в) нижний байт адреса полоски пикселей в массиве пикселей видеопамяти
г) верхний байт адреса атрибута этой полоски пикселей
(нижний байт адреса атрибута тут не нужен, т.к. мы уже знаем, что он совпадает с (в) после предыдущих тем)
На уровне проводов это просто разброска линий и их перемешивание, что мы видели в предыдущих темах.
Так не было ли бы это возможным сделать без весомых затрат на самом старте?
(сразу обозначу — это чисто теоретический вопрос и статью я по нему писать не собираюсь. просто очень интересно.)
Возможно ли было в чипах ULA спектрума сделать дёшево и сердито вот какую концепцию:
а) запись в некие два порта вывода X и Y координаты пикселя генерировали бы на входе трёх других портов ввода:
б) верхний байт адреса полоски пикселей в массиве пикселей видеопамяти
в) нижний байт адреса полоски пикселей в массиве пикселей видеопамяти
г) верхний байт адреса атрибута этой полоски пикселей
(нижний байт адреса атрибута тут не нужен, т.к. мы уже знаем, что он совпадает с (в) после предыдущих тем)
На уровне проводов это просто разброска линий и их перемешивание, что мы видели в предыдущих темах.
Так не было ли бы это возможным сделать без весомых затрат на самом старте?
(сразу обозначу — это чисто теоретический вопрос и статью я по нему писать не собираюсь. просто очень интересно.)
140 комментариев
вообще можно конечно прилепить МК какой (УЛА тут и не нужен), который будет слушать порты и плевать ответы. но:
1. это уже будет не совсем спектрум
2. 2 OUT + 3 IN — 48 тактов, это без учета установки регистра C
Это не имеет смысла, так как он и так быстро вычисляется по таблице 512 байт, если расположить её в памяти с адреса кратного 256:
Не только экранный адрес, но и адрес цвета. Там же просто перемешать биты определенным образом и готово и то и другое за нулевое машинное время — ни складывать ни вычитать не надо. Но есть возня с портами дольше даже, чем перемешивание бит, то… вот как раз и хотелось спросить про это.
37 тактов и 512 байт памяти
62 такта, что к следующему порту можно перейти так.
или в случае 8-битых портов
60 тактов
Но дело в другом, такое не принято исходя из соображений здравого смысла. Проблемы вычислений адреса — это по-логике проблемы процессора, проблемы даже алгоритма, а не аппаратуры. Такого не было, даже на PC-шных EGA/CGA/VGA видекартах с их чумовейшими битпланами, на амигах/атарях, на консолях или на монструозных arcade game board.
Однако это не значит что данный подход плох или не работает. Работает, и такая идея и меня давно посещала также, и для вычисления адреса, и позже — для выполнения умножения/деления, либо для более генеральных вещей — для общения с «сопроцессором». Подобное весьма активно использовалось на NES/SNES, в дополнительных RISC-микропроцессорах стоящих на картридже игры, только работало не через OUT, а через запись в ячейки памяти и/или DMA.
ld l, y; 4
ld a, (hl); 7
…
Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса
Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
Вот заметка Flying, которая меня в своё время удивила: zxpress.ru/article.php?id=3614
Про Robus у меня не так много очевидных ссылок; ну вот можно например глянуть прямо у нас на Хайпе: hype.retroscene.org/blog/demo/830.html
Но вообще чем больше ты будешь писать под меня или под кого-то ещё, тем, мне кажется, выйдет неинтереснее. Интересно как лично ты видишь программирование на спектруме. Вот Flying сел писать такую заметку и у него вышел рассказ про библиотеку менеджмента памяти. Он ведь много что накодил, а болел получается именно этим. Вот интереснее всего и выходит когда рассказывают о том, что наболевшее в каком-то смысле.
А то как ты говоришь — этим занимался, как раз, ваш покорный слуга :))) (скрежеща зубами :) потому что ни PC, ни Amiga у меня не было). Почему я 100% уверен что драли? Ассемблерный код, разумеется, не перенесешь, но переносили нетривиальную основу (задумку) и математику эффекта.
А в некоторых эффектах и задумка и внутренняя реализация совпадает на 100% с оригиналом. Касаемо Codebusters/RST7 — какие там могут быть сомнения что «драли», если используется выдранный с Amiga/MSX контент… Первое же что вспоминается, кораблик из заставки MSX-игры Gradius(Nemesis) или туннель из Amiga Stardust.
Ну а касаемо Лёхи Exploder'а, не будем забывать что он несколько раз брал призы на Assembly в амижных демках…
Думаю, что если провести опрос у всех кодеров, кто реализовал что-то известное на ZXе, то выяснится, что не «драли». Имеется в иду повторяли визуально, а не декомпилили. Что касаемо RST7, то он повторял визуально. Не забывайте, что он сперва кодер, а потом уже график/музыкант. Поэтому совершенно очевидно, что ради примера он брал уже готовую картинку, в данном случае из игры. Из разговоров с TITUSом я понял, что они вдвоём любили общаться друг с другом в ключе — «вон смотри там есть эффект», и в итоге его повторяли. Судя по всему RST был жуткий генератор всего, что видел вокруг себя, а то как он это генерировал сделало тем кем он стал. К сожалению не все могут реализовать свои идеи по очень разным причинам, начиная от — «нет времени», кончая — «демки это дурь, круть только игры». А ведь у каждого не сбывшегося есть идеи, но никто он них не узнает, по скольку сработал триггер «НЕ».
Из того, что я могу судить, то «декомпилить» по факту нет смысла. Я не могу свой код перетащить фактически не на один компилятор, ведь я знаю, что тысячи макросов генерируют результат в виде «мяса». Из чего появляется главный вопрос, который я постоянно задаю сам себе — «зачем вообще нужна процедура самой быстрой точки» ??? Она, конечно, нужна, но исключительно как пример мастерства кодинга в конкретном случае, и этот случай только один — «SUPER FAST POINT». Ведь каждый из вас понимает, что из этой процедуры можно нарисовать только то, что очевидно, и мало того это уже нарисовано много-много-много лет тому назад. А вот если вы будете обсуждать комплекс решений, не саму точку, а то, что хотите получить в конце, вот тогда это очень полезно. Вот в данной статье добавьте самое главное, — «автомат», который даст мне рисовать группу точек по тем или иным параметрам. И даю вам гарантию, что этот «автомат» обязательно используют не по назначению, и в итоге вы будете смотреть на какой-нибудь эффект и задаваться вопросом — «а как?». Ведь в этом же смысл всех эффектов? Да? Ведь когда вы впервые смотрели на эффект RST7 с мультиколором, уверен, что не было ни одного вопроса типа — «о… этот корабль так прекрасен, кто же его нарисовал?», за то точно все задались вопросом — «я вижу цветную картинку, которая летает вверх-вниз по-пиксельно, а квадратиков нет, КАК?». Так что, — не важно от куда эта картинка, важно, что она тут, и в таком, вот, крутом виде.
Идеи… Идеи это самое интересное. Я видел очень много разных людей и могу с уверенностью сказать, что чистые идеи могут появиться только у гениев. Все остальные всегда-всегда-всегда-всегда-всегда-всегда и ещё раз всегда, что-то за кем-то повторяют. Конечно же улучшая! Хотя не всегда улучшая, не спорю, но как правило мы обращаем внимание на тех, кто улучшает. Посудите сами, вы же не будете своего ребёнка упрекать, что он подобно вам научился говорить, хотя, в принципе, он мог по ходу взросления взять и придумать свой язык. Далее он вырастит и научиться ещё чему-то, например кодить. Уверен, что вы будете им гордиться, хотя могли бы сказать, а чего-то это ты пишешь на том, чём папка писал, неее… — давай свой язык придумывая, а заодно и компьютер придумай. — Ребёнок повторяет за вами улучшая вас. Не спорю, он может родиться гением, и построить что-то сверх крутое, ну тогда будете ещё больше гордиться. Так, что повторять что-то за кем-то не есть плохо, главное, — что ты вносишь нового в чужую идею, делая её уникальной, а значит своей.
Снова про идеи, только с другой стороны. Чем хороши группы? В них идеи распределяются по мере мастерства каждого участника. Кодер фактически не может увидеть какова будет картинка или какой будет звук. Поэтому он сделает свою часть максимально изощрённо, и если у него не будет графика, то всем будет казаться, что эффект украден. Точно так же график видит чего накодит кодер и рисует к этому своё видение. По сути в реалиях — кодер работает с «рефференсом», если я правильно вспоминаю слова из классического построения современных задач. И прекрасна та команда(группа), которая находится в симбиозе. Вот последний человек в моём творчестве, который подхватывал мои идеи, — был Screen Killer, я ему постоянно отдавал все свои эффекты, которые он оформлял. Первый раз я это ощутил, когда делал эпилог для демки Virtual, где придумал совершенно идиотскую идею запустить титры по изогнутому листочку, который представлял себе помятым пергаментом. Всё что я сделал это нарисовал в ART-STUDIO, контур листочка в проекции, и запустил по ним титры. А он взял фотографию монитора и сказал, сейчас мы его расплавим и наложим на твой контур. И всё стало другим, всё стало лучше в разы. Этим и прекрасны коллективные работы, в них много идей, и как их не копируй, всё равно оригинал будет лучше.
И опять про идеи… Но истории о группе были очень давно. Очень очень давно… Каждый уже давно пошёл по своему пути. У меня есть файл в который я постоянно добрасываю идеи эффектов, и идеи игр так же, и идеи видео. Много там идей, их там сотни две — точно есть. Фактически все эти идеи есть последствие того, что я вижу в других работах, причём как демки, так и фильмы, картины, театр, да вообще всё что меня окружает. Я их сажусь и описываю, как понимаю сам и ни одна идея не была реализована так как я её описал. Многими идеями делюсь с Вовкой, надеюсь ещё не надоел со своими звонками… Многие идеи реализовал, и они лежат в виде кусков неприглядного кода. Есть куча музыки, которая вызовет очень много вопросов, от чего её не использую. Хотя я не знаю, до конца, как её вообще воспримут. Но я точно знаю, что большинство моих идей нельзя решить классическим путём, как в области кодинга, так и в области музыки и графики. Но мы все очень разные и как правило жутко упёртые. Хотя, наверное, упёртый я, а не остальные.
Лично я, фактически, никогда не декомпилил чужой код, хотя умудрился написать в 1995 году для этого декомпилятор — «DISDEV», так ни разу не использовал его по назначению, за-то декомпилировал ПЗУшку, получил море удовольствия и геморроя узнав как можно использовать команду «JP(HL)».
Однако я останусь при своем мнении по массе причин.
1. Дискуссия заведомо обречена, потому что в обсуждении будут появляться, в основном те, кто спешит заявить что он никогда не изучал чужой код. Обратное писать не спешат. :)
2. Никакой разумной причины скрывать хакинг нет. Более того, пытаясь сочинить для instrospec запрошенную статью, я напрямик советую смотреть как организован чужой код. Я абсолютно не сомневаюсь в том что сильные «кодеры», прежде всего сильные хакеры. Раньше как-то и не принято было ничего скрывать, хакерство было частью сцены и если не очевидным, то особо не скрывалось. (Пример — девушка из Lyra, сэмплы, картинки, музыка...).
3. Идея о том что не требуется смотреть/знать реализацию эффектов совершенно несостоятельна. Тривиальные вещи, такие как разнообразные скроллинги (мнущиеся, кривые, косые, с разными скоростями и зумом), атрибутную анимацию, спрайты итд смотреть нечего. Но дело в том что существуют advanced эффекты, для которых не зная know-how ты их не реализуешь, сколько ты не смотри. Просмотр знания не заменит. Сходу вспоминается water, rotozoom, bump mapping, fake phong mapping, texture mapping или там kefrens dots (я забыл реальное название, но однажды с introspec'ом обсуждали эффект из Insult — это всё он же). В некоторых случаях требуется знать не математику/алгоритм, а организационно-алгоримтический трюк (грубо говоря, «почему это прокатывает»).
4. Сходство некоторых эффектов на Amiga заметно глазами. Я выше применил достаточно грубый термин «драть», «выдирать» итд. Обычно он соответствует прямому копированию. Нет, я это в виду не имел. Реально достаточно только глянуть одним глазком ;), чтобы узнать как это работает, чтобы затем реализовать в коде нечто подобное.
5. Я не думаю что все всё и всегда смотрят. Многие сложные вещи приятнее сделать быстрыми самому.
Т.е. я не знаю, м.б. Exploder и очень сложный и даже неприятный человек, я же не знаю. Но на основании одного предложения в заметке примерно на пару кб текста, в основном на ассемблере, тебе не кажется, что ты немного скоропалительно приходишь к выводам?
Хотелось бы его найти, пообщаться. Если у кого есть зацепки — дайте знать. :)
Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
Глянул документацию по SjASMPlus — и интуиция не подвела. Там есть для этих оптимизационных целей ключевое слово IFUSED. Прикольно, прикольно…
Потестировал этот IFUSED — а фиг то там, он не умеет разруливать зависимости изнутри самих IFUSED, то есть применим довольно узко в сравнительно простых случаях.
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips
2) даже если был бы небольшой выигрыш, всё равно адрес по координатам объекта (спрайта, конца отрезка) вычисляется однократно, и в % от всего объекта будет уж совсем незначительным
3) не решает основную проблему нелинейной раскладки — медленный и неудобный down_hl, который нужен многократно на весь объект
4) в оригинальной юле, насколько помню, места не осталось уже совсем; добавлять вторую = удорожать комп; а если уж удорожать, то не для такой ерунды, а чего-нибудь намного полезнее (например, автоматического пересчета удобного логического адреса произвольного окна в неудобный физический адрес экрана, не отказываясь от экономии памяти)
Это не делает его удобнее или быстрее чем при постолбцовой раскладке где столбцы 256 байт, но ситуация не так уж и печальна. Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.
делает значительно неудобнее
для 128k разве что (и то, лучше бы отдать экрану часть этой памяти)
при ошибочном целеполагании
Пчму? Пример сотен байтов-килобайтов?
> при ошибочном целеполагании
Объясни, о чем ты, в чем ошибочность, итд
zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444
Вывод спрайтов может обойтись в сотни лишних байтов вместе с обвязкой.
в том, что минимальный размер экрана не означает экономного расходования памяти
30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).
ну вот видишь, ты подумал, что приехал, и успокоился
хотя делить там совершенно необязательно
ничего не понял, почему нет, почему одно и то же, в каких масштабах…
Ты придумал табличку? молодец. Я пока не придумал.
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…
Ты прав в одном, я никогда не буду работать в команде с Lethargeek. А он, наверное, примерно так же никогда не стал бы работать со мной. Потому что команда — это не просто несколько человек с интересом на похожие темы. Это ещё и… назовём это «совместимостью».
график я там выложил, чтоб узнать, мб кто-то лучше с тех пор придумал, нах тогда мне париться с продолжением
благо тема именно об этом была такая, но походу все последние активные кодеры разбежались с «гяфа» за эти годы
Твоё предложение фактически удваивает размер кода за 4 такта на точку. 4 такта — это из цикла где в лучшем случае тратится 26 тактов на итерации (на самом деле, в среднем тратится больше). 4/26 — это даже не 20% выигрыша. Думаю что DDA оправдать будет проще, потому что табличное деление можно втиснуть примерно в 100-150 тактов, и это выиграет относительно стандартного подхода для (100-150)/4 ~ 25-40 точек, т.е. для достаточно длинных линий.
Конкретно в деталях, ты там явно расписал не только Брезенхема в 2 ветки, ты также расписал и что-то другое. Мне было лень разбираться в подробностях, но процедура рисования линий длиной более 16К — это просто даже уже не очень и смешно.
467/610/538; 774/1013/893; 1221/1609/1415
но средневзвешенное дб поменьше среднего, особенно для линий короче 9 точек
так как самый худший случай (и близкие) статистически довольно редки
также думаю поменять местами ветки на входе
не ускорит, так хоть сузит разброс немного
протестирую и выложу исходники после этого
Короче, интересная идея. Скорее всего я пущу её в ход. Но хочется большего. Хочется линию в 2 раза быстрее, например. Вот это будет заметно.
применять можно вместе с обсуждавшейся процедурой или отдельно
тогда примерно или +1кб и +10% скорости, или -6кб и -10% скорости
Что средневзвешенно на полтора+ такта быстрее чем pop:add и не использует стек (только временно его указатель), а потому может применяться и при рисовании с двух концов (для UP_HL код аналогичный, но с альтернативной парой вместо sp и второй таблицей). Прерывания тоже не страшны, если над (sp) немного места зарезервировать. В сам sp грузим константу #XX20, где XX зависит от адресов таблиц и экрана. Например, в sp можно поместить #E020 если с #C000 рисуем на двух экранах. Код короткий, для таблиц на каждый сегмент экрана нужно 256*2 байт (на последний сегмент можно только 256, если закольцовывать не хотим).
Для развёрнутых процедур DOWN_HL будет соответственно «inc h» или «add sp:ld h,(hl)»
Средневзвешенно минус три такта на ступеньку.
Вот и всё, я даже засомневался, что никто еще до этого не допёр. :D
Ну т.е. конечно в компактном случае повеселее, и сама возможность гнать сразу две точки…
Ммм..., это конечно далеко от того, где я думал, но тоже довольно сексуально выглядит.
сейчас тестирую альтернативный метод, позволяющий диагональ построить в цикле за ~8300 и к тому же перспективнее для коротких (правда, код опять разбухнет под 8кб)
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
Сам сейчас склоняюсь уже к тому, что избавляться выгодней от лишних проверок, а не коррекции. Вопрос только в сокращении размера, но с коротким down это попроще, даже с таблицей. И забавный парадокс еще возникает: при увеличении наклона время отрисовки линии сокращается))
Для set пока что получается всего перспективней пополам еще разбить сектора, тогда можно пользоваться тем, что сразу после ступеньки проверка не нужна, то есть, например, на косую zx-диагональ их будет нужно только 191, а ведь вместе с каждой выкинутой проверкой не только sub уходит, но и jp. Плюс удобно хвост дорисовывать без счётчика пикселей и без расстановки ловушек просто переходом на нужный адрес (правда, для самых пологих так не получится). И если не гнаться за рекордом, размер цикла такого сектора естественным образом сокращается почти вдвое, хоть и несколько замедляется.
Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.
Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.
К сожалению вот только ответы давать не все хотят/умеют/могут…
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
несмотря на то, что по не зависящим от них причинам меньше «могли»
«Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software». (выше я пояснял, что на самом деле биты можно было аранжировать иначе)
Я до сих пор ясно, чётко, внятно не услышал две вещи: 1. какие у тебя вопросы к дизайну Altwasser'а? 2. Что именно, что конкретно ты бы мог предложить? Может быть попробуешь сформулировать? А я попытаюсь тебя понять. Пока что мне удалось тебя понять так — основная твоя претензия в том что можно было бы сделать экран по-столбцам, а то неудобно писать программное обеспечение, код раздувается в объеме. Я верно тебя понял? Постарайся выразить мысль как можно полнее.
НЕУДОБНАЯ для кодера адресация. И нет, требование соответствовать особенностям элементной базы его НЕ оправдывает. Потому что можно было И сделать лучшую раскладку, И соответствовать.
Да куда полнее-то, непонятно. В том, что касается конкретно темы твоей статьи, я вполне конкретно предложил столбцовую раскладку — тебе что, мало? Кстати, код не только лишь раздувается, но и раздутый, всё еще проигрывает по скорости коду для столбцовой раскладки.
1. Опять сферические кони в ваккуме. :) «другая». Какая именно?
2. С выдумкой по ходу дела firmware/software это ты ловко. Подвела таксономия, firmware это часть software. И выдумывать не надо, о чем идет речь ясно 2мя предложениями выше.
Опять «лучшую». Хардварную конкретику, плз. :)
Конечно мало. В этом-то всё и дело, дьявол таится в мелочах, когда начинаешь разбирать. Просто предложение иметь столбцы — это лишь наши с тобой мечты с дивана, не более. Столбцы, для начала, должны иметь высоту обязательно 256 байт, иначе с другими столбцами затея теряет смысл.
Дальнейшие вопросы.
Что насчет цвета? А то этот вопрос у тебя остался за кадром, спектрум получился монохромный как «Специалист».
Какова геометрия экрана? Сколько столбцов? Какой получается суммарный объем?
Пытаясь понять не пропустил ли я у тебя какие-то подробности, увидел https://hype.retroscene.org/blog/889.html#comment23546
Как на 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нс.
А человеки это часть человечества. Это же не повод сказать начальнику, что повышения зарплаты требует человечество.
«Выше» относительно чего, где? Теперь ты давай конкретику, процитируй.
И в чём проблема? Значит, будет 256 байт. Что совсем не означает столько же пикселей.
Он остался у тебя, а не у меня, потому что ты в прошлый раз не соизволил пройти по ссылке:
hype.retroscene.org/blog/889.html#comment23547
где обсуждается, куда пихать атрибуты
Какая хочешь, при условии 256 байт на столбец.
Сколько влезет или меньше, сколько захочешь.
Кол-во столбцов * 256 байт
Кратность 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, но в данной схеме можно также регулировать их размер в связи с размером растра по вертикали)
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…
Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;
Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
Даааааа? С чего бы? Текст ты написал НЕ СЕБЕ, а выложил на общее обозрение. И потому ТВОЯ задача писать его так, чтоб не было нечёткостей и ошибок. Я считаю, что моё прочтение текста согласуется с логикой и правилами русского языка.
Снова нелады с русским? Раз ЛЮБОЙ, то в том числе и такой, для которого раскладка Спектрума НЕУДОБНА.
А теперь проблемы с логикой. Вот какая разница, КТО писал, если Я дал в качестве ОТВЕТА на твой вопрос. Или мне теперь и буквами не пользоваться, потому что их придумал кто-то другой?
Где? Какие важные вопросЫ (теперь еще во множественном числе)? Что ты понимаешь под ГЕОМЕТРИЕЙ? Видимо, не ширину и не высоту, потому что на вопросы о ширине и высоте я ОТВЕТИЛ — они могут быть практически какими угодно (лишь бы влезло в тв-стандарт и в 256 байтов на вертикаль)
СТОП! с чего доказывать вдруг надо именно ЭТО? Ни «8k», ни тем более «1/60сек» совершенно к делу отношения не имеют. Доказать нужно ТОЛЬКО то, что байт полоски пикселей и байт соответствующего ей атрибута можно прочитать в страничном режиме. А для этого достаточно совпадения любых 7 бит в 14-битных адресах этих двух байтов. Лично мне это очевидно.
Ёжкин кот жеж. Совпадающие (то есть СТАРШИЕ 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* равны)
Я тут пару сообщений назад все хотел тебе сказать:
в общепринятом смысле «байты» (октеты) в адресе видеоконтроллера,
выставляемого на DRAM отсутствуют,
поскольку ША видео-адреса, будучи представленной выводами счётчиков,
не пересекается с микропроцессорной ША, вот такая для тебя шокирующая новость.
Однако говорить о старшей и младшей части адреса можно.
14 бит, 2^14 = 16384.
У вас факапчик-с приключился с видеообластью объемом 16кб.
Тут еще один факапчик из-за банального незнания как регенерируется DRAM.
К сведению: tREF по даташиту MAX 2 ms. Бит h7 — половина высоты растра. Сколько это ms?
Сорян, придется всё переделать, чтобы заработало в реальности.
ну и к чему тогда пустая придирка выше? Чтобы только показать вумность?
Нет, здесь факапчик-с у тебя приключился. Ты не подумал, что 16k нужно было бы для всех теоретических 64 столбцов, но столько даже в тв-строку не влезает с квадратным пикселем. 32 столбца как на спеке — 8k. А хочешь 320 пикселей в ширину, как на всех нормальных компах обычно — 10k. И то, что эта схема НЕ ДИКТУЕТ единственно возможную ширину экрана, как у Альтвассера — жирный ПЛЮС.
Нет, еще один факапчик тут опять у тебя из-за привычки очень выборочно читать. К сведению: выше сказано, что могла усложниться схема регенерации. И дело даже не в h7, а в том, что не перебираются все столбцы. Переделывать ничего не требуется, а достаточно 1-2 «лишних» чтений на строку растра, что практически процессор не замедляло бы (но, возможно привело бы к удорожанию изделий на пару фунтов, если бы не влезло в юлу).
Я конечно видел много клоунады, но такую чтобы мой оппонент сначала что-то нарисовал или написал,
а потом, несмотря на четко нарисованные биты, заявил что я должен якобы представлять это не так (при том что написал/нарисовал — он всё вполне четко) — вот такую изворотливость я вижу впервые.
Поздравляю. Ведь если уменьшить количество столбцов, уменьшится количество бит (или диапазон пересчета) и будет происходить регенерация не всех строк DRAM.
Дело в том что у тебя нарушена регенерация памяти и железо не рабочее. Дело в этом.
И пустым птицебольством «выше сказано, что могла усложниться схема регенерации» — не отделаешься.
Дело за малым, жду от тебя столбцовую раскладку адресов, такую чтобы работало.
Приведи корректные биты адреса, идущие от контролера к DRAM 4116. Если это возможно в реальности, а не в диванных мечтах.
иииииишто? Кто сказал из религиозных авторитетов, что регенерация должна осуществляться именно чтением растра для отображения и никак иначе?
Дурачок? Если нет, то прекращай включать дурачка. Даже в спектруме есть огромный промежуток в регенерации в 152 строки развёртки, почти полкадра. То есть достаточно делать один лишний доступ во время hblank, последовательно перебирая RAS от 0 до 127 — промежуток даже меньше получится. Можно даже применить для этого штатный счётчик строк видеоузла (но тогда на один hblank могут понадобиться два доступа, если промежуток в 184 строки слишком долгий).
Всё рабочее. Заканчивай клоунаду. От тебя жду формулу «коэффициента извратности перестановок»
? Ты нарисовал 7-бит часть адреса DRAM идущую по сигналу строба RAS:
Если это 7 бит адреса, стробируемые RAS и передаваемые в микруху, то какие требования предъявляет микросхема 4116?
Почему ты считаешь что это «я» с тебя требую, а не DRAM 4116?
Ты до сих пор не понял, чем (а не кем) обусловлено такое требование?
Значит рисуй заново.
1. Нужно не писать чушь, что выше, а знать что 4116 в отсутствие ULA рефрешит Z80.
2. Не надо переходить тонкую грань между шутками и оскорблением.
В сухом остатке.
Предложенная тобой схема столбцов — не работает.
Или ты дизайнишь столбцовый access к 4116 хотя бы расписав в виде циклов и адресов. Или затея иметь столбцовый растр не состоятельна, провалилась при практической реализации.
Ч.Т.Д.
С чего «значит»? Ты совсем не можешь в логику, ни на бит?
Но ведь ты действительно, мягко говоря, неумён, если сам не понимаешь, что следует и что не следует из твоих же собственных слов и сечёшь себя хуже унтер-офицерской вдовы. Ну, рефрешит юла медленную память в спеке, И ЧТО ИЗ ЭТОГО? Вот с чего ты делаешь странный вывод, что в принципе рефрешить её может ТОЛЬКО юла? И притом еще ЕДИНСТВЕННЫМ способом, только чтением строго пикселей и атрибутов, ничего больше? Тогда как в нашей унылой реальности без летающих розовых слонов для рефреша нужен только доступ к каждому ряду с частотой не ниже оговоренной, и кто будет обеспечивать эти доступы — пдп, процессор, юла, волчок, диаболо, слинки или йо-йо — для микросхемы совершенно НЕ ВАЖНО.
В сухом остатке: ты тупишь, а схема вполне рабочая.
Я с тобой до этой поры не пересекался. Поэтому не знал что у тебя за натура, верил в лучшее.
Народ тут уже намекнул, что я опозорился самим этим фактом разговора с «летаргичкой».
Засим пока, позориться мне дальше вряд ли стоит.
https://www.youtube.com/watch?v=IA_evL-1F0w&t=33
Инженеры не пользуются подобной терминологией, в электронике сложно представлять «средние». Именно этот образ мышления, терминология и форма выражения мысли поначалу вводит в полный ступор.
Не удивительно, что я долгое время не мог ничего понять, у меня даже мысли не работают подобным извращенно-искривленным образом, чтобы я смог до такого додуматься. Смеялся я дооолго...
Ндаа… и эти люди раскритиковали Sinclair ZX Spectrum!
Объясняю, что тут такое придумано.
Lethargeek предлагает чтобы layout (адресация) была такой:
То есть, в центре столбцов — пиксели, а по краям столбца сверху и снизу атрибуты.
При этом лежащие ближе к центру столбца (по-вертикали) байты пикселей соответствуют атрибутам ближе краю (по-вертикали) экрана.
Т.е. в начале адресов #xx00..#xx0F лежат атрибуты, далее с адреса #xx10 до адреса #xxEF идут пиксели, затем по адресам #xxF0..#xxFF снова лежат атрибуты.
Адресация такова:
двигаешься по пикселям вверх, адрес атрибутов спускается вниз.
двигаешься вниз, адрес атрибутов идёт вверх.
Высота экрана 224 строки (#E0).
Lethargeek должен быть внесен в анналы спектрумистов как выдумщик
самого наибольшего hardware-извращения, какое только можно представить.
За сим нарекаю справедливо заслуженным титулом «хардварный Петросян». :)))))
Нет, у ТЕБЯ они работают таким образом, если ты извращённо-искривлённый спектрум считаешь лучше. Это же именно на спектруме приходится извращаться для такой простой операции, как сдвиг по вертикали экранного адреса. Да и для вычисления по координатам самого адреса.
Ты неправильно используешь слово «край». У закольцованной структуры нету краёв. У фрагментов же внутри такой структуры край считается по выходу за фрагмент.
Если что, я не претендую на единоличное авторство))
Это всё результат одного давнего коллегиального обсуждения.
Ладно, понимаю, со стороны софта у тебя мозги могли быть безнадёжно искривлённо-извращены многолетним программированием на спеке. Но вот с чего ты в hardware извращение усмотрел? Применяется ведь тот же самый приём, что в спектруме — перепутывание адресных линий. А теперь ВНИМАНИЕ, ВОПРОС: ПОЧЕМУ ОДНО ПЕРЕПУТЫВАНИЕ ТЫ СЧИТАЕШЬ ИЗВРАЩЁННЕЙ ДРУГОГО? Ведь у тебя наверняка есть какие-то СЕРЬЁЗНЫЕ основания (раз уж ты такой серьёзный Непетросян)) Напиши, пожалуйста, нам здесь серьёзную формулу для вычисления КОЭФФИЦИЕНТА ИЗВРАТНОСТИ по заданной комбинации 14 неповторяющихся номеров! :|
Закольцованный экран без края?
Ват зе… Прям слышно как трещит мой шаблон...
Я всё понял. Страшный ты человек, зря я с тобой связался...
Пацаны, бегите… :)))
Не паясничай. И ты еще смеешь обвинять меня в клоунаде…
график мой неточный, ломаной по нескольким точкам
поверх старых точных графиков топикстартера
и накинул щедро 500 тактов сверху на вход еще
по завершении должно получиться немного меньше
Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
Поможет — ZX Evolution (+TSConf), ZX Next, Reverse.
А также навеска FT812, v9990…
Приделать к оригинальному спектруму аппаратное ЧТО-ЛИБО ВООБЩЕ, это как к сельскому деревянному толчку приделать лцд экран с тачпадом для общения в соцсетях.
Формально — нужно переставить в адресе 2 группы по 3 бита, концептуально — такое бы в голову не пришло никому.
Алсо, для подобных «удобств» в свое время сделали аж целую команду z80 — DAA.
Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.
Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
Вот цитата из его интервью: «This was a bit of a breakthrough at the time. The key to it was some very efficient code for copying the 4K of active screen area (256x128) during the screen refresh. I had to draw each frame in a separate block of RAM (4K) and then copy it across to the graphics area when the machine had finished drawing that part of the screen to the CRT. So I wrote a routine treated the screen memory like a stack, using every register of the CPU (including the alternates), pushing and popping 16 bytes at a time.»
а) рисует линию от начала до конца (а не легко гуглящийся fast divide & conquer)
б) не использует глобальных переменных кроме констант типа предрассчитанных таблиц
в) на самом деле то же самое что и (б) — не использует самомодификацию кода
г) способен писать как 0 так и 1 так и инверсию
д) легко скопипастить в другую программу
Суперскорость не особо нужна, думал легко найду, но ни на русском ни на английском гугл как ни мучаю — ничего подходящего не вижу…