• ? RADIX50 - 26.04.2019 23:21
  TO: SAV
  SUBJ: "дважды в него записывать данные...", "процессору можно забирать ближайший цикл,не ждать своей очереди..."
  RE: %SUBJ%
  ...
  Если ничего не путаю,то тов. KISSER в спроектированной им примочке "BK_SVGA"(которая на микроконтроллере) как раз использовал примерно похожий принцип. Дословно не помню,но что-то вроде "..получаются 2 копии содержимого видеоОЗУ + 2-кратная перезапись/обновление"; но его разработка почему-то подверглась некоторой.. ну.. критике, - как раз именно из-за вот этого "2-кратного повторения/хранения"(содержимое базовой видеоОЗУ "БК-001#" дублировалось в местном ОЗУ микроконтроллера); да плюс еще тогдашние "тролли"(коих тут обиталось одно время в те годы довольно заметное количество),не имевшие особого интереса/отношения к теме (возрождения)БК, "подливали масла" в огонь,конфликтуя с участниками форума.
  Не знаю,как кому,но мое мнение такое: приставка свою задачу(преобразование БКшного RGB в IBM_SVGA,причем,"на лету") решает? - решает(причем,без вмешательства в электросхему самой БКшки,т.е.,самостоятельно,в режиме "черного ящика")! А уж сколько копий видеокадра там хранится/дублируется, - для данного случая особой разницы не имеет(тем более,что быстродействие и объем своего ОЗУ выбранного KISSER'ом микроконтроллера заметно превосходят "БКшные",т.е., позволяют допустить некоторую "вольность",как в данном случае,позволив себе некоторую "расточительность" в виде 2-й(3-й) копии кадра), - т.к. для хранения основной программы(алгоритма) работы контроллера его встроенного ОЗУ хватало(причем,с "избытком",который можно тоже как-то использовать,"нагрузив" его дополнительными/промежуточными данными,которые "видны" только самому микроконтроллеру и на работу БК никак не влияют).
• ? RADIX50 - 02.09.2018 00:37
  Лучше опубликовать.
• ? RADIX50 - 29.08.2018 17:47
  RE:"внутрисхемное программирование": про наличие RS232(или USB)-порта на плате RE-мулятора я в курсе(он виден,в т.ч.,на фото).
  Под вн.сх.-программированием имелось в виду возм-ть прошивки 573РР##/1801РР##,не снимая ее с панельки на плате БК / блока МСТД, без программатора(которых тогда в наличии и не было нигде,кроме как на заводах у самих разработчиков). Вычитав в справочнике по м/сх о наличии перешиваемых 573-х и 1801-х чипов, долго не мог понять,почему нет такой возможности делать это прямо в блоке МСТД(допустим),не вынимая ПЗУ из схемы,как,напр., на материнках IBM PC и их аналогов(на той же "5SVA" или "MVP4" сам перешивал BIOS таким способом); (отсюда и название - "внутрисхемное").
  ...
  Еще хотелось бы уточнить(или прошу напомнить,если уже говорилось/тема была ранее): насколько помню,какие-то определенные партии заводских м/сх КР1801РР## имели своего рода "дескриптор","указатель" адреса(рабочего?) прошивки,размещаемой в ПЗУ как таковой(если смотреть сам бинарник - то размещалось где-то в первых байтах файла), и там был такой момент,что этот "адрес" было можно изменять только в сторону увеличения(поправьте,если путаю..), т.е., напр., если предыдущий раз "шили" программу для запуска с адр. "100 000", то в следующий раз нужно шить уже с адреса "120 000", "160 000" и т.д.(ну или примерно в таком духе).
  Можно уточниться,зачем так сделано для ПЗУ типа "РР1"(флэш-память с эл.стиранием и перезаписью)? Ну,для каких-то экземпляров "неизменяемых" ПЗУ типа "1801РЕ##",предназначенных для конкретных случаев, этот адрес,может,и нужно было делать "фиксированным"(одна ЭВМ стартует с "100 000", другая со "120 000"), а для ЭСППЗУ зачем?.. И что происходило с 1801РР1,когда вот этот "указатель адреса" достигал,допустим,некоторой "верхней" отметки и дальше увеличивать его нельзя(т.к. число выходит за рамки разрядности или за пределы адресн.простр-ва ЭВМ),а уменьшать не позволяет сама м/сх ? Т.е.,по сути,еще исправные РР1(не исчерпавшие ресурса перезаписи ячеек) приходилось выбрасывать(не использовав ресурс полностью)?.. При электрическом стирании "РР1" на программаторе(сбросе ячеек в исх. сост. по всему объему м/сх) разве все указатели не "сбрасывались" тоже в "начальное" состояние(позволяющее потом при следующем программировании,именно с записью нового бинарника,записать и новый указатель "адреса старта" ПЗУ)?.. Или это была нестираемая группа ячеек по типу "Бут-Блока" в м/сх типа "28F1000"(куда пишут BIOS для IBM PC-материнок)?..
  Насколько знаю,"SPECTRUM" и IBM PC(и еще какие-то представители микроархитектур того времени) при подаче питания стартуют с адреса "000000";в МП машин типа "HP/UX", DEC/Alpha и аналогичных, в принципе,предусмотрена техн. возм-ть стартовать "с любого" адреса(что в целом,удобно,т.к. адрес возможно варьировать под конкретные варианты применения таких вычислителей: грубо говоря,запускать что-то "свое" вместо штатного "Монитор'а" или "Фокода",не трогая остальную "раскладку" адресов для др. программ; либо "передвинуть" тот же "Монитор",запустив/разместив его "с другого" адреса,так сказать, "в пользу" своего самопального ПЗУшного отладчика). Но мне немножко не совсем понятна реализация такого "указателя (...начального...? ) адреса" в м/сх типа 1801РР##: зачем именно "так" было сделано(с увеличением номера адреса)?..
  ...А если скопировать "стандартную" прошивку из "1801РЕ##"("неизменяемую") в равную ей по объему "1801РР##",сделав полный бинарный "образ"(программатором), - то,с учетом вот такого "увеличивающегося" указателя, - будет ли "копия" "заводского" ПЗУ работоспособна(если в "РЕ-шке" имеется такой же "указатель", и он окажется "меньшего" значения,чем уже имеющийся в "РР-ке",подготовленной для записи копии этого образца)?
  ..Подскажите,плиз (или напомните,где посмотреть,если где уже обсуждалось ранее),буду очень признателен. :)
  ...
  А как решается этот "вопрос" в обоих вариантах разработки "RE-эмуляторов"-аналогов(как они "управляются" с этими "начальными указателями": меняют при заливке бинарника или выдают нужные значения "на ходу" при запросе от МП на чтение ПЗУ)?..
  ...
  В любом случае,обе разработки хороши,нужны и имеют право на существование.
  У каждого,конечно,свои предпочтения(при работе/обслуживании), но лично я предпочитаю работать с ПЗУ с помощью программатора(так в больш-ве случаев надежнее); но при отсутствии оного, в ряде случаев, удобнее,когда есть возм-ть обновить/считать/зашить "прошивку" не вынимая ПЗУ с системной платы (как на IBM PC в "горячем" режиме с помощью утилит типа "MOD-BIN" + "AWDFLASH"/"BFLASH").
