Но с другой стороны, это позволяло сэкономить на длине команды: в System/360 1-байтовых команд не было, а в 8086 - были
Подобную "экономию" надо рассматривать в комплексе. Наличие или отсутствие однобайтовых команд само по себе абсолютно неважно, важна совокупная длина программы, решающей некую задачу. Причём важна и в наши дни: хотя ёмкость ОЗУ можно считать условно бесконечной, ёмкость кэша первого уровня весьма невелика и является одним из основных факторов, ограничивающих производительность.
Ну, VMWare же сделали ;-) Правда есть нюанс - как именно: если на то, что в режиме пользователя программа видит CR0-3 хоста, можно наплевать, то привилегированный режим пришлось поддерживать в режиме интерпретации :-Q
Я понятия не имею, как сделали VMWare и на что они опирались. Но если там приходилось что-то интерпретировать в массовом порядке, это по определению не могло быть эффективным решением -- ну а в VM/370 гостевая система практически не теряла в производительности, если у неё не было собственной виртуальной памяти (если была, то для эффективности нужна была уже специальная поддержка, а без таковой тормоза таки возникали -- но не сказать, чтоб очень большие).
Виртуализации там просто не предполагалось, иначе бы команды чтения управляющих регистров сделали бы привилегированными.
Вряд ли виртуализация всей машины сразу предполагалась в Системе 370. Если на то пошло, в Системе 360 команды, считывающие "системные" данные, тоже были привилегированными -- т.е. IBM с самого начала шла правильным путём, полностью запретив пользователю доступ к тому, что его не касается. А в Интел -- просто дебилы, а "не предполагалось". Были б у них мозги -- не было бы, в частности, префиксов для команд, поскольку это исключает возможность быстрого и дешёвого декодирования команды. Не говоря уже о том, что архитекторы должны думать наперёд, а здесь у них даже отмазы в стиле "мы первопроходцы, до нас никогда этого не делали" не было.
Я же не зря уточнял: "с учетом выросших потребностей прикладного ПО". 512 КБ к началу 90-х - хватало уже не для каждой программы даже на однозадачной DOS. А в 90-х и 640К стало достаточно не только лишь всем, в результате куча программ начала использовать DOS extender, тот же культовый Doom требовал целых 4МБ, и школьников из небогатых российских семей это немало огорчало
Не смешивайте одно с другим. Для вытесняющей многозадачности и виртуальных машин памяти много не надо. То, что она требуется определённым прикладным программам, ни разу не увеличивает потребность в памяти для самой ОС.
RSX-11M в полноценном варианте могла работать на машине с примерно 128 Кбайтами ОЗУ (сама система под себя и драйверы пожирала меньше 100 Кбайт). Запустить, например, компилятор Паскаля на такой машине уже не получилось бы: он требовал под себя 64 Кбайта и не полез бы в оставшуюся память (полноценной виртуальной памяти на большинстве PDPшек не было из-за технических ограничений процессора и MMU, лишь на некоторых моделях, в частности, на PDP-11/70, такое можно было сделать). А вот ассемблер или Фортран в оставшийся объём вписывались и работали бы.
Так что не объём памяти был препятствием для нормальных ОС на ПК, а кривая архитектура процессора и компьютера в целом. И, кстати говоря, если RSX-11M хватало под себя условных 100 Кбайт ОЗУ (с вытесняющей многозадачностью и всем таким прочим, включая драйверы устройств), то почему убогой MS DOS и без драйверов (ввод-вывод управлялся кодом BIOS) нужно больше? Не говорит ли это как о качестве системы команд, так и о качестве кода системы?
А как насчет механизмов асинхронного ввода/вывода на уровне ядра - и не просто, а с учетом файловой системы? Отложенных процедур обработки прерываний в NT? Порта завершения ввода-вывода в коммерческих Unix и NT? Структурной обработки исключений, в том числе - и в режиме ядра?
RSX-11M была насквозь асинхронной и на уровне ядра, и на прикладном уровне -- в отличие от всяких Унихов, где асинхронного ввода-вывода для пользователя просто нет. (Да, в POSIX включили, но это не ОС, а стандарт, и далеко не везде эти расширения поддерживаются; в Линухе сравнительно появился IO_URING или как его там -- но, как по мне, оно какое-то... переусложнённое и неудобное).
Механизм отложенной обработки прерываний в NT -- практически 1:1 копия механизма VAX/VMS, а тамошний -- расширение механизма RSX-11M.
Порты завершения ввода-вывода -- это уже пользовательский уровень, причём принципиально новых возможностей не дающий.
Структурная обработка исключений -- это вообще про языки высокого уровня (C/C++), которые-то как раз развивались и далеко ушли от раннего Паскаля или Фортрана с Коболом. Я говорю о новых вещах на уровне, в первую очередь, железа, а там с подлинно новым весьма туго, особенно если говорить о концептуальном уровне, а не о реализации. Понятно, что современные суперскалярные процессоры куда круче микроархитектурно, чем первые -- но сама концепция впервые появилась и была воплощена именно в 1960-е.
Даже если взять ту же PCI Express: конечно, ничего аналогичного в 1970-е не было, однако сама идея синхронной последовательной передачи данных по одной линии вместо асинхронной по параллельной не только была в умах, но и на практике такие линии были -- только использовались не в качестве системных шин, а чисто для связи с определённой периферией. Или, скажем, GPU. Их не было, а вот матричные процессоры уже были -- а GPU, по большому, счёту, матричным процессором и является. Точней, несколькими матричными процессорами с кучей локальной памяти и некоторыми узкоспециализированными аппаратными блоками (для отсечения и отбраковки пикселей, не попадающих в кадр, например -- это можно делать и программно, но специализированная аппаратура справляется, понятно дело, быстрей), но базовая идея (широкий SIMD и всё такое) -- та же самая.
Ну, справедливости ради, на PDP-11 была не совсем страничная организация в том смысле, как обычно её понимают: там MMU работало по-другому (и это правильно, учитывая, что машинка была 16-разрядная, а не 32, как IBMовские мэйнфреймы). С точки зрения лёгкости управления отображением памяти и его влияния на производительность машины PDPшная схема лучше, но она не масштабируется с увеличением разрядности адреса.
Но таки да, виртуальную память со страничной организацией уже вовсю обкатали, как минимум, на Системе 370, где соответствующие ОС (OS/360 SVS и затем MVS и VM/370) появились в самом начале 1970-х, и уже было понятно, что оно работает эффективно, но требует некоторых улучшений. В частности, в поздних Системах 370 появилась команда IPTE -- INVALIDATE PAGE TABLE ENTRY -- чтобы запрещать доступ к определённой странице и одновременно чистить TLB от копий именно запрещаемого элемента (до этого была только команда PTLB, которая очищала весь TLB, что, естественно, не способствовало сохранению производительности).
Так что Интел могла бы уже на 8086/88 предусмотреть управление памятью в стиле PDP-11: для 16-разрядных адресов это куда эффективней со всех точек зрения, чем уродливые сегменты. Собственно, в Z8000 нечто аналогичное было сделано; правда, реализовано было с помощью дополнительной микросхемы, но, как по мне, это вполне разумно: сам проц 16-разр, ну а раз всё "на борт" впихнуть нельзя, оставьте решение за разработчиком компьютера. Никого ж не смущало, что FPU долго ещё был отдельной микросхемой, так почему для MMU это не разрешить?
Архитектура у интеловских процов ужасна. И в плане системы команд, особенно её кодирования (попробуйте, хотя бы, определить длину команды -- с учётом всех этих идиотских префиксов), и в плане системных вещей. В частности, виртуализацию на 80386 сделать невозможно технически, потому что дебилы-архитекторы половину системных по своей сути команд сделали непривилегированными. Установить значения системных регистров код пользователя не мог, а прочитать -- запросто, и это полностью убивает любую возможность виртуализации. Ну а в Системе 370 все такие команды были привилегированными -- потому виртуализация и оказалась возможной.
Что же до памяти, СВМ ЕС, она же VM/370, работала уже на машине с 512 килобайтами памяти. Ну а вытесняющая многозадачность была и в OS/360 MFT (минимальный объём -- 128 Кбайт), и в "бабке Винды" RSX-11M -- которой, если уж совсем минимальная конфигурация, хватало 32 Кбайт, а в полной её вовсю крутили на машинах с 248 Кбайтами. Да, все эти системы без графики, но, простите, первая версия Винды работала ещё на 8086/88, имея лишь 640 Кбайт ОЗУ -- т.е. пары мегабайт уж точно хватило бы и на графику невысокого разрешения, и на вытесняющую многозадачность. Ну а такой объём ОЗУ был, по сути, минимальным для компьютеров на 80386 -- память уже не была по-настоящему дефицитным ресурсом.
Насчёт Ряда 2 Вас уже поправили. 1020, 1022, 1030, 1032, 1033, 1040, 1050, 1052 -- Ряд 1, т. е. Система 360. Там поддержки виртуальной памяти не было, а значит, и СВМ работать не могла.
Что же до позднего появления виртуализации ПК, то здесь надо спасибо сказать фирме Интел, которая за всю свою историю не создала ни одного вменяемого процессора, если говорить про архитектуру: сплошное уродство на уродстве. Поэтому до появления специальных средств поддержки виртуализации создание системы виртуальных машин на интеловской архитектуре было невозможным технически. Ну а Системе 370 никаких дополнительных средств для этого не требовалось, хватало обычного механизма виртуальной памяти. Если специальные средства поддержки виртуализации имелись, они ускоряли работу и гипервизора, и виртуальных машин, но принципиально ничего не изменяли.
Ну а насчёт "нового и молодёжного" -- это не только виртуализация. Почти всё "новое" реально появилось впервые в 1960-70-х годах. Собственно, только Plug&Play, кажется, и стал реально новым, когда он появился на ПК в 1990-х.
Ну, интерес сейчас, как и к походу означенного князя -- чисто исторический, чтоб лучше понимать, как подобные решения в СССР реально принимались. Но, подозреваю, на нашем уровне этого не узнать.
Ну, судя по внутреннему устройству ЕС-1045/46, ереванская контора мало чему научилась. Да, машина получилась быстрая, но железа в ней... Явно больше, чем следовало бы, и, опять-таки, приличное его недоиспользование. Хотя до такого откровенного идиотизма, как в 1030, там всё-таки не доходит: чему-то таки научились, но явно недостаточно.
Честно говоря, я б на месте профильного нашего руководства после разработки 1030 просто разогнал бы ереванский институт нафиг. Пускай лучше коньяк делают: он у них лучше получался :) Но, думаю, у армян был не только коньяк, но и сильное лобби где надо. Ведь позже они не дали казанцам сделать новую машину на смену 1033, пропихнув свою 1045.
Можно, но это, по меньшей мере, непереносимо, так как: а) зависит от компилятора (как там оформляются ассемблерные вставки), и б) от архитектуры процессора (одна и та же операция на IA-32, ARM и RISC-V должна быть оформлена по-разному). А вот включение соответствующей операции в сам язык высокого уровня делает эту операцию стандартной и переносимой без лишних проблем.
Их вызовы выглядят подобно вызовам функций, но не более того. Собственно, компилятор и обычные функции, тела которых ему доступны, может встроить (причём, кажется, уже без всякого явного указания inline).
Ну, это обычное атомарное обращение к области памяти, выровненной должным образом (интервальный таймер -- слово и находится на границе слова), т.е. сие относится не к таймеру как к таковому, а к любому выровненному слову, участвующему в некоей операции. Но самый простой -- да, обновлять между командами.
Ну, конкретно эта цитата -- бред сивой кобылы. Никто не заставлял делать лишние линии адреса там, где они не нужны; скажем, в ЕС-1020 было реализовано лишь 18 линий, а у IBM 360/30 -- вообще только 16. В общем, это писал человек, не понимающий, как процессоры устроены внутри.
Ну а ЕС-1030 исключительно уродлива по микроархитектуре (внутреннему устройству проца), и это -- следствие альтернативной одарённости товарищей из Еревана, а отнюдь не архитектуры Системы 360, в которой были и очень удачные реализации (скажем, ЕС-1022, да и та же ЕС-1033 по всем статьям ЕС-1030 превосходила). Но раздалбывать разработчиков ЕС-1030 я буду в заключении :)
Мы пока Кейл используем; в конце концов сползём, наверное, на VSC + GCC, но, в любом случае, никаких тебе платформио и прочего, весь низкоуровневый код -- свой собственный.
Да хотя бы для отладки -- чтоб через UART выводить сообщения. Не говоря о том, что UART может быть подключён к другому компу, например. В общем, странное ограничение, как по мне.
По цене с Китаем тягаться абсолютно бессмысленно, и с этим ничего не сделаешь (не считая возможности для государства давить импорт пошлинами, а своё субсидировать).
А вот с технической точки зрения что мне не нравится на этой плате, так это необходимость выбора "или USB-UART, или USB". Получается, если я хочу отладить свой драйвер для USB на миландровском МК, используя эту плату, я автоматом лишаюсь USB-UART, а он очень часто весьма полезен. Правильней было бы сделать два USB-разъёма: один под USB-UART (его можно совместить с программатором, как это часто делается), другой под USB самого МК.
И кстати, почему светодиоды обозначены L? Всю жизнь так обозначаются катушки.
Подобную "экономию" надо рассматривать в комплексе. Наличие или отсутствие однобайтовых команд само по себе абсолютно неважно, важна совокупная длина программы, решающей некую задачу. Причём важна и в наши дни: хотя ёмкость ОЗУ можно считать условно бесконечной, ёмкость кэша первого уровня весьма невелика и является одним из основных факторов, ограничивающих производительность.
Я понятия не имею, как сделали VMWare и на что они опирались. Но если там приходилось что-то интерпретировать в массовом порядке, это по определению не могло быть эффективным решением -- ну а в VM/370 гостевая система практически не теряла в производительности, если у неё не было собственной виртуальной памяти (если была, то для эффективности нужна была уже специальная поддержка, а без таковой тормоза таки возникали -- но не сказать, чтоб очень большие).
Вряд ли виртуализация всей машины сразу предполагалась в Системе 370. Если на то пошло, в Системе 360 команды, считывающие "системные" данные, тоже были привилегированными -- т.е. IBM с самого начала шла правильным путём, полностью запретив пользователю доступ к тому, что его не касается. А в Интел -- просто дебилы, а "не предполагалось". Были б у них мозги -- не было бы, в частности, префиксов для команд, поскольку это исключает возможность быстрого и дешёвого декодирования команды. Не говоря уже о том, что архитекторы должны думать наперёд, а здесь у них даже отмазы в стиле "мы первопроходцы, до нас никогда этого не делали" не было.
Не смешивайте одно с другим. Для вытесняющей многозадачности и виртуальных машин памяти много не надо. То, что она требуется определённым прикладным программам, ни разу не увеличивает потребность в памяти для самой ОС.
RSX-11M в полноценном варианте могла работать на машине с примерно 128 Кбайтами ОЗУ (сама система под себя и драйверы пожирала меньше 100 Кбайт). Запустить, например, компилятор Паскаля на такой машине уже не получилось бы: он требовал под себя 64 Кбайта и не полез бы в оставшуюся память (полноценной виртуальной памяти на большинстве PDPшек не было из-за технических ограничений процессора и MMU, лишь на некоторых моделях, в частности, на PDP-11/70, такое можно было сделать). А вот ассемблер или Фортран в оставшийся объём вписывались и работали бы.
Так что не объём памяти был препятствием для нормальных ОС на ПК, а кривая архитектура процессора и компьютера в целом. И, кстати говоря, если RSX-11M хватало под себя условных 100 Кбайт ОЗУ (с вытесняющей многозадачностью и всем таким прочим, включая драйверы устройств), то почему убогой MS DOS и без драйверов (ввод-вывод управлялся кодом BIOS) нужно больше? Не говорит ли это как о качестве системы команд, так и о качестве кода системы?
RSX-11M была насквозь асинхронной и на уровне ядра, и на прикладном уровне -- в отличие от всяких Унихов, где асинхронного ввода-вывода для пользователя просто нет. (Да, в POSIX включили, но это не ОС, а стандарт, и далеко не везде эти расширения поддерживаются; в Линухе сравнительно появился IO_URING или как его там -- но, как по мне, оно какое-то... переусложнённое и неудобное).
Механизм отложенной обработки прерываний в NT -- практически 1:1 копия механизма VAX/VMS, а тамошний -- расширение механизма RSX-11M.
Порты завершения ввода-вывода -- это уже пользовательский уровень, причём принципиально новых возможностей не дающий.
Структурная обработка исключений -- это вообще про языки высокого уровня (C/C++), которые-то как раз развивались и далеко ушли от раннего Паскаля или Фортрана с Коболом. Я говорю о новых вещах на уровне, в первую очередь, железа, а там с подлинно новым весьма туго, особенно если говорить о концептуальном уровне, а не о реализации. Понятно, что современные суперскалярные процессоры куда круче микроархитектурно, чем первые -- но сама концепция впервые появилась и была воплощена именно в 1960-е.
Даже если взять ту же PCI Express: конечно, ничего аналогичного в 1970-е не было, однако сама идея синхронной последовательной передачи данных по одной линии вместо асинхронной по параллельной не только была в умах, но и на практике такие линии были -- только использовались не в качестве системных шин, а чисто для связи с определённой периферией. Или, скажем, GPU. Их не было, а вот матричные процессоры уже были -- а GPU, по большому, счёту, матричным процессором и является. Точней, несколькими матричными процессорами с кучей локальной памяти и некоторыми узкоспециализированными аппаратными блоками (для отсечения и отбраковки пикселей, не попадающих в кадр, например -- это можно делать и программно, но специализированная аппаратура справляется, понятно дело, быстрей), но базовая идея (широкий SIMD и всё такое) -- та же самая.
Ну, справедливости ради, на PDP-11 была не совсем страничная организация в том смысле, как обычно её понимают: там MMU работало по-другому (и это правильно, учитывая, что машинка была 16-разрядная, а не 32, как IBMовские мэйнфреймы). С точки зрения лёгкости управления отображением памяти и его влияния на производительность машины PDPшная схема лучше, но она не масштабируется с увеличением разрядности адреса.
Но таки да, виртуальную память со страничной организацией уже вовсю обкатали, как минимум, на Системе 370, где соответствующие ОС (OS/360 SVS и затем MVS и VM/370) появились в самом начале 1970-х, и уже было понятно, что оно работает эффективно, но требует некоторых улучшений. В частности, в поздних Системах 370 появилась команда IPTE -- INVALIDATE PAGE TABLE ENTRY -- чтобы запрещать доступ к определённой странице и одновременно чистить TLB от копий именно запрещаемого элемента (до этого была только команда PTLB, которая очищала весь TLB, что, естественно, не способствовало сохранению производительности).
Так что Интел могла бы уже на 8086/88 предусмотреть управление памятью в стиле PDP-11: для 16-разрядных адресов это куда эффективней со всех точек зрения, чем уродливые сегменты. Собственно, в Z8000 нечто аналогичное было сделано; правда, реализовано было с помощью дополнительной микросхемы, но, как по мне, это вполне разумно: сам проц 16-разр, ну а раз всё "на борт" впихнуть нельзя, оставьте решение за разработчиком компьютера. Никого ж не смущало, что FPU долго ещё был отдельной микросхемой, так почему для MMU это не разрешить?
Архитектура у интеловских процов ужасна. И в плане системы команд, особенно её кодирования (попробуйте, хотя бы, определить длину команды -- с учётом всех этих идиотских префиксов), и в плане системных вещей. В частности, виртуализацию на 80386 сделать невозможно технически, потому что дебилы-архитекторы половину системных по своей сути команд сделали непривилегированными. Установить значения системных регистров код пользователя не мог, а прочитать -- запросто, и это полностью убивает любую возможность виртуализации. Ну а в Системе 370 все такие команды были привилегированными -- потому виртуализация и оказалась возможной.
Что же до памяти, СВМ ЕС, она же VM/370, работала уже на машине с 512 килобайтами памяти. Ну а вытесняющая многозадачность была и в OS/360 MFT (минимальный объём -- 128 Кбайт), и в "бабке Винды" RSX-11M -- которой, если уж совсем минимальная конфигурация, хватало 32 Кбайт, а в полной её вовсю крутили на машинах с 248 Кбайтами. Да, все эти системы без графики, но, простите, первая версия Винды работала ещё на 8086/88, имея лишь 640 Кбайт ОЗУ -- т.е. пары мегабайт уж точно хватило бы и на графику невысокого разрешения, и на вытесняющую многозадачность. Ну а такой объём ОЗУ был, по сути, минимальным для компьютеров на 80386 -- память уже не была по-настоящему дефицитным ресурсом.
Насчёт Ряда 2 Вас уже поправили. 1020, 1022, 1030, 1032, 1033, 1040, 1050, 1052 -- Ряд 1, т. е. Система 360. Там поддержки виртуальной памяти не было, а значит, и СВМ работать не могла.
Что же до позднего появления виртуализации ПК, то здесь надо спасибо сказать фирме Интел, которая за всю свою историю не создала ни одного вменяемого процессора, если говорить про архитектуру: сплошное уродство на уродстве. Поэтому до появления специальных средств поддержки виртуализации создание системы виртуальных машин на интеловской архитектуре было невозможным технически. Ну а Системе 370 никаких дополнительных средств для этого не требовалось, хватало обычного механизма виртуальной памяти. Если специальные средства поддержки виртуализации имелись, они ускоряли работу и гипервизора, и виртуальных машин, но принципиально ничего не изменяли.
Ну а насчёт "нового и молодёжного" -- это не только виртуализация. Почти всё "новое" реально появилось впервые в 1960-70-х годах. Собственно, только Plug&Play, кажется, и стал реально новым, когда он появился на ПК в 1990-х.
Ну, интерес сейчас, как и к походу означенного князя -- чисто исторический, чтоб лучше понимать, как подобные решения в СССР реально принимались. Но, подозреваю, на нашем уровне этого не узнать.
Ну, судя по внутреннему устройству ЕС-1045/46, ереванская контора мало чему научилась. Да, машина получилась быстрая, но железа в ней... Явно больше, чем следовало бы, и, опять-таки, приличное его недоиспользование. Хотя до такого откровенного идиотизма, как в 1030, там всё-таки не доходит: чему-то таки научились, но явно недостаточно.
Честно говоря, я б на месте профильного нашего руководства после разработки 1030 просто разогнал бы ереванский институт нафиг. Пускай лучше коньяк делают: он у них лучше получался :) Но, думаю, у армян был не только коньяк, но и сильное лобби где надо. Ведь позже они не дали казанцам сделать новую машину на смену 1033, пропихнув свою 1045.
Можно, но это, по меньшей мере, непереносимо, так как: а) зависит от компилятора (как там оформляются ассемблерные вставки), и б) от архитектуры процессора (одна и та же операция на IA-32, ARM и RISC-V должна быть оформлена по-разному). А вот включение соответствующей операции в сам язык высокого уровня делает эту операцию стандартной и переносимой без лишних проблем.
Их вызовы выглядят подобно вызовам функций, но не более того. Собственно, компилятор и обычные функции, тела которых ему доступны, может встроить (причём, кажется, уже без всякого явного указания inline).
Ну, это обычное атомарное обращение к области памяти, выровненной должным образом (интервальный таймер -- слово и находится на границе слова), т.е. сие относится не к таймеру как к таковому, а к любому выровненному слову, участвующему в некоей операции. Но самый простой -- да, обновлять между командами.
Для некоторых из подобных команд у компилятора могут быть интринсики, что может быть удобней в плане программирования.
Интересно, а Эпл-2 клонировать не пытались? Он же тоже на 6502... Правда, там, небось, всё патентно огорожено...
Ну, конкретно эта цитата -- бред сивой кобылы. Никто не заставлял делать лишние линии адреса там, где они не нужны; скажем, в ЕС-1020 было реализовано лишь 18 линий, а у IBM 360/30 -- вообще только 16. В общем, это писал человек, не понимающий, как процессоры устроены внутри.
Ну а ЕС-1030 исключительно уродлива по микроархитектуре (внутреннему устройству проца), и это -- следствие альтернативной одарённости товарищей из Еревана, а отнюдь не архитектуры Системы 360, в которой были и очень удачные реализации (скажем, ЕС-1022, да и та же ЕС-1033 по всем статьям ЕС-1030 превосходила). Но раздалбывать разработчиков ЕС-1030 я буду в заключении :)
Он кардинально отличается от пульта ЕС-1030. У этих машин вообще нет ничего общего, кроме архитектуры (ИБМовской Системы 360).
А пульт ЕС-1030 плохо, но видно на фотке, что я использую для всех статей цикла.
А ещё -- хрен откажусь :)
Мы пока Кейл используем; в конце концов сползём, наверное, на VSC + GCC, но, в любом случае, никаких тебе платформио и прочего, весь низкоуровневый код -- свой собственный.
Да хотя бы для отладки -- чтоб через UART выводить сообщения. Не говоря о том, что UART может быть подключён к другому компу, например. В общем, странное ограничение, как по мне.
Тогда могла быть и ЕС-1046 -- модернизированная 1045.
Ну, сейчас киберпанк вполне себе играбельный: 100500 патчей даром не прошли.
По цене с Китаем тягаться абсолютно бессмысленно, и с этим ничего не сделаешь (не считая возможности для государства давить импорт пошлинами, а своё субсидировать).
А вот с технической точки зрения что мне не нравится на этой плате, так это необходимость выбора "или USB-UART, или USB". Получается, если я хочу отладить свой драйвер для USB на миландровском МК, используя эту плату, я автоматом лишаюсь USB-UART, а он очень часто весьма полезен. Правильней было бы сделать два USB-разъёма: один под USB-UART (его можно совместить с программатором, как это часто делается), другой под USB самого МК.
И кстати, почему светодиоды обозначены L? Всю жизнь так обозначаются катушки.
Мне вот что-то кажется, что Геральту на момент повествования около 100 лет... Или таки кажется, и реально он сильно моложе?