1 Тема от garnizon Отредактировано garnizon (02-10-2019 22:00)

  • garnizon
  • garnizon
  • Участник
  • Неактивен

Тема: UNI-Бейсик

Вот всем же известно что ИКП-1 (то что 88 года для 840 диска) есть как для семерки, так и для девятки.
И если создать диск командой INIT HELLO получится загрузочный диск с бейсиком.

А сложно ли создать UNI-диск, вот такой загрузочный с бейсиком, чтоб грузился и на 7 и на 9?
Насколько я понял, если в 0 трек вставить автоопределялку архитектуры и потом два дампа с дисков то все
получится, но Володя говорил что там много одинаковых крупных областей и можно за счет этого попробовать.
Таким образом сравнять время загузки на разных архитектурах.

А вы что думаете относительно такой идеи?

2 Ответ от AlexBel

  • AlexBel
  • AlexBel
  • Участник
  • Неактивен

Re: UNI-Бейсик

Я сейчас начал было расписывать возможные варианты практического применения такого диска, но потом стёр и решил спросить - а нафига это нужно? ;)
Пришёл к выводу, что это только приведёт к неоправданному расходу дискового пространства. Может, конечно, я не прав, но, думаю, это не имеет практического смысла.

3 Ответ от garnizon

  • garnizon
  • garnizon
  • Участник
  • Неактивен

Re: UNI-Бейсик

При составлении игротек для сайта удобно безумно, ну и для выкладывания универсальных прикладных пакетов на сайте тоже.

4 Ответ от AlexBel Отредактировано AlexBel (14-10-2019 08:42)

  • AlexBel
  • AlexBel
  • Участник
  • Неактивен

Re: UNI-Бейсик

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

5 Ответ от Voldemar0 Отредактировано Voldemar0 (12-11-2023 13:29)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: UNI-Бейсик

Тут два подхода:

1) Делать детектор архитектуры и, в зависимости его результата, загружать образы соответствующего бейсика. Т.е., фактически, иметь два варианта бейсика.
Это не очень сложно, но всё таки времени требует (как минимум, нужно хорошо изучить логику загрузки, а потом подправить существующий загрузчик).

2) Глубоко шерстить код бейсика и пытаться так его изменить, чтобы все моменты, где его поведение различается в зависимости от архитектуры, согнать в минимальное количества функций. И уже эти функции будут менять своё поведение в зависимости от архитектуры (которая, вероятно, будет определятся тем же детектором из п.1).

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

Я предполагаю, что команда Цикозы в Школьнице пытались зайти с этой стороны, но в итоге забросили идею. У них есть явно вынесенные процедуры управления памятью; по идее, это можно было бы расширить на архитектуру в целом. В ИКП-Бейсике тоже нечто подобное проглядывается. Но, в итоге, мы всё таки имеем раздельные версии того и другого.

==

2AlexBel:
я сам регулярно имею похожие проблемы: периодически работаю то с семёркой, то с девяткой, но мне бы нужен не только бейсик, но и остальной софт (ИКП, Рапира, Ассемблер.....) с автоматом под обе архитектуры. Возможно, более эффективно было бы пойти по п.1 сразу для всего ИКП.

6 Ответ от avivanov76

  • avivanov76
  • Участник
  • Неактивен

Re: UNI-Бейсик

В теории, как говорится, все возможно :) Но сделать это тяжело и мороки будет много.

С первым подходом основной источник проблем - это начальный загрузчик.

Проблема 1. На семерке сразу после включения доступно только 32 Кб ОЗУ и неважно, сколько там модулей ДопОЗУ и ПсевдоПЗУ - они не инициализируются Монитором. Загрузчик обязан уместиться в эти 32 Кб и еще оставить место для меню и картинки ИКП. На девятке все 128 Кб доступны, поэтому там загрузчик грузится в другие адреса. Мало того, в загрузчике ИКП девятки есть код инициализации модулей ДопОЗУ, который на эти адреса завязан.

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