• ? RADIX50 - 25.08.2018 22:35
  To: BD
  RE:"энергонезависимое ОЗУ 120 000 - 160 000":
  Да хоть как бы переключались,главное,шоб работало! ) Сейчас можно сделать "модняво", джамперами! )
  Подключалось "вторым этажом" в КНГМД или вешалось на разъем МПИ?
  ...А схемку в студию можно? ;)
• ? RADIX50 - 11.08.2018 19:34
  TO: Kisser
  SUBJ: "%изучение спроса%"
  ¤
  п.п. N1 - 7(либо,как минимум, 1-5); +п.7; +п.9; за указанн. цену.; встреча в метро;предпочтительно предварит-но забронировать с отсрочкой платежа на начало сентября;подъеду к указанному пункту(МосМетро).
• ? RADIX50 - 22.05.2018 20:40
  To: PHOTON1984
  SUBJ: "УК-03"
  #MAIN:
  Да,дизайн схожий ))
  Красота какая )) ...А интересно,для чего столько входов(/выходов)? :)
  Прибор работал как внешний общий "ленто-дисковод" для дисплейного зала/школьного класса? :)
• ? RADIX50 - 29.04.2018 22:58
  To: photon1984
  %SUBJ%: "КТС-90/УВХП"(2):
  ...Т.е., от "БКшки" ничего "супер-"особого не требуется,просто замыкать нужные контакты(релюхами или с 541КП##) вилки "ДУ ЛПМ МГ"(DIN7) сообразно заказанному режиму работы(загрузка/поиск/запись файла),а остальное магнитофон(его БЦВМ "145ИК19##") сделает "сам" :)
  Если б не 1991г., думаю, эта "примочка" вполне могла бы быть реализована(надо встроить несложную схемку,аналогичную собиравшейся кем-то из наших "форумских" на порт УП БК,см.сообщ-я выше; да,и еще как-то программно "увязать" ее работу с штатным драйвером магнитофона - т.е.,небольшая доделка схемы все равно понадобится). Плохо то,что,появись эта доработка "тогда", она вполне могла бы быть стандартизована(для серийного выпуска), а если ее пытаться приделывать "сейчас"(в наше время), то это уже будет некоторое "отклонение" от "классики". Некоторое "утешение" - на хваленых "Спектрумах" и др. похожих микро-ЭВМ "европейского" образца(массово-популярных для своего времени) даже встроенные(сбоку корпуса) магнитофоны были с "рычажным" управлением ЛПМ,т.е., эта "примочка" там тоже не была реализована(максимум что - LED-индикаторы режимов,типа как на "Commodor").
  ...
  Но вообще, такая "примочка"(хоть встроенная в БК, хоть в виде отдельного блока на МПИ/УП,по типу "блок КМ / КПУ" БК-0011) была бы весьма полезной,особенно,для тех,у кого не было дисководов(меня тоже с самого начала волновал этот вопрос, почему "штатное" дистанционное управление(судя по схеме распайки кабеля "БК-МГ") - по сути,таковым не является),т.к. даже магнитофон с автоматическим управл-ем ("Маяк","Яуза","Нота","ЭЛЕКТРОНИКА","Санда","Орель"...) приходилось включать вручную.. :)
