Бейсики для Вектора-06Ц и клонов

[Improver]

По хорошему - надо компилятор Basic' a делать...
Например, на основе драйверов устройств...

А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.

[Advertiser]

[Stl75]

А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.

Я думаю, Basic - на процедуры разобрали и
получились драйверы устройств...

Там команды - те же самые только в виде процедур...

[ivagor]

А что если для этого адаптировать ЛС-Паскаль?

Если отклониться в частичный оффтоп, то разных компиляторов (не бейсика) для вектора довольно много. ЛС, насколько помню, компилирует в P-код и это сильно на любителя. Если нужна поддержка векторовской графики, то это тоже было/есть. Например в VU30 упоминается "graph.crl - графическая библотека для языка программирования BDS C". А рядом там, кстати, заметка, как рисовать точки и линии средствами паскаля (на примере turbo pascal для z80, но не вижу серьезных препятствий для подобных процедур и в других компиляторах). Были еще библиотеки, возможно PPC подскажет. Ну и не могу в очередной раз не упомянуть z88dk - он умеет компилировать под вектор и там среди прочего есть и поддержка графики. И там проще (по крайней мере для меня) чем в CP/M-овских компиляторах добавлять ассемблерные процедуры.

[PPC]

Были еще библиотеки, возможно PPC подскажет.

Чувствую себя очень неловко обсуждая runtime окружение и C в теме про BASIC и очень прошу извинить за оффтоп так как совсем не хочется чтобы это повлияло на BASIC движение и его дальнейший генезис. Но раз ты спросил, попробую обозначить несколько моментов как они видятся учитывая по мере сил и BASIC 2.x, и совсем не претендуя на абсолют. Это просто соображения.

Библиотеки были, они есть и они будут - в смысле сращивания графики с языком C. Я серьёзно подумываю над этим но сейчас очень глубоко занят неким другим проектом под Вектор. Он тоже на C (так совпало), видится мне немаловажным, и хочется верить, что также пригодится и по этой теме.

В простейшем случае задача сводится к написанию прослойки, поддерживающей calling convention компилятора или даже интерпретатора. В таком виде у задачи нет ничего сложного, просто готовые функции обрамляются entry/exit кодом с поддерживаемой конвенцией, сохранением регистровых переменных и (если того требует конвенция) расчисткой фрейма перед выходом. Прослойки в общем-то можно делать сменными и тогда можно поддержать что угодно, хотя-бы даже и нативный BASIC интерпретатор. Но в любом случае потом это линкуется монолитом (либо становится частью интерпретатора). В виде графических примитивов могут сойти либо какие-то из моих старых/новых поделок библиотек (поделюсь без проблем) либо супер оптимизированные графические сниппеты которые несколько лет назад делали ivagor, и ко в одной из веток на форуме.

