Клоунадой ты сейчас занимаешься. И нарисовано, и сказано было чётко: «c — столбцы». А то, что в этих битах непременно должны перебраться все комбинации — исключительно твои личные сексуальные фантазии. Я же ничего такого не утверждал.
? Ты нарисовал 7-бит часть адреса DRAM идущую по сигналу строба RAS:
Если это 7 бит адреса, стробируемые RAS и передаваемые в микруху, то какие требования предъявляет микросхема 4116?
Почему ты считаешь что это «я» с тебя требую, а не DRAM 4116?
Ты до сих пор не понял, чем (а не кем) обусловлено такое требование?
иииииишто? Кто сказал из религиозных авторитетов, что регенерация должна осуществляться именно чтением растра для отображения и никак иначе?
Значит рисуй заново.
Дурачок? Если нет, то прекращай включать дурачка. Даже в спектруме есть огромный промежуток в регенерации в 152 строки развёртки, почти полкадра. То есть достаточно делать один лишний доступ во время hblank, последовательно перебирая RAS от 0 до 127 — промежуток даже меньше получится. Можно даже применить для этого штатный счётчик строк видеоузла (но тогда на один hblank могут понадобиться два доступа, если промежуток в 184 строки слишком долгий).
1. Нужно не писать чушь, что выше, а знать что 4116 в отсутствие ULA рефрешит Z80.
2. Не надо переходить тонкую грань между шутками и оскорблением.
В сухом остатке.
Предложенная тобой схема столбцов — не работает.
Или ты дизайнишь столбцовый access к 4116 хотя бы расписав в виде циклов и адресов. Или затея иметь столбцовый растр не состоятельна, провалилась при практической реализации.
Ч.Т.Д.
Ты неправильно используешь слово «край». У закольцованной структуры нету краёв. У фрагментов же внутри такой структуры край считается по выходу за фрагмент.
Закольцованный экран без края?
Ват зе… Прям слышно как трещит мой шаблон...
Я всё понял. Страшный ты человек, зря я с тобой связался...
Пацаны, бегите… :)))
Lethargeek ПОЧЕМУ ОДНО ПЕРЕПУТЫВАНИЕ ТЫ СЧИТАЕШЬ ИЗВРАЩЁННЕЙ ДРУГОГО?
Ведь у тебя наверняка есть какие-то СЕРЬЁЗНЫЕ основания (раз уж ты такой серьёзный Непетросян))
Напиши, пожалуйста, нам здесь серьёзную формулу для вычисления
КОЭФФИЦИЕНТА ИЗВРАТНОСТИ по заданной комбинации 14 неповторяющихся номеров!
А мне абсолютно норм! Вышел tsl, крикнул первую попавшуюся команду, и ушел в туман. Чего еще? Самое то, всё по закону жанра. По идее, он может еще где-то из-за кулис крикнуть: «прерывание вам всем в кернель!» После этого стреляет пушка и появляется VBI :)))
Нет, здесь факапчик-с у тебя приключился. Ты не подумал, что..
Я конечно видел много клоунады, но такую чтобы мой оппонент сначала что-то нарисовал или написал,
а потом, несмотря на четко нарисованные биты, заявил что я должен якобы представлять это не так (при том что написал/нарисовал — он всё вполне четко) — вот такую изворотливость я вижу впервые.
Поздравляю. Ведь если уменьшить количество столбцов, уменьшится количество бит (или диапазон пересчета) и будет происходить регенерация не всех строк DRAM.
И дело даже не в h7
Дело в том что у тебя нарушена регенерация памяти и железо не рабочее. Дело в этом.
И пустым птицебольством «выше сказано, что могла усложниться схема регенерации» — не отделаешься.
Дело за малым, жду от тебя столбцовую раскладку адресов, такую чтобы работало.
Приведи корректные биты адреса, идущие от контролера к DRAM 4116. Если это возможно в реальности, а не в диванных мечтах.
Поскольку атрибуты лежат в одном столбце с пикселями, то старший байт адреса один, то есть совпадают уже 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-извращения, какое только можно представить.
За сим нарекаю справедливо заслуженным титулом «хардварный Петросян». :)))))
О байтах и «русском языке».
Я тут пару сообщений назад все хотел тебе сказать:
в общепринятом смысле «байты» (октеты) в адресе видеоконтроллера,
выставляемого на DRAM отсутствуют,
поскольку ША видео-адреса, будучи представленной выводами счётчиков,
не пересекается с микропроцессорной ША, вот такая для тебя шокирующая новость.
Однако говорить о старшей и младшей части адреса можно.
14 бит, 2^14 = 16384.
У вас факапчик-с приключился с видеообластью объемом 16кб.
RAS: c13, с12, с11, с10, с9, с8,h7
Тут еще один факапчик из-за банального незнания как регенерируется DRAM.
К сведению: tREF по даташиту MAX 2 ms. Бит h7 — половина высоты растра. Сколько это ms?
Сорян, придется всё переделать, чтобы заработало в реальности.
Дорогой Lethargeek.
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…
Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;
Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
Литературно текст прекрасен, впечатлило, благодарю.
Однако я останусь при своем мнении по массе причин.
1. Дискуссия заведомо обречена, потому что в обсуждении будут появляться, в основном те, кто спешит заявить что он никогда не изучал чужой код. Обратное писать не спешат. :)
2. Никакой разумной причины скрывать хакинг нет. Более того, пытаясь сочинить для instrospec запрошенную статью, я напрямик советую смотреть как организован чужой код. Я абсолютно не сомневаюсь в том что сильные «кодеры», прежде всего сильные хакеры. Раньше как-то и не принято было ничего скрывать, хакерство было частью сцены и если не очевидным, то особо не скрывалось. (Пример — девушка из Lyra, сэмплы, картинки, музыка...).
3. Идея о том что не требуется смотреть/знать реализацию эффектов совершенно несостоятельна. Тривиальные вещи, такие как разнообразные скроллинги (мнущиеся, кривые, косые, с разными скоростями и зумом), атрибутную анимацию, спрайты итд смотреть нечего. Но дело в том что существуют advanced эффекты, для которых не зная know-how ты их не реализуешь, сколько ты не смотри. Просмотр знания не заменит. Сходу вспоминается water, rotozoom, bump mapping, fake phong mapping, texture mapping или там kefrens dots (я забыл реальное название, но однажды с introspec'ом обсуждали эффект из Insult — это всё он же). В некоторых случаях требуется знать не математику/алгоритм, а организационно-алгоримтический трюк (грубо говоря, «почему это прокатывает»).
4. Сходство некоторых эффектов на Amiga заметно глазами. Я выше применил достаточно грубый термин «драть», «выдирать» итд. Обычно он соответствует прямому копированию. Нет, я это в виду не имел. Реально достаточно только глянуть одним глазком ;), чтобы узнать как это работает, чтобы затем реализовать в коде нечто подобное.
5. Я не думаю что все всё и всегда смотрят. Многие сложные вещи приятнее сделать быстрыми самому.
Ё-моё. Ну вот с этими словами и не согласен я. С тем, ИМЕННО ТАКАЯ «аранжировка бит» была якобы «задана требованиями software». Потому что в тот момент никакого software не было, был (или планировался) firmware, по приказу руководства который драли, где возможно, с прошлой модели. А вот как раз для будущего software ИМЕННО ТАКАЯ «аранжировка» совсем НЕ требовалась, а лучше подошла бы совсем другая.
1. Опять сферические кони в ваккуме. :) «другая». Какая именно?
2. С выдумкой по ходу дела firmware/software это ты ловко. Подвела таксономия, firmware это часть software. И выдумывать не надо, о чем идет речь ясно 2мя предложениями выше.
НЕУДОБНАЯ для кодера адресация. И нет, требование соответствовать особенностям элементной базы его НЕ оправдывает. Потому что можно было И сделать лучшую раскладку, И соответствовать.
Опять «лучшую». Хардварную конкретику, плз. :)
Да куда полнее-то, непонятно. В том, что касается конкретно темы твоей статьи, я вполне конкретно предложил столбцовую раскладку — тебе что, мало?
Конечно мало. В этом-то всё и дело, дьявол таится в мелочах, когда начинаешь разбирать. Просто предложение иметь столбцы — это лишь наши с тобой мечты с дивана, не более. Столбцы, для начала, должны иметь высоту обязательно 256 байт, иначе с другими столбцами затея теряет смысл.
Дальнейшие вопросы.
Что насчет цвета? А то этот вопрос у тебя остался за кадром, спектрум получился монохромный как «Специалист».
Какова геометрия экрана? Сколько столбцов? Какой получается суммарный объем?
Пытаясь понять не пропустил ли я у тебя какие-то подробности, увидел https://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нс.
я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management)
Слова у меня в статье следующие:
«Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software». (выше я пояснял, что на самом деле биты можно было аранжировать иначе)
и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)
Я до сих пор ясно, чётко, внятно не услышал две вещи: 1. какие у тебя вопросы к дизайну Altwasser'а? 2. Что именно, что конкретно ты бы мог предложить? Может быть попробуешь сформулировать? А я попытаюсь тебя понять. Пока что мне удалось тебя понять так — основная твоя претензия в том что можно было бы сделать экран по-столбцам, а то неудобно писать программное обеспечение, код раздувается в объеме. Я верно тебя понял? Постарайся выразить мысль как можно полнее.
С Exploder'ом (Алексей Вересов) я был знаком примерно в ~2006? 7? (много общались удаленно). Мне он показался весьма неплохим человеком. А «бравада» — просто по молодости, может быть в то время ему реально казались крутыми те результаты (по оптимизации), которых он добился.
Хотелось бы его найти, пообщаться. Если у кого есть зацепки — дайте знать. :)
Я абсолютно 100% уверен что «драли». Гхм, собственно, в некоторых случаях нужно говорить — конверсия эффекта на ZX Spectum, настолько они узнаваемы в некоторых Amiga-интро, когда сейчас смотришь.
А то как ты говоришь — этим занимался, как раз, ваш покорный слуга :))) (скрежеща зубами :) потому что ни PC, ни Amiga у меня не было). Почему я 100% уверен что драли? Ассемблерный код, разумеется, не перенесешь, но переносили нетривиальную основу (задумку) и математику эффекта.
А в некоторых эффектах и задумка и внутренняя реализация совпадает на 100% с оригиналом. Касаемо Codebusters/RST7 — какие там могут быть сомнения что «драли», если используется выдранный с Amiga/MSX контент… Первое же что вспоминается, кораблик из заставки MSX-игры Gradius(Nemesis) или туннель из Amiga Stardust.
Ну а касаемо Лёхи Exploder'а, не будем забывать что он несколько раз брал призы на Assembly в амижных демках…
(Я хоть и отвечаю на твое сообщение, но на самом деле это «реплика в сторону»).
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…
? Ты нарисовал 7-бит часть адреса DRAM идущую по сигналу строба RAS:
Если это 7 бит адреса, стробируемые RAS и передаваемые в микруху, то какие требования предъявляет микросхема 4116?
Почему ты считаешь что это «я» с тебя требую, а не DRAM 4116?
Ты до сих пор не понял, чем (а не кем) обусловлено такое требование?
Значит рисуй заново.
1. Нужно не писать чушь, что выше, а знать что 4116 в отсутствие ULA рефрешит Z80.
2. Не надо переходить тонкую грань между шутками и оскорблением.
В сухом остатке.
Предложенная тобой схема столбцов — не работает.
Или ты дизайнишь столбцовый access к 4116 хотя бы расписав в виде циклов и адресов. Или затея иметь столбцовый растр не состоятельна, провалилась при практической реализации.
Ч.Т.Д.
Закольцованный экран без края?
Ват зе… Прям слышно как трещит мой шаблон...
Я всё понял. Страшный ты человек, зря я с тобой связался...
Пацаны, бегите… :)))
Я конечно видел много клоунады, но такую чтобы мой оппонент сначала что-то нарисовал или написал,
а потом, несмотря на четко нарисованные биты, заявил что я должен якобы представлять это не так (при том что написал/нарисовал — он всё вполне четко) — вот такую изворотливость я вижу впервые.
Поздравляю. Ведь если уменьшить количество столбцов, уменьшится количество бит (или диапазон пересчета) и будет происходить регенерация не всех строк DRAM.
Дело в том что у тебя нарушена регенерация памяти и железо не рабочее. Дело в этом.
И пустым птицебольством «выше сказано, что могла усложниться схема регенерации» — не отделаешься.
Дело за малым, жду от тебя столбцовую раскладку адресов, такую чтобы работало.
Приведи корректные биты адреса, идущие от контролера к DRAM 4116. Если это возможно в реальности, а не в диванных мечтах.
Инженеры не пользуются подобной терминологией, в электронике сложно представлять «средние». Именно этот образ мышления, терминология и форма выражения мысли поначалу вводит в полный ступор.
Не удивительно, что я долгое время не мог ничего понять, у меня даже мысли не работают подобным извращенно-искривленным образом, чтобы я смог до такого додуматься. Смеялся я дооолго...
Ндаа… и эти люди раскритиковали Sinclair ZX Spectrum!
Объясняю, что тут такое придумано.
Lethargeek предлагает чтобы layout (адресация) была такой:
То есть, в центре столбцов — пиксели, а по краям столбца сверху и снизу атрибуты.
При этом лежащие ближе к центру столбца (по-вертикали) байты пикселей соответствуют атрибутам ближе краю (по-вертикали) экрана.
Т.е. в начале адресов #xx00..#xx0F лежат атрибуты, далее с адреса #xx10 до адреса #xxEF идут пиксели, затем по адресам #xxF0..#xxFF снова лежат атрибуты.
Адресация такова:
двигаешься по пикселям вверх, адрес атрибутов спускается вниз.
двигаешься вниз, адрес атрибутов идёт вверх.
Высота экрана 224 строки (#E0).
Lethargeek должен быть внесен в анналы спектрумистов как выдумщик
самого наибольшего hardware-извращения, какое только можно представить.
За сим нарекаю справедливо заслуженным титулом «хардварный Петросян». :)))))
Я тут пару сообщений назад все хотел тебе сказать:
в общепринятом смысле «байты» (октеты) в адресе видеоконтроллера,
выставляемого на DRAM отсутствуют,
поскольку ША видео-адреса, будучи представленной выводами счётчиков,
не пересекается с микропроцессорной ША, вот такая для тебя шокирующая новость.
Однако говорить о старшей и младшей части адреса можно.
14 бит, 2^14 = 16384.
У вас факапчик-с приключился с видеообластью объемом 16кб.
Тут еще один факапчик из-за банального незнания как регенерируется DRAM.
К сведению: tREF по даташиту MAX 2 ms. Бит h7 — половина высоты растра. Сколько это ms?
Сорян, придется всё переделать, чтобы заработало в реальности.
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…
Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;
Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
Однако я останусь при своем мнении по массе причин.
1. Дискуссия заведомо обречена, потому что в обсуждении будут появляться, в основном те, кто спешит заявить что он никогда не изучал чужой код. Обратное писать не спешат. :)
2. Никакой разумной причины скрывать хакинг нет. Более того, пытаясь сочинить для instrospec запрошенную статью, я напрямик советую смотреть как организован чужой код. Я абсолютно не сомневаюсь в том что сильные «кодеры», прежде всего сильные хакеры. Раньше как-то и не принято было ничего скрывать, хакерство было частью сцены и если не очевидным, то особо не скрывалось. (Пример — девушка из Lyra, сэмплы, картинки, музыка...).
3. Идея о том что не требуется смотреть/знать реализацию эффектов совершенно несостоятельна. Тривиальные вещи, такие как разнообразные скроллинги (мнущиеся, кривые, косые, с разными скоростями и зумом), атрибутную анимацию, спрайты итд смотреть нечего. Но дело в том что существуют advanced эффекты, для которых не зная know-how ты их не реализуешь, сколько ты не смотри. Просмотр знания не заменит. Сходу вспоминается water, rotozoom, bump mapping, fake phong mapping, texture mapping или там kefrens dots (я забыл реальное название, но однажды с introspec'ом обсуждали эффект из Insult — это всё он же). В некоторых случаях требуется знать не математику/алгоритм, а организационно-алгоримтический трюк (грубо говоря, «почему это прокатывает»).
4. Сходство некоторых эффектов на Amiga заметно глазами. Я выше применил достаточно грубый термин «драть», «выдирать» итд. Обычно он соответствует прямому копированию. Нет, я это в виду не имел. Реально достаточно только глянуть одним глазком ;), чтобы узнать как это работает, чтобы затем реализовать в коде нечто подобное.
5. Я не думаю что все всё и всегда смотрят. Многие сложные вещи приятнее сделать быстрыми самому.
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нс.
«Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software». (выше я пояснял, что на самом деле биты можно было аранжировать иначе)
Я до сих пор ясно, чётко, внятно не услышал две вещи: 1. какие у тебя вопросы к дизайну Altwasser'а? 2. Что именно, что конкретно ты бы мог предложить? Может быть попробуешь сформулировать? А я попытаюсь тебя понять. Пока что мне удалось тебя понять так — основная твоя претензия в том что можно было бы сделать экран по-столбцам, а то неудобно писать программное обеспечение, код раздувается в объеме. Я верно тебя понял? Постарайся выразить мысль как можно полнее.
Хотелось бы его найти, пообщаться. Если у кого есть зацепки — дайте знать. :)
А то как ты говоришь — этим занимался, как раз, ваш покорный слуга :))) (скрежеща зубами :) потому что ни PC, ни Amiga у меня не было). Почему я 100% уверен что драли? Ассемблерный код, разумеется, не перенесешь, но переносили нетривиальную основу (задумку) и математику эффекта.
А в некоторых эффектах и задумка и внутренняя реализация совпадает на 100% с оригиналом. Касаемо Codebusters/RST7 — какие там могут быть сомнения что «драли», если используется выдранный с Amiga/MSX контент… Первое же что вспоминается, кораблик из заставки MSX-игры Gradius(Nemesis) или туннель из Amiga Stardust.
Ну а касаемо Лёхи Exploder'а, не будем забывать что он несколько раз брал призы на Assembly в амижных демках…
Поможет — ZX Evolution (+TSConf), ZX Next, Reverse.
А также навеска FT812, v9990…
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…