Ошибки в ИКП-бейсике

Собрался уже после этой темы http://forum.agatcomp.ru//viewtopic.php?id=148 долго и беспросветно копаться в Бейсике, но мне повезло удачно этот баг загуглить.
Вот тут есть дизассемблированный листинг Applesoft Бейсика с комментариями http://www.txbobsc.com/scsc/scdocumentor/

Нужный нам кусок - здесь: http://www.txbobsc.com/scsc/scdocumentor/E597.html
Это функция VAL, адрес $E707 (в ИКП Бейсике девятки - $E6C7).

Как видно, перед конвертированием строки в ее конец принудительно записывается нулевой байт.
Вообще, в Бейсике строки хранятся с указанием адреса и длины. Но внутренние алгоритмы (видимо для экономии на счетчике) используют C-шный формат, и для этого в конец строки принудительно прописывается нулевой байт. Тот байт, который был на месте нуля, сохраняется в стеке.

Вот только есть одна проблема. Данные переменной A$ начинаются с адреса $BFFF и занимают 1 байт. Угадайте, куда запишется нулевой байт? Правильно, в $C000.

Дальше внутренние процедуры обработают введенный символ из $BFFF, а потом вместо нуля из $C000 прочтут последний введенный символ из регистра клавиатуры. И так пройдут по всем адресам $C000-$C00F. Получив в нашем случае строку из 17 повторов последнего символа.

Потом эти процедуры прочитают адрес $C010, а там - не цифра. Парсинг остановится.
Так что бага унаследована от Applesoft. В Apple она не проявляется - когда DOS загружен, рабочая область Бейсика заканчивается на $9600 и проблем не возникает. Но ИКП-шный Бейсик использует всю память от $1900 до $BFFF и бага проявляется.

* Интересно, что на семерке такого эффекта нет - там регистр клавиатуры чистится сам, и процедура парсинга получит свой нуль.

Вылечить такое поведение ИКП-шного Бейсика можно командой

HIMEM:-16385

Либо можно в самом начале программы завести неиспользуемую строковую переменную и присвоить ей что-нибудь (но не пустую строку, конечно).

Бурные и продолжительные аплодисменты звучат из Загорска!

Сейчас прислали интересную багу бейсика (повторяется в Бейсика-60, ИКП-Бейсик-7 и Basic Master 95):

"4E" с любой последующей цифрой интерпретатор понимает как 40.
Без последующей цифры - как "4". Никаких сообщений о синтаксической ошибке.

]?4E                            
4      
       
]?4E6  
40     
       
]?4E4  
40     
       
]?4E0  
40

]?4E+0 
4

]?4E+1
40

]?4E+2 
400

]?4E+3 
4000

]?4E+4 
40000

]?4E-4 
4E-04

Попробовал в РАПИРе - там нормально всё: 4E+3 или 4E3 :

#BЫBOД:4E+3;                   
4000.0

Че-то в припоминаю в старых книжках было такое: аргументы оператора print должны быть разделены либо запятой, которая будет заменена символом табуляции, либо точкой с запятой, которая ни в каком виде не будет отображаться. Точка с запятой в конце вывода запрещает вывод символа перевода строки.
Также и вариант оператора INPUT с подсказкой: строка-подсказка должна быть отделена от имени вводимой переменной (или от списка вводимых переменных) точкой с запятой.
Это было формальное описание в каком-то бейсике.

Но в агатовском я точно помню, что строковые константы никто никогда не отделял от имён переменных.
А вот одну переменную от другой вроде бы я отделял точкой с запятой, но вообще две переменных подряд редко бывает нужно вывести, разве что результаты расчётов удобно через запятую-табуляцию выводить.
А численные константы в print вообще, наверное, нигде никто не вставлял внутри программ...

Век живи, век учись...

> Магия! Что хотели этим сказать авторы агатовских Бейсиков - не понимаю.

;) Мне кажется, они как раз с PDP реализацию TAB сделали.
Там TAB - это что-то связанное с табуляцией - т.е. с символом 011 или \t.
Он вызывает горизонтальное перемещение курсора до очередной позиции, кратной 8.
Это для рисования таблиц довольно удобная штука.

А для перехода на произвольную позицию у агатовского бейсика неплохо работает SPC и HTAB.
Ну как неплохо: HTAB не учитывает выбранный текстовый режим.
В каком-то режиме правильно работает, а в другом двоит или делит на 2 позицию... Не помню, но что-то там такое было.