Собственно, простую 2-х цветную графику 512x256 я так срастил очень очень давно, пример есть вот тут. В примере Supersoft С, у него __stdcall (фактически Паскаль). У MS Фортрана __fastcall (2 первых параметра в регистрах <HL>,<DE> остальные если есть в структуре на которую кажет <BC>. У большинства кросс компиляторов __cdecl и <BC> для хранения одной регистровой переменной, я склоняюсь к этому варианту.


Но мне кажется, что более правильно будет стандартизировать и вообще отделить вызываемые функции от конкретного приложения. Типа такой GIOS (он так в GSX-80 и назывался) - графический BIOS. А можно и не только графический, уверен что если мы все скинемся наработками то и всякую иную периферию сможем поддержать и хитрые алгоритмы сжатия и пересылки данных по волнам Векторовской памяти.

Вероятно для пользователя это дожно выглядеть либо в виде сервиса какого-нибудь прерывания, либо - как обычный вызов через единую точку входа (как в CP/M с её call 5 и параметрами). Первое предпочтительнее, rst эффективнее чем call, мы то знаем что на Векторе прерывания точно поддерживаются. Гари Килдалл таких предпосылок не имел. Сервисный вызов вполне может быть "многослойным". Программа для конкретного компилятора в виде первого сервисного вызова может просто ставить переходник-толмач поверх стандартно выбранной конвенции о вызовах (скажем, поверх чего-то __cdecl - подобного).
Тогда не будет проблемы с медленной линковкой сотен функций и позиционная независимость: Векторовская графика может быть уже предзагружена хоть в некий ROM, хоть-как часть ОС. Главное чтобы "линковка" была так или иначе by ordinal.

Примитивы можно вообще запихнуть в квазидиск.

Если всё правильно организовать, это может выглядеть как R/O системный файл CP/М или МикроДОСа находящийся на определённых дорожках квазидиска.
Возможно, RDS тут использовать предпочтительнее, хотя и в стандартной CP/M и в МикроДОСе тоже есть стандартный user extension вход для расширения функций системы. Под большинство ОС можно иметь до 8 цветов (или 16 если в этот момент не нужны функции BIOS. Пример - Robotz, где все меню 16-цветные а BIOS временно перемещён на квазидиск). Опять-же с Баркарём можно как-то это подружить в перспективе.
А если программе вообще не нужна ОСь то все 16 цветов доступны всегда.

Главное - договориться о стандартной системе вызовов и присвоить номера вызываемым функциям.

По секрету. Такую "стандартную" систему входов я также делал в далёких 90х. Оно работало, даже код сохранился где-то. Самое главное - стандартизировать соглашения о сервисных вызовах.

Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.
Такие мысли всякие. Ещё раз sorry за оффтоп.

[Stl75]

Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.

Очень было бы - хорошо, чтобы кто то осилил данную задачу...

Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...

[PPC]

Очень было бы - хорошо, чтобы кто то осилил данную задачу...

Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...

Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.

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

А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой. Тоже трудозатратно учитывая как там всё переплетено, но можно начать с малого.


PS. Чтобы исправиться за флуд/оффтоп, прилагаю свою безуспешную попытку создать некое подобие динамической игры на BASIC 2.5 в далёком 1991м. Тогда я пришёл к тем же выводам что недавно высказал ivagor: BASIC 2.5 в его текущем состоянии для таких игр не самое лучшее средство разработки. В том числе и поэтому, творение получило своё заслуженное название, то бишь "полный и катастрофический провал"...

Зато по поделке становится ясно, где затыки: обработка клавиатуры и вывод спрайтов. Возможно они взывают к изменениям в интерпретаторе.

[ivagor]

А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой.

Собственно в 2.70 так и сделано и без убирания некоторых компонентов для освобождения места дальнейшее заметное ускорение вряд ли возможно. Есть 3 вещи, которые можно сильно ускорить в runtime библиотеке (без перехода к компиляции): PUT (при ширине фрагмента кратной 8 точек), PAINT (выкладывал отдельно соответствующую процедуру), вывод символов. В этих задачах ускорение возможно за счет перехода от пикселей к байтам, проблема в нехватке места и в совместимости. Если убрать из бейсика быстрый набор, то скорее всего получится впихнуть быстрый PUT или PAINT (не вместе, а быстрые символы точно не поместятся). А про компилятор повторю мысль, которую уже писал: если нацеливаться на компиляцию 2.5, то runtime библиотка - не проблема (она уже есть), проблема в трансляторе.

[metamorpho]

......Есть 3 вещи, которые можно сильно ускорить в runtime библиотеке (без перехода к компиляции): PUT (при ширине фрагмента кратной 8 точек), PAINT (выкладывал отдельно соответствующую процедуру), вывод символов. В этих задачах ускорение возможно за счет ..........

А каков шанс ускорить команду POKE ? Например если там отключить проверку адреса куда заносятся данные (это не повлияет на совместимость), то насколько быстрее будет работать такой вариант ?
Может там ещё чего подкрутить можно, но так чтобы сохранялась совместимость со старыми программами на Бейсике.

[ivagor]

Могу порекомендовать использовать в POKE шестнацатеричные числа (например &0F вместо 15) в качестве аргументов, это может ускорить чуть ли не в 2 раза (конечно не всю программу, только POKE).

[Stl75]

Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.

Готовые компиляторы - есть для других ретро - платформ...
Например, ZX Boriel Basic - для Спектрума...
www.boriel.com

Либо компиляторы на ассемблере -
MCoder 2, например...

На MCoder 2 - фирма Atlantis Software -
выпустила множество игр...

Список игр на - www.vtrd.in - можно посмотреть...