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

[ivagor]

Сейчас бейсик в асме не нужен, но если

оффтоп

не оглядываться на вектор и воспарить мыслью, то можно увидеть картину: бейсик с асмом в пзу. Человек включает комп и сразу программает, не нужно ничего загружать.

[свернуть]

[svofski]

Вот если бы Бейсик для Вектора в 88 году так умел, тогда конечно.

[Ramiros]

заметил еще один глюк - если нажать АР2 затем УС+СС+любую клавишу, то печатаются гибриды из двух слов, (не два последовательных слова, что было бы логично, а именно какой то гибрид из начала одного слова и конца другого). Но это безобидный глюк т.к. бейсик не умирает

[x-code]

Про УС+D. Пробовал не только такое сочетание, но и УС+другие клавиши и в разных режимах (редактирования строки или работы программы). Никаких проблем не обнаружил.

Ну, чудеса... Я тут погуглил - про этот баг даже в первом выпуске "Байта" было:
http://sensi.org/scalar/media/w/vect...-33-151108.pdf (страница 6, примерно в середине страницы)

Возможно, какой-то из ваших патчей попутно починил и эту проблему?

[Ramiros]

Ну, чудеса... Я тут погуглил - про этот баг даже в первом выпуске "Байта" было:
http://sensi.org/scalar/media/w/vect...-33-151108.pdf (страница 6, примерно в середине страницы)

Возможно, какой-то из ваших патчей попутно починил и эту проблему?

Не исключаю что глюк был в ранней версии (наверное счетмашевцы его по тихому пофиксили), но в моем бейсике с кассеты такого глюка небыло точно.

[ivagor]

1.

если нажать АР2 затем УС+СС+любую клавишу, то печатаются гибриды из двух слов

Исправил.
2. Про УС+D. Не мог вспомнить, где я про это читал, оказывается в байте печатали. И тогда я уже вспомнил, что читал про это в начале 90х и у меня тогда тоже этой ошибки не было. Идей на эту тему у меня нет, "закладок" в бейсике на УС+D не нашел (смотрел исходный вариант, без моих правок). У меня был астраханский вектор, вроде как и у Ramirosa.
3. Несколько дней копался в реализации элементарных арифметических операций - умножение, деление, сложение и вычитание.
Тестировал вот на таком фрагменте:

10 FORI=1TO10000
20 A=I*I/I+I-I
30 NEXT
40 STOP

Удалось ускорить на 11% по сравнению с 2.59 или на 14%, если сравнивать с исходным 2.5. Больше и удачнее остальных операций (практически без увеличения размера) ускорилось деление. Очень не хватает команд и регистров более развитых процессоров.

[Advertiser]

[ivagor]

Добавил в предыдущий пост архив с бейсиком 2.60.

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

Опять забыл в readme упомянуть, что начиная с 2.59 в два раза уменьшена задержка при автоповторе клавиш.

[x-code]

Вспомнил ещё один глюк (а, может, и не глюк, а авторами так задумывалось). Ещё школьником экспериментировал с записью с помощью BSAVE на магнитную ленту спрайтов, сохранённых в ОЗУ с экрана оператором GET. И вот основная засада была в том, что функция ADDR не всегда корректно выдавала адрес массива в памяти. Я пытался даже подобрать формулу для расчёта корректирующего смещения, которое бы компенсировало ошибку ADDR, но эта ошибка была "плавающей" и ХЗ от чего зависела.

[ivagor]

1. Про ADDR. Думаю все же ошибок в ADDR нет, их уже пытались найти в вектор-user 7, но в 11 Филиппов показал частный пример, что все нормально. ADDR по-хорошему дубовый, нет отдельной специальной реализации этой функции, вызывается базовая функция поиска переменной. Если бы это базовая функция подглюкивала, то глючили бы практически все программы, использующие переменные (т.е. на практике все программы).
У меня есть предположение, что могло быть не так. Если GET, ADDR и BSAVE в программе, то все должно быть нормально и однозначно. А вот если GET отдельно, а ADDR и BSAVE потом из командной строки или GET и ADDR в программе, а BSAVE потом, то возможны варианты. Дело в том, что переменные "портятся" от каждого чиха. Например EDIT любой строки даже без ее редактирования (EDIT, потом сразу ВК) испортит переменные. Или удаление строки. Кстати, у EDIT и удаления строки через ввод ее номера (не через DELETE) есть неприятный побочный эффект - на 2 байта увеличивается адрес начала переменных. Если 100 раз сделать EDIT (даже без собственно редактирования строки) то область переменных уползет на 200 байт. Или 100 раз ввести строку, например 1000 REM и удалить ее через ввод номера 1000 - эффект будет аналогичный. Возвращают эту память RUN, NEW или DELETE (DELETE возвращает почти все кроме одного байта).
В GET еще в детстве раздражало требование использования ADDR. Думаю надо убрать это ограничение, не вижу в нем смысла.
2. Речь коснулась графики и я вспомнил, что в исходнике никак не отметил задание адреса таблицы для быстрого вычисления адреса и маски точки.
Адрес таблицы при расчете задается в районе метки DELETEADVERT, там lxi b, unk_4100. А используется таблица строго через mvi b,41h, в исходнике такая команда встречается 5 раз, все их надо заменить на mvi b, unk_4100>>8. Еще лучше заменить unk_4100 на нормальное имя.

[ivagor]

После некоторого размышления склоняюсь к тому, что проблема скорее возможна не при записи, а при чтении и даже после него. Единственный работающий вариант - запустили программу, объявили (инициализировали) все переменные, потом addr, потом bload и put. Если вышли из режима исполнения, то нужно быть сверхаккуратным, чтобы содержимое массива с картинкой осталось целым.