Вид для печати
Не то, что для использования, скорее для разработки -- делать одну универсальную версию проще, чем поддерживать актуальность нескольких. Хотя, случаи всякие бывают, может тут универсальность только навредит, не возражаю.Цитата:
Сообщение от ivagor
Интересный момент, не знал этого. А насколько Basic48k по другим оптимизациям отличается от более позднего 2.62? Может его тоже пора обновить? ;)Цитата:
Сообщение от ivagor
Согласен, это тоже нужно.Цитата:
Сообщение от ivagor
Еще проще не поддерживать актуальность, и к сожалению, на данный момент я следую этим путем. Фактически три ветки: бейсик для ВМ1 - упор на ускорение, в т.ч. графики, исправлены некоторые баги; basic48k - возможность делать большие программы, исправлены некоторые баги; basic 2.62 - исправлены все известные баги (там где это не мешает совместимости) и некоторое ускорение. Последнее направление наиболее актуально, первое скорее всего все (т.к. ВМ1 актуален только для коллекционеров), второе под вопросом.Цитата:
Сообщение от Improver
basic48 несколько уступает в скорости работы с графикой, т.к. приходится щелкать страницами, но не сильно.
Привет всем...
Думаю компилятор для Basic' a проще будет -
на основе драйверов устройств сделать...
???
На Спектруме - есть множество компиляторов...
Можете глянуть...
MCoder2, Tobos, Blast и тд...
Была целая кассета компиляторов...
Может что и подойдет...
Наконец-то довёл свой эксперимент до более-менее логического завершения.
Эксперимент называется "База ХТ1024". Всё дело происходило на Windows 7 32bit.
Текст программы редактировался с помощью утилиты Vector06CBasic и обычного текстового редактора. Утилита
Vector06CBasic вполне чётко справляется со своей главной задачей - конвертирование. Однако если бы там был более
богатый выбор цветовых тем и наличие более чёткого шрифта - тогда было бы совсем хорошо (однако в целом это не
обязательно т.к. есть куча удобных текстовых редакторов). Ещё заметил такое неудобство в Vector06CBasic - когда
переключаешься с одного окна на другое через ALT+Tab то нужно сначала щёлкнуть на поле конвертора и только потом
далее что-то делать можно.
Тестировал программу в эмуляторе VV. Там насколько я понимаю грузится стандартный Бейсик v2.5
Интересно что после загрузки в Бейсик, программа первый раз работает нормально, а потом я нажимал F12 и снова
запускал программу и она выдаёт ошибку - это похоже что остатки некоторых данных от первого запуска сохраняются в
памяти, а при повторном запуске получается "столкновение" интересов и сбой (так что если хотите второй раз запустить
программу, то нужно нажать F11 и повторить загрузку Бейсика и программы). При этом вспомнилось как я пытался в
детстве писать программы на Бейсике и записывал это на магнитную ленту кассет (по два раза на всякий случай) - и
постоянно в напряжении (пока не записал на кассету) с мыслями главное чтобы не отключили свет или чтобы не зависла
программа - т.к. при данных событиях был примерно такой по смыслу возглас - "шеф всё пропало...." т.е. всё что "набрано
непосильным трудом" исчезло и теперь нужно снова набирать программу - да это было то ещё испытание нервов - но всё
же вдохновлённые умы шли вперёд и делали свои шедевры :)
Приступая к этому проекту поначалу думал что сейчас по быстренькому напишу програмку (это ведь Бейсик), но
то и дело спотыкался об специфику Векторовского синтаксиса Бейсика. Также поначалу долго не мог понять почему
выдавалась непонятная ошибка - оказалось что в конце текста на Бейсике (вконце последней строки) нужно нажать Enter,
это таков формат Бейсик текста - а без этого будет выдавать непонятную ошибку и попробуй догадайся что же случилось.
Далее очень скоро начались проблемы с нехваткой памяти. Пришлось укрощать код прогрммы, особенно помогло
удаление почти всех комментариев REM (так как я довольно много их составлял). Далее время ушло на выяснение вопроса
- какой способ вывода графики наиболее быстрый.
Протестировал четыре следующих варианта вывода спрайта 8Х8:
вариант_1 = используя рисование прямоугольника с маской LINE BF (в одну плоскость)
вариант_2 = используя прямую запись в экран через POKE (в одну плоскость)
вариант_3 = используя подпрограмму в машинных кодах и её вызов через USR (в одну плоскость)
вариант_4 = используя вывод графики командой PUT
Насколько я выяснил все способы оказались почти одинаково медлены. Особенно удивил вариант подпрограммы в
машинных кодах и её вызов через USR, я думал что будет быстрее других, но нет. Скорее всего если бы размеры спрайта
были более крупными, тогда сила ассемблера проявилась бы.
Хотя вначале я выбрал вариант 4 (вывод через PUT) т.к. мне показалось что он немного более быстрее выводит
спрайт и им более удобно работать, но в итоге всё переделал и вывод главного героя я сделал через прямую запись в
экран командой POKE (в одну плоскость). Это стало необходимо поскольку память с PUT вариантом быстро закончилась т.к.
использование PUT оказалось довольно громоздким (для него нужно резервировать массив + рисуем главного героя +
запоминаем через GET).
Скорость персонажа в итоге получилась как на соревнованиях улиток :)
Кажется я изобрёл новый игровой жанр "пошаговый платформер" :) (хотя нет он и до этого существовал).
Но как бы всё работало на АССЕМБЛЕРЕ ? В эмуляторе VV есть кнопка F10, которая включает 12Мгц и "улитка"
существенно ускоряется.
В этом проекте также есть фон (одноцветный) в некоторых местах, а также есть места где персонаж оказывается
за объектом и его видно лишь частично - реализовано этос помощью размещения графики в разных плоскостях - это
несомненно сильная сторона Вектора.
В конце уровня ракета взлетает, но полностью не улетает в космос т.к. проблема - команда PUT (выводящая
ракету) спотыкается когда при вертикальным скроле координата Y сталкивается с границей-переходом от 255 сразу в
ноль, PUT не умеет это различать. Я хотел было сделать полёт ракеты через POKE, но решил что достаточно того что есть
(показано как ракета взлетает) в данном варианте исполнения проекта.
Программа почти вся на Бейсике, кроме одного - машинный код в программе используется для опроса
клавиатуры (спасибо Ivagor за код), т.к. INKEYS Бейсика из-за создаваемого им буфера нажатых клавиш - препятствует
тому чтобы сразу реагировать на изменения направления движения (если игрок жмёт например вправо или влево то всё
это копится в буфере и пока он не опустошён никуда в другую сторону не повернёшь).
На определёном этапе написания программы снова вылезло сообщение "нет памяти" - поэтому решил немного
ужать уровень-карту игры. REM вначале программы это "сжатый" уровень. Можно было ещё сжать, но появившейся
свободной памяти уже хватало.
Код программы наверное можно в чём-то оптимизировать и возможно это прибавит совсем немного скорости, но
решил этого не делать т.к. цель в основном другая была - проверить идею анимации с помощью палитры цветов. Да кстати
из всего что вы видите на экране - рисуется только персонаж - всё остальное анимируется через изменение палитры
цветов. Эксперимент удался - результаты мне понравились. Конечно слишком много вариантов анимации и различных
цветов не получится для одного экрана, но в разных уровнях игры можно использовать другие цвета и другие "обекты" для
анимации с помощью палитры - так что в целом возможно неплохое разнообразие (в рамках Вектора).
Ощущение от использования Бейсика v.2.5 - для своего времени (80-х) это было конечно мощно и хорошая идея
+ некоторые "хитрые" знания + некоторое количество фантазии смогли бы и без использования машинных кодов сделать
"небыстрые" интересные проекты (что впрочем отчасти и было сделано многими энтузиастами того времени).
Этот же проект возможно в том или ином виде когда-нибудь воплотится но уже будет сделан полностью на ассемблере.
Для жедающих посмотреть-потестировать это произведение - в приложении (см. файл ниже) текст программы на Бейсике
для Вектора 06Ц. Для загрузки уровня можно включить ускорение F10, а потом включить нормальный режим F9. Клавиши
управления: курсорные стрелки и пробел. Нашему персонажу по какой-то причине нужно покинуть космическую базу
XT1024, улетев на космическом корабле. Для этого нужно открыть все двери - это делается через пульты управления -
заходим на пульт нажимаем пробел и дверь открывается. В самом конце не забудьте открыть большую дверь над ракетой,
иначе не взлетит. Открыв все двери поднимаетесь на космиечский корабль и улетаете....
Вложение 78619
https://www.youtube.com/watch?v=4Nx6WEU4HsA
Впечатлен, не ожидал такого. Вроде бы идея лежала на поверхности, но не могу вспомнить, чтобы в игрушке на бейсике палитра использовалась для анимации многочисленных элементов уровня. Для полного счастья не хватает скорости.
Чтобы можно было запускать повторно надо изменить в строке 83 переход на строку 91 вместо 93.
Присоединяюсь, впечатляюсь вместе с ivagor-ом. Очень крутая получилась игрушка. Анимация уровня просто отличная.
Для бейсика - очень впечатляюще! Круто!
Доработал бейсик до 2.63, теперь там можно внедряться в обработчик прерывания как в 2.5. Просто раньше не было в открытом доступе игрушек требующих такую фичу (свои я не выкладывал), а теперь это нужно для BAZAXT1024/ANTIGRAV.
Про резервы ANTIGRAV по размеру. Массив GROT(32,32) можно безболезненно урезать до (31,31) и даже не менять программу. Если менять программу, то можно выиграть еще 3 Кб - вместо DIM организовать байтовый массив с использованим POKE и PEEK. Вредный совет - все имена переменных можно сократить до 2 букв, все равно эта ветка бейсиков больше не учитывает.
Хочу написать несколько мыслей по поводу ANTIGRAV, надеюсь в них есть конструктивность.
1. Можно попробовать все же реализовать концепцию basic-only изменив принцип управления. Пусть нажатие клавиши задает направление движения не на одну позицию, а до упора или до нажатия другой клавиши. Возможно тогда INKEY$ все же более-менее подойдет. Чтобы уменьшить влияние буферизации кнопку действия лучше перенести с пробела на СС и опрашивать по INP. Тогда, кстати, можно одновременно опрашивать две клавиши штатными средствами. Есть еще РУС/ЛАТ, но к нему привязана лампочка, хотя этот недостаток можно попробовать обратить в достоинство, если придумать какую-то игровую механику.
2. Если же оставить машинокодовый опрос, то почему-бы не решить ассемблером и другую проблему - скорость рисования уровня.
3. Игра на бейсике, поэтому тут не до быстроты реакции, я однозначно за это. Но было бы здорово добавить элемент головоломки, чтобы немного подумать над порядком выключения лазеров и открытия дверей.
metamorpho, класная задумка и реализация! Прикольно было надлюдать как строиться уровень :) Рокета только застряла и так не вылетела в космос, а в осталальном все супер! :)
Спасибо за подсказку !! Исправил - загрузил новый файл.Цитата:
Сообщение от ivagor
Ого 3 Кб это ж целое состояние. Интересно что быстрее обращение к массиву или чтение PEEK ?Цитата:
Сообщение от ivagor
Хороший совет. Был момент когда я заподозрил что что-то не так с длиной переменных - я не понимал почему длинные имена переменных разные а Бейсику всё равно. А оно оказывается вон что происходит.Цитата:
Сообщение от ivagor
Да идея basic-only заманчива.Цитата:
Сообщение от ivagor
В Байт №5 1991 г. в теме:"Машинные программы в Бейсике." там в конце этой темы написано:
"....с адреса 2CFCH располагается подпрограмма ввода кода нажатой клавиши без ожидания нажатия....в регистре А при выходе находится код нажатой клавиши (аналогично использованию ASC(INKEY$))"
Эта подпрограмма тоже самое что обычный INKEY$ или она отличается чем-то ?
Ещё по поводу опроса клавиатуры пришла такая идея (не знаю насколько просто или тяжело она реализуема) -
я предполагаю в Бейсике подпрограмма INKEY$ имея некий буфер складывает туда "нажатые клавиши".
Следовательно некоей командой (например INX D) меняется текущая ячейка буфера куда пишется очередной символ.
А что если аккуратно заменить этот INX D на команду NOP ? Тогда по идее буфер "умирает", а INKEY$ будет писаться только в одну ячейку отражая последнюю нажатую клавишу. Реально ли это ?
Кто-то тогда сможет сказать: "Ну это уже не Бейсик а АССЕМБЛЕР." :)Цитата:
Сообщение от ivagor
Да согласен - это было бы лучше. Да и других разных фишек можно добавить, но это в случае если дальше реализовывать игру на Бейсике. Но для меня развитию этого проекта в Бейсике сильно мешает скорость "бега" персонажа.Цитата:
Сообщение от ivagor
INKEY$ первым делом вызывает эту подпрограмму.Цитата:
Сообщение от metamorpho
Коды клавиш в буфер складывает не INKEY, а обработчик прерывания, а INKEY читает оттуда. Идея с полным убиранием буфера мне не нравится по нескольким причинам:Цитата:
Сообщение от metamorpho
1. Это изменит реакцию на клавиатуру в бейсике в целом.
2. Внедрение в прерывание легко сделать единообразно для разных версий бейсика, а вот если патчить работу с буфером или INKEY - это резко ограничивает свободу модификации бейсика, тут я против.
3. Внедренец в прерывание позволяет (в отличие от INKEY) опрашивать несколько клавиш одновременно.
- - - Добавлено - - -
Одномерный массив быстрее POKE и PEEK, скорее всего двумерный тоже. По крайней мере если в POKE и PEEK использовать конструкции типа POKE BASE+I или PEEK(BASE+I).Цитата:
Сообщение от metamorpho
Так её можно использовать для безбуферного опроса или она тоже с буфером ?Цитата:
Сообщение от ivagor
Что она выдаёт на выходе - символ из буфера или только что нажатый ?
- Пожалуй неудобство будет ощутимо для тех у кого реальный Вектор с кассетой, им придётся для другой программыЦитата:
Сообщение от ivagor
перезагрузить Бейсик. Все остальные варианты (с дисководами и квазидисками) пострадают похоже не особо сильно. Ну а
с возможностями эмуляторов это вообще не проблема.
- Это достаточно глобальный подход. Но с другой стороны делать версию игры под каждый Бейсик (я так понимаю чтоЦитата:
Сообщение от ivagor
речь идёт про Бейсик v2.5 стандартный, Бейсик М и Бейсик 2.63) наверно тоже не очень хорошая идея. Хотя есть подобие
- несовместимость новых программ со старыми версиями ОС или старых программ с новыми ОС - частая история.
Ещё можно сделать проверку версии Бейсика и в зависимости от этого сделать соответствующие изменения, но это уже
получится довольно громоздкая конструкция.
- Для игр в пределах Бейсика обычно достаточно одновременно знать только про одну клавишу, так что возможностьЦитата:
Сообщение от ivagor
опрашивать несколько клавиш одновременно - нужно ли это.
Однако в целом в итоге пожалуй идея с отключением буфера сквозит минусом больше чем плюсом.
Т.е. перед нами стоит выбор - или сэкономить память но будет медленее - или будет немного быстрее но "- 3 Кб".Цитата:
Сообщение от ivagor
Если разница в скорости не сильно большая, то пожалуй можно было бы и перейти на чтение массива через PEEK.
Весь опрос клавиатуры в бейсике через буфер, в т.ч. INKEY.Цитата:
Сообщение от metamorpho
Что касается низведения буфера до 1 символа - минусы я перечислил, а в чем плюсы такого варианта?
При условии что моё представление об отключении буфера было бы правильно, то плюсом является более короткая программа для достижения нужного нам опроса клавиатуры. Т.е. если бы буфер отключался через блокирование некоего INX D, тогда нам нужно было бы например XRA A/STA NNNN/RET всего 5 байтов вместо 42 байт для внедрения в прерывания.Цитата:
Сообщение от ivagor
И чисто философически мы бы больше вписывались в вариант basic-only, т.к использовали INKEY$ (только немного
модифицированый под наши потребности - мы всего лишь заменили 1 байт программы). :)
Тут я не согласен, нельзя быть немножко беременным. Любая модификация бейсика требует небольшой ассемблерной программки (т.к. штатными средствами он модифицировать себя не даст), а значит уже не basic-only.Цитата:
Сообщение от metamorpho
Плюс понятен - программа модификации короче. На мой взгляд это совсем не перевешивает озвученные минусы, особенно совместимость с разными версиями бейсика, в т.ч. гипотетическими будущими.
Тем не менее если хочешь попробовать, то достаточно заменить по двум адресам (в 2.5: 2EBF и 2D13) 3C на 00.
- - - Добавлено - - -
А можно занулить предыдущие (в 2.5: 2EBE и 2D12) адреса, результат будет аналогичный. Но и в первом озвученном варианте и во втором зануляем 2 адреса, 1 не получится.
- - - Добавлено - - -
Кстати, у INKEY есть еще недостаток по сравнению со "своим" опросом - задержки автоповтора. В этом смысле 2.61-2.63 лучше, т.к. там эти задержки меньше.
Я, может, глупость сейчас предложу: а что если дополнить бейсик ещё одним оператором, который будет читать код последней нажатой клавиши? Без учёта буфера, или с его очисткой, "Readkey" назвать, например... Это решит все проблемы в новых программах и сохранит совместимость со старыми.
На msx для этого добавили функции STICK() и STRIG(). STICK() позволяет опрашивать клавиши курсора (в т.ч. диагональные комбинации) или наклоны джойстика. STRIG() опрашивает "пробел" или кнопки джойстика. В бейсике 6128 даже добавили эти функции, но реализовали их так плохо, что опрос клавиатуры через них может привести к зависанию программы. Можно добавить в бейсик эти функции, но в предыдущих версиях их не будет.
Мне запомнилось, что в Бейсике может встречаться такая конструкция (пример из 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 файле не из этого Бейсика.
У меня два предположения:
1. При редактировании ввели заготовку строки, например
10IFA=BTHEN20
потом уже в токенизированном представлении изменили B на A в памяти.
2. Если есть другая версия бейсика, где вместо THEN этот токен был GOTO
- - - Добавлено - - -
Есть еще вариант, как мне кажется наиболее вероятный. Изначально строка была с пробелами, но ее обработали убирателем пробелов. Это значит, что или игра с РК/Микроши или убиратель пробелов адаптировали и для 2.5 (что совсем не трудно, учитывая, что он потомок РКшного Микрона).
Вот. Я тоже заподозрил, что должен быть какой-то пробелоубиратель. Правда тогда непонятно, почему в GOTO, GOSUB, THEN оставлены пробелы перед номерами строк. Там можно было бы сэкономить. Но в остальном уж очень регулярное отсутствие пробелов в таком большом листинге, вряд ли нормальный человек не вставил бы пробельчик-другой, если это было написано вручную.
Описание РКшной утилиты с возможностью компактирования. РКшного бинарника не нашел, попробовал специалистовский вариант (полный аналог) - убирает все пробелы.
Еще пара версий: или ту игрушку компактировали и потом еще редактировали с попутным добавлением пробелов или ее могли портировать из домикрона (там не было AT).
А где можно скачать cas. или txt. файлы программ для Бейсика ?
@lafromm31 передает привет и вот такой архив.Цитата:
Сообщение от metamorpho
lafromm31 и svofski спасибо !!Цитата:
Сообщение от svofski
Видно, что идея с каталогом программ на Бейсик продолжает жить :v2_thumb:
Снова привязалась идейка - увернуться не получается :) так что снова создаю и снова на чисто Бейсике.
В проекте планируются очень большие спрайты обычным DATA память Бейсика не вмещает (а ещё и музыку хочу если получиться уместить).
Пробовал идею HIMEM-ом увеличить память и загрузить через DATA спрайты, далее рисуем один спрайт в одной плоскости и DELETE строки с использованными DATA, далее включаем следующую плоскость и дальше грузим DATA и т.д. Но не тут то было, DELETE после выполнения выбрасывает из программы в Бейсик - а хотел по быстренькому нарисовать картину маслом и радоваться :)
Загружать дополнительный файл - не очень вариант.
Начал думать как их сжать - просто сжать данные в DATA не хватает.
Нужно избавиться от DATA - тут есть вариант "REM строка", но спрайты используют 165 различных байта, а в строке символ кодирует от 0-127 (и то есть специфичные как их закрутить тоже вопрос) предел.
Или же можно закрутить в REM строку любой код от 0 до 255 ?
А ещё придумал как сжать спрайт закодировав его в пределах символов с кодами 0-127, однако
нужно как-то определить крайний бит числа, т.е. например число (0)1010111 нужно определить бит (0 или 1) который в скобках.
Функция SGN похоже про другое и не поможет.
Можно ли это сделать чисто на Бейсике (может какие-то хитрости есть) ?
И ещё, получится ли OUT-ом на Бейсике извлекать звук, например похожим на гром грозы ?
Почему? Хороший пример - Бизнес, если бы его авторы захотели нарисовать картинку из DATA, то ничего похожего на полноцветное полноэкранное изображение у них бы не получилось.Цитата:
Сообщение от metamorpho
Можно, но для автоматизации процесса нужна утилита. Или добавление такой опции в существующие конвертеры.Цитата:
Сообщение от metamorpho
переменная AND 128=128 (или =0)Цитата:
Сообщение от metamorpho
Там ноль разве можно?Цитата:
Сообщение от ivagor
С ограничениями, REMы нужно поместить в конце программы (и не надо туда передавать управление) и чтобы там не было трех и более нулей подряд.Цитата:
Сообщение от svofski
Можно, но плавно.Цитата:
Сообщение от ivagor
Извините, был неправ. В памяти можно исправить и оно там лежит. Но если мы загружаем, то выполняется "привязка по месту" и она все испортит. Т.е. нули в REM не прокатят,увы.
- - - Добавлено - - -
Можно придумать хитрые правила байт-стаффинга, чтобы "безопасно" кодировать нули, но проще (хотя и больше по размеру) согласиться на классические 2 символа (образующие 16-ричное число) на байт в DATA.
Привет всем...Цитата:
В проекте планируются очень большие спрайты обычным DATA память Бейсика не вмещает (а ещё и музыку хочу если получиться уместить).
Насколько я помню...
Была команда - bload ""...
???
Все же два байта на один исходный расточительно. Когда кодировали вручную, это еще было приемлемо в связи с простотой, но сейчас уж точно никто вручную большие объемы кодировать не будет (да и раньше утилитами пользовались).
1. Base64
2. Более компактное представление и более простое для декодирования: используем один байт в качестве префикса для кодирования двух значений - его самого и нуля. В идеале надо брать в качестве префикса самый редкий байт.
Короткий бессмысленный тестик:
20 FORI=1TO10000
30 NEXT
Бейсик-Корвет (версия для 06Ц) - 14.19 секунды
Бейсик-Сигнал (версия для 06Ц) - 13.28 секунды
Бейсик-М - 12.96 секунды
2.5 - 12.94 секунды
Бейсик-6128 (06Ц) - 12.76 секунды
Бейсик-Сигнал (1200) - 12.67 секунды
1.3 - 12.59 секунды
2.6ВМ1 - 11.94 секунды
Бейсик-6128 (6128) - 11.52 секунды
Basic48k (6128) - 11.33 секунды
2.891 - 11.12 секунды
2.995 - 7.3 секунды
2.996 - 7.1 секунды
Добавляем строку (целые вместо плавучки)
10 DEFINTA-Z
Бейсик-Корвет (версия для 06Ц) - 6.98 секунды
Жаль, что 2.5 и потомки не могут в целочисленность.
Еще жаль, что корветовский бейсик в 06Ц варианте не может в 16 цветов LoRes.
Жаль. Но Бейсик-Корвет на Векторе это почти произведение искусства. Такие там красивые буковки и 512х256. А еще и DEFINTA-Z.
Подскажите, почему BLOAD читает только один раз один файл (следующие за ним BLOAD не включаются) ?
Вот код:
82 SCREEN 2,15:CLS:SCREEN 0,0,0,255,160,255,72,255,31,63,164,219,32,32,0,82, 0,160
85 REM HIMEM &9FFF
90 CLEAR
700 BLOAD ""
701 PRINTAT1,1,"TUR1"
710 BLOAD ""
711 PRINTAT1,1,"TUR2"
720 BLOAD ""
800 GOTO 800
Это в каком эмуляторе и как ты подсовываешь файлы для BLOAD? Можешь весь архив сюда? Тоже интересно.
Могу с уверенностью утверждать, что несколько BLOAD"" в программе работают нормально (проверял в Emu).
- - - Добавлено - - -
Проблема вероятно с VV.