Точно. Как и у всех в то время у меня был спектрум-совместымий ПК полу-заводской сборки. Сейчас посморел на распиновку Z80, в нём действительно присутствует сигнал /IORQ задающий тип доступа: к I/O или к памяти. Еще один плюс Zilog-у за то, что избавили разработчиков от лишнего гимора. :-)
p.s. я это к тому, что BASIC родился не под dos и даже не под cp/m
BASIC был создан из академического интереса, на больших ЭВМ, а применение нашел годы спустя на 8-ми битных и 16-ти битных персоналках с очень крохотной память и ограниченными аппаратными возможностями. На больших ЭВМ того времени BASIC был из разряда "не пришей рукав", он не мог конкурировать ни с FORTRAN-ом, ни с PL/I, ни с COBOL-ом ни даже с "Cи" на Мини.
BASIC использовался и как язык программирования и как операционная среда! Разработчики ПЭВМ использовали интерпретатор BASIC-а как замену операционной системы, которую, по большому счету, создать для таких ПЭВМ было невозможно из-за отсутствия внешних накопителей и малого обьема памяти. Это уже потом на 8-мибитках появятся привод гибких и жестких дисков, будет портирована CP/M и прочее DOS на её основе (или по мотивам), но в начале на этих машинках был только интерпретатор языка BASIC в различных плохосовместимых диалектах. И это был прогресс, потому как позволял использовать, пусть и убогую, ЭВМ простому Джону или Ивану у себя дома.
Я имел дело с КР580ВМ80А в конце 80-х, так что таких подробностей уже не помню. :-) Действительно, DBIN показывет только направление, а для определения типа доступа необходима микросхема контроллера шины (8228). Спасибо.
Я написал тестовую погу и заглянул в результирующий EXE. Если генерировать по второму варианту "EXE Requiring Run-Time Module", то получается коротенький файл похожий на "шитый код" в заголовке которого находится код подгрузки интерпретатора виртуальной машны из рядом лежащей библиотеки. Если выбрать первую опцию "Stand-Alone", то содержимое этой библиотеки включается в результирующий EXE, за которым следует все тот же "шитый код".
Спасибо, что включили мой username в свою статью. Прочтя Вашу статью я сильно озадачился - не выжил ли я из ума под старость лет, ведь в начале 90-х я имел дело QBasic и отчетливо помню, что никакой он не компилятор, но в Вашей статье приводятся ясные доказательства обратного. Чтож, надо разобраться. Я пошел гуглить и выяснил следующее:
Сущетсвуют целых три версии BASIC-а с похожими названиями от компании Microsoft: GW-Basic, QBasic и QuickBasic.
В состав MS-DOS сначала входил GW-Basic, с версии 5.0 его заменили на QBasic.
QuickBasic продвигался как отдельный продукт и действительно является компилирующим: содержит среду, компилятор, линкер и отладчик.
A subset of QuickBASIC 4.5, named QBasic, was included with MS-DOS 5 and later versions, replacing the GW-BASIC included with previous versions of MS-DOS. Compared to QuickBASIC, QBasic is limited to an interpreter only, lacks a few functions, can only handle programs of a limited size, and lacks support for separate program modules. Since it lacks a compiler, it cannot be used to produce executable files, although its program source code can still be compiled by a QuickBASIC 4.5, PDS 7.x or VBDOS 1.0 compiler, if available.
Моя ошибка в том, что QBasic вообще не мог генерировать .EXE файл.
Интересно посмотреть сколько занимает C++runtime в результирующем бинарнике и вообще на содержание символов в нем. Есть подозрение что с таким подходом 4МБ Вам не хватит. :)
Спасибо за статью. Всегда интересно посмотреть на чужой взгляд на давно устоявшиеся (и даже устаревшие) вещи.
Теперь немного критики. Вы так статарельно избегали погружения в устройство микропроцессоров, что незаметикли как допустили ошибку в выбранной концепции шины.
Вы правильно указали, что в 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.
Точно. Как и у всех в то время у меня был спектрум-совместымий ПК полу-заводской сборки. Сейчас посморел на распиновку Z80, в нём действительно присутствует сигнал /IORQ задающий тип доступа: к I/O или к памяти. Еще один плюс Zilog-у за то, что избавили разработчиков от лишнего гимора. :-)
PS: В i8086 тоже есть готовый сигнал M/IO.
BASIC был создан из академического интереса, на больших ЭВМ, а применение нашел годы спустя на 8-ми битных и 16-ти битных персоналках с очень крохотной память и ограниченными аппаратными возможностями. На больших ЭВМ того времени BASIC был из разряда "не пришей рукав", он не мог конкурировать ни с FORTRAN-ом, ни с PL/I, ни с COBOL-ом ни даже с "Cи" на Мини.
BASIC использовался и как язык программирования и как операционная среда! Разработчики ПЭВМ использовали интерпретатор BASIC-а как замену операционной системы, которую, по большому счету, создать для таких ПЭВМ было невозможно из-за отсутствия внешних накопителей и малого обьема памяти. Это уже потом на 8-мибитках появятся привод гибких и жестких дисков, будет портирована CP/M и прочее DOS на её основе (или по мотивам), но в начале на этих машинках был только интерпретатор языка BASIC в различных плохосовместимых диалектах. И это был прогресс, потому как позволял использовать, пусть и убогую, ЭВМ простому Джону или Ивану у себя дома.
Я имел дело с КР580ВМ80А в конце 80-х, так что таких подробностей уже не помню. :-) Действительно, DBIN показывет только направление, а для определения типа доступа необходима микросхема контроллера шины (8228). Спасибо.
Это какой-то
массовый психозглюк в пространственно-временном континууме. :)Был еще такой MS Visual Basic for MS-DOS (VBDOS), я скачал его инсталляшку и запустил в DosBox.
В меню есть опция для генерации .EXE:
Я написал тестовую погу и заглянул в результирующий EXE. Если генерировать по второму варианту "EXE Requiring Run-Time Module", то получается коротенький файл похожий на "шитый код" в заголовке которого находится код подгрузки
интерпретаторавиртуальной машны из рядом лежащей библиотеки. Если выбрать первую опцию "Stand-Alone", то содержимое этой библиотеки включается в результирующий EXE, за которым следует все тот же "шитый код".Был! Только что проверил. :)
Спасибо, что включили мой username в свою статью. Прочтя Вашу статью я сильно озадачился - не выжил ли я из ума под старость лет, ведь в начале 90-х я имел дело QBasic и отчетливо помню, что никакой он не компилятор, но в Вашей статье приводятся ясные доказательства обратного. Чтож, надо разобраться. Я пошел гуглить и выяснил следующее:
Сущетсвуют целых три версии BASIC-а с похожими названиями от компании Microsoft: GW-Basic, QBasic и QuickBasic.
В состав MS-DOS сначала входил GW-Basic, с версии 5.0 его заменили на QBasic.
QuickBasic продвигался как отдельный продукт и действительно является компилирующим: содержит среду, компилятор, линкер и отладчик.
Ни GW-Basic, ни QBasic не являются компилятором.
Ниже цитата с сайте Wikipedia: https://en.wikipedia.org/wiki/QuickBASIC
Моя ошибка в том, что QBasic вообще не мог генерировать .EXE файл.
Интересно посмотреть сколько занимает C++runtime в результирующем бинарнике и вообще на содержание символов в нем. Есть подозрение что с таким подходом 4МБ Вам не хватит. :)
Спасибо за статью. Всегда интересно посмотреть на чужой взгляд на давно устоявшиеся (и даже устаревшие) вещи.
Теперь немного критики. Вы так статарельно избегали погружения в устройство микропроцессоров, что незаметикли как допустили ошибку в выбранной концепции шины.
Вы правильно указали, что в 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.