У интеловских (или АМДшных) процов вполне может и не быть памяти; я и раньше встречал, что в качестве ОЗУ на время первых этапов инициализации используется кэш. Технически это вполне осуществимо, если кэш можно настроить в таком режиме. Более того, этих десятков мегабайт кэша вполне достаточно, чтоб запустить какую-нибудь там WinNT, только, скорей всего, DMA не будет работать чисто с кэшем, ему почти наверняка полностью инициализированную обычную память подавай :)
Все можно руками. Никто не говорил что нельзя. Просто целесообразность этой работы сомнительна
Вот как раз было сказано про "практически невозможно", что и вызывает, так сказать, большие сомнения. А не про то, что целесообразно и тем более не про то, что "это элементарно, Ватсон"
Как по мне, на ассемблере реально низкоуровневые вещи писать зачастую проще, чем на тех же сях. Для себя обычно на нём и пишу, а вот что по работе -- на це/це++, чтоб не я один мог понять, что там делается :)
Сейчас BIOS правильнее называть UEFI, но по инерции многие продолжают называть эту систему BIOS
Вообще-то, не совсем так. В большинстве современных ПК классический BIOS объединён с современным UEFI, поэтому может прикидываться хоть тем, хоть другим в зависимости от того, какая система загружена. Недавно я ради изврата на комп с Ryzen-что-то-там поставил MS DOS :) Работает-с.
В начале 80-х годов компания IBM разработала для своих компьютеров микропрограмму, которая обеспечивала инициализацию оборудования
Вообще-то, микропрограмма -- это то, что управляет работой процессора, если он с микропрограммным, а не жёстким схемным управлением. BIOS же -- самая что ни на есть программа, и то, что она сидит не в ОЗУ, а в ПЗУ, не делает его микропрограммой. Думается, на русском языке лучше содержимое ПЗУ BIOS всегда именовать прошивкой.
Эта система получила название BIOS, то есть базовая система ввода-вывода. Это была закрытая проприетарная разработка
BIOS IBMовских персоналок не был закрытой разработкой. Исходник BIOS для IBM PC, например, опубликован в Technical Reference Manual на этот компьютер.
Основная задача этой стадии на процессорах Intel — инициализация оперативной памяти. Это сложный процесс, он требует больших объемов закрытого кода, из-за чего его практически невозможно реализовать самостоятельно, даже если у вас есть все необходимые спецификации
Хм... Почему это его "практически невозможно реализовать самостоятельно", если спецификации имеются?
Вернемся к режиму SMM. Его преимущества особенно заметны в серверных продуктах благодаря технологии RAS. Это набор обработчиков ошибок оборудования. В SMM работают драйверы, которые реагируют на прерывания, так как доступ в режим SMM возможен только через SMI. Из обычного кода, в том числе из кода ядра ОС, напрямую попасть в SMM нельзя.
Например, работающий сервер выдает ошибку памяти. Если система настроена правильно, то оборудование генерирует SMI, которое переводит процессор в режим SMM. В нем запускается соответствующий обработчик, который предпринимает действия для устранения или учета ошибки.
Вообще, SMM -- это жуткий костыль, придуманный для того, чтоб управлять электропитанием ранних компов в условиях, когда ОС этим заниматься не умела (впервые появился в 80386SL). Обработка тех же ошибок памяти в SMM -- тоже не лучшее решение, если ОС умеет такое обрабатывать (а современные, теоретически, должны бы уметь это делать, ведь процы уже достаточно давно способны кидать прерывания при аппаратных ошибках, ну а в самых первых ПК в качестве сигнала неисправности памяти или ещё какой аппаратной ошибки использовался NMI).
Кстати говоря, у IBMовских мэйнфреймов прерывания от схем контроля были от Системы 360 до наших дней (т.е. с 1964-65 года), и ОС при возникновении такого прерывания думала, что делать дальше. Например, отказ блока памяти, если в этом блоке размещался прикладной код, приводил к "убийству" программы пользователя, но система в целом работоспособность сохраняла; отказ канала ввода-вывода приводил, понятное дело, к аварийному завершению всех выполняющихся операций ввода-вывода на этом канале, но при наличии альтернативных путей к нужным устройствам работоспособность системы, опять-таки, сохранялась, ну и т.д. и т.п.
Если сервер поддерживает разъем XDP, мы подключаем устройство Intel BlueBox для отладки
А синяя коробка поддерживает точки останова, покомандное выполнение и всё такое прочее, что доступно в обычных программах с помощью обычных отладчиков?
Как уже правильно отмечено, эти команды и регистры не нарушают совместимость снизу вверх: они не меняют поведение процессора для тех команд, которые уже существовали, а добавляют новые возможности. А вот использование бита 2 как индикатора переполнения или внесение изменений в команду десятичной коррекции разрушает совместимость, поскольку программы, написанные для 8080, полагаются на строго определённые правила формирования результатов выполнения используемых ими команд, а нововведения в Z80 приводят иногда к получению других результатов.
Скорей, в 89-м, но, в любом случае, всё это стало появляться в самом конце Союза, когда всё уже разваливалось, а воровать и продавать краденое стали практически открыто -- заметьте, "с рук", как Вы пишите, а не в магазинах, доступных честным гражданам.
Ну, во-первых, такое бывает. В официальной доке на ОС ЕС, в девичестве OS/360, на половину сообщений об ошибках первая рекомендация -- повторить задание или перезагрузить систему и повторить задание :)
Но ценность сохранения ОЗУ -- и в возможностях для отладки. Прога зависла, но, если ты разработчик, ты можешь из монитора или что там у них в ПЗУ лежит глянуть, что творится в памяти, не вылез ли стек за границы и т.д. и т.п.
Мне в своё время хватало примерно 7,25 Мбайт на личном жёстком диске для дисковода ЕС-5052. Точней, я не знал, чем его можно забить: исходники занимали куда меньше, а рабочая информация (временные файлы и т.п.) пишется на рабочие диски.
Я тоже так думал, а оказалось, что есть несовместимая разница во флагах. Вот регистр флагов 8080 из интеловской доки:
А вот он же для Z80:
У 8080 бит 2 -- всегда чётность, а в Z80 в зависимости от команды там либо чётность, либо переполнение. Соответственно, в определённых ситуациях программа, успешно работающая на 8080, не будет работать на Z80. Почему для переполнения они не использовали остающиеся без дела разряды 5 и 3, непонятно.
Вообще, это Cortex-M7, но конкретное семейство неважно: то ли отладчик неадекватно обрабатывает отладочную информацию, то ли компилятор некорректно её формирует. Это относится именно к сопрограммам; если их нет, отладчик работает нормально.
Что же касается ввода-вывода, то он по самой своей природе асинхронный. Запустил передачу по UARTу -- и всё, она идёт параллельно с работой процессора. Прерывания, естественно, тоже являются асинхронными. И оформлять код, который инициирует подобные операции и продолжает что-то делать после их завершения, оказалось куда удобней и читабельней с помощью сопрограмм, чем, например, в помощью подпрограмм обратного вызова или бесконечным анализом неких флагов в главном цикле. (Хотя на самом нижнем уровне, естественно, никаких сопрограмм нет и быть не может -- это достаточно высокоуровневые конструкции).
А сопрограммы позволяют легко и просто использовать асинхронный ввод-вывод, что на микроконтроллерах очень даже полезно, если там задачи посложней мигания светодиодами.
Практическая ценность -- в умении понимать, что там нагенерил компилятор, и при необходимости в способности отлаживаться на этом уровне. Мне, например, так пришлось отлаживать сопрограммы C++20, поскольку с ними отладчик Кейла не дружит от слова совсем (ему полностью срывает крышу). Правда, это немного более сложный случай, чем просто передача параметров в функции, но начинать-то надо с простого.
Потому что их тогда не было в готовом виде, и пришлось бы собирать на рассыпухе. Кроме того, напряжение -5В могло понадобиться (не для Радио-86РК, а вообще) и для других целей, где ток будет уже повыше -- скажем, для преобразователей уровней ТТЛ в уровни RS-232.
А, Вы про это. Я про другое говорю: как формируются битики, формирующие изображение. У Специалиста и многих других они лежат в ОЗУ, и за формирование их отвечает процессор. У а вот у Радио-86РК -- нет, там в ОЗУ лежат коды символов, а конкретные последовательности битов для отображения формирует КР580ВГ75 совместно с ПЗУ знакогенератора. По этой причине формирование изображения на Радио многократно быстрей, чем на Специалисте (нужно записать лишь коды символов, а не программно отрисовывать каждый символ как набор пикселей).
Что же до этого компа... Как по мне, это уже вообще ничем не оправданное извращение.
Ну дык и в Специалисте тоже, да и много где. А сделать можно не только VGA, можно хоть 4К -- вопрос только в том, сколько проц всё это отрисовывать будет :) Поэтому лично я, если б проектировал комп на 8080, ограничился бы чисто текстовым режимом (для бытового компа это не очень-то приемлемо, но меня аркадные игры никогда не привлекали, а более-менее приличные стратегии или симуляторы, как и стрелялки и прочие РПГ, стали возможны лишь на железе совсем другого уровня).
Да, в те времена ВГ75 была одной из самых дефицитных. Хотя года эдак до 87-88 честно купить вообще практически ничего нельзя было из цифровой электроники, даже рассыпуху 155-й серии проблематично (может, через Посылторг что-то и можно было, и то под вопросом, ну а в магазинах радиодеталей -- только лампы, транзисторы, небольшое количество аналоговых микросхем -- и всё). Поэтому все ранние компьютеры, включая Микро-80, были собраны, по сути, на ворованных деталях. Ну, коммунизм же, "всё вокруг колхозное -- всё вокруг моё" :) В общем, в тех условиях собрать Специалист действительно было проще: украсть нужные микросхемы 155-ю серии можно было практически на любом вычислительном центре, проц и КР580ВВ55 тоже уже встречались достаточно часто в промышленных изделиях, а значит, бывали и в ЗИПах тех предприятий, где эти изделия использовались, а вот ВГ75... Я его встречал вживую, если не ошибаюсь за давностью лет, только в терминалах СМ-7209, причём они польского производства, и ЗИПа к ним не было никакого -- впрочем, они никогда и не ломались.
В плане системы команд 8085 и 8080 совместимы полностью, а вот насчёт вывода INTE не помню, а смотреть даташит лениво :)
Поскольку у Вас не было цели собрать комп, которым потом можно активно пользоваться, Ваш подход представляется вполне разумным. Вот если б Вы хотели в дальнейшем им пользоваться подобно реальному Радио-86РК, что предполагает использование существующих программ, которых, всё же, не так уж мало (это по сравнению со "Спектрумом" их мало) замена 8080 на Z80 была бы ошибкой как раз в силу неполной совместимости: мало ли что начало бы выползать, и поди разберись, в чём дело...
Ну а три питания... Да, определённые проблемы сие доставляет, хотя вполне решаемые: преобразователей сейчас пруд пруди на любой вкус и цвет. "Тогда" с этим посложней было, на самом-то деле, особенно с питанием -5 В: импульсный преобразователь на рассыпухе соорудить затратно, а для линейного необходима отдельная обмотка трансформатора (как, собственно, и делали).
Я вот недавно узнал, что Z80 не полностью совместим с 8080 "снизу вверх", как это мною ожидалось: проблема во флаге переполнения и ещё чем-то там в регистре флагов. По этой причине не всякий код, написанный для 8080, будет корректно выполняться на Z80, хотя основная масса таки будет.
Ну, плюс та проблема со звуком, которая описана в статье и которую нужно решать костылём :) В общем, я бы, если б стал такое делать, взял бы всё-таки 8080 (КР580ВМ80А) -- благо, их вполне можно купить. Но, насколько понял, тут работал принцип "я тебя слепила из того что было" -- что тоже имеет право на существование, конечно.
В ногу, особенно в C/C++, может выстрелить очень много что, начиная с простого типа char (который имеет хз какой размер, да ещё может быть и знаковым, и беззнаковым -- про отсутствие контроля типов вообще промолчим).
Насчёт отсутствия локальных функций согласен. Но, как по мне, короткая и простая лямбда, вставленная прямо там, где она нужна, будет читабельней, чем отдельная, пускай даже вложенная функция (скажем, когда функции сортировки нужно передать указатель на функцию сравнения, а последняя сводится к сравнению одного поля структуры, что прекрасно укладывается в однострочную лямбду).
Вот если лямбда занимает несколько строк, то, как по мне, почти всегда лучше всё-таки оформить отдельную функцию.
У интеловских (или АМДшных) процов вполне может и не быть памяти; я и раньше встречал, что в качестве ОЗУ на время первых этапов инициализации используется кэш. Технически это вполне осуществимо, если кэш можно настроить в таком режиме. Более того, этих десятков мегабайт кэша вполне достаточно, чтоб запустить какую-нибудь там WinNT, только, скорей всего, DMA не будет работать чисто с кэшем, ему почти наверняка полностью инициализированную обычную память подавай :)
Вот как раз было сказано про "практически невозможно", что и вызывает, так сказать, большие сомнения. А не про то, что целесообразно и тем более не про то, что "это элементарно, Ватсон"
Как по мне, на ассемблере реально низкоуровневые вещи писать зачастую проще, чем на тех же сях. Для себя обычно на нём и пишу, а вот что по работе -- на це/це++, чтоб не я один мог понять, что там делается :)
Вообще-то, не совсем так. В большинстве современных ПК классический BIOS объединён с современным UEFI, поэтому может прикидываться хоть тем, хоть другим в зависимости от того, какая система загружена. Недавно я ради изврата на комп с Ryzen-что-то-там поставил MS DOS :) Работает-с.
Вообще-то, микропрограмма -- это то, что управляет работой процессора, если он с микропрограммным, а не жёстким схемным управлением. BIOS же -- самая что ни на есть программа, и то, что она сидит не в ОЗУ, а в ПЗУ, не делает его микропрограммой. Думается, на русском языке лучше содержимое ПЗУ BIOS всегда именовать прошивкой.
BIOS IBMовских персоналок не был закрытой разработкой. Исходник BIOS для IBM PC, например, опубликован в Technical Reference Manual на этот компьютер.
Хм... Почему это его "практически невозможно реализовать самостоятельно", если спецификации имеются?
Вообще, SMM -- это жуткий костыль, придуманный для того, чтоб управлять электропитанием ранних компов в условиях, когда ОС этим заниматься не умела (впервые появился в 80386SL). Обработка тех же ошибок памяти в SMM -- тоже не лучшее решение, если ОС умеет такое обрабатывать (а современные, теоретически, должны бы уметь это делать, ведь процы уже достаточно давно способны кидать прерывания при аппаратных ошибках, ну а в самых первых ПК в качестве сигнала неисправности памяти или ещё какой аппаратной ошибки использовался NMI).
Кстати говоря, у IBMовских мэйнфреймов прерывания от схем контроля были от Системы 360 до наших дней (т.е. с 1964-65 года), и ОС при возникновении такого прерывания думала, что делать дальше. Например, отказ блока памяти, если в этом блоке размещался прикладной код, приводил к "убийству" программы пользователя, но система в целом работоспособность сохраняла; отказ канала ввода-вывода приводил, понятное дело, к аварийному завершению всех выполняющихся операций ввода-вывода на этом канале, но при наличии альтернативных путей к нужным устройствам работоспособность системы, опять-таки, сохранялась, ну и т.д. и т.п.
А синяя коробка поддерживает точки останова, покомандное выполнение и всё такое прочее, что доступно в обычных программах с помощью обычных отладчиков?
Как уже правильно отмечено, эти команды и регистры не нарушают совместимость снизу вверх: они не меняют поведение процессора для тех команд, которые уже существовали, а добавляют новые возможности. А вот использование бита 2 как индикатора переполнения или внесение изменений в команду десятичной коррекции разрушает совместимость, поскольку программы, написанные для 8080, полагаются на строго определённые правила формирования результатов выполнения используемых ими команд, а нововведения в Z80 приводят иногда к получению других результатов.
Скорей, в 89-м, но, в любом случае, всё это стало появляться в самом конце Союза, когда всё уже разваливалось, а воровать и продавать краденое стали практически открыто -- заметьте, "с рук", как Вы пишите, а не в магазинах, доступных честным гражданам.
Ну, во-первых, такое бывает. В официальной доке на ОС ЕС, в девичестве OS/360, на половину сообщений об ошибках первая рекомендация -- повторить задание или перезагрузить систему и повторить задание :)
Но ценность сохранения ОЗУ -- и в возможностях для отладки. Прога зависла, но, если ты разработчик, ты можешь из монитора или что там у них в ПЗУ лежит глянуть, что творится в памяти, не вылез ли стек за границы и т.д. и т.п.
В общем, смысл в сохранении всё-таки имеется.
Мне в своё время хватало примерно 7,25 Мбайт на личном жёстком диске для дисковода ЕС-5052. Точней, я не знал, чем его можно забить: исходники занимали куда меньше, а рабочая информация (временные файлы и т.п.) пишется на рабочие диски.
Я тоже так думал, а оказалось, что есть несовместимая разница во флагах. Вот регистр флагов 8080 из интеловской доки:
А вот он же для Z80:
У 8080 бит 2 -- всегда чётность, а в Z80 в зависимости от команды там либо чётность, либо переполнение. Соответственно, в определённых ситуациях программа, успешно работающая на 8080, не будет работать на Z80. Почему для переполнения они не использовали остающиеся без дела разряды 5 и 3, непонятно.
Ещё надо за токами следить, чтоб не превысить. Но в простых случаях проблем, как правило, не возникает.
Вообще, это Cortex-M7, но конкретное семейство неважно: то ли отладчик неадекватно обрабатывает отладочную информацию, то ли компилятор некорректно её формирует. Это относится именно к сопрограммам; если их нет, отладчик работает нормально.
Что же касается ввода-вывода, то он по самой своей природе асинхронный. Запустил передачу по UARTу -- и всё, она идёт параллельно с работой процессора. Прерывания, естественно, тоже являются асинхронными. И оформлять код, который инициирует подобные операции и продолжает что-то делать после их завершения, оказалось куда удобней и читабельней с помощью сопрограмм, чем, например, в помощью подпрограмм обратного вызова или бесконечным анализом неких флагов в главном цикле. (Хотя на самом нижнем уровне, естественно, никаких сопрограмм нет и быть не может -- это достаточно высокоуровневые конструкции).
Рвёт крышу и при отсутствии оптимизации.
А сопрограммы позволяют легко и просто использовать асинхронный ввод-вывод, что на микроконтроллерах очень даже полезно, если там задачи посложней мигания светодиодами.
Практическая ценность -- в умении понимать, что там нагенерил компилятор, и при необходимости в способности отлаживаться на этом уровне. Мне, например, так пришлось отлаживать сопрограммы C++20, поскольку с ними отладчик Кейла не дружит от слова совсем (ему полностью срывает крышу). Правда, это немного более сложный случай, чем просто передача параметров в функции, но начинать-то надо с простого.
Потому что их тогда не было в готовом виде, и пришлось бы собирать на рассыпухе. Кроме того, напряжение -5В могло понадобиться (не для Радио-86РК, а вообще) и для других целей, где ток будет уже повыше -- скажем, для преобразователей уровней ТТЛ в уровни RS-232.
А, Вы про это. Я про другое говорю: как формируются битики, формирующие изображение. У Специалиста и многих других они лежат в ОЗУ, и за формирование их отвечает процессор. У а вот у Радио-86РК -- нет, там в ОЗУ лежат коды символов, а конкретные последовательности битов для отображения формирует КР580ВГ75 совместно с ПЗУ знакогенератора. По этой причине формирование изображения на Радио многократно быстрей, чем на Специалисте (нужно записать лишь коды символов, а не программно отрисовывать каждый символ как набор пикселей).
Что же до этого компа... Как по мне, это уже вообще ничем не оправданное извращение.
Ну дык и в Специалисте тоже, да и много где. А сделать можно не только VGA, можно хоть 4К -- вопрос только в том, сколько проц всё это отрисовывать будет :) Поэтому лично я, если б проектировал комп на 8080, ограничился бы чисто текстовым режимом (для бытового компа это не очень-то приемлемо, но меня аркадные игры никогда не привлекали, а более-менее приличные стратегии или симуляторы, как и стрелялки и прочие РПГ, стали возможны лишь на железе совсем другого уровня).
Да, в те времена ВГ75 была одной из самых дефицитных. Хотя года эдак до 87-88 честно купить вообще практически ничего нельзя было из цифровой электроники, даже рассыпуху 155-й серии проблематично (может, через Посылторг что-то и можно было, и то под вопросом, ну а в магазинах радиодеталей -- только лампы, транзисторы, небольшое количество аналоговых микросхем -- и всё). Поэтому все ранние компьютеры, включая Микро-80, были собраны, по сути, на ворованных деталях. Ну, коммунизм же, "всё вокруг колхозное -- всё вокруг моё" :) В общем, в тех условиях собрать Специалист действительно было проще: украсть нужные микросхемы 155-ю серии можно было практически на любом вычислительном центре, проц и КР580ВВ55 тоже уже встречались достаточно часто в промышленных изделиях, а значит, бывали и в ЗИПах тех предприятий, где эти изделия использовались, а вот ВГ75... Я его встречал вживую, если не ошибаюсь за давностью лет, только в терминалах СМ-7209, причём они польского производства, и ЗИПа к ним не было никакого -- впрочем, они никогда и не ломались.
В плане системы команд 8085 и 8080 совместимы полностью, а вот насчёт вывода INTE не помню, а смотреть даташит лениво :)
Поскольку у Вас не было цели собрать комп, которым потом можно активно пользоваться, Ваш подход представляется вполне разумным. Вот если б Вы хотели в дальнейшем им пользоваться подобно реальному Радио-86РК, что предполагает использование существующих программ, которых, всё же, не так уж мало (это по сравнению со "Спектрумом" их мало) замена 8080 на Z80 была бы ошибкой как раз в силу неполной совместимости: мало ли что начало бы выползать, и поди разберись, в чём дело...
Ну а три питания... Да, определённые проблемы сие доставляет, хотя вполне решаемые: преобразователей сейчас пруд пруди на любой вкус и цвет. "Тогда" с этим посложней было, на самом-то деле, особенно с питанием -5 В: импульсный преобразователь на рассыпухе соорудить затратно, а для линейного необходима отдельная обмотка трансформатора (как, собственно, и делали).
Я вот недавно узнал, что Z80 не полностью совместим с 8080 "снизу вверх", как это мною ожидалось: проблема во флаге переполнения и ещё чем-то там в регистре флагов. По этой причине не всякий код, написанный для 8080, будет корректно выполняться на Z80, хотя основная масса таки будет.
Ну, плюс та проблема со звуком, которая описана в статье и которую нужно решать костылём :) В общем, я бы, если б стал такое делать, взял бы всё-таки 8080 (КР580ВМ80А) -- благо, их вполне можно купить. Но, насколько понял, тут работал принцип "я тебя слепила из того что было" -- что тоже имеет право на существование, конечно.
В ногу, особенно в C/C++, может выстрелить очень много что, начиная с простого типа char (который имеет хз какой размер, да ещё может быть и знаковым, и беззнаковым -- про отсутствие контроля типов вообще промолчим).
Насчёт отсутствия локальных функций согласен. Но, как по мне, короткая и простая лямбда, вставленная прямо там, где она нужна, будет читабельней, чем отдельная, пускай даже вложенная функция (скажем, когда функции сортировки нужно передать указатель на функцию сравнения, а последняя сводится к сравнению одного поля структуры, что прекрасно укладывается в однострочную лямбду).
Вот если лямбда занимает несколько строк, то, как по мне, почти всегда лучше всё-таки оформить отдельную функцию.