ROM-диск для БК-0010 - Электроника БК-0010/0011M

РУС

ROM-диск для БК-0010
[+] Старые сообщения (31)
? -=RUS=- - 17.04.2017 23:11
Это в случае если программа только что написана или исправлена, тогда нужно её компиляция, а если она уже откомпилирована и записана, то запускать можно сразу.
? Дмитрий - 18.04.2017 10:22
Просто по фразе
¤
>> способ запуска Бейсик программ без компиляции, сразу
¤
так и понимается, что компиляция не нужна от слова "совсем", на что я и написал, что это невозможно.
¤
А по идее нужна программа, которой можно подсунуть дамп (к примеру 2000-37777) с исходником и уже сформированной таблицей кодов, из которого программа сделает запускаемый модуль, убрав все лишнее и исправив адреса текстовых строк (которые можно разместить после таблицы). Получится компактная программа, которая будет запускаться сразу.
? gid - 18.04.2017 11:40
Не нужны такие сложности с предкомпиляцией и дампами.
Нужно просто загрузить бейсиковскую прогу в память и выполнить подпрограмму из ПЗУ, которая выполняется командой "RUN", для этого просто нужно узнать, куда в ПЗУ обращаться. Всё само странслируется в байткод и запустится.
Но перед этим, скорее всего нужно будет проинициализировать рабочие ячейки бейсика. Как это сделать - есть разные варианты.
Самый простой - подготовить специальный массив сдампленных переменных + прога на бейсике.
Посложнее - вызов подпрограммы, которая выполняется после загрузки проги в память. Это опять же ковыряние в ПЗУ. Но для начала можно изучить исходники Бейсика http://emulator.pdp-11.org.ru/misc/BASIC-VVU_BK0010-BK0011.zip
? -=RUS=- - 18.04.2017 12:14
Поправка, команда не RUN (она с начало компилирует потом запускает программу), а GOTO она сразу запускает откомпилированную программу (в БК0010 БЕЙСИКе так).
? gid - 18.04.2017 12:49
Ну так у нас-то цель - запустить не предкомпилированную программу, а чисто .cod файл, поэтому всё таки RUN.
? -=RUS=- - 18.04.2017 13:33
А, для *.COD тогда наверное RUN. Хотя, если маразм мне не изменяет ))), то *.ASC запустить не возможно без компиляции. Надо записи свои найти.
? -=RUS=- - 18.04.2017 16:06
Да, запустить сразу без компиляции можно только *.BIN файл, так как в нём сохраняется таблица команд.
? Дмитрий - 18.04.2017 21:52
Если RUN, то адрес 135242
? vldmr@ - 10.05.2017 04:29
А не знаком ли кто из уважаемых форумчан с программатором ПЗУ системы willem, а в особености с 16-ти разрядной приставкой к оному? Такую приставку я купил у китайцев специально для этого проекта. Сам програматор мне служил без проблем уже давно. Но вот с этой приставкой мне так и не удалось ничего запрограмировать.
¤
В конце концов я стал её проверять безо всякого ПЗУ воткнутого в неё, и она всё равно начинает выдавать случайные данные при чтении воображаемого 1МБ ПЗУ, обычно к концу буфера. Ошибки всегда в младшем байте. Приставка сама по себе очень простая, там всего то два 8-ми разрядных буфера и транзистор, буфера на панельках, я менял их местами, ошибки всё равно в младшем байте. Пробовал две разные программы, родную под виндоус хп и открытую под линухом, результат тот же - случайные данные к концу буфера. Буду благодарен за любые советы по отладке, особенно просходящие из личного опыта
? 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), то программа стартует на выполнение сразу же,выполняясь "построчно").
? 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 строки>) может приводить к ее "вылету",по причине того,что программа может ссылаться на те значения определенных конкретных переменных(напр.,счетчик цикла или обработчик "чего-нибудь-там"),которые должны быть либо определены,либо хотя бы не равны нулю(допустим).
? MM - 08.06.2017 20:52
Насчет почему сделали ПЗУ - Бейсик - компиллятором - так примерно в 1985 г. был визг от одного особо грамотного пользователя БК , "что БКшка - самая медленная бытовая ЭВМ в мире". Затем было распоряжение руководителя НЦ "ускорить БКшку". Т.к. в ОКБ Э. уже в то время ( 1985-1986 г. ) возобладал "неделовой настрой инженеров", ускорить аппаратно немогли ( по чесноку - за нехер делать на 50% можно было ускорить только косметикой Э3 и заменой баговой ВП1-037 на ХМ1 ). Решили пойти "программным путём". Измеряли быстродействие Бейсик-ДВК ( патч с RT-11 под 017 ПЗУ ) - оно оказалось не особо быстрее 018 Фокала БК0010. Решили делать 3 темы - Бейсик - компиллятор, Фокал - компиллятор, и просто добавочное ПЗУ на 140000 адрес с Гротом - типа, "не нравится супермедленный Фокал - вот Вам Ассемблер !".
От компилятора - Фокала все в ужасе разбежались, Бейсик вроде как сделали в Вильнюсе, с кастрацией нескольких команд и т.п. сокращениями.
Зато Грот на 140000 существовал в виде прототипа-скелета :
https://itmages.ru/image/view/5783789/ca761613
*
Был и компиллятор Фортрана для БК0010 - лично не изучал, он не был одобрен в руководстве НЦ и не был доведен до финальной отладки. Исполнения - в виде блока МСТД с 3-мя ПЗУ.
? 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-##",имевших относительную автономность,пусть и худшую,в сравнении с головной ЭВМ на столе преподавателя).
? MM - 08.06.2017 23:34
Насчет Фортрана на диске - пойдет таковой от ДВК. В свое время я ловко уклонялся от этого монстрика.
Если есть интерес - погуглите такие системы программирования, наверника найдутся. Если в ОС ДВК - перегоните в формат .DSK в эмуле ДВК господина Патрона на штатный диск из комплекта поставки БК11М. В таком диске должны быть :
MACRO.SAV
LINK.SAV
( Экранный редактор текста )
DESS.SAV
DES.SAV ( дизассемблер - в принципе, опция )
*
Следует быть готовым, что компиллятор прицепит библиотеку блоков так на 20 к самому маленькому тексту программы.
*
Паскаль RT-11 есть на моем диске к блоку ВМ3А - можете оценить . Я совсем не в курсах этого дела, см. штатное руководство из комплекта поставки БК11 без "М" ( в БК11М это руководство было на дискете ).
? Alexander Tishin@ - 11.06.2017 19:16
MM, вот это про ВП1-37 интересно, сразу по нескольким пунктам:
¤
1) А как поднять производительность-то? Да, из-за наивного арбитража проц слишком много ждёт, но как это побороть? Единственный вариант, который я вижу -- это читать видеостроку с упреждением, чтобы проц имел хотя бы один цикл доступа сразу же после запроса. А второй заведомо будет сильно потом, ВМ1 медленный же, с его-то микрокодом. И в любом случае отдавать все циклы процу на полях видеосигнала, они же там видеоконтроллеру вообще не нужны. А площадь полей примерно 25%, между прочим.
2) Ну, проц хорошо бы действительно сразу поставить на штатные 5 МГц, с фига ли там три? Но тогда мы получаем либо вообще другой контроллер памяти, либо какие-то своеобразные схемы синхронизации.
¤
Что там реально из этого было можно сделать?
¤
Ну и наконец, а где она таки забагованная? Там, по большому счёту, я могу назвать только один принципиальный косяк (кроме неквадратных пикселов Ж)) -- выход синхросмеси вместо отдельных сигналов вертикальной и горизонтальной синхронизации, из-за чего выходной сигнал не совсем соответствует телевизионному стандарту. А так ... вот ВП1-14 реально забагованная, это вообще технический абсурд. Нахрена вообще этот недоэмулятор терминальной клавиатуры нужен?
? Alexander Tishin@ - 11.06.2017 19:38
Перечитал тему, есть, что сказать:
¤
1) Контроллер SD-карты можно вообще реализовать на параллельном порту, там четыре бита всего надо и преобразователь уровней аж на 6 резисторах. Скорость будет не супер, но всяко быстрее магнитофона. Я делал нечто подобное, правда без преобразователя, поскольку железка была и так 3,3 вольта :)
2) L - это мощная тема. Можно на какой-нибудь атмеге соорудить интерфейс а-ля КУВТ-через-L-своими-руками. Это не особо сложно. Я как-то раньше и не думал :)
3) Более того, можно соорудить вообще полноценный эмулятор КУВТ-86, это достаточно просто.
¤
Эх, времени на это нет ...
? MM - 11.06.2017 22:20
Главный баг в 037 - это арбитраж захвата процем ДОЗУ, он - никакой...
Т.е. ответ поступает не много, ни мало, через ~3-4 цикла обращения к ДОЗУ, при этом максимально-достижимая скорость выборки составляет приблизительно чуть больше 3000 нс ( три тысячи нс ).
Решений - аж 2 шт. :
1. Собрать диспетчер селекции главного СОЗУ БК на мелкоте, так сделано в БК11М2 - 037 используется только как генератор адресов сканирования экрана, в циклах доступа к ОЗУ не участвует. Используется приблизительно ~25 ИС мелкоты и 2 шт. 62512 ( из кэша 486 матерей ).
Скорость доступа - 1 такт ЦПУ. Можно усугубить развесистые макароны еще десяточком мелкоты и сделать отображение др.разрешений и даже глубины цвета ( битность пикселя ).
2. Привлечь ПЛИСоводов для изготовления корректно работающей 037 с оптимальным арбитражом и таймингами ( внутренние частоты ПЛИС, конечно, гораздо выше 6 мгц ). Недостаток метода - необходимо на порядок-другой больше бабла, чем п.1, и еще надо поискать разработчика...
( Бабло на разработку пин-то-пин аналога 037 ). Для желающих сэкономить сообщаю - себестоимость микросбрки может быть примерно как п.1.
? vldmr@ - 12.06.2017 00:41
Пин-ту-пин 037 - это интересно. Это же можно сделать такую маленькую платку, которую можно впаять на место 037 и заметно улучшить/ускорить обычную бкшку. В 0010 я б такое ставить не стал - пусть себе игрушки играет с правильной скоростью. А вот в 0011 - это самое что надо.
¤
А на платке кроме замены 037 должна быть выделенная видеопамять, и два проводка с неё навесом прямо к видео формирователю, а сдвиговые регистры выкусить и выбросить. И тогда никакого особо умного арбитража не надо - все обращения ЦПУ к ОЗУ обслуживаются сразу напрямую, ну и с обращениями к видео памяти разобраться не так и сложно, раз она статическая и на борту. Такую плиску я б пожалуй и сам бы взялся сделать, где нибудь к концу осени, если никто другой не начнёт, я попробую.
? vldmr@ - 12.06.2017 06:11
Пора мне отчитатся о нерадостном состоянии проекта, заявленного в начальной теме. Пора потому, что к сожалению, проект с моей стороны консервируется. Сделанные наработки помещены в публичный доступ на гитхабе со ссылкой в конце сообщения.
¤
А сейчас будет раздел отчёта об уроках проекта, или о том, как же это я так облажался. Короткая версия - имея дело с китаем следует быть готовым к любым поворотам судьбы. Длинная версия следует. Всего то железа было 16-ти разрядная микросхема ПЗУ, и несколько (3 как оказалось) микросхем программируемой логики. 16-ти разрядная ПЗУ требовала приставки к имеющемуся программатору, приставка, как и само ПЗУ была заказана в Народной Республике. Полученные компоненты вместе никак не работали, ни черта не программировалось, причем так как источником всего была НР, было не ясно, что конкретно не работает, то ли ПЗУ дохлое, то ли приставка левая, то ли программатор (тоже оригинально из НР), не выдержал. Проиставка, кстати, заслуживает отдельного описания - такую левую пайку я видел только на продутках производства СССР (в частности компьютер БК). Холодные контакты сплошь и рядом, грязь и сопли. Это неожиданно в наш век всеобщей роботизации. Короче, полная перепайка и промывка китайского изделия таки привела его в рабочее состояние, ура, ПЗУ у нас есть. Теперь логика, эти самые ГАЛы. Лучше надо было смотреть, что за фигню я выбрал. Мало того, что там на каждый регистр надо жертвовать ногой корпуса, так ещё и программатор очень специфический (и дорогой, если покупать у хозяев), без открытых спецификаций. Я расчитывал на любительский самопал, опубликованный в интернете, но после того, как я пропалил до трупиков 5 из 10-ти заказанных микросхем этим самопалом, я понял, что это не работает, и пора подумать об альтернативе. Ну вот, до тех пор, пока алтернатива не обозначится, проект законсервирован.
¤
Для любознательных, кто прочитал вышепреведённый стон, а также для тех, кто его пропустил, но посмотрел в конец, ссылка на артефакты проекта на гитхабе: https://github.com/vldmrrr/BK-ROM-Disk
¤
Буду рад узнать, если кто нибудь найдёт наработки полезными, а особенно если кто-то таки воплотит проект в дешовое (ВАЖНО!) железо
? Alexander Tishin@ - 12.06.2017 13:04
ММ, точно ТАК МНОГО? В официальной доке написано, что проц получает второй или третий цикл доступа, смотря когда успел обратиться. И быстрее в варианте pin-2-pin не выйдет, т.к. у БК нет очереди чтения из видеопамяти, там сразу же сдвиговые регистры.
¤
62512 с ценой нашёл только в одном месте, и цена там -- 600р :( 62256 полно за 200 примерно. 64Kx16 A62S6316 можно было бы поставить, но я не нашёл цен.
¤
Вообще, с такими ценниками возникает дурная мысля вместо рассыпухи поставить одну LPC4325 и сделать на ней программный видеоадаптер, эмулятор контроллера шины и т.д., даже эмулятор AY влезет. Цена вопроса ~1000р.
Разумеется, 136 КБ ОЗУ -- это впритык, но оно умеет и внешнюю память, если так уж надо, включая SDRAM. Корпус LQFP-144 можно и вручную запаять при достаточной ловкости рук :)
? MM - 12.06.2017 17:32
Да, так много ( более 3000 нс ) - результаты замера на блоке ВМ3А, в т.ч. с субмодулем 1801ВМ2.
Т.е. косметический патч ( не более 200 элементов И-НЕ ) внутри 037 запросто мог бы ускорить процесс по крайней мере до 2000 нс. без смены таймингов ДОЗУ.
Если применить худосочную ПЛИС с коррекцией таймингов ДОЗУ - можно довести и до 1500 нс ( среднее значение по итогам замеров от нескольких сек ). Если приделать еще и полный доступ на обратный ход луча - можно добиться ~1200 нс ( среднее значение ).
Больше ускорять невозможно, только если модулем ( вместо ВП1-037 ) с собственной СОЗУ до уровня 0...1 такт ЦПУ БК.
*
62512 привел для примеру. Запросто подойдут 621000 - они гуглятся.
<< Форум