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

[x-code]

Ещё один способ убить Бейсик 2.5 - это нажать комбинацию УС-D. После этого он перестаёт адекватно реагировать на нажатия клавиш на клавиатуре. Это не является большой проблемой на эмуляторе, а вот на настоящем Векторе с ёмкостной клавиатурой при быстром вводе операторов с помощью комбинаций УС+СС+символ это реально "доставляло", если нажатие СС вдруг не срабатывало.

[Advertiser]

[ivagor]

Нажал УС+D - бейсик напечатал ромб и штатно продолжает реагировать на клавиатуру.

[x-code]

Нажал УС+D - бейсик напечатал ромб и штатно продолжает реагировать на клавиатуру.

Может быть, не во всех вариантах Бейсика был этот баг... но я совершенно точно помню, что в том кассетном Бейсике, который шёл в комплекте поставки к моему "Вектору", этот проклятущий баг был совершенно точно - и, в своё время, стоил мне немало вырванных подростковых волос и нервных клеток

P.S. Блин, а, может, комбинация была УС-E... помню только, что при зажатом СС эта комбинация соответствовала какому-то графическому оператору - то ли LINE, то ли CIRCLE. Я даже приучал себя вводить именно этот оператор через комбинацию АР2+буква, потому что шанс "убить" Бейсик из-за несработавшей СС был очень немаленьким.

- - - Добавлено - - -

Насчет кросс-разработки на бейсике для вектора текущее состояние такое (очень слабое).

Я бы предложил подумать сделать такое на базе VS Code. Готовая IDE, грамматика языка задаётся декларативно - причём, вероятно, может даже получиться найти готовую конфигурацию под какой-нибудь Бейсик и допилить её под специфику "Вектора". Останется дописать только взаимодействие с эмулятором и/или образом диска, что не должно представлять большой сложности.

- - - Добавлено - - -

а встроить ассемблер в бейсик слабо

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

Полагаю, на ZX Spectrum ассемблер в ZX-Basic тоже не завезли по причине жёсткого ограничения на размер образа Бейсика в ПЗУ.

[Ramiros]

Если интересно есть еще один баг: при попытке вывести множество символов в графическом режиме экран начинает скролится. я так понимаю глюк сидит в операторе PRINT.
Вот пример:

[ivagor]

Эту штуку я припоминаю. Проблему можно значительно уменьшить (но не устранить полостью), если в конце PRINT поставить ;
Еще вроде я ставил между такими операторами CUR с верхним левым углом, т.е. тут не смертельно, скорее неприятно при больших объемах вывода с LINE BS. Может попробую посмотреть.

[ivagor]

Нашел в vector-user 7 такой список ошибок бейсика 2.5:
1. Ненужная токенизация для символьных переменных в INPUT - исправил в 2.57
2. "Левый" скролл при использовании LINE BS - исправил, пока не выложил
3. Якобы ошибка в ADDR - там нет ошибки, Филиппов в vector-user 11 это продемонстрировал
4. Ошибка в RENUM при некоторых неясных условиях.
Понятно, что список не полный, но свои любимые ошибки я уже исправил и про них можно прочитать в readme.

Остается RENUM. Кто-нибудь сталкивался с ошибками в его работе? Если да, то при каких условиях? Сам я не сталкивался и сейчас не смог привести RENUM к ошибке, возможно это ложная тревога, к с ADDR.

[Ramiros]

Я сталкивался с ошибками в RENUM, старался его использовать крайне редко и только когда программа уже готова (предварительно сохранив). Обычно если в программе нет ошибок переходов то все было нормально, но вот иногда в THEN, GOTO, GOSUB адреса переходов слетали, почему уже непомню.

[ivagor]

Посмотрел как реализован RENUM, криминала не нашел и без примера неправильной работы вряд ли смогу найти.
Попутно заметил, что в двух из четырех случаев вызова процедуры CHECKCROSSWITHSTACK забыл изменить следующий байт с команды на данные. Это не приводит к проблемам при компиляции исходника, но для наглядности и правильности исходника все же стоит его поправить, у себя поправил.

- - - Добавлено - - -

И все же я понял, в чем проблема. Дело не в размере программы (в VU7 написали про ошибки RENUM "особенно в длинных программах"), а в сочетании двух факторов - должна быть ссылка на последнюю строку и перед этим должен был быть хоть один сдвиг списка номеров в сторону уменьшения. Проще всего (я так и сделал в 2.58) при сдвиге в сторону уменьшения пересылать на 1 байт больше. Можно убедиться на renumtest, если после загрузки сделать RENUM1,1 то в других бейсиках во второй строке будет неправильный номер строки в GOTO. Это проблема не только BASIC2.5, а еще оригинального бейсика-микрон. Проверил только РКшный оригинал, но скорее всего и во всех его адаптациях на другие компы этот баг тоже есть.
Наивно надеюсь, что теперь все ошибки исправлены.

- - - Добавлено - - -

скорее всего и во всех его адаптациях на другие компы этот баг тоже есть.

Еще попробовал Апогей, Специалист и Искру-1080 (renum 1) - эта ошибка есть.

[lafromm31]

Renum глючил, когда замена номеров строк - приводила к тому, что на некоторых строках количество символов стало превышать максимальное количество символов в строке.

[ivagor]

Этот случай можно сказать противоположный тому, что я пропатчил (там в сторону уменьшения, здесь - увеличения). Более того, можно даже просто в режиме редактирования ввести строку, которая будет давать ошибку для LIST и EDIT из за размера.