Soviet Union ZX Spectrum CommunityСреда, 23.08.2017, 22:34
Вы вошли как Гость | Группа "Гости" | RSS
 [ · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 11
Soviet Union ZX Spectrum Community » ZX-строительство » Железо » "ZXM-Phoenix" - что добавить или изменить? (UPGRADE)
"ZXM-Phoenix" - что добавить или изменить?
Black_CatДата: Вторник, 29.06.2010, 21:28 | Сообщение # 1
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Изначально этот топик создавался для систематизации предложений по развитию компьютера ZXM-Phoenix, как ретро платформы на дискретной логике. Но т.к. сейчас развитие ZXM-Phoenix именно в таком ключе автор уже прекратил, то я попробую этот топик переформатировать и актуализировать его просто как топик по развитию ретро платформы на дискретной логике, но с опорой на ZXM-Phoenix, как базис.

Почему в наше время тотального использования FPGA и Dvelopment board предлагается развитие платформы именно на дискретной логике? Суть обращения к дискретной логике в современных любительских компьютерах в том, что такие системы изначально обладают системообразующим свойством, в отличие от систем на FPGA, которые как правило предназначены для разработки прототипов устройств, и в силу этого принципиально не рассматриваются как устоявшиеся платформы, а только как полигоны для экспериментов. Так система на дискретной логике уже содержит в себе архитектуру устройства, в то время как в системе на FPGA архитектуру устройства определяет загружаемый конфиг. Такая некоторая эфемерность архитектуры разрабатываемых на FPGA платформ роднит их по технологии разработки и сопровождения с программным обеспечением, из-за чего многие, далёкие от современной электроники люди, даже ошибочно причисляют системы на FPGA к программным эмуляторам, что несомненно ошибочно, ибо это реальные аппаратные системы.
Недостаток систем на дискретной логике, состоящий в их очень медленном развитии, требующем множества промежуточных вариантов архитектуры, в случае любительской разработки превращается в их основное достоинство, ибо развитие программно-аппаратной платформы предполагает её поддержку программным обеспечением, а т.к. эта платформа любительская, то и программная поддержка предполагается силами любителей, а это процесс очень инерционный во времени в силу именно любительства как фактора мотивации.
Таким образом, хотя любительские системы на FPGA имеют несомненное преимущество в скорости аппаратного развития, но т.к. в целом развитие программно-аппаратной платформы определяется так же и развитием специфичного программного обеспечения под эту аппаратную платформу силами любителей, то при любительском развитии особой разницы в темпах развития между аппаратными платформами на дискретной логике и на FPGA нет. Т.е. по интегральным темпам развития для любительских систем эти платформы сопоставимы, и единственный фактор дающий некоторые преимущества FPGA платформам - экономический, т.е. такие платформы менее затратны в их аппаратном развитии. В свою очередь системы на дискретной логике обладают другим фактором, принципиально отсутствующим у систем на FPGA - ретро дизайном, что в любительских разработках зачастую является приоритетным фактором.
Таким образом, подводя итог, можно определить, что разработка любительских программно-аппаратных систем небольшой сложности (до сотни корпусов на плате) на дискретной логике вполне оправдана, и сопоставима по интегральным темпам развития с аналогами на FPGA, а для более сложных систем выбор FPGA более целесообразен исходя из экономических соображений.

Как дальше развивать платформу ZXM-Phoenix?

1. Реализовать стандарт шины NemoBus v.1.2.
2. Реализовать на материнской плате базовые элементы архитектуры "Хiмеra".
3. Предусмотреть возможность расширения архитектуры компьютера, в т.ч. посредством установки доп. платы расширения на краевой разъём.
4. Расширить память до 4Mb.
5. Интегрировать расширенные видеорежимы:
- Timex: 512x192, MultiColor;
- TXT32x24, TXT64x24, TXT80x30;


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
Black_CatДата: Вторник, 17.03.2015, 20:15 | Сообщение # 2
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
1. Модернизация архитектуры ZXM-Phoenix для поддержки стандарта шины NemoBus v.1.2.

1.1 Сигнал CLK шины NemoBus v.1.2.

Реализуется на DD76.1, R78, L2. Позволяет с шины останавливаь процессор тактовой частотой.

1.2 Сигнал OW\BUSAK шины NemoBus v.1.2.

Позволяет внешним устройствам установленным в master-слот или краевой разъём с шины открывать любое окно для проецирования в него страниц памяти. Реализуется на R87 и DD62.3.

1.3 Сигналы RD\IORD, WR\IOWR, RFSH\MRW, HALT\TC шины NemoBus v.1.2.

Позволяют внешнему контроллеру ПДП в режиме захвата шины осуществлять пересылки RAM-RAM, RAM-I/O, I/O-RAM, I/O-I/O. Сигналы RD\IORD, WR\IOWR, RFSH\MRW в режиме захвата шины позволяют открывать одновременно доступ к памяти и портам ВВ для пересылок между ними при ПДП по запросу, при этом сами сигналы запроса ПДП подаются через дополнительную внешнюю шину. Реализуется на DD74. Сигнал HALT\TC в режиме захвата шины индицирует внешнему устройству конец цикла пересылки ПДП. Реализуется на DD77.2 DD78.2.

1.4 Сигнал ENDA\RS.

При обращении к ОЗУ, показывает устройству на шине, к каким адресам памяти идёт обращение - до 1Mb (ENDA\RS=0), или выше(ENDA\RS=1), т.к. устройства на шине, не использующие сигналы разъёма XP23 могут адресовать память только до 1Mb. При обращении к ПЗУ соответствует адресной линии A14". Реализуется на DD77.1, DD78.1, DD87.1.



Добавлено (17.03.2015, 20:15)
---------------------------------------------
2. Модернизация архитектуры ZXM-Phoenix до архитектуры "Хiмеra".

Архитектура Хiмеra определяет единствнно возможный путь развития компьютера ZX Spectrum, обеспечивающий возможность использования существующего ПО без необходимости его переделки, и без потери качества (т.е. исполнение аутентично оригиналу) под управлнием ОС.
Работа под ОС достигается инкапсулированием задачи (нативной программы) в аппаратно-программную виртуальную машину (АПВМ), под которую выделяется аппаратная архитектура ZX Spectrum или его клона, а так же ограниченная аппаратно память и УВВ. АПВМ работают в аппаратно выделенной им памяти и понятия не имеют, что за её пределами ещё что-то есть, т.к. физически не могут выйти за её пределы. АПВМ работают в режиме разделения времени, т.е. каждая АПВМ во время своего исполнения занимает всё процессорное время единственного процессора и выделенные ей УВВ. Благодаря этому нет тормозов обусловленных работой под ОС. ОС в архитектуре Хiмеra - это фактически такая же АПВМ, только с доступом ко всем ресурсам сразу, без ограничения памяти и УВВ, в задачи которой входит загрузка с внешних носителей ПО в отдельные АПВМ и выделения им ресурсов. Переключение между АПВМ осуществляется либо вручную, либо автоматически по таймеру с учётом приоритета исполняющихся АПВМ.
Ниже приведен упрощённый пример схемы модернизации архитектуры ZXM-Phoenix до архитектуры Хiмеra, реализующий пользовательский режим вытесняющей многозадачности, и позволяющий осуществлять переключение между АПВМ в ручном режиме.

2.1 Описание схемы.

По аппаратному сбросу или по нажатию специальной кнопки "NMI" на клавиатуре, в момент чтения КОПа из ОЗУ, инициируется режим ядра (реализуется на DD79.2 DD50.2). В этом режиме в окно CPU0 принудительно устанавливается страница ROM0 ПЗУ, вне зависимости от состояния портов управления страницами ПЗУ (реализуется на DD9.3, VD24-VD26, R89-R91), устанавливается комбинация сигналов DOS/=0, IODOS/=0, индицируящая режим KERNEL, и запрещающая внешним устройствам открывать любое окно для проецирования в него страниц памяти (реализуется на DD76,2, DD79.4), так же блокируется сигнал CSROM/, тем самым запрещая внешним устройствам захватывать окно CPU0 (реализуется на DD79.3).

В режиме ядра по сбросу, управление передаётся в BIOS, инициируя либо загрузку ОС, либо, при отсутствии ОС выход в менеджер загрузок BIOS, откуда можно в ручном режиме сконфигурировать и загрузить ПО в АПВМ, и затем передать ей управление перейдя из режима ядра в режим АПВМ. При этом состояние системных портов компьютера и регистров процессора определяющих состояние режима ядра сохраняется в системной области по адресам #8000-#803f.
Для переключения между ядром и программами загруженными в разные АПВМ, в ручном режиме предназначена кнопка "NMI" на клавиатуре. При её нажатии во время исполнения АПВМ, происходит выход в режим ядра с генерацией NMI, после чего обработчик NMI BIOS'а сохраняет состояние регистров процессора и системных портов АПВМ в системную область памяти предназначенную для хранения состояния АПВМ, и располагающуюся по адресам #8040-#bfff. В этой области для каждой АПВМ зарезервировано 64 байта описывающих её состояние, т.е. в системной области могут храниться данные ядра и 255 АПВМ. Размер ОЗУ, выделенного каждой АПВМ дискретен, и может быть равен 16kb, 48kb, 128kb, 256kb, 512kb, 1Mb, 2Mb, и задаётся портом маски адреса АПВМ #6DF7, доступным только из режима ядра (реализуется на DD81, DD85). Т.к. максимальный размер ОЗУ АПВМ составляет 2Mb, то старший разряд порта маски адреса для любой АПВМ всегда равен единице, и только в режиме ядра обнуляется, это используется для блокировки возможности установки в окно CPU0 ОЗУ при переходе из режима АПВМ в режим ядра. В режиме ядра, для получения программного доступа к порту включения ОЗУ в окно CPU0, необходимо сбросить старший разряд порта маски адреса АПВМ #6DF7 (реализуется на DD79.1, DD76.1). Расположение каждой АПВМ в ОЗУ компьютера задаётся портом адреса АПВМ #6FF7, доступным только из режима ядра (реализуется на DD80). Установка разрядов порта маски адреса АПВМ #6DF7 в единицу позволяет подменить соответствующие им разряды портов адреса страницы памяти на соответствующие значения разрядов порта адреса АПВМ #6FF7, тем самым аппаратно ограничивая доступное АПВМ адресное пространство и позиционируя АПВМ в ОЗУ компьютера (реализуется на DD82, DD83 и R79-R85, R106). Отключение аппаратного ограничения на доступное адресное пространство, а так же отключение позиционирования АПВМ в ОЗУ компьютера при выходе в режим ядра реализовано на VD33-VD40 и R99-R105, R108. Адрес экранной области ОЗУ АПВМ задаётся сигналами VM14-VM21 (реализуется на DD77.3, VD27-VD32, VD43, R10, R93-R98, R107).
Прикрепления: 6679257.png(375Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
Soviet Union ZX Spectrum Community » ZX-строительство » Железо » "ZXM-Phoenix" - что добавить или изменить? (UPGRADE)
Страница 1 из 11
Поиск:

Copyright MyCorp © 2006Сайт управляется системой uCoz