• ? RADIX50 - 29.04.2018 22:33
  To: photon1984
  %SUBJ%: "скан КТС-90":
  ну,вот там как раз и сказано,что вручную надо включать(или сам КТС/УВХП или обычный магнитофон) :)
  ...Хотя,да,уж какую-никакую логику управления магнитофоном-приставкой(его ЛПМ,точнее) в БК могли бы и встроить(разработчики).. На днях "покурил" "дата-shit" от КР145ИК1906 / ИК1914 - оказалось,в этом спец.процессоре много всяких "фишек" есть(и по управлению ЛПМ,и не только); причем,такое впечатление,что в имеющихся магнитофонах того времени явно далеко не все возможности были использованы(хотя,повторюсь,В самой м/сх " -ИК1906 / -ИК1914" много чего есть встроенное,даже возм-ть расширения внутренних ОЗУ/ПЗУ и динамическая индикация счетчика ленты - причем,хочешь в секундах-минутах,хочешь в "попугаях"/оборотах подкассетника/рулона;хочешь - даже с привязкой к реальному времени). А на "Маяке-233" - блок управления ЛПМ,по-моему,и вообще собран без использования того спецпроцессора - чисто на транзисторах и нескольких триггерах и силовых комутаторах(541КП## или аналогичных), хотя,работает в целом так же,как на "Электронике-204с" / "Э-220с"(которая на 145ИК1906 собрана).
  ¤
  Смотреть тут:
  http://radiowiki.ru/index.php?title=%D0%A4%D0%B0%D0%B9%D0%BB:%D0%9C%D0%A0%D0%91_1110._%D0%92%D0%B0%D1%80%D0%BB%D0%B0%D0%BC%D0%BE%D0%B2_%D0%98.%D0%92.,_%D0%9A%D0%B0%D1%81%D0%B0%D1%82%D0%BA%D0%B8%D0%BD_%D0%98.%D0%9B._%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80%D1%8B_%D0%B2_%D0%B1%D1%8B%D1%82%D0%BE%D0%B2%D0%BE%D0%B9_%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B5.djvu&page=29
  (Справочник "МРБ 1110. Варламов И.В., Касаткин И.Л. Микропроцессоры в бытовой технике".djvu, примерно стр.26-31, там много про эти м/сх информации дается).
• ? RADIX50 - 23.04.2018 19:42
  SUBJ:"управление магнитофоном":
  ...
  Вот интересно,есть ли вообще в принципе разработки(или хотя бы пытался ли кто-нибудь?) сделать осовремененную версию блока управления ЛПМ для "Электроники-МП-2##","Нота"/"Маяк"/"Вильма"/"Яуза-МП###", с учетом всех "недоработок" массово-серийных образцов? ))
  Ну, "современную" версию блока газоразрядного индикатора типа "ИЛТБ-001 / -030 / -М85"(на чипе КР1534ПП1/ПП2/ПП3/ПП4) - кто-то из аудиофилов,насколько помню, делали (несколько м-цев назад попадалось по перекрестной ссылке при поиске;правда,особо внимания не обратил,т.к. искал другое) - на какой-то "Ардуине" или схожем МК/ОМК: индикатор использовался как есть(сам ИЛТБ и вся его обвязка с питанием), а ОМК/ПЛИС применен в качестве замены 1534ПП## с "расширенными" возм-тями(динамич. индикация пикового уровня,"спадание" и прочие "вкусности", коих не было с 1534ПП1). :)
  ...А вот упрятать в ОМК/"ПЛИСину" блок управления ЛПМ? никому идея в голову не приходила? :)
