Просмотр полной версии : Бейсики для Вектора-06Ц и клонов
каков шанс ускорить команду POKE ?
Посмотрел, особых резервов там нет, получилось ускорить на 5% относительно 2.70. Если будут еще версии, то эта доработка там будет, но вряд ли это будет заметно. А вот использование шестнадцатеричных сказывается гораздо сильнее (особенно если POKE используется активно).
metamorpho
10.04.2023, 20:48
Посмотрел, особых резервов там нет, получилось ускорить на 5% относительно 2.70. Если будут еще версии, то эта доработка там будет, но вряд ли это будет заметно. А вот использование шестнадцатеричных сказывается гораздо сильнее (особенно если POKE используется активно).
Решил попробовать использовать шестнадцатеричные числа (заменил в POKE все десятичные) - Бейсик упрямо выдаёт синтаксическую ошибку в строке 297
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 с шестнадцатеричными был последним оператором в строке.
metamorpho
10.04.2023, 21:27
Это ошибка 2.5, в моих модификациях этот баг давно исправлен (пункт 3 в readme). В 2.5 надо чтобы POKE с шестнадцатеричными был последним оператором в строке.
Да точно. Запустил на Бейсике 2.70 и всё работает. Человечек стал немного шустрее бегать.
Хочется все же сохранить совместимость с 2.5. Можно последнее число в POKE (перед двоеточием) сделать десятичным, а остальные пусть будут шестнадцатеричными.
Хочется все же сохранить совместимость с 2.5.
Какой смысл сохранять совместимость с багами 30-летней давности? Если бы это был Бейсик из ПЗУ, то конечно. Но тут-то.
скорее всего получится впихнуть быстрый PUT или PAINT (не вместе, а быстрые символы точно не поместятся).
В пределе можно рассмотреть совсем безумные идеи патча интерпретатора на лету. Если, скажем удастся локализовать код исходных операторов большими кусками, то можно делать отдельные куски "микрокода" команд. Например, делаем BLOAD в ленточной версии BASIC или LOAD DATA в дисковом BASIC 2.5, загружая микрокод команды в интерпретатор на место быстрого набора зарезервированных слов (или какой-другой команды).
Или, cкажем, расширяем оператор SCREEN новыми смыслами на которые по умолчанию стоят заглушки.
А про компилятор повторю мысль, которую уже писал: если нацеливаться на компиляцию 2.5, то runtime библиотка - не проблема (она уже есть), проблема в трансляторе.
Может и правда начать с генерации какого-либо P-кода?
Скажем, в 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 будет чуть проще, хоть и всё равно гора работы.
Какой смысл сохранять совместимость с багами 30-летней давности?
1. Для самоудовлетворения мне нужна точка отсчета, чтобы получать удовольствие от того, насколько мои модификации быстрее. Эту причину можно смело игнорировать.
2. На данный момент есть дисковые версии только 2.5. Надо делать свой дисковый вариант, много лет собираюсь.
Может и правда начать с генерации какого-либо P-кода?
Надо определиться, что важнее - скорость или размер. Если скорость, то никакого байт-кода, только ассемблер, но тогда многие откомпилированные старые программы не поместятся в памяти.
Может и правда начать с генерации какого-либо P-кода?
ACK тоже компилирует свои языки (среди которых есть Бейсик) в какой-то промежуточный код. Если у тебя настроение есть в этом копаться, посмотри что там.
Что до p-кода, мы уже играли в похожую вещь, когда делали ZPU8080. Конечно zpu совсем не для 8080, это было чисто цирковое выступление и, может быть, можно придумать получше именно для 8080. Но я чего-то забыл, мы какую задачу решаем?
Если хочется скомпилировать Бейсик любой ценой, то почему не подходят те компиляторы, что уже есть? Если плавучка, то плавучка в ACK есть, нету только библиотеки, которая ее реализовывает.
Лично мне было бы прикольно попробовать сделать Бейсик наподобие 2.5, но не подглядывая в 2.5. По крайней мере кроме все той же злосчастной плавучки, вот чего делать самому было бы не прикольно. И посмотреть, насколько плохо все получится. Но это, опять же, из категории цирковых номеров, не дай бог углядеть в этом какую-то практическую ценность.
Надо определиться, что важнее - скорость или размер. Если скорость, то никакого байт-кода, только ассемблер, но тогда многие откомпилированные старые программы не поместятся в памяти.
Привет всем...
На мой взгляд основная разница программ на Basic' e и в коде - именно в скорости выполнения...
???
Человечек стал немного шустрее бегать.
Как metamorpho сказал, чтобы человек по быстрее бегал...
ACK тоже компилирует свои языки (среди которых есть Бейсик) в какой-то промежуточный код. Если у тебя настроение есть в этом копаться, посмотри что там.
<snip>
Но я чего-то забыл, мы какую задачу решаем?
Если честно, то я не до конца уверен, какую. Мне представляется, все решили писать компилятор
Если хочется скомпилировеать Бейсик любой ценой, то почему не подходят те компиляторы, что уже есть? Если плавучка, то плавучка в ACK есть, нету только библиотеки, которая ее реализовывает.
Я так понимаю, BASCOM всем/кому-то (не мне) не подходит потому, что
1. Это не BASIC 2.5 семантически
2. У него нет Векторовского нативного рантайма (что решаемо, но это всё равно не будет BASIC 2.5)
А ведь у BASCOM, кроме того что он цомпилер должен быть ещё и целочисленный integer...
По крайней мере кроме все той же злосчастной плавучки, вот чего делать самому было бы не прикольно. И посмотреть, насколько плохо все получится.
Ооо, денормализации мантиссы, сдвиги порядков...нет уж, увольте. Я тоже там был неск. раз отлаживая плавучку на асме. Не хочу
Если честно, то я не до конца уверен, какую. Мне представляется, все решили писать компилятор
Зачем же тогда компилировать именно Бейсик. Можно компилировать языки поприятнее. То, что делает metamorpho, прикольно именно тем, что оно сделано вот на таком вот Бейсике как у всех был.
Плавучка отдельно выдранная из Бейсика уже есть, тут пробегала пару страниц назад. Так что по идее можно ее взять, аккуратно вклеить в библиотеку ACK на место заглушек, вот и все дела. Наверняка повозиться придется конечно все равно, но все-таки это не то же самое, что ее писать.
Вопрос со звездочкой: а кому вообще сдалась и на что эта плавучка в Бейсике? В классическом варианте она была ценна тем, что получался могучий калькулятор. А сейчас?
Зачем же тогда компилировать именно Бейсик. Можно компилировать языки поприятнее. То, что делает metamorpho, прикольно именно тем, что оно сделано вот на таком вот Бейсике как у всех был.
Думаю, в твоём вопросе есть и неявный ответ: все хотят не просто компилятор какого-то абстрактного языка бейсик, а компилятор именно для Векторовского BASIC 2.5, что бы он из себя не представлял исторически, и откуда бы не произрастали его корни. Идея, как я понимаю такая: ты ему скармливаешь BAS или CAS файл, а на выхлопе - COM или даже монолитный ROM. Иначе отчего в этой теме про BASIC 2.5 столько постов...это "родные валенки", все их так или иначе носили. Вполне нормальное желание, хотя за всех говорить... просто мне так кажется.
Так что по идее можно ее взять, аккуратно вклеить в библиотеку ACK на место заглушек, вот и все дела. Наверняка повозиться придется конечно все равно, но все-таки это не то же самое, что ее писать.
Мне всё-таки нравится, когда я могу запустить компилятор на таргет платформ. Хотя ничего плохого в ACK нет. Но Aztec - исключительно прикольный цомпилер. Гораздо более доставляет, чем Pascal MT+. И потом, это ведь Томас Фенвик, живая легенда, выкинувшая в окно многолетние потуги MS и написавший за 3 месяца Win CE... а ACK - это кросс-средство в себе и оно чуть в стороне и слегка "полноватое", как язык Ада.
Хотя оба генерят чудовищный код... Подозреваю, можно гораздо лучше, даже не кросс, а прямо на платформе.
Насчёт плавучки, она полезна. Но для определённого круга задач (Фортран их решал). От того, что есть многоядерные FPU, Векторовская плавучка хуже не стала. Это-как с 12м айфоном, или какой там был предыдущий. Ну и потом, AMD выпускал сопроцессоры. Можно подумать об HDL архитектуре с таким.
Все наши задачи и достижения вообще с практической точки зрения не имеют смысла. Эзотерика, но нам ведь нравится :)
Ну да, понятно. У меня похожее, но чуть-чуть рядом. Интересно чтобы был Бейсик c REPL, а не компилятор. Пусть он будет похож на 2.5, но мне норм, если там какие-то эзотерические параметры у оператора SCREEN отвалятся. Я бы даже может наоборот, замутил какой-нибудь SCREEN эзотеричней всех, что уже были. С другой стороны вот эту сатанинскую муть с отсутствием пробелов хочется сохранить, а то это уже не совсем Бейсик получается.
Что до плавучки -- дело не в том, что она стала хуже, а в том, что считать чего-нибудь на Векторе вряд ли кто станет. Поэтому ставить себе творческий блок в виде недостижимой плавучки по-моему нелепо.
С другой стороны вот эту сатанинскую муть с отсутствием пробелов хочется сохранить
В бейсике 5.x микрософт изменил синтаксические требования и пробелы стали обязательны. В BASCOM есть параметр, который позволяет компилировать по новым или "старым" правилам.
metamorpho
12.04.2023, 11:52
Пламенное обсуждение вариантов Бейсика, разбудило и во мне фантазии на эту тему :)
Если описывать какой нужен новый Бейсик, то мне думается так:
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 точек в две плоскости и компилятор включает в скомпилированный код только этот вариант вывода спрайта.
Ещё я бы включил оператор скроллинга указанной области экрана, программу голосового робото-чтения букв и .... другие хотелки-модули :)
Допустим из математических операторов мне нужен только sin() и соs(), а остальные математические функции
(тангенс, арктангенс, логариф, возведение в степень и т.д.) мне не нужны, поэтому при компиляции подключается код
только этих двух нужных мне функций и всё.
По-моему Бейсик на ДВК-1 задавал в начале разные неудобные вопросы типа "НУЖНЫ ЛИ ВАМ РАСШИРЕННЫЕ ФУНКЦИИ?".
Если нам совсем не нужны строковые функции, то и не нужно их подключать.
А работать со строками он совсем не умел. Ты не ошибся с выбором платформы? =)))
Думаю, в твоём вопросе есть и неявный ответ: все хотят не просто компилятор какого-то абстрактного языка бейсик, а компилятор именно для Векторовского BASIC 2.5, что бы он из себя не представлял исторически, и откуда бы не произрастали его корни. Идея, как я понимаю такая: ты ему скармливаешь BAS или CAS файл, а на выхлопе - COM или даже монолитный ROM. Иначе отчего в этой теме про BASIC 2.5 столько постов...это "родные валенки", все их так или иначе носили. Вполне нормальное желание, хотя за всех говорить... просто мне так кажется.
Привет всем...
Ну я - примерно так и хотел...
Компилятор для Вектор Basic' a v2.5...
Открываешь - .bas, .cas - на выходе .com, .rom...
Как то - так...
Бейсик на ДВК-1 задавал в начале разные неудобные вопросы типа "НУЖНЫ ЛИ ВАМ РАСШИРЕННЫЕ ФУНКЦИИ?"
Некоторые версии микрософтовского тоже задавали подобные вопросы, тогда это было актуально.
При ковырянии бейсика выявляются некоторые вещи, которые мне кажутся интересными:
1. Реализация LINE в 2.5 использует однобайтный Y и двухбайтный X. Причем рисование линии не менялось с 1.3 (в Сигнале аналогично). И везде эта линия в паре с рисованием точки 0-255,0-255. Думаю линию позаимствовали где-нибудь.
2. Штатный POKE все же может нагадить в бейсик. POKE&FFFF, - первое значение попадет в FFFF, а следующие в 0000, 0001 и т.д. Глубина повреждений ограничивается длиной строки бейсика.
- - - Добавлено - - -
Еще мелкий момент. POKE и PEEK могут менять и смотреть не только знакогенератор и несколько следующих ячеек, но и почти все 3 буфера нот. Как это можно использовать - теоретически можно играть музыку без PLAY и символьных переменных, напрямую POKE в буфер.
metamorpho
12.04.2023, 14:52
По-моему Бейсик на ДВК-1 задавал в начале разные неудобные вопросы типа "НУЖНЫ ЛИ ВАМ РАСШИРЕННЫЕ ФУНКЦИИ?".
А работать со строками он совсем не умел. Ты не ошибся с выбором платформы? =)))
Непонял мысль про "ошибся с выбором платформы". Подозреваю я что-то недопонимаю в компиляции.
Понимание и обработка компилятором строковых переменных и констант входит в основоное ядро кода - и из него ничего
отключить нельзя. А вот строковые функции, о которых я написал, это имеется ввиду функция MID, RIGHT, STR, LEFT и
др. - вот эти функции подключаются только если они нужны.
Мой компилятор-чудо-Бейсик не будет задавать вопросов как на ДВК-1 :)
Конечно возможно я не совсем понимаю внутренности процесса компиляции, но вот как в общих чертах мне
представляется этот процесс на реальном Векторе:
- набираем и записываем в файл код программы как в обычном Бейсике (здесь всё происходит в текстовом редакторе с
некоторыми удобными настройками и подсветкой операторов и т.п.)
- далее запускаем с диска компилятор, который анализирует наш код. Компилятор выявляет все операторы и функции,
которые использует наша программа. Далее компилятор загружает с диска нужные модули (код отдельных функций и
операторов, либо другой вариант - по очереди загружает соответсвующие библиотеки - например библиотека строковых
функций или библиотека работы с графикой - и уже в библиотеке находит нужный код и вставляет его в память или в
темп-файл) и в итоге компилятор собирает все модули, которые используются в нашей программе. Далее в программу
вставляются адреса вызовов функций (с входными и выходными параметрами если нужно).
- далее формируется выходной файл ROM или COM (а ещё можно сделать фишку EXE файл, чтобы запускалось на PC -
тогда будет ретро игра сразу на двух платформах - со всеми пользами и интересностями)
Про выбор платформы была шутка. Бейсик на ДВК-1 был хтоническим спавном какой-то одной из древнейших версий Бейсика, которая не далеко ушла от калькулятора.
Что до остального, все это, включая компиляцию в x86, ACK уже предположительно (*) умеет. Отличие только в каких-то деталях синтаксиса и в том, что для Вектора нужно сделать библиотеку. Можно приделать свою в нужном объеме.
*) Предположительно, потому что что-то существенное я им компилировал и запускал только на языке Си. Но пробную программу на Бейсике типа Хелло вродл тоже собрал и работает.
**) Повторюсь, что в случае кросс-компиляции мне остается непонятным выбор языка. Зачем истязать себя Бейсиком, если при этом не сохраняется его основная ламповая фича -- спонтанность и интерактивность? Если сбросить с себя оковы бейсика, открывается путь еще к z88dk.
Функция INT() для меня загадка:
=>
PRINTINT(1.5E33)
1.5E+33
=>
PRINTINT(5.7)
5
=>
PRINTINT(-5.7)
-6
С обычными числами он ведет себя как floor(). Странно для отрицательных чисел, но работает как обещано, что ж поделать. А если число с порядком, то типа сам дурак? Как быть?
Функция INT() для меня загадка:
=>
PRINTINT(1.5E33)
1.5E+33
=>
PRINTINT(5.7)
5
=>
PRINTINT(-5.7)
-6
С обычными числами он ведет себя как floor(). Странно для отрицательных чисел, но работает как обещано, что ж поделать. А если число с порядком, то типа сам дурак? Как быть?
а что не так? 1.5х10^33 это же целое число.
а что не так? 1.5х10^33 это же целое число.
Да, так все и объясняется. Просто я когда думаю "целое", мне представляется целое, которое помещается в переменную целого типа. Которого кроме всего прочего в этом Бейсике и нет.
Еще поускорял где смог, перечень оптимизаций в readme
- - - Добавлено - - -
Забыл в начале readme исправить номер на 2.71, менять архив из-за такой мелочи не буду, там дальше все правильно.
Слова про z88dk я пожалуй беру обратно. Компилятор глючный как чорт.
Да, глюков там полно, но если не портировать готовые программы, а писать с нуля, то глюки можно обходить. Это неудобно и неприятно, но скорость откомпилированных программ сравнительно хорошая и даже есть пара библиотек плавучки. SDCC лучше, но ему нужен z80 и искаропки он не знает про вектор (что решаемо).
- - - Добавлено - - -
Прошу прощения за повторение, вроде уже писал, но тут наверно к месту. Когда портировал jpeg, то В КАЖДОМ из 3х попробованных компиляторов обнаружились баги, причем разные. Самый правильный - zpu8080, там был виноват я сам, ошибся в библиотеке. Замечательно, но медленно. Ошибку в SDCC я обошел, а через некоторое время ее исправили, супер, если бы не z80. И только z88dk никто на тему бага не думал править, скорее всего он до сих пор есть. C другой стороны, когда писал в z88dk маленькие тестовые программки, то все было нормально. А вот когда пробовал рейкастер с плавучкой и текстурами, вот там опять полезли иррациональные глюки, которые более-менее решились только когда стала доступна другая (микрософтовская) библиотека плавучки. С "любительскими" компиляторами для не самых популярных ретроплатформ все непросто.
если не портировать готовые программы, а писать с нуля, то глюки можно обходить
Это может быть так, когда глюки известные и стабильные. Тогда их можно принять как ограничения и с этим жить. Это не только для 8080 так бывает. Но когда один и тот же код в зависимости от вставленного где-то посередине printf(), или выбора опций, работает совершенно по разному, это получается совершенно невозможная путаница. Главное, что ты никогда не знаешь, исправят это в завтрашней версии, или испортят еще хуже. Я бы и рад помочь разработчикам хотя бы хорошим багрепортом, но глюки настолько эзотерические, что я не могу даже привести хороших тестовых примеров. Хотя вообще z88dk ценная вещь и наверняка когда-нибудь глючность его станет незначительной.
Кстати о zpu8080, игру в стиле ANTIGRAV на нем наверное можно забацать и пошустрее, чем получилось на Бейсике. Но процесс разработки боюсь не для всех =)
Главное, что ты никогда не знаешь, исправят это в завтрашней версии, или испортят еще хуже.
Вот того, что в z88dk что-то исправят я бы сильно не опасался, там, насколько могу судить, направленность на добавление фич (больше библиотек, больше платформ), а не на их отладку. Хотя я некоторое время не слежу, может ситуация поменялась.
У zpu8080 сильные стороны: безглючность (особенно если сравнить с z88dk), современность (про z88dk молчу, SDCC получше, но GCC круче) и (надо же и себя похвалить) быстрая целочисленная арифметика. Основные минусы: невысокая скорость результирующих программ и сложность организации процесса разработки для непрограммистов типа меня. Есть еще нереализованная уникальная фича - теоретически можно переделать интерпретатор zpu для работы (например с квазом) с адресным пространством >64 Кб. Скорость это снизит, зато большие программы. Для игр все же zpu8080 мне кажется не очень пригоден, хотя может для текстовых.
Хотя я некоторое время не слежу, может ситуация поменялась.
Одна из ошибок, которая чуть было не заставила меня выкинуть z88dk в окно раньше, чем я увидел первый результат, была исправлена четыре дня назад.
Скачал последнюю версию - чуда не случилось, исходный неправленый вариант библиотеки picojpeg не переваривает. Зато правленый вариант текущий z88dk делает на 917 байт короче и на 16% быстрее (это вариант без ассемблерных вставок)! Прогресс за 2 года ощутимый, еще бы работу с арифметикой доработали.
- - - Добавлено - - -
Извините, заканчиваю с оффтопом, но авторам компиляторов на заметку - как надо использовать возможности 8085. Один и тот же декодировщик jpeg c Леной, чисто Сишная версия без ассемблерных вставок (z88dk 20230414, sccz80):
8080 (29321 байт) 48 секунд
8085 (26962 байта) 34 секунды
z80 (28952 байта) 40 секунд
Это все с векторовским торможением, но абсолютные цифры не так важны, интересны соотношения.
Вчера ошибся в размере версии 8080, исправил. Дополнение: попробовал вариант с ассемблерными вставками - в отличие от чисто Сишного он почти не ускорился, всего на 0.1 секунды, зато размер меньше на 503 байта. Надо смотреть библиотеки, они наверно оптимизировали арифметику, в первую очередь умножение, а в версии с ассемлерными вставками вся критичная арифметика в них.
В MSX-BASIC имя переменной это два байта. Тип хранится отдельно и по совместительству является размером. По умолчанию A, A%, A$, A() -- разные переменные, потому что имеют разные типы. Если вызвать DEFINTA, A становится эквивалентом A%.
Можно без потерь сделать имена переменных трехбуквенными, если закодировать их в RADIX-50: в те же два байта помещаются 3 буквы и цифры. Подчеркивание не в стандарте RADIX50, но можно использовать вопросик или точку. Преобразования не самые удобные, правда.
В BASIC 2.5 я не залезал глубоко, но по-моему дела обстоят немного иначе -- мне показалось, что признак строковости это старший битик в имени переменной ($00,$41 = A, $80,$41 = A$, $C1,$41 = AA$). Так конечно RADIX50 не вклячишь.
Типы переменных в 2.5 Евгений Филиппов описал в Vector-User 10.
MSX Basic при большом желании можно портануть с ПК8002, но есть неприятные дополнительные требования и ограничения. Из экранных режимов скорее всего получится эмулировать текстовые. Спрайтов не будет. Если с квазом Баркаря, то можно попробовать сделать SCREEN 2. Толку без спрайтов наверно в этом нет. Для любителей расширенной математики с диском есть MBASIC и комания, для магнитофонщиков - Бейсик-Корвет.
Понимаю что я немного не в теме, всё же осмелюсь предложить посмотреть на
MSX Basic Compiler
https://github.com/leonhad/msx-bcc
-- подозреваю, что в нём можно заменить codegen часть + допилить рантайм -- и получить тем самым тот же язык для Вектора.
На мой поверхностный взгляд это близко по сложности к перепиливанию спековского Boriel - готового рантайма для вектора нет и z80.
Уголок любителей истории. Оказалось, что circle в 2.5 и драйверах устройств адаптирован с Ириши. Процедура быстрее корветовской, но довольно громоздкая. У Вектора сравнительно быстрый circle и неторопливая заливка, у Корвета наоборот.
У Вектора сравнительно быстрый circle и неторопливая заливка
По-моему ты оптимизировал заливку на Векторе, или это было только в одной из версий для альтернативных процессоров?
Заливку оптимизировал (отсюда (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=990233&viewfull=1#post990233) и далее), но отдельно, а в бейсик не встраивал (там места не хватает).
- - - Добавлено - - -
В процитированном фрагменте "У Вектора" надо понимать в контексте сообщения, т.е. "в 2.5 и драйверах устройств".
metamorpho
19.04.2023, 00:25
Эта дэмка нарисовалась в ходе продолжения экспериментов с палитрой.
В данном случае целью было показать что можно сделать на Бейсике на Вектор-06Ц.
Всё что вы видите это использование программируемой палитры Вектора
и написано полностью на Бейсике (без использования машинных кодов).
В целом данный эксперимент удался, хотя первоначальный "сценарий" картинки был поинтересней,
но его не удалось реализовать. Глюк с мельницей (в правом верхнем углу) оставил - мне показалось
это подходящая нотка для дэмки в тему дождя (молния в дали освещает мельницу).
Картинку собирал с помощью PaintNet + конвертор в дату + Pretty 8080 Assembler c новой возможностью сохранять в TAPE (спасибо svofski).
Тестировал на Бейсике 2.71 (спасибо ivagor).
Порядок загрузки.
1. Грузим Бейсик
2. Грузим DINOSINT.cas и запускаем RUN
3. Программа запросит файл - грузим PATHDINO.cas
Добавил ещё две версии дэмки.
Архив DINO2 - прибавил музыку (не свою) и отблеск молнии на "картине".
Архив DINO3 - прибавил музыку (не свою) и отблеск молнии на "картине" + бордюр.
https://www.youtube.com/watch?v=YE8GAIis7HM
Здорово! И радует, что хорошо работает в классическом 2.5
metamorpho
19.04.2023, 12:02
Появилась добавка.... :)
https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177002&viewfull=1#post1177002
metamorpho, с музыкой лучше (в DINO3 на мой вкус перебор спецэффекта).
А я довел бейсик до исчерпания свободного места, осталось байт 20. Главная фишка 2.72 - более быстрый PAINT, в котором налево строку закрашивает пиксельно-байтово. Ситуация примерно как с триммером, когда побрил половину лица и сел аккумулятор, направо осталась пиксельная заливка. Тем не менее в 2.72 PAINT в среднем на 36% быстрее чем в 2.5, это заметно. Дальше уже придется или оставить как есть или начать убирать ненужные элементы бейсика.
- - - Добавлено - - -
Добавлю, что прогон Рекламы в 2.72 быстрее чем в пзушном бейсике 6128 и бейсике 2.60ВМ1.
Upd 22.04.2023: Резко разогнал PAINT, теперь он почти в шесть с половиной раз быстрее 2.5.
Остальные минусы и плюсы:
1. Убрал быстрый набор по УС+СС.
2. CIRLCE медленнее 2.72 на 0.2-0.5% (но быстрее 2.5 примерно на 9.5%).
3. В 2.72 заметил ошибку PAINT, которая могла проявляться при заполнении экрана с заворотом за край, поэтому 2.72 убрал, в 2.80 ошибка исправлена.
4. За счет пунктов 1 и 2 в упакованном виде бейсик стал на 226 байт короче.
parallelno
19.04.2023, 21:34
Клёвый эксперимент! Отдельное спасибо за музычку и видео!
Еще пара слов про paint в 2.72. Из-за особенностей процедуры в основном используется заливка налево и перевод правой заливки на байты, как оказалось, дает очень маленькую прибавку скорости. На вопрос - "а почему тогда скорость намного меньше чем у процедур в ветке Программирование на ассемблере?" ответ такой - в paint для определения цвета используется пусть и разогнанная, но пиксельная процедура определения цвета, а в самых быстрых paintах - байтовое определение цвета. То, что в 20 оставшихся в 2.72 байт не влезает правая байтовая заливка - не критично, но, к сожалению, в 20 байт не влезут и процедуры байтового определения цвета.
В саге про paint не хватало оценки влияния байтовых проверок цвета на скорость. В качестве теста простая программка
1 CLS
2 COLOR15
3 CIRCLE128,128,127
4 PAINT128,128,10,15
5 STOP
Время выполнения от RUN до STOP:
1) 2.5 - 29.3 секунды
2) 2.72 - 18.7 секунды
3) 1 из 5 - 14.4 секунды
4) 2 из 5 - 12 секунд
5) 3 из 5 - 9.6 секунды
Под номерами 3-5 это 2.72 с удаленным быстрым набором по УС+СС и разогнанным (не до упора) paint. Не до упора, т.к. опять закончилось свободное место. Там 5 веток, в которых стоит использовать байтовые проверки, а мне хватило места на 3 из 5. Очевидный вывод, что довольно быстрый paint в векторовском бейсике возможен, было бы где его разместить.
Upd 22.04.2023: Расчистил место и довставлял байтовые проверки:
6) 4 из 5 - 7.1 секунды
7) 2.80 (5 из 5) - 4.5 секунды
Это не абсолютный рекорд для вектора, процедуры из Программирования на ассемблере быстрее. В бейсике компромисс для сокращения размера и совместимости - внутри процедуры используются координаты, а в самых быстрых вариантах полный переход на адреса+маски. Но такой переход кроме увеличения размера процедуры требует еще и больше стека, пришлось отказаться.
2.72 с удаленным быстрым набором по УС+СС
А по АР-2 быстрый набор сохранится? если да, то я за то чтобы пожертвовать (я УС+СС никогда не пользовался).
по АР-2 быстрый набор сохранится?
Да, сохранился. "Новый" по УС+СС - 335 байт, "старый" по АР2 - 79 байт. Есть еще резервы - таблицу синусов для дуг (256 байт) в CIRCLE можно сократить вдвое, а промежуточные значения вычислять линейной интерполяцией. Дальше сложнее. Можно убрать принтерные процедуры, выигрыш не оценивал. Ну и есть две таблицы по 256 байт для вычисления адресов и масок точек. Их в крайнем случае можно сократить (в basic48k сократил таблицу масок до 8 байт), но это приведет к замедлению графики. Вопрос в приоритетах, что важно, а что не очень.
Improver
21.04.2023, 11:24
"Новый" по УС+СС - 335 байт, "старый" по АР2 - 79 байт.По поводу быстрых наборов: активно пользовался и тем, и другим, но чаще через УС+СС, и заметил ещё с версии 2.50, что команды там выводятся немного по-разному, например по УС+СС+<запятая> выводит CLOAD с пробелом и кавычками в конце, а по АР2,[ -- без кавычек и пробела. Может если как-то объединить оба этих набора, то это немного сократит код?
"Классический" быстрый набор (АР2+), унаследованный от РКшного бейсика, выдает операторы и функции из таблицы токенизатора. А "новый" (УС+СС) пользуется собственной отдельной таблицей, куда в принципе можно ввести что угодно. В примере с cload его можно убрать из УС+СС, но не из АР2 (если запретить выдачу cload в АР2, то это не сократит, а увеличит соответствующую процедуру). Оба быстрых набора сегодня лично мне кажутся не очень нужными, особенно учитывая наличие современных утилит конверсии txt<->bas/cas, но я догадываюсь, что не все со мной согласны, поэтому в 2.55-2.72 я их не трогал. Если уж убирать, то ради какой-нибудь очень нужной штуки.
metamorpho
21.04.2023, 12:58
Есть идея усовершенствовать ANTIGRAV - ускорить человечика и взлёт ракеты, а также уровень при загрузке не рисовать постепенно, а быстро загрузить через BLOAD.
1. Вывод человечика идёт через POKE. По совету ivagor-а я уже заменил десятичные данные на шестнадцатеричные - немного ускорения уже есть.
И осталась идея в команде POKE отключить проверку адреса куда заносятся данные - это будет ещё + в ускорение.
Как можно это реализовать через ассемблерный код вставленый в тело моей программы (подобно тому как вставлен альтернативный опрос клавиатуры) ?
2. Ускорить вывод ракеты - он происходить через PUT. ivagor написал что PUT можно ускорить при ширине фрагмента кратной 8 точек.
Если нежелательно изменить это в Бейсике (для сохранения совместимости), то можно ли это реализовать через ассемблерный код вставленый в тело моей программы,
чтобы это было особенностью только моей программы, а не изменения Бейсика (это для сохранения совместимости) ?
Также есть проблема что PUT неправильно выводит данные, если при аппаратном скроллинге есть переход через границу адреса FF на 00 (в столбике).
Можно ли как-то это устранить ?
3. Загрузка уровня через BLOAD - можно реализовать уже сейчас без видоизменения Бейсика.
Таким образом можно сделать несколько различных уровней.
И так можно очень сильно сэкономить памяти т.к. всё что рисовалось через операторы Бейсика,
будет уже нарисовано и в готовом виде загружено в экранную-память (8000-FFFF).
При этом графика уровня уже может быть более разнообразной т.к. она не занимает память, а грузится сразу на своё место.
А ещё можно данные уровня тоже грузить через BLOAD (заодно с картинкой уровня) например с 7F00-FFFF.
Таким образом нет необходимости хранить все уровни в коде программы - это тоже сэкономит память.
в команде POKE отключить проверку адреса куда заносятся данные - это будет ещё + в ускорение.
Это очень-очень маленькое ускорение, могу гарантировать, что заметно не будет.
PUT можно ускорить при ширине фрагмента кратной 8 точек.
Да, это сравнительно простой вариант. В сложном, если очень заморочиться, можно сделать быстрый PUT с любыми размерами, но при некоторых неудобных значениях ширины придется сочетать байтовый и пиксельный вывод. На руку играет ошибка в описании бейсика, где приведена формула размера массива для GET, дающая во многих случаях завышенные значения. Возможно это для компенсации неаккуратного get, который иногда использует лишние байты. Проблема с быстрыми GET и PUT в том, что если не убрать все "лишнее" из бейсика, то они не поместятся. Вариант с кратностью 8 точкам проще, но менее интересен, т.к. во многих игрушках ширина фрагментов не подходит и они не ускорятся.
Также есть проблема что PUT неправильно выводит данные, если при аппаратном скроллинге есть переход через границу адреса FF на 00 (в столбике).
Можно ли как-то это устранить ?
Можно переделать обрезание на заворот, но это создает потенциальную несовместимость с имеющимися программами, вдруг есть игрушки, которые используют эту фичу.
Лучше использовать ассемблерную процедуру.
- - - Добавлено - - -
И так можно очень сильно сэкономить памяти т.к. всё что рисовалось через операторы Бейсика,
будет уже нарисовано и в готовом виде загружено в экранную-память (8000-FFFF).
Обращу внимание, что загрузка 32 килобайт в формате монитора на стандартной скорости - это в районе 200 секунд. Сейчас в ANTIGRAV от RUN до завершения построения уровня проходит 164 (2.5) или 134 (2.71-2.72) секунды. Но экономия памяти для программы на бейсике при использовании bload несомненная.
Improver
21.04.2023, 14:01
В примере с cload его можно убрать из УС+ССНе, я имел в виду не сокращать как-то количество команд, а сделать для обоих вариантов один общий метод вывода команды из одной таблицы, отдельной или токенизатора.
Оба быстрых набора сегодня лично мне кажутся не очень нужнымиМожет и так, если не писать программы непосредственно в Бейсике. :)
для обоих вариантов один общий метод вывода команды из одной таблицы, отдельной или токенизатора.
Технически можно убрать отдельную таблицу для УС+СС и задублировать выдачу по AР2+ и УС+СС+, но мне это кажется излишним.
Заменил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177056&viewfull=1#post1177056) 2.72 на 2.80. Дополнил результаты (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177121&viewfull=1#post1177121) тестирования PAINT.
Improver
22.04.2023, 15:15
1. Убрал быстрый набор по УС+СС.Ну это, может быть, зря, я предлагал объединить их с АР2, а не сократить... Можно как-то вернуть хотя бы основные команды, RUN, LIST, NEW, EDIT, CLOAD/CSAVE и BLOAD/BSAVE?
Полнофункциональный 2.71 остался (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176649&viewfull=1#post1176649), я его не убирал. А 2.80 - это для любителей быстрого paint.
Есть справка (http://archive.radio.ru/web/1988/08/035/) по комбинациям АР2+ РКшного микрона, она в значительной степени подходит и для векторовского бейсика.
EDIT - АР2+1
CLOAD - АР2+[
CSAVE - АР2+\
LIST - АР2+Y
RUN - АР2+J
Improver
23.04.2023, 09:43
Есть справка (http://archive.radio.ru/web/1988/08/035/) по комбинациям АР2+ РКшного микрона,Комбинации по АР2 перечислены в конце документации Векторовского бейсика (http://tenroom.ru/scalar/ware/698/index.html), тут проблем нет, просто по УС+СС легче запоминаются, например, УС+СС+R == RUN, УС+СС+L == LIST и т.п., я их до сих пор помню. :)
- - - Добавлено - - -
Хотя, если это только мне нужно -- забейте, пусть лучше будет paint быстрее.
Чисто теоретически есть вариант с залезанием бейсика в кваз Баркаря. Если ориентироваться на сохранение скорости графики, то оставляем экран все время включенным, а в область E000-FFFF кваза выносим что-то некритичное для быстродействия или редкое (например быстрый набор, принтер, возможно высшую математику) и щелкаем страницей по мере необходимости. Ограничение - программе нельзя делать HIMEM выше E000, скорее всего таких программ (по крайней мере распространенных) и не было. Но это уже принципиальный шаг от голого вектора к использованию кваза, всерьез на эту тему не думал.
У меня ложные воспоминания, что вроде я видел краткое описание дискового бейсика для РДС. Найти не могу, кто-нибудь помнит такое описание? Возможно я залезал внутрь, но базы иды тоже нет, максимум смотрел в отладчике.
Improver
25.04.2023, 19:08
дискового бейсика для РДСА разве был такой?
Вот тут ничего похожего нет? https://github.com/Vitaly-Vyunov/vector
basic25d.com 17792 байта. Руководства пользователя и программиста я смотрел, про бейсик там не заметил. Отстутствие описания в данном случае не проблема, но придется потратить дополнительное время.
- - - Добавлено - - -
Память была не ложной, нашел описание.
Глянул дисковый бейсик Виталия Вьюнова для РДС. Он получен патчением оригинального 2.5, что позволяет сравнительно просто вычленить изменения для работы с диском в РДС. На этом пока отложил в сторону, т.к. сильной потребности в дисковых "новых" бейсиках нет и мне эта тема кажется скучной. Еще отмечу, что basic25d несовместим с z80, как и многие его собратья. С 8085 тоже несовместим, но на 6128 не работала РДС в связи с отсутствием сигнала СТЕК и квазидиска.
Для удовольствия в очередной раз покопался в математике. Крупные оптимизации сделаны ранее, но удалось чуть-чуть ускорить и при этом немного сократить.
Для смотревших дизассемблер альтаирского бейсика не будет новостью, что мантисса - 3 байта, но в части вычислений добавляют 4й младший байт, который потом используется для округления. В принципе можно операции с этими "лишними" байтами поудалять и округления убрать, для игрушек скорее всего точности хватило бы. Но на такую несовместимость у меня рука не поднимается, это надо было в конце 80х - начале 90х делать альтернативный заточенный под игрушки бейсик.
Может быть можно каким-нибудь странным образом сделать поддержку цвета в Бейсике-Корвет?
Сугубо теоретические капитанские варианты:
1. Без кваза - 4 цвета с разрешением 256x256.
2. С квазом Баркаря (или для 6128) - 4 цвета с разрешением 512x256 или 16 цветов 256x256.
Основная проблема в том, что малой кровью это может сделать тот, у кого уже есть дизассемблер корветовского бейсика (у меня нет). Его можно дизассемблировать, есть забугорная книжка (где-то здесь я приводил ссылку) с дизассмом примерного прототипа, но это надо захотеть.
Эх, все непросто. Когда-нибудь я дозрею испечь свой Бейсик.
Будет очень здорово, если дозреешь.
Ускорил умножение, некоторые околоматематические процедурки и чуть-чуть FOR..NEXT/RETURN. Без упаковки сократил пару байт, а упакованный короче на 18. На глаз практически незаметно, но преодолен важный для меня рубеж - 2.81 обогнал пзушный бейсик 6128 во всех используемых мною тестах, математика держалась до последнего. Т.е. даже там, где эффект оптимизации минимален, он превысил разницу между 8080 и 8085 с учетом векторовского торможения.
Upd 04.05.2023. Заметно ускорил эллипсы и LINE BF/BS, немного быстрее стали paint, дуги, круги, вывод символов и деление, еще несколько мелких оптимизаций. Доработал PAUSE - теперь дает практически одинаковую задержку на всех типах процессоров. При рисовании "обратных" (от большего к меньшему) дуг использовалась стековая процедура обмена слов временно запрещавшая прерывания. На мой взгляд это было совершенно излишне, переделал без стека и без запрета прерываний. Эллипсы отмечу особо - они на 35-40% быстрее 2.5 или на 30-35% относительно 2.81.
Упакованный 2.82 на 49(!) байт короче 2.81 за счет оптимизации и бейсика и инициализатора распаковки. Если не блюсти размер, то можно еще ускорить умножение, деление и некоторые другие вещи, но ускорение будет не таким уж большим, решил лучше соблюдать культуру веса.
Upd 07.05.2023.
Исправил ошибку в SCREEN4 (скорость обмена с магнитофоном) - было небольшое отклонение от 2.5. В самооправдание скажу, что я не один такой ошибавшийся, в дизассемблере Филиппова и в бейсике 6128 в SCREEN4 тоже ссылки вместо констант, но у себя я теперь исправил. Наверное многие знают, но на всякий случай отмечу - в описании бейсика ошибка, диапазон аргумента SCREEN4 от 40 до 255, не до 460.
В 2.82 слегка поломал эллипсы очень сильно сплюснутые по горизонтали. Не то чтобы смертельно, но результат отличался от 2.5, исправил. Скорость не уменьшилась, даже немного увеличилась.
Освободил сравнительно много места и смог вернуть обратно быстрый набор по УС+СС+буква. К сожалению пришлось убрать восьмеричные числа (их не было в оригинальном 2.5, появились в 2.61), надеюсь svofski не будет меня сильно ругать. В связи с возвращением быстрого набора бейсик опять разбух, но не до тех значений, которые были на момент его удаления (с тех пор многое оптимизировал по размеру): упакованный 2.72 - 12958 байт, 2.83 - 12855 байт. Интересный факт - salvador сжал на байт сильнее, чем zx0.
Полностью переписал деление в плавучке, стало быстрее.
Upd2 07.05.2023. В 2.84 вернул восьмеричные, доработал поддержку шестнадцатеричных и восьмеричных.
Upd 11.05.2023: Переделал в компактную форму таблицу перекодирования в QWERTY (SCREEN5,1). Теперь POKE и PEEK не могут обращаться к этой таблице (диапазон 640-767). Вместе с несколькими другими оптимизациями освободилось место, что позволило ввести и новые и ранее отброшенные (из-за экономии памяти) улучшения:
1. Оптимизированы PUT и GET. PUT на 17% быстрее 2.84 и на 36% быстрее 2.5.
2. Немного ускорены: проверка следующего символа, умножение, сложение/вычитание и обработчик прерываний.
В упакованном виде 2.85 на 34 байта короче 2.84.
Upd 19.05.2023:
1. Исправлена ошибка в оцифровщике номеров строк (появилась в 2.70) - в некоторых случаях оцифровщик мог пропустить и неправильно перевести в число слишком большие номера.
2. Околоматематические микроускорения: сравнение, оцифровка номеров строк.
Upd 20.05.2023:
46. Исправил (ошибка появилась в 2.86) и ускорил ON.
47. Добавил в инициализатор распаковщика очистку памяти программы.
Upd 26.05.2023:
48. Ускорены вывод символов, LINE BF/BS.
49. Немного ускорены: сравнение чисел, обработчик прерываний, изменение цвета рисования точки.
50. Исправлена ошибка разрешения доступа к плоскостям в PAINT при использовании знчений цвета заливки и бордюра с предыдущего вызова PAINT.
Upd 08.06.2023:
51. Оцифровщик номеров строк переведен обратно на "стандарт Microsoft" 0-65529 и ускорен.
52. Вернул "старый" (новый был с 2.57) вариант обработки токенов при вводе символьных переменных в INPUT. Исправлено сообщение об ошибке при вводе неправильной строки в INPUT.
53. Чуть ускорен пропуск конца строки.
Обновил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728) бейсик.
плавучку уже выцепили (синтаксис z80). В принципе и в дизассембере 2.5 (синтаксис 8080), который я выкладывал примерно оно, но тут причесано и с комментариями.
Глянул DIV - комментарии с ошибками! Код правильный, но с комментариями оттуда (https://github.com/z88dk/z88dk/blob/master/libsrc/math/mbf32/z80/math_mbf32.asm) надо осторожно, стоит перепроверять.
Добавил 2.82 в результаты пары тестов:
1. Старт ANTIGRAV (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034)
2. Бессмысленный (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938) (пустой цикл)
Опять обновление (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728), хочу перед праздником исправить найденные недостатки.
Еще один кросскомпилятор (https://github.com/spotlessmind1975/ugbasic) бейсика (и тут (https://spotlessmind1975.itch.io/ugbasic-ide/purchase)). Для вектора он компилировать не будет, но и boriel не будет, так что вполне подходит в компанию.
Уже писал про недокументированное залезание POKE и PEEK в музыкальный буфер, но как оказалось это еще не все. В диапазоне 640-767 они лезут в таблицу перекодирования клавиатуры в QWERTY (включается по SCREEN5,1). В программах такого не встречал, это кому-нибудь нужно? Вопрос связан с тем, что таблицу перекодирования можно сократить/оптимизировать и освободить немного места, но тогда надо запрещать POKE и PEEK туда.
Финальная полнофункциональная версия (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728), свободное место и резервы закончились. Развивать дальше можно при удалении (или оптимизации по размеру с проигрышем в скорости) тех или иных элементов бейсика. Добавил 2.85 к результатам вышеупомянутых тестов, но в них разница небольшая.
Закрыл еще один детский гештальт связанный с векторовским бейсиком - быстрые PUT и GET. Это не замена полнофункционального 2.85 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728), это ответвление, т.к. в 2.90 пришлось выпилить: быстрый набор (УС+СС и АР2), SCREEN5 (JCUKEN/QWERTY).
При ширине фрагмента <8 точек работает пиксельный вариант (скорость между 2.84 и 2.85).
При ширине фрагмента >=8 точек работает байтово-пиксельный вариант (в лучшем случае PUT быстрее 2.85 почти в 2 раза, быстрее 2.5 почти в 3 раза; GET примерно аналогично, не стал измерять).
Если добавить ограничений (чтобы ширина была четная или даже кратна 8 точкам), то можно было бы еще ускорить, но есть две причины, почему не стал:
1. Хотелось получить эффект для большинства существующих программ, а там нечетная ширина для GET/PUT встречается.
2. Свободного места для альтернативных вариантов совершенно не осталось.
Пара слов про особенности PUT.
В описании PUT сказано, что аргументы X и Y в диапазоне 0-255. На самом деле они трактуются как двухбайтные знаковые. Отрицатаельные значения позволяют при необходимости постепенно выдвигать картинку слева и/или снизу. Это, кстати, позволяет эмулировать и заворот - делаем 2 PUT одной картинки, один вариант с положительными координатами, другой - с отрицательными (ну и надо их конечно совместить).
У пиксельного PUT есть побочный эффект - цвет последней "значащей" (не фоновой) точки после PUT становится текущим цветом рисования и вывода символов. Повторить такое поведение в байтово-пиксельном варианте во всех случаях к сожалению невозможно - это съело бы весь выигрыш в скорости, да и места нет. К счастью это не критично, попробовал несколько программ/игрушек - все нормально.
Upd 15.05.2023. Исправил GET и PUT (ошибки были в 2.90, в 2.85 все нормально), спасибо metamorpho за багрепорт. PUT немного ускорен.
Upd 18.05.2023. Заметно ускорен PUT (для ширины фрагмента >= 8 точек, особенно при четной ширине в режиме 2), немного ускорен GET (для ширины фрагмента >= 8 точек).
Upd 19.05.2023.
1. Исправлен GET для случая выхода за границу экрана (ошибка появилась в 2.92).
2. Исправлена ошибка в оцифровщике номеров строк (появилась в 2.70) - в некоторых случаях оцифровщик мог пропустить и неправильно перевести в число слишком большие номера.
3. Околоматематические микроускорения: сравнение, изменение знака, сложение, округление, оцифровка номеров строк.
Upd 20.05.2023.
1. Исправил (ошибка появилась в 2.93) и ускорил ON.
2. Добавил в инициализатор распаковщика очистку памяти программы.
3. Ускорены: сложение/вычитание, преобразование в целые (касается не только INT), помещение числа в стек.
Upd 26.05.2023.
54. Ускорены: вывод символов, LINE BF/BS.
55. Немного ускорены: сравнение чисел, оцифровка десятичных чисел, обработчик прерываний, изменение цвета рисования точки.
56. Исправлена ошибка разрешения доступа к плоскостям в PAINT при использовании значений цвета заливки и бордюра с предыдущего вызова PAINT.
Upd 27.05.2023. Заметно ускорена оцифровка десятичных чисел.
Upd 08.06.2023.
58. Оцифровщик номеров строк переведен обратно на "стандарт Microsoft" 0-65529 и ускорен.
59. Вернул "старый" (новый был с 2.57) вариант обработки токенов при вводе символьных переменных в INPUT. Исправлено сообщение об ошибке при вводе неправильной строки в INPUT.
60. Исправил (ошибка была в 2.95-2.96) и ускорил сравнение чисел.
61. Очень много оптимизаций: переходы, разбор имени и поиск переменных, математика, оцифровка чисел, массивы, обработка строк и некоторые другие вещи.
Upd 09.06.2023 - Исправлена (крайне редкая) ошибка поиска номера строки (появилась в 2.97).
metamorpho
13.05.2023, 22:20
.... быстрые PUT и GET....
Протестировал начальную версию ANTIGRAV (там через PUT вывод спрайта человечика) на Бейсике 2.90 - управление перестало работать, мои подозрения падают на baskey, видимо адреса опроса переехали на другие места.
На Бейсике 2.85 тест начальной версии ANTIGRAV (там через PUT вывод спрайта человечика) прошёл успешно - управление работает - скорость немного прибавилась и движение человечика выглядит более плавно.
ANTIGRAV я использую для тестирования, пробовал и в 2.85 и в 2.90 - выложенная на форум версия работает. Подход к обработке прерываний немного изменился от 2.84 к 2.85, а в 2.90 аналогично 2.85. Если найдутся ошибки - я готов исправить, но мне нужно воспроизвести ошибку, чтобы увидеть в чем там дело.
- - - Добавлено - - -
Чуть отклоняясь в сторону - пробовал в 2.85 (и 2.90) некоторые игрушки - на удивление ускорение в 2.85 (тем более в 2.90) иногда заметно даже невооруженным взглядом.
metamorpho
14.05.2023, 16:47
ANTIGRAV я использую для тестирования, пробовал и в 2.85 и в 2.90 - выложенная на форум версия работает. .........
Да ANTIGRAV работает и в 2.85 и в 2.90.
А вот этот экземпляр в 2.85 - работает, а в 2.90 - не работает. Не пойму почему, и вроде бы baskey одинаков с ANTIGRAV.
78874
metamorpho, спасибо за багрепорт! В байтовой части GET ошибка с учетом плоскостей (SCREEN2), завтра исправлю.
Improver
14.05.2023, 18:30
metamorpho, по поводу ANTIGRAV, хоть немного запоздало для предложений, но мне кажется, что если на рисовании уровня сначала закрасить весь экран "кирпичами", а потом при отрисовке просто пропускать места со стенами, то отрисовка будет быстрее.
metamorpho
14.05.2023, 19:20
metamorpho, по поводу ANTIGRAV, хоть немного запоздало для предложений, но мне кажется, что если на рисовании уровня сначала закрасить весь экран "кирпичами", а потом при отрисовке просто пропускать места со стенами, то отрисовка будет быстрее.
Improver, спасибо за хорошую идею. Да похоже это ускорит процесс рисования экрана. У меня есть идеи насчёт небольшого развития ANTIGRAV (используя быстрый PUT от ivagor), так что идея не опоздала.
Обновил быстропут до 2.91 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571)
Хочу обратить внимание, что ускорение PUT (и GET) нужно воспринимать в контексте конкретной программы.
Пара примеров:
1. PROVERKA, PUT человечека внизу у левой стены.
Время от PUT до PUT (клавиши не нажимаем):
2.5 - 400-443 тысячи тактов из них сам PUT 67500 тактов
2.85 - 297-337 тысяч тактов из них сам PUT 53500 тактов
2.91 - 276-316 тысяч тактов из них сам PUT 32000 тактов
Тут маленький одноплоскостной фрагмент 8x8 и вклад PUT в общее время сравнительно небольшой.
Замер времени пробегания от левой стены до правой стены:
2.5 - почти 31 секунда
2.891 - примерно 23.9 секунды
2.995 - примерно 11.3 секунды
2.996 - примерно 8.9 секунды
2. ANTIGRAV, взлет ракеты.
Время от PUT до PUT:
2.5 - 1590 тысяч тактов из них сам PUT 1239 тысяч тактов
2.85 - 1140 тысяч тактов из них сам PUT 838 тысяч тактов
2.91 - 710 тысяч тактов из них сам PUT 406 тысяч тактов
Время взлета ракеты:
2.5 - 63.2 секунды
2.891 - 45.13 секунды
2.995 - 18.03 секунды
2.996 - 16.46 секунды
metamorpho
15.05.2023, 18:10
Обновил быстропут .....Время от PUT до PUT:.....Время взлета ракеты:...
ivagor, спасибо за подробные данные тестовых исследований !!
Вершина развития быстропутгетия - 2.92 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571). Ускорение PUT при любых значениях ширины>=8, но наибольшее при четной ширине в самом популярном режиме 2. GET в основном ускорен при запрете части плоскостей, но и без этого немного быстрее. Ракета в ANTIGRAV теперь взлетает за 22.7 секунды, собственно PUT работает в данном случае в 4.6 раза быстрее, чем в 2.5. Отмечу еще одно преимущество ширины кратной 8 для 2.90-2.92 - в этом случае не только максимальная скорость, но и независимость скорости от содержания картинки (при пиксельном PUT его скорость зависит от числа изменений нефоновых цветов в строке).
В целом доволен, что получилось ускорить в несколько раз не только PAINT, но и GET/PUT.
Работа над ошибками (малокритичными).
Одна появилась в 2.70 - в некоторых случаях могли неправильно преобразовываться в число слишком большие номера строк (исправил в 2.86 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728) и 2.93 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571)). Для существующих программ это без разницы, но при разработке новых надо иметь правильно работающую проверку ошибок.
Вторую сделал в 2.92. Изменил порядок перемещения по плоскостям в GET и забыл изменить проверку на выход за пределы экрана (исправил в 2.93). До сих пор не видел программ, которые это используют, но вдруг кто-то захочет проверить бейсик на прочность.
Ускорил несколько околоматематических мелочей (в 2.93 больше, в 2.86 меньше, надеюсь меня простят ценители быстрого набора).
Упустил, что оцифровка номера строки вызывалась в ON не с парадного входа. Но нет худа без добра, обратил внимание на то, как ON сделан и оптимизировал (2.87 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728), 2.94 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571)). ON вызывал оцифровщик только для того, чтобы дойти до нужного номера строки, отбрасывая сами оцифрованные номера, и так каждый раз. Если номеров строк в ON много (например как у metamorpho), то это неприемлемое количество лишней работы.
В 2.94 кроме исправления и ускорения ON еще несколько оптимизаций. В нем старт ANTIGRAV (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034) стал быстрее 130 секунд, в PROVERKA забег от левой стены до правой меньше 23 секунд.
metamorpho
20.05.2023, 22:01
Ранее ivagor упоминал что загрузка 32 килобайт в формате монитора (командой BLOAD в Бейсике) на стандартной скорости - это в районе 200 секунд.
Если через SCREEN 4,N установать самую быструю скорость загрузки, то за сколько секунд можно будет загрузить 32 килобайт в формате монитора (командой BLOAD в Бейсике) ?
А можно ли сделать загрузку через BLOAD быстрее той которая указана в руководстве по Бейсику ?
Какой предел скорости через BLOAD на реальном Векторе возможен ?
Формально у SCREEN4 максимальный аргумент 255, но при таком значении не грузит (грузит с ошибкой). Успешная загрузка в Emu получилась при SCREEN4,246 - на 32 Кб это примерно 2 минуты. Для реала еще бы уменьшил (хотя бы до 235-240, надо проверять на реале). Есть альтернативный вариант - грузить самораспаковывающиеся архивы, если графика, то сожмется хорошо.
Improver
24.05.2023, 15:31
Ещё один забавный тест: откопал свою старую игру на бейсике "Воздушный шар" (делал в 1990 году по задаче из журнала "Наука и Жизнь"), там основное движение как раз было сделано через PUT достаточно большой картинки -- хорошо подходит для теста последних улучшений Бейсика. Итак, время движения воздушного шара от старта до столкновения с небоскрёбом без нажатия кнопок получается примерно такое:
Бейсик 2.5 -- 32 с.
Бейсик 2.85 и 2.87 -- 22 с.
Бейсик 2.94 -- 11 с.
Время засекал просто по секундомеру, но даже с погрешностью измерений явно видно большой прогресс в скорости обработки. Кому интересно будет повторить тесты -- вот архив с игрой: 78912
78913
Да, в этой программе прогресс виден. Хотелось бы еще быстрее PUTить, но без таблиц в квазе это вряд ли возможно.
Отвлекаясь от скорости - заметил, что бейсике F5 оказывается переключает магнитофонное реле. По-хорошему это должно быть описано в документации, но не могу вспомнить такой информации.
Improver
25.05.2023, 13:49
заметил, что бейсике F5 оказывается переключает магнитофонное реле. По-хорошему это должно быть описано в документации, но не могу вспомнить такой информации.А я помню, т.к. пользовался. :) Но в печатной документации на Бейсик этого нет, упоминание про F5 есть в программе "инфор-2" из базового комплекта:
78916
Когда писал про победу над бейсиком6128 упустил скорость вывода символов, исправляюсь (2.88 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728), 2.95 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571)).
Кроме печати буковок и LINE BF/BS есть еще неграфические оптимизации, особенно в 2.95, что позволило ему прокрутить пустой цикл (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938) менее чем за 11 секунд.
Исправлена недоработка PAINT, которая была начиная с классического 2.5. Если в PAINT не задавать цвет заливки и цвет бордюра, то он использует значения с прошлого раза. Ошибка в том, что на эти значения каждый раз накладывается маска доступа к плоскостям, и если это значения с прошлого раза, а мы увеличили число доступных для рисования плоскостей, то в цветах для PAINT они не будут "размаскированы". При неблагоприятном сочетании условий это даже могло приводить к зацикливнию PAINT. Не смертельно, можно нажать БЛК+СБР, но это неприятно и неправильно, теперь исправлено.
Извините за неприличное количество версий бейсика, но 2.96 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571) нельзя скрывать от общественности. Сегодня неожиданно сообразил как резко ускорить преобразование символьной записи десятичных чисел в двоичное представление. Микроускорение этой процедуры было в 2.95, но тут другой уровень. Это заметно сказалось на программах metamorpho (конечно не только на них, но это новые программы и результаты их тестов в предыдущих версиях я выкладывал). Старт ANTIGRAV (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034) и пробегание от левой стены к правой в PROVERKA (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178652&viewfull=1#post1178652) теперь в полтора раза быстрее, чем в 2.5! ANTIGRAV в 2.96 рисует заставку быстрее, чем загрузка готовой картинки по BLOAD"" даже с максимальной скоростью, а ведь кроме BLOAD пришлось бы инициализировать массивы и переменные, что тоже требует времени.
Rugg/Feldman benchmarks (https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks#Benchmark_7) для позиционирования векторовских бейсиков в общем ретрокомпьютерном контексте. Без учета графики, есть минимальный учет вывода букв. Тестики слишком простые, зато есть результаты для большого количества ретрокомпов. Пришлось внести незначительные изменения: без LET и в 2.5/2.96 STOP вместо END. Пробелы добавлял как оригинале, без них было бы чуть быстрее.
Нужно отметить, что в вики колонка Test 8 - это суммарный результат тестов 7+8. В таблице время в секундах, как в вики.
RFBM1 RFBM2 RFBM3 RFBM4 RFBM5 RFBM6 RFBM7 RFBM8 RFBM7+8
Корвет (целые) 1.16 5.45 20.32 19.30 20.52 30.52 47.67 - -
Корвет (одинарн) 1.82 6.96 19.48 19.62 20.84 34.67 57.06 9.68 66.74
BASIC 4.51 (целые) 1.22 5.39 18.91 18.00 19.42 29.59 46.34 - -
BASIC 4.51 (целые с \) - 12.37 13.80 23.97 40.72
BASIC 4.51 (одинарн) 1.85 6.82 18.51 18.71 20.14 33.95 53.73 9.34 63.07
MBASIC 5.29 (целые) 1.26 4.66 18.45 16.81 18.09 28.89 43.28 - -
MBASIC 5.29 (целые с \) - 10.89 12.17 22.96 37.35
MBASIC 5.29 (одинарн) 1.86 6.08 17.09 16.97 18.25 32.73 51.97 9.36 61.33
2.5 1.50 9.70 20.79 22.31 24.29 36.09 50.73 9.80 60.53
2.891 1.30 8.27 16.85 18.24 19.53 29.55 42.82 7.48 50.30
2.995 0.81 3.99 8.71 7.71 8.46 13.97 22.18 4.95 27.13
2.996 0.79 3.10 7.35 6.58 7.32 12.71 19.94 4.66 24.59
Результаты Бейсика-Корвет местами странные (RFBM3). Перепроверял, повторяемость есть. На Корвете тесты несомненно работали бы несколько быстрее - меньше времени на обработку прерываний, чуть-чуть быстрее процессор, быстрее вывод символов. Чтобы комментировать Бейсик-Корвет надо разбираться, но и без углубления видно, что 2.96 часто быстрее, даже если в корветовском использовать целые.
На какие ориентиры можно обратить внимание по 2.5/2.96:
1) Примерный аналог по железу и софту - Altair 8800 с Altair BASIC и результаты действительно близкие.
2) 2.96 позволил обогнать тройку классических компов с 6502 (1 МГц):
2.1) C64 с MS BASIC. 2.5 отстает во всех тестах кроме 8 (7+8), 2.96 впереди во всех тестах кроме 1.
2.2) Apple II с Applesoft BASIC. 2.5 медленнее во всех тестах, 2.96 быстрее во всех тестах.
2.3) VIC 20 c MS BASIC. Аналогично предыдущему пункту.
3) Скорость BBC Basic особо не впечатляет, как бы его не хвалили. Проц BBC Micro в 2 раза быстрее чем у предыдущей тройки и результаты примерно в 2 раза лучше. Да, у него есть интересные фишки, но скорость к их числу не относится. Пробовал пустой цикл в BBC Basic Z80 для CP/M - 2.96 даже на 8080 быстрее.
Бейсик-Корвет сделан на базе микрософтовского бейсика 4.x (скорее всего 4.51). Стало интересно сравнить с их финальным интерпретатором для 8080 - MBASIC 5.29 для CP/M (добавил в таблицу (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408)). Пробовал в T-34.
1. Предполагаю, что RFBM1 чуть медленнее из-за более медленного вывода символов. Там сама программа очень быстро пролетает, и относительный вклад вывода символов больше.
2. Все остальные тесты в 5.29 быстрее. Там, где разница <=4-5% - это из-за быстрого обработчика прерываний в T-34, но в ряде тестов разница намного больше.
3. В RFBM3 повторилась история с более медленным целочисленным вариантом (тоже перепроверял несколько раз).
5.29 на мой взгляд интереснее портированного корветовского своей скоростью и поддержкой дисковода, но там нет графики (а музыки и в корветовском нет). С графикой можно сделать финт ушами как для Океана-240 - не хакать глубоко бейсики, а внедрить графику в досовский драйвер печати символов через Esc-последовательности. Причем такой вариант подойдет для любого сипиэмного бейсика, в т.ч. для компилятора BASCOM. Но досы поддерживают 16 Кб видеопамяти из 32 и графические возможности были бы ограниченные, как у корветовского порта.
Добавил в таблицу (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408) результаты 4.51 (тестировал в T-34). Как и предполагалось, в большинстве тестов он немного медленнее 5.29, зато 18432 байта против 24320.
Жаль, что нет исходников 5.29 или 4.51 в готовом для компиляции виде, находится разве что такая штука (1 (https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/), 2 (https://github.com/microsoft/GW-BASIC)). Это GW-BASIC для x86, как оказалось в значительной степени транслированный (чем-то вроде такого (https://en.wikipedia.org/wiki/Source-to-source_compiler#SCP_TRANS86)) из 8080 (или менее вероятно z80), в комментариях остались регистры ABCDEHL.
Есть еще книжка (http://cpmarchives.classiccmp.org/trs80/Library/Books/Microsoft%20BASIC%20Decoded%20&%20Other%20Mysteries%20(1981)(James%20Farvour).pdf .7z) по TRS-80, где примерный аналог 4.51, но с вкраплениями команд z80.
Книжка по TRS80 прояснила ситуацию с целыми в RFBM3. Оказалось, что для целых есть нативные сложение/вычитание/умножение, а деление выполняется с одинарной точностью, что требует соответствующей конверсии. В RFBM4-7 тоже есть деление, но в RFBM3 делители 1-1000, а в 4-7 всегда 2, что проще для конверсии, в итоге накладные расходы не такие большие и не опускают целые варианты ниже одинарных на фоне остальных операций.
Я не одинок (https://github.com/feilipu/NASCOM_BASIC_4.7#modifications-to-ms-basic) в попытках оптимизации микрософтовского бейсика. Но я намного маньячнее, у чувака по ссылке ускорение до 12% с использованием команд z80, у меня в 2 раза больше при использовании 8080. А с z80 можно горы свернуть.
Посмотрел как хранится программа в 4.51/5.29 и оказалось, что используются "полукомпиляторные" штучки. Числовые константы и номера строк хранятся не в символьном виде (как в альтаирском 3.2 и его последователях) а во внутреннем формате, вместо номеров строк - адреса строк. С учетом этого понятно, почему 4.51 и 5.29 опережают 2.5 в большинстве тестов RFBM даже без использования целых (с одинарной точностью). По-хорошему они должны были бы рвать и 2.96, но микрософтовцы не стали заморачиваться с оптимизацией математики.
Жаль, что нет исходников 5.29 или 4.51 в готовом для компиляции виде
Там чёрт ногу сломит при дизассемблировании. Я попытался, но до конца не довёл. Очень часто используются прыжки в середину команды. Изврат, вобщем.
Приложенный архив хоть и даёт исходный бинарник при компиляции, но при релокации работать не будет, это точно.
Это так, чтобы посмотреть, насколько там всё запущено.
MBASIC.ZIP (на след. странице улучшенная версия)
- - - Добавлено - - -
Понравился сниппет:
RLC
ADD L
MOV L,A
ADC H
SUB L
MOV H,A
Понравился сниппет
Начальный RLC это частность, а остальной фрагмент (HL+=A) впервые увидел у спектрумистов, думал это они изобрели.
Да, RLC тут лишний, просто так скопировал, чтобы мысль не потерять, там был переход по таблице.
Не работает с отрицательными. А как красиво начиналось...
Не работает с отрицательными. А как красиво начиналось...
Это уже перебор, для смещения 0-255 отличный вариант, а для -128 - 127 настолько коротко и быстро на 8080 никак не получится.
Чего не было в описаниях советских постальтаирских бейсиков.
1. NEXT позволяет перечислить переменные через запятую. Если что - быстрее и короче совсем не указывать переменные в NEXT.
2. В имени переменной после первого символа могут быть не только буквы и цифры, но и пробелы (они будут проигнорированы). Т.е. переменная ABC идентична A B C или AB C или A BC (или AB). На мой взгляд это зря.
3. Более частный факт про описание 2.5 - информация про DELETE не вполне верная, нельзя сделать DELETE без аргументов и DELETE только с начальной строкой.
- - - Добавлено - - -
Если разрешить использовать BC или DE то так
mov c,a
add a
sbb a
mov b,a
dad b
Если нельзя трогать BC и DE, то придется задействовать команды перехода. Работоспособно, но не очень изящно.
parallelno
08.06.2023, 05:14
Там чёрт ногу сломит при дизассемблировании. Я попытался, но до конца не довёл. Очень часто используются прыжки в середину команды. Изврат, вобщем.
Приложенный архив хоть и даёт исходный бинарник при компиляции, но при релокации работать не будет, это точно.
Это так, чтобы посмотреть, насколько там всё запущено.
78956
- - - Добавлено - - -
Понравился сниппет:
RLC
ADD L
MOV L,A
ADC H
SUB L
MOV H,A
Вроде бы работает как для положительных, так и для отрицательных байт.
класная находка, спасибо! Кстати целиком там такой кусочек кода:
...
LXI H,L0495
L1B41:
...
RLC
ADD L
MOV L,A
ADC H
SUB L
MOV H,A
...
Он занимает 44 такта. В том контексте пара HL может иметь произвольное значение так как в программе есть JMP L1B41 из другого места, но если нам нужно прибавить к INT16 константе, то код можно немного ускорить до 40 тактов так:
...
RLC
ADI LOW_BYTE
MOV L,A
ACI HI_BYTE
SUB L
MOV H,A
...
Где LOW_BYTE это младший байт INT16 константы, а HI_BYTE это старший байт INT16 константы.
Надеюсь кому-то будет полезно. Извиняюсь что не по теме топика.
Ровно 4 года назад выложил первую "номерную" модификацию векторовского бейсика (2.55). Сегодня юбилейные 2.97 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571) и 2.89 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1177728&viewfull=1#post1177728).
1. ivagor зоркий глаз наконец-то узнал, почему в классике диапазон номеров строк 0-65529. Вернул и немного ускорил оцифровку.
2. Вернул "старый" вариант обработки токенов при вводе в INPUT. Расследование показало, что токенизация ввода INPUT - это оригинальная придумка авторов бейсика микрон.
Плюс - это позволяет вычислять арифметические выражения при вводе числовых переменных (микрософтовские от 3.2 до 5.29 и "наши" домикронные на базе 3.2 так не делают).
Минус - токенизация при вводе символьных переменных.
Оказалось, что в INPUT можно вводить символьные переменные с кавычками и при этом текст внутри кавычек не токенизируется даже в потомках микрона (нигде не читал о подобном). Поэтому решил убрать свой костыль, который был с 2.57, если нужно гарантированно обойтись без токенизации - используем кавычки.
3. Теперь о моей ошибке - в 2.95-2.96 частично поломал сравнение чисел и в некоторых случаях оно работало неправильно. Исправил и ускорил.
4. В 2.97 решил себя не сдерживать, использовал все свободное место и изыскал резервы, очень много оптимизаций, везде стало заметно быстрее даже на фоне 2.96.
В наборе тестов RFBM (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408) с одинарной точностью 2.97 тотально побеждает. Целые позволили удержаться микрософтовцам только в RFBM2. На мой взгляд очень хороший результат.
Пустой цикл (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938) теперь быстрее 10 секунд.
Синтетика это хорошо, но посмотрим ANTIGRAV - стартовое рисование уровня (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034) теперь меньше 100 секунд!
В итоге 2.97 - самый быстрый интерпретатор бейсика с одинарной точностью для 8080. Году в 78-79 этим даже можно было бы гордиться.
Немного подшаманил дизассемблер. Следующая итерация бейсика 5.29: см. дальше.
В 2.97 закралась ошибка в поиск строк, пофиксил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178571&viewfull=1#post1178571). Очень специфическая, в готовых программах она не проявляется, поэтому не находил тестами. На нее можно наткнуться набирая программу в самом бейсике при хитром порядке номеров. Есть и хорошая новость - после исправления и доработки скорость не ухудшилась, а даже микроскопически улучшились (обновлять результаты тестов не стал, принципиальной разницы нет).
Больше тестов хороших и разных. Решето Эратосфена.
10 DIM BS(500)
20 N=500
30 FOR I=2 TO N
40 IF BS(I)=0 THEN PRINT I;
50 J=1
60 IF I*J<=N THEN BS(I*J)=1:J=J+1:GOTO 60
70 NEXT
80 STOP
Пробелы между операторами для совместимости с 5.29. 4.51 и 5.29 тестировал в Т-34.
4.51 (одинарн) - 49.96 секунды
4.51 (целые) - 41 секунда
5.29 (одинарн) - 46.58 секунды
5.29 (целые) - 36.58 секунды
2.5 - 46.55 секунды
2.891 - 39.38 секунды
2.995 - 20.2 секунды
2.996 - 19.47 секунды
Вклад вывода чисел на экран можно оценить сравнив с результатами без PRINT I (4.51 не позволил оставить просто THEN, поэтому тут его результатов нет)
5.29 (одинарн) - 45.24 секунды
5.29 (целые) - 35.7 секунды
2.5 - 44.61 секунды
2.97fix - 29.86 секунды
2.98 - 18.71 секунды
Полез смотреть целочисленную арифметику в 5.29 и понял, что с целыми придется частично перетестировать. В продвинутых микрософтовских бейсиках есть отдельное целочисленное деление \. Т.е. когда есть деление для перехода на полноцелочисленность не хватает DEFINT, надо менять / на \. И я ведь когда-то читал про это, но не придал особого значения, а разница весьма заметная. Деление используется в RFBM3-7 (в решете деления нет). RFBM3 выдает переполнение с \, там остается /. Результаты RFBM4-7 с \ добавил в таблицу (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408). Но 2.97 не сдается даже когда в 4.51/5.29 используется \, в 2 тестах из 4 он впереди. Целочисленную арифметику в 5.29 по скорости особо не оптимизировали и в 4.51 явно не лучше, там большие резервы.
Подчистил "фантомные" метки в командах LXI (т.е. где должна быть константа). Наверное, больше уже ничего делать не буду.
Финальный дизасм бейсика 5.29: 78970
Арифметика с одинарной точностью в 5.29 оказалась несколько интереснее, чем ожидал.
Отличия от альтаирского 3.2 (и векторовского 2.5):
1. В цикл умножения добавили sticky bit, вероятно под влиянием IEEE, это немного замедляет умножение по сравнению с 3.2 и 2.5.
2.1. В деление добавили проверки при начальном увеличении экспоненты. Хорошая вещь, 3.2 и 2.5 могут пропустить переполнение при делении.
2.2. В окончании деления громоздко и коряво формируют троицу: guard bit, round bit, sticky bit, но дальше переходят на округление, где, как и в ранних версиях, учитывают только guard bit. Это или забывчивость или даже не знаю, как назвать.
3. Добавили оптимизацию частных случаев (когда есть нули) в сдвигах мантиссы вправо и влево. Тут я оказывается попал в тренд, в своих модификациях оптимизировал сдвиги вправо (и на мой субъективный взгляд сделал это лучше). Сдвиги влево пробовал менять, но в итоге в релиз не включил (не хватало места). Наверно зря, особенно если сравнить с тем, как в 5.29, надо было изыскать резервы. Кстати, в отличие от умножения и деления, в сдвиги вправо sticky bit не добавили.
4. У меня сложилось впечатление, что модификаторы бейсика совсем не напрягались. Для примера вместо того, чтобы убрать в нормализации лишнюю команду, которая ошибочно там оставалась с 3.2 (просто занимала 1 байт места и время на выполнение) они "исправили" ее на 3х байтовую, молодцы. Ну и они оставили некоторые старые неоптимальные решения, на мой взгляд бросающиеся в глаза, и добавили своих еще менее впечатляющих.
оставили некоторые старые неоптимальные решения
Я тоже посмеялся: операторы GOTO и GOSUB можно было писать с пробелом вот так - GO TO и GO SUB, но буква S куда-то потерялась. Прикольно, что всё равно как-то работает :)
- - - Добавлено - - -
Ага, можно писать GO DUB, GO HUB... всё равно токен будет GOSUB :)
По пробелам чемпион 4.51, там можно пробелы и в именах переменных, как в 3.2 (и 2.5+) и во всяких GO*UB, как в 5.29. А в 5.29 ужесточили с именами переменных. Думаю это один из источников ускорения 5.29, пробовал так делать в своей модификации - становится немного быстрее.
Извращенцы:
PUSH H
LXI D,L0FCC
CALL L0FBE
JNZ L0FD6
CALL L1305
LXI D,L0FD0
CALL L0FBE
MVI A,89h
JZ L0FB8
LXI D,L0FD3
CALL L0FBE
JNZ L0FD6
L0FB8:
MVI A,8Dh
POP B
JMP L1048
L0FBE:
LDAX D
ORA A
RZ
MOV C,A
CALL L1C5A
CMP C
RNZ
INX H
INX D
JMP L0FBE
L0FCC:
DB 'GO ',0
L0FD0:
DB 'TO',0
L0FD3:
DB 'UB',0
L0FBE сравнивает строки, только вот L1305 пропускает одну букву. При таком раскладе должно было работать GO ATO, но вместо этого получается GOSUB (JZ L0FB8 явно переходит на пару байт раньше). Победить не смогли, поэтому просто добавили GO TO в таблицу операторов:
OPS_G:
DB 'OT','O'+80h
DB 89h
DB 'O T','O'+80h
DB 89h
DB 'OSU','B'+80h
DB 8Dh
DB 'E','T'+80h
DB 0C1h,0
Микрософт :)
Понятно, что хотели как лучше - помочь неопытной части англоязычных пользователей, которые могут написать go to или go sub с пробелом, но реализация позорная. У меня получилось нормализовать приведенный фрагмент тремя исправлениями, многовато для простой задачи.
Не проще было добавить в таблицу операторов ещё и GO SUB? Тогда и лишнего кода не надо было бы. Единственный недостаток, пробел мог бы быть только один. Однако, и сейчас GO TO с несколькими пробелами не прокатит. GOSUB получается :) Если, конечно, переход оставить как есть.
- - - Добавлено - - -
Надо для прикола Altair Basic 8K дизассемблировать. Скорее всего там такая-же шняга :)
- - - Добавлено - - -
Дизассм Altair Basic 4K уже есть, с комментариями altairbasic.org (http://altairbasic.org/). Я знал, что у MBASIC оттуда ноги растут, сейчас хоть сравнить можно. Много похожего. Шняги с GOTO/GOSUB нет, но в 4Кб сложно что-то вменяемое вместить.
Не проще было добавить в таблицу операторов ещё и GO SUB?
Предлагаю такие 3 исправления (только приведенный фрагмент, там где L0FD6 я не смотрел):
1. CALL L1305 меняем на CALL L1306
2. JZ L0FB8 на JZ L0FBA
3. L0FD3: DB 'UB',0 меняем на L0FD3: DB 'SUB',0
Надо для прикола Altair Basic 8K дизассемблировать. Скорее всего там такая-же шняга
Нет, там нельзя пробелы внутри токенов. И писали его умные люди. Ошибаются все, но явной тупизны там нет.
metamorpho
03.07.2023, 19:34
Как пишется программа для Бейсика сейчас:
набираю код в текстовом редакторе -->> конвертор file.txt to file.cas -->> загрузка в Бейсике CLOAD"" и RUN (предварительно загрузка Бейсика в Эмулятор)
Можно ли сделать следующее:
Создать .bat файл, который взял бы .txt файл кода и преобразовал его через конвертор в .cas (или .bas) файл
Далее запустил эмулятор Вектора
Далее загрузил Бейсик (последнюю версию от ivagor)
Далее загрузил файл .cas (или .bas) и запустил бы его
В итоге мы можем писать код в удобном нам редакторе, а потом запускаем .bat файл, который делает все монотонные движения вместо нас.
Возможно ли такое ?
Нечто отдаленно похожее пытался делать подручными средствами (1 (https://zx-pk.ru/threads/9532-vektor-06ts-sredstva-razrabotki.html?p=551236&viewfull=1#post551236), 2 (https://zx-pk.ru/threads/9532-vektor-06ts-sredstva-razrabotki.html?p=553141&viewfull=1#post553141)), но это не совсем то, тем более на сегодняшний день.
Думаю v06x со скриптами способен приблизиться к желаемому или emu с современными утилитами, но конкретного готового решения у меня нет. Возможно svofski или b2m подскажут.
который делает все монотонные движения вместо нас
Возможно ли такое ?
Ну, ёлы-палы..
https://youtu.be/MmzbMz-DAGw
Файл должен иметь расширение ASC и, если там русский, он должен быть в UTF-8.
svofski, еще бы ты подсказал, как заменить используемый в таком автозапуске бейсик.
svofski, еще бы ты подсказал, как заменить используемый в таком автозапуске бейсик.
Просто загрузить другой бейсик вручную. Тогда дрег-н-дроп сделает CLOAD и все.
metamorpho
04.07.2023, 11:53
Ну, ёлы-палы................
:v2_jawdr::v2_eek:
И как я раньше проходил мимо такого сокровища !?!?!?! :)
svofski, спасибо !!!!
Жизнь за клавиатурой стала легче,
и как раз есть небольшая идейка (точнее их много но все небольшие) на Бейсике....продолжение следует....
Просто загрузить другой бейсик вручную. Тогда дрег-н-дроп сделает CLOAD и все.
Можно подробнее про "просто загрузить другой бейсик вручную" - как именно это сделать? Дропнул в v06x другой бейсик, потом дропнул asc - загружается 2.5. Открыл другой бейсик через диалог, потом дропнул asc - аналогичная картина.
metamorpho
04.07.2023, 12:54
Можно подробнее про "просто загрузить другой бейсик вручную" - как именно это сделать? Дропнул в v06x другой бейсик, потом дропнул asc - загружается 2.5. Открыл другой бейсик через диалог, потом дропнул asc - аналогичная картина.
У меня новый Бейсик грузится и работает. Я скачал последний вариант v06x - запустил, нажал на "кассету" и выбрал bas297.rom - он загрузился и далее закинул файл .asc и всё заработало.
Или дело в непоследнем v06x у меня или в r0m вместо rom, попозже попробую.
Я проверил на BASIC 2.97fix и v06x-8b8-win64, это работает.
Он проверяет байтики в памяти, чтобы поверить в то, что это бейсик. Если не находит, жмет сам себе F11. Может быть изменились байтики?
global signature_2b05 = [0xc5, 0xd5, 0x0e, 0x00, 0x57, 0xdb, 0x01]
В последней версии v06x все заработало, круто, спасибо!
metamorpho
05.07.2023, 12:29
svofski, а есть ли возможность ещё и команду RUN сделать автоматической (чтобы ближе к идеалу - меньше лишних движений) ?
Improver
05.07.2023, 12:55
команду RUN сделать автоматическойЭто было бы удобно при отладке программ на бейсике, но может помешать в других случаях, поэтому лучше не злоупотреблять автоматикой, хотя можно сделать её отключаемой в настройках.
Все скрипты могут быть пользовательскими, теоретически. Но прикручивать интерфейс, который это позволит удобно делать, пока руки не дошли. Набрать RUN все-таки не такая уж большая мука =)
Кстати, F9 должно ускорять 4x.
metamorpho
05.07.2023, 16:48
Все скрипты могут быть пользовательскими, теоретически. Но прикручивать интерфейс, который это позволит удобно делать, пока руки не дошли. Набрать RUN все-таки не такая уж большая мука =)
Кстати, F9 должно ускорять 4x.
Не, я не про интерфейс. Например команда CLOAD"" она же как-то сама набирается (без всякого интерфейса). Поэтому я подумал что и RUN можно также сделать как CLOAD"". Т.е. если есть уже готовое решение по команде CLOAD"", значит (подумал я) можно и RUN на этой заготовке сделать. :)
Но похоже там не всё так просто.
Всё же было бы здорово если RUN на автомате работал, поскольку когда запускаешь программу только один раз, то да это совсем не напрягает. Но когда делаешь новую программу и запускаешь её раз 100, то это уже другое ощущение процесса :)
А, кажется я понял насчёт интерфейса - это в смысле чтобы автоматический RUN сделать отключаемым - если это так, то тогда да.
Хотя можно сделать спец. версию с автоматическим RUN (если конечно это не много заморочек с заготовкой по CLOAD"").
А, кажется я понял насчёт интерфейса - это в смысле чтобы автоматический RUN сделать отключаемым - если это так, то тогда да.
Я об этом конечно же. Сейчас интерфейс процесса загрузки очень простой -- его нет. Это мой любимый вариант.
Если тебе не чужд Godot 3.5, ты можешь локально у себя поправить что хочешь. По-простому, чтобы без усложнений интерфейса, можно было бы решить все загрузкой скриптов из файлов вместо ресурсов. Но это пока не сделано.
- - - Добавлено - - -
metamorpho, возьми эту версию, специально по заказу https://www.sensi.org/~svo/v06x/v06x-cload-run.zip
metamorpho
05.07.2023, 19:29
metamorpho, возьми эту версию, специально по заказу https://www.sensi.org/~svo/v06x/v06x-cload-run.zip
svofski, спасибо за подарок !!!!
Эта версия почти работает. Маленький по объёму файл загружается и сам запускается. А вот файлы побольше загружается, но потом выдаётся RN вместо RUN или ещё R вместо RUN и соответственно "синтаксическая ошибка".
Наверное ему недостаточно времени на то, чтобы переварить. Попробуй по той же ссылке еще раз. Добавил задержку. Теперь он должен подождать пару секунд перед тем, как набирать RUN.
metamorpho
05.07.2023, 22:08
Наверное ему недостаточно времени на то, чтобы переварить. Попробуй по той же ссылке еще раз. Добавил задержку. Теперь он должен подождать пару секунд перед тем, как набирать RUN.
Заработало !! Спасибо !!
По поводу конвертирования файла .asc обнаружил небольшой моментик - если в файле .asc где-то встретится например
PLOT 50,120,2:LINE 2,2,BS:PRINT "Бейсик" - маленькими буквами
То на экране вместо маленьких букв будут другие символы. Конечно пользователю самому нужно следить за регистром букв, либо как вариант при конвертировании все мелкие буквы преобразовать в заглавные символы.
Да, любые ошибки будут плохо восприняты. Наверное можно сделать какой-то синтакс хайлайтер на основе конвертера, который бы подсвечивал заранее известные ошибки. Наверняка можно для vs.code и neovim это сделать. Но у меня нет такого опыта, так что на коленке быстро не сбацать.
Среди тестов не хватало сравнения с компилятором более содержательного, чем пустой цикл, пусть будет Мандельброт.
10 CLS
20 ROWS=21
30 COLUMNS=30
40 MAXITER=8
50 SCALE=4
60 SQ=2
70 SQ2=SQ*SQ
80 VR=-2.3*SCALE
90 VI=-1.0*SCALE
100 ZOOM=0.1*SCALE
110 FOR Y=0 TO ROWS-1
120 CI=VI+Y*ZOOM
130 FOR X=0 TO COLUMNS-1
140 CR=VR+X*ZOOM
150 ZR=CR
160 ZI=CI
170 FOR N=0 TO MAXITER-1
180 R2=ZR*ZR/SQ2
190 I2=ZI*ZI/SQ2
200 IF (R2+I2)>4*SCALE THEN 240
210 ZI=2*ZR*ZI/SQ2+CI
220 ZR=R2-I2+CR
230 NEXT
240 PRINT CHR$(40-INT(N));
250 XX=XX+1
260 NEXT X
270 PRINT
280 XX=0:YY=YY-1
290 NEXT
300 STOP
BASCOM - 79 секунд по секундомеру (mdos34)
2.5 - 191.6 секунды
2.97fix - 128.4 секунды
И это еще не финал соревнований.
260 NEXT X
Здесь X правда требуется, или это ради читабельности?
Для скорости лучше не указывать переменные в NEXT, но именно здесь X правда требуется, т.к. в строке 200 есть выход из цикла и без явного указания переменной бейсик путается, что ему NEXTить.
- - - Добавлено - - -
Добавил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1182018&viewfull=1#post1182018) скриншот
Понятно. И замена внутреннего цикла на бейсиковский эквивалент while скорости уж точно не принесет? N=0 ... N=N+1:IF N < MAXITER GOTO ...
Проблема с N=N+1: IF ... в том, что это два отдельных выражения, которые бейсик должен тяжело и мучительно парсить в цикле. NEXT парсить проще и он один делает и N+1 и GOTO.
Для сравнения оптимизированный вариант Мандельброта. Меньше букв и операций, меньше наглядности и понятности.
1 CLS
2 RW=21
3 CM=30
4 MI=8
5 SC=4
6 S4=4*SC
7 SQ=2
8 SQ=1/(SQ*SQ)
9 S2=2*SQ
10 VR=-2.3*SC
11 VI=-1.0*SC
12 ZM=0.1*SC
13 FOR Y=0 TO RW-1
14 CI=VI+Y*ZM
15 FOR X=0 TO CM-1
16 CR=VR+X*ZM:ZR=CR:ZI=CI
17 FOR N=0 TO MI-1
18 R2=SQ*ZR*ZR:I2=SQ*ZI*ZI
19 IF (R2+I2)>S4 THEN 22
20 ZI=S2*ZR*ZI+CI:ZR=R2-I2+CR
21 NEXT
22 PRINT CHR$(40-INT(N));
23 XX=XX+1
24 NEXT X
25 PRINT
26 XX=0:YY=YY-1
27 NEXT
28 STOP
Картинка не изменилась, просто быстрее работает.
BASCOM - 59 секунд по секундомеру (mdos34)
2.5 - 160.1 секунды
2.891 - 127.1 секунды
2.995 - 70.36 секунды
2.996 - 63.53 секунды
Видно, что компилятор дубовый и похоже сам не оптимизирует даже элементарные вещи. Зато он есть и работает, причем на самом 8080.
И все же он существует - исходник бейсика 5.2 с комментариями (https://winworldpc.com/download/c2bfc380-c2b2-c2b4-7d00-11c3a7c29d25)
Кроме того оказалось, что на известном сайте, где разобран 3.2 4k есть и фрагменты 4.1 Disk Extended (http://altairbasic.org/other%20versions/)
Очередная недокументированная фича - если в GOTO/GOSUB не указать номер строки, то он будет принят равным 0. Например
0 PRINT"HELLO WORLD!":GOTO
даст бесконечный цикл
А такой GOTO/GOSUB работает быстрее? Можно использовать для ускорения основного цикла, например?
Да, это быстрее, но использовать для ускорения цикла с IF не очень удобно, т.к. обычно запускают по RUN и выполнение программы начнется с 0й строки. Если добавить там проверку условия (первый запуск или нет), то это съест выигрыш. Еще можно делать самомодификацию программы, но на мой взгляд оно того не стоит.
В 2.97 помимо прошибания лбом стены за счет ускорения преобразования номеров строк в числа и собственно поиска строк добавил еще элементарное "кеширование" - запоминается последняя строка для GOTO и отдельно для GOSUB. Это дает заметный эффект не только в маленьких тестиках, но и в больших программах.
Идея с кешом замечательная. Вот бы вообще все строки хранить в заранее переваренном виде.
Известный факт, что продвинутые интерпретаторы (в т.ч. 4.51 и 5.29) и полукомпиляторы вместо номеров строк хранят адреса перехода, что конечно намного удобнее и быстрее при выполнении. Но для этого надо менять формат хранения программы, может когда-нибудь до этого дойдет. А пока приходится как в анекдоте про советские дороги и автомобили - "чего только не придумают эти русские, чтобы не строить хорошие дороги". Анонс - в новой версии среди прочего удалось добиться существенного прогресса по второму связанному с интенсивным поиском в рантайме фронту - поиск переменных, и продвинутый формат программы не спасет 4.51 и 5.29 от тотального поражения.
Не знал и не видел в векторовской документации, что 2.5 унаследовал от микрона функцию @ преобразующую dec->hex. Правда это не "настоящая" функция (как и TAB, SPC), ее результат нельзя присвоить символьной переменной, можно только напечатать через PRINT.
Еще одна скрытая возможность PRINT - поддержка Esc-последовательности
1Вh, 59h, 20+Y, 20+Х
для изменения координат курсора. Через нее реализованы CUR и AT, а можно использовать и напрямую, хотя это и неудобно.
Очередная вещь, про которую возможно знали все кроме меня - размер "точки" в LINE BS. Аргументы LINE BS задают во сколько раз увеличить символы по горизонтали и вертикали, тут вопросов нет. Но меня с детства удивляло, что "точки" (кроме случая LINE 1,1,BS) "внахлест". Оказывается сами они в 1.5 раза больше, чем расстояние между ними. Например при LINE 2,2,BS "точка" 3x3.
2.891 - версия с быстрым набором. Исправлены ошибки и недоработки, подробности в readme.
2.98 - очень быстрый интерпретатор.
Результаты тестов: RFBM (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408), старт ANTIGRAV (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034), пробежка в PROVERKA и взлет ракеты (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178652&viewfull=1#post1178652), пустой цикл (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938), решето (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179932&viewfull=1#post1179932), Мандельброт (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1182102&viewfull=1#post1182102).
Ошибки и недоработки тоже исправлены и есть уникальные особенности (как положительные так и отрицательные), подробности в readme.
Новые бейсики в картотеке: 2.891 (https://caglrc.cc/scalar/ware/909/), 2.99x (https://caglrc.cc/scalar/ware/940/)
в 2.98 заметил баг - после выхода из программы в интерактивный режим, PLAY продолжает играть.
Ramiros, спасибо, пофиксил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1183496&viewfull=1#post1183496).
Оказалось, что комодорщики, у которых тоже MS бейсик, знали про фишку (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1182274&viewfull=1#post1182274) с номером GOTO.
А еще они знали про "быстрый 0". Уже писал, что в 2.5 вместо 0 быстрее &, но это чисто векторовская фича, и в оригинальном 2.5 есть ограничения на места использования &. Но есть общемикрософтовский ноль - . (точка). В 2.5 точка быстрее всего, потом &, потом 0. В 2.98fix парсинг чисел очень сильно переделан, поэтому там 0 и . одинаково быстрые, а & чуть медленнее (и все эти варианты намного быстрее, чем в 2.5).
Небольшое дополнение про ориентиры для сравнения. По RFBM 2.98fix почти догнал (отстал в 5 тестах, немного обогнал в 2 и в 1 тесте ничья) BBC Basic на BBC micro (2 МГц 6502 без тормозов). Смотреть результаты BBC лучше не в wiki (там они странноватые), а в статье из Acorn User (https://archive.org/details/AcornUser014-Sep83/page/n27/mode/1up)
Не сомневался, что не первым изобрел велосипед кеширования номеров строк в GOTO/GOSUB, но не знал конкретных аналогов. В продвинутых бейсиках атари начиная с basic xl это есть.
Нашел обсуждение bbc basic, где подтвердилось, что он сам по себе не особо быстрый, фишка действительно в быстром железе (bbc micro) с тестами на котором обычно сравнивают.
Нашел вот такой космос: https://oldbytes.space/@zxdunny/109342959566427298
Попробовал переписать для Вектора. Получается чуть-чуть медленней, чем в оригинале, но тоже красиво. Как бы ускорить?
10 CLS:COLOR7,0,0:DIMK(32)
20 FORI=1TO15
30 R=1+SIN(PI/3+I/PI)
40 G=1+1*SIN(I/PI-PI/6)
50 B=1+1*SIN(3*PI/2+I/PI)
60 K=INT(R*3.5) + INT(G*3.5)*8 + INT(B*1.5)*64
70 N=(I*5)AND15:SCREEN0,N,K:K(N)=K:K(N+16)=K
80 NEXT
90 COLOR0:PLOT0,0:FORI=0TO15:COLORI:LINEI*8,0:NEXT
100 N=200:R=2*PI/235
110 X=0:Y=0:V=0:T=0:SZ=200:SW=256/SZ:SH=256/SZ
120 T=0.025
130 FOR I=0TON:FORJ=0TON
140 U=SIN(I+V)+SIN(R*I+X)
150 V=COS(I+V)+COS(R*I+X)
160 X=U+T
170 C=JAND15:COLORC-(C=0)
180 PLOT 128+U*63,128+V*63
190 NEXT:NEXT
200 REM T=T+0.025
300 N=0
310 FORI=1TO15:SCREEN0,I,K(I+N):NEXT
320 N=N+1:IFN=16THEN300
330 GOTO310
На самом деле весьма красиво уже когда 130 FOR I=0TO40:FORJ=0TON
Как бы ускорить?
Не совсем уверен, но по-моему квадратный корень будет быстрее, чем COS
Да и вообще, SIN/COS тут можно таблицей сделать. 1000-2000 значений по-моему достаточно.
Еще один медленный Мандельброт (https://zx-pk.ru/threads/32413-mandelbrot-v-ascii-art.html) (вариант побыстрее для вектора тут (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1182102&viewfull=1#post1182102)). Написан он явно так, чтобы притормозить интерпретаторы и дать фору компиляторам и полукомпиляторам, зато есть результаты других компов и бейсиков.
В списке перечислены компы, но понятно, что тестируются конкретные связки комп+бейсик.
Результаты вектора:
2.5 - 465.9 секунды, между спеком и +4.
2.98fix - 181.64 секунды, между БКшками.
В пузырящейся вселенной на мой взгляд фишка в анимации и векторовскому бейсику 4 фазы по силам.
Написан он явно так, чтобы притормозить интерпретаторы
Угу. Я потому и спросил. Просто мне не так очевидно, что именно вызывает неоправданные тормоза. Переписывать вселенную в сторону уменьшения читабельности не хочется. Хочется, чтобы оригинал был легко узнаваем. Но может быть что-то можно сделать, что помноженное на 40000 итераций, ускорит на чуть-чуть.
Четыре фазы можно попробовать. Правда тогда будет не цветное. Мне понравилось как цвета получились.
Угу. Я потому и спросил.
Это я про вариант Мандельброта, который рекламирует litwr. Но, конечно, пузырящаяся вселенная для 8-битных ретробейсиков подходит еще хуже. Понятно, что надо избавляться от математики внутри циклов и переходить на таблицы, о чем уже написал b2m. У автора SpecBAS в паке дем для его бейсика есть 3 варианта bubble_universe, возможно один из них менее требовательный. Насчет малого числа фаз - если оставаться в рамках бейсика и ослабить критерии трувекторизма, то есть 6128, у которого доступных плоскостей в 3 раза больше и можно даже сделать анимацию в цвете.
Хоть ZPU8080 расчехляй...
zpu8080 круче и код компактнее, но z88dk быстрее.
Да, наверное больше смысла все-таки будет освоить z88dk. Там и плавучка есть? Или ты думаешь про таблицы?
Там даже несколько библиотек плавучки, хотя для вектора с 8080 имеют смысл только две. И над выбором не придется особо думать, микрософтовская библиотека (фактически аналог математики в 2.5) лучше. У zpu8080 проблема с плавучкой в ненативности, она точная, но очень уж медленная. При любой реализации пузырей, даже на асме, я бы максимально постарался отабличить.
Уточненные и расширенные результаты тестирования неспешного Мандельброта (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1186954&viewfull=1#post1186954). Исправил "палитру" символов (при копировании исходника в нее на каком-то этапе затесался лишний пробел). Доработал определение времени прогона.
06Ц (Emu/VV/v06x):
2.5 - 439.896 секунды, между спеком и +4
2.98fix - 176.198 секунды, между БКшками
06Ц (Emu80):
2.5 - 439.976 секунды, между спеком и +4
2.98fix - 176.218 секунды, между БКшками
Дополнительно протестировал 6128 (Emu/VV):
1.0 (пзу) - 388.618 секунды, между C64 и 800XL (на 11.5% быстрее 2.5 на 06Ц)
2.5 - 393.371 в Emu/393.391 в VV, между 800XL и dragon (на 10.5% быстрее 2.5 на 06Ц)
2.98fix - 166.394 секунды, между БКшками (на 5.5% быстрее 2.98fix на 06Ц)
Отмечу, что по разнице скорости на 06Ц и 6128 можно оценивать степень покомандной (не алгоритмической) оптимизированности под векторовское торможение. Если для 2.5 эта разница 10.5%, то для 2.98fix 5.5%, потому что в 2.98 в критичных местах MOV R,R/INR/DCR максимально заменены на альтернативные варианты. Еще можно добавить, что если оптимизировать 2.98 с использованием команд 8085, то он обойдет результат БК0011.
Чуть подробнее про влияние векторовского торможения. Интересующиеся историей вектора наверняка помнят фрагмент из описания прототипа: "Эффективная тактовая частота - 2.4 МГц"
Т.е. на какой частоте должен был бы работать 8080 без торможения, чтобы соответствовать вектору на 3 МГц. Посмотрим, какой "эффективной тактовой частоте" соответствуют бейсики при выполнении Мандельброта. Результаты с торможением приведены в предыдущем посте, а результаты без торможения позволяет получить Emu, если в конфиге закомментировать adjust=4
06Ц без торможения (Emu)
2.5 - 327.855 секунд
2.98fix - 143.85 секунд
Сравнивая с "тормозными" результатами получаем, что для 2.5 эффективная частота=2.2359 МГц, для 2.98fix=2.4492 МГц.
2.5 можно отнести к плохо оптизированным под вектор программам, коэффициент торможения 0.7453 просто неприличный.
Что касается 2.98fix, то в совокупности с еще одной программой - расчет знаков Пи по алгоритму spigot (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html) считаю, что "эффективная частота" 2.43-2.45+ (коэффициент торможения 0.81-0.82) для вектора - это показатель хорошей оптимизации.
Возвращясь к авторской оценке считаю ее адекватной для умеренно оптимизированных для вектора программ. И у меня самого даже есть пример такой программы - "старый" Мандельброт на асме, в котором что-то оптимизировано, а что-то как написано первый раз так и осталось. И для того Мандельброта (не помню, выкладывал ли на форум, но точно посылал svofski) получался коэффициент торможения практически ровно 0.8, т.е. "эффективная частота" 2.4 МГц.
В завершение для полноты картины еще BASCOM. Тут менее точно, т.к. засекал по секундомеру.
06Ц (Emu, mdos34) - 98 секунд, между ABC 802 и BBC Master (mode 7), т.е. вышел на второе место в том списке
06Ц без торможения (Emu, mdos34) - 74 секунды
"Эффективная частота" в данном случае=2.27 МГц, коэффициент торможения 0.76.
Ну и немного спорта:
6128 (Emu, ОС6128) - 87 секунд, первое место перед ABC 802.
Перевел программу (и пофиксил некоторые баги)из журнала Радиолюбитель 8-1991:
Посылаю программу для настройки телевизоров, написанную для ПЭВМ "Вектор". Коротко о себе: ученик 11-го класса средней школы N244 г.Киева ОНИЩЕНКО Игорь.
Простой (даже слишком простой) тестик (https://youtu.be/H05hM_Guoqk?t=318), зато понятно и видно, что тестировали и как тестировали.
Время выполнения в секундах:
Amstrad CPC - 27
VIC-20 - 34
C64 - 40/38
TI-99/4A - 77
ZX Spectrum - 87
Siclair QL - 39
Atari 800XL - 50
Apple II - 36
06Ц (2.5) - 45
06Ц (2.98fix) - 21
Убрал из списка ZX80, т.к. там программа изменена и так некорректно сравнивать.
2.98 можно сказать вне конкурса, т.к. для популярных ретрокомпов есть более быстрые бейсики, которых не было в тесте.
Медленному Мандельброту (1 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1186954&viewfull=1#post1186954), 2 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187164&viewfull=1#post1187164), 3 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187315&viewfull=1#post1187315), 4 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187396&viewfull=1#post1187396)) понадобился эпилог.
После простенького тестика решил еще раз взглянуть на результаты Мандельброта и глаз зацепился за удивительно медленный Корвет. Решил сам проверить и получилось вот что:
Корвет, Бейсик 2.0/пзу (Emu80) - 493 секунды (по секундомеру)
По сравнению с результатом, который привел litwr (564.92 секунды) разница очень большая. Насколько помню процессор корвета не тормозится при обращении к пзу и основному озу, а один такт ожидания добавляется при обращении к (некоторым?) портам. Даже если emu80 не 100% точен такая погрешность не могла набежать.
Какое это имеет отношение к вектору - неспешного Мандельброта протестировал только из-за наличия результатов для нескольких компьютеров. Но получается, что тем результатам нельзя доверять, печальная история.
- - - Добавлено - - -
Кажется понял основную причину такой разницы. Часть интерпретаторов (а компиляторам это без разницы) при вводе удаляет лишние пробелы в начале строки, а часть не удаляет. Векторовский 2.5 удаляет, а корветовские 1.1 и 2.0 - не удаляют. В оригинале (https://zx-pk.ru/threads/32413-mandelbrot-v-ascii-art.html?p=1087473&viewfull=1#post1087473) щедро насыпали пробелов в начале строк внутри циклов, на самом напряженном участке, вероятно чтобы максимально затормозить незадачливые интерпретаторы. litwr не удалял эти пробелы из корветовской версии, я удалял. Ну а векторовские 2.5-2.98 сами удаляют эти пробелы, как уже написал, поэтому заметно опередили корвет, хотя проц корвета чуть быстрее.
ivagor, используя Basic2_98fix попробовал порисовать в GRAF V5.3, есть большие проблемы с GET/PUT и PAINT, артифачит и даже вылетает в бейсик во время заливки. В 2.5 проблем нет.
Ramiros, спасибо за багрепорт, но вряд ли я смогу поправить в данном случае.
В get/put проблема понятна, но места для исправления нет. Скорее всего придется ограничится добавлением в readme описания ограничения. Ограничение совместимости в данном случае это плата за скорость и компактность, увы.
А для paint хотелось бы увидеть конкретный пример зависания или вылета, у меня пока не получилось воспроизвести.
Для graf 5.3 (и других подобных программ, которых я пока не знаю) могу порекомендовать более консервативный 2.891 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1183496&viewfull=1#post1183496).
- - - Добавлено - - -
Наверно стоит написать, в чем проблема с put в graf 5.3. Там две картинки для последующих put получают не через get, а с помощью poke в массив. А внутренний формат хранения картинок get/put в 2.98 другой, иначе невозможно было сделать быстрый байтово-пиксельный get/put. Для совместимости в graf 5.3 пришлось бы добавить в poke детект того, что пишем в область памяти определенную как массив, предположить, что это для будущего put и преобразовывать на ходу записываемые значения. И это решение тоже было бы не универсальным, т.к. можно написать программу, которая будет делать poke в область массива, но не для put. Повторюсь, признаю, что 2.98 несовместим с graf 5.3, используйте 2.891.
Ramiros,
А для paint хотелось бы увидеть конкретный пример зависания или вылета, у меня пока не получилось воспроизвести.
Ошибку можно воспроизвести легко, простейший вариант - сначала залить весь экран красным, а потом синим.
Подозреваю что пэинту не хватает буфера для запоминания всех препятствий.
Понятно, но тут скорее проблема не в самом paint, а опять в get/put. В 2.891 все нормально.
Ну и на солнце тоже есть пятна, в оригинальном paint были две ошибки, которые исправил в 2.80 и 2.88. Другое дело, что авторы "классических" программ если напарывались на те ошибки, то могли их обходить.
1. В 2.99 исправил ошибку GET (была в 2.90-2.98), которая в GRAF при определенных условиях приводила к вылету в бейсик при последующем PAINT.
2. Сделал универсальный вариант GRAF 5.3U, который работает и в 2.5-2.891 и в 2.99. Программа при этом не увеличилась, а даже немного сократилась. Можно резюмировать, что без POKE внутрь массива GET вполне можно обойтись.
Ramiros, еще раз спасибо за багрепорты!
Upd 07.12.2023: 2.99fix - исправлен RENUM
Upd 26.12.2023:
В старых MS бейсиках на очень многих платформах есть баг (на 8080 его исправили в 5.x), проявляющийся при ошибке в вычислении функции VAL (видео (https://www.youtube.com/watch?v=6j8kel86F60&t=282s)). В 2.991 исправил, но пришлось убрать восьмеричные числа, которые были с 2.61 (в 2.5 их не было), т.к. места не хватало. 2.99fix не убираю на случай если кому-то хочется восьмеричных и не так важны ошибки при вычислении VAL.
Upd 27.02.2024: 2.992 - Исправлены/доработаны CLS и определение переполнения порядка числа при его переводе из символьного представления в двоичное.
Upd 09.03.2024: 2.993 - Исправлен RETURN, небольшие опимизации.
2.99x (https://caglrc.cc/scalar/ware/940/) в картотеке
Решил узнать, сколько быстродействия у медленного Мандельброта крадет зловредное оформление программы. Убрал REM и лишние пробелы, максимально "упаковал" в строки через двоеточние, перенумеровал с минимальным шагом. Алгоритм и все операции остались без изменений.
06Ц 2.5 (Emu) - 403.854 секунды вместо 439.896 у оригинала, на 8% быстрее
06Ц 2.99 (Emu) - 166.913 секунды вместо 176.198 у оригинала, на 5% быстрее
2.99 эффективнее борется с избыточностью программы.
Корвет бейсик 2.0/пзу (Emu80) - 486 секунд (по секундомеру) вместо 564.92 у оригинала (по данным litwr, Emu), на 14% быстрее
Повторюсь, что корветовский бейсик сам не удаляет начальные пробелы в строке, поэтому эффект от уборки мусора больше. У корвета еще остается резерв в виде частичного использования целых.
На мой взгляд тот тест в оригинальном виде проверяет скорее не быстродействие, а способность бейсика бороться с искусственными препятствиями, т.к. сложно представить например автора программы для корвета, который оптимизируя по скорости оставит кучу пробелов на критичном участке.
На мой взгляд тот тест в оригинальном виде проверяет скорее не быстродействие, а способность бейсика бороться с искусственными препятствиями, т.к. сложно представить например автора программы для корвета, который оптимизируя по скорости оставит кучу пробелов на критичном участке.
Все таки ты оцениваешь этот бенчмарк очень предвзято, имея глубокие познания о том, как работают Бейсики. Мы от тебя узнали, что Корвет тормозит от пробелов и теперь трудно это забыть обратно. Но мне как раз очень легко представить себе, что кто-то писал для Корвета, используя пробелы. Особенно потому, что скорее всего эту фичу кто-то сделал нарочно, чтобы придать Бейсику какое-то подобие структурности.
Ну и смысл бенчмарка по-моему не в запредельной оптимизации, а в сравнении разных величин при фиксированной постоянной.
1. Работа над ошибками.
Сначала (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1186954&viewfull=1#post1186954) сделал почти правильно. Потом (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187164&viewfull=1#post1187164), к сожалению, убрал один символов из "палитры", отсутствующий в 2.5 (и не только в 2.5 и не только на векторе). Это немного влияет на результат, что особенно важно при сравнении с другими компьютерами, поэтому вернул символ в "палитру" (вместо ~ использовал -). Время везде в секундах.
Оригинал:
06Ц 2.5 (Emu) - 453.375
06Ц 2.99 (Emu) - 181.43
Корвет 2.0/пзу (Emu, по данным litwr) - 564.92
Оптимизированный вариант:
06Ц 2.5 (Emu) - 416.214, на 8% быстрее оригинала
06Ц 2.99 (Emu) - 171.905, на 5% быстрее оригинала
Корвет 2.0/пзу (Emu80, по секундомеру) - 501 секунда, на 11% быстрее оригинала
Чтобы не было сомнений приложил исходники.
ты оцениваешь этот бенчмарк очень предвзято
2. На мой взгляд предвзятость - это введение в тест быстродействия нескольких элементов, которые часть бейсиков проигнорируют, а часть будут тратить на них время.
От пробелов тормозят все интерпретаторы, но нюанс в том, что некоторые (потомки msbasic 3.2, в т.ч. векторовский 2.5) убирают часть незначащих пробелов при вводе строки, а часть (более поздние msbasic, в т.ч. корветовский и, например, msxный) не убирают.
Особое оформление исходника - это нормально например в целях обучения. Но если это тест быстродействия и элементы оформления влияют на скорость, то по моему мнению их (элементы оформления) надо минимизировать.
До каких пределов минимизировать - вопрос для обсуждения. Как вариант - минимизировать до достижения максимальной переносимости теста при сохранении его правильной работы.
При таком подходе точно лишние:
1. Куча строк с комментариями, которые часть бейсиков будут пробегать каждый раз в цикле при поиске номера строки, а часть проигнорируют.
2. Пробелы в начале строк.
3. Длинные номера строк.
Пробелы между операторами части бейсиков (но не 2.5) нужны, тут компромисс более-менее понятен.
Разбиение всех операций на индивидуальные строки, без двоеточий - понятно, кому это нужно, но для MSBASICов это тормоз.
Также отмечу, что в подобных тестах целесообразно приводить точность вычислений для каждой платформы. У 2.5 и Корвета (в данном тесте!) 3 байта мантиссы и 1 байт экспоненты, двоичное представление.
Результаты лучше смотреть не в посте litwr, а на gitlab (https://gitlab.com/retroabandon/bascode/-/blob/master/benchmarks.md?ref_type=heads), т.к. там приведена точность расчетов и на чем тестировали.
Бесконечно можно не только смотреть на огонь, воду и работу других людей, но и обсуждать Мандельброта. На неделе придумал, как еще оптимизировать поиск двухбуквенных переменных (оригинальный Мандельброт за 163.618 секунды, на 10% быстрее 2.99), что позволяет обойти в таблице результатов БК0011. Но резервов по свободному месту уже не было, пришлось пойти на пару небольших компромиссов. Проблема в том, что пока не нашел других программ, в которых эта оптимизация давала бы настолько выраженный эффект, поэтому оставил этот бронепоезд на запасном пути. Тогда решил зайти с другой стороны - раз в других программах новая оптимизация мало что дает, значит основная проблема не в бейсике, а в данной реализации Мандельброта.
Показываю фокус, следите за руками. Берем manlt_optimized_corrected_06С.cas (который с косметическими оптимизациями) и всего лишь добавляем в первую строку нициализацию наиболее используемых переменных - получили manlt_optimized2_06С.cas. И вуаля - он выполняется в 2.99 за 144.509 секунды, чуть опережая даже BBC Basic на BBC Micro, и с запасом обходя БК0011 и Amstrad CPC. Подводя итог можно сказать, что удалось разоблачить и обезвредить диверсионную реализацию Мандельброта. Не стоит воспринимать этот тест слишком серьезно, хотя можно взять на заметку некоторые моменты.
Если важна скорость в векторовских родственниках 2.5 (и в многочисленных родственниках msbasic 3.2 на других компьютерах), то:
1. Минимизируйте число пробелов.
2. Перенумеруйте финальную версию с шагом 1, чтобы получить минимальную длину символьного представления номеров строк.
3. В финальной версии минимизируйте число комментариев.
4. "Упаковывайте" операции в строки через двоеточия.
5. Если переменных много, и некоторые из них используются намного чаще других, то стоит их инициализировать в первую очередь. Для 2.98-2.99 это не касается числовых переменных с однобуквенными именами, они в любом случае будут обрабатываться с максимальной скоростью.
Пункты 1-3 можно доверить роботу.
Пункты 1-4 кроме ускорения одновременно приводят и к сокращению размера программы.
Результаты тестов:
2.5 - 313.279 секунды
2.891 - 257.927 секунды
2.995 - 144.209 секунды
2.996 - 133.606 секунды
Получилось нечто похожее на красивую трассировку лучей. Списал домашку у Paul Dunn (https://github.com/ZXDunny/SpecBAS). 5 цветов (в т.ч. "полутоновые" тени), четкие границы квадратов в отражении благодаря точной плавучке. Красота требует жертв, готовьте супервекторы или запасайтесь терпением. Время рисования в 2.5 - примерно 389 минут (6 часов 29 минут), в 2.99 - примерно 165 минут (2 часа 45 минут).
Выглядит феноменально. Немного медленно, но ничего, ведь можно построить рендерфарм из тысяч Векторов и рендерить блокбастеры.
Интересно, насколько реально сделать небо неоднородным, чтобы у сфер макушка как-то выделялась?
Эта картинка уже не "как на спеке, только медленнее", а все же векторовская, мне нравится. Из компов с 8080 еще на корвете можно сделать примерно так, только там нет чего-то вроде 2.99, чтобы побыстрее. Полутоновые макушки сфер - это следующее, что хотелось бы, осталось найти, у кого списать пример попроще. Параллельно можно думать про конверсию в асм с прицелом на многопроцессорные супервекторы.
Я согласен, очень Векторовская картинка получилась.
Пока многопроцессорные Векторы не изобрели, можно сделать рендерфарм на локальной сети. Допустим 16 клиентов и один раздатчик.
И можно даже сделать в рамках существующих программных и аппаратных средств при участии оператора. Рендерфарм из 32 векторов. Каждый рендерит столбец 8x192 и сбрасывает через магнитофонный выход 3 файла (3 плоскости) по 256 байт на одну машину. Сам рендер займет чуть больше 5 минут (если 2.99), но потом еще возня с перекачкой. Со стороны наверно этот цирк выглядел бы забавно.
CityAceE
30.11.2023, 19:42
Получилось нечто похожее на красивую трассировку лучей.
Блин, какой же всё-таки крутой Вектор! Ну, безусловно, к Вектору должен прилагаться ivagor, иначе будет сложно оценить его крутизну! :)
Вектор в некоторых аспектах несомненно крут, а мне было достаточно 1) захотеть; 2) найти где списать; 3) списать. Хотелось бы еще изобразить что-то вроде такого (https://youtu.be/rY413t5fArw?t=33), причем на векторе можно в значительной степени "настоящими" цветами, без жесткого дизера.
И можно даже сделать в рамках существующих программных и аппаратных средств при участии оператора. Рендерфарм из 32 векторов. Каждый рендерит столбец 8x192 и сбрасывает через магнитофонный выход 3 файла (3 плоскости) по 256 байт на одну машину. Сам рендер займет чуть больше 5 минут (если 2.99), но потом еще возня с перекачкой. Со стороны наверно этот цирк выглядел бы забавно.
Такое можно устроить из эмуляторов. Звук можно провести через Virtual Audio Cable. Надо только подумать о том, как сделать так, чтобы 32 Вектора не конфликтовали друг с другом.
Видимо так: мастер соединен со входами всех воркеров. Выходы воркеров сливаются в один провод, который идет в мастер.
Каждый воркер имеет свой номер xxx. Он делает BLOAD"TASKxxx". Получает задачу с номером столбца (можно даже диапазон строк, чтобы дробить задачи на мелкие). Считает задачу. По окончании задачи делает BLOAD"READYxxx" и ждет -- это будет от сервера команда готовности принять результат от этого воркера. Затем он делает BSAVE"RESULTxxx" и переходит к началу (ждет следующую задачу).
Сервер, когда не раздает задачи, просто делает BSAVE"READYxxx", затем BLOAD"RESULTxxx". Нужен таймаут на BLOAD. Если нет ответа через 5 сек, переходим к следующему запросу.
BLOAD по-моему может бесконечно ждать требуемого имени. Вот чего я не знаю, так это как сервер сделает BLOAD с таймаутом. Наверное для этого потребуется все-таки какая-то ассемблерная хирургия.
Если не гнаться за максимальной эффективностью, то можно обычным BLOAD без таймаута грузить результаты в жестко заданном порядке - сначала номер 1, потом 2 и т.д. до 32. Меня больше смущает физическая реализация проводки 1<->32, тут стандартным решением вряд ли обойдешься. Для 1<->2 в детстве была покупная коробочка, там кнопками можно выбирать.
А что если порядок окажется не тот? Время расчета всегда будет отличаться, хоть и не сильно. По-моему лучше наколдовать сервер чуть-чуть поумнее. Если он будет колдунский, он еще и сможет раздавать задачи для загрузки в воркеров с уже подставленными идентификаторами тоже сам. Только воркеров все же придется вручную по очереди запускать.
За физическую реализацию лучше особо пока не страдать. Тот, кто соберет комплект из 32 исправных Векторов, обязательно сможет разобраться с такой мелочью.
Если порядок окончания расчетов не совпадет с тем, что ожидает мастер, то на мой взгляд это приведет лишь к задержке по времени (снижению эффективности), но не к нарушению работы.
Отвлекаясь от векторпанка можно вспомнить про КУВТы, там была какая-никакая локалка и при большом желании можно было организовать распределенные вычисления.
Если порядок окончания расчетов не совпадет с тем, что ожидает мастер, то на мой взгляд это приведет лишь к задержке по времени (снижению эффективности), но не к нарушению работы.
Как ты видишь ситуацию, когда два воркера закончили +/- одновременно и стали делать BSAVE ? И как распределять задачи, если воркеров меньше 32 ?
Что-то ЛВС-ное мы запускали через EMU, но детали как-то подзабылись. Идея с магнитофонами мне нравится больше, потому что просто понятней с чем имеем дело.
Как ты видишь ситуацию, когда два воркера закончили +/- одновременно и стали делать BSAVE ?
Воркеры должны делать BSAVE только когда получат приглашение (через BLOAD) от мастера.
И как распределять задачи, если воркеров меньше 32 ?
Если серьезно, то со всех точек зрения реалистичным мне представляется вариант с двумя векторами, соединенными через магнитофонный интерфейс. Мастер рендерит половину, посылает (BSAVE) приглашение второму, дальше проблем нет.
- - - Добавлено - - -
Все же добавлю про дальше. Когда второй (или 3й, 4й и т.д.) готов, то он посылает (BSAVE) мастеру ответ. И тогда мастер ожидает 3 файла собственно с картинкой.
Возвращаясь чуть ранее - мастер должен посылать копии приглашений второму (3му, 4му, ...) пока тот не ответит, на случай если воркер отстает со своей частью рендера.
- - - Добавлено - - -
Возвращаясь чуть ранее - мастер должен посылать копии приглашений второму (3му, 4му, ...) пока тот не ответит, на случай если воркер отстает со своей частью рендера.
Но тут потребуется патчнуть BLOAD на тему таймаута, как ты написал ранее.
Виртуальных Векторов мы можем насоединять и два и все 32. Правда в винде черт ногу сломит как это сделать, может быть под маком или линуксом это проще будет организовать.
Как в твоей схеме разрешается конфликт я все равно не понимаю. Если сервер отправит приглашение чуть раньше времени, получатель его не услышит и тогда сервер будет ждать ответа вечно. Ну никак не обойтись без таймаута.
- - - Добавлено - - -
А, вижу, ты тоже написал про таймаут. Ну вот.. Может быть проще тогда сервер сделать не на бейсике, раз уж такие дела.
Если решать частную задачу рендера на двух векторах, то проще всего переложить согласование на оператора. Когда мастер или воркер завершают рендерить свою часть они подают звуковой сигнал. Если первым завершил мастер, то переводим его в режим приема файлов с воркера. Если первым завершил воркер, то придется ждать мастера. И ничего не надо патчить, лишь бы оператор был рядом.
И ничего не надо патчить, лишь бы оператор был рядом.
Оператора придется патчить напитками и проч. Ну и вообще описание процесса напоминает анекдот про комьютерный вирус из технологически отсталого региона.
Есть еще вариант -- сервер ждет загрузки без имени, то есть первого попавшегося. Когда веркер заканчивает, он начинает делать BSAVE со случайными интервалами между повторами. Рано или поздно всем достанется таймслот, но может быть придется ждать очень долго, в основном из-за того, что клиент не знает продолжать ему или таки наконец заткнуться. И надо позаботиться, чтобы рандомайз был разный на всех веркерах. Еще при таком подходе не понятно, как раздавать новые задачи, если веркеров меньше 32.
BLOAD ведь делает опрос клавиш для останова оператором. Нельзя поками сделать в этом месте патч с вызовом счетчика? Чтобы не новую версию Бейсика писать. Тут не нужен какой-то изощренный таймер. Нет ответа минуту, стоп.
BLOAD пропатчить можно, но все же я продолжаю пребывать в убеждении, что просто для иллюстрации принципиальной возможности годится вариант с оператором за еду, а для чего-то более серьезного нужна сеть. Вряд ли можно изобрести какой-то особенный велосипед, все нормальное на эту тему уже придумано, выбор зависит от приоритетов.
Принципиальная возможность очевидна, а картина с оператором не демонстрирует вообще ничего, кроме способностей оператора, к сожалению. И их тут никаких исключительных не потребуется. Вот когда автоматически куча машин работает в сговоре друг с другом -- это впечатляет.
Композиция "Сферы над планетой у звезды-гиганта". Вот это уже примерно то, что я ожидал и хотел получить от трассировки лучей на векторе.
Попутно заметил, что в 2.98 слегка поломал RENUM, пофиксил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1188493&viewfull=1#post1188493).
Upd 13.12.2023: Оптимизированная версия SPGIANTRTX2.cas
Время рисования в 2.99:
SPGIANTRTX.cas - примерно 3 часа 24 минуты
SPGIANTRTX2.cas - примерно 2 часа 57 минут
metamorpho
07.12.2023, 17:09
:v2_jawdr: :v2_clapp:
parallelno
07.12.2023, 22:28
Класс!
Всем спасибо, рад, что понравилось!
Но очень долго рисует. Моральных сил на ассемблерный вариант трассировщика с красивыми сферами не хватает, зато смог заметно разогнать версию (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1190238&viewfull=1#post1190238) на бейсике. Читабельность ускоренного варианта пострадала, поэтому оставил и предыдущий.
metamorpho
22.12.2023, 11:42
Подскажите - есть FDD (образ диска) на нём программы на Бейсике - загрузил его запустил появилась "зелёная оболочка" микродос похоже нажал команду D увидел каталог программ, а как дальше запустить программу на Бейсике и самое интересное можно ли эту записать в формате .bas или .cas чтобы не на дисковом Бейсике запускать ?
Интересуют программы обнаружил их в каталоге программ центра Байт:
- музыкальный редактор (автор Дашковский) .BAS
- музыкальный редактор МУЗА .BAS
и ещё
- игра The House .BAS
Если есть у вас такие программы можете выложить их куда-нибудь ?
Для запуска бейсиковских программ с диска два варианта
1. run.com (run и дальше название бейсиковской программы)
2. Дисковый бейсик (http://caglrc.cc/scalar/ware/687/). Есть еще версия для РДС, но надо искать ссылку.
Проще пойти другим путем - вытаскиваем с диска .bas и с помощью например программы thetrikа преобразуем в .cas
metamorpho
22.12.2023, 16:32
......Проще пойти другим путем - вытаскиваем с диска .bas и с помощью например программы thetrikа преобразуем в .cas
А как вытащить с диска .bas ?
Сам пользуюсь плагинами для Windows Commandera (OdiWcx (https://github.innominds.com/serge-404/OriZEmu/tree/master/UTILS/OdiWcx-OhiWcx)) или Fara (надо найти ссылку). При настройке плагина OdiWcx надо задать расширение fdd вместо (или вместе) odi, т.к. изначально он для ориона, но формат образов одинаковый.
Fara (надо найти ссылку)
https://caglrc.cc/scalar/ware/810/ но по-моему он только для 32-битного Фара.
Только что в соседней теме еще упоминал SteinBlume, которая подходит тем, кто не любит фары с плагинами.
metamorpho
22.12.2023, 23:39
https://caglrc.cc/scalar/ware/810/ но по-моему он только для 32-битного Фара.
Установил FAR + плагин из картотеки (этот вариант похоже самый простой) - всё заработало - нашёл все файлы, которые искал.
ivagor, svofski спасибо !!
metamorpho
24.12.2023, 18:39
Насколько мне было известно руководство по Бейсику было только в виде сканированных .pdf и .djvu файлов.
И вот как то в очередной раз заглядывая в отсканированное руководство по Бейсику и ломая глаза на плохом качестве текста, я решил сделать более читаемым текст руководства по Бейсику. Вооружившись trial версией известной OCR программы сконвертировал PDF в текст. Качество конечно не самое лучшее получилось, было много ошибок в тексте и всякой непонятности, но всё же местами текст был нормальным. Далее дело шло медленно, но стабильно - я преобразовывал полученный текст руководства в некий новый документ. И вот сейчас представляю его вам.
https://drive.google.com/file/d/1xOiv4zLRAfiO57Ui6YEHi2_UnoQYme7t/view?usp=sharing
Данная версия докуммента конечно не идеальна и возможно содержит ошибки и неточности.
Если обнаружите ошибки или что-то посчитаете нужным добавить про различные хитрости и моменты Бейсика, то пишите здесь в теме про Бейсик или мне в личку и я буду вносить изменения в документ.
Навигация по PDF документу: Можно использовать гиперссылки. Я пользуюсь бесплатной версией программы (PDF XChange Editor) для просмотра PDF файлов. В ней легко перемещаться с помощью CTRL + HOME = в начало документа, CTRL + END = в конец документа, CTRL + F = поиск слова, в меню есть инструмент "Выделить текст" = можно выделить и скопировать любой текст.
Комодорщик обнаружил ошибку в старых MS бейсиках, подробности там (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1188493&viewfull=1#post1188493).
Improver
27.12.2023, 19:48
Если обнаружите ошибки или что-то посчитаете нужным добавить про различные хитрости и моменты Бейсика, то пишите здесьВ конце, в дополнениях, приводится раскладка клавиатуры для эмулятора, неплохо бы указать для какого, и раскладки в других эмуляторах -- там есть отличия, иногда существенные. А в остальном вроде всё хорошо. Спасибо за этот полезный и титанический труд!
metamorpho
27.12.2023, 22:01
В конце, в дополнениях, приводится раскладка клавиатуры для эмулятора, неплохо бы указать для какого, и раскладки в других эмуляторах -- там есть отличия, иногда существенные. А в остальном вроде всё хорошо. Спасибо за этот полезный и титанический труд!
Improver, спасибо за информацию !! Не знал что "раскладки в других эмуляторах -- там есть отличия". Учту это.
Занёс эту информацию в список для исправления ошибок.
https://drive.google.com/file/d/1gpD...ew?usp=sharing
Привет всем...
Посмотрел книжку...
Команда - Free - с 2мя 'e' пишется...
И еще опечатка в списке команда,
вместо Free - там Int написано...
А можно через Bload - массивы для Put
загружать?
Improver
28.12.2023, 05:36
Команда - Free - с 2мя 'e' пишется...В оригинальной документации с одной "е":
79985
- - - Добавлено - - -
metamorpho, в параграфе 3.5, в описании пропущено FRE() и далее из-за этого в INT(), LOG() и LG() что-то напутано в формулировках... И символ "Пи" там же не правильно написан.
FRE() - определяет размер свободного пространства в ОЗУ
INT() - выделяет целую часть числа
LG() - десятичный логарифм
LOG() - натуральный логарифм
еще
EXP() - число e возводится в указанную аргументом степень
RENUM - перенумерует строки программы в памяти
USR() - обращается к заранее подготовленной подпрограмме на машинном языке
- знак минус
Насчет "Пробелы не допускаются:" - в клонах MS бейсиков 3.2 и 4.x они, к сожалению, много где допускаются. Извините, сейчас не буду искать, где я про это писал, но этот пункт желательно уточнить.
Подробные описания не смотрел, но надо учитывать, что в оригинальном руководстве не все соответствует действительности, например аргументы DELETE, про это тоже где-то писал.
А можно через Bload - массивы для Put
загружать?
Начиная с 2.61 такая возможность есть.
metamorpho
28.12.2023, 12:23
Спасибо всем за информацию об ошибках !!
Всё исправил и обновил ссылку на новое описание Бейсика.
https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1191025&viewfull=1#post1191025
ivagor, нашёл вот что - в посте #358 в этой теме:
......
Чего не было в описаниях советских постальтаирских бейсиков.
1. NEXT позволяет перечислить переменные через запятую. Если что - быстрее и короче совсем не указывать переменные в NEXT.
2. В имени переменной после первого символа могут быть не только буквы и цифры, но и пробелы (они будут проигнорированы). Т.е. переменная ABC идентична A B C или AB C или A BC (или AB). На мой взгляд это зря.
3. Более частный факт про описание 2.5 - информация про DELETE не вполне верная, нельзя сделать DELETE без аргументов и DELETE только с начальной строкой.
1. например
FOR A=1 TO 10
FOR B=1 TO 10
NEXT B
NEXT A
т.е. можно не указывать NEXT B, NEXT A, а просто написать NEXT, NEXT ?
А что имелось ввиду "NEXT позволяет перечислить переменные через запятую" - как так через запятую, что за переменные ?
2. Пробелы в именах - это относится к Бейсику v.2.5 ?
---------
Ещё - можно ли в Бейсике (не применяя ассемблерных вставок) через OUT в порт 1 вывести синтезированную речь (возможно запретив прерывания) ?
Каким образом (как это выглядит в строках кода) через Bload можно загружать массивы для Put ?
Привет всём...
Через restore, read, data - спрайты рисовать,
много памяти уйдёт...
Хотелось бы по подробнее про загрузку
массивов для put через bload...
Насчёт сроков правильно написали...
Многие не помнят как команды работают,
а Вы за 2 месяца софтину хотите???
Да ещё приличную...
Ну я как бы начну, а там как получится...
1. например
FOR A=1 TO 10
FOR B=1 TO 10
NEXT B
NEXT A
т.е. можно не указывать NEXT B, NEXT A, а просто написать NEXT, NEXT ?
можно NEXT B,A или NEXT:NEXT
Второе, насколько помню, чуть быстрее
2. Пробелы в именах - это относится к Бейсику v.2.5 ?
Да, к 2.5 и всем его модификациям это тоже относится
Ещё - можно ли в Бейсике (не применяя ассемблерных вставок) через OUT в порт 1 вывести синтезированную речь (возможно запретив прерывания) ?
К сожалению нет, частота дискретизации недостаточная, бейсик слишком медленный.
Каким образом (как это выглядит в строках кода) через Bload можно загружать массивы для Put ?
Попробуем без подробного кода
Генерация
1. Делаем HIMEM, чтобы выделить место под картинку
2. Рисуем на экране картинку и делаем GET в область между HIMEM и экраном
3. Делаем BSAVE сохраненной через GET картинки
Использование
1. HIMEM
2. BLOAD
metamorpho
28.12.2023, 14:04
...
Насчёт сроков правильно написали...
Многие не помнят как команды работают,
а Вы за 2 месяца софтину хотите???
Да ещё приличную...Ну я как бы начну, а там как получится...
Это похоже больше в тему конкурса подходит.
Всё же Бейсик не ассемблер, а тем более если раньше программировали на нём, то это как на велосипеде один раз научился, а потом спустя время навык намного легче восстановить, чем если бы вообще не знали Бейсика.
Так что 2 месяца вполне себе нормально, а если больше растягивать, то бывает вдохновение теряется :)
.............
Попробуем без подробного кода
Генерация
1. Делаем HIMEM, чтобы выделить место под картинку
2. Рисуем на экране картинку и делаем GET в область между HIMEM и экраном
3. Делаем BSAVE сохраненной через GET картинки
Использование
1. HIMEM
2. BLOAD
Оригинальный способ !!
А как быть если много разных картинок - спрайты анимации например - это надо же расположение каждой в памяти знать, иначе как PUT догадается откуда выводить из какого массива ?
Или же уже при записи вся структура (массивы) должна быть определена и она записывается при запоминании в GET ?
Оригинальный способ !!
Он несколько более оригинальный, чем хотелось бы, в 2.5 так не получится.
А как быть если много разных картинок - спрайты анимации например - это надо же расположение каждой в памяти знать, иначе как PUT догадается откуда выводить из какого массива ?
Или же уже при записи вся структура (массивы) должна быть определена и она записывается при запоминании в GET ?
Надо самому распланировать распределение памяти. Для этого надо считать, сколько займет каждая картинка. Самый простой вариант - берем формулу из описания 2.5
INT(Х*У/8+3/4)+1 и умножаем на 4 - это будет число байт на картинку. На самом деле можно и чуть поменьше, но пусть лучше будет с запасом.
Вместе с графическими данными хранятся еще два параметра - ширина и высота картинки.
частота дискретизации недостаточная, бейсик слишком медленный.
Прикинул достижимую частоту дискретизации при выводе по OUT1,PEEK(I)
в 2.5 - 160-190 Гц
в последних модификациях - 300-320 Гц
А для речи надо раз в 10-20-30 больше.
metamorpho
29.12.2023, 19:12
Почитал ("по быстрому варианту") тему про подключение мыши к Вектору и вот такой вопрос появился:
Можно ли как-то сделать чтобы например в эмуляторе включить опцию МЫШЬ и в Бейсике или в других программах мышь например имитировала движение Векторовских "курсорных клавиш" и например нажатия "Пробела" и "ВК" ?
Т.е. в эмуляторе мы двигаем мышь (обыкновенную :) не PS/2 не COM ) и при эмуляция выдаёт код как-будто в Векторе произошло нажатие клавиши вверх вниз влево вправо (а также можно на любые клавиши повесить движение по диагонали) Пробел (левая кнопка мыши) ВК (правая кнопка мыши).
Что это может дать ? Например я в эмуляторе (на ассемблере или в Бейсике) сделал редактор графический или музыкальный - и там основное управление повесил на стрелки и Пробел и ВК, чтобы с помощью мыши было удобно редактировать.
Насколько трудно прикрутить к эмулятору такую опцию ?
Почитал ("по быстрому варианту") тему про подключение мыши к Вектору и вот такой вопрос появился:
Можно ли как-то сделать чтобы например в эмуляторе включить опцию МЫШЬ и в Бейсике или в других программах мышь например имитировала движение Векторовских "курсорных клавиш" и например нажатия "Пробела" и "ВК" ?
Т.е. в эмуляторе мы двигаем мышь (обыкновенную :) не PS/2 не COM ) и при эмуляция выдаёт код как-будто в Векторе произошло нажатие клавиши вверх вниз влево вправо (а также можно на любые клавиши повесить движение по диагонали) Пробел (левая кнопка мыши) ВК (правая кнопка мыши).
Что это может дать ? Например я в эмуляторе (на ассемблере или в Бейсике) сделал редактор графический или музыкальный - и там основное управление повесил на стрелки и Пробел и ВК, чтобы с помощью мыши было удобно редактировать.
Насколько трудно прикрутить к эмулятору такую опцию ?
В VV в разделе Options...Mouse можно на любую кнопку мыши и даже на вращение колеса повесить обработку любой векторовской клавиши, а вот на перемещение курсора к сожалению нельзя.
metamorpho
29.12.2023, 20:52
В VV в разделе Options...Mouse можно на любую кнопку мыши и даже на вращение колеса повесить обработку любой векторовской клавиши, а вот на перемещение курсора к сожалению нельзя.
Ramiros, спасибо за информацию - это уже хоть какой-то прогресс...
Нет, это будет ужасно.
А если сделать по другому (думаю это совсем просто должно быть для того чтобы включить в эмулятор) - например назовём опцию в эмуляторе "БУДУЩАЯ МЫШЬ" :)
мышь USB которую подключат к Вектору в будущем, но уже сейчас она доступна в эмуляторе.
Так вот (при включении опции "МЫШЬ") эмулятор будет выдавать в определённые ячейки памяти "эмуляции Вектора"
координаты мыши X (0-255) Y (0-255), если курсор мыши вне поля эмуляции то выдаёт 0,0 .... также ещё в другой ячейке памяти будет информация о нажатии левой и правой кнопки мыши. Например это можно заносить в ячейки 7FFD-7FFF. Понятно что при включении этой опции некоторые программы могут не работать, однако эта опция не для тех программ которые написаны в прошлом, а для новых программ, которые можно написать уже сейчас используя эмулятор. К тому же опцию всегда в любой момент можно отключить.
Эта опция - это возможность сделать более удобные программы ведь мышь в своё время была "скачком" в отношении удобства использования программ. И эта опция немного "развяжет руки" некоторым творцам кода :)
В том числе и Бейсик на Векторе уже будет с супер возможностью.
"БУДУЩАЯ МЫШЬ"
Пока я видел только PS/2 мышь KTSerg-а. Попытки договориться о том, как должна работать какая-то другая будущая мышь пока ни к чему не привели, потому что каждый хочет изобрести именно свой велосипед. Я лично прохладно отношусь к поддержке мыши на Векторе, поэтому пока просто жду, пока один из велосипедов не получит общественное признание и богатую библиотеку поддерживающего его софта.
metamorpho
29.12.2023, 22:46
Не обязательно что эта "будущая мышь" когда-нибудь вообще появится. Скорее всего она будет "жить" только в эмуляторе. Я в большей мере имел ввиду иметь возможность уже сейчас создавать программы для Вектора, в которых можно удобно что-то делать с помощью мыши. Скорее эта опция не "будущая мышь", а "виртуальная мышь".
Продолжаю подбирать крошки за комодорщиками. Подсмотрел у того же чувака (это не он нашел, он в данном случае популяризатор) такую оптимизацию:
вместо
IF сравнение1 AND сравнение2 THEN
заметно быстрее делать
IF сравнение1 THEN IF сранение2 THEN
Продолжаю подбирать крошки за комодорщиками. Подсмотрел у того же чувака (это не он нашел, он в данном случае популяризатор) такую оптимизацию:
вместо
IF сравнение1 AND сравнение2 THEN
заметно быстрее делать
IF сравнение1 THEN IF сранение2 THEN
В этом есть логика :) , и наверно в сравнение1 нужно подставлять то, которое чаще дает false
Фишка в том, что IF IF быстрее даже если выполняются оба условия.
Пожелания к авторам конвертеров BAS/CAS<->TXT
1. Простое - выдавать лог с номерами строк, длина которых больше стандартной допустимой в бейсике.
2. Посложнее - реализовать перенумерацию. Тогда с чистой совестью можно было бы выпилить из бейсика RENUM и использовать освободившееся место для чего-нибудь более полезного.
3. Сложное - расширить диапазон поддерживаемых бейсиков. Кроме 2.5-2.99 есть куча потомков MS Basic 3.2 на множестве компьютеров, у которых формат программы одинаковый, но различаются коды токенов и файлы-контейнеры. Или вынести из программы в некие редактируемые конфиги коды токенов и описания контейнеров или хотя бы поддержать некоторые другие бейсики. Сейчас например в РЕТРОГРАДе добавился специалист, но нет средств для конверсии его программ. Редактировать в самом бейсике конечно можно, но это значительно менее удобно.
ivagor, привет. Думаю смогу добавить, нужно только знать какие операторы (все случаи) работают с номерами строк. Помню в каких-то бейсиках можно было писать if ... then number, в некоторых были on error goto. Иметь бы такой список - без проблем бы добавил в свой конвертер перенумерацию. Насчёт других бейсиков нужно глянуть как там обстоят дела с пробелами между операторами.
88h - GOTO
89h - RUN
8Bh - RESTORE
8Ch - GOSUB
A1h - THEN
С пробелами во всех потомках MS бейсика 3.2 все одинаково, т.е. как в 2.5. Отличаются коды токенов и форматы файлов, да и то многое совпадает. Тут надо ждать инициативы от желающих добавить тот или иной бейсик. Требуются соответственно список токенов (код - оператор/функция) и формат файла.
- - - Добавлено - - -
Кстати, желательно еще добавить функцию автоматического удаления всех незначащих пробелов и (наверно отдельно) комментариев. В составе сервисной утилиты для РК были такие функции.
Improver
03.01.2024, 23:52
Список токенов, после которых RENUM проверяет наличие номера строкиК этому списку я бы ещё добавил:
CEh -- EDIT
CFh -- DELETE
98h -- LIST
D8h -- LLIST
как команды, использование которых не возбраняется в тексте программ на бейсике.
- - - Добавлено - - -
Да, и стоит упомянуть, что GOTO и GOSUB могут иметь несколько номеров строк в виде списка в случае их использования с оператором "ON [выражение] GOTO/GOSUB".
Требуются соответственно список токенов (код - оператор/функция) и формат файла.
Да. Если кто-то скинет подобное для других ПК - добавлю в свой конвертер. Пока делаю опцию перенумерации и удаления/добавления пробелов.
Привет всем...
Вот нарисовал я спрайты на Спектруме для конкурса...
Как их через Bload - на Вектор загрузить?
На Спектруме формат - name.$C...
metamorpho
05.01.2024, 13:57
...Вот нарисовал я спрайты на Спектруме для конкурса...Как их через Bload - на Вектор загрузить? На Спектруме формат - name.$C...
Тут появляется вопрос про формат данных сделанный на Спектруме, как они расположены ?
Для Вектора в игре сколько будет использовано плоскостей ?
Если всё соответствует Векторовскому расположению графики, то похоже самый простой способ
зайти на "Прекрасный Ассемблер" вот пример использования
https://svofski.github.io/pretty-8080-assembler/?data:text/plain;base64,ICAgICAgICA7IEJBU0lDIDIuNSBCTE9BRCBkY XRhCiAgICAgICAgLnByb2plY3QgYm9ibGFkCiAgICAgICAgLnR hcGUgdjA2Yy1jYXMKCiAgICAgICAgLm9yZyAkNzAwMAogICAgI CAgIGRiICdPaCBoYWknCiAgICAgICAgZHMgMTYKICAgICAgICB kYiAxLDIsMyw0
и там вставить свои данные
.org $8000 (здесь указываем нужный адресс куда будет загружаться картинки)
db 1,2,3,4..........(здесь наша графика)
и выгрузить их кнопкой "TAPE" в формате .CAS
далее в своей основной программе через BLOAD"" загружаем то что записали через TAPE в "Прекрасном Ассемблере"
Далее (кадры анимации например) командой GET запоминаем данные с экрана
(при этом запоминать можно из одной плоскости или из всех 4-х это регилируем командой SCREEN 2,N)
Далее стираем экран и выводим меню игры
и далее можно использовать PUT, выводя запомненую графику на экран.
Тут появляется вопрос про формат данных сделанный на Спектруме, как они расположены ?
Для Вектора в игре сколько будет использовано плоскостей ?
Про плоскости - думаю 3...
8 цветов хватит...
Данные расположены подряд...
2*16 байт на спрайт...
Но конвертировать на Векторе буду...
metamorpho
05.01.2024, 23:15
Про плоскости - думаю 3...8 цветов хватит... ..
В таком случае можно использовать следующий вариант:
10 SCREEN 2,15:CLS:SCREEN 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0:REM очистка всех плоскостей видео ОЗУ и гасим все цвета
20 HIMEM &9FFF:REM память для программы и данных на Бейсике увеличивается до 24 Кб
30 CLEAR: DIM A(NNN),B(NNN),C(NNN),......: REM инициализация места хранения графики
40 SCREEN 2,0:CUR 24,1:BLOAD "":REM загружаем графику в экран
50 SCREEN2,7:REM запрет обращения к плоскости 8000-9FFF
60 PLOT 0,0,2:GET 16,16,ADDR(A(0)).......: REM запоминаем с экрана в память графику (кадры анимации например)
65 CLS
70 SCREEN 0,0,0,1,2,3,4,5,6,7,0,0,0,0,0,0,0,0:REM установка палитры цветов под режим SCREEN 2,7 вместо 1-7 цвета палитры.. в итоге восемь цветов вместе с фоном
110 REM ВЫВОД МЕНЮ
В таком случае можно использовать следующий вариант:
С этим Bload - приколы...
Записал Bsave "tst2",&8000,&8fff
На выходе файл размером - 4369 байт...
#1000=4096 байт...
Один в один не получается...
???
Есть предложение продолжить обсуждение деталей преобразования картинок в теме например про "Картинки для вектора" или в теме конкурса "РЕТРОГРАД".
metamorpho
06.01.2024, 17:59
Есть предложение продолжить обсуждение деталей преобразования картинок в теме например про "Картинки для вектора" или в теме конкурса "РЕТРОГРАД".
Может я чего не понял, но почему тема преобразования и загрузки картинок для Бейсика не подходит в этой теме.
Мы же здесь обсуждаем вопросы по Бейсику или нет ?
Может я чего не понял, но почему тема преобразования и загрузки картинок для Бейсика не подходит в этой теме.
Мы же здесь обсуждаем вопросы по Бейсику или нет ?
Тема конвертации картинок бесконечно глубокая и она завалит тут собой все очень быстро, лучше ее обсудить в отдельной ветке. Зачем все валить в одну кучу? Поиск на форуме плохой, а гугл его не индексирует. Откуда страх создания новых тем?
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot