Просмотр полной версии : Бейсики для Вектора-06Ц и клонов
metamorpho
15.01.2024, 00:51
Обновил "Новое описание Бейсика" (добавил таблицы для оператора SCREEN, исправил всякие ошибки....)
скачать здесь https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1191025&viewfull=1#post1191025
metamorpho, таблицы красивые, информативные, здорово. Если возможно предлагаю "Таблицу кодов физических цветов" (SCREEN 0) переделать как у b2mа (http://caglrc.cc/scalar/ware/770/)
И желательно бы еще пробежаться по тексту, осталось много мелких ошибок OCR. Если соберусь, то составлю перечень, но не могу твердо пообещать.
ivagor, а ведь таблицу b2m-а можно дополнить текстом с кодами цветов. Я имею ввиду программно.
Можно любую картинку, в т.ч. и коды цветов, но почему-то никто не сделал, наверно не чувствовали необходимости. clrs это образец стиля b2mа, самодокументированная - коды цветов от 0 до 255 в порядке чтения слева-направо и сверху-вниз.
metamorpho
15.01.2024, 17:15
.....предлагаю "Таблицу кодов физических цветов" (SCREEN 0) переделать как у b2mа (http://caglrc.cc/scalar/ware/770/)
И желательно бы еще пробежаться по тексту, осталось много мелких ошибок OCR. Если соберусь, то составлю перечень, но не могу твердо пообещать.
ivagor, да согласен у b2m более лучший вариант - нагляднее и практичнее если использовать оттенки цветов. Поставлю себе в список на обновление.
Насчёт ошибок - да их там наверно ещё хватает, но я ошибки скорее всего сам отловлю вскоре, а вот если бы ты посмотрел на описание команд Бейсика и сказал мне где исправить (или дополнить) их неточное описание которое есть в оригинале - то было бы здорово.
Например недавно увидел в описании команды COLOR "цвет изображения","цвет фона","цвет бордюра" и в "цвет изображения" в оригинале написано от 0 до 255, но ведь их всего 0-15.
ivagor, а ведь таблицу b2m-а можно дополнить текстом с кодами цветов. Я имею ввиду программно.
Вот это было бы здорово...
почему-то никто не сделал, наверно не чувствовали необходимости.
Мне почему-то просто не приходило в голову. Подумал об этом только когда увидел картинку из книжки metamorpho.
Мне почему-то просто не приходило в голову.
Да мне тоже, но вроде и так было понятно, где какие цвета. С напечатанными номерами быстрее и удобнее, но вряд ли программу использовали бы как справочник, хотя кто знает.
если бы ты посмотрел на описание команд Бейсика и сказал мне где исправить (или дополнить) их неточное описание которое есть в оригинале - то было бы здорово.
Например недавно увидел в описании команды COLOR "цвет изображения","цвет фона","цвет бордюра" и в "цвет изображения" в оригинале написано от 0 до 255, но ведь их всего 0-15.
Это сложнее, тем более обещать не могу, но если что, то конечно выложу сюда.
Про "цвет изображения" в COLOR - там от 0 до 255 для символов. Младший полубайт - цвет символа, старший полубайт - цвет фона символа. А для графики от 0 до 15, да.
metamorpho
15.01.2024, 20:30
...............Про "цвет изображения" в COLOR - там от 0 до 255 для символов. Младший полубайт - цвет символа, старший полубайт - цвет фона символа. А для графики от 0 до 15, да.
Вот это открытие, я этого не знал. Странно почему создатели оригинального руководства по Бейсику не разъяснили про старший и младший полубайты, а просто написали: "<цвет изображения> - это арифметическое выражение, определяющее математический цвет изображения и подложек под символами."
Посмотрел, может в уроках бейсика про это писали, но нет. Кстати, имеет смысл упомянуть серию уроков бейсика в руководстве. Например в 8 уроке самая векторозависимая информация (знакогенератор, ячейки таймера и т.п.). Ошибки там тоже есть, никто не идеален.
Так или иначе, но программисты про цвета символов знали и в некоторых программах использовали.
metamorpho
15.01.2024, 23:57
Ещё одно обновление "Нового описания Бейсика".
Решил не откладывать в долгий ящик и прошёлся орфографией по тексту и исправил штук 50 (или больше) OCR ошибок, также добавил инфо про уроки по Бейсику и
заменил таблицу цветов в операторе SCREEN и ещё добавил дополнительное инфо по команде COLOR.
скачать здесь
https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1191025&viewfull=1#post1191025
Improver
16.01.2024, 13:23
metamorpho, в главе "Некоторые важные моменты" заметил такую фразу:
Имя загружаемой программы ограничено до 11 символов, остальные игнорируются.
В описании CLOAD указано ограничение в 6 символов, но, насколько я помню, на самом деле имя может быть до 127 символов, и при чтении выводится полностью, как было до этого записано, т.е. не игнорируется. А при явном задании имени при чтении по команде CLOAD "<имя>" можно задать только первые несколько символов, тогда будет загружена первая запись с совпадающим началом названия.
Есть ограничение программы Монитор-Отладчик при чтении данных, записанных в Бейсике по BSAVE, там да, до 11 символов, хотя сам Бейсик нормально принимает в BLOAD до тех же 127, но Монитор не игнорирует имена больше 11 символов, а выдаёт ошибку... Или указанное ограничение относятся к программам-конверторам в bas и cas?
И ещё, в "Разном полезном":
Функция @ преобразует dec->hex. <...>
Эта функция явно указана в описании команды PRINT, если что...
Имя загружаемой программы ограничено до 11 символов, остальные игнорируются.
Это касается модернизированных бейсиков начиная с 2.98.
Improver
17.01.2024, 09:01
Это касается модернизированных бейсиков начиная с 2.98.В таком случае хорошо бы указать, что "Некоторые важные моменты" относятся к 2.99, чтобы не было путаницы, а лучше привести все отличия и изменения 2.99 по отношению к 2.5 тамже, где ссылка на 2.99.
З.Ы. Я использую 2.891, если что... :)
metamorpho
20.01.2024, 22:53
Очередное обновление "Нового описания Бейсика". Ещё понаходил (и подсказали) несколько ошибок OCR, также привёл в порядок (выровнил) кавычки и некоторые строчки, а то они всякие разные были. Сделал (по совету) для примеров кода моноширинный шрифт, однако мой PDF вьювер отображает их некорректно (кернинг - расстояние между символами нарушается буквы слипаются), я так и не понял почему поэтому сделал откат и вернул старый шрифт.
скачать здесь
https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1191025&viewfull=1#post1191025
svofski нашел еще один трассировщик лучей (https://gabrielgambetta.com/zx-raytracer.html), а я адаптировал. Время рисования за счет оптимизации и использования 2.991 сократилось с 17+ часов на спеке до 4 часов 45 минут на векторе. Нельзя сказать, что это однозначный шаг вперед по сравнению с сферами (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1190238&viewfull=1#post1190238). Там отражения и при более низкой сложности картинка (на мой субъективный взгляд) получается круче. Зато у этого трассировщика за счет выбора цветов и штатного дизера большой потенциал портирования на разные компы (со сферами намного сложнее). Для примера портанул еще и на корвет.
80227
Upd 18.02.2024: rt9v06c - время рисования сократилось до 4 часов 3 минут (basic 2.991), картинка не изменилась.
Upd 16.03.2024: rt12v06c - 3 часа 23 минуты 10 секунд (в 2.993)
Еще изменил дизер. Слева старый, справа новый.
8022680511
Upd 03.05.2024: rt14v06c - 3 часа 17 минут 31 секунда (в 2.995)
Upd 20.05.2024: rt15v06c
2.5 - 8 часов 33 минуты 39 секунд
2.891 - 7 часов 4 минуты 2 секунды
2.995 - 3 часа 9 минут 44 секунды
2.996 - 2 часа 56 минут 37 секунд
Все уже было - трассировщик(и) (https://www.cpc-power.com/index.php?page=detail&num=19283) для амстрада cpc. Сферы с отражениями, шахматное поле - явно источник вдохновения был то же, что и у меня.
Почитал, что пишут умные люди и оптимизировал трассировщик без отражений (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1193499&viewfull=1#post1193499) (только векторовскую версию, корветовскую можно оптимизировать по аналогии).
А вот еще (https://mastodon.me.uk/@coprolite9000/111762131524979212) сферы с отражениями и шахматной доской на bbcbasic. Получается как минимум на 3х 8-битках есть подобная штука: CPC, BBC и 06Ц.
Один из вариантов, как в крайнем случае сэкономить немного памяти. Если в игре элементы игрового поля (стены, лестницы, предметы и т.д.) разных цветов, то их можно попытаться разнести в разные плоскости. Если они двухцветные, то можно одним GETом запомнить в памяти сразу 4 картинки:
1. SCREEN2,15
2. Нарисовали в одной позиции, но в разных плоскостях соответствующие картинки
3. GET
А потом когда нужно вывести один элемент - SCREEN2,1:PUT. Когда второй - SCREEN2,2:PUT и т.д. Понятно, что можно комбинировать и например 4+4 цвета или 2+8 цветов. Не очень желательно использовать это для движущихся объектов, т.к. SCREEN2 не самый быстрый оператор (но и не самый медленный).
metamorpho
25.02.2024, 16:12
вариант 1.
D=148:G=12
....
34 SCREEN 0,0,0,D,G
....
GOTO 34
вариант 2.
....
34 SCREEN 0,0,0,148,12
....
GOTO 34
Какой вариант будет выполняться быстрее ?
вариант 1.
D=148:G=12
....
34 SCREEN 0,0,0,D,G
....
GOTO 34
вариант 2.
....
34 SCREEN 0,0,0,148,12
....
GOTO 34
Какой вариант будет выполняться быстрее ?
Теоритически, 2.
Хотя там разница небольшая будет.
Второй вариант медленнее
в 2.5 на 63-71%
в 2.991 на 43-60%
- - - Добавлено - - -
Важный момент - в 2.5 первый вариант будет тем медленнее, чем позднее объявлены переменные D и G. Я протестировал самый благоприятный вариант, когда D и G - единственные переменные.
В 2.991 порядок объявления переменных на скорость доступа к однобуквенным (в данном случае D и G) не влияет.
Еще наверно стоит написать, что в обоих случаях замерял время в цикле, т.е. в первом варианте без учета D=148:G=12.
2.992 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1188493&viewfull=1#post1188493) - исправил две ошибки, одну свою и одну MS.
Прогрессивный во всех смыслах вариант сфер с отражениями над шахматной доской (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1190238&viewfull=1#post1190238).
Строит в 4 прохода.
Первые два прохода - 100% трассировка.
Потом два микропрохода по краям, которые не считаю за отдельные.
И завершают два прохода с интерполяцией, когда трассировка только если интерполятор не может сам выбрать цвет.
Время сократилось с 2 часов 57 минут до 2 часов 17 минут (в 2.992). Отличия в картинке есть, но они микроскопические и я посчитал, что ускорение на 22% более чем искупает их.
8044080441
Слева - 100% трассировка, справа - с интерполяцией.
Кроме того в таком варианте общее представление о картинке можно составить уже после первого прохода, который занимает примерно 44 минуты, а не через 3 часа.
Upd 07.03.2024: SPGIANTRTX4 - 2 часа 6 минут 7 секунд (в 2.993)
Upd 16.03.2024: SPGIANTRTX5
2.5 - 5 часов 6 минут 53 секунды
2.891 - 4 часа 12 минут 16 секунд
2.995 - 1 час 58 минут 30 секунд
2.996 - 1 час 48 минут 40 секунд
Ускорил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1195173&viewfull=1#post1195173) сферы с отражениями еще на 10 минут. Немного не хватило, чтобы выйти из двух часов, но мои способности по оптимизации на уровне программы на бейсике исчерпаны.
И от сфер бывает польза. Многократные длительные прогоны позволили выявить и исправить (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1188493&viewfull=1#post1188493) крайне редкую ошибку RETURN, которую сделал в 2.98. Кроме того немного оптимизировал несколько мелочей, в основном касающихся математики.
Тот случай, когда приятно ошибиться. Все же получилось нарисовать сферы с отражениями (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1195173&viewfull=1#post1195173) менее чем за два часа.
На этом фоне 4 часа без отражений и с дизером выглядели совсем неприлично, оптимизировал (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1193499&viewfull=1#post1193499). Еще мне не нравились шумность и излишняя яркость дизера, переделал. Речь про векторовскую версию, корветовскую не трогал.
можно ли в Бейсике (не применяя ассемблерных вставок) через OUT в порт 1 вывести синтезированную речь (возможно запретив прерывания) ?
Не через out, но теоретически нечто отдаленно похожее на речь или музыку все же можно воспроизвести штатным средством - BSAVE. Сначала загружаем звук по BLOAD, потом воспроизводим по BSAVE. Все упирается в конвертер, который должен преобразовать ИКМ в манчестер. Есть степень свободы - загрузить можно на стандартной скорости, а перед воспроизведением увеличить. Еще вариант - в бейсике-корвет частотная модуляция, можно и там попробовать.
Чтобы не засорять тему конкурса напишу пару пунктов постскриптума здесь.
1. Получилось ускорить рейкастер в 4 раза по сравнению с ретроградной версией.
В 2.5 - 2 минуты 54 секунды
В 2.993 - 1 минута 7 секунд
2. Как и в случае с GRAF5.3 нет никаких принципиальных технических ограничений для универсального варианта SpaceSt5, совместимого со всей линейкой бейсиков 2.5-2.9+. Более того, в SpaceSt5 графика 8 цветная и ее пиксельное представление в программе менее эффективно (занимает больше места), чем по плоскостям. С учетом вышесказанного и неоднократных упоминаний SpaceSt5 в конктексте несовместимости с 2.9+ я все же решил выложить универсальную версию. Если автор Андрей Ефимов против, то я конечно уберу SpaceSt5U.
Upd 3.04.2024: RCTXTFAST2
2.5 - 2 минуты 39.34 секунды
2.891 - 2 минуты 7.16 секунды
2.995 - 57.74 секунды
2.996 - 54.86 секунды
"Я хочу, чтобы картинка ожила". Черно-белая, зато можно немного повернуть налево или направо (управление курсором). Но сначала надо дождаться, пока нарисует (4 минуты 44 секунды в 2.993, 12 минут 32 секунды в 2.5).
Upd: добавил версию с автоматическими поворотами, выход по нажатию клавиши.
"Я хочу, чтобы картинка ожила". Черно-белая, зато можно немного повернуть налево или направо (управление курсором). Но сначала надо дождаться, пока нарисует (4 минуты 44 секунды в 2.993, 12 минут 32 секунды в 2.5).
А можно сделать опцию, чтобы не надо было жать клавиши, а просто качало влево вправо? Это классный эффект (wiggle stereoscopy (https://en.wikipedia.org/wiki/Wiggle_stereoscopy)).
CityAceE
02.04.2024, 21:01
ivagor, я прекрасно понимаю, что внутренняя мотивация превыше всего, но вдруг тебя хоть как-нибудь, хотя бы краешком зацепит моя идея. Ты, конечно, видишь, что я потихоньку пытаюсь развивать идею Bare Metal программирования под Raspberry Pi. Если взглянуть на Raspberry Pi под углом ретро-компьютеров, то получается очень мощная штука. Там много памяти, много мегагерцев и прочего. И там на самом деле можно программировать ровно в том же стиле, что и под КР580ВМ80А, без всяких прокладок. Я мечтаю о том, чтобы туда прямо под голое железо адаптировать тот самый BASIC. Крохотная железяка, которая после включения тут же готова к работе, и на которой можно писать на BASIC, как тогда, а программы типа RCTXT будут отрабатывать за секунды! Для работы в этом направлении не требуется реальное железо, достаточно QEMU. Но если нужно реально железо, то я готов его оплатить тебе его. Хотя мне почему-то кажется, что у тебя и так есть Raspberry Pi, и не одна... Готов помогать всем, чем только смогу. Надеюсь, что кто-то ещё подтянется.
А можно сделать опцию, чтобы не надо было жать клавиши, а просто качало влево вправо?
Я выбирал между ручным и автокачем, и волевым решением выбрал ручное, не попробовав авто. И зря, оказалось (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1196526&viewfull=1#post1196526) довольно неплохо.
CityAceE, спасибо за такой щедрый аванс доверия, но ты агитируешь не того человека. У меня лежат мертвым грузом некоторые железки, но "малинок" нет и нет опыта работы с ними. Когда нужно много мегагерц мне хватает обычного настольного компа, сейчас нет каких-то особенных интересных задач требующих bare metalа.
И зря, оказалось довольно неплохо.
Кайф!
CityAceE
03.04.2024, 09:04
ты агитируешь не того человека
Спасибо за ответ! Он был, конечно, ожидаем... Но не попытаться я не мог ;) Я, безусловно, понимаю, что дело тут не в отсутствии железяки или опыта работы с ней. В первую очередь нужен личный интерес. А его навязать невозможно... Но время идёт, интересы приходят и уходят. Буду тешить себя надеждой, что когда-нибудь по какой-нибудь причине тебя сможет заинтересовать bare metal на "малинке".
"Я хочу, чтобы картинка ожила". Черно-белая, зато можно немного повернуть налево или направо (управление курсором). Но сначала надо дождаться, пока нарисует (4 минуты 44 секунды в 2.993, 12 минут 32 секунды в 2.5).
Upd: добавил версию с автоматическими поворотами, выход по нажатию клавиши.
А если подправить палитру, то получится две картинки, но с "карасно-зелёными" очками... почти стерео... не очень правильное, но стерео. ;)
А если подправить палитру, то получится две картинки, но с "карасно-зелёными" очками... почти стерео... не очень правильное, но стерео.
Если нацеливаться на анаглифные очки, то как вариант четные строки надо рисовать одним цветом, нечетные - другим. И могу ошибаться, но мне навскидку кажется, что для стерео придется перенести ось вращения с наблюдателя в сцену.
- - - Добавлено - - -
А с затворными очками слишком сложно, надо синхронизироваться с разверткой вектора и частота кадров слишком низкая.
Если нацеливаться на анаглифные очки, то как вариант четные строки надо рисовать одним цветом, нечетные - другим. И могу ошибаться, но мне навскидку кажется, что для стерео придется перенести ось вращения с наблюдателя в сцену.
А с затворными очками слишком сложно, надо синхронизироваться с разверткой вектора и частота кадров слишком низкая.
Для затворных очков свои просмотрщики/вьюверы, я о них не говорил.
Для простых анаглифных очков, с примитивными картинками, достаточно трёх цветов: красный, синий (или зелйный) и их смесь.
В данном случае, так как каждая из картинок в своей плоскости, с цветами вообще нет проблем, только палитру поправить.
А вот почему я сказал, что "почти стерео", это именно из-за отсутствия смещения для "оси вращения" как ты выразился.
Говоря по другому, картинки должны быть с разных точек наблюдения в сцену, как ты выразился :)
И если смещение будет, то "стерео" будет настоящим, даже при использовании всего трёх цветов.
У меня когда-то была инструкция, как на бумаге рисовать стерео картинки, красным и синим карандашами. Если объект нарисован с разных точек наблюдения, то получается "вау-эффект". :)
И могу ошибаться, но мне навскидку кажется, что для стерео придется перенести ось вращения с наблюдателя в сцену.
А как сейчас? Мне кажется, что для стерео важна не ось вращения, а положение камеры и точка, куда она смотрит. Смотрим всегда в одну точку, но смещаем голову влево-вправо.
А как сейчас? Мне кажется, что для стерео важна не ось вращения, а положение камеры и точка, куда она смотрит. Смотрим всегда в одну точку, но смещаем голову влево-вправо.
Для одного глаза (без смещения точки обзора) настоящего стерео - не получится :(
На объект нужно смотреть двумя глазами - с разных точек обзора, тогда получается стерео.
Для одного глаза (без смещения точки обзора) настоящего стерео - не получится :(
На объект нужно смотреть двумя глазами - с разных точек обзора, тогда получается стерео.
Я именно это и предложил. Двух глаз нет, зато мы можем двигать камерой, занимая по очереди положение каждого глаза. Есть даже небольшое преимущество -- не надо ограничиваться двумя глазами.
А как сейчас? Мне кажется, что для стерео важна не ось вращения, а положение камеры и точка, куда она смотрит.
"Ось вращения" включает в себя положение камеры и направление съемки или взгляда. Тут вопрос привычности, понятности и удобства описания. А сейчас стоим в одном месте и только поворачиваем голову.
Мне, честно говоря, стерео не особо интересно, тут карты в руки кому-нибудь другому.
Получилось разогнать рейкастер (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1196484&viewfull=1#post1196484) быстрее минуты. Осталось ускорить всего лишь в 57 раз и будет 1 FPS.
CityAceE
03.04.2024, 21:24
Получилось разогнать рейкастер быстрее минуты.
А разогнанную Специалистовкую версию стоит ждать?
Надо признать, что ускорения в разы без упрощения картинки уже не будет. Но есть символические рубежи. Например на специалисте интересно было бы выйти из 3 минут. Если получится, то я такой версией конечно похвастаюсь.
CityAceE
04.04.2024, 18:50
на специалисте интересно было бы выйти из 3 минут.
А с чем связана такая низкая скорость на Специалисте по сравнению с Вектором? Неужели только из-за более низкой таковой частоты процессора? Или там ещё и сам Бейсик существенно более тормозной? Хотя вроде прародитель один и тот же.
Для специалиста нет быстрого бейсика. А если сравнивать не с 2.993, а с классическим 2.5, то должен возникнуть вопрос, а почему вектор выигрывает меньше, чем разница в скорости процессоров. Тут несколько причин: оптимизация RCTXTFAST2 в основном для 2.993 (очень хотелось нарисовать меньше чем за минуту), несколько более медленные умножение и деление, а также ограниченная поддержка 16-ричных (последние пункты - тяжелое наследие микрона).
Я упустил важный фактор, который играет в пользу 2.5 - сравнительно быстрое рисование линий, у специалистовского бейсика оно на удивление медленное, хотя битплан один вместо 4. Скорее всего оптимизацией специально для 2.5 можно довести разрыв класических бейсиков примерно до разницы в скорости процессоров, но в версии специально для 2.5 нет смысла.
CityAceE
05.04.2024, 14:16
А не существует ли готового разобранного дизассемблера исходного Бейсика? Чтобы можно было гурьбой накинуться, оптимизировать, добавить все недостающие команды, которые появились уже у нас в разных компах. Ну и адаптировать под все нужные платформы. То есть чтобы можно было его дорабатывать, а собирать под разные платформы. И чтобы совместимость была на каком-то уровне между друг другом.
Существуют
http://altairbasic.org/ (или без подробностей https://github.com/option8/Altair-BASIC)
или доработанный вариант http://www.nascomhomepage.com/lang/8kbasic.asm
Есть очень простой вариант использования микрософтовского компилятора BASCOM в сочетании с графикой (правда специфической - ч/б высокого разрешения) - надо запускать откомпилированную программу в CP/M-39 (https://caglrc.cc/scalar/ware/667/). А для вывода графики используем POKE в диапазоне &HA000-&HDFFF. Вариант очевидный и простой, но неудобный, наверно поэтому таких программ не написали. Но надо отметить, что при использовании целых компилятор покает весьма шустро.
Попутно выяснил, что МикроДОС 28 (https://caglrc.cc/scalar/ware/669/) при наличии (и только при наличии!) кваза прячет видео под него, как и "обычные" досы.
Я тут подумал - а зачем откомпилированной BASCOMом программе дос, если она не пользуется его возможностями? И действительно, берем откомпилированную программу после этапа инициализации, меняем два байта начального перехода и все, можно запускать из начального загрузчика (дос или эмуляторы дос или кваз не нужны, только голый вектор!). Чтобы запускать из любого окружения, а не только из начального загрузчика, надо добавить программирование палитры, но для чистоты эксперимента я не стал.
В качестве подопытной программы выступил многострадальный рейкастер. После почти полного перевода на фиксированную точку текстуры стен несколько расколбасило, зато рисует за 32.3 секунды. И таким макаром можно пользоваться BASCOMом не только для вектора.
Хорошая новость - svofski недавно завел в картотеке карточки для бейсиков 2.891 (https://caglrc.cc/scalar/ware/909/) и 2.99x (https://caglrc.cc/scalar/ware/940/), за что ему большое спасибо!
Теперь про 2.994 (финал ветки 2.99x, если не найдутся ошибки). Начиная с 2.98 заменил рисование линий на быструю и компактную процедуру. Но у этой процедуры есть недостаток - она рисует "стандартные" линии, а в 2.5 (и до 2.97 включительно) при маленьких наклонах было нечто нетрадиционное. И некоторые программы пользуются своеобразием линий при маленьких наклонах, поэтому скрепя сердце решил вернуть линии в духе 2.5. Максимально оптимизировал по сравнению с 2.5, но все равно нормальным линиям несколько уступает.
Для "старых" линий не хватало места, поэтому пришлось поджать и микроскопически замедлить (в некоторых случаях) умножение. Замедление (там где оно есть) порядка долей процентов, невооруженным взглядом незаметно.
Если все будет хорошо, то планирую начать ветку 3.x, где наконец уберу все, что считаю лишним (принтер, RENUM), верну быстрые линии и умножение, сделаю некоторые оптимизации.
Извините, еще одна версия в ветке 2.99x (https://caglrc.cc/scalar/ware/940/)
Началось с того, что полез проверять высказанное на стриме конкурса предположение, что вывод листинга с длинными строками, вызывающими переполнение, приводит к порче бейсика. У меня не получилось испортить бейсик длинными строками и не придумал, как это сделать, если у кого-то получилось, то напишите, постараюсь разобраться и исправить. Зато заметил, что в отличие от 2.5 в 2.9+ не получается редактировать и выводить на листинг без сообщения о переполнении строки по 127 символов. Сейчас авторы набирают и редактируют тексты вне бейсика (и получаются строки по тысяче символов), поэтому никто не замечал, поправил этот момент.
Дальше больше, заметил, что можно сократить фрагмент связанный с автоповтором на несколько байтов, потом еще нашел что оптимизировать по размеру. В итоге вернул скорость умножения на уровень 2.993. И линии немного ускорил, но до показателей нормального Березенхэма не дотянуться. Так и не нашел, в отличие от CIRCLE, откуда авторы 2.5 позаимствовали такие своеобразные линии.
Посмотрел, как lafromm31 проходил CORPSE и под впечатлением попробовал оптимизировать рисование уровней. Время рисования заставки и первого уровня сократилось с 24-25 секунд до 15 секунд. Полное прохождение модифицированной игры не проверял, прошел только два уровня. Если автор против, то уберу этот вариант.
Upd 17.05.2024: CORPSEfld2, совместимость процедуры опроса клавиатуры с бейсиками >=2.98
Вычислениями в бейсике никто особо не увлекается, но с исторической точки зрения может быть интересно. Оказывается в вариациях микрософтовского basic8k крайне неэффективно реализованы преобразования десятичных дробей и экспоненциальных форм из символьного представления в двоичное. Положительные степени (например 1E10) побыстрее, а вот дроби (например 1.23) и отрицательные степени (например 1E-10) совсем плохо. Крайний клинический случай это когда длинная дробь с близкой к максимуму отрицательной степенью, например 1.2345678E-38. В 2.5 время преобразования такого числа - 0.2 секунды! И это на одно число, т.е. в секунду можно сделать всего 5 таких преобразований. Рецепт лечения тут один - если подобные константы активно используются, например в цикле, то надо до цикла поместить их в переменные. И у меня есть пример на эту тему - трассировщик с дизером (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1193499&viewfull=1#post1193499), там в двух местах использовалась константа 1E10. После переделки на переменную ускорение на 6 минут.
Посмотрел ролик про БК и мне там понравилась "объемная" синусоида на бейсике (https://youtu.be/glMUOe7UR6I?t=906). Сначала повторил в бейсике-корвет (http://caglrc.cc/scalar/ware/96/), а потом подумал что с цветом лучше и сделал для 2.5+. Рисует быстро, 13.9 секунды в 2.5 или 7.1 секунды в 2.995
Бейсики 2.5+ унаследовали от РКшного микрона неприятную особенность - после печати каждых 128 символов (если в конце PRINT стоит ";") происходит непрошеный перевод строки. А svofski нашел, когда это приводит к ошибке, но тот случай легко правится на уровне программы на бейсике. В качестве примера приложил простейшую программу, которая печатает "лабиринт" (на C64 (https://youtu.be/B-Cky_2l11U?t=34) гораздо больше похоже на лабиринт, т.к. там символы могут занимать все знакоместо без зазоров по горизонтали и вертикали). Если хочется без паразитных переводов строки, то можно попробовать эту программку в Basic-M (https://caglrc.cc/scalar/ware/470/)
Это не все неприятности, касающиеся печати символов на экране. Дальше вспомнил, что функция POS() не соответствует описанию. Она не дает позицию курсора в строке, она возвращает номер напечатанного после перевода строки символа по модулю 128. Совпадение с позицией курсора будет при выполнении условий:
1. Был перевод строки и после этого печать с начала строки.
2. Напечатано не более 42 символов.
Это уже недоработка Темиразова и Соколова при адаптации микрона на вектор, в оригинальном РКшном POS() работает правильно. Проблема усугубляется тем, что авторы бейсика 2.5 в паре мест сами используют эти данные как горизонтальную позицию курсора.
В одном месте от РКшного бейсика-микрон осталась проверка которая не работает на векторе, т.к. не поменяли 64 символа в строке на 42.
В другом, там где обрабатывается запятая в PRINT, поменяли, но не совсем правильно.
Совокупность перечисленных причин приводит к довольно своеобразному "паттерну печати" при активном выводе символьной и числовой информации на экран с использованием разделителей "," и ";". Даже не знаю, стоит ли все это править в 2.9+ или считать все это фичами, а не багами. Или оставить доработки до гипотетического 3.0.
И еще нашел ошибку в 2.995 - не совсем корректно обрабатывается клавиша F5, это поправлю.
metamorpho
06.05.2024, 18:04
....Даже не знаю, стоит ли все это править в 2.9+ или считать все это фичами, а не багами. Или оставить доработки до гипотетического 3.0.
.....
На мой взгляд - пусть баги остануться фичами.
Ждём Бейсик 3.0 - версия без оглядки на совместимость со всеми предыдущими версиями :)
3.0 - версия без оглядки на совместимость со всеми предыдущими версиями
Настолько экстремально все же не будет, считаю очень важным, чтобы классические программы работали. Пусть будут мелкие непринципиальные отличия в каких-то моментах, но от базы векторовских программ на бейсике отказываться никак нельзя.
Вот кстати один из спорных для меня вопросов - линии.
Слева "векторовская классика", справа - вариант который был с 2.98 по 2.993
8076780768
Большинство бейсиков (да и практически все графические библиотеки) рисуют как справа. Но в некоторых классических векторовских программах своеобразные линии используются. Значимый пример - РЕКЛАМА, там можно заметить отличия на рисунке "киберзверя" ("киберволка"?). В disaster PPC тоже заметны различия в рисунке космического корабля. И пока полностью не определился, что важнее - сохранить идентичность рисунков или выиграть в скорости и размере процедуры.
Пара слов про компилятор. Компилятор специально для 2.5+ скорее всего не будет написан никогда, но есть другой путь, чуть более реальный. Теоретически можно научить BASCOM переваривать векторовские программы. Для этого нужны 2 вещи:
1. Ассемблерная библиотека для BASCOM с поддержкой графики и музыки.
2. Препроцессор, который берет текстовый файл программы для 2.5 и меняет там графические и музыкальные операторы и функции на вызовы вышеупомянутой библиотеки.
На оригинальность не претендую, просто надеюсь, что написанное подтолкнет кого-нибудь к практическим действиям в данном направлении (необязательно для вектора, для любого компа с 8080).
Improver
08.05.2024, 07:55
Пример подобной конструкции, кмк: ЛС-Паскаль (https://caglrc.cc/scalar/ware/97/).
Теоретически, можно даже написать некий конвертор из бейсика в p-код и использовать компилятор Паскаля.
Задачи могут быть разные, но для быстродействия конверсия в p-код ничего хорошего не даст. Вот если конвертировать бейсиковские исходники в паскалевские (или сишные) исходники и потом нормальным компилятором получать машинный код, то это другое дело. Это обобщение того, что я написал, просто конвертировать исходник 2.5 в BASCOM проще, чем в Паскаль или Си.
...Теоретически можно научить BASCOM переваривать векторовские программы. Для этого нужны 2 вещи:
1. Ассемблерная библиотека для BASCOM с поддержкой графики и музыки.
...
Я думал, что "Драйверы устройств" - это ассемблерная библиотека графики, музыки и всего прочего.
Или для BASCOM нужно что-то особенного?
Проблемы две:
1. Драйверы устройств располагаются по тем же адресам, что и родная runtime библиотека BASCOM.
2. Нужно так или иначе обеспечить интерфейс, чтобы из BASCOM можно было вызывать нужные процедуры.
Добавил CORPSE в свой набор бенчмарков, соответственно стал часто запускать и заметил, что изредка на экране появляются странные черточки. После этого можно много раз запускать и ничего не будет, а потом вдруг снова. Расследование показало, что опрос клавиатуры baskeysCorrected2 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1173576&viewfull=1#post1173576) не полностью совместим с версиями бейсика начиная с 2.98 (особенности обработчика прерываний), извините. Проблема косметическая, бейсик не ломается, но все равно неприятно и так оставлять нельзя. Сделал новый вариант, который совместим со всей линейкой от 2.5 до 2.9+. Машиннокодовая процедура на 3 байта длиннее (стартовый адрес изменился!), а бейсиковский загрузчик оптимизировал, он компактнее. CORPSEfld доработал (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1197933&viewfull=1#post1197933), но потенциальная проблема касается и других игрушек, например VITAMINO, поэтому надо или запускать их в бейсиках <2.98 или заменить процедуру опроса. Рекомендую все же заменить, в 2.98 много важных оптимизаций (по количеству и качеству изменений это скорее 3.0), предыдущие версии заметно медленнее. На примере CORPSE (время от RUN до строки 315, инициализация+заставка):
2.891 - 59.6 секунды
2.97fix - 45.6 секунды
2.98fix/2.995 - 29.4 секунды
CORPSEfld2:
2.891 - 45.3 секунды
2.97fix - 35.5 секунды
2.98fix/2.995 - 19.5 секунды
2.996 - 17.6 секунды
Скорость бейсика конечно сказывается не только на инициализации и рисовании уровня, но и на скорости движения героя и отзывчивости управления. С 2.5 не сравнил, т.к. в нем очень ограниченная поддержка шестнадцатеричных и пришлось бы дорабатывать CORPSE для совместимости. Смысла в такой доработке нет, даже в 2.891 слишком медленно, в 2.5 было бы просто невыносимо.
Ускорил дизернутый трассировщик (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1193499&viewfull=1#post1193499) до упора. Все ради любви к круглым цифрам и новой версии бейсика, в которой будет рисовать меньше чем за 3 часа.
В штатном описании 2.5 для функции RND приведен только один вариант вызова - RND(1)
Из дизассемблера или описаний микрософтовских бейсиков можно узнать полный набор вариантов того, как влияют аргументы RND:
1) >0 - генерация нового псевдослучайного числа
2) =0 - повторение предыдущего
3) <0 - рестарт псевдослучайной последовательности с RND SEED зависящим от аргумента
Особый интерес представляет случай 3, т.к. в 2.5 (как и во всех клонах msbasic 8k) нет оператора RANDOMIZE, позволяющего задать RND SEED.
Первое число последовательности при вызове с аргументом <0 получается так (это справедливо для аналогов микрософтовского 3.2, в более новых версиях они изменили генератор и инициализацию):
1. Меняются местами старший и младший байт мантиссы аргумента
2. Результат всегда будет положительный и после нормализации диапазон (0,1]
Пара примеров близких к границам диапазона:
1) RND(-16777215) - последовательность начнется с 1.
2) RND(-1) - последовательность начнется с 7.65943E-06. Можно получить чуть-чуть меньшее значение, если делить аргумент на степени двойки. На первый элемент это повлияет очень слабо, но на следующие сильно.
2.995fix и 2.996 в картотеке (https://caglrc.cc/scalar/ware/940/).
2.996 - это ребрендинг 3.0, посчитал что не тянет на смену главной цифры, но отличий не так уж мало и ускорение во многих тестах заметное. Кое-что из 2.996 удалил, поэтому 2.995fix тоже остается. Полный список изменений в readme или проще почитать прямо в карточке базиса. Прокомментирую отдельные моменты касающиеся 2.996:
1. В качестве утилиты для ренумерации можно использовать 2.891 или 2.995fix.
2. Линии оставил "классические", но немного ускорил.
3. Ну и самое интересное для меня, результаты бенчмарков:
Пустой цикл (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938)
ANTIGRAV (стартовое рисование уровня) (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1176034&viewfull=1#post1176034)
Пробегание от левой стены до правой в PROVERKA и взлет ракеты в ANTIGRAV (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1178652&viewfull=1#post1178652)
Rugg/Feldman benchmarks (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1179408&viewfull=1#post1179408)
Решето Эратосфена (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)
Медленный Мандельброт (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1188980&viewfull=1#post1188980)
Трассировщик с дизером (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1193499&viewfull=1#post1193499)
Трассировщик с отражениями (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1195173&viewfull=1#post1195173)
Рейкастер (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1196484&viewfull=1#post1196484)
CORPSEfld2 (инициализация+заставка) (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1199163&viewfull=1#post1199163)
В 2.5 нет оператора (в MSX BASIC называется SOUND) который позволяет задавать произвольную частоту канала таймера, но это вполне можно сделать через OUT. С таким подходом вектор становится настолько могуч, что может на бейсике изобразить нечто похожее на спековский биперный движок phaser1 (basphas) или на Новикова (автора Fatax, Eraser и т.д.). Или можно накрутить звуковые эффекты. А можно глиссандо (basglis), но тут очень зависит от скорости бейсика, причем разница даже между 2.995 и 2.996 слышна невооруженным ухом. Это еще одна потенциально сильная сторона вектора, которая не была раскрыта, надеюсь на конкурсе или вне конкурса кто-нибудь попробует использовать.
Так оператор BEEP же есть, вроде как аналог SOUND, или в MSX есть и BEEP? Может стоит в новом бейсике переделать оператор BEEP на таймер? или тоже добавить SOUND?
В 2.5 BEEP играет через бипер и не позволяет точно задавать частоту, там очень грубая шкала значений.
В msx есть BEEP, но на msx1 он издает один предустановленный звук через AY, а на msx 2 можно выбрать из очень небольшого числа комбинаций. Т.е. это не музыкальный оператор и тем более не для звуковых эффектов. Он позволяет подать звуковой сигнал и потом загасить каналы AY, если до этого там что-то звучало.
Что касается SOUND на msx, то признаюсь, что забыл (посыпаю голову пеплом), там фактически SOUND и есть специализированный OUT для AY. И примеры, которые я привел ранее, можно считать именно повторением концепции использования SOUND на msx.
Если говорить про новые операторы и функции, то оглядываясь назад я бы кое-что добавил. Просто не думал, что будет написано несколько новых очень хороших программ/игр на бейсике, в которых эти операторы или функции могли бы использоваться. Как минимум надо было добавить функцию для прямого опроса клавиатуры без буферизации. Но не все так плохо, дополнительные возможности (в т.ч. и звуковые) в бейсик можно вводить и с использованием машиннокодовых подпрограмм.
Пользуясь случаем спрошу - чего сильно не хватает в бейсике (кроме скорости)?
metamorpho
06.06.2024, 15:25
.......Как минимум надо было добавить функцию для прямого опроса клавиатуры без буферизации. Но не все так плохо, дополнительные возможности (в т.ч. и звуковые) в бейсик можно вводить и с использованием машиннокодовых подпрограмм.
Пользуясь случаем спрошу - чего сильно не хватает в бейсике (кроме скорости)?
Сильно не хватает - нового Бейсика-компилятора :)
Конечно все дополнительные возможности в Бейсике можно сделать с использованием машиннокодовых подпрограмм.
Поэтому хотя сильной необходимости и нету, но было бы неплохо в состав команд существующего Бейсика внедрить что-то из следующего:
- опрос клавиатуры без буферизации [KEY]
- [SOUND] примерно как в MSX
- установка/сброс, инверсия,сдвиг, чтение битов переменной [BITS переменная,режим,(двоичное число наложения)]
- распаковщик (упаковщик вне Бейсика отдельной утилитой) [READZIP 2000:UNZIP адрес куда распаковать]
строка № 2000 "4jrfkfjwefjwofjowjfwjklf0t45kttg94jutg4w897854huh. ..."
- запомнить кадр анимации с экрана [READKADR номер кадра,X,Y,размер по X, размер по Y,режим плоскостей(сколько использовать 1-4)]
- или инициализировать кадр анимации, чтобы при выводе кадр читался прямо из кода программы на Бейсике
например строка № 3000 "41947093280289357935748978936489726789346934853485 03458034...."
первые три байта строки: размер по X, размер по Y,режим плоскостей(сколько использовать 1-4)
[INITKADR номер строки, номер кадра]
- вывод покадровой анимации [ANIMATOR номер кадра,X,Y,режим вывода (с наложением и без)]
Сильно не хватает - нового Бейсика-компилятора
Увы, это я не потяну. Самое близкое, что могу посоветовать из компиляторов (правда си), поддерживающих вектор - z88dk (https://github.com/z88dk/z88dk). Поддержка векторовского железа там очень ограниченная.
Для сильных духом еще есть микрософтовский BASCOM, но там придется всю векторовскую поддержку писать на асме самостоятельно.
От себя могу пообещать только еще чуть ускоренный интерпретатор, правда пришлось кое-чем пожертвовать.
- опрос клавиатуры без буферизации [KEY]
Самое близкое, что сейчас есть - baskeysCorrected3 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1199163&viewfull=1#post1199163). Встроенная в бейсик функция была бы удобнее, но функционально baskeys вполне заменяет.
- [SOUND] примерно как в MSX
Как уже упомянул в предыдущем своем посте, описанный здесь (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1199878&viewfull=1#post1199878) вариант использования OUT является функциональным аналогом SOUND в msx basic.
И, кстати, подобным образом можно играть и через AY, что уже будет являться полным аналогом msx.
Другое дело, что хотелось бы большей функциональности и большего удобства.
распаковщик (упаковщик вне Бейсика отдельной утилитой)
Если подгружать файл по BLOAD и потом запускать по USR, то можно использовать любой существующий для вектора распаковщик.
Для анимации можно написать небольшую процедуру на ассемблере. Само по себе это не сложно, но надо обдумать как удобнее организовать интерфейс с программой на бейсике.
Привет всём...
На Спектруме есть компилятор - MCoder2...
На нём даже коммерческие игры составляли
на Basic' e...
Atlantis Software, например...
И небольшой он, 5 - 7 кБ...
???
- установка/сброс, инверсия,сдвиг, чтение битов переменной [BITS переменная,режим,(двоичное число наложения)]
В первый раз пропустил этот пункт.
Установку/сброс, инверсию и чтение битов переменной можно делать с использованием AND, OR и NOT. Но будет не очень удобно и не быстро.
Вместо сдвигов начиная с 2.98 сделал очень быстрое умножение степеней двойки (в т.ч. дробных) на число и деление на степени двойки (включая дробные). В 2.996 с аналогичной скоростью можно и умножать на степени двойки. И отдельный оператор или функция тут не помогут, эти операции для чисел с плавающей точкой уже выполняются на максимальной скорости.
- - - Добавлено - - -
степеней двойки (в т.ч. дробных)
Уточню, что собственно степени любые целые (положительные и отрицательные), а результирующие числа при отрицательных степенях получаются дробные.
Например:
1) Cдвиг влево на один разряд 2*A. Через деление тоже можно, но через умножение тут быстрее.
2) Арифметический сдвиг вправо на один разряд .5*A или A/2 (2^-1=.5)
3) Сдвиг влево на 3 разряда 8*A
4) Арифметический сдвиг вправо на 4 разряда .0625*A или A/16 (2^-4=.0625; 2^4=16)
Сказал А про SOUND в MSX, надо и Б сказать. Можно найти примеры звуковых эффектов для AY с использованием MSX BASIC и их легко повторить на векторе (конечно при наличии AY).
Меняем
SOUND RN,DT
на
OUT21,RN:OUT20,DT
и вперед.
Из книги
Блэнд Г. Основы проограммирования на языке БЕЙСИК в стандарте MSX. Москва, "Финансы и статистика", 1989
взял пример со страницы 122.
Процедура двухцветной анимации. Я склонился к подходу Волкова (автора Специалиста). Трактуем всю память как графику, 256 столбцов высотой 256 точек. Вместо GET/PUT используем копирование прямоугольного фрагмента из источника в место назначения. Надеюсь что из описания и примера использования все станет понятно. Замечу, что можно как в примере рисовать исходные картинки на экране, а можно задавать их в памяти и вне экрана (через POKE или BLOAD). И конечно можно грузить в экран по BLOAD. В примере исходные картинки видны, но возможно в другой программе будет иметь смысл скрыть их палитрой в отдельной плоскости.
Рисование функции на базе статьи из журнала Байтик 91/3, стр. 4-6.
В примере использовал десятичные константы, но если хочется побыстрее и не важна совместимость с 2.5, то предпочтительнее шестнадцатеричные. Ну и в примере для наглядности константы типа 224+24, для скорости лучше использовать готовую сумму.
Можно сделать процедуру и для 4 цветов.
Для 16 или 8 цветов в бейсиках 2.9+ как мне кажется лучше использовать GET/PUT (для фрагментов с шириной кратной 8 точек).
ivagor, заметил глюк в последних версиях бейсика (в 2.993 еще нормально), моя программка некорректно рисует овалы. Похоже в операторе CIRCLE есть ошибка.
Прикладываю саму прогу, ошибка возникает в строке 500, я прогу немного подправил чтобы сразу на кусок кода где ошибка выходила.
Вероятно дело в рисовании линий, постараюсь в понедельник разобраться.
- - - Добавлено - - -
Последняя версия, в которой правильно - 2.994, в крайнем случае на нее можно будет откатиться.
Похоже в операторе CIRCLE есть ошибка.
Все же успел вчера найти и поправить - ты прав, в 2.995 и 2.996 ошибка в CIRCLE.
В микрософтовских бейсиках в целом и в вариантах векторовского 2.5 в частности есть три варианта условных переходов:
1. IF ... THEN номер строки
2. IF ... GOTO номер строки
3. IF ... THEN GOTO номер строки
Вариант 3 очевидно самый неудачный, т.к. самый медленный и на байт длиннее. Из оставшихся в 2.5 вариант 2 немного быстрее, но в векторовских программах (даже в кишиневских) он не используется, поэтому в новых бейсиках IF ... THEN будет немного быстрее, а IF ... GOTO может даже уберу, если не найдутся примеры использования.
Ну и немного про новые грядущие бейсики.
2.997 - это 2.995 с исправлениями и даже небольшими дополнениями и оптимизациями.
Вместо 2.996 будет отдельная ветка бейсиков, с предварительным названием rtbasic. По сравнению с 2.996 пока два наиболее крупных отличия:
1. Убрал текстовые сообщения об ошибках, вместо них номера и файлик с соответствиями номеров и ошибок. При очень большом желании его можно распечатать.
2. Это позволило встроить в бейсик убиратель незначащих пробелов. Соответственно упрощен и ускорен парсер.
metamorpho
18.06.2024, 23:31
2 CLEAR:SCREEN 2,15:CLS:SCREEN 3,255,255,255,255,255,255,255,255
4SCREEN 0,0,0,253,0,0,0,0,0,0,0,0,0,0,0,0,0,16:COLOR 1,16,15
24 SCREEN 2,1:COLOR 1:PLOT 0,0,2:LINE 255,255,BF
60FOR H=0 TO 255:COLOR 0:PLOT 0,H,2:LINE 255,H:NEXT H
77GOTO 77
Почему-то не стирает нулевую точку. Это ошибка или я что-то напутал ?
PLOTX,Y,2 только перемещает графический курсор. В данном случае можно двумя вариантами стереть
1. В строке 60 изменить PLOT0,H,2 на PLOT0,H,1
2. В строке 60 изменить PLOT0,H,2 на PLOT0,H,0 и тогда еще можно убрать COLOR0, т.к. режим 0 и так стирание.
metamorpho
19.06.2024, 13:06
PLOTX,Y,2 только перемещает графический курсор.....
И всё же непонятно почему вариант PLOT 0,Y,2 не стирает, ведь по идее курсор перемещён в нулевую точку и рисование должно начинаться именно с неё, а оно начинается с точки 1.
Это особенность реализации LINE в 2.5, рисование линии не затрагивает текущую точку, на которую указывает графический курсор. В других бейсиках оператор LINE бывает с возможностью задания и начальной и конечной точки. Например в бейсике-корвет LINE(0,0)-(1,0) нарисует 2 точки.
Можно предположить почему так сделали. Или просто попытаться найти в этом пользу. Когда рисуем несколько линий встык экономим на "стыковых" точках (рисуем их по одному разу, а не по два).
Насчет третьего параметра PLOT - он действует и на следующие PLOT, поэтому когда как в приведенном примере много раз PLOT с одинаковым режимом имеет смысл один раз задать его (до цикла), а в цикле использовать уже без третьего параметра. Так будет чуть быстрее и компактнее.
Неофициальная (несогласованная с организаторами) микрорекламка летнего РЕТРОГРАДА 2024 (https://zx-pk.ru/threads/35752-retrograd-leto-2024-konkurs-programm-dlya-vektor-06ts.html). Работает и в 2.5, но в новых бейсиках и картинку быстрее нарисует и стыки между фрагментами музыки гораздо менее заметны.
Upd 22.06.2023: Версия 2.
1. Быстрее рисует буквы и они точнее отцентрированы.
2. Доработана музыка. Меньше задержка на стыках музыкальных фрагментов.
3. Исправлено зацикливание палитры.
metamorpho
21.06.2024, 22:50
Неофициальная (несогласованная с организаторами) микрорекламка ......
ivagor, спасибо за интересную дэмку-приглашение - сделано класно !! особенно музыка понравилась - необычное звучание :v2_thumb:
Моя дэмка-приглашение тоже на подходе - в этом месяце выложу в теме конкурса.
Кстати если дэмка-приглашение соответствует правилам сайта, то её можно выкладывать в теме конкурса без согласования с организаторами.
metamorpho, спасибо, я старался. Глянул свежим взглядом и немного доработал (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1200349&viewfull=1#post1200349).
Попутно обнаружил очередную особенность бейсика, на этот раз PLAY. Глобальное задание октавы O "маскирует" глобальное задание длительности L. Например L1O1 изменит длительность, а O1L1 - нет.
Слегка доработанный "спирограф" из недавнего видео Алексея Морозова.
metamorpho
09.07.2024, 10:02
Заметил что в эмуляторе оператор BEEP звучит тише чем оператор PLAY.
Это так и есть на реальном Векторе ? (подскажите а то я подзабыл)
На реале громкость бипера примерно равна громкости одного канала таймера. Соответственно 3 канала таймера могут звучать примерно в 3 раза громче бипера.
- - - Добавлено - - -
Уточню - суммарный сигнал 3х каналов таймера примерно в 3 раза больше сигнала бипера, но т.к. восприятие громкости звука человеком нелинейное, то громкость все же не в 3 раза выше.
Improver
09.07.2024, 14:26
Уточню - суммарный сигнал 3х каналов таймера примерно в 3 раза больше сигнала бипера, но т.к. восприятие громкости звука человеком нелинейное, то громкость все же не в 3 раза выше.Тоже уточню: сигнал с трёх каналов таймера будет в 3 раза выше только если сигналы всех каналов совпадут по фазе и частоте, обычно же разница меньше... Поэтому на слух, сигналы от BEEP и PLAY там более близки по громкости, насколько я помню, и плюс да, ещё нелинейность восприятия.
сигнал с трёх каналов таймера будет в 3 раза выше только если сигналы всех каналов совпадут по фазе и частоте, обычно же разница меньше
Мгновенные значения суммы каналов таймера от 0 до 3, но это не важно. Можно посмотреть с такой стороны: если принять размах сигнала одного канала за 1, то среднее значение в этом канале близко к 0.5, это же справедливо и для бипера (бейсик не умеет регулировать скважность и сигналы таймера и бипера близки к меандру). Среднее значение суммы трех каналов в 3 раза больше и =1.5.
- - - Добавлено - - -
Сравнивать средние значения звуковых сигналов - не лучший вариант, но в данном случае численно они равны амплитудам, что уже подходит лучше. Амплитуда одного канала (измеренная от среднего) =0.5, амплитуда суммы трех каналов =1.5. Но конечно есть нюанс, сигнал одного канала - меандр, сигнал суммы трех каналов зависит от частот и эффективные значения будут различаться, особенно если учитывать АЧХ дальнейшего тракта.
Improver
09.07.2024, 15:50
сигнал одного канала - меандр, сигнал суммы трех каналов зависит от частот и эффективные значения будут различатьсяВот и я про то же... Если в момент измерения частоты попадут так, что один канал будет в 1, а два других в 0, то общая амплитуда на выходе будет =1 (от минимума до максимума), а в другой момент может быть амплитуда =3, когда все три канала будут в 1. Т.е. при разных частотах на каналах амплитуда сигнала будет изменятся от 0 до 3 условных единиц. Громкость же определяется не одномоментно, а на каком-то времени звучания, как усреднённая, и для того, чтобы было превышение в три раза относительно одного канала бипера, надо чтобы фазы и частоты их совпадали всё это время. Нет совпадения фаз и частот -- средняя громкость будет меньше... В обычной музыке для Вектора, думаю, средняя громкость трёх каналов ВИ относительно сигнала бипера будет не больше, чем раза в полтора, что на слух малозаметно.
Чтобы не засорять тему конкурса напишу здесь.
В 2.996 нет ошибки в умножении (https://zx-pk.ru/threads/35752-retrograd-leto-2024-konkurs-programm-dlya-vektor-06ts.html?p=1201045&viewfull=1#post1201045), есть особенность преобразования дробных чисел из символьного представления в двоичное. В 2.5-2.995, как и в других микрософтовских бейсиках, при таком преобразовании каждая цифра после запятой в итоге приводит к отдельному делению на 10. Это компактный, но чудовищно медленный вариант. В 2.996 для ускорения используются деления не только на 10, но и на 100 и 1000. Так в разы быстрее, но появляется расхождение с микрософтом из-за того, что при каждом делении еще выполняется округление. Т.е. при делении 3 раза на 10 будет 3 округления, а при делении на 1000 только одно. Вариант 2.996 не только быстрее, но и точнее, т.к. лишние промежуточные округления только "портят" число.
Вернемся к RG2024LETO. Увидеть разницу в выполнении BEEP0.001 можно на таком примере PRINT INT(.001*1000)
2.5-2.995 напечатают 0
2.996 напечатает 1
2.996 точнее! Разница преобразования .001 в одном самом младшем бите мантиссы, который даже не видно при печати числа, но тут он сыграл. Отказываться от быстрого и более точного преобразования дробных чисел я не буду, но т.к. есть разница с классикой, то это еще один аргумент в пользу отделения таких бейсиков в отдельную ветку.
В юности играл в президента на бейсике. И тогда и сейчас интересно, откуда он взялся. Агатовцы пытаются (http://forum.agatcomp.ru/viewtopic.php?id=538) ответить на этот вопрос.
metamorpho
19.08.2024, 18:10
Спрошу на всякий случай :)
10 DIM M(50),MR(12)
20 M1=34:M=4:MR=123
Правильно ли я понимаю что M и MR массива никак не пересекаюся и не конфликтуют с обычными переменными M1, M, MR ?
Да, имена массивов и скалярных переменных могут совпадать, но они будут располагаться в разных участках памяти и доступ к ним будет совершенно независимый.
подскажите новичку, в бейсике можно включить режим 512 для самого интерпретатора, обычного редактирования программ ? очень нравится узкий шрифт Монитора. можно ли так же в Бейсике?
В 2.5 можно только побаловаться (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1172457&viewfull=1#post1172457)
Нормально пользоваться (печатать буквы и рисовать графику) в режиме высокого разрешения можно в Бейсике-Корвет (https://caglrc.cc/scalar/ware/96/)
Есть еще вариант - загрузить в 06Ц Эмулятор Монитора Старт-1200 (https://caglrc.cc/scalar/ware/546/), переключиться в режим высокого разрешения ($, вернее "солнышко"), потом запустить бейсик. Но нормально пользоваться не получится, т.к. 1) Эмулятор Монитора неправильно задает палитру в режиме высокого разрешения; 2) Бейсик-Сигнал нормально не поддерживает режим высокого разрешения.
Если графика не нужна, то еще можно использовать бейсики для cp/m.
Глянул дизассемблированный исходник Бейсика, выложенный в первом посте. Честно говоря - удивлён сколько там неоптимальностей в коде. Ведь нетрудно было написать и короче и быстрее....
metamorpho
18.12.2024, 09:56
Сделал игру (для конкурса) на Бейсике v.2996. Делал и тестировал в эмуляторе V06x (от svofski) - там удобно формат файла .ASC закинул в окошко и не нужно никаких команд набирать всё автоматически запускается. На днях собирал работы для конкурса и конвертнул из .ASC в формат Бейсика .CAS
и запустил его на других эмуляторах - игра запускается показывает меню стартует основная часть и потом виснет на моменте когда скроллинг экрана происходит. Чтобы это могло быть ? Почему в V06x всё работает, а в других эмуляторах виснет ?
Этот CAS в v06x нормально работает? Если да, то проблему надо искать в эмуляции, возможно не в эмуляции самого вектора, а в перехвате загрузки. Если нет, то стоит попробовать конверснуть ASC->CAS каким-нибудь другим способом.
metamorpho
18.12.2024, 10:55
Этот CAS в v06x нормально работает? Если да, то проблему надо искать в эмуляции, возможно не в эмуляции самого вектора, а в перехвате загрузки. Если нет, то стоит попробовать конверснуть ASC->CAS каким-нибудь другим способом.
Этот CAS в v06x не работает?
Я делаю так - переименовываю .ASC в .ТХТ а потом через конвертор Vector06CBasic.exe от TheTrik конвертирую в .CAS
А какие способы конверснуть ASC->CAS ещё есть ?
Насколько понимаю, если кинуть ASC в v06x, то он формирует в памяти программу, которая работает и которую надо сохранить из v06x. Не помню, умеет ли v06x сохранять в cas. Если не умеет, то можно сохранить в wav, загрузить wav в другой эмулятор и сохранить в cas.
metamorpho, v06x сохраняет неправильный cas, или v06x не грузит .cas, полученный Vector06CBasic.exe ?
metamorpho
18.12.2024, 14:41
metamorpho, v06x сохраняет неправильный cas, или v06x не грузит .cas, полученный Vector06CBasic.exe ?
v06x .cas, полученный Vector06CBasic.exe, грузит но также как и другие эмуляторы зависает при работе программы
в тоже самое время v06x ту же самую программу но в формате .asc грузит и всё работает
сохранять в v06x в формате .cas не пробовал, а наверное зря :) нужно будет попробовать
- - - Добавлено - - -
А как сохранять в v06x в формате .cas ?
А как сохранять в v06x в формате .cas ?
А, не получается написать CSAVE"TEST" ? Да, я думаю я это недоделал -- у меня локально это частично работает, но я не опубликовывал.
В твоей ситуации наверное можно попробовать сравнить результат загрузки из .CAS с исходным текстом. Это не самое приятное занятие наверное, но я думаю так получится быстрее всего найти проблему и может быть найти способ ее обойти. Если это срочно, присылай текст -- вместе быстрее найдем.
Можно еще так попробовать. С помощью Vector06CBasic конверснуть asc(txt)->cas а потом cas->koi7 и сравнить с исходным вариантом. Теоретически может быть засада в пробелах.
metamorpho
18.12.2024, 17:48
А, не получается написать CSAVE"TEST" ? Да, я думаю я это недоделал -- у меня локально это частично работает, но я не опубликовывал.
CSAVE"TEST" попробовал - сначала тишина была (просто "проглотил" команду и всё) потом на третий раз пошёл звук куда-то что-то выгрузил, но я так и не нашёл куда :)
В твоей ситуации наверное можно попробовать сравнить результат загрузки из .CAS с исходным текстом. Это не самое приятное занятие наверное, но я думаю так получится быстрее всего найти проблему и может быть найти способ ее обойти. Если это срочно, присылай текст -- вместе быстрее найдем.
Нет это не срочно, надеюсь Lafrom31 сможет запустить на стриме программу через V06x.
А завтра (или сегодня) уже в общий доступ архив конкурсных программ выложу.
Для одноцветной векторной анимации, как в SP_LINE (летне-зимний ретроград), в модернизированных бейсиках лучше использовать тройную буферизацию.
В 2.5 это работает не на 100% хорошо, т.к. если в нем прерывание пришлось на выполнение SCREEN0, то часть цветов (которые успели обработаться) перепрограммируются, а оставшиеся - в следующее прерывание. Идеально (для переключения видеостраниц) перепрограммировать палитру в 2.5 можно только с привлечением ассемблерных подпрограмм. В 2.5 без ассемблера можно уменьшить вероятность попадания прерывания на SCREEN0 за счет минимизации времени выполнения этой команды (минимум перепрограммируемых цветов и по возможности быстрое для интерпретации представление этих цветов).
metamorpho
23.12.2024, 19:20
Очень шустро работает алгоритм.
SCREEN.,1,.,.,.,W,W,W здесь как я понял точки это нули ?
Чем точки использовать лучше ? Это где-то описывалось в руководстве по Бейсику или это ещё одно из "скрытых" возможностей Бейсика ?
IF(X1AND255)<>X1THEN ...... (X1AND255)<>X1 как это расшифровать на русский язык ? :) предполагаю одна часть такая "если Х1>255"
Про "быстрые нули" писал здесь (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1185146&viewfull=1#post1185146).
Расшифровать IF(X1AND255)<>X1THEN можно так IF X1>255 OR X1<0 THEN
metamorpho
23.12.2024, 22:30
Про "быстрые нули" писал здесь (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1185146&viewfull=1#post1185146).
Расшифровать IF(X1AND255)<>X1THEN можно так IF X1>255 OR X1<0 THEN
IF(X1AND255)<>X1 превосходит по скорости IF X1>255 OR X1<0 ?
В 2.996 примерно на 4.5%. Одно сравнение, одна логическая операция и скобки против двух сравнений и логической операции.
Можно учесть, что бОльшую часть времени фигура летает вдали от границ и еще немного ускорить.
Вспомнил пример векторной анимации из ZX-РЕВЮ 95\1. Автор оригинальной программы - Ульянов А.М. Картинки мне кажется с PC.
morph1 - однократная анимация без прекалка
morph3 - зацикленная анимация с прекалком
LeoN65816
25.12.2024, 06:37
В 2.996 примерно на 4.5%. Одно сравнение, одна логическая операция и скобки против двух сравнений и логической операции.
А "прокатит", если вообще убрать сравнение (IF X1 AND 65280 THEN) ?
Прокатит, только стоит спрятать &FF00 в переменную и избавиться от скобок. Тогда получается еще ускорить triplbuf7.
LeoN65816
25.12.2024, 07:52
Ещё вариант: IF HI(X1) AND 255 THEN
В линейке 2.5 такой функции нет.
Можно еще учесть симметрию фигуры и границ.
metamorpho
25.12.2024, 14:42
Прокатит, только стоит спрятать &FF00 в переменную и избавиться от скобок. Тогда получается еще ускорить triplbuf7.
т.е. наглядно вот так примерно ?
D=&FF00
IF X1 AND D THEN....
И это по простому означает IF X1>255 OR X1<0 THEN ?
А как это происходит например X1=144
далее как работает Бейсик 144 AND FF00 ?
т.е. наглядно вот так примерно ?
D=&FF00
IF X1 AND D THEN....
И это по простому означает IF X1>255 OR X1<0 THEN ?
Да. Понятно, что это подходит для проверки прямоугольников со стороной от 0 до степени двойки-1. Более общий и, что приятно, более быстрый вариант - использовать массив с отмеченными границами. Приложил пример, еще там учтена симметрия фигуры. К первоначальной идее иллюстрации тройной буферизации это прямого отношения не имеет (тем более "морфинг" более содержательный пример), но пусть летает побыстрее, почему бы и нет. Переводить все переменные на однобуквенные не стал для сохранения читаемости.
Твистер на бейсике, душераздирающее зрелище. Надо конечно делать на асме, но если не хочется, то можно воспользоваться мощью современных эмуляторов. В Emu80 (начиная с 4.0.498) LAlt+PgUp пока не станет приемлемо. В Emu можно удерживать F9.
Upd: twister6 совместим и с режимом 12 МГц в VV (F10).
Ускорил как смог. Здесь аж двухбайтная машиннокодовая процедура, поэтому twister6 (где только бейсик) тоже оставил.
Округление в клонах msbasic (наверняка где-то уже было)
A=SGN(A)*INT(ABS(A)+.5)
В программах иногда используются "бесконечные" циклы с заранее неизвестным числом повторений (может быть реализован выход из цикла по проверке некоторых условий, этот момент я не трогаю).
Как правило для зацикливания в таких случаях используется GOTO назад, например:
1 REM
10 REM
100 REM
199 GOTO234
200 REM
234 REM
999 GOTO199
basic 2.5 - 7900 тактов на итерацию
basic 2.996 - 4100 тактов на итерацию
Можно ускорить подобные циклы используя FOR:
1 REM
10 REM
100 REM
199 FORI=.TO1STEP.:GOTO234
200 REM
234 REM
999 GOTO199 - ошибка, в этой строке должно быть 999 NEXT
basic 2.5 - 5760 тактов на итерацию
basic 2.996 - 2828 тактов на итерацию
Выигрыш очевиден, причем если перед строкой начала цикла (199 в примере) будет больше других строк, то вариант с GOTO будет еще замедляться, а на FOR это не влияет.
В модернизированных бейсиках есть еще один потенциальный плюс - FOR не перебивает кеширование переходов, если они используются и внутри цикла, как в приведенном примере (поэтому в 2.996 относительный выигрыш больше).
Объясни, пожалуйста, почему добавление лишних операторов что-то ускоряет и почему нельзя было просто написать 999 GOTO234 -- в чем смысл 199 GOTO234 ?
почему добавление лишних операторов что-то ускоряет
Лишний FOR исполняется один раз и это потребует
в basic 2.5 - 4980 тактов
в basic 2.996 - 2272 такта
Т.е. за 2-3 итерации (а цикл то "бесконечный") это время будет скомпенсировано и пойдет чистый выигрыш.
А выигрыш за счет
1) Парсинг NEXT быстрее, чем GOTO+номер
2) Адрес начала цикла в NEXT сохранен FORом и сразу переходим куда надо. В GOTO надо еще найти строку (если речь не о модернизированном бейсике и если номер не совпал с "кешем").
почему нельзя было просто написать 999 GOTO234 -- в чем смысл 199 GOTO234
Это порча жизни кешированию переходов и ближе к реальности, когда в содержательной программе внутри цикла будут переходы, скорее всего условные.
А выигрыш за счет
1) Парсинг NEXT быстрее, чем GOTO+номер
2) Адрес начала цикла в NEXT сохранен FORом и сразу переходим куда надо. В GOTO надо еще найти строку (если речь не о модернизированном бейсике и если номер не совпал с "кешем").
Вот тут мне надо еще раз. В твоем примере я NEXT не вижу. Это какой-то неявный NEXT?
Спасибо, я умудрился скопировать хвост варианта NEXT из варианта GOTO, а правильный вариант такой
1 REM
10 REM
100 REM
199 FORI=.TO1STEP.:GOTO234
200 REM
234 REM
999 NEXT
Можно ускорить подобные циклы используя FOR:
1 REM
10 REM
100 REM
199 FORI=.TO1STEP.:GOTO234
200 REM
234 REM
999 GOTO199
Можно еще исправить оригинальное сообщение, чтобы было проще тем, кто найдет это потом когда-нибудь.
И я все-таки не до конца понял что делает GOTO234 в варианте с FOR. Что если я просто напишу FORI=.TO1STEP. без :GOTO234 ?
Можно еще исправить оригинальное сообщение, чтобы было проще тем, кто найдет это потом когда-нибудь.
Не хотел там править, чтобы было понятен последующий диалог. Сейчас поправил, надеюсь с разными датами исходного сообщения и правки будет понятнее.
И я все-таки не до конца понял что делает GOTO234 в варианте с FOR. Что если я просто напишу FORI=.TO1STEP. без :GOTO234 ?
Могу только повторить, что для варианта с GOTO199 это перебивание кеширования номера строки в 2.996, чтобы лучше соответствовало реальным программам, у которых внутри циклов бывают переходы.
Узкоспецифический вопрос - какой вариант записи дробных чисел быстрее для парсинга и преобразования во внутреннее представление?
В 2.5 A=.1 или A=.9 быстрее, чем A=1E-1 или A=9E-1. Но при наличии нулей после запятой вариант с E становится предпочтительнее: A=1E-2 или A=9E-2 быстрее, чем A=.01 или A=.09.
В 2.996 вариант с E всегда быстрее.
Ну и я уже писал, что при частом использовании числа большой (по модулю) степени и/или с большим количеством знаков после запятой его выгоднее присвоить переменной и пользоваться ей.
Могу только повторить, что для варианта с GOTO199 это перебивание кеширования номера строки в 2.996, чтобы лучше соответствовало реальным программам, у которых внутри циклов бывают переходы.
Понятно. То есть это попытка приблизить бенчмарк к реальности, а не часть рекомендованного паттерна. Тебе наверное трудно в это поверить, но это совершенно не очевидно. Это выглядит в контексте примера как какой-то особый трюк, который позволяет все разогнать в два раза. По-моему совсем не вредно такие примеры подробно документировать.
Согласен, надо было четче разграничить суть и дополнительные бантики.
Суть простая - в "бесконечных" циклах вместо
GOTO назад
быстрее делать так
FORI=.TO1STEP.
...
NEXT
Переменная I выбрана случайным образом, можно использовать и другие буквы.
В msbasicах (даже версий 5.x) нет команды досрочного прерывания цикла FOR...NEXT, но есть как минимум два варианта, как это сделать.
1. Очевидный.
Если мы проверили внутри цикла некое условие и оказалось, что надо цикл прервать, то присваиваем переменной цикла конечное значение и переходим на NEXT.
Строго говоря можно взять значение чуть меньше, главное чтобы (это значение+шаг цикла)>конечное значение. Это может иметь смысл, например если конечное значение дробное, а мы хотим для краткости и скорости использовать целое.
2. Менее очевидный. Годится при наличии вложенных циклов.
Если нам надо досрочно окончить внутренний цикл, то делаем переход за пределы внутреннего NEXT. Главное - надо в NEXT внешнего цикла обязательно добавить имя переменной этого цикла.
NEXT с указанием переменной сбросит со стека "лишнее" и дойдет до своей переменной. Особенно эффективен этот вариант для прерывания сразу нескольких внутренних циклов с выходом во внешний.
Вариант 1 при наличии вложенных циклов тоже годится, но скорее всего вариант 2 будет чуть быстрее, хотя лучше проверять конкретные случаи.
Пробный подход к шейдерной штуке (https://www.shadertoy.com/view/X3sGRB). Невыносимо медленно и по качеству изображения уступает оригиналу, но что-то в этом есть.
С дизером намного лучше, ну и перешел с желтого на зеленый.
Переделал тригонометрию на LUT, в 2.996 ускорение почти в 3 раза (но все равно очень медленно).
Все побежали и я побежал.
Еще год назад сделал (кроме шаманства с палитрой) версию 2.997 и хотел ее выложить вместе с более быстрым rtbasicом, но его не доделал, за год не притрагивался.
А тут на горизонте новый Ретроград и вдруг кто-нибудь захочет использовать бейсик.
Исправления и улучшения:
89. Исправлены: работа разделителей , и ; с оператором PRINT; функция POS. Печать чисел без переноса, как в оригинальном бейсике-микрон для РК86.
90. Исправлен CIRCLE (рисование дуг эллипсов при некоторых комбинациях параметров, ошибка была в 2.995). Спасибо Игорю Титарю за багрепорт.
91. Часто встречающаяся в программах комбинация IF..THEN теперь выполняется чуть быстрее, чем практически не используемый вариант IF..GOTO
92. В кодовых подпрограммах теперь можно использовать пересылки или стирание стеком (через BC) по методу Медноногова.
93. Увеличено время между командами программирования палитры для максимальной совместимости с любыми 06Ц и .02.
94. Несколько мелких оптимизаций.
Это "очередная финальная" версия ветки 2.9x, надеюсь на это раз действительно финальная.
Уже писал (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1200167&viewfull=1#post1200167), но повторюсь, что 2.997 заменяет 2.995, по быстродействию они близки, а место более быстрого 2.996 в перспективе должен занять еще чуть более быстрый rtbasic.
aGGreSSor
19.07.2025, 00:45
В 2.997 длительность звучания оператора BEEP .001,1 ощутимо дольше чем BEEP .01,1
Отсутствует возможность определения версии Бейсика из программы на Бейсик,
при этом сам Бейсик свою версию на старте не отображает.
Ни один эмулятор не содержит обновлённый Бейсик по умолчанию.
Поэтому всё что остаётся автору написать в начале программы нечто подобное
(и рассчитывать что умный пользователь пойдёт гуглить в чём дело):
82521
- - - Добавлено - - -
metamorpho, возьми эту версию, специально по заказу https://www.sensi.org/~svo/v06x/v06x-cload-run.zip
К сожалению, sensi.org лежит и эта ссылка не доступна.
- - - Добавлено - - -
Я конечно не метаморф, но эта ссылка дана также в документации Бейсик_Вектор-06Ц.pdf
В 2.997 длительность звучания оператора BEEP .001,1 ощутимо дольше чем BEEP .01,1
Это не только в 2.997, а во всех вариантах 2.5, кроме 2.996. Проблема в недостаточной точности (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1201054&viewfull=1#post1201054).
aGGreSSor
19.07.2025, 09:57
Ещё вопрос. Существуют конверторы bas2asc (https://github.com/svofski/vector06sdl/tree/master/bas2txt) и Vector06C Basic Converter (https://github.com/thetrik/Vector06C-Basic-Converter). Оба позволяют перегонять bas в текст и текст в bas, последний дополнительно умеет в cas. Чтобы перегнать бейсик-программу из cas в bas или текст мне надо писать свой конвертер?
Vector06C-Basic-Converter позволяет преобразовывать форматы bas, cas, txt в любых сочетаниях, в т.ч. и cas->bas, cas->txt.
aGGreSSor
19.07.2025, 10:45
Vector06C-Basic-Converter позволяет преобразовывать форматы bas, cas, txt в любых сочетаниях, в т.ч. и cas->bas, cas->txt.
Проверил, действительно открывает. Странно, вчера получал какие-то ошибки. Спасибо!
aGGreSSor
20.07.2025, 22:14
Скажите, а в векторном бейсике есть что-нибудь типа TIME, чтобы замерить время выполнения куска программы (желательно в секундах)?
Есть такой эталонный тест - Ahl's benchmark (https://en.m.wikipedia.org/wiki/Creative_Computing_Benchmark).
При запуске на Basic 2.5 и 2.997 он даёт одинаковый результат:
3.38745E-02
9.84033
Хотя даже на глаз видно, что программа завершается в 2.997 быстрей. Для сравнения на Apple ][e она выполняется 113.7 сек.
Есть новый тест претендующий на эталонность - bench64 (https://github.com/scruss/bench64/tree/main).
Его особенность в том, что не допускаются никакие оптимизации, типа перенумерации с шагом 1, быстрые нули, запись &число и т.д.
Он берёт за эталон последнюю модель Commodore 64 производившуюся для США и каждый из 8 содержащихся в нём тестов выполняется за минуту, что приравнивается к 100 попугаям
Относительно комода сравниваются остальные Бейсики, например Sinclair Basic даёт 29 попугаев, т.е. в 3,5 раза медленней комодовского, а BBC Micro даёт 202 попугая, т.е. в 2 раза быстрей комода.
Всё это прекрасно, но я не знаю как засечь время на векторном бейсике. Generic версия без таймера внезапно даёт результаты идентичные Спектруму и опять - одни и те же на обоих Бейсиках - 2.5 и 2.997:
BASIC BENCH INDEX
> I GOOD. NTSC C64=100
1/8 - FOR:
309.5 S; 130.8 /S; I= 19
2/8 - GOTO:
367.8 S; 72.1 /S; I= 16
3/8 - GOSUB:
340.9 S; 61.7 /S; I= 18
4/8 - IF:
181.8 S; 80.1 /S; I= 33
5/8 - IF:
135.3 S; 26.9 /S; I= 44
6/8 - MATHS:
110.1 S; 3.5 /S; I= 54
7/8 - STRING:
125.8 S; 39.2 /S; I= 48
8/8 - ARRAY:
103 S; 16.3 /S; I= 58
OVERALL INDEX= 29
Вероятно, если бы удалось внедрить TIME (как в других вариантах), результаты бы отличались (не вдавался в логику). Прилагаю сами тесты.
82533
Ссылки (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1199785&viewfull=1#post1199785) на тесты скорости, которые пробовал.
Там есть и "общечеловеческие", например Rugg/Feldman benchmarks (комментарии там несколько устаревшие, т.к. результаты бейсиков обновлял, а комментарии - нет).
В большинстве случаев засекал в отладчике emu для максимальной точности, но есть и пример использования встроенных возможностей - медленный Мандельброт.
POKE768,0,0,0 в начале - это инициализация, PEEK(768) - младший и PEEK(769) - средний байты результата, сколько кадров прошло. Если мало, то есть еще и самый старший байт PEEK(770).
aGGreSSor
22.07.2025, 01:54
Спасибо, ivagor! Таким образом, выражение позволяющее узнать кол-во секунд приблизительно прошедшее с момента старта компьютера строится аналогично Спектруму:
(65536*PEEK(770)+256*PEEK(769)+PEEK(768))/50
В процессе адаптации возникло две проблемы:
1) Так же как и на Спектруме, нельзя просто присвоить выражение переменной или функции и рассчитывать что оно всякий раз будет пересчитываться при вызове. Оно посчитается один раз, присвоится и будет всякий раз выдаваться одно и то же. В принципе, это логично, но на комоде это не так. По этой причине scruss допустил в версии bench64 (https://github.com/scruss/bench64/tree/main) для Спектрума ошибку, так что время в его версии не идёт, поэтому и результаты bench64zx.bas (https://github.com/scruss/bench64/blob/main/sinclair_zx-spectrum/bench64zx.bas) идентичны bench64g.bas (https://github.com/scruss/bench64/blob/main/generic_no_TIME/bench64g.bas) (generic no time). Исправил и выкатил релиз для спектрума (https://zxart.ee/eng/software/system-software/programming/basic/bench64/) на zxart. Аналогично и для Вектора все TIME просто заменяются на выражение выше и вычисляются всякий раз по новой.
2) Не хватало символьной памяти, ошибка "мал буфер" в тесте STRING. Добавил в тест CLEAR 2000 (скорей всего слишком много, но работает).
Других изменений не было.
Результаты:
| Vector | Vector | Commodore64 | Sinclair | Sinclair |
| BASIC 2.5 | BASIC 2.997 | BASIC | BASIC 48 | BASIC 128 |
| (3 Mhz) | (3 Mhz) | (1,023 Mhz) | (3,5 Mhz) | (3,5 Mhz) |
--------+-----------+-------------+-------------+-----------+------------+
FOR | 91 | 182 | 100 | 21 | 18 |
GOTO | 89 | 185 | 100 | 18 | 15 |
GOSUB | 75 | 193 | 100 | 19 | 15 |
IF | 101 | 219 | 100 | 35 | 29 |
FN | 86 | 189 | 100 | 46 | 43 |
MATHS | 112 | 225 | 100 | 55 | 55 |
STRING | 84 | 139 | 100 | 49 | 44 |
ARRAY | 91 | 186 | 100 | 59 | 55 |
--------+-----------+-------------+-------------+-----------+------------+
OVERALL | 90 | 186 | 100 | 30 | 26 |
Похоже на правду. Зримое подтверждение того что BASIC 128 на Спектруме медленней BASIC 48, а Basic 2.997 на Векторе производительней Basic 2.5, причём более чем в 2 раза!
Тест: 82535
На один момент стоит обратить внимание. В общем случае не рекомендую измерять время выражением
(65536*PEEK(770)+256*PEEK(769)+PEEK(768)
Если очень не повезет, то между PEEKами может произойти инкремент с переносом и получится странный результат. Вероятность этого очень маленькая (и в данном тесте такого не случилось), но мне один раз "повезло", поэтому стал делать как в медленном Мандельброте. Отдельно PEEKи, чтобы уменьшить время между ними (и, соответственно, вероятность переноса), отдельно проверка на перескок и отдельно вычисление. Ну и для максимальной точности лучше делить на 50.08, но это ерунда, которой можно пренебречь.
Запускал bench64vc много раз и получил-таки перенос между PEEKами. Проявляется это как неожиданные +5 секунд в каком-нибудь тесте. Для контроля правильности надо или запускать тест 2-3 раза или откорректировать измерение времени.
В 2.997 остались несколько свободных байт и попробовал потратить их на оптимизацию одной из процедур работы со строками. Седьмой тест (7/8 - STRING) становится на секунду быстрее (I=142 вместо 139), общий индекс 187 вместо 186.
И еще вспомнил специфический момент. В последних модернизированных бейсиках в случае прерывания выполнения программы в результате ошибки или по УС+С (LCtrl+C) однобуквенные переменные обнуляются (это экономит 1 байт, что было крайне необходимо в момент введения).
Например
10 I=1:I2=2
20 MMM
Запускаем, получаем синтаксическую ошибку в строке 20, жмем LCtrl+С для перехода к командной строке и делаем PRINT I,I2
2.5 напечатает 1 2
2.997 напечатает 0 2
Это не ошибка, скорее особенность, но в некоторых случаях для отладки удобнее классический вариант.
Вопрос к заинтересованной общественности - надо ли ради такой ерунды (микроускорение строковых операций и необнуление однобуквенных переменных) зарелизить еще одну версию или лучшее враг хорошего и стоит успокоиться на 2.997?
Вопрос к заинтересованной общественности - надо ли ради такой ерунды (микроускорение строковых операций и необнуление однобуквенных переменных) зарелизить еще одну версию или лучшее враг хорошего и стоит успокоиться на 2.997?
Я за то, что бы зарелизить.
aGGreSSor
24.07.2025, 13:19
Вопрос к заинтересованной общественности - надо ли ради такой ерунды (микроускорение строковых операций и необнуление однобуквенных переменных) зарелизить еще одну версию или лучшее враг хорошего и стоит успокоиться на 2.997?
Вопрос версионности. Может точку ввести для минорных изменений? Типа 2.997.2?
Для контроля правильности надо или запускать тест 2-3 раза или откорректировать измерение времени.
Bench64 мне понравился за возможность оценки сверху, чтобы понять порядок, соотношение. Если надо откорректировать, напишите как. Хотел сделать пуллреквест автору scruss (хотя врядли он его примет спустя 5 лет :) ).
У меня два вопроса:
Когда у меня заполнен экран изображением отрисованным через LINE BF, включая нижние 2 строки, спустя некоторое время (зависящее от режима CPU в эмуляторе) этот экран начинает сам двигаться вверх по знакоместам, как Scroll? на Спектруме. На Спектруме это выключается через переменные, а как на Векторе выключить прокрутку? Читал "Скроллинг экрана - 771" в доке по Бейсику, но больше ничего по теме там не нашёл. «Vector-user» №1 №10 и «Байт №8» ясности тоже не добавили (м.б. невнимателен).
Как принудительно заткнуть замечательную самоиграйку запущенную через PLAY? Она играет всю дорогу пока выполняется программа. Прописывание пробела в M1$,M2$,M3$ с повтором PLAY не помогает. Команда STOP в доке по Бейсику не описана.
Графические операторы напрямую не связаны со скроллом, только вывод текста на экран (PRINT, INPUT, или в режиме редактирования, ну и CLS приводит в исходную позицию).
PEEK(771) или POKE771,... позволяют узнать или задать позицию аппаратного скролла.
bench64 в качестве синтетического теста быстродействия мне не очень нравится, пока не вижу примеров, где он соответствует (пусть не в целом, а по отдельным позициям) более содержательным программам. Но это общий недостаток синтетики (RFBM это тоже касается).
Например тест 6/8 MATHS показывает выигрыш 2.997 относительно 2.5 примерно в 2 раза, а если сравнить с околоматематическими тестами без графики (Мандельброты и решето Эратосфена), то там ускорение примерно в 2.2-2.3 раза.
Но тест полезный, спасибо за адаптацию для вектора, он мне нашел еще одну ошибку в 2.996.
Каждый PLAY перезагружает соответствующий канал или каналы. Например PLAY"P","P","P" заглушит все три канала.
Прикинул, сколько байт потребовал бы самый простой вариант выдачи информации о версии. Новая отдельная функция это запредельная роскошь, но даже если использовать имеющуюся функцию с хитрым аргументом, например FRE(-.5) и возвращает 2.998, то минимум потребуется 27 байт или немного больше. Столько места нет, даже если не оптимизировать строки и попробовать наскрести еще несколько байт.
Прикинул, сколько байт потребовал бы самый простой вариант выдачи информации о версии. Новая отдельная функция это запредельная роскошь, но даже если использовать имеющуюся функцию с хитрым аргументом, например FRE(-.5) и возвращает 2.998, то минимум потребуется 27 байт или немного больше.
Пару байт по фиксированному адресу и PEEK()
Думал об этом варианте, но речь о бейсиках 2.5+ в которых
1. Для PEEK (и POKE) недоступны часть адресов
2. Для части адресов используется трансляция/переадресация
Т.е. нельзя расположить в коде бейсика 2 байта и прочитать их с использованием PEEK.
Я не придумал, где можно расположить байты с версией в читабельной области так, чтобы в 2.5 это были всегда одни байты, а в 2.998 всегда (как вариант) 29h и 98h и это ничего бы не портило.
Дополнительно не хотелось бы замедлять PEEK введением проверок, но на это я в крайнем случае готов.
Компромисс - можно читать байты с версией из кода бейсика с использованием подпрограммы в машинных кодах, это реалистично, но возможно не всех устроит.
Есть вариант, который требует от самого бейсика 0 байт - определение по косвенным признакам. Конкретную версию в общем случае так вряд ли получится узнать, но примерную группу (2.5 или 2.8 или 2.9) можно.
metamorpho
25.07.2025, 16:31
Возможно я не совсем точно понимаю как новые версии Бейсика разворачиваются при запуске. но
вот такая идея есть - зашить в Бейсик готовую программу типа:
10 CLS:PRINT "2.997":NEW
и при запуске Бейсика, запустить эту готовую программу, которая себя удалит, а на экране останется версия Бейсика.
Механизм автостартующей "предустановленной" программы был в 2.5, в новых бейсиках его нет. Тем не менее при старте другим способом выполняется микропрограммка, заменить ее не получится, не хватает места. Печати версии бейсика при старте нет для сокращения размера, чтобы легче было разместить в пзу при необходимости. Ну и печать версии на экране не решает задачу определения версии из программы.
aGGreSSor
25.07.2025, 19:57
В порядке бреда. Наверное цифра 2 версии нам вообще не нужна. Потому что и так ясно что бейсик 2.какой-то. Поэтому достаточно 1 байта. Если появляется Бейсик 3, ну значит в этом байте будет 3, для 3.1 - 4 и т.д. До мажорной версии 4.какой-то мы врядли доживём. :v2_dizzy_priest: Есть функция которая меня выбесила - INP. Почему она не IN? :mad: Чтобы парсер отличил от INT? Вот это 1 байт, кстати. Ломает совместимость, правда. :v2_rolley
Как я вижу варианты требований к точности определения версии:
1. Нужна конкретная версия и только она. Такое возможно, если программа вызывает через машинный код процедуры бейсика, адреса которых плавают от версии к версии. Пример - бейсиковский вариант Моны. В таком случае самый надежный вариант ориентироваться на 2.5.
2. Нужна версия, в которой уже исправлена определенная ошибка или ошибки. Т.е. скорее всего подойдут несколько версий начиная с такой-то. Примеры были на ретрограде, например широкое использование шестнадцатеричных чисел, которые в 2.5 очень ограниченны. Можно сделать очень просто (хотя и не очень изящно) - печатаем на экране что-то вроде
"Для данной программы требуется версия бейсика не ниже такой-то"
потом пробуем использовать исправленный вариант какого-то оператора или функции. Если бейсик старый - вылетаем с ошибкой и на экране остается вышеприведенное сообщение. Если бейсик подходящий - стираем сообщение и идем дальше.
3. Используются внутренние особенности, без которых можно обойтись. Примеры были и в классических программах и на ретрограде. Например - для картинки, которая будет выведена с использованием PUT, пишем данные прямо в массив, откуда будет PUT. Вместо этого лучше нарисовать на экране например через POKE, потом GET, потом PUT, в таком случае программа будет совместима с любым внутренним представлением картинки GET/PUT. Примеры таких адаптаций пары программ я выкладывал, это вполне осуществимо.
aGGreSSor
26.07.2025, 01:16
Ушатал Бейсик. Писал трек в текстовом редакторе с конверсией в cas через Vector06CBasic. Где-то паттерна до 6 всё было нормально, дальше начало орать про "Несоотв. данных" на этапе загрузки cas. Далее в эмуляторе vv начали происходить чудеса. Бейсик 2.5 ушатывается сразу, Бейсик 2.997 ещё немного мучается. Прилагаю программу: 82547 и видео на тытруба. В документации не сказано сколько м.б. GOTO с оператора ON, мог перебрать. Строки передаваемые в PLAY менее 127 символов.
https://www.youtube.com/watch?v=1N86ku9ONN0
Проблема не в бейсике, это конвертер привередничает. Если несоответствие данных при загрузке, то запускать нет смысла, надо добиваться безошибочной загрузки.
Загрузил в Vector06CBasic, удалил последнюю пустую строку, потом нажал Enter (добавил пустую строку) и после этого он смог сделать нормальный cas, который нормально загружается и играет и в 2.5 и в 2.997.
Конверсия музыки отличная, спасибо!
Попробовал встроенным конвертером в v06x. Надо переименовать .txt в .asc и заменить клопов на доллары, а так все всосалось сразу.
aGGreSSor
31.07.2025, 01:53
Вопрос по функциям. В описании DEF FN сказано "Список параметров содержит имена формальных переменных, которые используются при формировании выражения функции." Например, два параметра понадобится для вычисления целочисленного остатка от деления (т.к. функции MOD в 06Ц Бейсик нет). Оператор DEF DN M(A,B)=A-INT(A/B)*B даёт синтаксическую ошибку. Обнаружил, что если записать DEF FN M(A B)=A-INT(A/B)*B, то ошибки нет. Казалось бы: это оно. Но при попытке передачи функции аргументов, например FN M(2 4), выбрасывает ошибку "деление на ноль". Судя по всему, при таком вызове в функцию передаётся 0 для обоих аргументов. Потому что тестовые DEF FN M(A B)=A и DEF FN M(A B)=B вернули 0.:(
Версия микрософтовского бейсика, которая была прототипом, поддерживает только один аргумент DEFFN. Цитата со страницы 31 (страница 36 pdf) отсюда (https://altairclone.com/downloads/manuals/BASIC%20Manual%2075.pdf)
"A function may be defined to be any expression, but may only have one argument"
В описании 2.5 начало (там где Формат: ) правильное
"<параметр> - любое допустимое имя, которое будем называть формальной переменной"
Но потом в разделе Действие: уже ерунда про список параметров.
aGGreSSor
31.07.2025, 09:16
Версия микрософтовского бейсика, которая была прототипом, поддерживает только один аргумент DEFFN. Цитата со страницы 31 (страница 36 pdf)
Отличная pdf, спасибо! Заодно прояснил себе, что оператор с нестандартным/нелогичным именем INP (которое бесит) был ещё в 8K ALTAIR BASIC на 9 странице. :rolleyes:
Хорошо бы исправить эту формулировку в следующей версии описания (пользуюсь pdf от metamorpho ( v.1.2 2023-2024 г.). Также там в описании SCREEN есть невнятное место: N - код математического цвета (от 0 до 15), начиная с которого производится изменение цвета (0-цвет фона). Отсюда невозможно понять, что 1 - цвет бордюра. Например, SCREEN 0,0,5,0 установит красный фон и чёрный бордюр. И, кстати, 15 как я понимаю - это цвет тона. Т.е. SCREEN 0,15,5 сработает аналогично COLOR 5 и установит красный цвет тона. metamorpho, неплохо было бы добавить эту формулировку. Кстати, во всех доках палитровых бейсиков которые находил, то что в v1.2 называется математическими цветами, называют логическими. Долго пытался понять что такое "математический" цвет. Нормальная формулировка: Команда SCREEN 0,0,L,P служит для присвоения логическому цвету L (0-15, из 16 возможных) физического цвета P из палитры. Она аналогична VDU 19,L,P в Acorn BASIC, кстати.
не хотелось бы замедлять PEEK введением проверок, но на это я в крайнем случае готов.
Ну а что, рабочий вариант. Что там возращают бейсики 2.5 на PEEK(0) и PEEK(1)? Для новых версий - номер версии.
POKE и PEEK по адресам 0-639 - это знакогенератор. Если понадеяться на то, что в знакогенератор практически всегда пишут, но не читают, то можно попробовать выдавать по PEEK(0) и PEEK(1) что-нибудь другое (не из знакогенератора), например версию бейсика.
Свое видение детекта версии я уже написал (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1216675&viewfull=1#post1216675), на мой взгляд без явной реализации этой фичи в бейсике можно обойтись. В тех же микрософтовских бейсиках поздних версий такого тоже не добавили.
Долго пытался понять что такое "математический" цвет.
Это терминология из штатного описания бейсика 2.5
Также там в описании SCREEN есть невнятное место: N - код математического цвета (от 0 до 15), начиная с которого производится изменение цвета (0-цвет фона). Отсюда невозможно понять, что 1 - цвет бордюра.
Цвет бордюра зависит не только от SCREEN (физический) но и от третьего аргумента COLOR (математический/логический, по умолчанию в 2.5=1, но так не во всех его клонах).
Т.е. SCREEN 0,15,5 сработает аналогично COLOR 5 и установит красный цвет тона.
SCREEN0,15,5 не аналогичен COLOR5
1. Он поменяет 15й цвет палитры, COLOR5 цвет палитры не поменяет.
2. COLOR5 задаст в каких плоскостях будут рисовать следующие графические операторы (рисуем в 0й и 2й плоскостях, стираем в 1й и 3й - это справедливо, если разрешено рисование во всех плоскостях). SCREEN0 не влияет на то, в каких плоскостях будут рисовать следующие графические операторы.
15 как я понимаю - это цвет тона
В состоянии по умолчанию настроено рисование цветом 15, т.е. во всех плоскостях. Но опять же это справедливо не для всех клонов 2.5
Команда SCREEN 0,0,L,P служит для присвоения логическому цвету L (0-15, из 16 возможных) физического цвета P из палитры.
Команда SCREEN0,0,L,P присвоит математическим/логическим цветам 0 и 1 физические цвета L и P
aGGreSSor
31.07.2025, 22:27
Команда SCREEN0,0,L,P присвоит математическим/логическим цветам 0 и 1 физические цвета L и P
Да, но я имел ввиду другой контекст.
10 FOR L=0 TO 15
20 P=INT(RND(1)*255)+1)
30 SCREEN 0,L,P
40 NEXT L
И вот здесь берём мою формулировку: Команда SCREEN 0,L,P в строке 30 служит для присвоения логическому цвету L (0-15, из 16 возможных) случайного физического цвета P из палитры 255 цветов.
Цвет бордюра зависит не только от SCREEN (физический) но и от третьего аргумента COLOR (математический/логический, по умолчанию в 2.5=1, но так не во всех его клонах).
Проблемы терминологические. Я считаю так:
Логический цвет - это то чем оперирует программист на своём уровне логики работы программы, это абстракция. В 06Ц Бейсик программист может оперировать 16 цветами, потому что больше Вектор на экране формально показать не может.
Физический цвет - это цвет который присвоен логическому цвету физически, по факту. Какие для этого отображения потребовалось затронуть плоскости, программисту на уровне Бейсика, в принципе безразлично. Он про них наверное и знать не обязан.
То что я хочу сказать:
Физический цвет фона зависит от установленного логического цвета 0
Физический цвет бордюра зависит от установленного логического цвета 1
Физический цвет тона зависит от установленного логического цвета 15.
Вместо тысячи слов. Вот программа на Acorn BASIC:
10 REM Draw to the screen
20 MODE 2
30 D=1280/16
40 X=0
50 MOVE X,0
60 MOVE X,1024
70 FOR I=0 TO 15
80 X=X+D
90 GCOL 0,I
100 PLOT 85,X,0
110 PLOT 85,X,1024
120 NEXT I
130 REM Cycle the palette
140 K=0
150 FOR L=0 TO 15
160 P=0
170 IF L=K THEN P=5
180 VDU 19,L,P,0,0,0
190 NEXT L
200 K=K+1
210 IF K>15 THEN K=0 : REM We can now use 0 as part of our animation
220 GOTO 150
Переписываем это на 06Ц Бейсик:
10 D=255/16
20 X=0
30 PLOT X,0,2
40 PLOT X,255,2
50 FOR I=0 TO 15
60 X=X+D
70 COLOR I
80 LINE X,0,BF
90 LINE X,255,BF
100 NEXT I
110 K=0
120 FOR L=0 TO 15
130 P=0
140 IF L=K THEN P=5
150 SCREEN 0,L,P
160 NEXT L
170 K=K+1
180 IF K>15 THEN GOTO 110
190 GOTO120
И это даже работает. Внимание, вопрос: как будет выглядеть проверка необходимая для того чтобы эта шляпа не моргала бордюром? :)
Программа для Вектора: 82601
Переделал немного, 0-й цвет это цвет фона, его в данном случае нельзя использовать, иначе будет моргать бордюром. 82602
aGGreSSor
01.08.2025, 00:29
Переделал немного, 0-й цвет это цвет фона, его в данном случае нельзя использовать, иначе будет моргать бордюром. 82602
Спасибо. Но в случае IF L=K AND L>0 мы просто не рисуем первую позицию анимации, чтобы у нас не моргал бордюр. Немного нелогично, цветов у нас 16. В оригинале это выглядит так:
https://blog.mousefingers.com/post/bbc/CycleAll.gif
Проблему бордюра можно решить просто переключая цвет бордюра например так: 82603
aGGreSSor
01.08.2025, 02:04
Проблему бордюра можно решить просто переключая цвет бордюра например так: 82603
Вот, спасибо! Мне было интересно, удастся ли это решить.
В записи для Acorn BASIC три нуля в инструкции VDU 19,L,P,0,0,0 после устанавливаемого физцвета служат похожей цели.
В 06Ц Бейсик мы при SCREEN 0,L,P,0 и L=15 получили бы синтаксическую ошибку
Ваша конструкция с перестановкой цвета бордюра в IF L=K THEN P=5:COLOR 15,0,15-L является выходом для этой задачи. :v2_dizzy_rose:
Сравнительно компактный вариант определения версии (<=2.995, 2.996, 2.997-2.999).
aGGreSSor
01.08.2025, 20:42
Сравнительно компактный вариант определения версии (<=2.995, 2.996, 2.997-2.999).
Это очень вовремя. Посмотрел: да, определяет. Добавлю это в демку для CC. Спасибо! :v2_dizzy_drink:
В 2.998 точно будут стартовое сообщение о номере версии и сохранение однобуквенных числовых переменных при останове программы по УС+С или ошибке.
Также будут мелкие оптимизации, но их могу откатить, если место понадобится для исправления ошибок или реализации важных пожеланий.
Встроенного определения номера версии не будет.
Очередная финальная версия ветки 2.9x. Свободного места не осталось.
Логический цвет - это то чем оперирует программист на своём уровне логики работы программы, это абстракция.
Если правильно понимаю, на других платформах это называется индексом в палитре цветов (просто когда писали мануалы для Вектора, такой терминологии в русскоязычном пространстве в ходу не было)
Если отбросить терминологию из штатного описания, то можно и так: индекс в палитре и содержимое палитры или цвет в видеопамяти и цвет в палитре.
aGGreSSor
05.08.2025, 12:07
Если правильно понимаю, на других платформах это называется индексом в палитре цветов
Думаю, нет. Palette index это именно номер цвета в неизменяемой палитре из 256 цветов, иначе физический цвет. Можно было бы назвать 16 цветов отображаемых на экране, также палитрой (задаваемой) и ivagor выше это даже сделал. Но такой подход вносит путаницу, потому что о какой палитре мы говорим можно будет понять только из контекста. Проще считать что палитра одна - это все 256 физически доступных цветов.
(просто когда писали мануалы для Вектора, такой терминологии в русскоязычном пространстве в ходу не было)
Конечно. Я писал про доку в pdf созданную уважаемым metamporho и выложенную здесь (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1191025&viewfull=1#post1191025). Это ни в коем случае не критика, в той pdf проделана огромная работа по консолидации информации из разных мануалов, с любовью всё раскрашено, пользоваться этой pdf удобно. Считаю что она ключевая по 06Ц Бейсик. Но есть моменты вводящие в заблуждение и недосказанности, есть орфографические ошибки которые надо вычитывать. Поэтому просто подсвечиваю и предлагаю на обсуждение в теме.
aGGreSSor
08.08.2025, 13:02
Вопрос. Конструкция ON <var> GOTO/GOSUB ограничена 15 переходами. Плюс сверху ограничена длиной строки 127 символов (по крайней мере для отображения LIST).
Вычисляемые переходы типа M=<номер строки>:GOTO/GOSUB M в 06Ц Бейсик не работают. Как сделать более 15 переходов не вводя пачку IF..THEN ?
Сейчас выкручиваюсь такой конструкцией:
ON <var> GOTO/GOSUB <15 переходов>
<var2>=<var>-15:ON <var2> GOTO/GOSUB <15 переходов>
и т.д.
Но это времяёмкая шляпа.
Количество переходов в ON ... GOTO/GOSUB ограничивает только длина строки. При использовании для программирования на бейсике комбинации редактор+конвертер эта длина может быть очень большой. Пример с ретрограда - в игрушке CORPSE есть 2 штуки ON ... GOTO с примерно 40 переходами.
Думаю, нет. Palette index это именно номер цвета в неизменяемой палитре из 256 цветов, иначе физический цвет. Можно было бы назвать 16 цветов отображаемых на экране, также палитрой (задаваемой) и ivagor выше это даже сделал. Но такой подход вносит путаницу, потому что о какой палитре мы говорим можно будет понять только из контекста. Проще считать что палитра одна - это все 256 физически доступных цветов.
Возможно, на Векторе действительно принята такая терминология, т.к. Вектор физически даёт на выбор всего 256 цветов из-за ограничений ЦАП. На PC в эпоху VGA палитрой называли только те цвета, которые одновременно могли присутствовать на экране, т.к. говорить о "палитре" в 262144 (или сколько там позволял VGAшный ЦАП) цветов не было особого смысла ввиду того, что каждый из R, G, B компонентов занимал отдельный байт.
aGGreSSor
12.08.2025, 21:28
Возможно, на Векторе действительно принята такая терминология, т.к. Вектор физически даёт на выбор всего 256 цветов из-за ограничений ЦАП. На PC в эпоху VGA палитрой называли только те цвета, которые одновременно могли присутствовать на экране, т.к. говорить о "палитре" в 262144 (или сколько там позволял VGAшный ЦАП) цветов не было особого смысла ввиду того, что каждый из R, G, B компонентов занимал отдельный байт.
Как дело обстояло на PC в эпоху VGA не могу сказать. На Амигах, например, стандартно описывается экран как 32-256 цветов из палитры 4 096 цветов (в зависимости от всяких EHB, etc), а с включённым HAM8 как 262 144 цветов из палитры 16,7 млн. (24 бита). Это общераспространённая терминология и по-русски, и по-английски, например такая табличка:
82648
- - - Добавлено - - -
При использовании для программирования на бейсике комбинации редактор+конвертер эта длина может быть очень большой. Пример с ретрограда - в игрушке CORPSE есть 2 штуки ON ... GOTO с примерно 40 переходами.Судя по всему из-за конвертора у меня эти баги и возникают. Причём они плавающие, но на момент написания поста была чёткая картина, что вот есть кусок кода в котором переходы начиная с 16-го не выполнялись. Можно было предположить, что это связано с хранением данных. В результате на какой-то итерации заработало. Да, можно. Да, ограничено только длиной строки. :rolleyes:
- - - Добавлено - - -
Конверсия музыки отличная, спасибо!
Спасибо за оценку и наводку. Свою демку закончил. Решил не использовать эту музыку в демке, так что если кому-то надо для этих целей, прилагаю полную версию "Полёта шмеля" Николая Римского-нашего-Корсакова (СС уже близко): 82649
Доделал тестовый вариант rtbasic. Это потомок 2.996, остались все ускорения которые там были, найденные ошибки исправлены. Есть и новые оптимизации.
Основное отличие - автоматическое удаление незначащих пробелов, что позволило упростить и ускорить парсер. Это приводит и к некоторой несовместимости и особенностям.
1. Программы с самомодификацией могут потребовать адаптации, если там были пробелы в строках до адреса модификации.
2. Если в INPUT A$ вводите строку с пробелами, то обрамляйте ее кавычками (аналогично для DATA). Но это желательно делать и в версиях 2.5-2.9x, чтобы обойтись без непрошенной токенизации.
Главный недостаток - убраны текстовые сообщения об ошибках, вместо этого можно распечатать файл Errors.txt и положить рядом на столе.
Поддержка принтера, RENUM/AUTO и @ были убраны еще в 2.996, здесь их тоже нет. Для перенумерации можно использовать 2.998, что не очень удобно, но вариант рабочий. В свою очередь rtbasic можно использовать как утилиту для удаления незначащих пробелов. Загрузили с пробелами, выгрузили уже без пробелов.
Есть отличия и в работе пары графических операторов.
Вернул быстрое и компактное рисование линий, которое было в 2.98-2.993.
Немного замедлена сравнительно редкая операция рисования дуг в CIRCLE, зато процедура компактнее.
Указанные два момента приводят к тому, что рисунки в классических версиях и в новой могут не совпадать точка в точку, но я решил пойти на это. Если нужно абсолютное совпадение графики используйте 2.998.
metamorpho
13.08.2025, 22:12
.......... Решил не использовать эту музыку в демке, так что если кому-то надо для этих целей, прилагаю полную версию "Полёта шмеля" Николая Римского-нашего-Корсакова (СС уже близко).....
"Полёт шмеля" - звучит очень даже хорошо. Это можно на конкурс в раздел "Другие возможные категории" включить.
aGGreSSor
14.08.2025, 00:47
"Полёт шмеля" - звучит очень даже хорошо. Это можно на конкурс в раздел "Другие возможные категории" включить.
У меня была идея сделать 3D-тоннель по которому летит шмель под эту музыку, но в итоге сначала сделал что попроще (3 эффекта, 5 частей, будет на CC) и память закончилась. Так что дарю идею. Тоннель сделать просто, а спрайты в бейсике я не придумал как делать. Если знакогенератором, то там символы эти 5x8 не склеиваются, полоски по бокам. Не стал дальше голову ломать. Шатать шмеля можно было бы аппаратным скроллером. Если бы для Вектора было что-то типа zxart.ee, я бы туда загрузил и забыл. Кому-нибудь пригодилось бы. :v2_dizzy_army:
- - - Добавлено - - -
Немного замедлена сравнительно редкая операция рисования дуг в CIRCLEИспользовал эту сравнительно редкую операцию в хвост и гриву.
рисунки в классических версиях и в новой могут не совпадать точка в точку, но я решил пойти на это.
У меня всё совпало с 2.997 и 2.998. Визуально не вижу отличий. Я использовал у себя "сравнительно компактный вариант определения версии (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1216880&viewfull=1#post1216880)", чтобы отшить V2.5. Отшил. Заодно отшил и эту версию Бейсика. Проверил, что если удалить определение, то моя программа работает как и задумывалось. Никакой разницы с 2.997/2.998 (судя по описанию думал что её должно страшно перекорёжить).
Тест версии определяет RT как 2.996. Учитывая неактуальность 2.996 (там несколько ошибок, в т.ч. одна довольно серьезная), можно забыть про 2.996 и определять именно RT.
Отличия в линиях (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1198384&viewfull=1#post1198384) и дугах незначительные, но при некоторых условиях они проявляются. Что касается скорости дуг - RT рисует их медленнее 2.998, но все же быстрее 2.5.
Сразу извините за такой ламерский вопрос — а какой из вариантов Бейсика для Вектора-06Ц максимально напоминает Q(uick)Basic?
Бейсик-Корвет (https://caglrc.cc/scalar/ware/96/) или MSBASICи для CP/M
Картинки мне кажется с PC
Из Fantavision Animations (https://youtu.be/K8bMrhai7aw?t=68). Когда поступал в институт на дне открытых дверей в одной из лабораторий крутили эти анимации.
Переделал бейсиковский рейкастер с bascom (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1196971&viewfull=1#post1196971) на cbasic. Результат удручающий - 115 секунд. Львиная доля вычислений переведена на целые, но немного плавучки осталось, полный перевод - это уже будет совсем другая программа. И думаю, что дело не только в плавучке, очистку экрана (там целые) cbasic делает в 1.5 раза медленнее. Из приятного - откомпилированная программа после минимальной доработки напильником работает из загрузчика, как и после bascom.
Чем на встроенном Бейсике 2.5 можно заменить LOCATE?
Чем на встроенном Бейсике 2.5 можно заменить LOCATE?
CUR X,Y или PRINT AT X,Y, ...
В первом сообщении этой темы (https://zx-pk.ru/threads/35752-retrograd-leto-2024-konkurs-programm-dlya-vektor-06ts.html) ссылки на полезные ресурсы, в том числе новое описание Бейсика, составленное metamorpho.
CUR X,Y или PRINT AT X,Y, ...
Благодарю, про CUR прочёл в официальной документации (https://caglrc.cc/scalar/ware/698/), а вот PRINT AT (как в Sinclair Basic) упустил из виду.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot