Цитата Сообщение от introspec Посмотреть сообщение
а) Потому что фирмы изготовители работали полный рабочий день и за деньги, т.е. имели гораздо больше времени и стимулов.
Ага. И цель у них была - заработать бабла. У тебя сейчас цели другие. И если >128К твоим целям не соответствуют, ты под них и не пиши, но и не говори, что оно не надо.
Цитата Сообщение от introspec Посмотреть сообщение
б) Даже в таких, существенно более выгодных условиях, фирмы-изготовители практически никогда не писали софт под 128к. Потому что за их свет в их офисах и за хлеб на их столе платили пользователи, а пользователей 128к было недостаточно, чтобы оправдать разработку под 128к only.
Вот и я ровно о том же. Не пиши под 256К only, пиши 48/128/256.
Цитата Сообщение от introspec Посмотреть сообщение
в) Потому что есть разные виды урезанных возможностей. Добавить 128к звук - почти тривиальный ход, т.к. не требует никаких существенных ресурсов: доп. память в 128к есть, проигрыватель не требует много тактов, да и кол-во тактов на фрейм в 128к немного подросло. Фактически, не требуется писать новый рендер или новый движок, мы просто добавляем к 48 движку несколько броских фишек. Та же самая идея - увеличение объёма графики без подзагрузок, всё грузится в буфер и бросается в главную память по необходимости. Но это опять 48к мышление, просто дополненное эффективной подгрузкой.
Это абстрактный разговор. Ты уверен, что ты знаешь за всех разработчиков все способы использования памяти выше 128К? Вернее, что их не существует, кроме как распихивания графики уровней, которую можно и с дискеты 10 раз за игру подгрузить. Я вот знаю способ как использовать такую память не только как буфер для графики. В играх.
Цитата Сообщение от introspec Посмотреть сообщение
д) Что я пытаюсь сказать. В моём понимании, вот это мышление "написать под всё с урезанными возможностями" означает, на самом деле, написать под минимальную конфигурацию, а потом добавить сверху малозначительные плюшки. А раз плюшки малозначительные (мы же собираемся их сравнительно безболезненно выкидывать, так?), ответ на оригинальный пост оказывается очевидным: не нужна дополнительная память, т.к. мы не собираемся её всерьёз использовать.
Нет, не так. Написать код изначально так, чтобы можно было урезать возможности относительно запланированных на машинах с более слабым железом. Я не собираюсь никогда следовать предложенному тобой шаблону. Иначе можно сказать, что "не нужен нам кемпстон джойстик (мышь, сопроцессор, видеорежим, дисковод, ...) потому что мы не собрираемся их всерьез использовать.

Цитата Сообщение от introspec Посмотреть сообщение
е) Есть ещё такой подход, написать сразу под всё, макроассемблер всё скушает.
Мне этот подход тоже не нравится. Надо, чтобы загрузчик детектил железо и спрашивал у пользователя про возможности его машины, и на основании этой информации включал/выключал поддержку устройств в коде. Пример такого кода - в моих биперных демках для AAA, они работают по-разному на 48 и 128К, заточены под Пент, Скорп, Профи и оригинал, при этом используется один и тот же образ.
Цитата Сообщение от introspec Посмотреть сообщение
Именно поэтому, в моём понимании, авторы ретро-железок должны думать не о том, что продать пользователю, а о том, что пользователю нужно.
В моем понимании время заботы об интересах пользователя ушло вместе с коммерческой разработкой для Спектрума (это не значит, что пользователи вообще идут лесом). Все пишется по приколу. Если моя идея не влезет в 128К, я не буду париться про то, что у nn% нет 128К. Я напишу под 256К потому что менят так прет, потому что так я вообще что-то напишу, а впихивание этого в 128К сделает разработку невозможной. А теперь скажи мне, ты больше ценишь канонiчный софт, или невышедший?