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

[metamorpho]

....Чтобы можно было запускать повторно надо изменить в строке 83 переход на строку 91 вместо 93.

Спасибо за подсказку !! Исправил - загрузил новый файл.

Про резервы ANTIGRAV по размеру. Массив GROT(32,32) можно безболезненно урезать до (31,31) и даже не менять программу. Если менять программу, то можно выиграть еще 3 Кб - вместо DIM организовать байтовый массив с использованим POKE и PEEK.

Ого 3 Кб это ж целое состояние. Интересно что быстрее обращение к массиву или чтение PEEK ?

Вредный совет - все имена переменных можно сократить до 2 букв, все равно эта ветка бейсиков больше не учитывает.

Хороший совет. Был момент когда я заподозрил что что-то не так с длиной переменных - я не понимал почему длинные имена переменных разные а Бейсику всё равно. А оно оказывается вон что происходит.

Хочу написать несколько мыслей по поводу ANTIGRAV, надеюсь в них есть конструктивность.
1. Можно попробовать все же реализовать концепцию basic-only изменив принцип управления. Пусть нажатие клавиши задает направление движения не на одну позицию, а до упора или до нажатия другой клавиши. Возможно тогда INKEY$ все же более-менее подойдет. Чтобы уменьшить влияние буферизации кнопку действия лучше перенести с пробела на СС и опрашивать по INP. Тогда, кстати, можно одновременно опрашивать две клавиши штатными средствами. Есть еще РУС/ЛАТ, но к нему привязана лампочка, хотя этот недостаток можно попробовать обратить в достоинство, если придумать какую-то игровую механику.

Да идея basic-only заманчива.
В Байт №5 1991 г. в теме:"Машинные программы в Бейсике." там в конце этой темы написано:
"....с адреса 2CFCH располагается подпрограмма ввода кода нажатой клавиши без ожидания нажатия....в регистре А при выходе находится код нажатой клавиши (аналогично использованию ASC(INKEY$))"
Эта подпрограмма тоже самое что обычный INKEY$ или она отличается чем-то ?

Ещё по поводу опроса клавиатуры пришла такая идея (не знаю насколько просто или тяжело она реализуема) -
я предполагаю в Бейсике подпрограмма INKEY$ имея некий буфер складывает туда "нажатые клавиши".
Следовательно некоей командой (например INX D) меняется текущая ячейка буфера куда пишется очередной символ.
А что если аккуратно заменить этот INX D на команду NOP ? Тогда по идее буфер "умирает", а INKEY$ будет писаться только в одну ячейку отражая последнюю нажатую клавишу. Реально ли это ?

2. Если же оставить машинокодовый опрос, то почему-бы не решить ассемблером и другую проблему - скорость рисования уровня.

Кто-то тогда сможет сказать: "Ну это уже не Бейсик а АССЕМБЛЕР."

3. Игра на бейсике, поэтому тут не до быстроты реакции, я однозначно за это. Но было бы здорово добавить элемент головоломки, чтобы немного подумать над порядком выключения лазеров и открытия дверей.

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

[ivagor]

Эта подпрограмма тоже самое что обычный INKEY$ или она отличается чем-то ?

INKEY$ первым делом вызывает эту подпрограмму.

предполагаю в Бейсике подпрограмма INKEY$ имея некий буфер складывает туда "нажатые клавиши".
Следовательно некоей командой (например INX D) меняется текущая ячейка буфера куда пишется очередной символ.
А что если аккуратно заменить этот INX D на команду NOP ? Тогда по идее буфер "умирает", а INKEY$ будет писаться только в одну ячейку отражая последнюю нажатую клавишу. Реально ли это ?

Коды клавиш в буфер складывает не INKEY, а обработчик прерывания, а INKEY читает оттуда. Идея с полным убиранием буфера мне не нравится по нескольким причинам:
1. Это изменит реакцию на клавиатуру в бейсике в целом.
2. Внедрение в прерывание легко сделать единообразно для разных версий бейсика, а вот если патчить работу с буфером или INKEY - это резко ограничивает свободу модификации бейсика, тут я против.
3. Внедренец в прерывание позволяет (в отличие от INKEY) опрашивать несколько клавиш одновременно.

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

что быстрее обращение к массиву или чтение PEEK

Одномерный массив быстрее POKE и PEEK, скорее всего двумерный тоже. По крайней мере если в POKE и PEEK использовать конструкции типа POKE BASE+I или PEEK(BASE+I).

[metamorpho]

INKEY$ первым делом вызывает эту подпрограмму.

Так её можно использовать для безбуферного опроса или она тоже с буфером ?
Что она выдаёт на выходе - символ из буфера или только что нажатый ?

Коды клавиш в буфер складывает не INKEY, а обработчик прерывания, а INKEY читает оттуда.
Идея с полным убиранием буфера мне не нравится по нескольким причинам:

1. Это изменит реакцию на клавиатуру в бейсике в целом.

- Пожалуй неудобство будет ощутимо для тех у кого реальный Вектор с кассетой, им придётся для другой программы
перезагрузить Бейсик. Все остальные варианты (с дисководами и квазидисками) пострадают похоже не особо сильно. Ну а
с возможностями эмуляторов это вообще не проблема.

2. Внедрение в прерывание легко сделать единообразно для разных версий бейсика, а вот если
патчить работу с буфером или INKEY - это резко ограничивает свободу модификации бейсика, тут я против.