• ? RADIX50 - 23.04.2018 19:20
  SUBJ: "работал бы как стриммер":
  Кстати,сходным же способом работает приставка "ArVID" на IBM PC,превращая бытовой "видак" во внешний "жесткий диск"("стриммер" на видеокассетах): запись-чтение данных идет через разъемы Video-in / Video-out по видеокабелю, а управление режимами ЛПМ "ArVID" выполняет,подавая "радиокоманды" на ИК-приемник встроенной системы Д.У. "видака" через выведенный наружу внешний ИК-излучатель(имитируя работу ИК-пульта ДУ аналогично тому,как это делал бы пользователь,в т.ч.,с обычным магнитофоном,вручную). В начале ленты пишется так же некий "каталог" из серий цифр(показания счетчика в виде относительного "оффсета" от начала,надо понимать),а в самых поздних версиях "АрВИДа" - еще и с запоминанием "задержек"(в т.ч., времени,требуемого на перемотку видеоленты до нужного участка на конкретном ЛПМ "видака").
  ...
  Т.е.,в случае,с наличием "полнокомандного" режима Д.Упр. (когда управлять можно ВСЕМИ рабочими параметрами,а не только лишь режимами ЛПМ), - вопрос с использованием магнитофона в режиме "стриммера" для ЭВМ решается практически "сам собою" :)
