Комментарии 98
У меня вопрос насчет эмуляторов. Есть ли сейчас активные проекты по разработке эмуляторов? Нет ли акивных проектов разработки эмуляторов под 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... хотя, сейчас у меня есть и маки, и амиги и атари...
Уважаемый @Manwe_SandS, извините что я слегка подзапозднился на Вашу вечеринку, но у меня есть технический вопрос. Скажите, какой скорости чтения (в байт/сек) можно достичь в турбо режиме через стандартный магнитофонный вход БК ?
Теперь поясню зачем это мне. В конце 80-х я также прогал на БК 0010-01 и у меня была идея которую по тем временам реализовать не удалось. Идея состоит в том, чтобы непрерывно считывать с магнитнной ленты данные и визуализировать их на экране в маленькое окошко размером 32x32 пикселя, таким образом получив примитивный видеопроигрыватель (в детстве мы все мечтали иметь свой японский видеомагнитофон). Картинка размером 32x32 @ 5 Гц это примерно 640 байт/сек сырых данных. Если их пожать простейшим RLE то можно уменьшить поток вдвое. Способен ли такой битстрим просочиться через магнитофонный порт стандратной, немодифицированной БК ?
Да, мой турбо-загрузчик выдаёт 1285 байт в секунду на стандартной БК 0010. Насколько я знаю, это самый быстрый из существующих загрузчиков на БК. Правда, магнитофон и кассета понадобятся очень качественные. А лучше воспроизводить WAV с компьютера, качественного телефона или mp3-плеера (только не сжимать звук в mp3, а воспроизводить wav или flac без потерь). Я использую iPhone 6 Pro для этих целей, всё стабильно работает.
Вообще, идея классная. Можно стримить Bad Apple с магнитофона. Даже на 1-битный звук скорости хватит, если переделать загрузчик. А в идеале можно записать код в левый канал, оригинальную музыку в правый канал, разделить каналы разветвителем и направить один в БК, второй в динамик. Получится цифровое видео + аналоговый звук.
Я посчитал: картинка в разрешении 20x20 точек = 100 байт, при скорости 1285 байт в секунду получаем почти 13 fps. Прикинул как смотрится Bad Apple в таком разрешении – вполне узнаваемо. Для монохромного экрана это даже 40x20, что уже гораздо лучше.
А 32x32 пикселя – это 256 байт на кадр, тогда получаем всего 5 кадров в секунду. Слишком дискретно.
Александр, большое спасибо за ответ.
5 кадров в секунду это овердохрена! Вы помните какая была анимация в играх на БК ?
Моё видение технологии стриминга видео на БК следующее:
Картинку 32x32x2 (два бита на цвет) нужно сжимать простейшим алгоритмом (RLE хорошо подходит для битмапов и прост в реализации). После сжатия в битстрим добавлять избыточное кодирование (Hamming 7/4) и упаковывать в пакеты на подобие HDLC с небольшим заголовком. В заголовке присутствует поле "тип" ("видео", "аудио", "служебный") и поле "задержка" в мс. В служебном пакете можно передавать координаты картинки на экране и ряд простейших команд: "очистить экран", "подгрузить палитру", может быть еще что-то. Пакеты выдавать в порт магнитофона в турбо режиме, один за одним без пауз. При проигрывании, программа player читает данные из порта магнитофона, находит и декодирует пакеты, вынимает данные и складывает видео кадры в отдельный буфер. Другая часть программы изымает кадры из буфера и выводит их на экран с заданной задержкой. Если есть "аудио", то можно передавать команды на синтез звука (упрощенный MIDI, трекинговую музычку).
Грубый расчет на пальцах:
32x32x2 * 5 fps * 0.5 (RLE) * 7 / 4 (hamming) + 32 (DLC заголовок) = 8992 бит/с = 1124 байт/сек. Еще остается немного на музыку - "аудио" пакеты могут следовать с интервалами 1/10 и это впишется в бюджет магнитофона. :-)
Используя служебные пакеты можно придумать разные спец. эффекты. Таким образом аудиокассета превращается в нечто странное - потоковая демка. Помоему это новое слово в демо-дизайне. :-)
Надо тестировать сколько времени уйдёт на распаковку, может быть и нет смысла в этом. Для Good Apple я использовал дельта-модуляцию, там это оправдано из-за большого размера экрана. А на маленьком экране (кадре) может быть не нужно. У нас же по 4 точки в байте (или по 8 в ч/б режиме), и одинаковых байтов на экране будет очень мало. Тем более последовательности байтов.
Скорость сильно зависит от качества передачи, что в случае с магнитофонами было под вопросом. Качество самого магнитофона, качество ленты, скорость деградации при такой плотности записи.
Сам протокол основанный на частотах, используется же в диалап модемах, там при хорошей линии скорость достигала 56 кбит/сек, но 28 кбит/с в принципе у большинства заводилась.
Но что у нас с магнитофонами:
Качество считывания хуже.
Качество стабильности хуже - прокрутка ленты неравномерна и на высоких частотах это настолько критично, что диапазон частот сразу нужно ограничивать.
Эффективный диапазон частот из-за этого снижали до ~20 Гц до 20 кГц, что сразу снижает скорость.
В общем 2400 был пределом для магнитофонов в турбо-режиме (spectrum), на БК наверное ниже.
Думаю даже в домашних условиях можно попробовать уплотнить запись раза в два, но стабильности не будет, даже если прочитается с первого раза, со второго уже может не прочитаться. Ну и ретрейн в условиях кассетного магнитофона (в отличие от модемов) технически невозможен, поэтому один сбой на протяжении всего участка - и все.
В эмуляторах можно поэкпериментировать, проигрывая wav/mp3, там можно попробовать достичь теоретического максимума в условиях заданного диапазона частот.
Копировщик CF50 записывает на максимальной скорости 272 байта в секунду на БК 0010. Такое читалось с хороших кассет и на хороших магнитофонах. Причём, это не турбо-загрузчик, а стандартная процедура из ПЗУ выдаёт 2174 бод.
Мой турбо-загрузчик для БК выдаёт 1285 байт в секунду – это в 4.7 раза быстрей. Я не тестировал именно на кассетах, но думаю что как минимум 4800 бод можно выжать.
Я больше ориентировался на свой опыт со спектрумом, технология та же. С БК у меня не было слишком свободного доступа, чтобы успеть поиграться с таким.. В принципе можно было бы попробовать на эмуляторе сделать загрузчик который считает из wav, так мы сделаем "идеальный магнитофон, работающий с идеальной кассетой на золотых проводах", и по сути измерится производительность порта/памяти/процессора, но смысла не будет, так как нельзя будет применить на реальных кассетах...
Александр, а как работает Ваш турбо-загрузчик ? Какой вид модуляции/кодирования используется ?
Да самый простой. Узкий импульс – единица, широкий импульс – ноль. В оригинальном методе (в ПЗУ БК) после каждого бита есть ещё короткий синхроимпульс, а в своём методе я его убрал, у меня синхронизация происходит по перепаду фронта. Так что получилось ускорение почти в два раза на той же частоте сигнала.
Плюс я ещё частоту поднял, подогнав ширину импульсов пол скорость выполнения инструкций процессора, так что даже при плавающей скорости запас нужен всего в одну-две инструкции процессора. Такая подгонка позволяет ускорить сигнал даже для стандартной процедуры чтения из ПЗУ. Вот примеры: https://manwe.pdp-11.ru/?/games/tapes
На Википедии пишут, что полоса частот у компакт-кассет с металлопорошковым покрытием достигала 10кГц, что по теореме Котельникова дает нам предел в 4800 бод. В целом - не плохо.
Программирование под БК 0010 в 2019-ом году