Спасибо за статью. Всегда интересно посмотреть на чужой взгляд на давно устоявшиеся (и даже устаревшие) вещи.
Теперь немного критики. Вы так статарельно избегали погружения в устройство микропроцессоров, что незаметикли как допустили ошибку в выбранной концепции шины.
Вы правильно указали, что в i8080 имеются специальные инструкции для работы с портами ввода/вывода (как и во всех последующих сериях микропроцессоров Intel, кстати). Для реализации этих инструкций на корпус микропроцессора i8080 выведен специальный сигнал DBIN, который указывает на то, с чем будет осуществляться обмен - с памятью или с I/O устройством. Это означает, что адреса устройств могут пересекаться с адресами ячеек памяти и это не создает никаких проблем для аппаратуры, так как декодер адреса учитывает этот сигнал. В выбранной Вами модели шины данного сигнала нет, а значит возникает "конфликт интересов" выражающийся в отсутствии возможности использовать младшие адреса ячеек памяти которые по номерам пересекаются с портами ввода/вывода. Скорее всего этой проблемы Вы не заметили, так как работали в основном с MOS 6502, где I/O организован через memory-mapped регистры, но с i8080 и i8086 эта проблема выплывет и Вам придется переделать шину.
Выбранный Вами способ задания диапазонов устройств на шине не тольно не оптимальный, он неправильный. :) При реализации аппаратуры, блок I/O регистров конкретного устройства обычно задается в виде базового адреса и битовой маски (или префикса указывающего длину лидирующей части адреса). Это позволяет легко, одной операцией AND, вычислить тэг для определения утройства к которому производится обращение. Я думаю, Вам следовало бы сделать то же самое - сохранять в std::map карту тэгов и указателей на обьект Device. Это избавило бы от необходимости каждый раз вызывать метод find(), который итеративно бегает по массиву и бездарно потребляет процессорное время, а доступ к устройству - всего пара инструкций реального процессора.
Вообще, я настоятельно рекомендую ознакомиться с принципами реализации классических микропроцессоров, то есть слегка погрузиться в мир микроархитектуры. Вы найдете там очень много интересных и нестандартных, в то же время очень простых, решений, которые упростят Вам программирование Вашего симулятора. Еще раз спасибо.
AFAIK, он не был компилируемым как таковым, просто среда упаковывала интерпретатор с кодом в один .EXE файл. Нормальных компиляторов с "Васика" я не встречал.
Действительно лучше сразу изучать Си. Но детям требуется какой-то эффект быстро и сейчас (проиграть мелодию, нарисовать картинку линиями). В этом смысле Basic более пригоден. Чтобы добраться до графического контекста на Си, придется написать километры кода попутно освоив ряд нетривиальных концепций и парадигм.
Каким бы хорошим не был Basic, это всё равно интерпретируемый язык. Взрослые парни пишут на компилируемых языках. В этом смысле все питонисты - дети. ;)
BBC Basic созданный для машины BBC Micro был с самого начала весьма гибким языком структурного программирования. Более того, он развивается по сей день, в него добавили поддержку SDL2 и портировали на многие платформы. Есть ряд примеров достаточно сложных игр с 3D графикой. На мой взгля это самый подходящий вариант ЯП для школьника младших классов. После него не страшно переходить к изучению Си.
REM Geography quiz
PRINT "What is the capital of France:"
PRINT "a) Paris"
PRINT "b) London"
PRINT "c) Madrid"
INPUT "Enter a,b or c: " Reply$
CASE Reply$ OF
WHEN "A", "a": PRINT "Correct"
WHEN "B", "b": PRINT "Sorry, that's England"
WHEN "C", "c": PRINT "Sorry, that's Spain"
OTHERWISE: PRINT "Sorry, invalid response"
ENDCASE
END
Ну, USB 1.0 вообще не является дифф линией, а в USB 2.0 есть её жалкое подобие. Зато аппаратная часть очень просто реализуется и не требуется дорогостоящих трансиверов. При желании можно программно модулировать сигнал на шине. Иными словами, USB взял рынок дешевизной.
На мой взгляд маркер EOP это очень годное решение - избавляет от необходимости вводить поле с размером пакета или полезной нагрузки, занимает всего три битовых интервала.
На мой взгляд FireWire гораздо более сложен в реализации. Если перенестись в конец 90-х, то можно понять что не всякий производитель мог себе позволить проектировать такие сложные интерфейсы. USB 1.0 (и даже 2.0) относительно простой протокол. Ну и я думаю Apple приложила не мало усилий, чтобы усложнить сторонним разработчикам адаптацию этого стандарта.
У USB и PS/2 абслютно разные электрические интерфейсы, это не просто посылка байтов. Никакой совместимости между этими двумя стандартами нет и быть не может. Может быть только общий уровень абстракций, как например в Input Device в Linux который формирует общий поток событий для ПО прикладного уровня.
Я мечтаю о ПЛИС с классической архитектурой логического блока (5/6-LUT + FF + 1-bit ALU + MUX) с гигантским количеством блоков и линий интерконнекта, выполненный по топовым нанометрам. Есть какое-то внутреннее чувство, что Ваш тестовый проект на такой ПЛИС мог бы выдать Fmax = 1 ГГц. Но прогресс ушел куда-то не туда.
Я добавил в конце статьи ссылку на презентацию (PDF, 56 слайдов) к моему докладу на эту же тему с которым я выступил на конференции FPGA-Systems 2025 прошедшей 29 ноября 2025 в Москве. Это для тех, кто хочет быстро ознакомиться с содержимым статьи не читая её. :-)
На Wikipedia в статье про PS/2 написано, что некоторые клавиатуры и мыши, предназначенные для работы в процессе загрузки ОС, могут определить куда они подключены и задействовать две имеющиеся сигнальные линии либо для встроенного USB Device устройства, либо для PS/2. Для этого промышленностью выпускались специальные переходники позволяющие подключить одно и то же устрйство с USB type A разъемом либо в USB type A (HID), либо в круглый PS/2. Но это не совместимость на уровне стандартов, это такой костыль от производителей устройств ввода нацеленный на облегчение перехода пользователей на USB HID.
Спасибо. Про V-USB мне подсказали на конференции FPGA-Systems уже после моего доклада, не знал. Хочу посмотреть как там вычисляется CRC16 и при этом библиотека успевает вложиться в жесткие тайминги. У меня это сделать не получилось на RV32 ядре 60+ МГц, поэтому пришлось отдать расчет CRC на железную часть.
Честно говоря я не представляю как это возможно. PS/2 это последовательный синхронный интерфейс с побайтовой передачей работающий на частотах 7-12 кГц, у него два сигнала: DATA и CLK, оба имеют TTL уровни +5V. USB 1.0 - это асинхронная шина с пакетной коммутацией, сигналы D+ и D- имеют уровни +3.6V max, частоты: 1.5 и 12 МГц. Как это совместить ?
Не обязательно тестировать на изделии, которое скорее всего существует в единичном экземпляре, достаточно протестировать на аналогичном железе - поставьте себе рядом одноплатный комп для экспериментов и издевайтесь над ним сколько душе угодно. Это все равно лучше чем виртуалка и ближе к реальному сетапу.
Коллега, я вижу что Вы не знакомы с теорией эксперимента (либо у Вас какая-то странная интепретация). А она гласит, что измрение длинной дистанции полученное с помощью 100 палочек по сантиметру будут менее точны чем измерение полученное палкой длиной в 1 м, так как у каждой палочки по сантиметру есть своя ошибка и эта ошибка будет накапливаться быстрее ровно в 100 раз. Иными словами, важна не частота дискритизации (размер кванта времени), сколь её точность. Какова ошибка измерения этого кванта в 1/430ТГц ? Об этом в статье нет ни слова. И журналист изнасиловавший ученого совершенно не понимает этого момента. Безусловно, уменьшение кванта времени до 1/430ТГц дает большие возможности - меньшим кваном можно проводить измерения очень коротких промежутков времени, что раньше было невозможно. Но не надо примешивать сюда точность измерения - она может быть какой угодно и зависит от постановки эксперимента.
Круто! Но как самому захостить Ваше решение ? Не хочу загружать к Вам свои файлы. В наше трудное время от облачных решеный надо избавляться, а не плодить их.
Руководство очень плохое! Такое руководство отпугнет всякого желающего пропатчить драйвер или написать свой. Хотя на практике это тривиальные задачи не требующие никаких Docker-ов и прочей чешуи.
Спасибо за статью. Всегда интересно посмотреть на чужой взгляд на давно устоявшиеся (и даже устаревшие) вещи.
Теперь немного критики. Вы так статарельно избегали погружения в устройство микропроцессоров, что незаметикли как допустили ошибку в выбранной концепции шины.
Вы правильно указали, что в i8080 имеются специальные инструкции для работы с портами ввода/вывода (как и во всех последующих сериях микропроцессоров Intel, кстати). Для реализации этих инструкций на корпус микропроцессора i8080 выведен специальный сигнал DBIN, который указывает на то, с чем будет осуществляться обмен - с памятью или с I/O устройством. Это означает, что адреса устройств могут пересекаться с адресами ячеек памяти и это не создает никаких проблем для аппаратуры, так как декодер адреса учитывает этот сигнал. В выбранной Вами модели шины данного сигнала нет, а значит возникает "конфликт интересов" выражающийся в отсутствии возможности использовать младшие адреса ячеек памяти которые по номерам пересекаются с портами ввода/вывода. Скорее всего этой проблемы Вы не заметили, так как работали в основном с MOS 6502, где I/O организован через memory-mapped регистры, но с i8080 и i8086 эта проблема выплывет и Вам придется переделать шину.
Выбранный Вами способ задания диапазонов устройств на шине не тольно не оптимальный, он неправильный. :) При реализации аппаратуры, блок I/O регистров конкретного устройства обычно задается в виде базового адреса и битовой маски (или префикса указывающего длину лидирующей части адреса). Это позволяет легко, одной операцией AND, вычислить тэг для определения утройства к которому производится обращение. Я думаю, Вам следовало бы сделать то же самое - сохранять в std::map карту тэгов и указателей на обьект Device. Это избавило бы от необходимости каждый раз вызывать метод find(), который итеративно бегает по массиву и бездарно потребляет процессорное время, а доступ к устройству - всего пара инструкций реального процессора.
Вообще, я настоятельно рекомендую ознакомиться с принципами реализации классических микропроцессоров, то есть слегка погрузиться в мир микроархитектуры. Вы найдете там очень много интересных и нестандартных, в то же время очень простых, решений, которые упростят Вам программирование Вашего симулятора. Еще раз спасибо.
Скорее всего Вы правы, мне на глаза попадались только QBASIC и Visual Basic. Оба умели генерировать .EXE, но не настоящий. :)
AFAIK, он не был компилируемым как таковым, просто среда упаковывала интерпретатор с кодом в один .EXE файл. Нормальных компиляторов с "Васика" я не встречал.
Действительно лучше сразу изучать Си. Но детям требуется какой-то эффект быстро и сейчас (проиграть мелодию, нарисовать картинку линиями). В этом смысле Basic более пригоден. Чтобы добраться до графического контекста на Си, придется написать километры кода попутно освоив ряд нетривиальных концепций и парадигм.
Каким бы хорошим не был Basic, это всё равно интерпретируемый язык. Взрослые парни пишут на компилируемых языках. В этом смысле все питонисты - дети. ;)
BBC Basic созданный для машины BBC Micro был с самого начала весьма гибким языком структурного программирования. Более того, он развивается по сей день, в него добавили поддержку SDL2 и портировали на многие платформы. Есть ряд примеров достаточно сложных игр с 3D графикой. На мой взгля это самый подходящий вариант ЯП для школьника младших классов. После него не страшно переходить к изучению Си.
Номера строк давно являются необязательными. Вот пример более длинной программы на BBC Basic с процедурами и структурами.
Занимательная некромантия ? Похвально.
Есть такая штука Unofficial port of GCC toolchain to 16-bit Intel x86 target. Сам не проверял, не уверен что C++ компилит нормально.
Ну, USB 1.0 вообще не является дифф линией, а в USB 2.0 есть её жалкое подобие. Зато аппаратная часть очень просто реализуется и не требуется дорогостоящих трансиверов. При желании можно программно модулировать сигнал на шине. Иными словами, USB взял рынок дешевизной.
На мой взгляд маркер EOP это очень годное решение - избавляет от необходимости вводить поле с размером пакета или полезной нагрузки, занимает всего три битовых интервала.
На мой взгляд FireWire гораздо более сложен в реализации. Если перенестись в конец 90-х, то можно понять что не всякий производитель мог себе позволить проектировать такие сложные интерфейсы. USB 1.0 (и даже 2.0) относительно простой протокол. Ну и я думаю Apple приложила не мало усилий, чтобы усложнить сторонним разработчикам адаптацию этого стандарта.
У USB и PS/2 абслютно разные электрические интерфейсы, это не просто посылка байтов. Никакой совместимости между этими двумя стандартами нет и быть не может. Может быть только общий уровень абстракций, как например в Input Device в Linux который формирует общий поток событий для ПО прикладного уровня.
Я мечтаю о ПЛИС с классической архитектурой логического блока (5/6-LUT + FF + 1-bit ALU + MUX) с гигантским количеством блоков и линий интерконнекта, выполненный по топовым нанометрам. Есть какое-то внутреннее чувство, что Ваш тестовый проект на такой ПЛИС мог бы выдать Fmax = 1 ГГц. Но прогресс ушел куда-то не туда.
Я добавил в конце статьи ссылку на презентацию (PDF, 56 слайдов) к моему докладу на эту же тему с которым я выступил на конференции FPGA-Systems 2025 прошедшей 29 ноября 2025 в Москве. Это для тех, кто хочет быстро ознакомиться с содержимым статьи не читая её. :-)
На Wikipedia в статье про PS/2 написано, что некоторые клавиатуры и мыши, предназначенные для работы в процессе загрузки ОС, могут определить куда они подключены и задействовать две имеющиеся сигнальные линии либо для встроенного USB Device устройства, либо для PS/2. Для этого промышленностью выпускались специальные переходники позволяющие подключить одно и то же устрйство с USB type A разъемом либо в USB type A (HID), либо в круглый PS/2. Но это не совместимость на уровне стандартов, это такой костыль от производителей устройств ввода нацеленный на облегчение перехода пользователей на USB HID.
Спасибо. Про V-USB мне подсказали на конференции FPGA-Systems уже после моего доклада, не знал. Хочу посмотреть как там вычисляется CRC16 и при этом библиотека успевает вложиться в жесткие тайминги. У меня это сделать не получилось на RV32 ядре 60+ МГц, поэтому пришлось отдать расчет CRC на железную часть.
Честно говоря я не представляю как это возможно. PS/2 это последовательный синхронный интерфейс с побайтовой передачей работающий на частотах 7-12 кГц, у него два сигнала: DATA и CLK, оба имеют TTL уровни +5V. USB 1.0 - это асинхронная шина с пакетной коммутацией, сигналы D+ и D- имеют уровни +3.6V max, частоты: 1.5 и 12 МГц. Как это совместить ?
Отлично, спасибо.
Описать то, что заявлено у Вас в заголовке статьи (подробное руководство разработчика ядра), в том числе:
устройство Kconfig;
струтуру драйверов ядра;
структуру Device-Tree и зачем это всё нужно;
как собсно пропатчить код, собрать ядро и проверить результат;
как правильно сделать патч, проверить его и отправить в upstream.
Ну и все это на примере добавления заявленой функции PROTO_DOWN в драйвер сетевого интерфейса.
Не обязательно тестировать на изделии, которое скорее всего существует в единичном экземпляре, достаточно протестировать на аналогичном железе - поставьте себе рядом одноплатный комп для экспериментов и издевайтесь над ним сколько душе угодно. Это все равно лучше чем виртуалка и ближе к реальному сетапу.
Коллега, я вижу что Вы не знакомы с теорией эксперимента (либо у Вас какая-то странная интепретация). А она гласит, что измрение длинной дистанции полученное с помощью 100 палочек по сантиметру будут менее точны чем измерение полученное палкой длиной в 1 м, так как у каждой палочки по сантиметру есть своя ошибка и эта ошибка будет накапливаться быстрее ровно в 100 раз. Иными словами, важна не частота дискритизации (размер кванта времени), сколь её точность. Какова ошибка измерения этого кванта в 1/430ТГц ? Об этом в статье нет ни слова. И журналист изнасиловавший ученого совершенно не понимает этого момента. Безусловно, уменьшение кванта времени до 1/430ТГц дает большие возможности - меньшим кваном можно проводить измерения очень коротких промежутков времени, что раньше было невозможно. Но не надо примешивать сюда точность измерения - она может быть какой угодно и зависит от постановки эксперимента.
Круто! Но как самому захостить Ваше решение ? Не хочу загружать к Вам свои файлы. В наше трудное время от облачных решеный надо избавляться, а не плодить их.
Руководство очень плохое! Такое руководство отпугнет всякого желающего пропатчить драйвер или написать свой. Хотя на практике это тривиальные задачи не требующие никаких Docker-ов и прочей чешуи.