- Это достаточно глобальный подход. Но с другой стороны делать версию игры под каждый Бейсик (я так понимаю что
речь идёт про Бейсик v2.5 стандартный, Бейсик М и Бейсик 2.63) наверно тоже не очень хорошая идея. Хотя есть подобие
- несовместимость новых программ со старыми версиями ОС или старых программ с новыми ОС - частая история.
Ещё можно сделать проверку версии Бейсика и в зависимости от этого сделать соответствующие изменения, но это уже
получится довольно громоздкая конструкция.

3. Внедренец в прерывание позволяет (в отличие от INKEY) опрашивать несколько клавиш
одновременно.

- Для игр в пределах Бейсика обычно достаточно одновременно знать только про одну клавишу, так что возможность
опрашивать несколько клавиш одновременно - нужно ли это.

Однако в целом в итоге пожалуй идея с отключением буфера сквозит минусом больше чем плюсом.

Одномерный массив быстрее POKE и PEEK, скорее всего двумерный тоже. По крайней мере если в
POKE и PEEK использовать конструкции типа POKE BASE+I или PEEK(BASE+I).

Т.е. перед нами стоит выбор - или сэкономить память но будет медленее - или будет немного быстрее но "- 3 Кб".
Если разница в скорости не сильно большая, то пожалуй можно было бы и перейти на чтение массива через PEEK.

[ivagor]

Так её можно использовать для безбуферного опроса или она тоже с буфером ?
Что она выдаёт на выходе - символ из буфера или только что нажатый ?

Весь опрос клавиатуры в бейсике через буфер, в т.ч. INKEY.

Что касается низведения буфера до 1 символа - минусы я перечислил, а в чем плюсы такого варианта?

[metamorpho]

.....Что касается низведения буфера до 1 символа - минусы я перечислил, а в чем плюсы такого варианта?

При условии что моё представление об отключении буфера было бы правильно, то плюсом является более короткая программа для достижения нужного нам опроса клавиатуры. Т.е. если бы буфер отключался через блокирование некоего INX D, тогда нам нужно было бы например XRA A/STA NNNN/RET всего 5 байтов вместо 42 байт для внедрения в прерывания.
И чисто философически мы бы больше вписывались в вариант basic-only, т.к использовали INKEY$ (только немного
модифицированый под наши потребности - мы всего лишь заменили 1 байт программы).

[ivagor]

И чисто философически мы бы больше вписывались в вариант basic-only, т.к использовали INKEY$ (только немного
модифицированый под наши потребности - мы всего лишь заменили 1 байт программы).

Тут я не согласен, нельзя быть немножко беременным. Любая модификация бейсика требует небольшой ассемблерной программки (т.к. штатными средствами он модифицировать себя не даст), а значит уже не basic-only.
Плюс понятен - программа модификации короче. На мой взгляд это совсем не перевешивает озвученные минусы, особенно совместимость с разными версиями бейсика, в т.ч. гипотетическими будущими.
Тем не менее если хочешь попробовать, то достаточно заменить по двум адресам (в 2.5: 2EBF и 2D13) 3C на 00.

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

А можно занулить предыдущие (в 2.5: 2EBE и 2D12) адреса, результат будет аналогичный. Но и в первом озвученном варианте и во втором зануляем 2 адреса, 1 не получится.

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

Кстати, у INKEY есть еще недостаток по сравнению со "своим" опросом - задержки автоповтора. В этом смысле 2.61-2.63 лучше, т.к. там эти задержки меньше.

[Improver]

Я, может, глупость сейчас предложу: а что если дополнить бейсик ещё одним оператором, который будет читать код последней нажатой клавиши? Без учёта буфера, или с его очисткой, "Readkey" назвать, например... Это решит все проблемы в новых программах и сохранит совместимость со старыми.

[ivagor]

На msx для этого добавили функции STICK() и STRIG(). STICK() позволяет опрашивать клавиши курсора (в т.ч. диагональные комбинации) или наклоны джойстика. STRIG() опрашивает "пробел" или кнопки джойстика. В бейсике 6128 даже добавили эти функции, но реализовали их так плохо, что опрос клавиатуры через них может привести к зависанию программы. Можно добавить в бейсик эти функции, но в предыдущих версиях их не будет.

[svofski]

Мне запомнилось, что в Бейсике может встречаться такая конструкция (пример из BLOKIGR.BAS)

308 IFK=1ANDT(J0+J*K,I0+I*K)=ATHEN 312

И это доставляет, потому что простой лексер не может сделать выбор между токенами AT и THEN. Нужно придумывать что-нибудь, типа выбирать совпадение подлиннее. Решил проверить, правда ли он такой умный. Пробую написать тест в 2.5:

10IFA=ATHEN20

И на это получаю синтаксическую ошибку. Уходит ошибка только если я ставлю пробел между A и THEN. Или IFB=BTHEN20, тогда тоже проблем нет. Что я не понимаю про строку 308, почему там Бейсик 2.5 не спотыкается?

Еще забавнее -- если сделать EDIT 308 и нажать ENTER, то эта строка тоже начинает выдавать синтаксическую ошибку. Значит токены в этом .BAS файле не из этого Бейсика.

[ivagor]

У меня два предположения:
1. При редактировании ввели заготовку строки, например
10IFA=BTHEN20
потом уже в токенизированном представлении изменили B на A в памяти.
2. Если есть другая версия бейсика, где вместо THEN этот токен был GOTO

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

Есть еще вариант, как мне кажется наиболее вероятный. Изначально строка была с пробелами, но ее обработали убирателем пробелов. Это значит, что или игра с РК/Микроши или убиратель пробелов адаптировали и для 2.5 (что совсем не трудно, учитывая, что он потомок РКшного Микрона).