Я сейчас не помню кто первым изобрёл копирование буфера в экран стеком. Но точно помню что это было раньше, что-то типа 1985 или 1986; думаю к 1989, которых не клали в экран стеком, просто уже увольняли по профнепригодности :)
Лёш, про стек наверное в 89 так же говорили) Команды PUSH и POP нужны для того, чтобы сохранять и восстанавливать значения! Не надо придумывать для них странное применение, зачем помещать стек в экранную область? ЕРЕСЬ СЖЕЧ!
@tsl, походу в этом треде жгут вообще поголовно все!
Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.
Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
Поскольку атрибуты лежат в одном столбце с пикселями, то старший байт адреса один, то есть совпадают уже 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?
Сорян, придется всё переделать, чтобы заработало в реальности.
P.S.
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе.
Что здесь странного, если в тексте семантические ошибки и альтернативный русский язык? Даже раз, небось, прочесть поленился, отсюда перлы типа 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 бит (то есть все, кроме двух старших и неучитываемых) и в младшем байте адреса совпадёт еще один (старший) бит. Ну, на в цифрах, если ты по-русски не понимаешь:
c — столбцы экрана, инкремент слева направо
v — вертикаль пикселей, инкремент сверху вниз
^ — вертикаль атрибутов, инкремент снизу вверх
h — верхняя или нижняя половина (все биты h* равны)
Дорогой Lethargeek.
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…
Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;
Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
1. Опять сферические кони в ваккуме. :) «другая». Какая именно?
ZOMG, мне что, столбцы в каждом предложении поминать?
2. С выдумкой по ходу дела firmware/software это ты ловко. Подвела таксономия, firmware это часть software.
А человеки это часть человечества. Это же не повод сказать начальнику, что повышения зарплаты требует человечество.
И выдумывать не надо, о чем идет речь ясно 2мя предложениями выше.
«Выше» относительно чего, где? Теперь ты давай конкретику, процитируй.
Конечно мало. В этом-то всё и дело, дьявол таится в мелочах, когда начинаешь разбирать. Просто предложение иметь столбцы — это лишь наши с тобой мечты с дивана, не более. Столбцы, для начала, должны иметь высоту обязательно 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, но в данной схеме можно также регулировать их размер в связи с размером растра по вертикали)
Литературно текст прекрасен, впечатлило, благодарю.
Однако я останусь при своем мнении по массе причин.
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нс.
Я специально выбрал такой пример, чтоб подчеркнуть не сложность фичи, а то, что авторы думали настолько «на отъебись», что ни за что не сделали бы ничего подобного.
Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.
Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
Инженеры не пользуются подобной терминологией, в электронике сложно представлять «средние». Именно этот образ мышления, терминология и форма выражения мысли поначалу вводит в полный ступор.
Не удивительно, что я долгое время не мог ничего понять, у меня даже мысли не работают подобным извращенно-искривленным образом, чтобы я смог до такого додуматься. Смеялся я дооолго...
Ндаа… и эти люди раскритиковали 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?
Сорян, придется всё переделать, чтобы заработало в реальности.
Глянул документацию по SjASMPlus — и интуиция не подвела. Там есть для этих оптимизационных целей ключевое слово IFUSED. Прикольно, прикольно…
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
Даааааа? С чего бы? Текст ты написал НЕ СЕБЕ, а выложил на общее обозрение. И потому ТВОЯ задача писать его так, чтоб не было нечёткостей и ошибок. Я считаю, что моё прочтение текста согласуется с логикой и правилами русского языка.
Снова нелады с русским? Раз ЛЮБОЙ, то в том числе и такой, для которого раскладка Спектрума НЕУДОБНА.
А теперь проблемы с логикой. Вот какая разница, КТО писал, если Я дал в качестве ОТВЕТА на твой вопрос. Или мне теперь и буквами не пользоваться, потому что их придумал кто-то другой?
Где? Какие важные вопросЫ (теперь еще во множественном числе)? Что ты понимаешь под ГЕОМЕТРИЕЙ? Видимо, не ширину и не высоту, потому что на вопросы о ширине и высоте я ОТВЕТИЛ — они могут быть практически какими угодно (лишь бы влезло в тв-стандарт и в 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* равны)
У меня к тебе предложение, перестать заниматься странным делом, пытаясь доказать мне что мой тест должен читаться как-то иначе. Текст написал я, и его смысл лучше всего известен мне. Его не я должен понимать так, как понимаешь ты, а наоборот — твоя задача — понять его так, как понимаю его я, не вводя лишних сущностей и не доказывая их мне. Уточняю, чтобы тебе было более понятно — под «software» имеется в виду обобщенно любой «программный доступ», отличие от hardware. В т.ч. из BASIC ROM.
Ты второй раз даёшь мне ссылку на чужой пост со словами «а вот тут вот было», ты, дескать, просто не заметил. Но Weiv и Lethargeek, надеюсь, разные люди? И даже если Weiv полагает нечто так, то ты можешь думать иначе. Какое мне дело до чужих постов? Для меня невозможно знать заранее, что Weiv и ты думаете одинаково. Не надо заниматься такими вещами.
Снова проигнорированы важные вопросы о геометрии экрана.
Между тем, инорировать их нельзя, поскольку надо доказать, что удастся опрашивать 8K «столбцами» вместе с цветом каждые 1/60сек для микросхем 4116 самой медленной отбраковки, т.е. самых дешевых. Это и есть именно то, из-за чего я веду с тобой эту беседу, но давай посмотрим дальше. А вдруг я где-то ошибаюсь…
Теперь о хорошем. Наконец-то я услышал и увидел от тебя конкретику. Благодарю, это интересно!
Я пока не согласен с утверждением для page mode, но это выяснится далее. Мне не удалось понять твою схему адресации, возникли вопросы. Прошу пойти мне навстречу и по-циклам описать примерно так, как я описал в заметке;
Вот у нас есть 14 бит адреса микросхем 4116, мультиплексированные по 7 и 7 бит. Опиши (напиши биты) по-циклам, как дисплейный контроллер стробируя сигналами RAS и CAS передает по 7 бит экранный адрес так, чтобы получить такую развёртку пикселей и цвета, как придумал ты. Укажи, какие биты адреса в каком цикле там совпадают. Только делай это не словесно, а выписав в каждом цикле проименованные и пронумерованные биты, иначе я снова ничего не пойму.
А человеки это часть человечества. Это же не повод сказать начальнику, что повышения зарплаты требует человечество.
«Выше» относительно чего, где? Теперь ты давай конкретику, процитируй.
И в чём проблема? Значит, будет 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, но в данной схеме можно также регулировать их размер в связи с размером растра по вертикали)
Однако я останусь при своем мнении по массе причин.
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нс.