nedoPC.org

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

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

Здесь получается некоторый парадокс, так как периферийный процессор имеет больше возможностей, чем основной.
Например, основной процессор считывает порт клавиатуры. А на самом деле порт - отдельное теневое ОЗУ. И код клавиши моментально считывает из теневого ОЗУ, а периферийный процессор получает прерывание и адрес порта, который прочитал основной.
Тем самым, у основного порты - чисто виртуальные.

P.S.: Жаль, что Windows тупо запретила приложениям доступ к портам.
Хотя могла бы синтезировать им особую карту портов (где нет ПДП или SoundBlaster, а есть DirectInput/DirectShow/OpenAL/OpenGL и почта (думаешь, что читаешь порт, а на самом деле читаешь почту) без всяких вызовов Win-API). То есть, OS - виртуальное железо, а не склад библиотек работы с реальным железом, как тот же GDI…

Вот с портами я с появлением Windows долго мучался и должен сказать, что это не совсем так.
Windows не любит, когда лезут напрямую к портам, о которых она знает, которые она обслуживает
сама, поскольку тут может быть между приложениями конфликт доступа к портам.
Windows 3.х, Windows 95, Windows 98, Windows ME и даже Windows XP работать с портами напрямую
(через DLL) хоть и мешают, но не сильно (Windows XP - чуть строже).
А вот более старшие версии - там всё более затруднено причем специально.
Но если на шину повесить своё устройство по незанятым адресам, то Windows сильно мешать не сумеет,
она не знает - что это и как мешать.
Другое дело, что так повесить своё устройство на шину PCI тоже довольно проблематично.
Ну тут трудно сказать что-то против: система многозадачная многопользовательская с разделением аппаратных
ресурсов между задачами - она должна уметь поддерживать себя от краха.

A в том и суть, что, например, перехватывать системой все порты и заменить портовое пространство своим.
Например, вот порт клавиатуры 0x60. Для драйвера - да. А вот для приложения - абсолютно виртуальный порт, например, чтения событий, как GetMessage.
Или GetActiveWindow - порт 0x61 на чтение, например, и на запись - SetActiveWindow.
Или те же GDI SelectObject - запись в порт 0x62.
Ну, как уже, надеюсь, понятно, с реальными портами ничего общего. Какой бы порт приложение ни читало, Система либо вернёт значение фиксированной функции, либо рандом, не генерируя исключения, если порт не в списке Системы.
То есть, вместо справочника по API был бы справочник по портам Windows.

Плюсы есть?
Допустим, запускаем app.com (не exe) и изначально программа считается как под DOS.
И под это дело эмулировались реальный порты.
Но стоит в особый порт записать особое значение, как эмуляция портов отключается вместо с VDM, а Система открывает программе свои порты. И никаких DLL подгружать не надо. Только через порты строишь граф библиотек и Система сама всё делает.
Например, строишь граф «port 123 --> irc://chat.com/#main» и при выводе в порт №123 всё отправляется на канал чата…
Получаем «Облачный Компьютер», где через манипуляцию портами можно хоть связями между серверами манипулировать…
В худшем случае из порта, например, 255 будем читать код ошибки 404.
Никаких исключений.
Свобода - как в эпоху DOS. Только вместо примитивных портов CGA/EGA/VGA/SoundBlaster - порты OpenAL/OpenGL/DirectPlay/DirectShow и т.д.

Это я к чему.
По-идее, на базе i8080/z80 можно сделать так, чтобы сервисный процессор занимался железом и базовыми функциями.
А вот основной процессор, скажем, для построения линии, мог бы просто в порты отправить x1,y1,x2,y2 и код цвета, чтобы сервисный процессор уже сам возился с пикселями, страницами памяти и палитрой.

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

Я прокомментировал только вот эту фразу:

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

Этo я понял и вижу, что меня не допоняли.

Под "корректным доступом" имеется совсем не то, что я имею ввиду.
Да, есть приложения, где любители стряпают свои девайсы и пробивают доступ к ним по портам. Как раз я - не об этом!

Подойдём с другого края.
Если бы в эпоху DOS имелся бы защищённый режим, то вместо прерывания «int 21» с кодом подфункций в «ah» можно было бы ввести виртуальные порты с кодом в «dh»…
Например, вместо:с вызовами функций можно было бы писать так:Где проецировать API-DOS в память приложения не нужно вообще.
Просто "программируешь порты DOS" и покидаешь код через hlt.
Вот здесь я развернул шире этот вопрос…

P.S.: Как-то раз я сделал эмулятор i8086, который эмулировал только набор инструкций именно i8086, но рисовал OpenGL-сферы именно через записи в порт. При этом сама *.com-программа весила менее 100 байтов…
То есть, я провёл опыт. какой могла быть среда DOS, если бы у i8086 имелся бы защищённый режим и виртуальные порты.

Я почитывал про эту самую УКНЦ и схему её рассматривал... мутно как-то они там сделали...

Но пришла мне в голову совсем не по поводу УКНЦ мысль одна очень интересная - а что если
связку процессоров по типу ведущий-ведомый организовать следующим образом:
У ведомого (пусть он и будет для графики) есть своя память и Видео-ОЗУ.
В пространстве памяти также есть регистры или общая память, в которые может сделать запись
ведущий процессор.

При старте ведомый процессор очищает Видео-ОЗУ, выводит начальную информацию и замирает по HALT.

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

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

В принципе можно и операции ввода-вывода так назначить...

"Истра-4816" имела три процессора на борту, ВМ86 и два ВМ80. Один ВМ80 обслуживал периферию, второй и ВМ86 - работали параллельно как ЦП. Схемы мне найти не удалось, только плата где-то в железках лежит.

Попадалось мне где-то на форумах упоминание о ней в таком контексте...
Но там, где попадалось, о ней упоминали именно в таком контексте: а как она это делала?
Схем также не нашли...

В начале 90х у нас в институте всё ещё стояли большие шкафы всяких "Малых ЭВМ" и у одного был выдвинут ящик где я разглядел 580ВМ80А, использованный в качестве периферийного процессора - после этого мир в моих глазах стал иным...

Тебя постигло чувство горького разочарования в "Малых ЭВМ" ?

Не - понимание того, что крутость только что изученного ВМ80 в данном случае тратилась на управление тупой периферией

Кстати, да - это было обидно... ВМ80 много где совали на обслуживание периферии...

Пока я разными способами ворошил в поисковиках CRISS CP/M computer, попался вот такой интересный материал:

Самодельный ноутбук ZedRipper на шестнадцати Z80

Что-то мне кажется, что основная идея этого монстра о 16-ти процессорах z80, практически такая же,
как у Пропеллера...https://habr.com/ru/post/159847/