Если что-=то менять, то почему бы не сделать загружаемый знакогенератор - заменить рф2 на ру10. Ну, конечно схему загрузки добавить. ру10 вроде тогда уже делали.

схема "загружалки" будет очень немаленькая.

гараздо проще применить скажем 27256 и набить её знакогенераторами на полную фантазию а потом переключать дип свичами.
кстати, думаю, фантазия закончится быстрее чем ПЗУ.

Придется ставить дополнительную ПЗУ на 4 Кб, так как основная ПЗУ всего 2 Кб и занята полностью. А раз такое дело, то лучше сделать триггер, который бы переключал в качестве знакогенератора ОЗУ<->ПЗУ. То есть, параллельно ПЗУ припаять ОЗУ и переключать их CS-входы.

В видеоадаптере Микро-80 применены микросхемы РУ2 объемом 1 КБит. Вот их и надо применять. Нам потребуется 6x3 Килобита под знакогенератор 256*6*10. Это уже 18 редких микросхем + дешифратор адреса (155ИД4).

Это уже слишком много, что бы это делать.

А далее, нам нужно только 5 корпусов. Несколько корпусов (155ЛН1, 155ЛА7), которые будут при обращении к адресам F000-F005 подавать сигнал записи на РУ2. Если мы заполним видеопамять идентичными значениями, то на 8 адресных линиях РУ2 будет всегда нужное значение. На остальные 4 линии адреса ставим мультиплексор (2x155ЛР1 + 155ЛН1) к которому подключаем шину адреса процессора.

И вот такой способ записи:

void setChar(byte charCode, byte* charData) {
``for(i=0; i<2048; i++)
````memory[0xE000+i] = charCode;
``for(i=0; i<6; i++)
````memory[0xF000+i] = charData[i];
}

Можно конечно мультиплексор поставить на все линии адреса, но для этого потребуется еще 4 корпуса 155ЛР1. И еще триггер, что бы сделать возможность отключения знакогенератора от ценного адресного пространства.

Короче, дохрена микросхем. Легче тогда выкинуть знакогенератор вообще и сделать полноценный граф режим. Получится что то похожее на Специалист.

Можно обойтись и меньшим количеством микросхем, если сделать порт F000 так, чтобы при чтении из него выдавались младшие биты адреса знакогенератора, а при записи - записывался бы байт по текущему адресу в знакогенератор. Процедура записи ОЗУ знакогенератора должна будет подождать нужный адрес и сразу записать байт (64мкс будет достаточно). Заполнив экран особым образом можно ускорить загрузку знакогенератора. Итого - пара шинных формирователей для чтения/записи порта и немного логики.

---------- Post added at 15:23 ---------- Previous post was at 15:16 ----------

В качестве шинных формирователей можно использовать две 589АП16.

два момента:

загружаемый ЗГ не позволит организовать к-либо отладку до его загрузки, что иногда критично.

полный граф режим весьма "неспешен" в скролировании текста, кто пускал NC на "происке" тот в цирке не смеётся.
разумнее былоб сразу продумать и вывести соответсвующие сигналы видео модуля для возможности подключения дополнительного графического ОЗУ, получив таким образм полноценную текстовую моду и накладывающуюся на неё графическую.

Я и предлагал параллельно ПЗУ знакогенератора добавить ОЗУ. Когда потребуется свой знакогенератор, то мы просто отключим ПЗУ.

Если так дальше развивать идею, то у нас получится MSX без спрайтов. То есть видеоадаптер ПК80xx. :) А потом добавим 4 цвета на символ и скроллы и получится NES без спрайтов.

Я бы делал, но не буду, аппаратное копирование изображений 8x8 с учетом прозрачности. Процессор бы отправлял три значения: номер спрайта, X, Y. Если сделать отдельную видеопамять, то вывод спрайта займет 64 такта, что при скорости в 8 Мгц равно скорости выполнение нескольких команд процессора 8080. За это время он как раз успеет загрузить следующие N,X,Y. Схема громоздка, но проста как валенок.

Это уже было бы похоже на MSX2

Был такой комп ПК8002, так там и спрайты были, на рассыпухе. И схема не такая уж громоздкая была, одноплатный, в корпусе Корвета.

imho спрайты нужны для портирования мегаигр, но зачем портировать с MSX или NES если проще использовать оригинал?

а вот для написания программ на бейсике текст и графика будут очень кстати.

Еще один вариант компьютера:

Процессор 580ВМ80
ПЗУ 27256
ОЗУ 62256
580ВВ55 для клавиатуры, магнитофона.
Видеоадаптер на одном корпусе ATMega (http://www.tinyvga.com/avr-vga)
И еще 4 корпуса примитивной логики и получится компьютер.

:)

