Просмотр полной версии : Бейсики для Вектора-06Ц и клонов
До сих информация по векторовским бейсикам была раскидана по разным темам, предлагаю в дальнейшем писать про них здесь.
Завершил дизассемблирование бейсика 2.5, начатое много лет назад. Т.к. спешил получить результат, то забил на оформление исходника (в основном на имена) и в текущем виде выкладывать не хочу, надеюсь со временем доведу до ума.
Чтобы отметить это знаменательное для меня событие соорудил модификацию под названием BASIC 2.55. Исправил, немного ускорил и доработал некоторые процедуры по аналогии с бейсиком 2.6 для ВМ1 (http://www.sensi.org/scalar/ware/833/) (в карточке инфа не к последней версии, в readme в архиве - к последней) . По функционалу эти версии практически одинаковы, но 2.6 для ВМ1 быстрее, основные правки на ускорение использовали уникальные команды ВМ1.
Отмечу один момент, который по понятной причине не был реализован для ВМ1 - 2.55 поддерживает любой проц (580ВМ80, 580ВМ1, z80 и 1821ВМ85). Внимательный читатель скажет, что это уже вроде было (http://www.sensi.org/scalar/ware/469/), но тут есть фишка - задержка в процедурах обмена с магнитофоном теперь не зависит от проца. Пример, когда это критично - z80 может быть подключен по кишиневской схеме, с отключаемыми тормозами на dcr или по омской или владимирской без тормозов, т.е. детекта проца недостаточно. Данная версия будет корректно работать при любом известном варианте проца для вектора.
Нескромно считаю данный вариант лучшим "кассетным" векторовским бейсиком.
Недостаток - адреса магнитофонных процедур съехали и перехваты в стандартных конфигах не будут работать. Приложил дополненный конфиг для emu, для других эмуляторов можно поправить по аналогии.
UPD 10.06.2019. Выложил исходник "как есть".
ivagor, достойно доклада на ЦЦ :)
Думаю достоин доклада на ЦЦ был бы какой-то сравнительно серьезный обзор, но над ним надо было бы отдельно работать. Сам я весьма рад, что дожал долгострой, но этой моей личной радости мало для доклада. Хотя меня распирает и излишки выплескиваются на форум.
Вот интересная тема с "классическими" модификациями бейсика 2.5: Филиппов, Фролов, Вьюнов и астраханские заводские программисты. По бинарникам предполагаю, что первые трое скорее всего полностью 2.5 не дизассемблировали, только фрагментами (как и я до сих пор). У них большие куски кода совпадают по расположению с оригиналом и перемежаются с патчами. А вот астраханские товарищи или сами напряглись и серьезно дизассемблировали или получили исходники из Кишинева (хотя кое в чем они ошиблись (http://www.sensi.org/scalar/ware/875/)).
Тут стоит упомянуть исходник, который выкладывали в архиве Филиппова. Он не полный и не совсем точный, хотя названия я многие оттуда утащил. Причем они не всегда совпадают с названиями из статьи Филиппова про бейсик в вектор-user. Скорее всего тот исходник промежуточный вариант.
ivagor, а можно еще сделать, чтоб команды color15,color и т.п. не убивали бейсик ?
Ramiros, спасибо за наводку на эту штуку. Ты раньше вроде про нее писал, но я забыл. Поправил, но там еще надо посмотреть и потестировать.
Теперь нормально )) я попробовал несколько козырных комбинаций которые смог вспомнить, везде выдает синтаксическая ошибка. А почему так происходило? я конечно догадываюсь что фишка была связана с тем, что в место переменных нельзя использовать зарезервированные слова, но хотелось бы подробностей.
Присоединяюсь к tnt23, даешь доклад на ЦЦ!
А почему так происходило?
Была недоработка в парсере аргумента для случая, когда туда попадал токен оператора. Дело в том, что коды токенов операторов и функций в 2.5 получились вперемешку. "Классические" операторы до функций, "новые" в основном после.
Вчера сделал тупо, с несколькими проверками, сегодня решил оптимизировать. В итоге оставил одну новую проверку и убрал одну старую, которая при вводе штатными средствами никогда не сработала бы. При этом адреса процедур, размер и скорость работы парсера не изменились, чем я успел погордиться пару минут. Решил проверить, а как там в других модификациях BASIC 2.5. Оказалось, что эта ошибка была везде (хотя и приводила к разным последствиям в разных вариантах), кроме BASIC-М (http://www.sensi.org/scalar/ware/470/). И самое обидное, что Фролов сделал именно так, как я только что додумался, но он это сделал в 1991 году.
Вспомнил еще ошибку бейсика 2.5 и она тоже связана с токенами. Оператор INPUT (в отличие от версий этого бейсика на других компах и даже бейсика-сигнал для 1200) токенизирует и вычисляет вводимые данные. Если для числовых переменных это скорее плюс, такой бесплатный калькулятор, то для символьных это большой минус. В детстве в бейсиковской программе пришлось организовать свой посимвольный ввод строки. Плохой способ поправить эту штуку понятен, но может придумаю получше.
Прислушался к внутренним ощущениям и не обнаружил позывов к доработке исходника 2.5, потому выложил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1015877&viewfull=1#post1015877) в первом посте как есть. Сам я для удобства дальнейших модификаций немного доработал его, но в исходный исходник эти доработки не вносил.
Можно его куда-нибудь конверснуть, но основной интерес был бы в возможности запускать на другой машины векторовские бейсиковские игрушки. А по возможностям пожалуй единственный подходящий комп - орион-про с мультикартой.
Исправил вышеупомянутую ошибку INPUT при вводе значений символьных переменных, других модификаций 2.5 с исправлением этой ошибки нет.
Ещё один способ убить Бейсик 2.5 - это нажать комбинацию УС-D. После этого он перестаёт адекватно реагировать на нажатия клавиш на клавиатуре. Это не является большой проблемой на эмуляторе, а вот на настоящем Векторе с ёмкостной клавиатурой при быстром вводе операторов с помощью комбинаций УС+СС+символ это реально "доставляло", если нажатие СС вдруг не срабатывало.
Нажал УС+D - бейсик напечатал ромб и штатно продолжает реагировать на клавиатуру.
Если интересно есть еще один баг: при попытке вывести множество символов в графическом режиме экран начинает скролится. я так понимаю глюк сидит в операторе PRINT.
Вот пример:
Эту штуку я припоминаю. Проблему можно значительно уменьшить (но не устранить полостью), если в конце PRINT поставить ;
Еще вроде я ставил между такими операторами CUR с верхним левым углом, т.е. тут не смертельно, скорее неприятно при больших объемах вывода с LINE BS. Может попробую посмотреть.
Нашел в vector-user 7 такой список ошибок бейсика 2.5:
1. Ненужная токенизация для символьных переменных в INPUT - исправил в 2.57
2. "Левый" скролл при использовании LINE BS - исправил, пока не выложил
3. Якобы ошибка в ADDR - там нет ошибки, Филиппов в vector-user 11 это продемонстрировал
4. Ошибка в RENUM при некоторых неясных условиях.
Понятно, что список не полный, но свои любимые ошибки я уже исправил и про них можно прочитать в readme.
Остается RENUM. Кто-нибудь сталкивался с ошибками в его работе? Если да, то при каких условиях? Сам я не сталкивался и сейчас не смог привести RENUM к ошибке, возможно это ложная тревога, к с ADDR.
Я сталкивался с ошибками в RENUM, старался его использовать крайне редко и только когда программа уже готова (предварительно сохранив). Обычно если в программе нет ошибок переходов то все было нормально, но вот иногда в THEN, GOTO, GOSUB адреса переходов слетали, почему уже непомню.
Посмотрел как реализован RENUM, криминала не нашел и без примера неправильной работы вряд ли смогу найти.
Попутно заметил, что в двух из четырех случаев вызова процедуры CHECKCROSSWITHSTACK забыл изменить следующий байт с команды на данные. Это не приводит к проблемам при компиляции исходника, но для наглядности и правильности исходника все же стоит его поправить, у себя поправил.
- - - Добавлено - - -
И все же я понял, в чем проблема. Дело не в размере программы (в VU7 написали про ошибки RENUM "особенно в длинных программах"), а в сочетании двух факторов - должна быть ссылка на последнюю строку и перед этим должен был быть хоть один сдвиг списка номеров в сторону уменьшения. Проще всего (я так и сделал в 2.58) при сдвиге в сторону уменьшения пересылать на 1 байт больше. Можно убедиться на renumtest, если после загрузки сделать RENUM1,1 то в других бейсиках во второй строке будет неправильный номер строки в GOTO. Это проблема не только BASIC2.5, а еще оригинального бейсика-микрон. Проверил только РКшный оригинал, но скорее всего и во всех его адаптациях на другие компы этот баг тоже есть.
Наивно надеюсь, что теперь все ошибки исправлены.
- - - Добавлено - - -
скорее всего и во всех его адаптациях на другие компы этот баг тоже есть.
Еще попробовал Апогей, Специалист и Искру-1080 (renum 1) - эта ошибка есть.
lafromm31
13.06.2019, 08:39
Renum глючил, когда замена номеров строк - приводила к тому, что на некоторых строках количество символов стало превышать максимальное количество символов в строке.
Этот случай можно сказать противоположный тому, что я пропатчил (там в сторону уменьшения, здесь - увеличения). Более того, можно даже просто в режиме редактирования ввести строку, которая будет давать ошибку для LIST и EDIT из за размера.
ivagor, Можно ли увеличить длину вводимой строки? почему ее длинна 127 символов вместо разумных 255 ?
С одной стороны вроде можно. Но места под 255 символов там нет, надо чем-то жертвовать. Чем пожертвовать в принципе есть (быстрое вычисление адреса точки, быстрый ввод операторов, принтер), но я бы оставил это место для чего-то более полезного.
Есть кардинальное решение проблемы удобного редактирования бейсиковских программ - нужна пара писишных утилит (или одна универсальная) для перевода bas->txt и txt->bas. Для вектора есть универсальный bt.com, для старых писи - одна или две утилиты (только для bas->txt). В принципе даже я могу такие утилитки написать, но надо созреть. Если кто-то еще готов - было бы еще лучше.
Или совсем полное решение проблемы - кросс-среда разработки на бейсике для писи. На это я на данный момент не готов.
Или совсем полное решение проблемы - кросс-среда разработки на бейсике для писи. На это я на данный момент не готов.
Токенайзер на коленке можно написать наверное, особенно зная, как работает оригинал, чтобы исключить сюрпризы. Но это как-то слишком просто и без изысков. "Утилиту" для конверсии .txt->.bas, она же транслятор для кросс-среды, можно сделать завернув бейсик в эмулятор. Бейсик надо как-то убедить, что ему вводят программу по строкам (наверное?), а результат из него выковыривать в .bas. Эмулятор для этого можно немного подточить, чтобы не тратить время на мишуру типа экрана, тогда весь процесс будет занимать доли секунды. Зная точки входа, прототип такой штуки можно наскриптовать в v06x.
И наконец-то свершится то, чего ждет вся прогрессивная общественность последние 30 лет. Для Вектора-06ц можно будет программировать на Бейсике в многогигабайтном Эклипсе.
В возможностях v06x со скриптами я не сомневаюсь, там явно можно наворотить практически все что угодно, если знать как. Но мне хотя бы простой и без изысков вариант сделать, т.е. утилиту bas<->txt. Причем такую утилиту сменой таблицы токенов можно ориентировать почти на любой советский бейсик для ВМ80.
ivagor, есть еще одно пожелание - уменьшить хотя бы в 2 раза (а лучше в 3) интервал времени для авто повтора нажатых клавиш, а то не хватает терпения ждать когда курсор начнет бежать и добежит в нужную позицию.
уменьшить хотя бы в 2 раза (а лучше в 3) интервал времени для авто повтора нажатых клавиш
Точно, сам хотел это сделать и забыл.
Насчет кросс-разработки на бейсике для вектора текущее состояние такое (https://zx-pk.ru/threads/9532-vektor-06ts-sredstva-razrabotki.html?p=551236&viewfull=1#post551236) (очень слабое).
Хм, а зачем тогда так витиевато? Нельзя ли BT.COM запустить zrun-ом, aliados-ом, или какой другой утилитой запуска CP/M из-под совремнной ОС?
Идея хорошая, но похоже BT.COM слишком своеобразный. emuc (b2m) и RunCPM (https://github.com/MockbaTheBorg/RunCPM/) ругаются.
- - - Добавлено - - -
По поводу RENUM и ошибки, которую озвучил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1016423&viewfull=1#post1016423) lafromm31
1. Это ошибка влияет только на показ на экране (LIST) и редактирование (EDIT), работоспособность программы сохраняется.
2. Ошибка обратимая. Если ренумеровать обратно с маленьким шагом, то снова можно будет LISTить и EDITить.
3. Исправление этой ошибки потребовало бы или много памяти (которой без кваза или отключения плоскостей нет) или модификации ренумератора в двухпроходной, который будет работать в два раза дольше обычного. Учитывая некритичность ошибки (пп.1-2) желания модифицировать ренумератор у меня не появилось.
Можно взглянуть на эту ошибку в renumtest2. Загружаем, смотрим, запускаем. Потом RENUM10000,100 и снова пробуем смотреть и запускать. А потом RENUM1,1 и с просмотром (и редактированием) снова все хорошо.
Но зато попутно я нашел еще один вариант ошибки RENUM, который как и первый (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1016313&viewfull=1#post1016313) может приводить к появлению левых строк.
Смежный вопрос - RENUM добавляет пробел между оператором и номером строки, может убрать эту фичу? Так листинг чуть нагляднее, зато место кушает, которого при четырех плоскостях мало.
похоже BT.COM слишком своеобразный. emuc (b2m) и RunCPM ругаются.
Func=32 выдаёт мой эмуль, неподдерживаемый вызов функции 50. По стандарту это вызов BIOS, а что там в векторовском МикроДОСе - я не знаю. Вопчем ему нужен МикроДОС.
Смежный вопрос - RENUM добавляет пробел между оператором и номером строки, может убрать эту фичу? Так листинг чуть нагляднее, зато место кушает, которого при четырех плоскостях мало.
Пробел лучше убрать.
Func=32 выдаёт мой эмуль, неподдерживаемый вызов функции 50. По стандарту это вызов BIOS, а что там в векторовском МикроДОСе - я не знаю. Вопчем ему нужен МикроДОС.
В DE указатель на блок параметров. Там код функции (06) и потом значения регистров. 06 это что-то типа AUX OUT в CP/M, что явно никак не ложится на здравый смысл. Скорее всего ему просто надо вернуть какую-то пустышку для счастья и он отстанет. Вопрос - какую.
Скорее всего ему просто надо вернуть какую-то пустышку
Да нет, он там и файл частями грузит/сохраняет, и число выводит. Из других функций CP/M замечены только вывод строки и удаление файла.
Добил RENUM. Оказалось, что в 2.58 я правил следствие, а не причину. Авторы слишком перемудрили со вспомогательной расчетной процедурой и просто забыли правильно инициализировать одну из регистровых пар при сдвиге в сторону уменьшения. 2.59 правильно ренумерует и renumtest и renumtest3 (в нем можно попробовать просто RENUM, в классическом 2.5 будет жесткий результат). Дополнительно убрал вставку пробела до номера строки.
- - - Добавлено - - -
Забыл в reamde написать, что еще уменьшил задержку между автоповторными символами в 2 раза.
ivagor, renumtest3 реально удивил, такого фаталити у меня не было никогда :)
Да нет, он там и файл частями грузит/сохраняет, и число выводит. Из других функций CP/M замечены только вывод строки и удаление файла.
Вот ведь злец! Ладно, я уже свой почти написал.
Пока делаете-) а встроить ассемблер в бейсик слабо
как в BBC Micro Basic
10 PRINT "THIS IS BASIC"
20 DIM GAP % 20
30 P %= GAP %
40 [
50 JSR & FFE7
60 RTS
70 ]
80 CALL GAP %
Утилита для преобразования .BAS->.ASC, что не ново, но так же и обратно -- из .ASC в .BAS!
Нужен Python 3.
https://github.com/svofski/vector06sdl/tree/master/bas2txt
(Чтобы скачать один файл -> bin2txt.py - View Raw, будет такая ссылка (https://raw.githubusercontent.com/svofski/vector06sdl/master/bas2txt/bas2asc.py)).
В каталоге testdata те файлы, на которых я проверяю, чтобы было 100% совпадение при конверсии из .BAS в .ASC и обратно.
Никаких красот, так чтобы сделать из этого загляденный IDE, нет. Если что не так, то валится кишками наружу. Если кто захочет сделать IDE, можно будет доделать плюшек по необходимости.
Спасибо ivagor-у за брутальное тестирование!
svofski мегареспект! Работает лучше бейсиковского парсера. Теперь желающие могут фигачить проги на бейсике с удобным редактированием в современных редакторах.
Вторая правка для тех, кто работает с исходником бейсика. Там в районе адресов 03xxh есть четыре cpi 90h. Их все надо заменить на cpi COMANDBUFER&255
Нажал УС+D - бейсик напечатал ромб и штатно продолжает реагировать на клавиатуру.
Может быть, не во всех вариантах Бейсика был этот баг... но я совершенно точно помню, что в том кассетном Бейсике, который шёл в комплекте поставки к моему "Вектору", этот проклятущий баг был совершенно точно - и, в своё время, стоил мне немало вырванных подростковых волос и нервных клеток :)
P.S. Блин, а, может, комбинация была УС-E... :v2_conf3: помню только, что при зажатом СС эта комбинация соответствовала какому-то графическому оператору - то ли LINE, то ли CIRCLE. Я даже приучал себя вводить именно этот оператор через комбинацию АР2+буква, потому что шанс "убить" Бейсик из-за несработавшей СС был очень немаленьким.
- - - Добавлено - - -
Насчет кросс-разработки на бейсике для вектора текущее состояние такое (очень слабое).
Я бы предложил подумать сделать такое на базе VS Code. Готовая IDE, грамматика языка задаётся декларативно - причём, вероятно, может даже получиться найти готовую конфигурацию под какой-нибудь Бейсик и допилить её под специфику "Вектора". Останется дописать только взаимодействие с эмулятором и/или образом диска, что не должно представлять большой сложности.
- - - Добавлено - - -
а встроить ассемблер в бейсик слабо
Компилятор ассемблера навскидку займёт пару килобайт... можно, конечно, увеличить размер "исполняемого файла" самого Бейсика - но, тогда, под пользовательскую программу и память места совсем мало останется (особенно, если задействованы все четыре экранные плоскости).
Полагаю, на ZX Spectrum ассемблер в ZX-Basic тоже не завезли по причине жёсткого ограничения на размер образа Бейсика в ПЗУ.
1. Третья правка в исходник. Как и вторая она связана с буфером редактирования/печати. В районе метки loc_16D4 нужно заменить
cpi 0F0h
на
cpi ((COMANDBUFER+127)&255)^255
2. Про УС+D. Пробовал не только такое сочетание, но и УС+другие клавиши и в разных режимах (редактирования строки или работы программы). Никаких проблем не обнаружил.
3. Про ассемблер в бейсике. Встраивать в интерпретатор не стоит, а вот при кросс-разработке теоретически можно представить вариант, когда из текстового исходника с ассемблерными вставками конвертер делает правильный .BAS. Причем бейсик можно даже не модифицировать, хотя с модификацией можно сделать удобнее.
Сразу скажу, что совершенно не призываю svofski реализовать такую штуку. Думаю, что если вводить новые возможности, то только под готовность их использовать. Мне вот асм в бейсике не нужен, при большой необходимости отдельно отлажу и как-нибудь объединю.
С моей точки зрения бывает бессмыслица, бред, деменция и где-то в конце этого пути -- ассемблер в Бейсике. Не надо меня уговаривать этого не делать, я и так не собирался.
Сейчас бейсик в асме не нужен, но если
не оглядываться на вектор и воспарить мыслью, то можно увидеть картину: бейсик с асмом в пзу. Человек включает комп и сразу программает, не нужно ничего загружать.
Вот если бы Бейсик для Вектора в 88 году так умел, тогда конечно.
заметил еще один глюк - если нажать АР2 затем УС+СС+любую клавишу, то печатаются гибриды из двух слов, (не два последовательных слова, что было бы логично, а именно какой то гибрид из начала одного слова и конца другого). Но это безобидный глюк т.к. бейсик не умирает :)
Про УС+D. Пробовал не только такое сочетание, но и УС+другие клавиши и в разных режимах (редактирования строки или работы программы). Никаких проблем не обнаружил.
Ну, чудеса... :v2_conf2: Я тут погуглил - про этот баг даже в первом выпуске "Байта" было:
http://sensi.org/scalar/media/w/vector-byte-1-33-151108.pdf (страница 6, примерно в середине страницы)
Возможно, какой-то из ваших патчей попутно починил и эту проблему?
Ну, чудеса... :v2_conf2: Я тут погуглил - про этот баг даже в первом выпуске "Байта" было:
http://sensi.org/scalar/media/w/vector-byte-1-33-151108.pdf (страница 6, примерно в середине страницы)
Возможно, какой-то из ваших патчей попутно починил и эту проблему?
Не исключаю что глюк был в ранней версии (наверное счетмашевцы его по тихому пофиксили), но в моем бейсике с кассеты такого глюка небыло точно.
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. Больше и удачнее остальных операций (практически без увеличения размера) ускорилось деление. Очень не хватает команд и регистров более развитых процессоров.
Добавил в предыдущий пост архив с бейсиком 2.60.
- - - Добавлено - - -
Опять забыл в readme упомянуть, что начиная с 2.59 в два раза уменьшена задержка при автоповторе клавиш.
Вспомнил ещё один глюк (а, может, и не глюк, а авторами так задумывалось). Ещё школьником экспериментировал с записью с помощью BSAVE на магнитную ленту спрайтов, сохранённых в ОЗУ с экрана оператором GET. И вот основная засада была в том, что функция ADDR не всегда корректно выдавала адрес массива в памяти. Я пытался даже подобрать формулу для расчёта корректирующего смещения, которое бы компенсировало ошибку ADDR, но эта ошибка была "плавающей" и ХЗ от чего зависела.
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 на нормальное имя.
После некоторого размышления склоняюсь к тому, что проблема скорее возможна не при записи, а при чтении и даже после него. Единственный работающий вариант - запустили программу, объявили (инициализировали) все переменные, потом addr, потом bload и put. Если вышли из режима исполнения, то нужно быть сверхаккуратным, чтобы содержимое массива с картинкой осталось целым.
ivagor, /* Больше и удачнее остальных операций (практически без увеличения размера) ускорилось деление. Очень не хватает команд и регистров более развитых процессоров.*/
может версию под z80, ускоренную
или на 8085
С одной стороны было бы здорово оптимизировать все программы под каждый околовекторовский проц. Но на практике мотивации на это не хватает. Бейсик для ВМ1 уже модифицировал, к нему вряд ли вернусь. Для ВМ85 делал версию 48k, там в основном менял функциональность, не оптимизировал, но уникальные команды 8085 немного использовал. z80 пока не трогал, поэтому модификация под него все еще интересна, но до сих пор не нашел хорошего транслятора мнемоник 8080->z80 (парой существующих пользовался, но они мне не очень понравились).
- - - Добавлено - - -
Взглянул GET и PUT. Проверка на область переменных только в GET, а в PUT можно использовать любой адрес. Получается даже в классическом 2.5 главное правильно сохранить картинку, а потом лучше загружать ее выше HIMEM и оттуда PUT.
ivagor, процессоры ладно, а вот компилятор бейсика ?
типа bascom
Это было бы очень здорово, но я не потяну. Или когда-нибудь, ближе к пенсии.
мож препроцессор какой, ну убрать лишнее из кода перед исполнением
типа http://noktosoft.megafolio.com/en/bpp.php
там и исходники
но эт сложный, может попроще
Было бы во что препроцессить. Сам я пробовал только микрософтовский BASCOM, компилирует очень медленно, но результат компиляции при использовании целых чисел весьма резвый. Но он штатными средствами не поддерживает ни векторовской графики ни звука. Не разбирался, как к скомпилированной программе стыковать кодовые процедуры, хотя наверняка это все возможно, а соответственно и графика со звуком. Но такой подход слишком своеобразный даже для меня.
Пара слов про символьные переменные.
1. Менеджер области символьных переменных, если его так можно назвать, не очень совершенен. Иногда он выдает "МАЛ БУФЕР ОШИБКА" в ситуациях, которые в принципе можно было бы разрешить мирным путем. Например
CLEAR 3
A$="1"
A$="2"
A$="3"
A$="4"
и т.д. нормально работает, а вот
CLEAR 3
A$="12"
A$="34"
будет ругаться и понятно, что это исправимая ситуация. Но эту штуку я править не буду, раз микрософтовцы не захотели, то я и подавно.
2. При задании символьных переменных закрывающая кавычка не обязательна (можно сэкономить один байт).
A$="12
Пара слов про оптимизацию процедур умножения и деления. Оказалось, что в домикронных бейсиках были процедурки побыстрее с самомодифицирующимся кодом (для клонов вектора из этой серии, например, бейсик для старта 1200). Но внимательный человек, который сравнит домикронный и мой варианты оптимизации, убедится, что я не списывал, а выдумывал свой велосипед. Умножение сильно отличается, деление не так сильно, но все же отличается. Ставлю на то, что мои варианты чуть быстрее, может когда-нибудь измерю насколько.
В комплекте emu (вроде и не только emu, но я сейчас в других не проверял) конфиг вектора с z80 комплектуется 32 Кб загрузчиком с хакнутым бейсиком. Хакул его вроде Vadik, но сейчас я уже не уверен. Проблема в том, что хаки там не вполне корректные.
1. Может пропустить явную ошибку
10 A="1"
2. Может найти ошибку там, где ее нет
10 A=1
20 PRINT A-2
3. Кое-что может неправильно вычислить
PRINT SGN(-1)
Бейсики из этой темы, например 2.60 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1017222&viewfull=1#post1017222) или более ранний в картотеке (обычный (http://www.sensi.org/scalar/ware/469/), дисковый (http://www.sensi.org/scalar/ware/687/)) работают без ошибок.
Надо бы пересобрать 32 Кб загрузчик.
Странно, но я не смог увидеть ни одной ошибки. Проверял в загрузчике который лежит в VV.
В комплекте VV (версия 6.96) я увидел только вариант 32 Кб загрузчика, в котором бейсик совсем несовместим с z80 (TIMSoftBoot.RT совпадает с vector.epr в emu). Как ты проверял, если тот бейсик даже не стартует на z80? Если попробовать с VV vectorz80.epr из комплекта emu, то все вышеперечисленные примеры багов воспроизводятся.
В emu80 loader.rom совпадает с двумя вышеупомянутыми файлами, т.е. тоже бейсик не работает на z80.
ivagor, Я подумал что речь про обычный 32кб загрузчик.
внутри бейсик 2.5
( бейсик и ассемблер)
https://disk.yandex.ru/i/QVXyYuq2l7JbVQ
Можно ли исправленный Basic разместить в ПЗУ с 32-килобайтным загрузчиком (http://sensi.org/scalar/ware/541/) вместо 2.5?
Давно собираюсь, надо бы сделать.
- - - Добавлено - - -
Может и монитор заменить, например на дос (только надо выбрать - какой именно)? Тест техпрогона пожалуй стоит оставить.
Давно собираюсь, надо бы сделать.
- - - Добавлено - - -
Может и монитор заменить, например на дос (только надо выбрать - какой именно)? Тест техпрогона пожалуй стоит оставить.
Может просто замените сам бейсик? ))) В котором хотелось бы увидеть обозначение, что он 2.61 ,а не какой-то там нонейм )))
Может просто замените сам бейсик? ))) В котором хотелось бы увидеть обозначение, что он 2.61 ,а не какой-то там нонейм )))
Я тогда и заменил (https://zx-pk.ru/threads/8778-varianty-zagruzchikov.html?p=1027910&viewfull=1#post1027910) (без надписи 2.61 при старте).
Я тогда и заменил (https://zx-pk.ru/threads/8778-varianty-zagruzchikov.html?p=1027910&viewfull=1#post1027910) (без надписи 2.61 при старте).
Может в Бейсик внедрите надпись? ) Прошивка без монитора, увы - не мой вариант.
Наверняка я вернусь к этой теме. Правда у меня на первом месте в момент окончания предыдущего бейсиковского обострения стояла задача сделать дисковую версию, хотя бы свой вариант run.com и я его даже практически полностью продумал. Но надо было ковать железо сразу, теперь многое забылось и надо разбираться заново.
Если вдруг кто не знает, LAFROMM31 стримит разбор бейсиковских программ, за что ему большое спасибо. Хочу прокомментировать один момент из вчерашнего стрима, про 2.61, VV и CLOAD. VV поддерживает перехват CLOAD для 2.61 по крайней мере с 6.99, но как LAFROMM31 говорил в первом стриме, он использует более раннюю версию VV, тут проблема в этом. На всякий случай напомню, что конфиг для emu в комплекте, т.е. на данный момент два популярных эмулятора поддерживают удобную работу с 2.61.
Дополню про VV и 2.61. Можно просто скопировать строки из cas.ini новой версии
;
; BASIC v2.61:
BIProc[2BBC]="C5D50E0057DB01E610"
BOProc[2C18]="C5D5F5570E087A0757"
в cas.ini старой версии и CLOAD/CSAVE будут перехватываться.
Но при разборе старых программ все же лучше использовать классический 2.5. Уже два-три раза за стримы программы выдавали ошибки. Если бы использовался 2.61, то первая мысль была бы - "он виноват", а на самом деле это или поврежденные файлы или недоделанные программы.
Стримам @lafromm31 после выхода в эфир недостает индекса для навигации.
Как идея для пока мерцающей где-то в далеком будущем надежды на каталогизацию Бейсиковского софта: ссылку на ютуб + временную метку можно было бы вставлять в описание программы.
lafromm31
19.05.2021, 18:40
Да идея уже не мерцает. Процесс потихоньку пошел. Пока правда в текстовом файлике, с указанием названия, даты, автора (если есть информация), краткого описания и тегов по жанру и принадлежности. Делаю по два скриншота, один из них с заставкой (титульником). Сортирую файлы пока двумя вариантами - по авторам, и по жанрам. Попадается много дублей, причем некоторые с разным размером. По хорошему, нужно разбираться, чем отличаются. По возможности, просматриваю, стараюсь определить в чем разница. По завершению, могу бросить Вам собранную информацию, и если будет желание - её можно будет добавить в картотеку.
На стримах несколько раз упоминалась тема конверсии TXT->BAS и в этой связи вспоминали несомненно заслуженную, но не очень удобную для кросс-разработки утилиту BT.COM. Напомню, что есть современная утилита (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1016691&viewfull=1#post1016691) svofski на питоне.
К седьмому стриму. Переделал kombin.dba в cas, такой вариант можно грузить в эмуляторе в кассетный бейсик.
- - - Добавлено - - -
К крестикам-ноликам от 11.87. RB7GA - Аркадий Григорьевич Ройтван (https://www.qrz.ru/db/RB7GA), а UO5OT, как уже выяснили ранее, Олег Васильевич Генделев (https://www.qrz.ru/db/UO5OT)
По следам последнего стрима завершение(?) истории с самой ранней программой на бейсике (перехватчик, 17.05.87).
1. Исходная программа была написана не для 2.5, что и я писал и lafromm31 сказал на стриме.
2. Обе имеющиеся версии адаптированы для 2.5, но немного по-разному.
2.1. В версии с указанием только авторства UO5OT (Олега Васильевича Генделева) есть вторая строка с операторами SCREEN, которой пмсм не было в оригинале (см. п.2.2).
2.2. В версии с указанием адаптатора к 2.5 UO5OIS (Анатолий Нимирский) от 17.6.89 нет второй строки с операторами SCREEN (зато там добавлен звучок с использованием PLAY).
На мой взгляд логичнее предположить, что это две независимые адаптации к 2.5, т.к. не вижу причин, зачем Анатолию Нимирскому было удалять строку со SCREENами.
В итоге все же вектор с палитрой (и бейсик к нему) в районе апреля-мая 87 опять становится очень маловероятным. Можно ориентироваться по "официальным" программам, которые писали Глеклер, Минаков, Соколов, там самые ранние даты относятся к марту 88.
Давно собирался написать, но все время на что-то отвлекался. Регулярная рубрика "по следам стримов и около".
1. Про бейсиковские демки и радио 87/10. Начну с последнего. Tim0xA этот вопрос уже рассматривал, но я сейчас не могу найти ну и в любом случае я дополню. Программа с обложки того номера радио предназначена для бейсика 1.3 (есть оператор CLR). В эмуляторах ее можно набрать и запустить в бейсике кристы-2, который, как я уже писал (https://zx-pk.ru/threads/835-vektor-06ts-obshchie-voprosy.html?p=1023958&viewfull=1#post1023958), является бейсиком 1.3 с небольшими косметическими изменениями. Интересный момент - программа не рисует то, что изображено на экране компьютера на обложке, она рисует примерно вот это (https://youtu.be/uCPIclEo41c?t=8993) (до вывода надписей). Т.е. это как раз пример фрагмента, заимствованного в рекламе для 2.5 из рекламы Темиразова и Соколова, которая похоже была для 1.3. Полностью ту рекламу я не видел и отзывов очевидцев тоже не читал. Еще shapipovo писал про рекламу для вектора (старт-1200), возможно она была очень близка к версии для 1.3 (но не совпадала, т.к. бейсики отличаются), надеюсь когда-нибудь она найдется.
2. По поводу компиляторов бейсика. Специальных для вектора нет, но можно компилировать микрософтоским компилятором для cp/m. Скорее всего результирующие программы могут работать и без диска в эмуляторе cp/m в мониторе-отладчике, если не используются файловые операции.
- - - Добавлено - - -
Возможно кто-нибудь такой же занудный, как я сам, напишет, что CLR есть и в бейсике старта-1200, но там нельзя использовать CLR без аргумента, как в строке 3, а в 1.3 можно. Кроме того, бейсик 1200 не умеет LINE с B/BF (1.3 умеет). Еще в 1200 есть ограничение на длину строки, строка 10 для него длинновата.
В итоге:
1. Есть CLR, поэтому не 2.5
2. CLR без аргументов; LINE B/BF; длинная строка 10 - поэтому не бейсик 1200, а 1.3.
Кроме того это разбирательство заставило внимательно еще раз прочитать страницу 31 руководства 1200 и получается такая родословная:
1. Бейсик 1200=Бейсик 1.0.
2. Бейсик 1.2/1.3 (1.3 скорее всего отличается от 1.2 только надписью про 33 ВРВ, фото с которой и приведено на обложке радио 87/10)
3. Бейсик 2.5
Умеренного ускорения бейсика (от единиц до десятков процентов) добиться сравнительно просто, что можно видеть в 2.61/версии для ВМ1/48k. Но есть графические операции, которые можно ускорить в разы:
1. Вывод символов
2. PAINT
3. PUT
Проблема в занимаемой памяти. В бейсике есть небольшие внутренние резервы, но их хватит разве что на п.1 или 2 (по отдельности) и точно не хватит на п.3. Все и сразу можно получить с квазом, самый простой и удобный вариант - ERAM или 6128, но скорее всего для Баркаря или даже для обычного тоже можно что-то придумать. Не то чтобы я собираюсь это делать (но например быстрый PAINT выкладывал отдельно), просто хотел написать, что текущая скорость 2.5 - это далеко не предел возможностей вектора.
Improver
09.06.2021, 18:59
текущая скорость 2.5 - это далеко не предел возможностей вектора.Так ещё в те годы был БЕЙСИК-М, который в разы (а то и десятки раз) обгонял 2.5 по скорости вывода текста, да и по другим параметрам тоже... Или это опечатка, имелся в виду 2.61?
Вывод символов в бейсике-м не быстрее, чем в 2.5, а основной цикл интерпретации даже немного медленнее. Когда модифицировал бейсик для ВМ1 и 48k я замерял и получилось, что заполнение экрана символами в -м примерно на 3.5% медленнее, чем в 2.5. Там внутренние резервы использовали для добавления новых возможностей, на радикальное ускорение вывода символов места не осталось.
Что в -м быстрее, так это скролл при выводе текста в нижнюю строку, поэтому листинг длинной (занимающей много экранов) программы будет выводится раза в 2 быстрее. Это сделано просто убиранием "лишнего" торможения, оборотная сторона - пострадал внешний вид, скролл с "заворотом", в 2.5 выглядит аккуратнее. Спорное решение, возможно стоило сделать управление скоростью скролла, хотя бы два варианта - как в 2.5 и максимальный разгон, как в -м.
- - - Добавлено - - -
Кстати о скролле. Совершенно забыл, в версии для ВМ1 и в 48k я же его тоже разогнал, но не до упора, как в -м, а до упора без заворота. В итоге 48k на ВМ85 (а без ВМ85 он не работает) скроллит как -м (разницу в торможении отыгрывает за счет более быстрого проца), а версия для ВМ1 скроллит быстрее -м процентов на 15 (там еще и вывод графики и символов оптимизирован, но максимум на десятки процентов, не в разы, как я уже писал), и это все без заворорачивания.
В 2.61 я про это забыл, может и там надо было сделать.
В завершение темы -м небольшой комментарий по поводу рекламы в VU6.
"Вывод текстов ускорен в 1.5-3 раза с более плавным перемещением по экрану".
С одной стороны вроде и не соврали, "вывод текстов", не "вывод символов", с другой - все же очень значительное умолчание, что вывод текстов будет быстрее только при скролле.
Насчет скорости. 2 раза я намерял при выводе листинга рекламы с базовой кассеты. Большее ускорение можно получить, если изменить соотношение между печатью текста и скроллом в пользу последнего. Крайний случай - печатаем только 1 символ и скроллим, в этом случае -м быстрее 2.5 даже не в 3, а почти в 4 раза, но на практике в большинстве случаев (при печати листинга) будет гораздо ближе к 2.
Интересно, что предыдущее бейсиковское обострение было тоже в июне, но в 2019.
BASIC 2.62 (http://sensi.org/scalar/ware/909/)
Процедуры обмена с магнитофоном вернулись на "классические" адреса, что дает совместимость при перехвате магнитофонных операций с бейсиком 2.5 (не требуется адаптация эмуляторов для данной версии бейсика).
Ускорен скроллинг при выводе текста.
Более эффективный упаковщик ZX0 вместо MegaLZ.
Еще в комплекте bas262.wav - файл для быстрой (13.5 секунд, для сравнения rom2wav при параметрах по умолчанию генерирует wav длительностью 90 секунд) загрузки в реал через магнитофонный вход. Благодаря svofski загрузчик даже автостартующий.
Интересно, что предыдущее бейсиковское обострение было тоже в июне, но в 2019.
Дело скорее всего в температурном режиме. В любом случае известие радостное!
С точки зрения инвентаризации это обновление карточки №909 (http://sensi.org/scalar/ware/909/) ?
С точки зрения инвентаризации это обновление карточки №909 ?
Именно так.
Обновил. Год оставить 2021, или это как Евро 2020 в зачет прошлого года?
Если нельзя диапазон, то лучше 2021, как год последней (финальной?) доработки.
История изменений в описании, даты сохранились только 2.61 и 2.62. Если пришлешь даты остальных, я подпишу напротив каждой свою дату.
А кто-то прикидывал, как много (или как мало) игр на бейсике имеют ассемблерные вставки?
Вроде такие встречались, но лично я этот вопрос ни когда не изучал... только сейчас вспомнилось, когда прочитал про адреса магнитофонных подпрограмм.
Если пришлешь даты остальных, я подпишу напротив каждой свою дату.
Думаю хватит даты для первой публичной версии (2.55) из этой серии - 08.06.2019. 2.55-2.61 - июнь 2019, 2.62 - июнь 2021.
Прописал даты для .55, .61 и .62, заодно чуть чуть отформатировал старый текст.
в 2.62 (в ранних наверное тоже) заметил такой неприятный баг - если написать строку программы до упора, то такая строка при выводе или редактировании вызывает ошибку и ее невозможно отредактировать, и загруженные проги нередко прерывают листинг из за этого же глюка.
Это "классический" баг (или особенность) присущий еще 2.5, сталкивался с ним в детстве (и lafromm31 на стримах его демонстрировал) и в теме его уже упомянул (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1016425&viewfull=1#post1016425). Насколько помню, я посчитал его скорее фичей, которая может быть использована для "защиты" и не стал трогать.
Попробовал все же исправить вышеупомянутый баг и скромно назвал результат BASIC 2.62 Hacker Edition (https://disk.yandex.ru/d/qHA7Y2bEC3GCAQ). Он позволяет смотреть с использованием LIST "защищенные" программы, например BRUCELEE. Для упрощения модификации пришлось пойти на компромисс - LIST в этой версии не отделяет номера строк пробелом от остальной части строки. На первый взгляд работает, но стоит еще потестировать.
Доброго времени суток!
Написал небольшую программу под винду для конвертации бейсиковских программ для вектора.
https://github.com/thetrik/Vector06C-Basic-Converter
небольшую программу под винду
Ммм... FASM, VB6... ностальгия...
В readme неплохо бы указать, чем компилировать. Не все сразу распознают исходники для шестого Васика.
На всякий случай, ссылка в этот же тред на мою утилиту bas2asc #36 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1016691&viewfull=1#post1016691).
Не нужен FASM и VB6, но нету GUI и нужен Python 3. У всех свои недостатки =)
Немного попробовал последнюю версию Vector06CBasic.exe. 1.05 по сравнению с 1.03 точно лучше, с ней нет ошибки при конверсии тестового файла. Не понял, зачем при конверсии в txt в начале (а может и не только в начале, но я углубленно не разбирался) добавляются лишние неотображаемые символы.
Немного попробовал последнюю версию Vector06CBasic.exe. 1.05 по сравнению с 1.03 точно лучше, с ней нет ошибки при конверсии тестового файла.
Спасибо за тесты!
Там было исправлено много багов. К примеру при копировании в буфер обмена из буфера обмена, все символы транслируются с учетом знакогенератора бейсика.
Не понял, зачем при конверсии в txt в начале (а может и не только в начале, но я углубленно не разбирался) добавляются лишние неотображаемые символы.
Это BOM (https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%80%D0%BA%D0%B5%D1%80_%D0%BF%D0%BE% D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D1%82%D0 %B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0% B1%D0%B0%D0%B9%D1%82%D0%BE%D0%B2), нужно для правильного открытия UTF-8 файлов на других платформах.
Эпопея с "адресуемыми точками" навела на мысль, что в бейсике 2.5 с использованием SCREEN2 и PLOT можно рисовать точки и в режиме высокого разрешения. Для включения режима 512x256 нужно патчить бейсик, а он не позволяет делать это через POKE, поэтому добавил машиннокодовую вставку. Она расширяет оператор COLOR, чтобы его третий параметр (цвет бордюра) мог принимать значения от 0 до 31. Бит 4 (вес 16) включает (если =1) режим 512x256. Для примера COLOR15,0,16 включает 512x256, а COLOR15,0,0 - 256x256.
Удобство и скорость такого подхода неудовлетворительные, поэтому не стоит считать это готовой процедурой для дальнейшего использования, это всего лишь демонстрация возможности (и поэтому не сделал вариант для 2.62).
Стоит отметить, что Бейсик-Корвет и Бейсик-1200 поддерживают режим высокого разрешения.
В процессе наткнулся на баг 2.5 - маска SCREEN3 не учитывается при выводе символов с LINE BS, если увеличение по X и/или по Y=1. В описании SCREEN3 и LINE BS про это не написано. Наверняка я с этим сталкивался в 90х, но забыл. В принципе можно сделать версию BASIC 2.63 с правкой этого бага, но есть большая вероятность, что часть программ используют его как фичу.
Пример, где исправление бага LINE BS приводит к неправильному отображению одного из фрагментов - штатная векторовская реклама. Суть думаю понятна - если программа активно меняет маску SCREEN3, и в какой-то момент выводит символы с увеличением по горизонтали и/или вертикали в 1 раз, а программист забывает перед этим задать маску 8*255 (или сознательно не делает этого), то при исправлении бага символы частично или полностью пропадают. Эта ошибка касается и LINE BF если ширина и/или высота прямоугольника=1. Остается только констатировать, что для ветки бейсиков 2.5 теперь это не баг, а фича.
metamorpho
13.02.2023, 21:29
Появилась у меня идея (уже несколько дней крутится у меня в голове не могу отбиться :) ) написать на Бейсике для Вектора нечто интересное-необычное (на мой взгляд).
Радостно обнаружил что есть "программа под винду для конвертации бейсиковских программ для вектора" от thetrik, а также "утилиту bas2asc" от svofski. И уже готов был начать реализовывать идею (и конечно набирать текст в удобном текстовом редакторе, а не на Бейсике в Эмуляторе), однако пройдя по ссылкам не обнаружил (может я не увидел где они там лежат) готового к работе .EXE файла программ для конвертации бейсиковских программ для Вектора. Насколько я понял эти программы нужно компилировать для чего нужен FASM и VB6, а для второй программы нужен Python 3.
Просьба к авторам если возможно скомпилируйте под Windows (32bit), чтобы программы были готовые к использованию. И напишите как в них преобразовать файл из Бейсика в современный текстовый формат и обратно.
В недавних упражнениях пользовался утилитой thetrika, exe лежит в релизах (https://github.com/thetrik/Vector06C-Basic-Converter/releases) или прямая ссылка на 1.0.7 (https://github.com/thetrik/Vector06C-Basic-Converter/releases/download/1.0.7/Vector06CBasic_1.0.7.zip)
Просьба к авторам если возможно скомпилируйте под Windows (32bit), чтобы программы были готовые к использованию.
Под Windows 32-бит увы, не могу, я не знаю где такое найти. 64 бит вот, пожалуйста, bas2asc в виде exe (https://github.com/svofski/vector06sdl/releases/download/godot-7b/bas2asc-win64.zip)
bas2asc megagame.bas megagame.asc -- bas в текст
bas2asc megagame.asc megagame.bas -- текст в bas
metamorpho
15.02.2023, 12:51
Освоение Бейсика для Вектора идёт полным ходом :)
Перечитал описание Бейсика (реальная книжечка от Вектора сохранилась), а также эту ветку форума про Бейсик.
Открыл файл.CAS в конверторе (Vector06C- Basic-Converter автор thetrik) и набросал там основу проекта.
Далее если знать то путь до живого Бейсика не сложен =>> Загрузил эмулятор VV, загрузил (F3+F11 и потом F12) Бейсик (v 2.5), загрузил CLOAD"" файл.CAS в Бейсик, сделал RUN = и полезли всякие ошибки, то это не так то данные некорректны, вообщем с некоторыми моментами пришлось упорно эксперементировать, чтобы понять как они работают. В итоге приноровился и если знать всякие моменты, то программа пишется достаточно быстро. Однако скорость выполнения Бейсик-программ не радует - "заварил чай - запустил вывод уровня на экран - пошёл попить чай - пришёл, вывод на экран уровня ещё работает" .... вообщем это трагедия какая-то (а что ты хотел это же ИНТЕРПРИТАТОР 198n-х) :)
Но я к этому был готов, поэтому не расстроился и решил не хоронить Бейсик так сразу :)
Итак перед вами попытка ускорить выполнение программы и обойтись чисто Бейсик операторами - без использования вставок машинных кодов через USR. Можно конечно самому поэксперементировать, но время не очень много, а результатов хочется поскорее.
Поэтому прибегаю к ускорению процесса и попытаюсь использовать знания и опыт знающих эту тему.
На данный момент пытливый ум ищет ответа на следующие вопросы:
1. Можно ли в Бейсике запретить прерывания (конечно можно) ? Если можно запретить прерывания, то продолжится ли выполнение программы или будет зависание ? Насколько программа прерывания связана с ходом выполнения Бейсик-программы = понятно что оператор PLAY и SCREEN не будет работать корректно = а ещё есть какие-то операторы сильно зависящие от прерываний ?
2. Запоминает ли оператор GET информацию со всех четырёх плоскостей экрана или же на него влияет оператор SCREEN 2 (которая запрещает/разрешает обращения к плоскостям) т.е. если например две плоскости запрещены то GET запомнит информацию только с двух плоскостей ? Или же GET запоминает массив цвета точек изображения ? Как устроен GET ?
И соответственно выводит ли PUT во все четыре плоскости или же только в те которые разрешены оператором
SCREEN 2 ? Как устроен PUT, выводит ли он попиксельно или байтами ?
3. Тот же вопрос по оператору LINE x,y,BF (рисование закрашеного прямоугольника). Рисует ли он во все четыре плоскости или только в те которые разрешены оператором SCREEN 2 ?
Кто-нибудь знает ответы ?
1. Можно ли в Бейсике запретить прерывания (конечно можно) ?
Штатными средствами нельзя, только с использованием своей машиннокодовой процедуры.
Насколько программа прерывания связана с ходом выполнения Бейсик-программы = понятно что оператор PLAY и SCREEN не будет работать корректно = а ещё есть какие-то операторы сильно зависящие от прерываний ?
Клавиатура не будет опрашиваться.
Запоминает ли оператор GET информацию со всех четырёх плоскостей экрана или же на него влияет оператор SCREEN 2
SCREEN2 влияет.
выводит ли PUT во все четыре плоскости или же только в те которые разрешены оператором
SCREEN 2
И на PUT тоже SCREEN2 влияет (и на LINE BF).
Как устроен PUT, выводит ли он попиксельно или байтами ?
Попиксельно.
Чтобы избежать разочарований не рекомендую нацеливаться на динамическую игру, тут не спасают и машиннокодовые процедуры (примеров много, один из ярких - Йети в BASS (http://tenroom.ru/scalar/ware/687/index.html)). А вот что-нибудь логическое или пошаговое вполне возможно.
Однако скорость выполнения Бейсик-программ не радует - "заварил чай - запустил вывод уровня на экран - пошёл попить чай - пришёл, вывод на экран уровня ещё работает" .... вообщем это трагедия какая-то (а что ты хотел это же ИНТЕРПРИТАТОР 198n-х)
Уже не раз касались этого вопроса. Это связано с многогранной кривизной Бейсика, который получил в свое время наибольшее распространение, и стал прообразом Векторовского Бейсика. Можно сделать быстрее, но надо затеять свой Бейсик с нуля. Такое дело, на которое не очень тянет даже таких психов, как мы тут. У меня бывают шальные мысли на этот счет, но пока справляюсь отгонять бесов.
Положение мог бы в некоторой степени спасти кросс-компилятор, но это из области фантастики. С другой стороны на Си в его z88dk воплощении можно писать программы под вектор. Но с векторовскими библиотеками там не то чтобы густо, писать свои ассемблерные процедуры придется.
Положение мог бы в некоторой степени спасти кросс-компилятор, но это из области фантастики.
Что-то типа кросс-компилятора Бейсика теоретически возможно. Это бестолково, но это проще сделать. Преимущество по сравнению с z88dk и ark в том, что теоретически можно добиться совместимости со старыми бейсиковскими программами. И вот тогда все бесчисленные биоритмы, психологические тесты и гороскопы, все то, что было так нужно, но не хватало терпения дождаться окончания вычислений, наконец обрадуют нас молниеносным исполнением.
Есть еще вариант - микрософтовский BASCOM для CP/M. Он чудовищно медленно компилирует, но результат работы не такой уж плохой, местами даже хороший. Только там надо делать ассемблерные процедуры для вектора, а то он про графику и музыку не знает.
Есть еще вариант - микрософтовский BASCOM для CP/M. Он чудовищно медленно компилирует, но результат работы не такой уж плохой, местами даже хороший. Только там надо делать ассемблерные процедуры для вектора, а то он про графику и музыку не знает.
Даже не знал про такой. Но Бейсик, где надо доделывать для Вектора ассемблерные процедуры просто чтобы нарисовать линию, это такой совсем непонятный крокодил, который не понятно, как применить. Например, можно на Бейсике написать сложный вычислитель какого-нибудь интересного семпла с плавающей точкой, вычислять, а потом проигрывать его машинным кодом.
Текстовые игрушки можно делать (президент и т.п.), правда для них и 2.5 нормально подходит. Логические игрушки могут быстрее шевелить мозгами - реверси, калах и компания.
Improver
15.02.2023, 19:09
Business в бейсике тоже относительно нормально шевелится. Писать игры и там можно, только надо учитывать особенности Векторовского бейсика.
Можно сделать быстрее, но надо затеять свой Бейсик с нуля. Такое дело, на которое не очень тянет даже таких психов, как мы тут. У меня бывают шальные мысли на этот счет, но пока справляюсь отгонять бесов.
На соседнем форуме тоже собираются писать компилятор Бейсика: http://www.nedopc.org/forum/viewtopic.php?f=46&t=22048
Прикольно, только спорно "тоже" и "собираются". Мне показалось, что разговоры на том же уровне пока, что и тут. Только еще и ушедшие в никуда из-за пустопорожних споров о определениях. Но будет круто, если кто-то чего-нибудь запилит.
Привет всем...
Про Бейсики - есть интересный вариант...
ZX Boriel Basic - он по-моему, мультиплатформенный...
На Python' e написан...
https://www.boriel.com
https://github.com/boriel/zxbasic
Интересно. Теоретически он поддерживает разные бекенды и к нему можно прикрутить 8080. Труд немалый, но раз кто-то осилил это для z80, то и для 8080 осилить можно.
На мой субъективный взгляд проще написать компилятор (или некий полукомпилятор) для 2.5, чем перенацелить boriel на вектор с 8080.
Задачи разные. Написать 2.5 -- это довольно творческий процесс. Даже если это технически проще, такое дело требует глубокого погружения и отрешения от мирских дел. Бекенд наоборт, предельно тупая и кропотливая задача, но ее можно делать в час по чайной ложке почти на автомате. Но это все так. По-моему ни того, ни другого никто особенно не жаждет. Лично мне интересно было бы посмотреть на обычный интерактивный интерпретатор, но сделанный немного иначе.
Кроме backend там и runtime нужен (для 2.5 он в случае вектора есть). Но спор (если это можно назвать спором) довольно отвлеченный от реальности - "Какой из компиляторов проще ненаписать", это я осознаю.
Если говорить об интерпретаторах, то более поздние микрософтовские получше. Для вектора они есть или в CP/M или в виде Бейсик-Корвет (2.5 наследник 3.2, а корветовский, если не изменяет память - 4.7 или 4.5). Но несомненно можно сделать и намного лучше. Осталась ерунда - сделать целевую платформу коммерчески привлекательной и программисты сами придут и наклепают Бейсиков и Сей.
А можно из Бейсика 2.5 (или Корветовского) выцепить части рантайма, которые могли бы быть полезны отдельно от Бейсика, или использованы в другом интерпретаторе или компиляторе? Особенно плавучку и преобразования чисел.
Умные люди плавучку уже выцепили (https://github.com/z88dk/z88dk/blob/master/libsrc/math/mbf32/z80/math_mbf32.asm) (синтаксис z80). В принципе и в дизассембере 2.5 (синтаксис 8080), который я выкладывал примерно оно, но тут причесано и с комментариями.
metamorpho
22.02.2023, 15:28
В целом то что задумал сделать похоже получается (хотя и со скрипом, я думал на Бейсике быстрее будет, но оказалось при незнании тонкостей Бейсика на Вектор можно подолгу застрять на всякой ерунде) - т.е. сделать что-нибудь необычное-интересное используя только штатные команды Бейсика. Возможно и будут вставки машинных кодов, но пока надеюсь без них обойтись. Однако встречаются моменты, которые я не знаю пока как можно решить, например:
1. Команда INKEY¤ оказывается сохраняет нажатые клавиши в некий буфер и соответственно когда игрок нажимает клавишу например ВПРАВО то всё время пока она нажата код этой клавиши пишется в буфер - это приводит к тому что когда игрок нажимает ВЛЕВО то персонаж попрежнему бежит ВПРАВО т.к. INKEY¤ выдаёт из буфера всё что накопилось до этого, поэтому актуально поменять направление не получается.
Конечно с таким управлением невозможно нормально играть.
На данный момент я решил использовать такой подход
1100 V=ASC(INKEY¤):IF V<>255 THEN 1100
таким образом "выкачивается"-обнуляется буфер перед тем как начнётся новый опрос клавиатуры.
Это немного помогает, но всё равно хочется чего-то получше.
Есть ли способ побороть эту проблему с помощью команд Бейсика ?
Например я подумал что вероятно через команду PEEK можно где-то в памяти прочитать именно то какая клавиша СЕЙЧАС нажата. Кто-нибудь знает адресс этой ячейки ?
2. По замыслу проекта главный герой должен улететь на ракете в космос. И тут без аппаратного скрола не обойтись. Возможно команда POKE по адресу ячеки скроллинга будет решением. Кто-нибудь знает адресс этой ячейки ?
Есть ли способ побороть эту проблему с помощью команд Бейсика ?
Если ограничиться командами бейсика, то есть два частичных решения:
1. Опрашивать клавиши СС и РУС/ЛАТ с использованием INP(1). Еще там клавиша УС, но, насколько помню, она приостановит выполнение программы.
2. Опрашивать джойстик (тоже INP).
В детстве я для себя радикально решил эту проблему машиннокодовой вставкой.
Возможно команда POKE по адресу ячеки скроллинга будет решением. Кто-нибудь знает адресс этой ячейки ?
Ячейки бейсика описаны в vector-user 1 (сдвиг экрана - 771). Еще кажется в информационной бейсиковской программе, но тут надо уточнить.
metamorpho
23.02.2023, 17:07
С INKEY$ Бейсика не получается нормально читать клавиатуру.
Пришлось машинный код использовать. Однако программа виснет.
Вот код Бейсика:
4 HIMEM &7FF0
5 RESTORE 900 : REM ЗАГРУЗКА МАШИННЫХ КОДОВ
6 AD=&7FF1
7 FOR I=1 TO 9
8 READ B:POKE AD,B:AD=AD+1
9 NEXT I
..................
215 V=USR(&7FF1): REM ОПРОС КЛАВИАТУРЫ
220 IF V=239 THEN RX=RX-1:GOTO 250
221 IF V=191 THEN RX=RX+1:GOTO 250
222 IF V=223 THEN RY=RY-1:GOTO 266
223 IF V=127 THEN RY=RY+1:GOTO 266
.................
900 DATA &F3,&3E,&FE,&D3,&03,&DB,&02,&FB,&C9
Это код подпрограммы (которая прописана в строке 900)
F3 DI
3E FE MVI A,0FEH ; ПРОВЕРКА НАЖАТИЯ НА КЛАВИШИ ИГРОВОГО РЯДА.
D3 03 OUT 03
DB 02 IN 02
FB EI
C9 RET
Насколько я понял (прочитал) в переменную V заносится значение аккумулятора при выходе из подпрограммы по USR.
Что не так с моей подпрограммой ?
Нужно опрашивать клавиатуру с привязкой к прерыванию и задавать режим ВВ55. Можно например как в baskeys - один раз внедряемся в прерывание и потом берем коды клавиш из 7FF8 (курсор) и 7FF9 (пробел и компания)
metamorpho, На векторе нельзя так просто взять и опросить клавиатуру, т.к. порты клавиатуры по совместительству еще являются портами видеоконтроллера (отвечают за скролинг и цвет палитры), поэтому опрос клавы приведет к артифактам на экране. клаву опрашивают во время обратного хода луча т.е. в обработчике прерывания, к тому же порт B ВВ55 на время опроса клавы надо переключать направление порта, а потом возвращать в прежнее состояние.
metamorpho
23.02.2023, 22:50
.... Можно например как в baskeys - один раз внедряемся в прерывание и потом берем коды клавиш из 7FF8 (курсор) и 7FF9 (пробел и компания)
Запускаю baskeys она выдаёт мерцающие точки и тире-артефакты и перестаёт реагировать на клавишу F12 (похоже виснет).
..................
......................... прошло несколько минут
А нет ВСЁ РАБОТАЕТ - настроил (вставил задержку между выводом print и палитру немного поменял) вроде как.
Запускаю baskeys она выдаёт мерцающие точки и тире-артефакты и перестаёт реагировать на клавишу F12 (похоже виснет).
Интересно, что проблему выявил только VV (в v06x-godot не так просто попробовать, а в emu и emu80 было нормально). Надеюсь исправленный вариант будет нормально работать везде.
- - - Добавлено - - -
Забыл дополнить, что адреса для PEEK сдвинулись - 7FFC и 7FFD
Upd: поправил проверку повторного запуска
Upd 01.03.2023: добавил архив с BAS и TXT полученными конверсией в Vector06CBasic.exe
metamorpho
24.02.2023, 11:06
Интересно, что проблему выявил только VV (в v06x-godot не так просто попробовать, а в emu и emu80 было нормально). Надеюсь исправленный вариант будет нормально работать везде.
- - - Добавлено - - -
Забыл дополнить, что адреса для PEEK сдвинулись - 7FFC и 7FFD
ivagor, спасибо !!
Да я использую VV.
Теперь управление более менее играбельное. Хотя скорости не хватает (для разнообразия переключаю на 12 Мгц и всё летает :) )
Заметил интересную особенность baskeys - после первого запуска всё работает, потом нажимаю F12 и снова RUN и на втором запуске программа красиво (из эффекта зависания можно делать демку :) ) виснет.
Заметил интересную особенность baskeys - после первого запуска всё работает, потом нажимаю F12 и снова RUN и на втором запуске программа красиво (из эффекта зависания можно делать демку ) виснет.
Забыл, что после доработки сместились не только ячейки с данными клавиатуры, но и адрес команды перехода. Проверку в строке 25 исправил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1173576&viewfull=1#post1173576)
- - - Добавлено - - -
Кстати, кроме отсутствия буферизации дополнительная фича - возможность опрашивать несколько клавиш одновременно, правда тут надо аккуратно, в байте писали про ограничения реала.
В обсуждении BASCOM не хватало цифр, для примера Мандельброт (https://github.com/RC2014Z80/RC2014/tree/master/BASIC-Programs/Mandlebrot#benchmarking) ускоряется компилятором примерно в 3 раза.
в v06x-godot не так просто попробовать
Что сделать, чтобы было проще пробовать?
Краткая история моих пробований:
1. Конверснул baskeys.txt в baskeys.bas с использованием Vector06CBasic.exe. Попробовал загрузить в v06x_3-theydo-win64, там в комплекте шли скрипты и все что нужно. Файл при загрузке выдал ошибку, там что-то не то с последней строкой. Кто виноват - Vector06CBasic или скрипты я не разбирался.
2. Попробовал конверснуть baskeys.txt в baskeys.bas с использованием bas2asc.py. Выдает какую-то ошибку, подробно не разбирался (все же конверсии в cas в других эмуляторах запускались). Возможно стоило взять для конверсии последний exe.
3. Можно было еще записать .bas на образ дискеты и запустить дисковым бейсиком, но это я не пробовал.
Проще всего для пользователя было бы перехватывать cload или bload в бейсике. Если это сложно для реализации, то хотя бы приложить набор скриптов, как в v06x_3-theydo-win64 (но тут еще надо разобраться с конверсией в bas, по крайней мере это касается лично меня и baskeys)
Спасибо за подробный список проблем! Похоже тут потребуется работа мысли, может быть даже неоднократная.
Записал baskeys.bas изготовленный с использованием Vector06CBasic на образ fdd и попробовал в v06x-godot-8 - работает.
Конверснул baskeys.txt в baskeys.bas
А где baskeys.txt ? Вижу только baskeys.zip и baskeys2Corrected.zip, оба только .cas содержат.
Могу выложить, но наверно уже не надо, я понял, на чем спотыкался bas2asc. Vector06CBasic.exe при сохранении в txt добавляет в начале байты (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1121919&viewfull=1#post1121919) EF BB BF. Если их удалить, то bas2asc нормально конвертит txt->bas (в cas не пробовал, но наверняка тоже нормально). txt (и bas) я не выкладывал, т.к. думал, что конвертером из cas можно получить и bas и txt. И это правда, но, как оказалось, есть нюанс.
metamorpho
28.02.2023, 23:34
Ставлю эксперименты - пытаясь найти самый быстрый вариант вывода уровня на экран.
Протестировал три следующих варианта:
вариант_1 = вывод спрайта 8Х8 используя рисование прямоугольника с маской (в одну плоскость)
вариант_2 = вывод спрайта 8Х8 используя прямую запись в экран через POKE (в одну плоскость)
вариант_3 = вывод спрайта 8Х8 используя подпрограмму в машинных кодах и её вызов через USR (в одну плоскость)
Оказалось что все три варианта практически почти равны по скорости - все работают медленно.
Пробовал отключать строку 103 - во всех вариантах это ничего не меняло в скорости.
Думал второй вариант будет быстрее первого, т.к. прямая запись в экран без лишних команд, но увы.
Далее возлагал надежды на вариант третий поскольку машинные коды используются, но к удивлению
тормоза такие же, я так предполагаю сам вызов USR в Бейсике громоздкий. Выходит если подпрограмма в
машинном коде очень короткая в смысле в отношении графики вывод 8х8 точек, то выгоды при использовании USR, от неё нет.
Вывод пока такой - либо продолжать делать без машинных кодов и принять тормоза как есть.
Либо переходить на более объёмные машинные коды, но тогда кажется потеряется смысл написания программы в Бейсике.
90 REM --------- программа вывода уровня на экран
98 CLS:FAN=2:RESTORE 650
вариант_1 99 XT=0:YT=248
вариант_2 99 BD=33015:CD=BD
вариант_3 99 BD=128:TY=247:CD=BD
100 FOR I=0 TO 31
102 FOR J=0 TO 31
103 READ A:GROT(J,I)=A
106 IF A=0 THEN GOTO 201: REM ----------- ПУСТО
вариант_1 107 IF A=1 THEN SCREEN 2,8:COLOR 8:SCREEN 3,0,239,239,239,0,254,254,254:GOTO 200:REM СТЕНА
вариант_2 107 IF A=1 THEN POKE BD,0,239,239,239,0,254,254,254:GOTO 201: REM СТЕНА
вариант_3 107 IF A=1 THEN POKE 32578,TY:POKE 32579,BD:KB=USR(&7F40):GOTO 201: REM СТЕНА
200 PLOT XT,YT,2:LINE STEP 7,7,BF: REM --- РИСУЕМ ЭЛЕМЕНТЫ SCREEN 2,15:
вариант_1 201 XT=XT+8
вариант_2 201 BD=BD+256
вариант_3 201 BD=BD+1
204 NEXT J
вариант_1 205 XT=0:YT=YT-8
вариант_2 205 BD=CD:BD=BD-8:CD=BD
вариант_3 205 BD=CD:TY=TY-8
206 NEXT I
Все таки программа на бейсике должна быть на бейсике, а не в машинных кодах, иначе теряется весь ее смысл, исключение может быть разве что опрос клавиатуры ибо по другому ни как. И весь челендж как раз сделать быстро (на сколько возможно) именно операторами бейсика.
После того, как разобрался с конверсией txt->bas с использованием bas2asc оставался последний вопрос
Попробовал загрузить в v06x_3-theydo-win64, там в комплекте шли скрипты и все что нужно. Файл при загрузке выдал ошибку, там что-то не то с последней строкой. Кто виноват - Vector06CBasic или скрипты я не разбирался.
Тот bas, который делает bas2asc нормально грузится скриптом в v06x_3-theydo-win64. Единственная разница, которую вижу в basах bas2asc и Vector06CBasic - bas2asc добавляет больше нулей. Не разбирался, как работает загрузочный скрипт v06x, вероятно он ожидает, что 3 нуля в конце программы будут в составе bas (и это пожалуй правильно), а Vector06CBasic этого не обеспечивает.
metamorpho, немного бустануть программу можно используя basic 2.62 (http://sensi.org/scalar/ware/909/)
2.62 даст проценты ускорения, на глаз незаметно.
Если оставаясь в рамках бейсика говорить например о рисовании лабиринта 32x32, то быстрее сделать можно, но быстро все равно не будет. Если разных видов тайлов немного, например 4, то можно объединить их по 2 и сделать 16 вариантов рисования. При выводе с использованием POKE удобно объединить 2 по вертикали, если тайлы одинаковые, то можно нарисовать 2 одним POKE.
В детстве я проходил этот путь когда делал редактор спрайтов и "мегаигру". Постепенно перекладывал медленные операции на машиннокодовые процедуры, в частности и рисование уровня. Редактор в принципе и на бейсике+коды получился нормально, а вот игру надо было полностью перевести на ассемблер. Это было возможно, но проблема была с графикой и анимацией главного героя, красиво или хотя бы приемлемо у меня не получалось.
- - - Добавлено - - -
2.62 более ценен тем, что там исправлены известные баги.
Не разбирался, как работает загрузочный скрипт v06x, вероятно он ожидает, что 3 нуля в конце программы будут в составе bas (и это пожалуй правильно), а Vector06CBasic этого не обеспечивает.
Я деталей тоже не помню, но bas25hook.chai дописывает 0 0 0 d3 d3 d3 0 в конец виртуального .cas-файла перед контрольной суммой.
metamorpho а есть где-то текст твоей программы целиком, чтобы запустить?
bas25hook.chai дописывает 0 0 0 d3 d3 d3 0 в конец виртуального .cas-файла перед контрольной суммой
Это странно, в конце должно быть три нуля потом контрольная сумма. В casах так уже сделано, лучше для них скрипт сделать.
Это странно, в конце должно быть три нуля потом контрольная сумма. В casах так уже сделано, лучше для них скрипт сделать.
Оишбся, не в конец, а после имени. Три нуля подряд интерпретируются как признак конца bas-файла. Видимо ты клонишь к тому, что если в конце .bas файла не нашлось трех нулей, их стоит додумать. Это можно сделать, просто мне не встречалось таких bas-файлов раньше. Пришли плс.
Добавил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1173576&viewfull=1#post1173576) архив с BAS и TXT.
BAS, насколько я понимаю, был в свое время форматом для хранения на дискетах, поэтому контрольная сумма там не требовалась. На тему тонкостей BAS надо бы посмотреть BT.COM от авторов вектора.
Спасибо, пока я не добрался сделать чего-то полноценно, можно вставить
for (var i = zeroseq; i > 0; --i) {
this.cas.push_back(0)
}
cs &= 0xffff // это было
в bas25hook.chai в строке 59. И тогда твой .bas загружается.
В bas файлах контрольной суммы нет, это все про cas.
metamorpho
01.03.2023, 22:53
Ещё протестировал вариант вывода графики уровня с командой PUT, скорость тоже медленная.
Прежде чем выводить через PUT нужно резервировать массив (- память), потом нарисовать спрайт (- память) и потом
запоминать это в GET и только потом использовать PUT. Минусы - затраты памяти и много лишних движений.
Над плюсами ещё думаю есть ли они.
Запускал программу в Бейсик 2.62 - если мерить строго на глаз то ощущение что есть небольшой прирост скорости, но
в целом всё так же медленно.
Вариант с машинными кодами - решил не использовать (кроме опроса клавиатуры), чтобы было чисто на Бейсике.
Сейчас решаю какой вариант из оставшихся трёх выбрать - возможно будет комбинированное решение.
............
metamorpho а есть где-то текст твоей программы целиком, чтобы запустить?
Пока что нигде нету. После завершения проекта выложу здесь.
Скорее всего в этой игре будет один уровень в конце которого главный герой на чём-то куда-то улетает.
Этот проект задумывался мной как небольшое исследование и как результат демонстрация того какие можно было делать игры чисто на Бейсике с использованием некоторых специфичных моментов Вектора.
metamorpho
07.03.2023, 10:47
....и вот что получается - нарисовал с помощью LINE ракету и вылетает надпись "памяти больше нет". Как так нет, я же "почти" ничего ещё не рисовал :)
Однако быстро память кончилась, а я не успел внедрить и половины того что хотел. Придётся ужимать код программы и использовать другой вариант вывода персонажа игры (сейчас он через ресурсоёмкий PUT выводится).
Игра и на базовом этапе (уровень и человечек бегает - типа LodeRunner) была довольно медленная, а с прибавлением каждого нового элемента скорость падает уже до неиграбельности. Однако меня подкупает включение режима 12Мгц - всё прекрасно летает и парит (может сделаю настройки под режим 12Мгц). Вообщем хочется ещё немного поэксперементировать с некоторыми идеями, но уже сейчас понятно что на стандартном режиме 3Мгц на Бейсике мало что можно выжать в отношении скорости.
На данный момент в ходе экспериментов с Бейсиком удалось реализовать идею (она конечно не новая, но думаю немного в новой форме) анимации различных объектов (в основном статичных) с помощью программирования палитры. Т.е. можно хоть весь экран привести в движение без особых нагрузок на процессор, всё что нужно сделать это заранее правильно нарисовать графику, а потом в ходе игрового цикла менять только палитру.
Есть ещё идея сделать скроллинг уровня вверх-вниз, но это наверное совсем уничтожит скорость игры :)
Хотя на 12Мгц думаю всё будет неплохо работать.
Вообщем процесс создания пока продолжается, но память в Бейсике всё же коротка и сколько не ужимай программу довольно скоро упрёшься в потолок - а значит скоро (наверное) будет выдан результат моих экспериментов :)
С нехваткой памяти можно бороться несколькими способами:
1. Отключать плоскости, но что-то мне подсказывает, что в данном случае этот вариант не подойдет.
2. Более экономно хранить данные
2.1. Разделить программу на основной блок (загружаем по cload"") и блок данных, подгружаемый по bload"".
2.2. Компромиссный вариант - упаковывать данные в строки после REM и читать оттуда по PEEK.
Improver
07.03.2023, 11:46
А что если использовать бейсик для ПК-6128ц, там, вроде, памяти под программу можно больше выделить? Или тут вопрос "спортивного интереса", запустить игру именно на Векторе?
metamorpho
07.03.2023, 11:57
А что если использовать бейсик для ПК-6128ц, там, вроде, памяти под программу можно больше выделить? Или тут вопрос "спортивного интереса", запустить игру именно на Векторе?
....да тут чисто "спортивный интерес" - запустить игру именно на Векторе
Мне неприятно быть негативным занудой, но вижу тут противоречие: игра для вектора, но для нормальной работы нужно 12 МГц. Стоить подумать над радикальным изменением игрового процесса, пусть графика будет попроще и движения поменьше, но хотя бы как-то приемлемо играется. Повторю свое мнение - нормальные динамические игры на basic 2.5 невозможны. Еще вариант - на бейсике сделать что-то очень-очень упрощенное, а на ассемблере полную версию.
metamorpho
07.03.2023, 14:54
Мне неприятно быть негативным занудой, но вижу тут противоречие: игра для вектора, но для нормальной работы нужно 12 МГц.
----Да не, 12Мгц это не требование к игре, это скорее всего видение того "как бы это работало на ассемблере".
Этот проект задумывался мной как небольшое исследование и эксперимент и как результат выйдет демонстрация того что получилось именно на Бейсике с использованием некоторых специфичных моментов Вектора.
А конструктивные предложения и критика всегда приветствуются :)
Стоить подумать над радикальным изменением игрового процесса, пусть графика будет попроще и движения поменьше, но хотя бы как-то приемлемо играется. Повторю свое мнение - нормальные динамические игры на basic 2.5 невозможны.
-- Да тут и так всё самое простое (наверное) - никакой особой динамики нет. Тут даже врагов движущихся нет. Всё это чисто эксперимент.
Еще вариант - на бейсике сделать что-то очень-очень упрощенное, а на ассемблере полную версию.
-- В этом и была одна из целей этого эксперимента - проверить идею - проверил - она оказалась рабочей.
Далее эту идею можно будет использовать в игре на ассемблере (если таковая будет). Но идея пока что захватывает - программируемая палитра - это может быть мощно и многогранно.
Improver
07.03.2023, 17:02
Повторю свое мнение - нормальные динамические игры на basic 2.5 невозможны.Тут важны границы этой нормальности, как мы их понимаем. Вообще, может мои воспоминания о бейсике рафинировались за долгие годы, но я помню, что на бейсике тоже были динамические игры, в некоторых главный герой игры вырождался в один пиксель для скорости перемещения, в других применялись ассемблерные вставки ("Торпедная атака", например), даже змейки-питоны были всякие, достаточно динамичные ( в том числе и самописные :)), а в некоторых играх обновление картинки раз в секунду не считалось криминалом -- всё зависит от сюжета и фантазии. Да и вспомните те годы, тогда даже минутная отрисовка заставки игры, или того же крокодила в "рекламе" бейсика, была чем-то вроде компьютерной магии, а не признаком тормозов. Да куда уж там, даже на МК-61 играли в динамические игры. В общем, если не ставить современные требования по графике, то динамику на бейсике тоже можно сочинить, я думаю. А насколько они будут нормальные -- это всё субъективно.
Да, критерии качества в данном случае субъективны и вероятно у меня планка слишком высоко.
в других применялись ассемблерные вставки ("Торпедная атака", например)
Хороший пример - ассемблер используется, а толку (на мой взгляд) мало, играбельность очень низкая.
даже змейки-питоны были всякие, достаточно динамичные ( в том числе и самописные )
В детстве делал и своего питона на бейсике и тогда он мне казался нормальным. Но если сейчас оглянуться, то там не было никакого запаса быстродействия. Помню шустрого питона как бы на бейсике (публиковали в Радиолюбителе) - так там основной игровой цикл ассемблерной вставкой.
тогда даже минутная отрисовка заставки игры, или того же крокодила в "рекламе" бейсика, была чем-то вроде компьютерной магии, а не признаком тормозов.
Если картинка красивая, то я готов и минуту подождать. Готов подождать, когда логическая игрушка думает над ответным ходом. А когда игра с невероятными тормозами реагирует на нажатия клавиш - вот это для меня неприемлемо.
Глянь игру "Искатель Алмазов" (Радиолюбитель 04-06 1994г) на бейсике, там тоже все очень медленно. Как тут предлагали уже урезается память для экрана в пользу памяти программы.
если использовать бейсик для ПК-6128ц, там, вроде, памяти под программу можно больше выделить?
ПЗУшный бейсик 6128 не позволяет прозрачно использовать 16-цветную графику, если бейсиковская программа залезает за 8000h. Basic48k (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=573890&viewfull=1#post573890) для 6128 позволяет, но есть техническая возможность сделать аналогичный бейсик и для 06Ц с квазом Баркаря.
Improver
08.03.2023, 13:04
ivagor, по большому счёту, уже почти назрела такая необходимость. Думаю, оптимальным для разработки был бы вариант одного универсального бейсика с автодетектом оборудования, т.е. при старте проверяется, если есть память 6128 -- используем её, если есть КД баркаря -- то его... А нет ни того, ни другого -- будет просто бейсик 2.62. :)
"Единый самонастраивающийся бейсик" удобнее для использования, но в нем пришлось бы пойти на компромиссы. Например в Basic48k для ускорения и сокращения немного используются недокументированные команды 8085, в унифицированном варианте проще было бы от них отказаться. На мой взгляд необходимость в бейсике48 для 06Ц назреет тогда, когда появится хотя бы одна программа для него (написать и отладить можно и в варианте для 6128).
Более нужная вещь - run262 или basd262 для запуска с диска. С самого начала собирался, пока так и не собрался.
Ну а самым интересным был бы компилятор для 2.5, но мне сложновато.
Improver
08.03.2023, 17:49
"Единый самонастраивающийся бейсик" удобнее для использования,Не то, что для использования, скорее для разработки -- делать одну универсальную версию проще, чем поддерживать актуальность нескольких. Хотя, случаи всякие бывают, может тут универсальность только навредит, не возражаю.
Например в Basic48k для ускорения и сокращения немного используются недокументированные команды 8085Интересный момент, не знал этого. А насколько Basic48k по другим оптимизациям отличается от более позднего 2.62? Может его тоже пора обновить? ;)
Более нужная вещь - run262 или basd262 для запуска с диска.Согласен, это тоже нужно.
скорее для разработки -- делать одну универсальную версию проще, чем поддерживать актуальность нескольких.
Еще проще не поддерживать актуальность, и к сожалению, на данный момент я следую этим путем. Фактически три ветки: бейсик для ВМ1 - упор на ускорение, в т.ч. графики, исправлены некоторые баги; basic48k - возможность делать большие программы, исправлены некоторые баги; basic 2.62 - исправлены все известные баги (там где это не мешает совместимости) и некоторое ускорение. Последнее направление наиболее актуально, первое скорее всего все (т.к. ВМ1 актуален только для коллекционеров), второе под вопросом.
basic48 несколько уступает в скорости работы с графикой, т.к. приходится щелкать страницами, но не сильно.
Привет всем...
Думаю компилятор для Basic' a проще будет -
на основе драйверов устройств сделать...
???
На Спектруме - есть множество компиляторов...
Можете глянуть...
MCoder2, Tobos, Blast и тд...
Была целая кассета компиляторов...
Может что и подойдет...
metamorpho
17.03.2023, 21:39
Наконец-то довёл свой эксперимент до более-менее логического завершения.
Эксперимент называется "База ХТ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. Игра на бейсике, поэтому тут не до быстроты реакции, я однозначно за это. Но было бы здорово добавить элемент головоломки, чтобы немного подумать над порядком выключения лазеров и открытия дверей.
parallelno
19.03.2023, 04:30
metamorpho, класная задумка и реализация! Прикольно было надлюдать как строиться уровень :) Рокета только застряла и так не вылетела в космос, а в осталальном все супер! :)
metamorpho
19.03.2023, 23:08
....Чтобы можно было запускать повторно надо изменить в строке 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. Игра на бейсике, поэтому тут не до быстроты реакции, я однозначно за это. Но было бы здорово добавить элемент головоломки, чтобы немного подумать над порядком выключения лазеров и открытия дверей.
Да согласен - это было бы лучше. Да и других разных фишек можно добавить, но это в случае если дальше реализовывать игру на Бейсике. Но для меня развитию этого проекта в Бейсике сильно мешает скорость "бега" персонажа.
Эта подпрограмма тоже самое что обычный 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
20.03.2023, 17:39
INKEY$ первым делом вызывает эту подпрограмму.
Так её можно использовать для безбуферного опроса или она тоже с буфером ?
Что она выдаёт на выходе - символ из буфера или только что нажатый ?
Коды клавиш в буфер складывает не INKEY, а обработчик прерывания, а INKEY читает оттуда.
Идея с полным убиранием буфера мне не нравится по нескольким причинам:
1. Это изменит реакцию на клавиатуру в бейсике в целом.
- Пожалуй неудобство будет ощутимо для тех у кого реальный Вектор с кассетой, им придётся для другой программы
перезагрузить Бейсик. Все остальные варианты (с дисководами и квазидисками) пострадают похоже не особо сильно. Ну а
с возможностями эмуляторов это вообще не проблема.
2. Внедрение в прерывание легко сделать единообразно для разных версий бейсика, а вот если
патчить работу с буфером или INKEY - это резко ограничивает свободу модификации бейсика, тут я против.
- Это достаточно глобальный подход. Но с другой стороны делать версию игры под каждый Бейсик (я так понимаю что
речь идёт про Бейсик v2.5 стандартный, Бейсик М и Бейсик 2.63) наверно тоже не очень хорошая идея. Хотя есть подобие
- несовместимость новых программ со старыми версиями ОС или старых программ с новыми ОС - частая история.
Ещё можно сделать проверку версии Бейсика и в зависимости от этого сделать соответствующие изменения, но это уже
получится довольно громоздкая конструкция.
3. Внедренец в прерывание позволяет (в отличие от INKEY) опрашивать несколько клавиш
одновременно.
- Для игр в пределах Бейсика обычно достаточно одновременно знать только про одну клавишу, так что возможность
опрашивать несколько клавиш одновременно - нужно ли это.
Однако в целом в итоге пожалуй идея с отключением буфера сквозит минусом больше чем плюсом.
Одномерный массив быстрее POKE и PEEK, скорее всего двумерный тоже. По крайней мере если в
POKE и PEEK использовать конструкции типа POKE BASE+I или PEEK(BASE+I).
Т.е. перед нами стоит выбор - или сэкономить память но будет медленее - или будет немного быстрее но "- 3 Кб".
Если разница в скорости не сильно большая, то пожалуй можно было бы и перейти на чтение массива через PEEK.
Так её можно использовать для безбуферного опроса или она тоже с буфером ?
Что она выдаёт на выходе - символ из буфера или только что нажатый ?
Весь опрос клавиатуры в бейсике через буфер, в т.ч. INKEY.
Что касается низведения буфера до 1 символа - минусы я перечислил, а в чем плюсы такого варианта?
metamorpho
20.03.2023, 19:19
.....Что касается низведения буфера до 1 символа - минусы я перечислил, а в чем плюсы такого варианта?
При условии что моё представление об отключении буфера было бы правильно, то плюсом является более короткая программа для достижения нужного нам опроса клавиатуры. Т.е. если бы буфер отключался через блокирование некоего INX D, тогда нам нужно было бы например XRA A/STA NNNN/RET всего 5 байтов вместо 42 байт для внедрения в прерывания.
И чисто философически мы бы больше вписывались в вариант basic-only, т.к использовали INKEY$ (только немного
модифицированый под наши потребности - мы всего лишь заменили 1 байт программы). :)
И чисто философически мы бы больше вписывались в вариант basic-only, т.к использовали INKEY$ (только немного
модифицированый под наши потребности - мы всего лишь заменили 1 байт программы).
Тут я не согласен, нельзя быть немножко беременным. Любая модификация бейсика требует небольшой ассемблерной программки (т.к. штатными средствами он модифицировать себя не даст), а значит уже не basic-only.
Плюс понятен - программа модификации короче. На мой взгляд это совсем не перевешивает озвученные минусы, особенно совместимость с разными версиями бейсика, в т.ч. гипотетическими будущими.
Тем не менее если хочешь попробовать, то достаточно заменить по двум адресам (в 2.5: 2EBF и 2D13) 3C на 00.
- - - Добавлено - - -
А можно занулить предыдущие (в 2.5: 2EBE и 2D12) адреса, результат будет аналогичный. Но и в первом озвученном варианте и во втором зануляем 2 адреса, 1 не получится.
- - - Добавлено - - -
Кстати, у INKEY есть еще недостаток по сравнению со "своим" опросом - задержки автоповтора. В этом смысле 2.61-2.63 лучше, т.к. там эти задержки меньше.
Improver
20.03.2023, 22:06
Я, может, глупость сейчас предложу: а что если дополнить бейсик ещё одним оператором, который будет читать код последней нажатой клавиши? Без учёта буфера, или с его очисткой, "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 оставлены пробелы перед номерами строк. Там можно было бы сэкономить. Но в остальном уж очень регулярное отсутствие пробелов в таком большом листинге, вряд ли нормальный человек не вставил бы пробельчик-другой, если это было написано вручную.
Описание (http://www.danbigras.ru/RK86/Basic/TxtBas.html) РКшной утилиты с возможностью компактирования. РКшного бинарника не нашел, попробовал специалистовский вариант (полный аналог) - убирает все пробелы.
Еще пара версий: или ту игрушку компактировали и потом еще редактировали с попутным добавлением пробелов или ее могли портировать из домикрона (там не было AT).
metamorpho
27.03.2023, 12:06
А где можно скачать cas. или txt. файлы программ для Бейсика ?
А где можно скачать cas. или txt. файлы программ для Бейсика ?
lafromm31 передает привет и вот такой архив (https://www.sensi.org/~svo/c/basicsort2.zip).
metamorpho
27.03.2023, 16:16
lafromm31 передает привет и вот такой архив (https://www.sensi.org/~svo/c/basicsort2.zip).
lafromm31 и svofski спасибо !!
Видно, что идея с каталогом программ на Бейсик продолжает жить :v2_thumb:
metamorpho
28.03.2023, 18:31
Снова привязалась идейка - увернуться не получается :) так что снова создаю и снова на чисто Бейсике.
В проекте планируются очень большие спрайты обычным 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, то ничего похожего на полноцветное полноэкранное изображение у них бы не получилось.
Или же можно закрутить в REM строку любой код от 0 до 255 ?
Можно, но для автоматизации процесса нужна утилита. Или добавление такой опции в существующие конвертеры.
А ещё придумал как сжать спрайт закодировав его в пределах символов с кодами 0-127, однако
нужно как-то определить крайний бит числа, т.е. например число (0)1010111 нужно определить бит (0 или 1) который в скобках.
Функция SGN похоже про другое и не поможет.
Можно ли это сделать чисто на Бейсике (может какие-то хитрости есть) ?
переменная AND 128=128 (или =0)
Можно, но для автоматизации процесса нужна утилита. Или добавление такой опции в существующие конвертеры.
Там ноль разве можно?
Там ноль разве можно?
С ограничениями, REMы нужно поместить в конце программы (и не надо туда передавать управление) и чтобы там не было трех и более нулей подряд.
С ограничениями
Можно, но плавно.
Извините, был неправ. В памяти можно исправить и оно там лежит. Но если мы загружаем, то выполняется "привязка по месту" и она все испортит. Т.е. нули в 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.
metamorpho
31.03.2023, 14:03
Подскажите, почему 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.
Подскажите, почему BLOAD читает только один раз один файл (следующие за ним BLOAD не включаются) ?
Привет всем...
В команде Bload "" - в кавычках - имя файла ставится...
С пустыми кавычками - может и не грузится...
???
metamorpho
31.03.2023, 15:31
Это в каком эмуляторе и как ты подсовываешь файлы для BLOAD? Можешь весь архив сюда? Тоже интересно.
Эмулятор VV.
Это и есть вся программа - её цель объединить три слоя.
Рядом в каталоге лежат три файла где записаны слои.
Пробовал BLOAD "" и так BLOAD "name" - без разницы.
Грузится только один файл. А потом окно диалога загрузки не появляется.
- - - Добавлено - - -
Могу с уверенностью утверждать, что несколько BLOAD"" в программе работают нормально (проверял в Emu).
- - - Добавлено - - -
Проблема вероятно с VV.
Да точно. Попробовал в EMU там такой вариант работает.
А как сделать то, что можно загрузить таким BLOAD? Я пробую то и сё в emu80, попробовал из мануала BSAVE"PROG",4000,6300. Все записывается, но когда делаю BLOAD неизменно говорит мне "НЕЛЬЗЯ ОШИБКА". Я согласен, что нельзя ошибка, надо без ошибка, но как?
А как сделать то, что можно загрузить таким BLOAD? Я пробую то и сё в emu80, попробовал из мануала BSAVE"PROG",4000,6300. Все записывается, но когда делаю BLOAD неизменно говорит мне "НЕЛЬЗЯ ОШИБКА". Я согласен, что нельзя ошибка, надо без ошибка, но как?
Берешь кодовый блок - скомпилировав из ассемблера,
или набранный в мониторе или записанный командами poke - в память...
И блок кода записываешь...
Потом командой Bload "name" - загружаешь в память...
И скорее всего адреса загрузки должны быть выше, больше адреса в Himem...
На область Basic' a Bload "" - загружать данные не будет...
Himem &6fff
Bload "" - например c &7000...
Stl75, спасибо, HIMEM помогло.
svofski, дело не в HIMEM, а в адресах. Нельзя загружать по адресам <4300h. >= можно
svofski, дело не в HIMEM, а в адресах. Нельзя загружать по адресам <4300h. >= можно
Himem - он стек понижает или повышает с &7fff...
Выставляет новый адрес стека ниже или выше...
В Basic' е стек находится чуть ниже экранных областей...
Все равно в v06x у меня не загружает. Читает 4 байта префикса, 31 байт имени с нулями, после чего сразу говорит "нельзя ашипка" не доиграв даже до того места, где записаны стартовые адреса. Я смотрю через перехват $2b05. Тот же файл в emu80 и VV загружается. Что может быть не так?
По описанию непонятно, попробуй потрассировать BLOAD. В 2.5 начало с 1B54h, но собственно загрузка начинается с 1B7Dh
- - - Добавлено - - -
31 байт имени с нулями
Вот это смущает, почему 31?
С помощью проги перевел две игры из журналов Радиолюбитель:
"Питон" (Александр Еременчук РЛ-08/1993)
"Атака" (Артем Чеботарев РЛ-03/1992)
Вот это смущает, почему 31?
Число не имеет значения, имя ведь может быть разной длины. Я просто не учел, что там может быть флажок ожидания синхробайта, когда надо скипать до E6. Пока исправил, но вообще это неправильно, получается, что эмулятор слишком много знает о структуре файла и всякую фигню от себя додумывает. Надо встраиваться на более низкий уровень.
P.S. глюк с незагрузкой RDS я больше повторить не могу. Загружается.
"Питон" (Александр Еременчук РЛ-08/1993)
Тот самый питон, где основной цикл на асме. Время инициализации на мой взгляд слишком долгое, в таких случаях лучше подгружать кодовый блок.
- - - Добавлено - - -
Исправил (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938) время прогона тестика для 2.6ВМ1. Постараюсь адаптировать хотя бы часть оптимизаций оттуда в версию для 8080.
Перевел еще 2 игры из журнала Радиолюбитель:
Познай себя (И.Онищенко РЛ.3/93)
Ход конем (А.Еременчук РЛ.8/93)
Оптимизировал бейсик с учетом основных (но не всех) достижений версии для 580ВМ1 (перечень изменений в readme). В качестве модного и актуального бенча предлагаю оценить старт ANTIGRAV (от RUN до завершения рисования уровня):
2.5 - 164.4 секунды
2.891 - 130.17 секунды
2.995 - 65.58 секунды
2.996 - 52.23 секунды
Еще 2 игры из журнала - Радиолюбитель - Ваш компьютер:
Метеоритная защита (Усов.В. РЛ-ВК-10/1996);
Одинокая пешка (Усов.В. РЛ-ВК-08/1997);
parallelno
03.04.2023, 04:53
thetrik, Сколько всего нового - забытого старого. Нужно будет перетеститровать. Спасибо что делаешь это!!
metamorpho
03.04.2023, 13:00
Мой новый проект пока буксует - причина ограничения памяти и скорости Бейсика.
Есть идея как ускорить (в какой-то мере) процесс, но для этого мне нужно
Подскажите пожалуйста:
1. Правильно ли я понял что формат Бейсика BSAVE это тоже самое что и формат записи МОНИТОРА-ОТЛАДЧИКА ?
2. Может ли "Pretty 8080 Assembler" выгрузить в формате BSAVE ?
Мой новый проект пока буксует - причина ограничения памяти и скорости Бейсика.
Есть идея как ускорить (в какой-то мере) процесс, но для этого мне нужно
Подскажите пожалуйста:
1. Правильно ли я понял что формат Бейсика BSAVE это тоже самое что и формат записи МОНИТОРА-ОТЛАДЧИКА ?
2. Может ли "Pretty 8080 Assembler" выгрузить в формате BSAVE ?
Идейно они мало отличаются, но все-таки не одно и то же. Учту, что неплохо было бы добавить.
metamorpho
03.04.2023, 16:08
Идейно они мало отличаются, но все-таки не одно и то же. Учту, что неплохо было бы добавить.
Из ответа я понял:
1. в "Pretty 8080 Assembler" нет возможности выгрузить в формате МОНИТОРА-ОТЛАДЧИКА
2. формат BSAVE и формат МОНИТОРА-ОТЛАДЧИКА всётаки чем-то отличаются и значит формат МОНИТОРА-ОТЛАДЧИКА мне не подходит. Мне нужен Бейсиковский формат BSAVE.
Есть вариант на языке высокого уровня на РС создать файл формата BSAVE, чтобы Бейсик его загружал.
Например в журнале Байт №5 Октябрь 1991 г. приводится физический формат файла МОНИТОРА-ОТЛАДЧИКА.
А есть ли где-нибудь описание формата BSAVE ?
Извини за телеграфный ответ. Да, ты правильно понял.
А есть ли где-нибудь описание формата BSAVE ?
Может быть, но по-моему с ним довольно прозрачно. Такой тест:
POKE&7000,1
BSAVE"FORMAT",&7000,&70FF
Сохраняем format.cas и смотрим. Получается по-моему так:
4 байта 0xD2
имя файла, 0, 0, 0
(много нулей, допустим 255)
0xE6 - байт синхронизации
MSB, LSB адрес началча big-endian
MSB, LSB адрес конца big-endian
(данные, 256 байт в нашем случае)
1 байт контрольная сумма.
metamorpho
03.04.2023, 17:18
Извини за телеграфный ответ. Да, ты правильно понял.
Может быть, но по-моему с ним довольно прозрачно. Такой тест:
POKE&7000,1
BSAVE"FORMAT",&7000,&70FF
Сохраняем format.cas и смотрим. Получается по-моему так:
4 байта 0xD2
имя файла, 0, 0, 0
(много нулей, допустим 255)
0xE6 - байт синхронизации
MSB, LSB адрес началча big-endian
MSB, LSB адрес конца big-endian
(данные, 256 байт в нашем случае)
1 байт контрольная сумма.
Отличная идея !! Так это можно вообще не изобретать велосипед (насколько я понял), можно сохранить в Бейсике BSAVE то пространство памяти, которое мне нужно будет загрузить - и заменить данные на свои (например выгруженные в hex формате в Pretty).
Однако что такое контрольная сумма в формате BSAVE непонятно ? - поскольку википедия даёт достаточно обширный комментарий на этот счёт.
Однако что такое контрольная сумма в формате BSAVE непонятно ? - поскольку википедия даёт достаточно обширный комментарий на этот счёт.
Я бы написал программу на чем угодно, что под рукой и привычное. Судя по тому, что контрольная сумма единицы и всех нулей равна единице, это просто сумма всех байт данных по модулю 256.
Назло здравому смыслу я сделал конвертер bin2cas.bat на языке bat-файлов. Использование, например: bas2cas.bat bload.bin bload.cas 0x7000
Проверял только в 11 винде.
metamorpho
03.04.2023, 21:16
Я бы написал программу на чем угодно, что под рукой и привычное. Судя по тому, что контрольная сумма единицы и всех нулей равна единице, это просто сумма всех байт данных по модулю 256.
Заполнил FF область от 8000 до 9FFF. Записал BSAVE "NNNNNNN",8000,9FFF
Открыл в HEX формате и вот что выдаёт:
D2 D2 D2 D2 (имя файла 7 байт) (259 нулей) E6
80 00 9F FF (адрес началча и конца)
(245 раз FF) C0 DC E2 E2 DC E2 E2 DC C0
(247 раз FF) 00 71 8A CB AA 9A 8A 71 00
(247 раз FF) 00 C7 28 2C AA 69 28 C7 00
(247 раз FF) 00 00 80 80 80 80 80 00 00
(247 раз FF) 00 72 8A 0A 7B 8A 8A 73 00
(247 раз FF) 00 08 08 08 CF 08 08 EF 00
(247 раз FF) 00 20 20 20 3C 20 20 BE 00
(247 раз FF) 03 03 03 03 03 03 03 03 03
(6146 раз FF) 29 (контрольная сумма)
После первых 8 строк данных идёт некая цепочка из девяти байт - что это ?
Количество байт данных должно быть 32*256=8192 по факту (8*256)-2=2046+6146=8192 всё сходится
Контрольная сумма 29&(41) - не совсем понял как её вычислить ?
- - - Добавлено - - -
Назло здравому смыслу я сделал конвертер bin2cas.bat на языке bat-файлов. Использование, например: bas2cas.bat bload.bin bload.cas 0x7000
Проверял только в 11 винде.
До конца ещё не понял, но похоже это решение моего вопроса :) Спасибо !!
bas2cas.bat bload.bin bload.cas 0x7000 а вот эти циферки 0x7000 это что ?
а вот эти циферки 0x7000 это что ?
Адрес, куда он загружается.
- - - Добавлено - - -
но похоже это решение моего вопроса
Это больше как шутка, но и ты не самым серьезным делом занят =)
Подскажите, почему 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
Я незнаю как сделано в других эмуляторах, но в моем (VV) после первого детекта последовательности CAS перехватчиком выскакивает диалоговое окно выбора .cas файлов, по завершению которого взводится флажек блокировки открытия следующего на некоторое время (доли секунды, точно не помню). Иначе это окно появляется бесконечно.
Просто добавь паузу в ~1сек перед следующим BLOAD"" и все заработает как надо.
Improver
03.04.2023, 23:03
После первых 8 строк данных идёт некая цепочка из девяти байт - что это ?Не понятно, откуда это, может что-то записалось в область данных? А формат записи на магнитную ленту директивой BSAVE следующий:
- заголовок 256 байт 0h (нет в файлах .cas)
- синхробайт 0E6h (нет в файлах .cas)
- 4 байта 0D2h
- имя файла (до 127 байт ?);
- 3 байта 0h
- заголовок 256 байт 0h
- синхробайт 0E6h
- ст., мл. байт адреса начала;
- ст., мл. байт адреса конца;
- байты файла
- 1 байт контр. сумма всех байтов файла без переноса
Шутки шутками, а я добавил .tape v06x-cas к прекрасму (https://svofski.github.io/pretty-8080-assembler/). .tape v06c-cas или .tape v06c-bload сделает cas и wav как надо для BLOAD. Для скачивания .cas жать кнопку TAPE.
Пример: [ссыла (https://svofski.github.io/pretty-8080-assembler/?data:text/plain;base64,ICAgICAgICA7IEJBU0lDIDIuNSBCTE9BRCBkY XRhCiAgICAgICAgLnByb2plY3QgYm9ibGFkCiAgICAgICAgLnR hcGUgdjA2Yy1jYXMKCiAgICAgICAgLm9yZyAkNzAwMAogICAgI CAgIGRiICdPaCBoYWknCiAgICAgICAgZHMgMTYKICAgICAgICB kYiAxLDIsMyw0)]
- - - Добавлено - - -
Я незнаю как сделано в других эмуляторах, но в моем (VV) после первого детекта последовательности CAS перехватчиком выскакивает диалоговое окно выбора .cas файлов, по завершению которого взводится флажек блокировки открытия следующего на некоторое время (доли секунды, точно не помню). Иначе это окно появляется бесконечно.
У меня после диалога ставится флажок-признак того, что файл открыт и, пока он стоит, диалог больше не открывается. Когда файл кончается, флажок сбрасывается. Для дополнтельной защиты подсмотрел у Pyk сброс флажка по 0x2b8e. В emu80v4 это называется закрытие файла, но это по-моему просто означает, что бейсик вывалился в REPL. То есть два BLOAD подряд при исполнении программы срабатывание 0x2b8e не вызовут.
- - - Добавлено - - -
P.S. и это чем-то даже хорошо, потому что можно сделать синтетический .CAS файл, в котором будет склеено несколько файлов. Ну и WAV тоже так.
У меня после диалога ставится флажок-признак того, что файл открыт и, пока он стоит, диалог больше не открывается. Когда файл кончается, флажок сбрасывается. Для дополнтельной защиты подсмотрел у Pyk сброс флажка по 0x2b8e. В emu80v4 это называется закрытие файла, но это по-моему просто означает, что бейсик вывалился в REPL. То есть два BLOAD подряд при исполнении программы срабатывание 0x2b8e не вызовут.
Метод по моему не идеальный. Что если файл не полный/кривой, или что если выйти из диалога по ESC-ей? В моем случае диалог не появится, или будет грузится в обычном режиме через .wav
Метод по моему не идеальный. Что если файл не полный/кривой, или что если выйти из диалога по ESC-ей? В моем случае диалог не появится, или будет грузится в обычном режиме через .wav
Если файл, например, обрубок, диалог откроется во второй раз. Его можно закрыть. Если диалог закрыть без файла (сразу, или по кривости файла), можно грузить wav. По-моему нормально обрабатываются жизненные ситуации и восстановление после исключительных не обременительное.
metamorpho
04.04.2023, 17:39
Не понятно, откуда это, может что-то записалось в область данных? А формат записи на магнитную ленту директивой BSAVE следующий:
- заголовок 256 байт 0h (нет в файлах .cas)
- синхробайт 0E6h (нет в файлах .cas)
- 4 байта 0D2h
- имя файла (до 127 байт ?);
- 3 байта 0h
- заголовок 256 байт 0h
- синхробайт 0E6h
- ст., мл. байт адреса начала;
- ст., мл. байт адреса конца;
- байты файла
- 1 байт контр. сумма всех байтов файла без переноса
Было проведено исследование и тайна этих цепочек раскрыта (спасибо KTSerg) - это оказались адреса записи данных 8000-9FFF - на экране они возникают вначале исполнения команды BSAVE.
- - - Добавлено - - -
Шутки шутками, а я добавил .tape v06x-cas к прекрасму (https://svofski.github.io/pretty-8080-assembler/). .tape v06c-cas или .tape v06c-bload сделает cas и wav как надо для BLOAD. Для скачивания .cas жать кнопку TAPE.
Вот это поворот !! Ещё вчера мечтали, а уже сегодня это стало реальностью :) СПАСИБО !!
Оптимизировал бейсик с учетом основных (но не всех) достижений версии для 580ВМ1 (перечень изменений в readme). В качестве модного и актуального бенча предлагаю оценить старт ANTIGRAV (от RUN до завершения рисования уровня):
2.5 - 164.4 секунды
2.63 - 154.8 секунды
2.70 - 136.1 секунды
В этой версии (может быть в более ранних тоже) не работает тот самый перехват адреса 0x2b8e, которым так удобно закрывать файл. Подскажи, как в 2.70 лучше подхватить конец работы с файлом, особенно конец записи файла?
2B8E в 2.5 это ввод с клавиатуры, постараюсь его туда вернуть.
Дополнение к бессмысленному тесту (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1175938&viewfull=1#post1175938):
BASCOM (плавучка) - 13 секунд
BASCOM (целые) - 0.5 секунд (да, полсекунды)
Для полной честности можно еще прибавлять 1.25 секунды на инициализацию.
Хотя стоит подумать над альтернативной процедурой для перехвата. Пример: bload"" в некоей демонстрационной программе на бейсике, после bload"" внутри программы нет обращений к клавиатуре - перехода на 2B8E в этом случае не будет.
- - - Добавлено - - -
Как вариант - щелкание магнитофонным реле (1B4F в 2.5), вызывается в конце CLOAD, VERIFY, MERGE, CSAVE, BLOAD, BSAVE.
- - - Добавлено - - -
Еще лучше реагировать на релешный бит порта 1, тогда можно не привязываться к адресу процедуры.
Реле это правда отличная идея и наверняка наиболее универсальная. Надеюсь, что ты сохранил его в новых версиях Бейсика.
В 2.55-2.70 сохранил все по максимуму, в т.ч. реле.
Есть еще один нетрадиционный вариант ускорения бейсика 2.5 (или его потомков) - сделать версию для ориона-про (с мультикартой). В турбо там будет в 3 раза быстрее, с отключенным турбо (переключать можно программно) примерно как на векторе.
Есть еще один нетрадиционный вариант ускорения бейсика 2.5 (или его потомков) - сделать версию для ориона-про (с мультикартой). В турбо там будет в 3 раза быстрее, с отключенным турбо (переключать можно программно) примерно как на векторе.
Привет всем...
По хорошему - надо компилятор Basic' a делать...
Например, на основе драйверов устройств...
В смысле - на основе библиотеки кодовых процедур...
???
Stl75, компиляторов Бейсика есть целых два, Microsoft BASCOM (http://cpmarchives.classiccmp.org/cpm/Software/rlee/M/MICROSOFT/BASCOM/) и Amsterdam Compiler Kit (https://github.com/davidgiven/ack) умеет компилировать Бейсик для CPM под 8080, правда без плавучки.
Еще есть игрушечный компилятор бейсика на бейсике BCBC (http://www.z80.eu/basic.html). Его не пробовал, но я и ACK не пробовал.
Improver
08.04.2023, 22:06
По хорошему - надо компилятор Basic' a делать...
Например, на основе драйверов устройств...А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.
А что если для этого адаптировать ЛС-Паскаль? Там был интерпретатор и компилятор с библиотеками, которые и использовать... Если это возможно.
Я думаю, Basic - на процедуры разобрали и
получились драйверы устройств...
Там команды - те же самые только в виде процедур...
А что если для этого адаптировать ЛС-Паскаль?
Если отклониться в частичный оффтоп, то разных компиляторов (не бейсика) для вектора довольно много. ЛС, насколько помню, компилирует в P-код и это сильно на любителя. Если нужна поддержка векторовской графики, то это тоже было/есть. Например в VU30 упоминается "graph.crl - графическая библотека для языка программирования BDS C". А рядом там, кстати, заметка, как рисовать точки и линии средствами паскаля (на примере turbo pascal для z80, но не вижу серьезных препятствий для подобных процедур и в других компиляторах). Были еще библиотеки, возможно PPC подскажет. Ну и не могу в очередной раз не упомянуть z88dk - он умеет компилировать под вектор и там среди прочего есть и поддержка графики. И там проще (по крайней мере для меня) чем в CP/M-овских компиляторах добавлять ассемблерные процедуры.
Были еще библиотеки, возможно PPC подскажет.
Чувствую себя очень неловко обсуждая runtime окружение и C в теме про BASIC и очень прошу извинить за оффтоп так как совсем не хочется чтобы это повлияло на BASIC движение и его дальнейший генезис. Но раз ты спросил, попробую обозначить несколько моментов как они видятся учитывая по мере сил и BASIC 2.x, и совсем не претендуя на абсолют. Это просто соображения.
Библиотеки были, они есть и они будут - в смысле сращивания графики с языком C. Я серьёзно подумываю над этим но сейчас очень глубоко занят неким другим проектом под Вектор. Он тоже на C (так совпало), видится мне немаловажным, и хочется верить, что также пригодится и по этой теме.
В простейшем случае задача сводится к написанию прослойки, поддерживающей calling convention компилятора или даже интерпретатора. В таком виде у задачи нет ничего сложного, просто готовые функции обрамляются entry/exit кодом с поддерживаемой конвенцией, сохранением регистровых переменных и (если того требует конвенция) расчисткой фрейма перед выходом. Прослойки в общем-то можно делать сменными и тогда можно поддержать что угодно, хотя-бы даже и нативный BASIC интерпретатор. Но в любом случае потом это линкуется монолитом (либо становится частью интерпретатора). В виде графических примитивов могут сойти либо какие-то из моих старых/новых поделок библиотек (поделюсь без проблем) либо супер оптимизированные графические сниппеты которые несколько лет назад делали ivagor, и ко в одной из веток на форуме.
Собственно, простую 2-х цветную графику 512x256 я так срастил очень очень давно, пример есть вот тут (https://zx-pk.ru/threads/34508-80-simvolov-v-stroke-i-rezhim-512-tochek-voobshche.html?p=1159060&viewfull=1#post1159060). В примере Supersoft С, у него __stdcall (фактически Паскаль). У MS Фортрана __fastcall (2 первых параметра в регистрах <HL>,<DE> остальные если есть в структуре на которую кажет <BC>. У большинства кросс компиляторов __cdecl и <BC> для хранения одной регистровой переменной, я склоняюсь к этому варианту.
Но мне кажется, что более правильно будет стандартизировать и вообще отделить вызываемые функции от конкретного приложения. Типа такой GIOS (он так в GSX-80 и назывался) - графический BIOS. А можно и не только графический, уверен что если мы все скинемся наработками то и всякую иную периферию сможем поддержать и хитрые алгоритмы сжатия и пересылки данных по волнам Векторовской памяти.
Вероятно для пользователя это дожно выглядеть либо в виде сервиса какого-нибудь прерывания, либо - как обычный вызов через единую точку входа (как в CP/M с её call 5 и параметрами). Первое предпочтительнее, rst эффективнее чем call, мы то знаем что на Векторе прерывания точно поддерживаются. Гари Килдалл таких предпосылок не имел. Сервисный вызов вполне может быть "многослойным". Программа для конкретного компилятора в виде первого сервисного вызова может просто ставить переходник-толмач поверх стандартно выбранной конвенции о вызовах (скажем, поверх чего-то __cdecl - подобного).
Тогда не будет проблемы с медленной линковкой сотен функций и позиционная независимость: Векторовская графика может быть уже предзагружена хоть в некий ROM, хоть-как часть ОС. Главное чтобы "линковка" была так или иначе by ordinal.
Примитивы можно вообще запихнуть в квазидиск.
Если всё правильно организовать, это может выглядеть как R/O системный файл CP/М или МикроДОСа находящийся на определённых дорожках квазидиска.
Возможно, RDS тут использовать предпочтительнее, хотя и в стандартной CP/M и в МикроДОСе тоже есть стандартный user extension вход для расширения функций системы. Под большинство ОС можно иметь до 8 цветов (или 16 если в этот момент не нужны функции BIOS. Пример - Robotz, где все меню 16-цветные а BIOS временно перемещён на квазидиск). Опять-же с Баркарём можно как-то это подружить в перспективе.
А если программе вообще не нужна ОСь то все 16 цветов доступны всегда.
Главное - договориться о стандартной системе вызовов и присвоить номера вызываемым функциям.
По секрету. Такую "стандартную" систему входов я также делал в далёких 90х. Оно работало, даже код сохранился где-то. Самое главное - стандартизировать соглашения о сервисных вызовах.
Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.
Такие мысли всякие. Ещё раз sorry за оффтоп.
Когда я за это возьмусь, ориентироваться буду на Ацтек. У него теперь сняты ограничения на распространения компилятора в некоммерческих целях. И главное, хоть он и K&R но им можно компилить как host-target на PC, так и на Векторе (это важно само по себе) потому как цомпилер под 8080.
Очень было бы - хорошо, чтобы кто то осилил данную задачу...
Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...
Очень было бы - хорошо, чтобы кто то осилил данную задачу...
Команд в Basic' e Вектора - не тысячи...
Недавно считал по руководству, насчитал штук - 90...
Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.
Я возьмусь. Но не сейчас. И одному тут точно не справиться. Думаю, одно обсуждение деталей может занять немало. А там есть что обсудить. Правда всё вроде решаемо, но видятся компромиссы (в смысле либо жертвы размером оставшегося пользователю ОЗУ либо - жертвы скорости отрисовки). Но это всё-таки оффтоп.
Сейчас я очень хочу сначала довести один проект до некоего разумного состояния. Погряз ;)
А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой. Тоже трудозатратно учитывая как там всё переплетено, но можно начать с малого.
PS. Чтобы исправиться за флуд/оффтоп, прилагаю свою безуспешную попытку создать некое подобие динамической игры на BASIC 2.5 в далёком 1991м. Тогда я пришёл к тем же выводам что недавно высказал ivagor: BASIC 2.5 в его текущем состоянии для таких игр не самое лучшее средство разработки. В том числе и поэтому, творение получило своё заслуженное название, то бишь "полный и катастрофический провал"...
Зато по поделке становится ясно, где затыки: обработка клавиатуры и вывод спрайтов. Возможно они взывают к изменениям в интерпретаторе.
А для BASIC наверное возможна постепенная "пересадка органов". В смысле замена существущих внутри него драйверов на более быстрые один за другим, процедура за процедурой.
Собственно в 2.70 так и сделано и без убирания некоторых компонентов для освобождения места дальнейшее заметное ускорение вряд ли возможно. Есть 3 вещи, которые можно сильно ускорить в runtime библиотеке (без перехода к компиляции): PUT (при ширине фрагмента кратной 8 точек), PAINT (выкладывал отдельно соответствующую процедуру), вывод символов. В этих задачах ускорение возможно за счет перехода от пикселей к байтам, проблема в нехватке места и в совместимости. Если убрать из бейсика быстрый набор, то скорее всего получится впихнуть быстрый PUT или PAINT (не вместе, а быстрые символы точно не поместятся). А про компилятор повторю мысль, которую уже писал: если нацеливаться на компиляцию 2.5, то runtime библиотка - не проблема (она уже есть), проблема в трансляторе.
metamorpho
10.04.2023, 13:49
......Есть 3 вещи, которые можно сильно ускорить в runtime библиотеке (без перехода к компиляции): PUT (при ширине фрагмента кратной 8 точек), PAINT (выкладывал отдельно соответствующую процедуру), вывод символов. В этих задачах ускорение возможно за счет ..........
А каков шанс ускорить команду POKE ? Например если там отключить проверку адреса куда заносятся данные (это не повлияет на совместимость), то насколько быстрее будет работать такой вариант ?
Может там ещё чего подкрутить можно, но так чтобы сохранялась совместимость со старыми программами на Бейсике.
Могу порекомендовать использовать в POKE шестнацатеричные числа (например &0F вместо 15) в качестве аргументов, это может ускорить чуть ли не в 2 раза (конечно не всю программу, только POKE).
Да, было бы здорово иметь такой готовый Vector API рантайм с поддержкой языков высокого уровня. Мне кажется, это однозначно ускорило бы разработку софта для платформы, причём не обязательно игр.
Готовые компиляторы - есть для других ретро - платформ...
Например, ZX Boriel Basic - для Спектрума...
www.boriel.com
Либо компиляторы на ассемблере -
MCoder 2, например...
На MCoder 2 - фирма Atlantis Software -
выпустила множество игр...
Список игр на - www.vtrd.in - можно посмотреть...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot