Pull to refresh

Comments 87

Очень рад слышать, что сообщество БК 0010 живо и активно! С БК 0010 начался мой путь в ИТ. Помню как я ребенком простаивал часы в маленьком игровом салоне с компьютерами БК 00100.

У меня вопрос насчет эмуляторов. Есть ли сейчас активные проекты по разработке эмуляторов? Нет ли акивных проектов разработки эмуляторов под web assembly?
Исходники эмулятора Gid открыты, в них иногда вносят изменения.
Есть ещё открытый проект хардварного эмулятора на микроконтроллере: zx-pk.ru/threads/30072-emulyator-bk-0011m-na-esp8266.html
WebAssembly – хорошая идея, я не слышал об эмуляторе БК, но было бы здорово. Если задумаете взяться, я с удовольствием поучаствую.
Собирал свой эмулятор (BKBTL) под WASM, скорее чтобы попробовать чем как реально широко используемый проект — nzeemin.github.io/bkbtl-wasm/index.html
Ну и свой основной эмулятор (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();
}
Да, тоже на это наткнулся на днях, поправлю. Спасибо!
Тоже делал для себя (лет 15-ть назад) эмулятор системы команд PDP-11 :)
и под ним даже отладил Форт систему уже для реального железа функционирующего в рамках некоторой самопальной IDE. (сам эмулируемый процессор поддерживал передачу по COM порту и поэтому его можно было соединить через виртуальный COM порт на этом же компьютере с IDE)

P.S. Программирование, в пределах этого инструментария, было на «высокоуровневом» ассемблере (if, else, while ...) в рамках этой IDE с расширенными псевдокомандами ассемблера. IDE тоже была на диалекте Форта (Win32Forth), а эмулируемый процессор на Форт системе (SPF4)
До сих пор есть желание сделать эмулятор на каком нибудь контроллере (типа STM32)

А, для того же ZX-Spectrum делал прошивку ПЗУ с русификацией и турбированием.
а к редактору TLW подключил 64-е клавишную клавиатуру.
Ну и где то остались дискетки от ZX-Spectrum с каким то своим ассемблерным программированием и играми (может уже и не читаются после такого времени ) :)

Есть еще Open-Source эмулятор для Android — BkEmu. Разрабатываю я его не то чтобы очень активно, но баги фиксятся и даже иногда добавляются новые фичи. Люди запускали его даже на видеотелефоне. :)

Программировать в своё удовольствие — это роскошь, которую можно позволить себе только в отпуске.
Программировать во время отпуска, это не роскошь, а скорее профдеформация. На море съездить, в поход, сменить род деятельности, банально отоспаться… но нет. Как вы не выгораете? И не боитесь ли выгореть?
Просто моя работа не связана напрямую с программированием.

Автора как раз легко понять. Полтора месяца, что я провел за редактором кода (и за учебниками) между двумя работами этим летом — одни из самых лучших за последние несколько лет.