Компьютер-то получится, но какой интерес в такой конструкции?
Мало корпусов? Да пробегала ссылка на комп на одном корпусе Атмеги - с клавиатурой, вывод на ВГА монитор, загрузкой программ и встроенным бейсиком - всё это на одной микросхеме.
Мне вот интересно даже не старые компы, какими они были, а какими они могли бы быть. Если бы меня сегодняшнего закинуть в те времена, как бы я сделал?

вот почитал интересное сообщение:
http://www.zx.pk.ru/showpost.php?p=429802&postcount=5
"Можно пойти дальше, и предположить, что процессор хочет данные всегда, когда Ф2 0=>1 (для Z80 надо бандить на оба перепада). Для надежной работы ВМ80 можно просто выделить квант времени от Ф1 до Ф2 (одна четверть такта Ф2):
Код:
F1- _________---_________---_________---
F2- ------______------______------______
ARB |CPU| |CPU|
И в этот квант полностью предоставлять память процессору (сигнал записи маскировать им же). И тогда 3/4 оставшегося времени использовать память по своему усмотрению."
Тоесть если 1/3 времени предоставить одному процессору, то в оставшиеся 3/4 времени к памяти успеют обратится ещё 3 процессора?
Правильно ли я понял, что если тактовые сигналы нескольких вм80 сдвинуть относительно друг друга, то 4 процессора смогут работать с общей памятью?
Тогда 1 процессор сможет выводить видео, другой звук в нормальном качестве,
третий подсасывает в это же время новые данные с диска\карточки памяти, и четвертый всем этим управляет.
Такая вот колхозная Амига на вм80.
Или может не стоит городить такие огороды, а вместо 4-х двухмегагерцовых процессоров взять один 8-ми мегагерцовый и будет тоже самое?

если в слове хлеб сделать 4 ошибки то получится "пиво"

а если 580вм80 поменять на 6502 - Apple I

;)

У атмег мало оперативной памяти и программы хранящиеся в оперативной памяти выполнять нельзя, поэтому хреновый компьютер.

А интерес в этом компьютере такой, что на нем можно CP/M запустить.

смогут, но не долго, как три хозяйки на одной кухне

в любом случае они будут ждать друг друга (подгрузка данных, окончание операции видеовывода etc) а системма семафоров сведет с ума любого програмиста. или надо будет писать реентерабельный код, что опять таки доплнительно сожрет и так не густую оперативу.

Только кто программы писать будет под четырехпроцессорный компьютер?

выполнение различных команд происходит за различное время в течении от 1 до 5 машинных циклов.

в любом случае у вас между процами произойдет рассинхрон (практически сразу) и о безветовости можно забыть.

А идея использовать ATMega в качестве видеоадаптера прекрасна как оргазм. :)

Четыре процесоора на 64Кб памяти это, конечно не то. К каждому из 4-х процессоров добавляем регистр 8-ми разрядный для номера текущего сегмента, в котором работает данный проц. При обращение проца к памяти к старшим адресам подключается этот (для каждого из процессоров свой) регистр. Итого 16+8 линий адреса адресуют 16Мб памяти. При таком запасе памяти ожиданий будет минимум. Можно заранее всего назагружать, потом переключать страницы.

Будет работать. Здесь имеется ввиду следующее. Процессору данные на входе нужны только в момент спада тактового импульса. Вот и предлагается память подключать не на весь такт, а только на четверть такта.

Процессоры вообще мешать друг другу не будут. Просто память будет в 4 раза быстрее шевелиться.

Зачем синхрон потактовый тут нужен? Центральный проц дает задание процу ввода вывода загрузить массив с музыкой в такой-то сегмент. Пока идет загрузка муз проц не отвлекается, доигрывает старую мелодию. Потом центральный проц запускает в этот сегмент проц музыки и тот играет заданный отрывок - один раз или в цикле.

---------- Post added at 00:20 ---------- Previous post was at 00:09 ----------

Подумал - 4 двухмегагерцовых будет круче намного , чем 8-ми мегагерцовый проц.
Так как в четыре раза будет больше внутренних регистров - 4 программных счетчика, 4 аккумулятора и тд.
Эх, концепции, концепции, ... вот сделал бы кто...
Ну пусть даже просто нарисует схемку, я бы спаял...

идея понятна, но вот насчет реализации есть сомнения.

---------- Post added at 22:26 ---------- Previous post was at 22:21 ----------

это только в случае с музыкой