• ? RADIX50 - 23.04.2018 19:04
  SUBJ:"казанский магнитофон...":
  RE:"управление моторчиком..":
  ...
  Ну,насколько могу видеть по внеш.виду лентопротяги и кнопкам на передней панели, - как раз-таки он ближе к "Маяку"/"Ноте"/"Яузе"/"Электронике-МП-204/МП-220": хорошо виден "контроллер" на рассыпной логике(на "Электронике-МП-2##",напр.,он сделан на спец.процессоре типа КР145ИК1902, который для ЧПУ-станков когда-то был разработан; по-моему,он разрядностью всего 6бит,если не путаю; а на "Маяках" - как раз на м/сх 561-й серии) и соленоиды тяг ЛПМ.
  С передней панели точно управляется(клавишами-кнопками) "как положено", а вот что выведено на DIN-5-разъем "БК", - вот не знаю,не знаю.. :)
  ...А вообще,прям "монстр" - два типа ленты("хром/железо"),электронное управление! ))) Жаль,что аудиотракт монофонический, а так был бы прям портативный "Маяк-МП" ))))))))))
  ...Лично мне идея(концэпт,так сказать, разработки) нравится(только вот не доведено было "до ума" для работы с бездисковой БК-0010,чтоб уж коль не дисковод,то магнитофон бы хоть в "нормально-автоматическом" режиме-то работал бы!) :)
  ...Тот "наш","кассетный стриммер" про который я говорил выше, - он все-таки обладал более расширенным функционалом,т.к. управление было полностью электронное(через длинный "шинный" разъем,а не с DIN5).
  _
  To: GID:
  SUBJ: "только в(ы)ключать мотор...":
  ...Совершенно правильно. Сама "БКшка",в штатной комплектации(т.е., "как есть",без доработок) только лишь разрешает/запрещает питание двигателя магнитофона,щелкая релюшкой,и все(если прозвонить штатный кабель "МАГНИТОФОН" БК-0010,или глянуть по схеме, - то на разъем "ДУ" идет всего 2 провода,которые замыкает реле внутри БК,и никаких особых сигналов там нет).
  Вообще,идея была вполне здравая(ведь сделал же такой блок управления тот инженер в "Науке и Жизнь",см. мое сообщ-е выше), но для этого надо было положить в заводскую коробку-комплект(БК-0010/0011) еще один блочок по типу "КМ"(или КПУ,как бишь он там правильно звался на БК-0011?),который,включаясь либо в МПИ,либо в УП ("LPT БК" :) ), реализовывал полное управление режимами через тот же разъем DIN7/"Д.У." на стационарных магнитофонах(в 80-е годы таковые аудио-деки уже вполне имелись); единственный вопрос тогда был бы только - изготовить переходник(DIN7 от "контроллера МГ"-> DIN7 магнитофона) с нужной распайкой под конкретный магнитофон,чтобы БКшка через "контроллер Д.У. МГ" "нажимала" на нужные "клавиши" магнитофона,коммутируя контакты разъема при поиске нужной фонограммы.
  ...
  RE:"СМ1700,агрегат в составе...":
  ...Что-то ближайшее похожее на "полностью автоматический" типа "стриммер"(аналогично приведенному мною примеру,см.выше),оказывается, делалось и для ПЭВМ серий "Искра-1256".
  Смотреть здесь(основной трэд):
  http://rt20.mybb2.ru/viewtopic.php?f=3&t=100858&st=0&sk=t&sd=a&start=100
  (стр. 3, общ. тема "Переделка Маяк-233 на сквозной канал"; Добавлено: 11 апр 2018, 09:51),
  искать по ключевой фразе: "ЛПМ от кассетного накопителя Искра 005-33, подарил знакомый."(можете отсюда выделить и вставить в поиск по CTRL/F)
  И там же,чуть ниже,под абзацем, - линки штук на 10 картинок ЛПМ с разных ракурсов.
  ...
  Конечно,он сразу сделан "как стриммер-автомат", но для звука такой ЛПМ - он,скорее всего,"никакой" :)
  Зато целиковое автоматическое управление(правда,"бескнопочное").. :)
  ...
  To: BD
  SUBJ:"Электронный счетчик":
  Вот на "Электронике-МП-204, -"МП-220" - там счетчик ленты как раз-таки полностью электронный(!). Но вот беда,что автопоиск там работает,мотая только "до нуля"(надо постоянно "нулить" счетчик,если хочешь закольцовать нужный участок фонограммы). Автоповтор и автоперемотка - работают корректно лишь "на полную" сторону кассеты - т.е., когда полностью проиграется одна сторона(сработает автостоп в конце кассеты), "Электроника-МП-2##" может перемотать снова на начало и по указанию пользователя,либо остановиться,либо включить воспроизведение заново(тут она все делает корректно - не зря ж на процессоре от ЧПУ-станка построена! :) ).
  Показания электронн.счетчика ленты как таковые - на разъем "Д.У." не выводятся(не было такой необходимости в "те" годы,хотя,насколько знаю,шина по типу I2C или другая/похожая для упр-я быт./промышл. техникой тогда тоже уже существовала - уж могли бы что-то и приделать похожее,ценой небольшого усложнения схемы магнитофона).
  ...Но такого,чтоб,обнулив счетчик при вставке кассеты,свободно задавать размеры "окна" для автопоиска/автоповтора/автоперемотки (т.е., по ДВУМ значениям счетчика ленты - мотать "от" и "до"), - насколько помню, такой сервисной ф-ции в стац.магнитофонах "того" периода не было предусмотрено(отчасти,думаю,что и зря! - как раз бы могло вот пригодиться,- не "тогда",так хоть "щас").
  По крайн.мере не было такой ф-ции в доступных тогда в массе своей магнитофонов второго "класса" (т.е.,чья модель начиналась числом типа "2##",т.е., "Весна-212","Маяк-240","Санда-207"). Про стац.магнитофоны 1-го и 0-го классов сказать ничо не могу(распайку DIN7 "Д.У." тоже не знаю,т.к. доводилось использовать их только как устройство перезаписи кассет в ручном режиме,и не более того) :)
