COM port на 16c550 Uart [Архив] - Speccy

Vasily_A

28.12.2022, 20:57

фифо надо специально включать, насколько я помню работу с ним на 286-х машинках... так что - это не проблема.

есть куча разных древних уартов, в дип корпусах, доступных на али. в том числе 6402.

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

SuperMax

29.12.2022, 08:05

я бы сначала задался вопросом - а цель-то какая ?

если мы говорим о терминале то 9600 это уже нормально
а 57600 это выше крыши

Alex

29.12.2022, 10:44

Чем больше скорость, тем лучше :)
57600 - для текстового терминала хорошо...
А если файлы тащить , или терминал графический да картинка растровая?
Конечно в некоторых играх на текстовом терминале - печально будет, слишком быстро :)

Hunta

29.12.2022, 11:02

Чем больше скорость, тем лучше
Нет. При работе на прерываниях система почти всё время начинает тратить на обработку прерываний. Я экспериментировал на 115200 - и это для PDP2011. А ВМ1 вообще повесится

Alex

29.12.2022, 15:50

Вопрос в том, что если есть делать что процессору окромя копирования... Тогда да.
Не просто так мультиплексоры да ещё с прямым доступом к памяти придумывали :)
Были так же платки для UNIBUS кои добавляли возможность DMA обычным последовательным интерфейсам, да и не только им(для принтера, перфоратора и прочая).
Знакомый инженер хвастался :)
Вот как они были сделаны, как работали - не ведаю :(
Тогда не поинтересовался подробностями, а теперь жалею :(
У меня есть, конечно свои гнусные домыслы и измышления, но это всего лишь мои гнусные домыслы и измышления...
Но в большинстве случаев, в случае RT11SJ всё будет неплохо.
Проблемы начнутся с FB, а уж на мультизадачных RSX-11(TSX-11, RSTS/E да и прочая) будет виселица ... Там как раз платки эти и мультиплексоры весьма актуальны.

Hunta

29.12.2022, 16:06

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

Не просто так мультиплексоры ... придумывали
Мультиплексор - это в первую очередь уменьшение количества регистров и микросхем логики работы с шиной.

Были так же платки для UNIBUS кои добавляли возможность DMA обычным последовательным
Мультиплексор DH. Возможно, даже мой DHV поддерживает, но лень и некогда лезть в документацию. Но - штатно - это поддерживает только RSX да ещё и с достаточно жёсткими ограничениями - потому как в обычный в/в хорошо вмешивается драйвер. Например, можно драйверу сказать - спозиционировать курсор и потом вывести.

в случае RT11SJ всё будет неплохо
Именно на ней я и проверял. На PDP2011. На 115200 уже было всё так себе.

а уж на мультизадачных RSX-11(TSX-11 да и прочая) будет виселица
На RSX виселицы не будет - я вполне впараллель процессу вывода текстовика на один терминал работал на другом. Но периодические кратковременные подтормаживания были. Так что RSX уже можно было не считать real-time

Alex

29.12.2022, 16:34

Ну да, не просто так загрузки в КЦГД писались по готовности.
В мультиплексорах были ещё буфера...
Платки не были частью мультиплексора, они были сами по себе. Предполагаю, что они как-то сигнал готовности перехватывали и делали цикл DMA.
По этому их можно было на многие устройства повесить.
Мультиплексор DH - это отдельное законченное изделие.

- - - Добавлено - - -

PDP2011 - скажем так, случай несколько особый ... Вот если на 1801ВМ3 или F-11, J-11 тормоза будут...
Если честно, мне было бы интересно будут тормоза или нет в таком случае.
Как мне представляется, при копировании - в SJ всё зависнет, но там всего лишь одна задача и на это плевать. Как только очередной блок данных отправлен(принят) обслуживание последовательного порта прекратится и всё вернётся на круги своя :)
Конечно, есть и в SJ программы, которые будут виснуть, но это проблема автора программы ... Недостаточно качественно написан код.
Как вариант, можно использовать драйвер перфоратора и посмотреть, будет ли виснуть...?

- - - Добавлено - - -

Если нужно реальное время в SJ - тогда всё в руках программиста :)

- - - Добавлено - - -

И ещё, если ввод-вывод идёт средствами системы через макросы, то число число прерываний, обрабатываемых системой, как минимум удваивается и-за выполнения EMT ...

Hunta

29.12.2022, 16:42

В мультиплексорах были ещё буфера
Не только в мультиплексорах. Кстати, ЕМНИП, то и для каких то DL были вроде FIFO. И кстати - ещё плюс мультиплексоров - можно было на прерывании проверить готовность по всем каналам, то есть там соотношение - готовность/прерывания будет больше единицы, что снижает накладные.

