Comments 87
У меня вопрос насчет эмуляторов. Есть ли сейчас активные проекты по разработке эмуляторов? Нет ли акивных проектов разработки эмуляторов под web assembly?
Есть ещё открытый проект хардварного эмулятора на микроконтроллере: zx-pk.ru/threads/30072-emulyator-bk-0011m-na-esp8266.html
WebAssembly – хорошая идея, я не слышал об эмуляторе БК, но было бы здорово. Если задумаете взяться, я с удовольствием поучаствую.
Ну и свой основной эмулятор (UKNCBTL) тоже собирал под WASM — nzeemin.github.io/ukncbtl-wasm/index.html
Собрал под Windows 10, Visual Studio Community 2019. Единственно, в файле Board.cpp в строчке 169 добавил проверку:
bool CMotherboard::IsFloppyEngineOn() const
{
if (m_pFloppyCtl == NULL)
return false;
return m_pFloppyCtl->IsEngineOn();
}
и под ним даже отладил Форт систему уже для реального железа функционирующего в рамках некоторой самопальной IDE. (сам эмулируемый процессор поддерживал передачу по COM порту и поэтому его можно было соединить через виртуальный COM порт на этом же компьютере с IDE)
P.S. Программирование, в пределах этого инструментария, было на «высокоуровневом» ассемблере (if, else, while ...) в рамках этой IDE с расширенными псевдокомандами ассемблера. IDE тоже была на диалекте Форта (Win32Forth), а эмулируемый процессор на Форт системе (SPF4)
До сих пор есть желание сделать эмулятор на каком нибудь контроллере (типа STM32)
А, для того же ZX-Spectrum делал прошивку ПЗУ с русификацией и турбированием.
а к редактору TLW подключил 64-е клавишную клавиатуру.
Ну и где то остались дискетки от ZX-Spectrum с каким то своим ассемблерным программированием и играми (может уже и не читаются после такого времени ) :)
Есть еще Open-Source эмулятор для Android — BkEmu. Разрабатываю я его не то чтобы очень активно, но баги фиксятся и даже иногда добавляются новые фичи. Люди запускали его даже на видеотелефоне. :)
Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.Программировать во время отпуска, это не роскошь, а скорее профдеформация. На море съездить, в поход, сменить род деятельности, банально отоспаться… но нет. Как вы не выгораете? И не боитесь ли выгореть?
И демки с музыкой в MP3-формате — не демосцена.
Что касается демок с музыкой в mp3 формате, то всё зависит от демки. Само наличие там mp3 музыки ни о чём не говорит.
Второе: видеоряд не «полностью заимствован». Здесь можно увидеть как я рисовал 3D-вставки: twitter.com/Manwe_sns/status/1177540242125066240
Третье: когда в демках начали использовать MP3, это было встречено негативно. Потом ещё на Амиге начали играть неупакованную музыку прямо с диска — это вообще было фу. Я и сам так считал, и отчасти до сих пор придерживаюсь такого мнения. В идеале всё должно быть в риалтайме. Но демо-сообщество в целом переварило и смирилось с использованием потоковой музыки в демо. У нас в «Good Apple» тоже неупакованная потоковая музыка. Будем за это ругать или как? Просто чтобы я смог понять объективность подхода.
Ну и четвёртое: да, это «демонстрация технологии». Никто же не обманывает, не говорит, что силуэты рендерятся в 3D в реальном времени. Была изобретена технология упаковки и скоростного вывода видео. Идею бесшовного вывода звука ещё за полгода до этого придумали Excess Team. Всё это в сочетании, а также титры с многоцветным трюком — некий законченный продукт. Как его назвать, если не «демо»?
На БК словом «демо» называли вообще всё что попало: например, многочисленные подборки музыки под пищалку. Или взять наш прошлогодний релиз «In Your Space» — для БК-сцены это вполне «демо», хотя там даже на экране ничего не изменяется во время проигрывания музыки.
Мне кажется, надо просто смотреть контекст: в каком состоянии находится демосцена на той или иной платформе. Где-то помигать курсором — уже демо. А на другой платформе это пффф.
КДПВ:
Эх были же времена. Помню, как мне нравился ассемблер PDP-11, с его выразительной системой команд. Когда перешел на PC и начал профессионально и заниматься программированием, ностальгия стала такой сильной, что даже пришлось написать эмулятор. Система команд PDP-11 оказалась настолько простой и логичной что у меня сходу запустился монитор и даже некоторые программы, хотя я писал по памяти, не заглядывая в документацию. БЕЙСИК все же не заработал, так как о использовал несколько хитрых команд в реализации которых я допустил ошибки, а о существовании парочки я даже не подозревал. Пришлось тогда искать материалы, того же Юрия Зальцмана и т.д. Удивительно что спустя 20 лет проект всем еще жив и приносит пользу. Спасибо большое тому замечательному человеку, который поддерживает и развивает его сейчас.
… прочувствовать всю красоту и изящество DEC’овского ассемблера: абсолютно равноправные регистры, восемь методов адресации, линейная память – красота!Небольшое уточнение: все почти так, но некоторые регистры все же были "равноправнее" других. R6: стек RS и R7: счетчик команд PC, всеже неявно использовались некоторыми специальными командами и по другому интерпретировались в автоинкремендах и автодекрементах. Так MOVB #377, -(SP) сдвигает адрес на 2 (слово), а не на байт, как можно было бы ожидать с другими регистрами.
Если нужна высокая скорость, то лучше очищать память не побайтно, а сразу словами. Получится вдвое быстрее. Но можно ускориться сверх того: по какой-то причине команда CLR работает медленней, чем MOV. Поэтому:CLR(Rd), сначала загружала значение из указанного адреса в R0, потом обнуляла его, а потом уже загружала обратно. MOV Rs, (Rd) не делала лишней загрузки из памяти. Я точно не помню уже зачем это было нужно. По-моему, CLR необходимо было выставить флаги состояние процессора NZCV на основании предыдущего значения операнда.
Мне больше нравился такой код "защиты от стопа":
SUB (PC),(SP)<br> RTI
Вроде ничего не напутал. Он одной командой вычитал 2 (т.к в момент выполнения PC указывает на адрес RTI — opcode которой как раз двойка) из PC сохраненного в стеке, который тут же восстанавливался при возврате с помощью RTI, что приводило к выполнению последней прерванной команды.
Я прошёлся трассировкой по ПЗУ, выявил как можно слегка перехитрить алгоритм загрузки с магнитофона и заставить БК читать данные в 4 раза быстрее.
На БК был загрузчик Turbo, если не ошибаюсь, авторства Саяпина, который повышал скорость чтения — записи с аудионосителей примерно на порядок. Причиной тому использование четырёхтональной записи (вместо стандартной двух), и оптимизация кодирования, когда наиболее часто встречаемые последовательности кодировались более высокочастотными тонами, что дополнительно повышало скорость обмена.
Но я хотел добиться повышения скорости загрузки без сторонних решений, то есть читать разогнанные звуковые файлы стандартной подпрограммой из ПЗУ, чтобы это работало во всех играх и программах. Больше 4-кратного прироста у меня не получилось.
Ну а потом сделал и турбо-формат свой. Вариант с 4-тоновым сигналом поначалу тоже рассматривал (смотрел код Help12), но в итоге пришёл к тому, что чем меньше код загрузчика, тем лучше. Поэтому турбо-формат у меня простой как валенок, загрузчик микроскопический, скорость вполне устраивает (в 8 раз выше нормы).
Был такой подход к ускорению загрузки/записи, но на практике пользоваться им было очень трудно. Уж больно этот загрузчик был требовательным к качеству ленты и оборудования. Малейшее провисание ленты или повреждение и все сохраненные данные в помойку. Дисковод в это смысле был гораздо практичнее и надежнее.
Копировщик назывался HELP7. Две копии файла люди писали почти всегда — даже в стандартном формате: магнитофоны имели тенденцию время от времени "зажёвывать" плёнку, после чего в этом месте информация восстановлению (на доступной тогда аппаратуре) не подлежала. Вторая копия предназначалась для спасения как раз от таких случаев (такой вот RAID на кассетах). У меня сохранилась записанная им кассета — как-нибудь покажу осциллограмму.
Дисковод появился на БК позже уже. Касаемо саяпинского Турбо, он, помнится, писал, данные поблочно и двумя копиями, так что если вдруг была какая-то проблема со считыванием, она решалась чтением того же блока из второй копии.
Причина в том, что этот кодировщик наиболее плотный из простых (без частотной манипуляции и фазовой манипуляции) и легко реализуется снятием сигнала с цифровой микросхемы практически без подготовки.
Но главное свойство этого кода в том, что он САМОсинхронизирующийся. САМО, означает, что носитель информации, несущий этот код может быть нестабильным (что в условиях использования бытового магнитофона, или при передаче через дальний эфир — очень актуально).
У Манчестера-2 синхронизация происходит в каждом такте — при передаче каждого символа. Нестабильность может достигать до 25% частоты передачи или записи.
Т.е. теоретически, каждый следующий такт (символ или бит — плотность Манчестера-2 — это 1 бит на символ) может иметь частоту на 25% отличающуюся от предыдущего символа. За счёт этого совершенно неважно какой формы сигнал и насколько плохой тракт записи-воспроизведения используется — по барабану — код всё исправит.
Поэтому этот код очень устойчив к среде носителя. Конечно глушение сигнала не спасёт, но для этого на простых системах использовали либо просто повтор, либо индикацию сбоя т.е. просто подсчёт контрольной суммы (CRC32). На сложных системах — перемежение инфы и восстанавливающие коды (чаще всего eat-Salmon )). Конечно не такие мощные как на компакт-дисках, но и плотность инфы на носителе была в то время невысокая — так что хватало перемежать блок на 4-8 байтов (У CD блоки что-то около от 2-х до 8-ми килобайт).
Так что никакие многотональные кодировщики не могли быть плотнее и устойчивее, чем Манчестер-2 в то время.
Любое уплотнение и фазовая манипуляция требовала либо колоссальное повышение затрат (объёма вычислений в реальном времени), либо спец микросхем, на что пойти не могли изготовители оборудования (либо дорого, либо невозможно). Это всё позже родилось. В CD — наиболее массово.
Да, но нет.
Как человек много в те годы работавший над вскрытием защит от копирования на магнитной ленте (а потом и на флоппи, но это уже другая история), могу сказать что в БК настройка на частоту и, соответственно, скорость протяжки, во всех форматах записи производилась на основе начальной тональной настроечной последовательности. Исходя из произведённых замеров — импульсов за заданную единицу времени или тактов процессора, в случае с БК, далее производился анализ основных тонов, которыми кодировалась информация. Контроль на основе CRC32.
Никакой подстройки в процессе или кодов Рида-Соломона там не было. Хотя для последних попадалась где-то сторонняя реализация.
Но возможно я что-то запамятовал, конечно.
Настроечный тон БК использует так: высчитывает его период, умножает на 1.5 и любой импульс который длинней этой величины считает за 1, а любой который короче – за 0. Получается, что допустим люфт ~ 25%.
Полностью формат записи БК я описал здесь (и способ его оптимизации): ссылка дана в статье.
В формате БК после каждого бита зачем-то вставлен синхроимпульс. Я не понял смысла этих синхроимпульсов. Ощущение, что это какой-то ментальный артефакт, стереотип программиста: мол, деды ставили синхроимпульсы, и мы должны ставить. В итоге длительность записи увеличивается аж на 150% (в среднем). Лучше бы убрали синхроимпульсы и замедлили звук вдвое – надёжность сильно возросла бы.
В своём турбо-формате я использовал что-то типа Манчестера-2 (хотя и не знал о существовании такого). Просто это самый очевидный, короткий и быстрый метод передачи, допускающий небольшой люфт частоты сигнала.
Ivanq экспериментировал и с другим методом, без самосинхронизации. Там частоты намного превышают слышимый спектр (у нас профессиональная внешняя звуковая карта T.C. Electronic с частотой 96 КГц). БК даже читает десяток-другой байт, после чего сбивается. За clock звуковой карты я спокоен, дело в неточности кварца БК. Так что без самосинхронизации никак не получается.
В детстве я вообще считал что около 4 кбайт доступно пользователю, остальное — пзу и экранная память.
Кто может подсказать спецификацию, которая в то время поставлялась в учебные заведения?
Интернет говорит что 32 кб… Но я помню, как некоторые программы, которые дома писал в тетрадке, не помещались в память компа.
Значит 16 кбайт для пользователя. Спасибо.
Насколько я помню, один из кассетных копировальщиков (copycopy) именно так и работал — код расположен в верхней трети, меню посредине, вся остальная память — для хранения копируемого содержимого.
Они еще и данные сжимали на лету. А 128ые переключали страницы и могли загрузить непрерывный файл вплоть до 120 кб. Лента-диск копировщики Родионова и МОА тоже умели использовать расширенную память. Особенно кдобно это было при записи с диска на кассету — напихал файлы на сколько памяти хватило, и он пишет. Причем Родионовсеий грузил с ленты лучше. И поддерживал скриптинг. Можно было хоть всю кассету автоматически записать.
Его записывали с эмулятора? Интересно было бы послушать запись с реальной железки.
Могу на следующей неделе записать в линию и выложить.
А они по качеству сильно разные, кучка резисторов это одно, микросхема совсем другое. А если резисторы подстроечные многооборотистые а питание ключей стабилизированно и всё это в ручную настраивается то можно вообще проф пригодный вариант получить.
В общем, R-2R решае, а разочарование в ково сах постигало лишь особо жадных до резисторов.
PS: да, да, собиралась плата в те годы вручную, все радиодетали втыкались, потом специально обученные женщины их паяли, потом мы кисточками наносили латекс на контакты, после купания в лаке, их ножиками и пинцетами сдирали. Потом вибро-стенд, печка, морозильник по нескольку раз.
БК была потом. Начали с другом писать в машинных кодах. Написали SUPERCALC. Работало. Даже формулы переносились. Фокал, Клад, Тетрис… Basic.
А еще вечная обида — IBM PC была в стотысяч раз круче БК-0010, а книжка Л.Пула — волшебной (всё выбросил, а её оставил).
P.S. Сейчас всё лучше. Это очень вдохновляет.
Тоже этим летом игрался с легендарным PDP-11, правда в лице МК-90, и тоже участвовал в CC. Программирование под древние платформы, конечно, очень увлекательное занятие!
Но меня терзает вопрос какие сайты может создавать ребёнок 13 лет?
Ну или, чтобы далеко не ходить, вот сайт, созданный ребёнком в 10 лет (фронтэнд и бэкэнд): thesands.ru/forth-demotool
Кстати, тут у нас, на Хабре, есть AlexeyNadezhin который теперь главный по лампочкам. Так вот он, будучи автором самого популярного DOS для этих машин, может много чего рассказать про БК...
Великолепная работа! Отсылка к рекламе айподов понравилась — ныне и сам эпл точно так же потерял себя и (надо надеяться) мечется в поисках :-)
Надо по возвращении домой попробовать что-то подобное на МК-90 замутить :-)
Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher.
Эх, а вот такие, если их можно назвать, "продукты", человеку, понимающему в производительности и оптимизации, упоминать должно быть стыдно...
Что касается оптимизации, для меня было важно наладить как можно более простой и быстрый процесс разработки. Упомянутая утилита позволяет записывать образ флешки за 2 клика. Более простого решения для MacOS я не нашёл. Под Windows пользуюсь также программой USB Image Tool – она хороша во всём, но всё же требует чуть больше движений.
Достал с полки тетрадку с записями из детства — все заработало! Даже клавиатура привычно глбючила, пока не нашел опцию, что можно отключить идентичную эмуляцию клавиатуры =)
по какой-то причине команда CLR работает медленней, чем MOV.
По той причине, что в микропрограмме CLR x реализована как BIC x, x (нестрого говоря, "сбросить в числе X биты по маске X"), то есть ячейку назначения надо сначала прочитать, а потом записать. А MOV R2, x сразу пишет (чтение из регистра ожидаемо быстрее чтения из памяти).
At the core, the demo consists of an animplayer (which is an image sequence playback program) that takes its data and calculates the graphics data at runtime, resulting in a line drawer to create the polygons and blitter to fill them.
To do this, they took their footage, and had it displayed fame per frame as a bitmap. Now they would not store these bitmaps but rather have a coder outline the image and store this basic data to disk. The lines could then be created at runtime as mentioned above, requiring very little disk space.
какие тёплые лампочки... БК0011М+ был мой последный перед уходом в х86, точнее... была искра 1031 (кажется), потом БК, параллельно проскочили АТАРИ, во второй раз... потом всё это было продано, и дальше уже только х86... хотя, сейчас у меня есть и маки, и амиги и атари...
Программирование под БК 0010 в 2019-ом году