• ? RADIX50 - 08.06.2017 22:19
  RE:"компилятор/Бейсик":
  Да,наслышаны,наслышаны - "вильнюсский" компилирующий Бейсик действительно "кастрирован": не реализовали,напр., закраску прямоугольника/полигона(команда "LINE(x1,y1)-(x2,y2),B,F,{color}"), нет команды "MERGE" (а можно было бы делать "оверлейную"/динамическую подгрузку,допустим,лабиринтов в игру(по мере прохождения оной),или битмапа в какую-нидь программу типа "чертилка", - непосредственно при ее работе); некорректно работает даже "LOAD {filename},R" ,будучи вставленная последней командой в программу,выводящую,напр., заставку или "help" от предполагаемой игры(программы),чтоб дальше уже загрузить саму основную программу(или игровой "движок"),не расходуя лишнее ОЗУ(пытались сделать так,чтоб грузилось "друг за другом",не останавливая магнитофон,как это было на "ZX": сначала рисует заставку на весь экран,потом грузит саму игру, т.е., "помодульно",- ага,хрен там: "LOAD" в программном режиме не срабатывает,только в "единичном",с ком.строки!). Наличие корректной команды "MERGE" убрало бы вообще все проблемы на корню!
  ...Да много чего нет, по сравнению с тем же IBMским "GWBASIC"'ом(а уж с "Ямаховским" - ни тот,ни другой даже в сравнение не идут, ибо на "Ямахе" "Бейсик" воще супер: даже работает команда "LIST" в программном режиме,не то что "у нас тут"!) :)
  Причем,что интересно: даже сами преподаватели(на тот момент - многие действительно профи-,хорошо владевшие в т.ч., и системным программированием) - сами открытым текстом называли "Бейсик/Вильнюс" "дубовым".
  ...Причем,со всеми "урезаниями" - все равно для "Вильнюса" понадобилось аж целых 3 м/сх "1801РЕ"(или "1801РР"),т.е.,компилятор занимает аж целых 24К.
  ...
  По поводу FOCAL/FOCOD'а: насколько знаю,по крайн.мере,"МСТДшные" варианты - это тоже "Фортраноподобные" языки(ПЗУшный "FOCOD" для БК-0010-01 - это вообще,по-моему,чей-то курсач/диплом(выдавался как задание кому-то на кафедре ЭВМ при МГУ или МИФИ),адаптированный для БК-0010),т.к. используют синтаксис/правила "прототипного" FORTRAN'а (потому я их так и зову,не вдаваясь в подробности). Насколько знаю,в конце 90-х гг написаны графические версии "ФорТрана" (транслятор "GRAFORR",с возможностью в т.ч., объектного программирования) - сначала для "не-X86-совместимых"(DEC/MOTOROLA) ЭВМ,а чуть позже - и для "X86"(на P-133,который не "MMX",- работает вполне себе так шустро).
  ...Кстати,"МСТДшный" ПЗУшный "FOCAL(FOCOD)" - занимает менее 4К и еще содержит встроенный беглый "HELP" по командам(т.е., в 6раз меньше "Вильнюса").
  ...
  RE:"Прототип-скелет": вот положили бы они тогда такую штуковину в базовый комплект поставки - было бы неплохо! По крайн.мере,удобно: хочешь - ставишь МСТД с FOCODом, хочешь - с GROT'ом(а "Бясик" и так уже встроенный) и программируешь. По крайней мере,в тех же германских бытовых ЭВМ того времени - такие штуки в набор входили("картриджи ПЗУ с языками программирования").
  ...
  RE:"Исполнение - в виде МСТД с 3-мя ПЗУ":
  "Полноценный" "FORTRAN" в 90-е гг довелось видеть у кого-то из продвинутых владельцев БК, только в "той" модификации транслятор(не исключено,что слегка "пропатченный" под собственные нужды) загружался с дискеты как внешняя программа. Хотя,в ПЗУ было бы надежнее и удобнее. Как "DOS6.22/ROM_version" или другие промышленные для IBM PC. Ну,или тогдашние бездисковые станции марки "HP/UX",где и "пускач",и вся ОС с драйверами находилась в ПЗУ, не занимая место на системных дискетах(кстати,что-то похожее было реализовано на каких-то вариациях "YAMAHA-MSX-##",имевших относительную автономность,пусть и худшую,в сравнении с головной ЭВМ на столе преподавателя).