PDP2011 - скажем так, случай несколько особый
Это не особый случай, это случай ОЧЕНЬ быстрого PDP-11. А значит, ВМ3, F11 и даже J11 - ситуация будет ещё хуже.

Как мне представляется, при копировании - в SJ всё зависнет, но там всего лишь одна задача и на это плевать.
Не в этом дело. А в том, что если накладные расходы (обработка прерывания) становятся ощутимыми, то РЕАЛЬНАЯ скорость передачи - падает. И будь у тебя хоть 10 мбит/с скорости uart-а - как получал ты файл на фактической скорости 100 кбит/с, которая была и на 115200 - так и получаешь. То есть скорость канал увеличили, а скорость передачи не возросла. Числа для примера, это не реальные цифры :) Реальные - надо создавать стенд и тестировать :) Но будет что-то похожее :)

- - - Добавлено - - -

И ещё, если ввод-вывод идёт средствами системы через макросы, то число число прерываний, обрабатываемых системой, как минимум удваивается и-за выполнения EMT ...
И да и нет. .TTYOUT, скажем - там ещё больше может быть, .PRINT, .WRITE - в общем случае нет

- - - Добавлено - - -

В целом, подводя итог - пропорционального Щастья от увеличения скорости - не получить. Поэтому смысла делать высокоскоростные DL для процов типа ВМ1-ВМ2 и даже 1811 - я не вижу. 38400-57600 - за глаза.
И кстати, у мелкосхемы топикстартёра основной недостаток с точки зрения PDP-11 - вовсе не FIFO - с этим вполне можно жить. А то, что есть регистры и для работы их нужно запрграммировать, а система регистров на стандартные четыре регистра устройств а-ля-DL-11 - не ложится

Alex

29.12.2022, 17:04

PDP2011 - работа с шиной внушает некие сомнения...

По поводу реальной системы - 6 каналов по 57 600(-65 прошивка). Процессор на ДВК 1801ВМ3. Система SVD ВУЗ, разработанная в нашем институте. Одна ДВК с винчестером и с платой ИРПС-6 работала с 6 УКНЦ соединённые звездой.
ДВК с RT11FB - вполне тянула, на теперешние деньги как сервер :) . На УКНЦ вполне нормально можно было работать. Даже на самой ДВК можно было что-то делать, например, фортран запускать. Пытались заменить на RT11XM - пошли тормоза :(
При этом надо учесть, что драйвер DW без прямого доступа к памяти, чисто программный обмен.

- - - Добавлено - - -

Ой, ещё забыл, в ДВК ещё был КЦГД на той же скорости 57 600, итого 7 каналов по 57 600 на -65 прошивках :)
И ещё один канал на плате процессора был в резерве для подключения куда-то ещё. Но его не считаем, так как не использовали.
И ведь работало почему-то :)

Hunta

29.12.2022, 17:13

PDP2011 - работа с шиной внушает некие сомнения
И она там быстрее. Есссвенно, я говорю про мой, а а не авторский вариант.

На УКНЦ вполне нормально можно было работать.
И что - все шесть каналов одновременно и непрерывно передавали файлы? В редакторе сидеть - так ещё больше можно было навтыкать.

- - - Добавлено - - -

А ещё есть такое, как - текущее восприятие. Мне, во времена, когда в качестве домашнего компа стоял Квант-4, работа на винчестера казалось ой какой быстрой. А потом, когда я его опять оживил - "нихера себе тормоза"

Alex

29.12.2022, 17:23

Самый напряжный момент была - начальная загрузка всего класса :)
И в редакторах и с прочими программами ...
И использование редактора в таких условиях обмен сильнее грузит. Это на многозадачной RSX-11 где идёт чисто обмен с терминалом(халява :) ). А на УКНЦ загружена полнокровная RT11.
Следовательно в большинстве случаев файл .SAV тащится по каналу, плюс сам редактируемый текст(ну хотя бы часть, от редактора зависит...). далее сохранение текста... Потом KMON...

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

Ну да, MFM скорость обмена 5 Мбит/сек... Ещё добавим время на позиционирование и поиск сектора...
А когда до этого работал на DX: и MX: то быстрой :)

Hunta

29.12.2022, 17:28

Ну да, MFM скорость обмена 5 Мбит/сек
Это скорость обмена с поверхностью. Смею уверить, что 600 кб/с на выходе ты не получишь. Если будет 200 кб/с - это будет ОЧЕНЬ хорошо.

- - - Добавлено - - -