Проблема 3 - это самомодифицирующийся код. Загрузчик грузит меню ИКП, а меню ИКП патчит код загрузчика. Раз у нас две версии, то и патчить, скорее всего, придется две разных части загрузчика в зависимости от архитектуры. Ну и понятное дело, придется менять код меню тоже.

Проблема 4 - это "стартеры" приложений. В загрузчике есть такие куски кода, которые я называю "стартеры". Дело в том, что когда загружается какая-то часть пакета (например, Рапира или Бейсик), то эта часть ничего не знает про оборудование. Нужен специальный кусочек кода, который скажет той же Рапире, что принтер находится в этом слоте, дисковод в этом и т.д.
Кроме того, запуск той же Рапиры - это не передача управления в одну точку. Там отдельно инициализируется IOSUB, настраиваются процедуры переключения банков памяти и только потом управление передается Рапире.
Так вот, для каждой архитектуры стартеры разные. Так что их тоже придется держать в загрузчике в двух версиях.

Проблема 5 - размеры. Во-первых, увеличится загрузчик, так что поедет раскладка модулей по диску. Во-вторых, загрузчик ИКП работает с диском по линейным адресам (там просто номер сектора от 0 до 1023, трек вычисляется автоматом с учетом формата диска). Проблема в том, что этого может не хватить, поскольку все части пакета тоже будут в двух версиях.
Навскидку я не помню, сколько там секторов занимают компоненты ИКП, но помнится, что на диске 140 КБ места почти не остается, то есть, как раз секторов 400-500 они и занимают.

Второй подход тоже нифига не проще.

Самое сложное там - вызовы между страницами ПсевдоПЗУ. Что в Рапире, что в Бейсике подход примерно один: в ПсевдоПЗУ создается область для межстраничных вызовов. Когда нужно вызвать что-то в соседней странице, управление передается на одну из точек в этой области. Дальше вызывается процедура переключения страниц (она вынесена в основное ОЗУ, поскольку адреса модулей ПсевдоПЗУ пишутся при запуске прямо в код этой процедуры). После этого выполняется инструкция RТS и управление возвращается в область межстраничных вызовов, только это уже другая область, на другой странице ПсевдоПЗУ. И уже там находится код для вызова требующейся процедуры.

Если начать менять код, то будет меняться и его размер. Значит, поедут адреса и даже распределение процедур по страницам ПсевдоПЗУ.
Это будет неисчерпаемый источник проблем :) Если какую-то процедуру придется переместить, то надо будет учесть все сценарии ее использования и все зависимости от других процедур. Потому что на новом месте ей могут оказаться недоступны процедуры, которые были доступны ранее. Отлаживать это все - просто будет сказка. Страшная.
Я поражаюсь вообще терпению разработчиков Рапиры и Бейсика, которые все это отлаживали без эмуляторов и аппаратных отладчиков.

7 Ответ от Voldemar0 Отредактировано Voldemar0 (13-11-2023 06:47)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: UNI-Бейсик

> Загрузчик обязан уместиться в эти 32 Кб и еще оставить место для меню и картинки ИКП.

Картинки для семёрки и девятки разные: разрешение 256x256, но у семёрки это монохром, а у девятки 4 цвета.
Так что определение типа оборудования должно быть ДО загрузки селектора систем, картинки и прочего.
Так как на 140ку двойной ИКП ни в каком варианте не влезет, то речь только о 840ках. А там влезет всё на пару раз легко.


> Если начать менять код, то будет меняться и его размер. Значит, поедут адреса и даже распределение процедур по страницам ПсевдоПЗУ.

Там было попроще всё, я полагаю. Просто по разным банкам раскидывались взаимоисключающие части: например, ДОС и Бейсик. В РАПИРе раскидывался код ДОСа, интерпретатора, прекомпилятора и текстового редактора. Может быть и каких-то ещё редко используемых частей (редкие медленные операторы, например). Т.е. заполнение каждого банка растёт само по себе. Банк, в котором расположена любая процедура, заранее известен.

