Есть еще один нетрадиционный вариант ускорения бейсика 2.5 (или его потомков) - сделать версию для ориона-про (с мультикартой). В турбо там будет в 3 раза быстрее, с отключенным турбо (переключать можно программно) примерно как на векторе.
Есть еще один нетрадиционный вариант ускорения бейсика 2.5 (или его потомков) - сделать версию для ориона-про (с мультикартой). В турбо там будет в 3 раза быстрее, с отключенным турбо (переключать можно программно) примерно как на векторе.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Привет всем...Сообщение от ivagor
По хорошему - надо компилятор Basic' a делать...
Например, на основе драйверов устройств...
В смысле - на основе библиотеки кодовых процедур...
???
Stl75, компиляторов Бейсика есть целых два, Microsoft BASCOM и Amsterdam Compiler Kit умеет компилировать Бейсик для CPM под 8080, правда без плавучки.
Больше игр нет
Stl75(09.04.2023)
Еще есть игрушечный компилятор бейсика на бейсике BCBC. Его не пробовал, но я и ACK не пробовал.
А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.
Я думаю, Basic - на процедуры разобрали и
получились драйверы устройств...
Там команды - те же самые только в виде процедур...
Если отклониться в частичный оффтоп, то разных компиляторов (не бейсика) для вектора довольно много. ЛС, насколько помню, компилирует в P-код и это сильно на любителя. Если нужна поддержка векторовской графики, то это тоже было/есть. Например в VU30 упоминается "graph.crl - графическая библотека для языка программирования BDS C". А рядом там, кстати, заметка, как рисовать точки и линии средствами паскаля (на примере turbo pascal для z80, но не вижу серьезных препятствий для подобных процедур и в других компиляторах). Были еще библиотеки, возможно PPC подскажет. Ну и не могу в очередной раз не упомянуть z88dk - он умеет компилировать под вектор и там среди прочего есть и поддержка графики. И там проще (по крайней мере для меня) чем в CP/M-овских компиляторах добавлять ассемблерные процедуры.
Чувствую себя очень неловко обсуждая 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 за оффтоп.
ivagor(09.04.2023), metamorpho(10.04.2023), Stl75(09.04.2023)
Очень было бы - хорошо, чтобы кто то осилил данную задачу...Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.
Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...
Последний раз редактировалось Stl75; 09.04.2023 в 22:05.
Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.
Я возьмусь. Но не сейчас. И одному тут точно не справиться. Думаю, одно обсуждение деталей может занять немало. А там есть что обсудить. Правда всё вроде решаемо, но видятся компромиссы (в смысле либо жертвы размером оставшегося пользователю ОЗУ либо - жертвы скорости отрисовки). Но это всё-таки оффтоп.
Сейчас я очень хочу сначала довести один проект до некоего разумного состояния. Погряз
А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой. Тоже трудозатратно учитывая как там всё переплетено, но можно начать с малого.
PS. Чтобы исправиться за флуд/оффтоп, прилагаю свою безуспешную попытку создать некое подобие динамической игры на BASIC 2.5 в далёком 1991м. Тогда я пришёл к тем же выводам что недавно высказал ivagor: BASIC 2.5 в его текущем состоянии для таких игр не самое лучшее средство разработки. В том числе и поэтому, творение получило своё заслуженное название, то бишь "полный и катастрофический провал"...
Зато по поделке становится ясно, где затыки: обработка клавиатуры и вывод спрайтов. Возможно они взывают к изменениям в интерпретаторе.
aGGreSSor(20.07.2025), ivagor(10.04.2023), metamorpho(10.04.2023)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