Если я правильно понял просмотренные по диагонали исходники, то вся программа состоит в чтении информации с диска и выдачи ее на экран. При всем уважении к труду 13-летнего программиста — это НЕ демо-сцена.
Человек говорит про твою работу, а ты ссылаешься на чужую, в подтверждении того, что твоя — демо. Немного странно. Да, по ссылке — тоже не демо. Я бы назвал это «демонстрация технологии». При всём уважении — наличия крутого кода совершенно недостаточно, чтобы считать работу «демо». Вдобавок, с полностью заимствованным видеорядом.
Что касается демок с музыкой в mp3 формате, то всё зависит от демки. Само наличие там mp3 музыки ни о чём не говорит.
Говоря о моей работе, человек сам ссылается на другие работы, ибо определять что есть демо, а что нет, можно только при наличии некоторого множества работ и устоявшегося их названия. Поэтому мой аргумент — отсылка к другим общепризнанным на демосцене работам. Логично же. Это первое.
Второе: видеоряд не «полностью заимствован». Здесь можно увидеть как я рисовал 3D-вставки: twitter.com/Manwe_sns/status/1177540242125066240
Третье: когда в демках начали использовать MP3, это было встречено негативно. Потом ещё на Амиге начали играть неупакованную музыку прямо с диска — это вообще было фу. Я и сам так считал, и отчасти до сих пор придерживаюсь такого мнения. В идеале всё должно быть в риалтайме. Но демо-сообщество в целом переварило и смирилось с использованием потоковой музыки в демо. У нас в «Good Apple» тоже неупакованная потоковая музыка. Будем за это ругать или как? Просто чтобы я смог понять объективность подхода.
Ну и четвёртое: да, это «демонстрация технологии». Никто же не обманывает, не говорит, что силуэты рендерятся в 3D в реальном времени. Была изобретена технология упаковки и скоростного вывода видео. Идею бесшовного вывода звука ещё за полгода до этого придумали Excess Team. Всё это в сочетании, а также титры с многоцветным трюком — некий законченный продукт. Как его назвать, если не «демо»?
На БК словом «демо» называли вообще всё что попало: например, многочисленные подборки музыки под пищалку. Или взять наш прошлогодний релиз «In Your Space» — для БК-сцены это вполне «демо», хотя там даже на экране ничего не изменяется во время проигрывания музыки.
Мне кажется, надо просто смотреть контекст: в каком состоянии находится демосцена на той или иной платформе. Где-то помигать курсором — уже демо. А на другой платформе это пффф.
UFO landed and left these words here
Получается, что если бы в 1985 году были жёсткие диски такого объёма и с такой скоростью считывания, то можно было бы проигрывать в реальном времени аудио+видео (пусть и с 1 битом на пиксель) на железе того времени. Не только БК, к другому железу демосценщики бы тоже нашли подход.
ну собственно довольно быстрый скроллинг экрана на БК показывал, что как минимум видеопамять способна отображать несколько кадров в секунду
На сколько я помню, видеопамять — это кольцевой буфер, скролл «аппаратный», т.е. задается смещение относительно начала видеопамяти и перерисовывать нужно всего одну строку изображения.
Все: невозможно услышать изображение
КДПВ:

Эх были же времена. Помню, как мне нравился ассемблер 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 на основании предыдущего значения операнда.
Под равноправием я имел в виду использование любых регистров в качестве аргументов любых команд. Например, никто не запрещает использовать регистр стека (SP) или счётчик команд (PC) в качестве индекса цикла или в качестве приёмника слова состояния процессора (PSW). Правда, что после этого будет — берегись! :)

Мне больше нравился такой код "защиты от стопа":
SUB (PC),(SP)<br> RTI
Вроде ничего не напутал. Он одной командой вычитал 2 (т.к в момент выполнения PC указывает на адрес RTI — opcode которой как раз двойка) из PC сохраненного в стеке, который тут же восстанавливался при возврате с помощью RTI, что приводило к выполнению последней прерванной команды.

Смутно помнится что была команда, которая копировала себя адресом выше и передавала управление на этот адрес. Занеся и запустив команду по младшему адресу получали зависший комп с полосатым экраном. С некоторой натяжкой можно считать самым коротким «червём» :) Как сказано неоднократно выше, это было возможно благодаря развитой и разнообразной системе адресации
Ортогональность, если по-нормальному.
Чем мне лично нравились PDP/LSI 11в отношении управления оборудованием — что можно было обращаться к регистрам внешних устройств, как к ячейкам ОЗУ и делать с ними те же операции, а не гонять через аккумулятор. )
Ну в итоге к этому же и пришли на PC. Сначала была старая система, где использовались специальные команды для работы с портами (так они экономили адресное пространство). Теперь, когда адресное пространство стало огромным и устройства стали гонять огромные порции данных с огромной скоростью, всё опять мапится в адресное пространство, как на БК.
Я прошёлся трассировкой по ПЗУ, выявил как можно слегка перехитрить алгоритм загрузки с магнитофона и заставить БК читать данные в 4 раза быстрее.

На БК был загрузчик Turbo, если не ошибаюсь, авторства Саяпина, который повышал скорость чтения — записи с аудионосителей примерно на порядок. Причиной тому использование четырёхтональной записи (вместо стандартной двух), и оптимизация кодирования, когда наиболее часто встречаемые последовательности кодировались более высокочастотными тонами, что дополнительно повышало скорость обмена.