Если развивать вариант 2, то между такими блоками мало взаимных вызовов и эти шлюзовые вызовы можно было уже оформлять через какие-то процедуры, расположенные достаточно статично: либо с фиксированными адресами (просто вынося их в начало блока, положение которого также фиксировано) либо динамически подстраивающиеся под заранее неизвестные адреса:

 lda #<Far_Function_Addr
 ldx #>Far_Function_Addr
 ldy #Far_Function_Bank
 jsr Far_Call
или
 jsr Far_Call
 dfb Far_Function_Bank
 dfw Far_Function_Addr

Ну чем не RPC ? ;))


> Я поражаюсь вообще терпению разработчиков Рапиры и Бейсика, которые все это отлаживали без эмуляторов и аппаратных отладчиков.

Терпение - дело простое. Это когда тебе ничего так не интересно, как часами и днями сидеть за компом :))

С другой стороны: ну так и ни РАПИРа ни бейсик не блещут прям феноменальной стабильностью в работе (по сравнению с Ямахой, например).
РАПИРа получше (в девяточной есть одна ошибка, которая у меня в эмулях вылазила нередко: вылет на недокументированные команды), ну а бейсик - там своих проблем полно. На семёрке я хорошо это помню. На девятке - тоже, наверное, хватало (судя по статьям Серкова).

8 Ответ от avivanov76 Отредактировано avivanov76 (14-11-2023 01:44)

  • avivanov76
  • Участник
  • Неактивен

Re: UNI-Бейсик

Voldemar0 пишет:

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

Я когда пишу "загрузчик" я имею в виду сектора 1-15, которые грузятся с 0 трека. Меню (программа, которая позволяет выбирать части пакета для загрузки), картинка - это все загрузчик грузит позже.

Кстати, если девяточный загрузчик переделывать на загрузку с другого адреса, то придется заодно перелопачивать все адреса и номера банков в таблицах загрузки. У девятки память поделена на 8 страниц по 8 Кбайт каждая. Штатно загрузчик грузится в 4-ю и все компоненты ИКП грузит с учетом этого. То есть, в свою страницу ничего не грузит. Если пересадить его в 1-ю, то придется менять все адреса в таблицах загрузки.

Мне кажется, чтобы уменьшить объем работы, можно было бы сделать так:
1) грузится загрузчик семерки
2) проверяет, а не на девятке ли он загрузился
3) если на девятке, то он просто берет и грузит загрузчик девятки по стандартному адресу, передает ему управление и дальше тот работает как обычно
4) если нет, то загрузка идет дальше как на семерке (определение оборудования, загрузка меню и картинки и т.д.)

В этом случае придется менять только загрузчик семерки и номера секторов в таблицах загрузки в обоих загрузчиках. Меню трогать не придется.

Voldemar0 пишет:

Просто по разным банкам раскидывались взаимоисключающие части: например, ДОС и Бейсик. В РАПИРе раскидывался код ДОСа, интерпретатора, прекомпилятора и текстового редактора.

Ну не совсем. Например, в Рапире есть процедуры выделения и освобождения памяти. Они нужны всем и всегда. И интерпретатору и препроцессору. То есть, нет такой ситуации, что началось выполнение программы на Рапире, включилась одна страница ПсевдоПЗУ и больше не переключалась до момента завершения программы.

В Бейсике ситуация даже хуже. Рапира-то сразу была сделана с учетом того, что интерпретатор на одной странице, а препроцессор на другой. А Бейсик изначально был монолит в 12 Кбайт (в Apple), и при добавлении новых фич для Агата новые процедуры просто поштучно выкидывались на другую страницу. (Ну, у меня такое ощущение сложилось.)

И тут главное то, что в Рапире обе страницы ПсевдоПЗУ забиты под завязку, а в Бейсике одна из страниц. Поэтому что-то добавлять туда трудно.

Voldemar0 пишет:

Ну чем не RPC ? ;))

Еще можно AJAX назвать. Больше непонятных букв :)

Voldemar0 пишет:

Терпение - дело простое. Это когда тебе ничего так не интересно, как часами и днями сидеть за компом :))

Да, в школьные и студенческие годы с этим было проще. Не приходилось отвлекаться на работу :)