Не 14 а 12 ;)Цитата:
Сообщение от Sonic
Вид для печати
Не 14 а 12 ;)Цитата:
Сообщение от Sonic
Почему?Цитата:
Сообщение от heroy
Цитата:
Сообщение от Sonic
В GS 12МГц проц (DMA USC был без процессора)Цитата:
Сообщение от heroy
OpenFirmware. :)Цитата:
Сообщение от Sonic
В принципе, даже бейсик имеет право на существование. Главное, чтобы он не был неизбежным злом - чтобы была возможность выключать ПЗУ из адресного пространства, чтобы иметь все 64к как ОЗУ. И как-то при старте не выпадать сразу в Бейсик, а сначала, к примеру, пытаться грузануться с диска. Или иметь настраиваемый bootlist.
Если я не ошибаюсь, первые персоналки IBM PC (XT?) как раз и имели такой бейсик в ПЗУ, который стартовал в отсутствие загрузочных дисков.Цитата:
Сообщение от Error404
Такие машины есть. По идее имеющиеся апгрейдятся ну очень легко - просто добавляется отключение ПЗУ - и все.Цитата:
Сообщение от Error404
Или альтернатива - грамотно интегрировать загрузку в бейсик. RANDOMIZE USR 15619:REM:RUN - это я согласен неудобно. Вон в импортных дисковых интерфейсах все рулит. В PlusD просто набираешь RUN при отсутствии в памяти программы - и порядок. В D80 вообще ничего набирать не надо - просто бейсик расширяется и все. Начинает понимать конструкции типа LOAD"A:Program". Как впрочем и должно быть.Цитата:
И как-то при старте не выпадать сразу в Бейсик, а сначала, к примеру, пытаться грузануться с диска. Или иметь настраиваемый bootlist.
Судя по всему создатели бетадиска руководствовались теми же соображениями что и создатели советских клонов Спека: "неважно насколько качественно, главное как можно меньше средств".
Я сделаю немного оффтопа.
Я смотрю на существующую арихитектуру x86 и x64. Я смотрю на их многопроцессорные решения (2, 4 и более процессоров на одной материнской плате). И я могу сделать такой вывод: для этой чрезвычайно поддержанной деньгами платформы пока многоядерность является своего рода "бонусом", за счёт чего можно несколько увеличить производительность некоторых приложений. Единственным исключением является рынок серверов, но его стоимость (как наверное любого серверного решения) вызывает желание выть на луну в ночном небе.
Т.о. даже в PC платформе на фоне многозадачных/многопоточных ОСей пока многоядерность является лишь бонусом.
Теперь с земли грешной возвращаюсь под облакы наших спекков.
В настоящее время я бы очень хотел развития платформы, только я не вижу смысла развивать её столь революционно. Лично я НЕ против многопроцессорности, но 1) на каких именно платформах будет внедряться эта конфигурация 2) как будет организован менеджер многопроцессорности 3) как управлять этим менеджерам 4) предполагается симметричная равноправная система многопроцессорности или что-то иное?
В текущем обсуждении пока обсуждались проблемы технического толка, как будет работать память и т.п., а вот как насчёт опять же поддержки такой системы? для чего вообще можно будет использовать два процессора? Чисто теоретически - каждый процессор должен обладать отдельным адресно-страничным пространством, как это предполагается реализовывать? Что даст это для существующего парка ПО?
Для существуещего ПО это не даст ничего. ПО, поддерживающее новые фичи нужно будет делать самостоятельно.Цитата:
Сообщение от GriV
Зачем Спектруму два (три, четыре, сто) процессора? Лучше установите один, но хороший!
Один хороший процессор стоит n плохих и наоборот.
Вообще, не в процессорах дело. Звук у ZX УЖЕ неплохой (для возможностей ядра Спектрума). Графика... не видел пока твердых стандартов. Есть прерывания, есть процедуры, а многоядерность -- не показатель.