PC-01 Lviv

Реплика вынесена из темы "ПК-I (прототип ПК-01 "Львов")".
Если изменить константу чтения (адрес BE41) на 4A (в некоторых пределах +- можно поварьировать относительно 4A и все же будет грузить, но константа по умолчанию в два с лишним раза больше чем нужно), то SLOAD будет грузить бейсиковские проги РК-подобных бейсиков.

UPD: Константу 4A я пересчитал из константы векторовского бейсика, который может грузить РКшные проги. Если пересчитать из задержки в оригинальной РКшной процедуре, то получится константа 57h. Но это не особо критично, т.к. SLOAD грузит РКшные проги и при 4Ah и при 57h.

UPD2: Можно не заморачиваться с загрузкой из WAV, а добавить в конфиг Львова для EMU перехват загрузки rk. В секции
cas : tape-recorder {
нужно добавить строчку
biproc[E5A0-E5F7]=rk

Для удобства можно еще заменить строчку с фильтром:
filter="Lvov files (*.lvt;*.l??)|*.lvt;*.l??|RK86 files (*.rk?)|*.rk;*.rk?"

UPD.
Связанная тема "ПК-I (прототип ПК-01 "Львов")".

Отличное исследование! А как с запуском РК'шных программ на Бейсике на "Львове"? Никаких экспериментов?

_________________
Carthago delenda est, Carthaginem delendam esse

Очень простенькие программы пойдут без переделок, одну такую я попробовал. Но подавляющее большинство нужно дорабатывать. Проблем несколько:
1. Коды токенов совпадают не на 100%
2. Размеры экрана не совпадают ни по символам ни по графике.
3. В РКшных игрушках можно встретить вызовы процедур в кодах.

он использует фазовую модуляцию для байта, как и РК, а вот логический формат потока я не изучал...
а "автоподстройки по пилоту" там нет?

Нет, только инициализация при старте. Мне не хватает эрудиции, чтобы вспомнить примеры реализации автоподстройки для РКшного формата.

UPD: Слона я не сразу заметил. Неожиданно (для меня, не для матерых любителей ПК-01) BE41 оказалась многофункциональной ячейкой и судя по руководству программиста - http://lvovpc.ho.ua/files/program.html) ее основной функцией считается признак инвертирования при выводе на принтер.
Или сэкономили один байт или просто забыли, когда делали версию 2.0, что эта ячейка уже используется как константа чтения для SLOAD. Если отключить инверсию при выводе на принтер, записав 0 в BE41, то это будет соответствовать константе чтения (десятичной) 256, при этом удастся загрузить только файлы со скоростью почти в 3 раза медленнее стандартной РКшной.

Рискну предположить, что разработчики версии 2.0 могли просто-напросто не знать о функциональном назначении ячейки BE41. Или SLOAD добавили уже после того, как разобрались с поддержкой принтера.

А с какого адреса располагается в ПЗУ подпрограмма SLOAD? Велика ли она по размеру?

_________________
Carthago delenda est, Carthaginem delendam esse

Известно, что в предыдущей версии был или
1) SLOAD в виде аналогичном 2.0
или
2) его функциональный аналог (возможно расположенный по другим адресам и использующий другие ячейки для хранения служебных данных)
Была ли в предыдущей версии поддержка принтера?
Если со SLOAD вариант 1) и принтера (поддержки принтера) раньше не было, то "забыли про SLOAD", если со SLOAD вариант 2) и принтер был и раньше, то "забыли про принтер"
Интересные, но маловероятные комбинации 1) и "принтер был" а также 2) и "принтера не было". В этих случаях можно было бы предположить, что процедурами обмена с магнитофоном и принтером занимались разные люди/команды, которые не общались между собой, и в итоге использовали одну и ту же ячейку для разных целей.

В принципе можно было сделать так - использовать для признака инверсии выдачи на принтер только младший бит соответствующего байта. Размер и время работы процедуры вывода символа на принтер при этом бы не изменилось (надо только поменять ora a на сдвиг), а для константы чтения разница в единицу совершенно не принципиальна (кроме единственной пары 00 и 01).

Вобще разработчики прошивки ПЗУ Львова меня удивляют. В 2.0 есть две разных процедуры рисования точки - "старая" для PLOT/DRAW и "новая". Я бы лично сделал одну, но использовал "препроцессинг" координат.
С какого это легко, а что касается размера - это как считать.
Обработка оператора начинается с D873 и, в том что касается чтения с магнитофона, заканчивается на D8C4. Потом идет переход на процедуру "адаптации". Тут есть некоторая неаккуратность - SLOAD корректно читает бейсик программу начиная с адреса заданного ячейками 0243-0244, а вот "адаптация" всегда идет с жестко записанного в самой процедуре (в ПЗУ) адреса. Хотя при значениях 243-244 по умолчанию все будет нормально.
В процессе работы SLOAD вызываются и другие процедуры, их размеры мне лень считать. Упомяну только процедуру чтения байта с фазовой модуляцией E5A0-E5F7.

Вот-вот. Подозреваю, что этот оператор попал из прошивки ПЗУ неведомой ЭВМ, на основе которой разрабатывали "Львов". Отсюда, кстати, возникают два новых вопроса. Форма оператора загрузки SLOAD довольна специфична, что-то я не могу припомнить, чтобы где-то подобное написание встречал. Попытался погуглить - ноль, никаких зацепок. Использовалась ли еще где-нибудь подобная форма оператора загрузки? И еще вопрос. Интересно, где-нибудь на зарубежных ЭВМ использовался схожий принцип записи инфы на ленту? Надо бы устроить инспекцию ЭВМ бывшего соц.лагеря.
Ну, это как раз просто понять. Золотой принцип соблюден: "Работает - не трогай!"

_________________
Carthago delenda est, Carthaginem delendam esse

Сам я придерживаюсь версии о происхождении большинства бейсиков советских 8биток на КР580ВМ80 от бейсика Микро-80, который, в свою очередь, является производной от майкрософтовского альтаирского бейсика. Там и в последователях (первые версии бейсиков для РК86, Специалиста, Вектора, ...) соответствующий оператор - MLOAD. К слову, у почти всех остальных "советских 8биток на КР580ВМ80" тоже бейсик на основе майкрософтовского, но более поздней версии
Шутки шутками, но IMHO это странное разбазаривание ресурсов. Если нормально подойти (в целом к наполнению ПЗУ, не только к рисованию точек), то можно было или сократить число ПЗУшек или добавить функциональности.

У Бейсика ПК-01 особенная стать, о чем есть прямое свидетельство разработчика: UPD.
Интересно, что такое "габаритная система"?

_________________
Carthago delenda est, Carthaginem delendam esse

Да, габаритная система, еще и с бейсиком - это загадочно. Неужели из этой оперы - http://www.korabli.eu/galleries/oboi/vo ... ya-sistema?
Еще, кажется у "Квартета И" было - "в одной из - что за секретность?"
Пусть бейсик без транзита с микро-80, а из страны соцлагеря, но все же майкрософтовский альтаировский. Без MS никуда, даже в 80х.

Против MS у меня при себе возражений нет.

А если серьезно, то хотелось бы точнее установить происхождение ПК-01. Вроде бы "усё ясно", но не хватает деталей, без которых пазл не складывается. Плохо, что у нас почти ничего неизвестно о разработках "братушек" из соц.лагеря. На слуху только "Правец" и "Роботрон". Но были же там и собственные бытовые ПЭВМ, уверен.

_________________
Carthago delenda est, Carthaginem delendam esse