Самый напряжный момент была - начальная загрузка всего класса
Вот на это и ориентируйся. Да ещё если впараллель, а не последовательно. И 115200 вместо 57600 тебя бы не в два раза спасло.

Alex

29.12.2022, 17:52

Я полагаю, что скорость будет ещё менее :( Позиционирование однако...

Оно и так неплохо работало :)

Возможно, что подняв скорость ситуация стала бы чуток лучше. Ну может процентов на 20... И то хлеб был бы.
По моему мнению обмен тут мог упереться в MFM винчестер ...
Так что до затыка обмена по последовательному каналу не дошло бы...

Hunta

29.12.2022, 18:10

Так что до затыка обмена по последовательному каналу не дошло бы..
Если поставить канал на мбит? Дошло бы. Хотя.. Чего сейчас спорить - ситуацию всё равно не воспроизвести.

- - - Добавлено - - -

Кстати, насчёт MFM - не думаю, что уперлись в него бы. Всё таки у него одно прерывание на 512 байт, а не на 1 байт

Alex

29.12.2022, 18:54

Сама система SVD ВУЗ канула в лету :(

Ну даже чуть более чем в два раза уменьшить накладные расходы на пересылку по каналу - если бы можно было бы в регистр писать/читать не байт, а 16-бит слово ...

- - - Добавлено - - -

Прерывание - прерыванием, но передача буфера контроллера происходит программно. Но именно словами, а не байтами.

Hunta

29.12.2022, 19:08

но передача буфера контроллера происходит программно
И накладных расходов при этом ГОРАЗДО меньше, потому что не надо на каждом байте (слове) контекст сохранять, вопсстанавливать. У мультиплексоров, кстати, из за этого при массовой передаче-приёме (по всем каналам) накладных тоже будет меньше.

Alex

30.12.2022, 09:08

В принципе на FPGA можно малой кровью такой адаптер сделать с 16 битным регистром данных.
Ведь существовали 16 битные платы ИРПР для межмашинной связи(не видел лично, но хотя бы слышал :) ), для операционки на PDP-11 можно таковым прикинуться :)
На другой конец микроконтроллер или что душе угодно...