> Проверил. В ИКП-7 HTAB во всех текстовых режимах работает нормально. В Бейсике 60 косячит: в Т32 все нормально, в Т64 шаг удвоенный.

Мне кажется, это даже в доках на Бейсик-60 упомянуто. Если так, то это не ошибка, а фича Ж)

> Даже странно: или работу этого оператора вообще не проверяли, или проверяли только в режиме Т64. Хотя это более удобный вариант выводить что-то в табличной форме - все можно вывести одним оператором PRINT.

Может быть правили по бинарнику, переводя с Apple ][ на Агат и где-то не хватало места для нормальной реализации.

Разобрался с оператором TAB.
Нужный кусок кода Бейсика Apple находится здесь https://www.txbobsc.com/scsc/scdocumentor/DACF.html
Процедура называется PR.TAB.OR.SPC (адрес $DB16).

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

Процедуры вывода на экран хранят горизонтальную позицию курсора в ячейке $24. Но в Агате это уже не совсем позиция курсора. В режиме Т32 это номер байта, а поскольку в этом режиме каждый символ занимает два байта (символ и его атрибут), то номер байта в два раза больше, чем позиция курсора.

Как с этим поступает Бейсик-60?
Да никак. Отличий между Apple и Бейсик-60 в коде процедуры нет (адрес $DB13).

Смотрим наш пример:

10 PRINT TAB(4);"A";TAB(8);"B"
20 PRINT "1234567890"

Поскольку первый PRINT начинается на новой строке, то значение ячейки $24 равно 0 и первый TAB работает как положено.
Однако после печати символа "A" позиция курсора равна 4, а вот значение ячейки $24 равно 8.
Второй TAB должен поставить курсор в 8 позицию. Чтобы проверить, не проехал ли он эту позицию, он берет аргумент (8) и вычитает из него единицу и значение из ячейки $24. А там тоже 8 :) Получается -1 и оператор TAB игнорируется. Символ "B" печатается сразу вслед за "A".

Похоже, багу просто не заметили.

С ИКП-7 все смешнее. Багу заметили, код исправили. Но... наполовину. Может задание на исправление было криво сформулировано, может проверять было лень, но получилась какая-то ерунда. Смотрим код:

DA98    CA        DEX           ; в X аргумент TAB, вычитаем 1
DA99    8A        TXA
DA9A    24 32     BIT    $32    ; проверяем режим (Т32/Т64)
DA9C    30 01     BMI    $DA9F
DA9E    0A        ASL           ; режим Т32, удваиваем аргумент
DA9F    38        SEC
DAA0    E5 24     SBC    $24    ; вычитаем позицию курсора, она же номер байта
DAA2    90 05     BCC    $DAA9
DAA4    AA        TAX           ; результат отдаем оператору SPC

Что сделали для исправления ошибки? Проверили видеорежим (старший бит ячейки $32 равен нулю в режиме Т32). Если включен Т64, все работает как и раньше. Если включен Т32, то аргумент TAB удваивается. Потом из него вычитается позиция курсора (которая в этом режиме равна номеру байта), и... все. Поделить результат пополам забыли.
В нашем примере аргумент первого TAB - это 4. Вычитаем 1, получаем 3. Удваиваем, получаем 6. Вычитаем номер байта (0), получаем 6. Печатаем 6 пробелов, а потом "A". Ну вот оно и вывелось в 7-й позиции. Зашибись!

Я могу сказать, для чего сам бы в те годы использовал бы что-то вроде POS.

Такой сюжет: есть прога со свободным перемещением курсора (используя стрелки, чистку экрана, enter, ввод каких нибудь символов). Прога просто читает код через GET A$, а потом вывод через PRINT A$;.

А теперь, в какие-то моменты, я хочу знать координату курсора, например, когда нажимается кнопка какой-нибудь буквы. Допустим, что я его запоминаю в массиве: символ и положение курсора (не хватает ещё какой нибудь фунции VPOS или LINE). И потом этот массив сохраняю в файл. При небольшом количестве введённых символов получается что-то вроде компактной программы рисования текствого экрана (без необходимости сохранять всё видеоозу).

В чём преимущество такого подхода: мне не нужно знать всю логику процедур движения курсора. Просто скидываю символ от ввода на вывод и фильтрую нажатия буквенных клавиш (if A$ >= "A" and A$ <= "Z").

Для начинающего программиста вполне полезная штука.

Нет, проблема только с Т32. Там номера байтов с позицией курсора не совпадают.