• ? RADIX50 - 08.06.2017 19:12
  RE:"команда GOTO в Бейсике-БК":
  ...Команда GOTO передает управление на конкретную строку с номером (напр., GOTO 270), но только в процессе работы уже запущенной(скомпилированной) программы(т.е.,когда выполнена настройка стэка и всех нужных рабочих адресов для конкретного случая,которые могут быть различны). Для именно запуска программы не "с начала",а с конкретной строки, - подается команда "RUN <N строки>", напр., "RUN 435" или "RUN 260". При этом все равно выполняется компиляция(по крайн.мере,частичная, - как минимум с той строки,с которой было заказано запустить программу, и до конца,пока не встретятся команды END или STOP).
  Беда "Бейсика-БК" в том,что инженеры сделали его именно компилирующего действия(т.е.,в ОЗУ надо держать и исходный текст,и скомпилированные объектные коды),что нерационально с точки зрения использования/расхода ОЗУ ЭВМ(и так весьма небольшого изначально). Вполне можно было(тем более,если "передирали" фирменный "BASIC-MSX") сделать транслятор интерпретирующего типа (как тот же ПЗУшный FORTRAN/FOCOD,идущий в блоке МСТД на "БК-0010-01").По крайней мере,и сам будет компактнее,и ОЗУ для работы должен,по идее,требовать меньше(собст-но,только для хранения исходного текста).
  Замечу,что в случае наличия вложенных циклов или вызовов подпрограмм типа GOSUB "<N...>" или мало-мальски "разветвленности" алгоритма программы, запуск "не с начала"(командой RUN <N строки>) может приводить к ее "вылету",по причине того,что программа может ссылаться на те значения определенных конкретных переменных(напр.,счетчик цикла или обработчик "чего-нибудь-там"),которые должны быть либо определены,либо хотя бы не равны нулю(допустим).
