Немного оффтопа - Hudson Soft, через 4 года после Famicom (описанного в статье) выпустившая в Японии совместно с NEC консоль PC Engine (также выпущенную в Америке под названием TurboGrafx-16), развила эта концепцию мапперов еще дальше - маппер тут встроен непосредственно сам в процессор HuC6280.
Данный процессор по сути является развитием процессора MOS 6502 (который без BCD-арифметики используется в составе процессора 2A03 в NES/Famicom). Он так же является 8-битным и имеет 64 КБ непосредственно адресуемой памяти. Но сама адресная шина процессора HuC6280 - 21-битная, и он может адресовать до 2 МБ памяти. Реализуется это за счет встроенного в процессор маппера, который делит эти 2 МБ на 256 участков по 8 КБ. Все адресное пространство в 64 КБ разделено на 8 участков по 8 КБ и на каждый участок можно отобразить любую из 256 страниц физической памяти, записав в специальный регистр номер страницы (регистров также 8, по числу участков).
Такая система позволила значительно упростить и уменьшить сами картриджи (в них содержится только ROM чип с игрой). Ну и в целом, для 8-битной системы потолок в 2 МБ оказался вполне себе достаточным - большинство игр на картриджах не превышали объем 512 КБ - 1 МБ.
Как раз месяц назад проходил оригинальную CD версию игры без всяких улучшающих модов (типа свободного обзора мышью). В детстве у меня этой игры не было, тогда как тот же Doom, разумеется, был. Тем не менее, игрой остался очень доволен.
В ретроспективном взгляде игра все же достаточно сильно опередила свое время, предлагая в 1994 году иммерсивный 3D экшен с нелинейным прохождением.
Может быть, игре тупо не повезло со временем выхода - как уже упоминалось в статье, инфопространство захватил Doom и тезис Кармака про "сюжет в порнофильме".
Хотя, с другой стороны, жанр 3D шутеров тогда просто был не так сильно развит. Ему не нужны были все эти сложные механики, нужно было, наоборот, сделать кривую вхождения более пологой.
И как по мне, Doom своим выходом как раз все это и обеспечил. Это примерно как выход Super Mario Bros в 1985 году поднял планку молодого тогда жанра платформинговых игр на новый уровень. Ну и дополнительно выход Doom серьезно повлиял на геймплейные аспекты для жанра 3D экшена, задав как основы для спидрана (в нем появилась удобная возможность записывать свои прохождения, что позволяло обмениваться файлами записей и сравнивать их), так и мультиплеерной игры (можно почитать в Интернете, как в 1994 в компаниях ложились сети из-за широковещательных пакетов, посылаемые сетевой игрой в Doom).
Таким образом, жанр 3D экшена вернулся к идее сюжетно-иммерсивного геймплея только ближе к концу 90-х, когда появились знакомые многим Half-Life, Unreal, ну и вторая часть System Shock как раз в этот же период вышла.
Ну а вообще, еще до System Shock были подобные игры в жанре 3D экшена, обладающие интересными игровыми механиками и предлагающие нелинейное прохождение, просто они мало известны в силу внешней непривлекательности с точки зрения современного зрителя. Посмотрите, например, Cybercon 3 на компьютере Amiga - мне кажется, что авторы System Shock явно вдохновлялись им тоже при создании своей игры.
Если говорить про интересные видеосистемы начала 1980-х, нельзя не упомянуть достаточно популярную в Японии, но практически неизвестную в остальном мире на фоне остальных компьютеров серию Fujitsu FM-7 (вышедшую в 1982 году как удешевленный вариант компьютера Fujitsu FM-8).
На фоне своих конкурентов (NEC PC-8801, Sharp X1) данная серия компьютеров отличалась интересной особенностью - в ней было 2 CPU модели Motorola 6809, второй при этом работал независимо от первого и отвечал за видеосистему и доступ к видеопамяти (ну и вдобавок отвечал за ввод с клавиатуры). Процессоры были связаны между собой небольшим окном в адресном пространстве, через которое они могли обмениваться данными. Графика выводилась путем отправки программы и данных из основной памяти в видеопамять, после чего второй CPU исполнял эту программу и рисовал на экране пиксели, линии и другие примитивы.
Да, это по сути первый персональный компьютер (именно персональный, профессиональные графические станции к тому времени уже существовали) с программируемым видеопроцессором (то есть GPU), а программы для него можно назвать самыми первыми шейдерами.
Возможно, это будет немного оффтопом, но раз в статье было упоминание про язык MML, напишу немного о нем (так как сам в одно время занимался аранжировками с использованием этого языка), а также в чем его особенности в сочинении музыки по сравнению с использованием трекеров.
Подход тут в корне отличается. Любой трекер, как описывается в статье, в большинстве случаев - это WYSIWYG-программа, с графическим интерфейсом, где паттерны и ордер-лист композиции достаточно наглядно ее представляет и редактирование партитуры также происходит наглядно. Тогда же как MML - это что-то наподобие программы (то есть обычный текст, редактируемый в любом текстовом редакторе), которая впоследствии компилируется в воспроизводимый звуковой модуль (универсального MML-диалекта нет, так как у каждого звукового чипа свои особенности). Разница примерно такая же, как если делать документ в Word, или с использованием TeX.
Текст-программа на языке MML чаще всего структурируется - вначале это разнообразная метаинформация (название трека, автор, ...), далее идут описания инструментов (которые можно редактировать напрямую, но обычно они редактируются в отдельном WYSIWYG-редакторе, а затем получившийся текст с параметрами вставляется в программу), затем настройки каналов (каждый из который обычно привязан к одному генератору звукового чипа компьютера), и после этого сама партитура - набор музыкальных данных (ноты, паузы, размеры, регулировки инструментов, эффекты и прочее), перед которым идет название канала, который должен это проигрывать. Паттерны, присущие трекерному формату, отсутствуют - каждый канал играет все свои данные от начала и до конца (при этом возможно указать точку циклического воспроизведения), и вся логическая разбивка трека ложится исключительно на плечи аранжировщика. Также в MML нотация, в отличие от трекерной музыки, музыкальная - ноты и паузы тут имеют классические описания длительности (обычно указывается знаменатель, например для 1/64 это просто 64)
Определенные сходства с трекерным форматом все же есть. Например, выше упоминавшаяся концепция каналов (чаще всего они имеют заглавные буквы латинского алфавита, A-Z), но, которые в отличие от трекерных аналогов, чаще всего полностью независимы друг от друга. Есть определенные преимущества, присущие текстовому формату - можно оформлять подпрограммы или макрокоманды, которые затем вызываются в основном коде партитуры, и за счет которых можно параметризовать повторяющиеся участки музыки. Также формат текста позволяет проводить манипуляции средствами самого текстового редактора (поиск, замена, регулярные выражения и так далее) Недостатки также присутствуют - за счет того, что это обычный текст, "увидеть" целиком весь трек сложно. Плюс также за счет независимости каналов вся синхронизация между ними ложится на аранжировщика. Нередки ситуации, когда за счет разной длительности общего числа тактов в разных каналах один начинает играть раньше (или позже другого). В трекерном формате такого не происходит за счет жесткой "сетки", которая формирует паттерн. Для решения этой проблемы несколько музыкальных тактов группируется (получается своеобразный "паттерн") и каждый такой "паттерн" уже потом редактируется индивидуально от других.
Причины популярности конкретно MML формата в японской компьютерной среде (в основном в саундтреках к играм и додзин-альбомах, демосцены в западном понимании там не было вообще) сугубо исторические. На ранних японских компьютерах в большинстве случаев имелся предустановленный диалект BASIC, в котором имелась упоминаемая в статье команда CMD PLAY. Эта команда проигрывала на звуковом чипе компьютера (который зависел от машины) ноты в простейшем диалекте MML-формата. На основе этого было разработано много MML-редакторов, которые часто оставляли BASIC-редактор как основу, а все музыкальные данные заносили в комментарии (так что MML-композиция оставалась также и валидной BASIC-программой). Обычно каждая компания или разработчик делали свой MML диалект под конретные нужды. Например, Юзо Косиро (известный как минимум по саундтреку Streets of Rage) написал свой MML-редактор MUCOM88 (распространыемый коммерчески под названием MUSIC LALF).
Тема MML-музыки довольно обширная, в спонтанный комментарий все нюансы не влезут, впору писать отдельную статью. От себя скажу, что как трекерный, так и MML формат имеют право на жизнь. Я, пытавшийся делать аранжировки как в том, так и в другом формате, так и не определился, какой из этих способов удобнее. Я думаю, было бы довольно интересно увидеть MML-диалект для биперной музыки.
Я этой зимой купил себе SC-88 Pro - в целом отличий от звучания с Sound Canvas VA (в режиме 88Pro) не заметил. Единственное, что SCVA не поддерживает (насколько я знаю) - это User Instruments / Drumkits (которые грузятся в банк 064/065). Например, вот в этой миди https://www.youtube.com/watch?v=F1eHXuMsRMA эти эффекты используются, и в SCVA они будут звучать немного иначе, чем на железке.
А по переделке - очень круто! Я единственное, что сделал на своем SC-88Pro - это переделку с 100В на 220В (благо это там делается перепайкой одного провода). Но вот вашу переделку уже боязно осуществлять :) , так как аппарат в единственном экземпляре.
Немного оффтопа - Hudson Soft, через 4 года после Famicom (описанного в статье) выпустившая в Японии совместно с NEC консоль PC Engine (также выпущенную в Америке под названием TurboGrafx-16), развила эта концепцию мапперов еще дальше - маппер тут встроен непосредственно сам в процессор HuC6280.
Данный процессор по сути является развитием процессора MOS 6502 (который без BCD-арифметики используется в составе процессора 2A03 в NES/Famicom). Он так же является 8-битным и имеет 64 КБ непосредственно адресуемой памяти. Но сама адресная шина процессора HuC6280 - 21-битная, и он может адресовать до 2 МБ памяти. Реализуется это за счет встроенного в процессор маппера, который делит эти 2 МБ на 256 участков по 8 КБ. Все адресное пространство в 64 КБ разделено на 8 участков по 8 КБ и на каждый участок можно отобразить любую из 256 страниц физической памяти, записав в специальный регистр номер страницы (регистров также 8, по числу участков).
Такая система позволила значительно упростить и уменьшить сами картриджи (в них содержится только ROM чип с игрой). Ну и в целом, для 8-битной системы потолок в 2 МБ оказался вполне себе достаточным - большинство игр на картриджах не превышали объем 512 КБ - 1 МБ.
Как раз месяц назад проходил оригинальную CD версию игры без всяких улучшающих модов (типа свободного обзора мышью). В детстве у меня этой игры не было, тогда как тот же Doom, разумеется, был. Тем не менее, игрой остался очень доволен.
В ретроспективном взгляде игра все же достаточно сильно опередила свое время, предлагая в 1994 году иммерсивный 3D экшен с нелинейным прохождением.
Может быть, игре тупо не повезло со временем выхода - как уже упоминалось в статье, инфопространство захватил Doom и тезис Кармака про "сюжет в порнофильме".
Хотя, с другой стороны, жанр 3D шутеров тогда просто был не так сильно развит. Ему не нужны были все эти сложные механики, нужно было, наоборот, сделать кривую вхождения более пологой.
И как по мне, Doom своим выходом как раз все это и обеспечил. Это примерно как выход Super Mario Bros в 1985 году поднял планку молодого тогда жанра платформинговых игр на новый уровень. Ну и дополнительно выход Doom серьезно повлиял на геймплейные аспекты для жанра 3D экшена, задав как основы для спидрана (в нем появилась удобная возможность записывать свои прохождения, что позволяло обмениваться файлами записей и сравнивать их), так и мультиплеерной игры (можно почитать в Интернете, как в 1994 в компаниях ложились сети из-за широковещательных пакетов, посылаемые сетевой игрой в Doom).
Таким образом, жанр 3D экшена вернулся к идее сюжетно-иммерсивного геймплея только ближе к концу 90-х, когда появились знакомые многим Half-Life, Unreal, ну и вторая часть System Shock как раз в этот же период вышла.
Ну а вообще, еще до System Shock были подобные игры в жанре 3D экшена, обладающие интересными игровыми механиками и предлагающие нелинейное прохождение, просто они мало известны в силу внешней непривлекательности с точки зрения современного зрителя. Посмотрите, например, Cybercon 3 на компьютере Amiga - мне кажется, что авторы System Shock явно вдохновлялись им тоже при создании своей игры.
Cybercon 3 (Amiga)
Если говорить про интересные видеосистемы начала 1980-х, нельзя не упомянуть достаточно популярную в Японии, но практически неизвестную в остальном мире на фоне остальных компьютеров серию Fujitsu FM-7 (вышедшую в 1982 году как удешевленный вариант компьютера Fujitsu FM-8).
На фоне своих конкурентов (NEC PC-8801, Sharp X1) данная серия компьютеров отличалась интересной особенностью - в ней было 2 CPU модели Motorola 6809, второй при этом работал независимо от первого и отвечал за видеосистему и доступ к видеопамяти (ну и вдобавок отвечал за ввод с клавиатуры). Процессоры были связаны между собой небольшим окном в адресном пространстве, через которое они могли обмениваться данными. Графика выводилась путем отправки программы и данных из основной памяти в видеопамять, после чего второй CPU исполнял эту программу и рисовал на экране пиксели, линии и другие примитивы.
Да, это по сути первый персональный компьютер (именно персональный, профессиональные графические станции к тому времени уже существовали) с программируемым видеопроцессором (то есть GPU), а программы для него можно назвать самыми первыми шейдерами.
Подробнее про программирование под него можно почитать тут: https://www.chibiakumas.com/6809/fm7.php
Под него даже пару демок имеется (правда, далеко не выжимающие все возможности платформы):
Hidden text
Возможно, это будет немного оффтопом, но раз в статье было упоминание про язык MML, напишу немного о нем (так как сам в одно время занимался аранжировками с использованием этого языка), а также в чем его особенности в сочинении музыки по сравнению с использованием трекеров.
Подход тут в корне отличается. Любой трекер, как описывается в статье, в большинстве случаев - это WYSIWYG-программа, с графическим интерфейсом, где паттерны и ордер-лист композиции достаточно наглядно ее представляет и редактирование партитуры также происходит наглядно. Тогда же как MML - это что-то наподобие программы (то есть обычный текст, редактируемый в любом текстовом редакторе), которая впоследствии компилируется в воспроизводимый звуковой модуль (универсального MML-диалекта нет, так как у каждого звукового чипа свои особенности). Разница примерно такая же, как если делать документ в Word, или с использованием TeX.
Текст-программа на языке MML чаще всего структурируется - вначале это разнообразная метаинформация (название трека, автор, ...), далее идут описания инструментов (которые можно редактировать напрямую, но обычно они редактируются в отдельном WYSIWYG-редакторе, а затем получившийся текст с параметрами вставляется в программу), затем настройки каналов (каждый из который обычно привязан к одному генератору звукового чипа компьютера), и после этого сама партитура - набор музыкальных данных (ноты, паузы, размеры, регулировки инструментов, эффекты и прочее), перед которым идет название канала, который должен это проигрывать. Паттерны, присущие трекерному формату, отсутствуют - каждый канал играет все свои данные от начала и до конца (при этом возможно указать точку циклического воспроизведения), и вся логическая разбивка трека ложится исключительно на плечи аранжировщика. Также в MML нотация, в отличие от трекерной музыки, музыкальная - ноты и паузы тут имеют классические описания длительности (обычно указывается знаменатель, например для 1/64 это просто 64)
Определенные сходства с трекерным форматом все же есть. Например, выше упоминавшаяся концепция каналов (чаще всего они имеют заглавные буквы латинского алфавита, A-Z), но, которые в отличие от трекерных аналогов, чаще всего полностью независимы друг от друга. Есть определенные преимущества, присущие текстовому формату - можно оформлять подпрограммы или макрокоманды, которые затем вызываются в основном коде партитуры, и за счет которых можно параметризовать повторяющиеся участки музыки. Также формат текста позволяет проводить манипуляции средствами самого текстового редактора (поиск, замена, регулярные выражения и так далее)
Недостатки также присутствуют - за счет того, что это обычный текст, "увидеть" целиком весь трек сложно. Плюс также за счет независимости каналов вся синхронизация между ними ложится на аранжировщика. Нередки ситуации, когда за счет разной длительности общего числа тактов в разных каналах один начинает играть раньше (или позже другого). В трекерном формате такого не происходит за счет жесткой "сетки", которая формирует паттерн. Для решения этой проблемы несколько музыкальных тактов группируется (получается своеобразный "паттерн") и каждый такой "паттерн" уже потом редактируется индивидуально от других.
Причины популярности конкретно MML формата в японской компьютерной среде (в основном в саундтреках к играм и додзин-альбомах, демосцены в западном понимании там не было вообще) сугубо исторические. На ранних японских компьютерах в большинстве случаев имелся предустановленный диалект BASIC, в котором имелась упоминаемая в статье команда CMD PLAY. Эта команда проигрывала на звуковом чипе компьютера (который зависел от машины) ноты в простейшем диалекте MML-формата. На основе этого было разработано много MML-редакторов, которые часто оставляли BASIC-редактор как основу, а все музыкальные данные заносили в комментарии (так что MML-композиция оставалась также и валидной BASIC-программой). Обычно каждая компания или разработчик делали свой MML диалект под конретные нужды. Например, Юзо Косиро (известный как минимум по саундтреку Streets of Rage) написал свой MML-редактор MUCOM88 (распространыемый коммерчески под названием MUSIC LALF).
Тема MML-музыки довольно обширная, в спонтанный комментарий все нюансы не влезут, впору писать отдельную статью. От себя скажу, что как трекерный, так и MML формат имеют право на жизнь. Я, пытавшийся делать аранжировки как в том, так и в другом формате, так и не определился, какой из этих способов удобнее. Я думаю, было бы довольно интересно увидеть MML-диалект для биперной музыки.
Думаю, все же сейчас SC-88 корректнее сравнивать с Sound Canvas VA - https://www.roland.com/global/products/rc_sound_canvas_va, поскольку VSC88 уже порядком устарел и не имеет поддержку возможностей 88Pro и 8820/8850.
Я этой зимой купил себе SC-88 Pro - в целом отличий от звучания с Sound Canvas VA (в режиме 88Pro) не заметил. Единственное, что SCVA не поддерживает (насколько я знаю) - это User Instruments / Drumkits (которые грузятся в банк 064/065). Например, вот в этой миди https://www.youtube.com/watch?v=F1eHXuMsRMA эти эффекты используются, и в SCVA они будут звучать немного иначе, чем на железке.
А по переделке - очень круто! Я единственное, что сделал на своем SC-88Pro - это переделку с 100В на 220В (благо это там делается перепайкой одного провода). Но вот вашу переделку уже боязно осуществлять :) , так как аппарат в единственном экземпляре.