Столько лет уже прошло, а это до сих пор кому-то важно. Вадим: ничего доказывать не надо, мне безразлично ты это сделал или не ты и я уже никого не подозреваю.
Обожаю всё-таки романтику тех ранних лет.
Давно уже натыкался на статью от 20 сентября 1975 года про тестирование новенького и только что спущенного со стапелей микропроцессора 6502 (англ.): www.swtpc.com/mholley/Microprocessors/EDN_Sep_20_1975_6502.pdf
Текст под фото: «Рис. 2 — Изначальный макет (нашего) журнала для „оживления“ микропроцессора MOS Technology 6502 показывает насколько просты машины второго с половиной поколения в плане разводки проводов для пользователя. Эта макетная плата была разложена (в течении недели) чтобы приблизиться к топологии, которую журнал использует для общих замеров микропроцессоров. И хотя мы обнаружили немало шума (главным образом вместе с синхроимпульсами) на всех наших довольно длинных и разбросанных проводах, но 6502 отработал без ошибок.»
Так вот — эта разводка это они буквально тестировали как работает процессор подключив к нему просто щупы и анализируя активность на шине данных, т.к. даже толком RAM к нему подключить не могли. 10 байт программы в ППЗУ залили и смотрели как она ножками «шевелит». :)
Fairchild F8 там, кстати, тоже упомянут как «сильный соперник».
Так вот в начале статьи с восхищением рассказывается, что с появлением MOS 6502 на рынке становится возможным всего за 50 долларов (~240 долларов в сегодняшних ценах) становится возможным создать полностью рабочую мю-систему с 200 байтами ROM, 100 байтами RAM и даже, возможно (!) четырьмя портами ввода-вывода!
Но посмотрите на этой и с другой стороны — разве доступ к регистрам в точности как будто бы через порты ввода-вывода разве соответствует понятию регистра в современном смысле? По моему с памятью как раз проблем в этом смысле меньше, ведь доступ к VRAM ну у той же NES сделан как раз вот наподобие же — через порты ввода-вывода с выставлением адреса и даже тоже возможностью автоинкремента. Конечно тут такой древний мамонт, что напрямую на современные практики плохо натягивается, но всё-таки, имхо, как раз с RAM у такой организации доступа больше общего чем с регистрами. Ну по крайней мере, опять таки, в современном понимании. Так что я бы всё-таки сказал что в данном приборе не то чтобы нет RAM, но её прям мало и она прям «нетрадиционная». :) Но не вижу смысла до хрипоты об этом спорить.
Видео, кстати, с час назад досмотрел. Насчёт этих вот непоняток с адресациями я испытывал похоже такие же ощущения как и вы когда читал доки по Intel 4004 — прям реально вроде вот оно всё написано, но тоже доступ через пень-колоду, и даже 3 или 4 разных видов банков с разной адресацией и вырвиглазным страничным доступом который точно так же «вроде уже показалось что начал понимать», но снова натыкаешься на какую то хрень которую не можешь приладить к только что прочитанному и якобы «осмысленному». :) Дааа.
Так дело не в том, как технически реализованы эти ячейки (на ферритовых сердечниках точно так же можно сделать ОЗУ, а можно регистры). А в том, какие возможности обеспечиваются. В данном случае это «ОЗУ» отсутствует в адресном пространстве. И оно просто напросто не соответствует термину Random Access Memory, ибо оно не random. Нет там произвольного доступа к любой ячейке.
Отличная статья! Хотя я бы лично не согласился с тем, что регистры адресуемые через ISAR нельзя называть ОЗУ. Scratchpad memory в принципе популярна в микроконтроллерах и сейчас. И нужно еще помнить, что 50-е и 60-е термином «регистры» в принципе могли называть ячейки RAM, так, например называются ячейки памяти на ферритовых сердечниках в документации IBM-704 и поэтому вероятно в те годы ни у кого в принципе не вызывало претензий к терминологии даже если в документации к F8 что-то вот эдакое называется регистрами. Это уже потом понятия как то сильно разошлись и стали чуть ли не противопоставляться.
насчет инверсной графики это совершенно точно, так как было отлично видно на всех компьютерах, имевших проблемы с отображением чередующихся инверсных и неинверсных знакомест (тонкая светлая вертикальная полоса на стыке знакомест).
Прочитал всё что ты написал, написанное очень осмысленно.
Мои мысли пока такие. Думаю что надо стремиться к тому что выбирать пакер не просто так, имея накопленные знания, а иметь практически легко доступный «интерфейс» компрессоров (а может и декомпрессоров) с тем чтобы пробовать их практически и сразу сравнить. Потому что знание это хорошо, но компрессия, штука порой непредсказуемая. Сжимаемые данные внезапно могут оказаться с какой-то совсем неожиданной спецификой, так что практика может оказаться далеко от ожидаемого, как в ту, так и в иную сторону.
Также надо исследовать пакеры на _наборах_ специфичных данных, например на спрайтах и тексте (или как насчет того чтобы паковать стрим регистров AY? :))) ). Ориентация на скорость/сжатие хорошо, но для игроделов требования более интересные. Основное добавочное требование игровых схем упаковки — это возможность распаковывать произвольные фрагменты упакованных данных, а не всё сразу и не потоково.
И вообще, интересный факт из всех демок E.S.I. А в курсе ли вы, что _ВСЕ_ они идут на 48к компьютере? Интересно, почему и зачем это. AY чип в оригинальном спектруме был только на 128к модели.
У них были расширенные до 128к 48-е спектрумы с АУ интерфейсом но без второго экрана. Yerz даже ведёт список игор до сих пор которые 48к+ау
И еще до кучи, что-то там интересное творится в 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.
Давно уже натыкался на статью от 20 сентября 1975 года про тестирование новенького и только что спущенного со стапелей микропроцессора 6502 (англ.): www.swtpc.com/mholley/Microprocessors/EDN_Sep_20_1975_6502.pdf
Текст под фото: «Рис. 2 — Изначальный макет (нашего) журнала для „оживления“ микропроцессора MOS Technology 6502 показывает насколько просты машины второго с половиной поколения в плане разводки проводов для пользователя. Эта макетная плата была разложена (в течении недели) чтобы приблизиться к топологии, которую журнал использует для общих замеров микропроцессоров. И хотя мы обнаружили немало шума (главным образом вместе с синхроимпульсами) на всех наших довольно длинных и разбросанных проводах, но 6502 отработал без ошибок.»
Так вот — эта разводка это они буквально тестировали как работает процессор подключив к нему просто щупы и анализируя активность на шине данных, т.к. даже толком RAM к нему подключить не могли. 10 байт программы в ППЗУ залили и смотрели как она ножками «шевелит». :)
Fairchild F8 там, кстати, тоже упомянут как «сильный соперник».
Так вот в начале статьи с восхищением рассказывается, что с появлением MOS 6502 на рынке становится возможным всего за 50 долларов (~240 долларов в сегодняшних ценах) становится возможным создать полностью рабочую мю-систему с 200 байтами ROM, 100 байтами RAM и даже, возможно (!) четырьмя портами ввода-вывода!
Видео, кстати, с час назад досмотрел. Насчёт этих вот непоняток с адресациями я испытывал похоже такие же ощущения как и вы когда читал доки по Intel 4004 — прям реально вроде вот оно всё написано, но тоже доступ через пень-колоду, и даже 3 или 4 разных видов банков с разной адресацией и вырвиглазным страничным доступом который точно так же «вроде уже показалось что начал понимать», но снова натыкаешься на какую то хрень которую не можешь приладить к только что прочитанному и якобы «осмысленному». :) Дааа.
Мои мысли пока такие. Думаю что надо стремиться к тому что выбирать пакер не просто так, имея накопленные знания, а иметь практически легко доступный «интерфейс» компрессоров (а может и декомпрессоров) с тем чтобы пробовать их практически и сразу сравнить. Потому что знание это хорошо, но компрессия, штука порой непредсказуемая. Сжимаемые данные внезапно могут оказаться с какой-то совсем неожиданной спецификой, так что практика может оказаться далеко от ожидаемого, как в ту, так и в иную сторону.
Также надо исследовать пакеры на _наборах_ специфичных данных, например на спрайтах и тексте (или как насчет того чтобы паковать стрим регистров AY? :))) ). Ориентация на скорость/сжатие хорошо, но для игроделов требования более интересные. Основное добавочное требование игровых схем упаковки — это возможность распаковывать произвольные фрагменты упакованных данных, а не всё сразу и не потоково.
У них были расширенные до 128к 48-е спектрумы с АУ интерфейсом но без второго экрана. Yerz даже ведёт список игор до сих пор которые 48к+ау
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.
Вопрос именно в том как получается всё плавно но за 2 инта и без разрывов.