Единый ZX конструктив.

[ZEK]

Речь о программинге доп процов может идти тока в случае если эти самые процы будут в клое в 1 экзампляре (ну даже 1-2 десятках, а если будет как доп плата (акселератор) который можно подключить к любом клону, и еще то что написал в решаемых задачах имеет смысл если процы будут 21-28Мгц в случае 3,5-7Мгу процов смысл теряется, (пункт 1 идеет ваще по отдельной статтье так как для того что бы он мог рулить звуком нужно организовывать захват шины и писать данные в порт, а это большая проблема для уществующих клонов)

[Advertiser]

[MegaMyth]

Если имеется более 1 проца, то следовательно необходимо организовывавать распределение доступа к шине. А в известных мне моделях клонов используется динамическая память, что накладывает некоторые ограничения. Не для кого не секрет, что в большинстве клонов, в момент обращения проца к памяти происходит генерация WAIT, что является следствием медленной работы памяти. Таким образом о мультипроцессорности речи быть не может, хотя можно извратиться и сделать память для каждого проца свою, но как же быть с устройствами. если всем дополнительным процам нужно будет работать с устройствами, то шина головного проца в некотроый момент времени будет занята на столько, что он не сможет сам выполнять команды. тем более если память у всех своя, значит нужно её каким-то образом пересылать... что тоже занимет время, за которое мы и боремся...
Отсюда вытекают некоторые правила:
1. Частота шины должна обеспечивать работу как минимум 2-х процов и видеоконтроллера. поскольку минимальный цикл чтения памяти у Z80 3 такта, мы получаем:
1 процессор 28 000 000/3=9,33 МБ/сек или 107 нс.
2 процессора 2*28 000 000/3=18,66 МБ/сек или 53 нс.
3 процессора 3*28 000 000/3=28 МБ/сек или 35 нс.
4 процессора 4*28 000 000/3=37,33 МБ/сек или 26 нс.
Но еще ведь есть и видеоконтроллер который должен успевать тоже читать из памяти и не тормозить другие процы. Максимальный поток данных выводимых на монитор составляет 7000000/8*2=2,5МБ/сек в обычном режиме 256*192*1 бит на пиксель+1 байт атрибута на 64точки, 3,5мб/сек при 320*200 4 бит на пиксель, 7 МБ/сек при 320*200 8 бит на пиксель (BitPerPixel), а в перспективе есть еще и 640*480*60-75гц*8BPP а это уже не много не мало, а 25.175-31.500МБ/Сек.
За счёт увеличения разрядности памяти до 16 бит(надеюсь в ближаёшее время не потребуются 16 битные режимы при разрешении 640*480) и временем доступа к памяти равным 15нс (на которой в данный момент ставяться эксперементы) то мы получаем среднее время доступа равное 30 нс во время прорисовки основной части экрана, и 15 нс при формировании бордюра и синхроимпульсов.
Отсюда видно что в теории всё это возможно, и я буду всеми силами пытаться это реализовать (как минимум 2 проца).
2. У каждого проца должны быть свои регистры адресации памяти.
3. Необходима система разрешения конфликтов при обращении к устройствам хотябы на программном уровне.
4. Необходимо отучать софтварных программистов работать с портами ввода вывода на прямую. вся работа с устройствами ТОЛЬКО ЧЕРЕЗ СРЕДСТВА ОПЕРАЦИОННОЙ СИСТЕМЫ или, что менее предпочтительно, через драйвер, но хотя можно и в драйвер встроить функцию распределения доступа.

[Shaos]

Это не miniITX, Fatherboard - это плата процессорного блока (как правило с минимально необходимыми контроллерами) выполненная в виде ISA-платы, естественно не имеющая на себе слотов но имеющая печатный разъём которым она втыкается в кроссплату со слотами расширения, т.е. фактически это та половина Motherboard, на которой детали, а кроссплата - это та часть Motherboard, на которой только слоты. По названию - сам понимаешь чем отличается папа от мамы - кто в кого втыкается.

Не знаю в каких таких самодельщицко-кулибинских кругах эти платы называются "фазербоардами", а в промышленной автоматике они называются MicroPC (иногда Slot-PC). Аффтар в очередной раз продемонстрировал свою способность называть выдуманными именами давно существующие концепции (по причине собственного невежества надо полагать) и опять эта выдумка подаётся как единственно правильное и всем давно известное...

[Error404]

Если имеется более 1 проца, то следовательно необходимо организовывавать распределение доступа к шине.

[...расчеты вырезал... ]

вся работа с устройствами ТОЛЬКО ЧЕРЕЗ СРЕДСТВА ОПЕРАЦИОННОЙ СИСТЕМЫ или, что менее предпочтительно, через драйвер, но хотя можно и в драйвер встроить функцию распределения доступа.

Не, объясните мне - зачем городить огород? Строить SMP или NUMA (какие там еще есть умные слова? ) из того, что для этого не предназначено. Не получится. Все уйдет "в песок", т.е. такая "multyZ80" машина недопустимо много времени будет работать на свою собственную синхронизацию. А если еще учесть, что 1 Z80 одновременно все равно работает только с 64к памяти, то и вообще смысл теряется.

Сделайте лучше фабрику лезвий с одним управляющим гипервизором. Проще простого - только нужно добавить обслугу прерываний и ПДП в каждое лезвие. И алгоритм работы будет простым и понятным (каким он есть уже не один десяток лет): в зависимости от требуемого действия по доступу к внешнему устройству или другому лезвию, лезвие будет выдавать на порт (т.е. на шину которой оно включено в фабрику) запрос, который дешифруется и маршрутизируется гипервизором. Выдав запрос в очередь, лезвие продолжает трудится над своей задачкой (или ждет - смотря какой алгоритм).
- Если это запрос к внешним устройствам, подключенным к гипервизору, то он считает нужные данные, поместив их через ПДП напрямую в буфер запросившего лезвия, затем даст лезвию отмашку по прерыванию - мол, кушать подано.
- Если это запрос на доступ к памяти другого лезвия (вариант когда одна однопроцессорная плата подготавливает данные для другой, или какие-то программные каналы обмена когда софтина умеет забрать под себя более чем одно лезвие), то гипервизор провериит этот запрос на корректность (платы лезвий в зависимости от ПО, которое на них крутится могут по-разному регистрироваться в гипервизоре) и перекинет данные.
- Прочие выходы/входы типа клавиатуры или RGBI (т.е. консоль) элементарно мультиплексируются в один канал все тем же гипервизором (программно выбирается консоль одного из блэйдов - того на котором нужно сделать какие-то настройки или что-то запустить).

Это, конечно, немного медленнее, чем многопроцессорность, но зато ничего не нужно изобретать (ПДП используют уже хрен знает сколько лет), совершенно прозрачно логически - т.е. отлаживаться будет в разы быстрее, расширяемость просто на уровне дотыкания платок в слот, причем характеристики лезвий могут быть разными - хоть Ленинград1 , хоть ARM или 68k - лишь бы DMA/INT было, да софт поддерживал совместимый протокол.

[Valen]

Если имеется более 1 проца, то следовательно необходимо организовывавать распределение доступа к шине.

Я думаю, разделение одной спековской шины между несколькими
процами не есть хорошо.
Новые процессорные модули (видео, звук, вычислительный аксель)
нужно делать как полностью автономные устройства, которые общаются
через канал (напр. шину) со спековским z80.
Каждый модуль, имеет свои независимые память, шину и проц.
А также имеет набор асинхронных команд
(после выдачи команды модулю, главный z80 сразу же может выдавать
следующую команду другому модулю )

Идеология программирования такая:
передать в память модуля данные и давать команды на их обработку

Вычислительный аксель, это например 60мипсовый АРМ (10$) с метром 10нс памяти.

[Black_Cat]

4. Необходимо отучать софтварных программистов работать с портами ввода вывода на прямую. вся работа с устройствами ТОЛЬКО ЧЕРЕЗ СРЕДСТВА ОПЕРАЦИОННОЙ СИСТЕМЫ или, что менее предпочтительно, через драйвер, но хотя можно и в драйвер встроить функцию распределения доступа.

Это давно бы было, если бы задачи работали через ось. А ось не используют потому что не хватает ресурсов Спектрума. Пока не будет быстрой машины, не будут использовать и ось (разве только в системных приложениях). НО!!, боюсь что даже когда будет быстрая машина - ось всё равно не будут использовать - просто применят добавочное быстродействие для расширения возможностей. Использование оси для Спека станет нормой когда программисту скорее всего уже невозможно или очень сложно будет справиться с разросшимися аппаратными ресурсами на низком уровне.

[Error404]

Это давно бы было, если бы задачи работали через ось. А ось не используют потому что не хватает ресурсов Спектрума. Пока не будет быстрой машины, не будут использовать и ось (разве только в системных приложениях). НО!!, боюсь что даже когда будет быстрая машина - ось всё равно не будут использовать - просто применят добавочное быстродействие для расширения возможностей. Использование оси для Спека станет нормой когда программисту скорее всего уже невозможно или очень сложно будет справиться с разросшимися аппаратными ресурсами на низком уровне.

Из наиболее близких - полно CP/M (и, кстати, даже MP/M) машин с тактом камня 1...2 МГц (и даже не Z80, а слабее), которые прекрасно работали через ОС и с экраном, и с клавиатурой и с дисководом и т.д.

Работать напрямую по экрану допустимо для игр под однозадачной ОС, главное чтобы игра не порушила ядро ОС, а при выходе восстанавливала среду такой, какой она была на момент старта игры.

[Error404]

Я
Новые процессорные модули (видео, звук, вычислительный аксель)
нужно делать как полностью автономные устройства, которые общаются
через канал (напр. шину) со спековским z80.
Каждый модуль, имеет свои независимые память, шину и проц.
А также имеет набор асинхронных команд
(после выдачи команды модулю, главный z80 сразу же может выдавать
следующую команду другому модулю )

Идеология программирования такая:
передать в память модуля данные и давать команды на их обработку

О! Тоже, что и я предлагал постом выше , только это более частный случай, как мне показалось. Я сторонник равенства - при такой архитектуре любую платку можно нагрузить любой функцией - все определяет набортная математика, которая вполне может быть загружаемой через гипервизор. И любая плата может иметь доступ к любым ресурсам целой системы.

[Black_Cat]

О играх и речь - они работают на грани возможностей системы, и с добавлением быстродействия процессора добавятся и расширенные режимы экрана, которые это быстродействие съедят и всё вернётся на круги своя. А вот на счёт возвращения прежнего состояния - это наверное самый оптимальный путь, притом сделать это аппаратным методом даже лучше. Это уже обсуждалось: http://zx.pk.ru/showthread.php?t=897 .

[Valen]

О играх и речь - они работают на грани возможностей системы, и с добавлением быстродействия процессора добавятся и расширенные режимы экрана, которые это быстродействие съедят и всё вернётся на круги своя.

Эту проблему уже давным-давно решили инженеры игровых машин.
Относительно маломощный проц +
быстрый специализированный VDP (работающий паралельно с главным процом)
= хороший результат.