А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.Цитата:
Сообщение от Stl75
Вид для печати
А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.Цитата:
Сообщение от Stl75
Я думаю, Basic - на процедуры разобрали иЦитата:
Сообщение от Improver
получились драйверы устройств...
Там команды - те же самые только в виде процедур...
Если отклониться в частичный оффтоп, то разных компиляторов (не бейсика) для вектора довольно много. ЛС, насколько помню, компилирует в P-код и это сильно на любителя. Если нужна поддержка векторовской графики, то это тоже было/есть. Например в VU30 упоминается "graph.crl - графическая библотека для языка программирования BDS C". А рядом там, кстати, заметка, как рисовать точки и линии средствами паскаля (на примере turbo pascal для z80, но не вижу серьезных препятствий для подобных процедур и в других компиляторах). Были еще библиотеки, возможно PPC подскажет. Ну и не могу в очередной раз не упомянуть z88dk - он умеет компилировать под вектор и там среди прочего есть и поддержка графики. И там проще (по крайней мере для меня) чем в CP/M-овских компиляторах добавлять ассемблерные процедуры.Цитата:
Сообщение от Improver
Чувствую себя очень неловко обсуждая runtime окружение и C в теме про BASIC и очень прошу извинить за оффтоп так как совсем не хочется чтобы это повлияло на BASIC движение и его дальнейший генезис. Но раз ты спросил, попробую обозначить несколько моментов как они видятся учитывая по мере сил и BASIC 2.x, и совсем не претендуя на абсолют. Это просто соображения.Цитата:
Сообщение от ivagor
Библиотеки были, они есть и они будут - в смысле сращивания графики с языком 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 за оффтоп.
Очень было бы - хорошо, чтобы кто то осилил данную задачу...Цитата:
Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.
Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...
Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.Цитата:
Сообщение от Stl75
Я возьмусь. Но не сейчас. И одному тут точно не справиться. Думаю, одно обсуждение деталей может занять немало. А там есть что обсудить. Правда всё вроде решаемо, но видятся компромиссы (в смысле либо жертвы размером оставшегося пользователю ОЗУ либо - жертвы скорости отрисовки). Но это всё-таки оффтоп.
Сейчас я очень хочу сначала довести один проект до некоего разумного состояния. Погряз ;)
А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой. Тоже трудозатратно учитывая как там всё переплетено, но можно начать с малого.
PS. Чтобы исправиться за флуд/оффтоп, прилагаю свою безуспешную попытку создать некое подобие динамической игры на BASIC 2.5 в далёком 1991м. Тогда я пришёл к тем же выводам что недавно высказал ivagor: BASIC 2.5 в его текущем состоянии для таких игр не самое лучшее средство разработки. В том числе и поэтому, творение получило своё заслуженное название, то бишь "полный и катастрофический провал"...
Зато по поделке становится ясно, где затыки: обработка клавиатуры и вывод спрайтов. Возможно они взывают к изменениям в интерпретаторе.
Собственно в 2.70 так и сделано и без убирания некоторых компонентов для освобождения места дальнейшее заметное ускорение вряд ли возможно. Есть 3 вещи, которые можно сильно ускорить в runtime библиотеке (без перехода к компиляции): PUT (при ширине фрагмента кратной 8 точек), PAINT (выкладывал отдельно соответствующую процедуру), вывод символов. В этих задачах ускорение возможно за счет перехода от пикселей к байтам, проблема в нехватке места и в совместимости. Если убрать из бейсика быстрый набор, то скорее всего получится впихнуть быстрый PUT или PAINT (не вместе, а быстрые символы точно не поместятся). А про компилятор повторю мысль, которую уже писал: если нацеливаться на компиляцию 2.5, то runtime библиотка - не проблема (она уже есть), проблема в трансляторе.Цитата:
Сообщение от PPC
А каков шанс ускорить команду POKE ? Например если там отключить проверку адреса куда заносятся данные (это не повлияет на совместимость), то насколько быстрее будет работать такой вариант ?Цитата:
Сообщение от ivagor
Может там ещё чего подкрутить можно, но так чтобы сохранялась совместимость со старыми программами на Бейсике.
Могу порекомендовать использовать в POKE шестнацатеричные числа (например &0F вместо 15) в качестве аргументов, это может ускорить чуть ли не в 2 раза (конечно не всю программу, только POKE).
Готовые компиляторы - есть для других ретро - платформ...Цитата:
Сообщение от PPC
Например, ZX Boriel Basic - для Спектрума...
www.boriel.com
Либо компиляторы на ассемблере -
MCoder 2, например...
На MCoder 2 - фирма Atlantis Software -
выпустила множество игр...
Список игр на - www.vtrd.in - можно посмотреть...
Посмотрел, особых резервов там нет, получилось ускорить на 5% относительно 2.70. Если будут еще версии, то эта доработка там будет, но вряд ли это будет заметно. А вот использование шестнадцатеричных сказывается гораздо сильнее (особенно если POKE используется активно).Цитата:
Сообщение от metamorpho
Решил попробовать использовать шестнадцатеричные числа (заменил в POKE все десятичные) - Бейсик упрямо выдаёт синтаксическую ошибку в строке 297Цитата:
Сообщение от ivagor
297 POKE BD-256,&00,&00,&00,&00,&00,&00,&00,&00:POKE BD,&20,&70,&60,&E0,&60,&60,&C0,&C0:GOTO 330
Что в ней не так не пойму ?
Там данные по-моему, по байту...Цитата:
297 POKE BD-256,&00,&00,&00,&00,&00,&00,&00,&00:POKE BD,&20,&70,&60,&E0,&60,&60,&C0,&C0:GOTO 330
Через запятую - нельзя...
Это ошибка 2.5, в моих модификациях этот баг давно исправлен (пункт 3 в readme). В 2.5 надо чтобы POKE с шестнадцатеричными был последним оператором в строке.
Да точно. Запустил на Бейсике 2.70 и всё работает. Человечек стал немного шустрее бегать.Цитата:
Сообщение от ivagor
Хочется все же сохранить совместимость с 2.5. Можно последнее число в POKE (перед двоеточием) сделать десятичным, а остальные пусть будут шестнадцатеричными.
Какой смысл сохранять совместимость с багами 30-летней давности? Если бы это был Бейсик из ПЗУ, то конечно. Но тут-то.Цитата:
Сообщение от ivagor
В пределе можно рассмотреть совсем безумные идеи патча интерпретатора на лету. Если, скажем удастся локализовать код исходных операторов большими кусками, то можно делать отдельные куски "микрокода" команд. Например, делаем BLOAD в ленточной версии BASIC или LOAD DATA в дисковом BASIC 2.5, загружая микрокод команды в интерпретатор на место быстрого набора зарезервированных слов (или какой-другой команды).Цитата:
Сообщение от ivagor
Или, cкажем, расширяем оператор SCREEN новыми смыслами на которые по умолчанию стоят заглушки.
Может и правда начать с генерации какого-либо P-кода?Цитата:
Сообщение от ivagor
Скажем, в Supersoft C есть т.н. Optimizer - отдельный исполняемый файл C2.COM, основная задача которого - перетолмачивание P-кода сгенерённого компилятором в ассемблерный выхлоп (то что он какой-нить peephole optimization ещё делает-скорее доп. фича).
Этот конкретный P-код хранится в виде текстового файла, так что можно на лету играться. Пример:
Скрытый текст
C65 2
D27 sh_font
D3 DLG_FONT
B9
D27 wn_inactive
C65 2
C1
B9
D27 bm_prompt
C65 2
D3 DLG_INFO
B9
D27 wn_inactive
C65 2
B12
B99
H61 sigterm
C1
B9
D27 textcolor
C65 2
D27 clrscr
D27 sh_csr
C1
B9
D27 exit
C65 2
[свернуть]
Недостаток в том что вот этот конкретный генератор возможно не поддерживает floating point типы данных.
Конечно, придётся разбираться во всех p-кодах, дописывать (использовать) рантайм для операций над типами и т.п.
ЛС-Паскаль уже предлагался, там вроде UCSD p-code, не уверен. Если так, то там стеков гора и быстро на ВМ80 не выйдет.
Возможно уже где-то есть P-код генератор для какого-нибудь абстрактного Бейсика и компилятор P-кода в i8080 c исходниками на C.
Если так, то портануть его на какой-нибудь C для CP/M ;) и допилить до совместимости с BASIC 2.5 будет чуть проще, хоть и всё равно гора работы.
1. Для самоудовлетворения мне нужна точка отсчета, чтобы получать удовольствие от того, насколько мои модификации быстрее. Эту причину можно смело игнорировать.Цитата:
Сообщение от svofski
2. На данный момент есть дисковые версии только 2.5. Надо делать свой дисковый вариант, много лет собираюсь.
Надо определиться, что важнее - скорость или размер. Если скорость, то никакого байт-кода, только ассемблер, но тогда многие откомпилированные старые программы не поместятся в памяти.Цитата:
Сообщение от PPC
ACK тоже компилирует свои языки (среди которых есть Бейсик) в какой-то промежуточный код. Если у тебя настроение есть в этом копаться, посмотри что там.Цитата:
Сообщение от PPC
Что до p-кода, мы уже играли в похожую вещь, когда делали ZPU8080. Конечно zpu совсем не для 8080, это было чисто цирковое выступление и, может быть, можно придумать получше именно для 8080. Но я чего-то забыл, мы какую задачу решаем?
Если хочется скомпилировать Бейсик любой ценой, то почему не подходят те компиляторы, что уже есть? Если плавучка, то плавучка в ACK есть, нету только библиотеки, которая ее реализовывает.
Лично мне было бы прикольно попробовать сделать Бейсик наподобие 2.5, но не подглядывая в 2.5. По крайней мере кроме все той же злосчастной плавучки, вот чего делать самому было бы не прикольно. И посмотреть, насколько плохо все получится. Но это, опять же, из категории цирковых номеров, не дай бог углядеть в этом какую-то практическую ценность.
Привет всем...Цитата:
Надо определиться, что важнее - скорость или размер. Если скорость, то никакого байт-кода, только ассемблер, но тогда многие откомпилированные старые программы не поместятся в памяти.
На мой взгляд основная разница программ на Basic' e и в коде - именно в скорости выполнения...
???
Как metamorpho сказал, чтобы человек по быстрее бегал...Цитата:
Человечек стал немного шустрее бегать.
Если честно, то я не до конца уверен, какую. Мне представляется, все решили писать компиляторЦитата:
Сообщение от svofski
Я так понимаю, BASCOM всем/кому-то (не мне) не подходит потому, чтоЦитата:
Сообщение от svofski
1. Это не BASIC 2.5 семантически
2. У него нет Векторовского нативного рантайма (что решаемо, но это всё равно не будет BASIC 2.5)
А ведь у BASCOM, кроме того что он цомпилер должен быть ещё и целочисленный integer...
Ооо, денормализации мантиссы, сдвиги порядков...нет уж, увольте. Я тоже там был неск. раз отлаживая плавучку на асме. Не хочуЦитата:
По крайней мере кроме все той же злосчастной плавучки, вот чего делать самому было бы не прикольно. И посмотреть, насколько плохо все получится.
Зачем же тогда компилировать именно Бейсик. Можно компилировать языки поприятнее. То, что делает metamorpho, прикольно именно тем, что оно сделано вот на таком вот Бейсике как у всех был.Цитата:
Сообщение от PPC
Плавучка отдельно выдранная из Бейсика уже есть, тут пробегала пару страниц назад. Так что по идее можно ее взять, аккуратно вклеить в библиотеку ACK на место заглушек, вот и все дела. Наверняка повозиться придется конечно все равно, но все-таки это не то же самое, что ее писать.
Вопрос со звездочкой: а кому вообще сдалась и на что эта плавучка в Бейсике? В классическом варианте она была ценна тем, что получался могучий калькулятор. А сейчас?
Думаю, в твоём вопросе есть и неявный ответ: все хотят не просто компилятор какого-то абстрактного языка бейсик, а компилятор именно для Векторовского BASIC 2.5, что бы он из себя не представлял исторически, и откуда бы не произрастали его корни. Идея, как я понимаю такая: ты ему скармливаешь BAS или CAS файл, а на выхлопе - COM или даже монолитный ROM. Иначе отчего в этой теме про BASIC 2.5 столько постов...это "родные валенки", все их так или иначе носили. Вполне нормальное желание, хотя за всех говорить... просто мне так кажется.Цитата:
Сообщение от svofski
Мне всё-таки нравится, когда я могу запустить компилятор на таргет платформ. Хотя ничего плохого в ACK нет. Но Aztec - исключительно прикольный цомпилер. Гораздо более доставляет, чем Pascal MT+. И потом, это ведь Томас Фенвик, живая легенда, выкинувшая в окно многолетние потуги MS и написавший за 3 месяца Win CE... а ACK - это кросс-средство в себе и оно чуть в стороне и слегка "полноватое", как язык Ада.Цитата:
Сообщение от svofski
Хотя оба генерят чудовищный код... Подозреваю, можно гораздо лучше, даже не кросс, а прямо на платформе.
Насчёт плавучки, она полезна. Но для определённого круга задач (Фортран их решал). От того, что есть многоядерные FPU, Векторовская плавучка хуже не стала. Это-как с 12м айфоном, или какой там был предыдущий. Ну и потом, AMD выпускал сопроцессоры. Можно подумать об HDL архитектуре с таким.
Все наши задачи и достижения вообще с практической точки зрения не имеют смысла. Эзотерика, но нам ведь нравится :)
Ну да, понятно. У меня похожее, но чуть-чуть рядом. Интересно чтобы был Бейсик c REPL, а не компилятор. Пусть он будет похож на 2.5, но мне норм, если там какие-то эзотерические параметры у оператора SCREEN отвалятся. Я бы даже может наоборот, замутил какой-нибудь SCREEN эзотеричней всех, что уже были. С другой стороны вот эту сатанинскую муть с отсутствием пробелов хочется сохранить, а то это уже не совсем Бейсик получается.
Что до плавучки -- дело не в том, что она стала хуже, а в том, что считать чего-нибудь на Векторе вряд ли кто станет. Поэтому ставить себе творческий блок в виде недостижимой плавучки по-моему нелепо.
В бейсике 5.x микрософт изменил синтаксические требования и пробелы стали обязательны. В BASCOM есть параметр, который позволяет компилировать по новым или "старым" правилам.Цитата:
Сообщение от svofski
Пламенное обсуждение вариантов Бейсика, разбудило и во мне фантазии на эту тему :)
Если описывать какой нужен новый Бейсик, то мне думается так:
1. Писать например компилятор обязательно совместимый с программами Бейсик v.2.5. ?? а какой в этом смысл ? если
цель компилятора ускорить выполнение программы, то ускорить старые Бейсик программы можно нажатием F10 (12 Мгц)
2. А если уж есть жгучее желание написать компилятор языка Бейсик, то это должен быть мощный Бейсик, свободный от
костылей совместимости со всеми предыдущими Бейсиками. Вобравший в себя все лучшие (оптимизированные и быстрые)
наработки и идеи. И заточен этот чудо Бейсик для более БЫСТРОГО и УДОБНОГО создания игровых программ и
демосцены. Например я бы включил в этот компилятор-Бейсик следующее:
- обязательная часть ядро-основа это основные Бейсик операторы (циклы, if then else, goto, gosub, работа с клавиатурой и подобное)
- возможность встроенных в код бейсика подпрограмм на ассемблере
И далее следует Глобальная модульность вокруг основного ядра, т.е. со всеми остальными операторами (по отдельности)
есть возможность включить или не включить их в свой скомпилированный код - это даст очень гибкую и эффективную
экономию памяти (это чем то напоминает идею из "драйверов устройств", но здесь у нас будет простота и в тоже время
удобство и мощность нового Бейсика).
Допустим из математических операторов мне нужен только sin() и соs(), а остальные математические функции
(тангенс, арктангенс, логариф, возведение в степень и т.д.) мне не нужны, поэтому при компиляции подключается код
только этих двух нужных мне функций и всё.
Если нам совсем не нужны строковые функции, то и не нужно их подключать.
Допустим мне нужен оператор рисующий линии и прямоугольники, а все остальные (окружности, точки, paint,
point и т.п) мне не нужны - соответственно компилятор их не подключает.
Ещё например мне нужен распаковщик (типа zip), чтобы распаковать область данных начиная со строки (или
метки) такой-то. Или же чтобы читать данные из файла и на лету их распаковывать в указанную область памяти.
Ещё было бы здорово иметь настраиваемый модуль загруки - например обычная загрузка, скоростная загрузка,
загрузка аля-zx spectrum и ещё что-нибудь.
Конечно музыка и звуки. beep и play (на выбор ВИ53 или AY) - с возможностью подключения разных движков тяжёлых и лёгких.
Оператор супер-быстрого вывода спрайта несколько разных вариантов - с оптимизацией по размеру, с указанием во сколько плоскостей выводить.......Например нам нужен только один вариант - вывод спрайтов 16х16 точек в две плоскости и компилятор включает в скомпилированный код только этот вариант вывода спрайта.
Ещё я бы включил оператор скроллинга указанной области экрана, программу голосового робото-чтения букв и .... другие хотелки-модули :)
По-моему Бейсик на ДВК-1 задавал в начале разные неудобные вопросы типа "НУЖНЫ ЛИ ВАМ РАСШИРЕННЫЕ ФУНКЦИИ?".Цитата:
Сообщение от metamorpho
А работать со строками он совсем не умел. Ты не ошибся с выбором платформы? =)))Цитата:
Сообщение от metamorpho
Привет всем...Цитата:
Сообщение от PPC
Ну я - примерно так и хотел...
Компилятор для Вектор Basic' a v2.5...
Открываешь - .bas, .cas - на выходе .com, .rom...
Как то - так...
Некоторые версии микрософтовского тоже задавали подобные вопросы, тогда это было актуально.Цитата:
Сообщение от svofski
При ковырянии бейсика выявляются некоторые вещи, которые мне кажутся интересными:
1. Реализация LINE в 2.5 использует однобайтный Y и двухбайтный X. Причем рисование линии не менялось с 1.3 (в Сигнале аналогично). И везде эта линия в паре с рисованием точки 0-255,0-255. Думаю линию позаимствовали где-нибудь.
2. Штатный POKE все же может нагадить в бейсик. POKE&FFFF, - первое значение попадет в FFFF, а следующие в 0000, 0001 и т.д. Глубина повреждений ограничивается длиной строки бейсика.
- - - Добавлено - - -
Еще мелкий момент. POKE и PEEK могут менять и смотреть не только знакогенератор и несколько следующих ячеек, но и почти все 3 буфера нот. Как это можно использовать - теоретически можно играть музыку без PLAY и символьных переменных, напрямую POKE в буфер.
Непонял мысль про "ошибся с выбором платформы". Подозреваю я что-то недопонимаю в компиляции.Цитата:
Сообщение от svofski
Понимание и обработка компилятором строковых переменных и констант входит в основоное ядро кода - и из него ничего
отключить нельзя. А вот строковые функции, о которых я написал, это имеется ввиду функция MID, RIGHT, STR, LEFT и
др. - вот эти функции подключаются только если они нужны.
Мой компилятор-чудо-Бейсик не будет задавать вопросов как на ДВК-1 :)
Конечно возможно я не совсем понимаю внутренности процесса компиляции, но вот как в общих чертах мне
представляется этот процесс на реальном Векторе:
- набираем и записываем в файл код программы как в обычном Бейсике (здесь всё происходит в текстовом редакторе с
некоторыми удобными настройками и подсветкой операторов и т.п.)
- далее запускаем с диска компилятор, который анализирует наш код. Компилятор выявляет все операторы и функции,
которые использует наша программа. Далее компилятор загружает с диска нужные модули (код отдельных функций и
операторов, либо другой вариант - по очереди загружает соответсвующие библиотеки - например библиотека строковых
функций или библиотека работы с графикой - и уже в библиотеке находит нужный код и вставляет его в память или в
темп-файл) и в итоге компилятор собирает все модули, которые используются в нашей программе. Далее в программу
вставляются адреса вызовов функций (с входными и выходными параметрами если нужно).
- далее формируется выходной файл ROM или COM (а ещё можно сделать фишку EXE файл, чтобы запускалось на PC -
тогда будет ретро игра сразу на двух платформах - со всеми пользами и интересностями)
Про выбор платформы была шутка. Бейсик на ДВК-1 был хтоническим спавном какой-то одной из древнейших версий Бейсика, которая не далеко ушла от калькулятора.
Что до остального, все это, включая компиляцию в x86, ACK уже предположительно (*) умеет. Отличие только в каких-то деталях синтаксиса и в том, что для Вектора нужно сделать библиотеку. Можно приделать свою в нужном объеме.
*) Предположительно, потому что что-то существенное я им компилировал и запускал только на языке Си. Но пробную программу на Бейсике типа Хелло вродл тоже собрал и работает.
**) Повторюсь, что в случае кросс-компиляции мне остается непонятным выбор языка. Зачем истязать себя Бейсиком, если при этом не сохраняется его основная ламповая фича -- спонтанность и интерактивность? Если сбросить с себя оковы бейсика, открывается путь еще к z88dk.
Функция INT() для меня загадка:
С обычными числами он ведет себя как floor(). Странно для отрицательных чисел, но работает как обещано, что ж поделать. А если число с порядком, то типа сам дурак? Как быть?Код:=>
PRINTINT(1.5E33)
1.5E+33
=>
PRINTINT(5.7)
5
=>
PRINTINT(-5.7)
-6
а что не так? 1.5х10^33 это же целое число.Цитата:
Сообщение от svofski
Да, так все и объясняется. Просто я когда думаю "целое", мне представляется целое, которое помещается в переменную целого типа. Которого кроме всего прочего в этом Бейсике и нет.Цитата:
Сообщение от Ramiros
Еще поускорял где смог, перечень оптимизаций в readme
- - - Добавлено - - -
Забыл в начале readme исправить номер на 2.71, менять архив из-за такой мелочи не буду, там дальше все правильно.
Слова про z88dk я пожалуй беру обратно. Компилятор глючный как чорт.
Да, глюков там полно, но если не портировать готовые программы, а писать с нуля, то глюки можно обходить. Это неудобно и неприятно, но скорость откомпилированных программ сравнительно хорошая и даже есть пара библиотек плавучки. SDCC лучше, но ему нужен z80 и искаропки он не знает про вектор (что решаемо).
- - - Добавлено - - -
оффтоп про Си
Прошу прощения за повторение, вроде уже писал, но тут наверно к месту. Когда портировал jpeg, то В КАЖДОМ из 3х попробованных компиляторов обнаружились баги, причем разные. Самый правильный - zpu8080, там был виноват я сам, ошибся в библиотеке. Замечательно, но медленно. Ошибку в SDCC я обошел, а через некоторое время ее исправили, супер, если бы не z80. И только z88dk никто на тему бага не думал править, скорее всего он до сих пор есть. C другой стороны, когда писал в z88dk маленькие тестовые программки, то все было нормально. А вот когда пробовал рейкастер с плавучкой и текстурами, вот там опять полезли иррациональные глюки, которые более-менее решились только когда стала доступна другая (микрософтовская) библиотека плавучки. С "любительскими" компиляторами для не самых популярных ретроплатформ все непросто.[свернуть]
Это может быть так, когда глюки известные и стабильные. Тогда их можно принять как ограничения и с этим жить. Это не только для 8080 так бывает. Но когда один и тот же код в зависимости от вставленного где-то посередине printf(), или выбора опций, работает совершенно по разному, это получается совершенно невозможная путаница. Главное, что ты никогда не знаешь, исправят это в завтрашней версии, или испортят еще хуже. Я бы и рад помочь разработчикам хотя бы хорошим багрепортом, но глюки настолько эзотерические, что я не могу даже привести хороших тестовых примеров. Хотя вообще z88dk ценная вещь и наверняка когда-нибудь глючность его станет незначительной.Цитата:
Сообщение от ivagor
Кстати о zpu8080, игру в стиле ANTIGRAV на нем наверное можно забацать и пошустрее, чем получилось на Бейсике. Но процесс разработки боюсь не для всех =)
Вот того, что в z88dk что-то исправят я бы сильно не опасался, там, насколько могу судить, направленность на добавление фич (больше библиотек, больше платформ), а не на их отладку. Хотя я некоторое время не слежу, может ситуация поменялась.Цитата:
Сообщение от svofski
У zpu8080 сильные стороны: безглючность (особенно если сравнить с z88dk), современность (про z88dk молчу, SDCC получше, но GCC круче) и (надо же и себя похвалить) быстрая целочисленная арифметика. Основные минусы: невысокая скорость результирующих программ и сложность организации процесса разработки для непрограммистов типа меня. Есть еще нереализованная уникальная фича - теоретически можно переделать интерпретатор zpu для работы (например с квазом) с адресным пространством >64 Кб. Скорость это снизит, зато большие программы. Для игр все же zpu8080 мне кажется не очень пригоден, хотя может для текстовых.