|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
nedoPC-580 (SMP на 5 процессорах КР580ВМ80А)
Author |
Message |
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Кстати говоря, заметно повысить быстродействие на определённом классе задач можно всего с двумя процессорами, на мой взгляд. Если один из них будет делать расчеты, а второй - отрисовывать по ним графику. Но в этом случае второй процессор должен быть, скорее всего специфический...
_________________ iLavr
|
24 Aug 2019 10:35 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Oб этом я задумывался как-то в 90-х, чтобы виртуализировать порты ввода-вывода. Периферийный процессор делает всю грязную работу по опросу клавиатуры, настройке ПДП и прерываний, переключение страниц памяти с их подменой и т.д… А основной процессор полностью управляет периферийным, но находится в инкапсуляции.
Здесь получается некоторый парадокс, так как периферийный процессор имеет больше возможностей, чем основной. Например, основной процессор считывает порт клавиатуры. А на самом деле порт - отдельное теневое ОЗУ. И код клавиши моментально считывает из теневого ОЗУ, а периферийный процессор получает прерывание и адрес порта, который прочитал основной. Тем самым, у основного порты - чисто виртуальные.
P.S.: Жаль, что Windows тупо запретила приложениям доступ к портам. Хотя могла бы синтезировать им особую карту портов (где нет ПДП или SoundBlaster, а есть DirectInput/DirectShow/OpenAL/OpenGL и почта (думаешь, что читаешь порт, а на самом деле читаешь почту) без всяких вызовов Win-API). То есть, OS - виртуальное железо, а не склад библиотек работы с реальным железом, как тот же GDI…
|
31 Oct 2019 01:22 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Вот с портами я с появлением Windows долго мучался и должен сказать, что это не совсем так. Windows не любит, когда лезут напрямую к портам, о которых она знает, которые она обслуживает сама, поскольку тут может быть между приложениями конфликт доступа к портам. Windows 3.х, Windows 95, Windows 98, Windows ME и даже Windows XP работать с портами напрямую (через DLL) хоть и мешают, но не сильно (Windows XP - чуть строже). А вот более старшие версии - там всё более затруднено причем специально. Но если на шину повесить своё устройство по незанятым адресам, то Windows сильно мешать не сумеет, она не знает - что это и как мешать. Другое дело, что так повесить своё устройство на шину PCI тоже довольно проблематично. Ну тут трудно сказать что-то против: система многозадачная многопользовательская с разделением аппаратных ресурсов между задачами - она должна уметь поддерживать себя от краха.
_________________ iLavr
|
31 Oct 2019 01:44 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
| | | | Lavr wrote: Вот с портами я с появлением 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 и код цвета, чтобы сервисный процессор уже сам возился с пикселями, страницами памяти и палитрой. То есть, если делать компьютер с уймой процессоров, то пусть функционал каждого будет продуман до уровня сетевого сервера, чтобы приложение через порты не пыталось программировать железо, а строило графы взаимодействия между процессорами на самом высоком уровне.
|
31 Oct 2019 04:13 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Я прокомментировал только вот эту фразу: Нельзя сказать, что Windows так уж тупо запретила приложениям доступ к портам. Просто доступ должен быть корректным с точки зрения используемой версии Windows.
_________________ iLavr
|
31 Oct 2019 05:03 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Этo я понял и вижу, что меня не допоняли. Под "корректным доступом" имеется совсем не то, что я имею ввиду. Да, есть приложения, где любители стряпают свои девайсы и пробивают доступ к ним по портам. Как раз я - не об этом! Подойдём с другого края. Если бы в эпоху DOS имелся бы защищённый режим, то вместо прерывания «int 21» с кодом подфункций в «ah» можно было бы ввести виртуальные порты с кодом в «dh»… Например, вместо: с вызовами функций можно было бы писать так: Где проецировать API-DOS в память приложения не нужно вообще. Просто "программируешь порты DOS" и покидаешь код через hlt. Вот здесь я развернул шире этот вопрос… P.S.: Как-то раз я сделал эмулятор i8086, который эмулировал только набор инструкций именно i8086, но рисовал OpenGL-сферы именно через записи в порт. При этом сама *.com-программа весила менее 100 байтов… То есть, я провёл опыт. какой могла быть среда DOS, если бы у i8086 имелся бы защищённый режим и виртуальные порты.
|
31 Oct 2019 18:55 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Я почитывал про эту самую УКНЦ и схему её рассматривал... мутно как-то они там сделали... Но пришла мне в голову совсем не по поводу УКНЦ мысль одна очень интересная - а что если связку процессоров по типу ведущий-ведомый организовать следующим образом: У ведомого (пусть он и будет для графики) есть своя память и Видео-ОЗУ. В пространстве памяти также есть регистры или общая память, в которые может сделать запись ведущий процессор. При старте ведомый процессор очищает Видео-ОЗУ, выводит начальную информацию и замирает по HALT. Ведущий процессор имеет свою область памяти и Видео-ОЗУ ему не доступно. Когда надо что-то вывести на экран, ведущий процессор записывает параметры в те самые регистры, ну или в какую-то общую для обоих область памяти выставляет нужный номер прерывания для ведомого и даёт ему сигнал прерывания, а сам работает дальше. Ведомый процессор в это время по своим программам выполняет то, что положено для этого прерывания, с заданными параметрами: рисует линию, рисует прямоугольник, рисует круг(элипс), т.е. номер прерывания определяет какую графическую операцию он должен выполнить. В принципе можно и операции ввода-вывода так назначить...
_________________ iLavr
|
16 Jan 2020 09:27 |
|
|
VituZz
God
Joined: 13 Nov 2010 04:06 Posts: 1345
|
"Истра-4816" имела три процессора на борту, ВМ86 и два ВМ80. Один ВМ80 обслуживал периферию, второй и ВМ86 - работали параллельно как ЦП. Схемы мне найти не удалось, только плата где-то в железках лежит.
|
19 Jan 2020 08:57 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Попадалось мне где-то на форумах упоминание о ней в таком контексте... Но там, где попадалось, о ней упоминали именно в таком контексте: а как она это делала?Схем также не нашли...
_________________ iLavr
|
19 Jan 2020 20:17 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22730 Location: Silicon Valley
|
В начале 90х у нас в институте всё ещё стояли большие шкафы всяких "Малых ЭВМ" и у одного был выдвинут ящик где я разглядел 580ВМ80А, использованный в качестве периферийного процессора - после этого мир в моих глазах стал иным...
|
22 Jan 2020 17:17 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Тебя постигло чувство горького разочарования в "Малых ЭВМ" ?
_________________ iLavr
|
22 Jan 2020 17:58 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22730 Location: Silicon Valley
|
Не - понимание того, что крутость только что изученного ВМ80 в данном случае тратилась на управление тупой периферией
|
24 Jan 2020 21:22 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Кстати, да - это было обидно... ВМ80 много где совали на обслуживание периферии...
_________________ iLavr
|
25 Jan 2020 10:22 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Пока я разными способами ворошил в поисковиках CRISS CP/M computer, попался вот такой интересный материал: Самодельный ноутбук ZedRipper на шестнадцати Z80
_________________ iLavr
|
06 Dec 2020 07:27 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Что-то мне кажется, что основная идея этого монстра о 16-ти процессорах z80, практически такая же, как у Пропеллера... https://habr.com/ru/post/159847/
_________________ iLavr
|
07 Dec 2020 18:07 |
|
|
Who is online |
Users browsing this forum: No registered users and 6 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|