Да, были на БК загрузчики с собственным форматом, самый известный из них — Help7. По тем временам это было очень круто, прямо волшебство (если у тебя качественный магнитофон).
Но я хотел добиться повышения скорости загрузки без сторонних решений, то есть читать разогнанные звуковые файлы стандартной подпрограммой из ПЗУ, чтобы это работало во всех играх и программах. Больше 4-кратного прироста у меня не получилось.
Ну а потом сделал и турбо-формат свой. Вариант с 4-тоновым сигналом поначалу тоже рассматривал (смотрел код Help12), но в итоге пришёл к тому, что чем меньше код загрузчика, тем лучше. Поэтому турбо-формат у меня простой как валенок, загрузчик микроскопический, скорость вполне устраивает (в 8 раз выше нормы).
Это да, но Turbo требовал своего загрузчика, плюс (из-за того, что на БК0011М отсутствует механизм автозапуска загружаемых приложений) — непонятно как целостно реализовать процедуру загрузки. Загружать загрузчик, останавливать ленту, запускать загрузчик, запускать ленту? Если магнитофон без управления — неудобно. В варианте автора запись готовится в совместимом со стандартным формате, разве что тайминги в модуляции укорочены, что требует хорошего качества устройства воспроизведения.
На БК-0010 есть автозапуск через загрузку прямо поверх текущего стека. В БК-0011М этого нет?
У 11М стек в другом месте (не с 1000о), потому не затирается.
Хуже того – не в той странице памяти, в которую происходит загрузка с магнитофона. То есть во время загрузки физически невозможно перетереть системный стек.
Зато 11М появилась позже и монитор, первым делом, передавал управление в ПЗУ по адресу 140000, где, в случае подключения контроллера дисковода, как раз оказывался загрузчик с диска, а в 10-ке операционку приходилось стартовать в ручную.
С контроллером дисковода — да, вручную. А контроллер HDD на БК-0010 уже делал всё как надо сам.
К сожалению у меня были только БК 0010-01 и БК 11М, но с дисководами. HDD я не застал. Могу только предположить что на 10-ке контроллером HDD подменялась ПЗУ по адресу 120000, где штатно был Бейсик и вместо него стартовал контроллер.

Был такой подход к ускорению загрузки/записи, но на практике пользоваться им было очень трудно. Уж больно этот загрузчик был требовательным к качеству ленты и оборудования. Малейшее провисание ленты или повреждение и все сохраненные данные в помойку. Дисковод в это смысле был гораздо практичнее и надежнее.

В каком-то копировщике я видел оригинальный загрузчик — он делил файл на блоки и считал контрольные суммы для каждого блока. Если какой блок грузился с ошибкой, то дозагружался только повреждённый блок — для этого после загрузчика шла не одна копия файла, а две. Да, по расходу ленты — это увеличение в два раза (хотя сам формат записи тоже был ускоренный, так что перерасход по сути — в 1,5), зато удобство — значительно выше. Если с лентой и оборудованием всё норм, то программа загружалась в 1,5-2 раза быстрее. Если были ошибки — то не надо было загружать всё снова.
Такой формат загрузки был штатным на советском же Вектор-06ц. Любопытно, почему на других домашних ПК той эпохи он если и прижился, то только в стороннем софте?

Копировщик назывался HELP7. Две копии файла люди писали почти всегда — даже в стандартном формате: магнитофоны имели тенденцию время от времени "зажёвывать" плёнку, после чего в этом месте информация восстановлению (на доступной тогда аппаратуре) не подлежала. Вторая копия предназначалась для спасения как раз от таких случаев (такой вот RAID на кассетах). У меня сохранилась записанная им кассета — как-нибудь покажу осциллограмму.

Дисковод появился на БК позже уже. Касаемо саяпинского Турбо, он, помнится, писал, данные поблочно и двумя копиями, так что если вдруг была какая-то проблема со считыванием, она решалась чтением того же блока из второй копии.

Слушайте, на подобных машинах (включая Радио РК-86, Специалист, ЮТ, ZX-Spectrum и подобные) всегда используется кодировка Манчестер-2. Она ДВУХ-тональная. (спектр манчестера-2 используется как лого фирмы Cisco).

Причина в том, что этот кодировщик наиболее плотный из простых (без частотной манипуляции и фазовой манипуляции) и легко реализуется снятием сигнала с цифровой микросхемы практически без подготовки.

Но главное свойство этого кода в том, что он САМОсинхронизирующийся. САМО, означает, что носитель информации, несущий этот код может быть нестабильным (что в условиях использования бытового магнитофона, или при передаче через дальний эфир — очень актуально).