• ? RADIX50 - 08.06.2017 18:58
  RE: "Ну так у нас-то цель - запустить не предкомпилированную программу, а чисто .cod файл, поэтому всё таки RUN.";
  RE:" А, для *.COD тогда наверное RUN. Хотя, если маразм мне не изменяет ))), то *.ASC запустить не возможно без компиляции. Надо записи свои найти:"
  #
  Насколько помню из инструкций(бумажных), файл в формате .COD - это как бы почти-"сжатый" исходный текст(файл), сохраняемый "во внутреннем формате BASIC-системы"(одним файлом), а .ASC - это будет тот же исходный текст программы, сохраненный "в открытом" виде,но разбитый поблочно по 256 байт(делается самим "Бейсиком" при выполнении дисковой/магнитофонной операции), - кстати,прекрасно слышно по звуку записи,если пишется/читается на магнитофоне. При этом при записи/чтении каждого такого 256-байтного "блока" каждый раз щелкает реле при начале и окончании записи оного(либо характерно дергаются головки дисковода,что тоже слышно на слух). В стандартный сектор на дискете как раз 2 таких "блока" и помещается(2*256Б = 512Б). Насколько помню, ".ASC" - стандартный формат используемой на БК/ДВК/УКНЦ/PDP версии "Бейсика". Фрагменты записываемого файла получают имена типа "myfile.asc.#000", "myfile.asc.#001", "myfile.asc.#002" и т.д.; последний(либо самый первый,уже точно не помню) "блок"-фрагмент получает имя "myfile.asc".
  ...
  Насколько могу видеть, технологически, - "ASC"-формат аналогичен команде IBM'ского "GWBASIC" "save "myfile",/A ", отличие в том,что там сохраняется тоже в формате ASCII(доступен к просмотру в "Нортоне" как обычный .TXT-файл любого типа), но весь файл целиком("одним файлом").
  Формат "COD" на БК - аналогичен "обычной" команде "SAVE" в GWBASIC(иногда с ключом /"bin" или "/b"),по которой сохраняется тоже "одним файлом", но он частично-"сжатый"(хотя,некоторые номера/строки при просмотре по F3 также читаемы),т.е., также во внутреннем формате GWBASIC'а, и имеет расширение ".BAS"(причем,меж разными версиями интерпретатора такие "сохраненки" могут быть несовместимы,т.е.,открывать надо в той же версии GWBASIC'а,откуда был сохранен этот файл).
  ...
  По поводу адреса загрузки/запуска(на БК/ДВК/УКНЦ/PDP): в случае с "#.ASC"- форматом - адрес загрузки 6-значный; в случае с форматом ".#COD" - что-то вроде как 4-значный; хотя,в данном случае,могу быть не точен. Фортрановские/FOCOD'овские файлы имеют адрес загрузки что-то вроде "1732"("невысокий", т.е.,грузятся "вниз", в "трюме").
  ...
  Зачем так было сделано с форматом ".ASC" - не знаю, но это штатный,"родной" формат "Бейсика".
  В практической эксплуатации - получается,что "поблочная" запись выходит менее надежная(так,напр., у меня на фирменных кассетах,идущих в комплекте, - изначально не читается программа "PATCH.ASC",инструментальный отладчик для подг-ки программ/данных в машинных кодах, - один предпоследний фрагмент выдает ошибку чтения,а без него бейсик-программа не запускается и по команде LIST выдает номера строк и "кашу"...).
  Никаких особых преимуществ это не дает, т.к. при сбое загрузки формат ".COD" также точно оказывается "незапускабелен",как и ".ASC".
  В отсутствие интернета(в тогдашние времена) найти программу целиком, в "небитом" виде, не представлялось возможным.
  ...
  Причем,каждый такой .ASC-блок(файл) имеет указатель на следующий за ним файл, - что-то типа многотомного ".RAR"-архива,только без сжатия(но с указанием,видимо,контрольных сумм предыдущего и последующего фрагментов,иначе бы текст бейсик-программы был читабелен до точки сбоя загрузки,обрываясь после нее).
  ...
  Касаемо загрузки/запуска,оба формата,и .COD,и .ASC,- по сути,равноценны(это лишь варианты сохранения исходного текста в файле), и для автоматического запуска после загрузки выполняется одна и та же команда Бейсика: LOAD "myfile.asc",R (или LOAD "myfile.COD",R). При успешной загрузке выполняется компиляция и запуск программы(в случае если "BASIC" - интерпретатор(как "GWBASIC" на IBM), то программа стартует на выполнение сразу же,выполняясь "построчно").

?