в случае с дисковым вводом/выводом надо ждать ответ окончания операции на предмет проверки не произошло ли ошибок
любые серьезные операции будут иметь остановки где главный проц будет ждать ответ периферийного
в такой ситуации смысл многопроцессорности теряется

---------- Post added at 23:27 ---------- Previous post was at 22:26 ----------

это все очень интересно при реальной многозадачности

может у меня не очень с фантазией, но приведите пример как бы Вы видели несколько задач на 86РК и главное - каких ?

Рассчитывал я уже арбитра на соседнем форуме.

Первые наброски по подключению 4х КР580ВМ80А к одной шинке. Все ресурсы могут быть расшарены, если всю шину адреса замультиплексировать. Итак, схема:
http://savepic.su/616808.png
Входящая тактовая частота - 10МГц. Это позволяет формировать F2 на частоте 2,5МГц - проверенная хорошая частота для ВМ80. Таймслот получается равен одному периоду частоты 10МГц, или 100нс, что не так и мало и можно использовать достаточно медленные ОЗУ (не забываем задержки на установку адреса в мультиплексорах и т.д.). 2 триггера образуют счетчик на 4 положения. Результирующие сигналы 5М и 2М являются одновременно и сигналом номера активного процессора (0..3), который следует подавать на мультиплексор адреса. Сам мультиплексор можно собрать из 8 микросхем 555КП2 (в одном корпусе 2 мультиплексора, а надо коммутировать 16 линий). Сигнал F1 каждого процессора можно (и даже нужно) использовать как гейт для сигналов RD/WR этого же процессора. Или так же тупо поставить еще один корпус 555КП2. Всего получилось 4 корпуса следующего комплекта: 555ТМ2, 555ЛП5, 555ЛН1 и 555ЛИ1. Если высоковольные буферы имеют инверсию (ЛА8, к примеру), тогда 555ЛИ1 меняется на 555ЛА3, а в наборе сигналов F2 нужно просто сменить местами F2_1 с F2_3 и F2_2 с F2_4. А теперь эпюры:
http://savepic.su/635240.png

А что касается:
Так вот, реализация, как говорится, реализована и показала себя только с лучшей стороны. Железный пример: Специалист МХ2.

1,Вывод звука
2,Вывод видео
3,Подгрузка новых данных с флешки
4,Главный процессор
Без лишней заумной многозадачности - например в General Sound стоит свой процессор , и спек с подключенным General Sound это как бы двухпроцессорная система . Просто каждый проц занимается своим делом. Но память у них общая и можно в принципе "тяжелые" вычислительные задачи разделить между всеми процессорами.

Ну тогда у нас любой компьютер к которому подключен IDE винчестер - тоже многопроцессорная машина. Не совсем корректный пример. :)

Постоянно читаю этот топик. Интересно. Но с мультипроцессорностью, в применении к РК-86 (и аналогичных), мне кажется перебор. Если только ради спортивного интереса, но опять же не для этих машин. Делать что-то другое - своё.
Ещё один момент, о нём уже упоминали, это софт. Для подобных платформ задача не такая уж и тривиальная, она в теории ничего, а как дойдёт до практики, то... скорее всего ограничится одним двумя приложениями, и на полку.

HardWareMan, Ну вот, оказывается всё давно уже придумано. ;)))
В принципе можно собирать , для начала 2 прца в связку - основной проц + видео проц. Только надо придумать как конкретно будет работать процессор видео - просто заменять мелкую логику или...

---------- Post added at 11:38 ---------- Previous post was at 11:33 ----------

Нет тут мультипроцессорности настоящей - одна задача не распараллеливается на несколько процессоров. По сути это компьютер с одним центральным процессором, и с процессорами, выполняющими роль контроллеров звука, видео и ввода-вывода. Так что аналогия с General Sound здесь самое то.

А какой тогда смысл делать общую память, да ещё супер-сегментированую? Понятно , что общая память должна быть, но не вся. В противном случае надо будет очень сильно помудрить с диспетчером памяти. У каждого контроллера есть чётко описанный "круг задач", и особого смысла в доступе ко всей памяти не вижу, за некоторыми исключениями. Достаточно для обмена одного "окна".

Процесору ввода- вывода нужна вся память - данные надо везде загружать, центральному процу тоже. Чтобы не ограничивать количество подгруженных данных для последующего вывода звука и видео остальным процессорам тоже полезна возможность доступа ко всей 16Мб памяти