У Манчестера-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 звуковой карты я спокоен, дело в неточности кварца БК. Так что без самосинхронизации никак не получается.
UFO landed and left these words here
Идея эмулятора была в том, что он запускается без OS. Грузится прямо с нулевого сектора HDD, написан на чистом ассемблере и всё такое. В общем, превращает PC в БК. До работы с асинхронными устройствами типа дисковода не дошли.
UFO landed and left these words here

Почему же? Переход из real mode в protected mode никто не отменял.

13 лет, кросс-ассемблер, работа с железом… Оказывается не все так плохо и теперь я спокоен за наше ближайшее будущее :)
Мне казалось, что памяти на БК-010-01 (Вильнюс) гораздо меньше, чем 40к.
В детстве я вообще считал что около 4 кбайт доступно пользователю, остальное — пзу и экранная память.
Кто может подсказать спецификацию, которая в то время поставлялась в учебные заведения?
Интернет говорит что 32 кб… Но я помню, как некоторые программы, которые дома писал в тетрадке, не помещались в память компа.
32КБ ОЗУ (16КБ основная + 16КБ экран) и 32КБ ПЗУ (8КБ монитор + 24КБ Бейсик «Вильнюс»)
Точно, был какой-то монитор, но тогда я не понимал зачем он…

Значит 16 кбайт для пользователя. Спасибо.

Монитор это BIOS по-современному

Но на БК0010 можно часть видеопамяти использовать как ОЗУ, верхняя четверть экрана будет занята картинкой, нижние три четверти — данными. Об этом способе потом забыли надолго, а недавно здесь один из авторов написал эмулятор ZX Spectrum для микроконтроллера, там не хватило ОЗУ, он использовал часть видеопамяти ЖК-дисплея.
на спектруме тоже легко было использовать часть видеопамяти как озу.
Насколько я помню, один из кассетных копировальщиков (copycopy) именно так и работал — код расположен в верхней трети, меню посредине, вся остальная память — для хранения копируемого содержимого.
Так почти все копировщики работали.

Они еще и данные сжимали на лету. А 128ые переключали страницы и могли загрузить непрерывный файл вплоть до 120 кб. Лента-диск копировщики Родионова и МОА тоже умели использовать расширенную память. Особенно кдобно это было при записи с диска на кассету — напихал файлы на сколько памяти хватило, и он пишет. Причем Родионовсеий грузил с ленты лучше. И поддерживал скриптинг. Можно было хоть всю кассету автоматически записать.

Звук в youtube-ролике слишком хорош для Covox 8-bit.
Его записывали с эмулятора? Интересно было бы послушать запись с реальной железки.
Не нужно, из этого видео понятно.
На Спектруме 8-битный covox звучал куда шумнее. Хотя там не было 22KHz.

А они по качеству сильно разные, кучка резисторов это одно, микросхема совсем другое. А если резисторы подстроечные многооборотистые а питание ключей стабилизированно и всё это в ручную настраивается то можно вообще проф пригодный вариант получить.
В общем, R-2R решае, а разочарование в ково сах постигало лишь особо жадных до резисторов.