Да и на "старых" платах процессора ДВК параллельный интерфейс ИРПР был двунаправленный, но увы байтовый...
Причём видел плату даже МС1201.03 такую.
Потом "доработали" обозвав ИРПР-М и выкинув нормальную двунаправленность и контроллер DX, да поменяли разъём :( (точнее двунаправленность почти никуда не делась, но её можно было использовать только для диагностики)
Чисто принтер подключить :(

Hunta

30.12.2022, 10:25

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

- - - Добавлено - - -

То есть мне то, конечно, фиолетово - ТС (или кто другой) может ваять что угодно. Просто что будет при реальном применении - я уже описал.

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

Alex

30.12.2022, 11:44

Вопрос в том, что если делать по-нормальному, то надо делать реплику сетевой платы от DEC.
Сделать сложно, но после изготовления - минимум проблем, тек как софт в наличии будет :)

А так, можно высокоскоростной последовательный порт для обмена... Микросхемы последовательного интерфейса со скоростью свыше одного мегабита есть в наличии на АлиЭкспрессе и прочих местах...
16 - битный проще программировать. Да и поискать готовый софт. Система ведь не знает, какой там интерфейс, ну за некоторыми исключениями типа сигнала Break...
Если приделать DMA - получится аппаратно конфетка, но упрётся всё в софт.

Hunta

30.12.2022, 12:35

тек как софт в наличии будет
DECNet - да (но - RSX), TCP/IP - фактически только под RT со всеми вытекающими

высокоскоростной
Ещё раз. Последний, дальше даже читать не буду. Высокоскоростного на прерывания по каждому хоть байту, хоть слову - не будет. Всё упрётся в накладные обработки прерываний.

16 - битный проще программировать.
Проще для кого? Для существующего софта? Покажи мне тот, который будет словами обмениваться, а не байтами

Да и поискать готовый софт.
В студию

истема ведь не знает, какой там интерфейс
Байтовый или словный - отлично знает.

но упрётся всё в софт.
Оно и сейчас упирается. Причём не только в этой теме. Кто у нас системный софт пишет, ну ка, перечисли?

Ещё раз. ТС может делать всё, что хочет. Он даже может и сделает. А вот сколько людей, кроме него - будут использовать - вот вопрос. Да и, честно говоря, я так и не понял - зачем оно ему?

- - - Добавлено - - -

И, Alex, задай себе(!) вопрос. Вот такая высокоскоростная, по последовательному каналу, плата - вот лично тебе(!) - зачем она конкретно(!) нужна. Не абстрактное - обмен между компами, а конкретно - вот прям щас - почему ты без неё жить не можешь?

А потом задай себе следующий вопрос - а сколько(!) ещё человек без неё жить не может?

Если я буду задавать себе первый вопрос - у меня есть ответ. Но мне нужна не совсем такая плата, которую хочет ТС, потому что со стороны PDP-11 она НЕ БУДЕТ последовательным портом для терминала. Плат с последовательным портом у меня есть, не одна, в том числе такие, на которых я могу сделать и мегабит. Но я посмотрел на реальную скорость (а не полосу пропускания) обмена и понял - не стоит овчинка таких скоростей. Вот по этим двум причинам плата, которую хочет сваять ТС - мне не интересна.

И я не вижу, кому она ещё может быть интересной - по крайне мере на этом форуме.

Alex

30.12.2022, 16:49

По поводу "высокоскоростного программного обмена" - каюсь, запамятовал... КНГМД(MX)... Стыдно мне... :(
Была сеть по последовательному каналу, был какой-то софт и это тут на форуме упоминалось. И поскольку там работало...
И вроде бы люди именно как с контроллером дисковода работали массово...

Жить все могут. Но иметь возможность высокоскоростного обмена по последовательному каналу, да и с буфером FIFO было бы полезно... :)
Хотя глюки будут... Пример, просмотреть файл отправив на терминал, хочешь притормозить, Ctrl+S жмёшь... Но поздно, кусок файла в буфере... И он выльется на экран. Как-то так... При условии, что буфер достаточно большой.

Hunta

30.12.2022, 18:50

Но поздно, кусок файла в буфере
16-ть символов - это ниочём - у тебя за секундну даже на скорости 9600 прилетает на порядок больше.

max232cpe

01.01.2023, 14:38

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

max232cpe

02.01.2023, 09:40

Свмое печальное что готовых устройств под двк новодельных можно по пальцам руки пересчитать, в основном одни разговоры о том как это никаму не нужно и как это сложно...

- - - Добавлено - - -

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

- - - Добавлено - - -

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

- - - Добавлено - - -

А по итогу людям не собирать нечего не готовое купить, в наличии 1.5 поделки и жалобы что софт никто не пишет при том что писать готовы а неначем!

Hunta

02.01.2023, 11:59

max232cpe

02.01.2023, 12:19

Процессорные платы, перекрывающие по возможностям 1201.03

http://www.kpxx.ru/dnepr/MS1201/V1.0/IMGL1350.JPG
http://www.kpxx.ru/dnepr/MS1201/V2.0/v2-001.jpg
http://www.kpxx.ru/dnepr/MS1201/V3.0/V3-002.jpg

Прототип КЦГД

http://www.kpxx.ru/dnepr/KCGD/Protoype.jpg

CF+Uart+сеть

http://www.kpxx.ru/dnepr/MICB/V0.0/MICB-02.2019.jpg

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

Их, так же как и предыдущих - меньше, чем кажется

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

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

Ну и разное прототипное
http://www.KpXX.Ru/Dnepr/Proto/01.jpg
http://www.KpXX.Ru/Dnepr/Proto/02.jpg
http://www.KpXX.Ru/Dnepr/Proto/03.jpg
http://www.KpXX.Ru/Dnepr/Proto/04.jpg

Я сужу не по форуму о спросе а на торговых площадках, попросил брата выставить на авито излишки плат пришедших с китая, за пару недель очередь из 40 чел которым нужны те или иные части двк, новые платы на заказанны в китае а их уже купили...
Большенство про этот форум даже понятия не имеют...
Если вам нравятся МК и FPGA это ваш выбор, комуто нравится сидеть и 40-50 корпусов впаивать и отлаживать!
Лично мне главное чтоб работало и не было излишеств которые часто бывают во многих проэктах. А какие там детали советские или импорт мне нет особой разницы я скорее выберу те что дешевле.

- - - Добавлено - - -

ПРо софт я не заню от него пака далёт хоть и литературы набрал много, но пака не получу стабильный экземпляр двк-2м и двк-3м\4 врятли до него доберусь.

Hunta

02.01.2023, 12:25

впаивать и отлаживать!
Я программист, а не электронщик, мне этот процесс не интересен, поэтому и идут такие поделки мимо меня, как бы не был интересен функционал платы.
А собранная на FPGA плата позволяет отлаживаться - не перепаивая кучу микросхем, а правильно собранная изначально - ещё и не колхозить с МГТФ.
И - современные МК мне не нравятся. Особенно когда их впихивают по делу и не по делу.

- - - Добавлено - - -

Но, как я написал где то в середине топика - если ТС интересно то, что он захотел - всё в его руках.