А лично мне, установка второго проца в тот же Специалист интересна другим. Это же реальный аппаратный отладчик на реальном процессоре и с отладкой на самом же устройстве! Один супервизор, крутит программу отладки и все такое, второй ведомый, управляющие сигналы которого (WAIT, RESET и т.д.) заведены на порт супервизора и могут быть управляемы в любое время. Останется только считывать текущий адрес и данные ведомого и все. Ну а житаг можно сэмулировать прерыванием, которое вызывать четко каждую команду. А так как подтверждение прерывания - то же машинные циклы, то супервизор может кормить ведомому процессору сразу нужные команды через (специальный регистр) и тем самым не занимать прерыванием рабочее ОЗУ (если от прерывания нужно только дампить регистры то программка может быть всего несколько байт).

HardWareMan, я ж не спрашиваю как ращепить тактовую на 4 фазы, я спрашиваю как потом сигналы обращения к памяти и периферии от процов собирать в одну кучу.

на всякий случай: время выборки современной фиолетки ~200 нс, флешки <100 нс, вашей любимой РФ1 > 400 нс.

Вот к этому:
я и веду.
Для каждого процессора придётся городить свой диспетчер памяти. А учитывая, что система должна быть достаточно гибкой, этот узел (для каждого ЦПУ свой) будет весьма не маленький. Потом все они должны работать более-менее согласованно, каждый должен знать с каким куском памяти ему работать. И подобных моментов, если подумать, можно ещё энное количество насобирать.

В моем варианте получилось 100нс/временной слот. Адреса и данные мультиплексировать. Можно сделать шину с Z, адреса и данные конкретного процессора подключать к ней только на время слота обращения конкретного номера процессора (и его фазы). Тогда весь этот ваш т.н. "арбитр" сведется к обычным буферам, которые и так ставить надо. При этом можно собрать плату первого процессора, а потом добавить второй и остальные по мере изготовления. И можно будет взаимозаменять их.

Про программное разруливание я ничего не говорю. Тут нужна сложная программа. При этом, нужно делать либо жестко одного супервизора, стартующего первым, и подчиненных, которые могут быть включены-выключены супервизором. А можно, как уже тут предлагалось, встроить в каждый отдельный процессор один уникальный порт с его номером и пользовать общую программу, которая ветвит действия согласно номеру процессора. Тогда каждый процессор будет работать всегда и автономно, не завися от супервизора.

Я считаю так. Все реально и не сильно большой кровью. Нужно, либо делать, либо трепаться дальше и не делать. Выбор за вами.

PS А с чего это вдруг РФ1 моя любимая микросхема? Я люблю буржуйские флешки и статическое ОЗУ большого обьема.

с большИм удовольствием понаблюдаю за развитием темы, хотя бы теоретическом...

Предлагаю не усложнять. После сброса каждый проц стартует и программно крутится каждый в своём "биосе" - программе в ПЗУ (физически это может быть одна на всех микросхема ПЗУ)
Можно усложнить - центральный проц загружает "биосы" остальных процев и после этого запускает их.

Может быть чтобы както приблизится к реальности и обкатать идеи сделать для начала на этой архитектуре , например, Орион с General Sound и загрузкой с флешки?

Если процессоры работают с разными адресными пространствами, то это уже не многопоточность, а просто несколько процессоров. Это что то типа УНКЦ получается.

А прикиньте, четырехпроцессорный ZX Spectrum. Каждый процессор будет отрисовывать свою часть экрана. Вот это вещь.

да, к стати, почему бы не придумать нормальный аппаратный курсор?

схема дешифрации, два регистра, три искл-или, две больших И, всё...

в добавок остается 5 (2+3) бит на разное управление, например для переключения знакогенераторов.

Можно поставить три-четыре ИЕ7. Загрузка значения в счетчики из регистров будет происходить по сигналу КСИ. При выводе очередного символа, будем уменьшать счетчик. Выход переполнения счетчика и будет сигналом для вывода курсора.

И еще можно упростить. Добавить RS-триггер, блокирующий уменьшение счетчиков с момента записи в них значения и до КСИ. Тогда регистры не нужны. Записывать в них значение можно прямо с шины.

Итого 3-4 шт ИЕ7, дешифратор адресов подающий сигнал загрузки в счетчики и на отображение курсора один ИСКЛ ИЛИ.

но тогда положение курсора надо будет каждый полукадр записывать по прерыванию от КСИ

За кадр счетчики должны сделать полный круг и вернуться в исходного состояние.

по количеству монтажа такое решение однозначно выиграет, но все логики я до конца себе еще не представляю.

Вроде подобная схема наложения спрайтов была в TIA Atari 2600. Только там оси Y не было, программист должен был перед выводом каждой строки информацию о спрайтах заносить.