Казань — прекрасное место для проведения такого мероприятия. Огромное количество БК-шек производилось на местном заводе «Элекон». Мне, будучи школьником, довелось поработать одно лето на этом прекрасном заводе, так что, может быть вам досталась БК-шка частично собранная моими руками :)
PS: да, да, собиралась плата в те годы вручную, все радиодетали втыкались, потом специально обученные женщины их паяли, потом мы кисточками наносили латекс на контакты, после купания в лаке, их ножиками и пинцетами сдирали. Потом вибро-стенд, печка, морозильник по нескольку раз.
А для какой цели латекс наносился?
Чтобы в нужных местах получились участки без лака.
Эх, ностальгия. В середине 90-х упрашивал родителей обменять ваучер на БК 0010-01, но тщетно. В итоге купили Спектрум. А недавно на работе в хламе нашел БКшку с монитором Электроника. Включил племяннику Бейсик, показал. Он полазил денёк, понажимал кнопки, да отложил в сторону. Ну а я держу для какого-то светлого будущего)
Прикольно. Я начинал не с БК-0010. Все было хуже — программируемый калькулятор «МК-59», игры из «Науки и жизни» и свои (ха, «охота на лис», вспомнил). Потом" Д3-28"" со встроенным кассетником и монозеленым монитором с клавиатурой дикой раскладки. По советской легенде — копия американского компьютера с подводных лодок. Мне было тогда настолько мало лет, что только спустя годы, после того, как я стал «президентом», я понял что такое «лидер профсоюза мусорщиков».
БК была потом. Начали с другом писать в машинных кодах. Написали SUPERCALC. Работало. Даже формулы переносились. Фокал, Клад, Тетрис… Basic.
А еще вечная обида — IBM PC была в стотысяч раз круче БК-0010, а книжка Л.Пула — волшебной (всё выбросил, а её оставил).
P.S. Сейчас всё лучше. Это очень вдохновляет.
МК-59 — не программируемый, а бухгалтерский настольный. Может быть МК-54? Моим первым компьютером был «Электроника Б3-21». А любимый Д3-28 — клон (или даже развитие, т. к. клоном была предыдущая модель) американского Wang 700.
56. Он программируемый, а по размерам как 59.

Тоже этим летом игрался с легендарным PDP-11, правда в лице МК-90, и тоже участвовал в CC. Программирование под древние платформы, конечно, очень увлекательное занятие!

UFO landed and left these words here
UFO landed and left these words here
Спасибо, очень интересная статья)
Но меня терзает вопрос какие сайты может создавать ребёнок 13 лет?
Есть вариант пройти по первой ссылке в начале статьи и посмотреть какие сайты может создавать ребёнок в 13 лет :)
Ну или, чтобы далеко не ходить, вот сайт, созданный ребёнком в 10 лет (фронтэнд и бэкэнд): thesands.ru/forth-demotool

Кстати, тут у нас, на Хабре, есть AlexeyNadezhin который теперь главный по лампочкам. Так вот он, будучи автором самого популярного DOS для этих машин, может много чего рассказать про БК...

У меня в девяностых был БК с ОС ANDOS и издательской системой Vortex. Строчил рефераты. После пишущей машинки всё это казалось удобным профессиональным инструментом.

этож чуть ли не бог! а он настоящий?

Великолепная работа! Отсылка к рекламе айподов понравилась — ныне и сам эпл точно так же потерял себя и (надо надеяться) мечется в поисках :-)


Надо по возвращении домой попробовать что-то подобное на МК-90 замутить :-)


Для записи образов дисков на Compact Flash пользуюсь мультиплатформенной утилитой Etcher.

Эх, а вот такие, если их можно назвать, "продукты", человеку, понимающему в производительности и оптимизации, упоминать должно быть стыдно...

Благодарю за отзыв!
Что касается оптимизации, для меня было важно наладить как можно более простой и быстрый процесс разработки. Упомянутая утилита позволяет записывать образ флешки за 2 клика. Более простого решения для MacOS я не нашёл. Под Windows пользуюсь также программой USB Image Tool – она хороша во всём, но всё же требует чуть больше движений.
Спасибо за хороший материал. Всегда интересно разбираться в чём-то новом, даже если это хорошо забытое старое ;)
Спасибо на ссылку на эмулятор.
Достал с полки тетрадку с записями из детства — все заработало! Даже клавиатура привычно глбючила, пока не нашел опцию, что можно отключить идентичную эмуляцию клавиатуры =)
по какой-то причине команда CLR работает медленней, чем MOV.

По той причине, что в микропрограмме CLR x реализована как BIC x, x (нестрого говоря, "сбросить в числе X биты по маске X"), то есть ячейку назначения надо сначала прочитать, а потом записать. А MOV R2, x сразу пишет (чтение из регистра ожидаемо быстрее чтения из памяти).

Пользуясь случаем, хочу порекламировать наш ютуб канал. Сейчас там в основном наши (Excess team) демки, но в ближайшее время мы начнем заполнять белые пятна БКшной демосцены. Причем записи будут с реальной машины, а не с эмулятора.
Напомнило старую добрую амиговскую демку 9 Fingers (видео, кое-какие технические детали). Там был очень похожий принцип потоковой подгрузки видео с дискеты:

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... хотя, сейчас у меня есть и маки, и амиги и атари...

Only those users with full accounts are able to leave comments. Log in, please.