Лучше приводить конкретные цитаты, выдержки из текста.
Желательно привести «точные координаты» утверждений, как я просил. Страницу (по нумерации источника), абзац, текст. Связано это с тем что я не могу вычитывать все документы в поиске утверждаемого, весьма лимитировано время...
Слово «физически» тобой правильно понято? Повторюсь.
И нужно еще помнить, что 50-е и 60-е термином «регистры» в принципе могли называть ячейки RAM, так, например называются ячейки памяти на ферритовых сердечниках в документации IBM-704 и поэтому вероятно в те годы ни у кого в принципе не вызывало претензий к терминологии
По моему мнению, ячейки памяти (в смысле ячейки ОЗУ) по смыслу не считались регистрами (в смысле регистрами процессора). В тексте применен термин «registers», означающий по смыслу также «ячейки памяти», «записи». Чего ты, видимо, не знал, не понял и не учел.
Второй мой тезис такой — в генеральном смысле регистр (в смысле регистр процессора) является ячейкой памяти (но не ОЗУ) и это действительно, может утверждаться в общем смысле.
Я тебе это пояснил, на что ты мне снова выдаёшь:
Вопрос когда чётко стали отличать память от регистров и по каким причинам, ведь видно что IBM в документации по IBM-704 от 1955 года использовала не в современном устоявшемся смысле.
Подозреваю что с пониманием текста про UNIVAC1 у тебя происходит то же самое. Уточни страницу по внутренней нумерации, абзац, текст. Гляну. А главное, еще раз выскажи свои тезисы, что ты утверждаешь/не утверждаешь, хочешь понять.
где прям проговаривается, что регистры это такие же ячейки как ячейки памяти, но их мало, они в тельняшках и быстро работают.
Регистры это вид памяти, ячейки памяти, да. Как иначе? Возникает ощущение, что у тебя трудности с базовой терминологией, не понимая общих (обобщенных) терминов ты полагаешь что это ФИЗИЧЕСКИ одни и те же вещи.
Вопрос когда чётко стали отличать память от регистров и по каким причинам
Слово register в английском имеет также смысл «запись». Всмысле то, что обычно называется «record». Поэтому, либо это не те «регистры», либо же термин register означал (а может и означает?) в редких случаях по смыслу «ячейка памяти».
Вообще (отступая в сторону) я в таких случая проверяю у англоговорящих исходный смысл термина по сайту etymonline.com. Учитывая что есть слова registrant, registry, registration — для англоговорящих это слово, по видимому, несет устойчивый смысл «запись», «нечто записанное». В смысле записи какого-то списка, нечто записанное на бумаге или внесённое. Поэтому регистры в самом общем смысле «записи» или ячейки (памяти)...
Но. Несмотря на это в каждой области существует устойчивый набор терминов и устоявшееся значение. Так что не стоит обобщать без явной на то необходимости. Напротив, стоит разделять понятия.
Интересный нюанс. На той же страница 6, конец параграфа вверху читаем о Core Memory: «Information is not retained when the power is off». Вообще, память на маг.серд. хранит информацию постоянно, до считывания, а у них на это не рассчитано.
Хотя я бы лично не согласился с тем, что регистры адресуемые через ISAR нельзя называть ОЗУ.
Вопрос тонкий из-за слишком широкого смысла термина «ОЗУ». Fairchild F8 содержит 64 байта scratchpad (сверх-оперативная память, сверх-оперативное ЗУ, СОЗУ). В документации данная память не только называется регистрами (scratchpad registers) но и имеет регистровую адресацию первых ячеек. С точки зрения документации и программиста F8 scratchad и RAM — различные понятия.
И нужно еще помнить, что 50-е и 60-е термином «регистры» в принципе могли называть ячейки RAM, так, например называются ячейки памяти на ферритовых сердечниках в документации IBM-704
Где я могу об этом прочесть? Можно URL на документацию? Страницу, конкретное место текста?
и поэтому вероятно в те годы ни у кого в принципе не вызывало претензий к терминологии даже если в документации к F8 что-то вот эдакое называется регистрами. Это уже потом понятия как то сильно разошлись и стали чуть ли не противопоставляться.
Это неверно. Внешняя память технологически появилась позже регистровой, но интерес представляет история термина «регистр». Помимо прямого смыслового значения: записывать, отмечать, вносить (т.е. регистрировать) дело тут может оказаться поинтереснее! Гипотезы такие. 1. «регистром» называется электронная схема, триггер. 2. Регистр это кассовый аппарат, втч счетный (букв. — счетчик). 3. Блок механического калькулятора/счетчика называется «регистром». 4. Регистры ЭВМ зачастую предоставляли оператору возможность механически вносить данные. Склоняюсь к прямому смысловому значению, но как оно исторически пока информации нет.
Прочитал всё что ты написал, написанное очень осмысленно.
Мои мысли пока такие. Думаю что надо стремиться к тому что выбирать пакер не просто так, имея накопленные знания, а иметь практически легко доступный «интерфейс» компрессоров (а может и декомпрессоров) с тем чтобы пробовать их практически и сразу сравнить. Потому что знание это хорошо, но компрессия, штука порой непредсказуемая. Сжимаемые данные внезапно могут оказаться с какой-то совсем неожиданной спецификой, так что практика может оказаться далеко от ожидаемого, как в ту, так и в иную сторону.
Также надо исследовать пакеры на _наборах_ специфичных данных, например на спрайтах и тексте (или как насчет того чтобы паковать стрим регистров AY? :))) ). Ориентация на скорость/сжатие хорошо, но для игроделов требования более интересные. Основное добавочное требование игровых схем упаковки — это возможность распаковывать произвольные фрагменты упакованных данных, а не всё сразу и не потоково.
И еще до кучи, что-то там интересное творится в H.A.T.E. не помню, что именно, я её глубоко не копал, по-моему дизассеблировал всего один раз, но там спрайты не просто по and-or, а сделаны «врезкой» битов: xor-and-xor или xor-or-xor…
Просто для информации.
Pape писал в книге что он оптимизировал код. Это очень свообразная оптимизация. Даже тот фрагмент что в книжке — без бутылки не разобраться.
Stalker (автор STS) в те годы пытался активно дизассемблировать именно R-Type. Как видно, не особо что вышло…
Чтобы два раза не вставать, из интересного в играх.
Savage (I) — рисует спрайты с создаваемой на лету «автомаской». «Автомаска» это биты графики спрайта, сдвинутые влево, сдвинутые вправо, наложенные по OR и инвертированные.
Т.е. из 00010000 сделает 00111000 и в итоге маска 11000111.
Примерно так же, как делается утолщеннный фонт. Но он это делает, естественно, по таблице. Хотя, припоминая дела 26-летней давности, я пробовал сранивать свою таблицу полученную описанным способом и она во многих местах не совпадала с имеющейся таблицей. Поэтому толи они вручную подредактировали таблицу (что может быть) толи сделали таблицу масок байтов вообще полностью вручную.
Dark Fusion делает 5 спрайтов бэкграунда (сдвинутых на 2pix), обеспечивая спрайты с пустым байтом-«концевиком» спереди и сзади, которым она и затирает фоновую графику при скроллинге. То есть графика шириной 3 байта имеет след. модификации:
00000000 11111111 11111111 11111111
00000011111111 11111111 11111111 00
000011111111 11111111 11111111 0000
0011111111 11111111 11111111 000000
11111111 11111111 11111111 00000000
Xecutor — определяет столкновения, читая собственную графику кораблика с экрана после того как выведет всех enemy-«тварюшек».
Jack The Nippper II не ждет int (как и подавляющее число игрушек) и использует технику как я её назвал «микробуфферинга», т.е. глобального бэкбуфера нет, локально бэкбуферится только то, что в данный момент накладывается друг на друга.
Из интересного не в играх — Shock последняя часть, с белыми «кувыркающимися» буквами SHOCK и звёздами — ВСЁ рисует ДО луча, то есть отрисовывает всё за верхний border. И вообще, интересный факт из всех демок E.S.I. А в курсе ли вы, что _ВСЕ_ они идут на 48к компьютере? Интересно, почему и зачем это. AY чип в оригинальном спектруме был только на 128к модели. Но графика вся выводится в 48к режиме, используя «гонки с лучом», и не просто графика, не используется память, все демки работают в 48к.
Из интересного. Когда-то очень давно, когда я увидел Lyra, я считал что демки _принципиально_ должны быть сделаны именно так, т.е. строго под 48к модель, несмотря на то что есть doublebuffered 128к экран. И использование doublebuffering'а мы считали «ламерством». Правда, жизнь расставила свои приоритеты, пока я усердно в поте лица устраивал гонки с лучом (например, сортируя спрайты), подъехала CB Satisfaction, где невозмутимо используется два экрана… =)
Насчет гонок с лучом. Гуглим книжку «RACING THE BEAM».
Вопрос именно в том как получается всё плавно но за 2 инта и без разрывов.
Любая программа, привязанная к int'у и перерисовывающая всё за 1/25sec (2*int) работает достаточно плавно.
«Разрывы» — это tearing графики? Zynaps все же синхронизируется с int'ом.
Tearing в Zynaps ещё как есть, просто он очень специфичный, надо знать, как он выглядит: время 3:52 и внимательно-внимательно смотрим далее. А столь специфичен он потому что они намеренно делают следующее. Они не обрабатывают «bulk» (т.е. широкую площадь) до и после луча (в месте потенциального сечения). Tearing будет заметен глазом когда МНОГО графики было ДО луча и МНОГО графики будет ПОСЛЕ луча, таким образом делая полосу «сечения» лучом хорошо заметной (МНОГОЕ сдвинуто до (выше луча) и МНОГОЕ (ниже луча) еще не сдвинуто). Вместо этого они обрабатывают по знакоместам (в некотором смысле симулируя столбцовый экран, бггг, вижу тут Lethargeek'а). Когда графика перерисовывается по знакоместам, проблема tearing'а случится только в нескольких «неудачных» знакоместах, попавших «под луч». Вдобавок, как я полагаю (не уверен на 100%), они используют трюк, начиная подвижную графику обновлять в рандомном порядке, таким образом делая «несчастливыми» знакоместами каждый раз разные. Это гораздо менее заметно для глаза.
Дичь с Zynaps совсем в другом. Насколько это мне известно с 90х, он рисует инверсную графику, накладывая её по AND и затирает атрибутами :))
— это изображение с paper black и white ink, т.е. в атрибутах байт 07.
Вопрос до конца не понятен. Почему за 2int'а? Потому что за 1 int (1/50sec, 50fps) не успевает. Не хватает производительности CPU. Если на реальном «железном» спектруме включить 7Mhz «turbo» Zynaps начинает стабильно работать в 50fps, причем графика не сечется, спрайты монстриков не исчезают.
по геймплею чётко видно, что нижние и верхние препятствия на скроллящейся части экрана никогда не пересекаются лишь приближаясь ровно к центру
Есть фоновая графика уровня в Zynaps и по центру, это не на первом уровне.
Напомни, что именно является «святым граалем» твоих поисков оптимального компрессора.
Могу ошибаться, но с моей точки зрения, это поиск наиболее сильного сжатия (требование №1 к любому компрессору) в то же время при самой высокой скорости _распаковки_ на z80.
При этом запаковка на z80, как таковая, абсолютно не принимается в расчет.
Видимо, всё это для целей демо-«анимы», т.е. основанных на быстро распаковываемых данных. Подтверди, так это или не так.
Изучал ли ты успехи товарищей на других 8-битных платформах? Каковы они?
Я с тобой до этой поры не пересекался. Поэтому не знал что у тебя за натура, верил в лучшее.
Народ тут уже намекнул, что я опозорился самим этим фактом разговора с «летаргичкой».
Засим пока, позориться мне дальше вряд ли стоит.
Желательно привести «точные координаты» утверждений, как я просил. Страницу (по нумерации источника), абзац, текст. Связано это с тем что я не могу вычитывать все документы в поиске утверждаемого, весьма лимитировано время...
По моему мнению, ячейки памяти (в смысле ячейки ОЗУ) по смыслу не считались регистрами (в смысле регистрами процессора). В тексте применен термин «registers», означающий по смыслу также «ячейки памяти», «записи». Чего ты, видимо, не знал, не понял и не учел.
Второй мой тезис такой — в генеральном смысле регистр (в смысле регистр процессора) является ячейкой памяти (но не ОЗУ) и это действительно, может утверждаться в общем смысле.
Я тебе это пояснил, на что ты мне снова выдаёшь:
Подозреваю что с пониманием текста про UNIVAC1 у тебя происходит то же самое. Уточни страницу по внутренней нумерации, абзац, текст. Гляну. А главное, еще раз выскажи свои тезисы, что ты утверждаешь/не утверждаешь, хочешь понять.
Регистры это вид памяти, ячейки памяти, да. Как иначе? Возникает ощущение, что у тебя трудности с базовой терминологией, не понимая общих (обобщенных) терминов ты полагаешь что это ФИЗИЧЕСКИ одни и те же вещи.
Загугли что такое «омонимы».
Вообще (отступая в сторону) я в таких случая проверяю у англоговорящих исходный смысл термина по сайту etymonline.com. Учитывая что есть слова registrant, registry, registration — для англоговорящих это слово, по видимому, несет устойчивый смысл «запись», «нечто записанное». В смысле записи какого-то списка, нечто записанное на бумаге или внесённое. Поэтому регистры в самом общем смысле «записи» или ячейки (памяти)...
Но. Несмотря на это в каждой области существует устойчивый набор терминов и устоявшееся значение. Так что не стоит обобщать без явной на то необходимости. Напротив, стоит разделять понятия.
Интересный нюанс. На той же страница 6, конец параграфа вверху читаем о Core Memory: «Information is not retained when the power is off». Вообще, память на маг.серд. хранит информацию постоянно, до считывания, а у них на это не рассчитано.
Где я могу об этом прочесть? Можно URL на документацию? Страницу, конкретное место текста?
Это неверно. Внешняя память технологически появилась позже регистровой, но интерес представляет история термина «регистр». Помимо прямого смыслового значения: записывать, отмечать, вносить (т.е. регистрировать) дело тут может оказаться поинтереснее! Гипотезы такие. 1. «регистром» называется электронная схема, триггер. 2. Регистр это кассовый аппарат, втч счетный (букв. — счетчик). 3. Блок механического калькулятора/счетчика называется «регистром». 4. Регистры ЭВМ зачастую предоставляли оператору возможность механически вносить данные. Склоняюсь к прямому смысловому значению, но как оно исторически пока информации нет.
Мои мысли пока такие. Думаю что надо стремиться к тому что выбирать пакер не просто так, имея накопленные знания, а иметь практически легко доступный «интерфейс» компрессоров (а может и декомпрессоров) с тем чтобы пробовать их практически и сразу сравнить. Потому что знание это хорошо, но компрессия, штука порой непредсказуемая. Сжимаемые данные внезапно могут оказаться с какой-то совсем неожиданной спецификой, так что практика может оказаться далеко от ожидаемого, как в ту, так и в иную сторону.
Также надо исследовать пакеры на _наборах_ специфичных данных, например на спрайтах и тексте (или как насчет того чтобы паковать стрим регистров AY? :))) ). Ориентация на скорость/сжатие хорошо, но для игроделов требования более интересные. Основное добавочное требование игровых схем упаковки — это возможность распаковывать произвольные фрагменты упакованных данных, а не всё сразу и не потоково.
www.youtube.com/watch?v=gVAtXqESDcs
R-TYPE アール・タイプ в японском оригинале звучит как «Ару Тайпу»
Pape писал в книге что он оптимизировал код. Это очень свообразная оптимизация. Даже тот фрагмент что в книжке — без бутылки не разобраться.
Stalker (автор STS) в те годы пытался активно дизассемблировать именно R-Type. Как видно, не особо что вышло…
Savage (I) — рисует спрайты с создаваемой на лету «автомаской». «Автомаска» это биты графики спрайта, сдвинутые влево, сдвинутые вправо, наложенные по OR и инвертированные.
Т.е. из 00010000 сделает 00111000 и в итоге маска 11000111.
Примерно так же, как делается утолщеннный фонт. Но он это делает, естественно, по таблице. Хотя, припоминая дела 26-летней давности, я пробовал сранивать свою таблицу полученную описанным способом и она во многих местах не совпадала с имеющейся таблицей. Поэтому толи они вручную подредактировали таблицу (что может быть) толи сделали таблицу масок байтов вообще полностью вручную.
Dark Fusion делает 5 спрайтов бэкграунда (сдвинутых на 2pix), обеспечивая спрайты с пустым байтом-«концевиком» спереди и сзади, которым она и затирает фоновую графику при скроллинге. То есть графика шириной 3 байта имеет след. модификации:
00000000 11111111 11111111 11111111
00000011111111 11111111 11111111 00
000011111111 11111111 11111111 0000
0011111111 11111111 11111111 000000
11111111 11111111 11111111 00000000
Xecutor — определяет столкновения, читая собственную графику кораблика с экрана после того как выведет всех enemy-«тварюшек».
Jack The Nippper II не ждет int (как и подавляющее число игрушек) и использует технику как я её назвал «микробуфферинга», т.е. глобального бэкбуфера нет, локально бэкбуферится только то, что в данный момент накладывается друг на друга.
Из интересного не в играх — Shock последняя часть, с белыми «кувыркающимися» буквами SHOCK и звёздами — ВСЁ рисует ДО луча, то есть отрисовывает всё за верхний border. И вообще, интересный факт из всех демок E.S.I. А в курсе ли вы, что _ВСЕ_ они идут на 48к компьютере? Интересно, почему и зачем это. AY чип в оригинальном спектруме был только на 128к модели. Но графика вся выводится в 48к режиме, используя «гонки с лучом», и не просто графика, не используется память, все демки работают в 48к.
Из интересного. Когда-то очень давно, когда я увидел Lyra, я считал что демки _принципиально_ должны быть сделаны именно так, т.е. строго под 48к модель, несмотря на то что есть doublebuffered 128к экран. И использование doublebuffering'а мы считали «ламерством». Правда, жизнь расставила свои приоритеты, пока я усердно в поте лица устраивал гонки с лучом (например, сортируя спрайты), подъехала CB Satisfaction, где невозмутимо используется два экрана… =)
Насчет гонок с лучом. Гуглим книжку «RACING THE BEAM».
Любая программа, привязанная к int'у и перерисовывающая всё за 1/25sec (2*int) работает достаточно плавно.
«Разрывы» — это tearing графики? Zynaps все же синхронизируется с int'ом.
Tearing в Zynaps ещё как есть, просто он очень специфичный, надо знать, как он выглядит: время 3:52 и внимательно-внимательно смотрим далее. А столь специфичен он потому что они намеренно делают следующее. Они не обрабатывают «bulk» (т.е. широкую площадь) до и после луча (в месте потенциального сечения). Tearing будет заметен глазом когда МНОГО графики было ДО луча и МНОГО графики будет ПОСЛЕ луча, таким образом делая полосу «сечения» лучом хорошо заметной (МНОГОЕ сдвинуто до (выше луча) и МНОГОЕ (ниже луча) еще не сдвинуто). Вместо этого они обрабатывают по знакоместам (в некотором смысле симулируя столбцовый экран, бггг, вижу тут Lethargeek'а). Когда графика перерисовывается по знакоместам, проблема tearing'а случится только в нескольких «неудачных» знакоместах, попавших «под луч». Вдобавок, как я полагаю (не уверен на 100%), они используют трюк, начиная подвижную графику обновлять в рандомном порядке, таким образом делая «несчастливыми» знакоместами каждый раз разные. Это гораздо менее заметно для глаза.
Дичь с Zynaps совсем в другом. Насколько это мне известно с 90х, он рисует инверсную графику, накладывая её по AND и затирает атрибутами :))
— это изображение с paper black и white ink, т.е. в атрибутах байт 07.
Вопрос до конца не понятен. Почему за 2int'а? Потому что за 1 int (1/50sec, 50fps) не успевает. Не хватает производительности CPU. Если на реальном «железном» спектруме включить 7Mhz «turbo» Zynaps начинает стабильно работать в 50fps, причем графика не сечется, спрайты монстриков не исчезают.
Есть фоновая графика уровня в Zynaps и по центру, это не на первом уровне.
Могу ошибаться, но с моей точки зрения, это поиск наиболее сильного сжатия (требование №1 к любому компрессору) в то же время при самой высокой скорости _распаковки_ на z80.
При этом запаковка на z80, как таковая, абсолютно не принимается в расчет.
Видимо, всё это для целей демо-«анимы», т.е. основанных на быстро распаковываемых данных. Подтверди, так это или не так.
Изучал ли ты успехи товарищей на других 8-битных платформах? Каковы они?
Я с тобой до этой поры не пересекался. Поэтому не знал что у тебя за натура, верил в лучшее.
Народ тут уже намекнул, что я опозорился самим этим фактом разговора с «летаргичкой».
Засим пока, позориться мне дальше вряд ли стоит.
https://www.youtube.com/watch?v=IA_evL-1F0w&t=33