Сейчас бейсик в асме не нужен, но если
оффтоп
не оглядываться на вектор и воспарить мыслью, то можно увидеть картину: бейсик с асмом в пзу. Человек включает комп и сразу программает, не нужно ничего загружать.[свернуть]
Вид для печати
Сейчас бейсик в асме не нужен, но если
оффтоп
не оглядываться на вектор и воспарить мыслью, то можно увидеть картину: бейсик с асмом в пзу. Человек включает комп и сразу программает, не нужно ничего загружать.[свернуть]
Вот если бы Бейсик для Вектора в 88 году так умел, тогда конечно.
заметил еще один глюк - если нажать АР2 затем УС+СС+любую клавишу, то печатаются гибриды из двух слов, (не два последовательных слова, что было бы логично, а именно какой то гибрид из начала одного слова и конца другого). Но это безобидный глюк т.к. бейсик не умирает :)
Ну, чудеса... :v2_conf2: Я тут погуглил - про этот баг даже в первом выпуске "Байта" было:Цитата:
Сообщение от ivagor
http://sensi.org/scalar/media/w/vect...-33-151108.pdf (страница 6, примерно в середине страницы)
Возможно, какой-то из ваших патчей попутно починил и эту проблему?
Не исключаю что глюк был в ранней версии (наверное счетмашевцы его по тихому пофиксили), но в моем бейсике с кассеты такого глюка небыло точно.Цитата:
Сообщение от x-code
1.Исправил.Цитата:
Сообщение от Ramiros
2. Про УС+D. Не мог вспомнить, где я про это читал, оказывается в байте печатали. И тогда я уже вспомнил, что читал про это в начале 90х и у меня тогда тоже этой ошибки не было. Идей на эту тему у меня нет, "закладок" в бейсике на УС+D не нашел (смотрел исходный вариант, без моих правок). У меня был астраханский вектор, вроде как и у Ramirosa.
3. Несколько дней копался в реализации элементарных арифметических операций - умножение, деление, сложение и вычитание.
Тестировал вот на таком фрагменте:
Удалось ускорить на 11% по сравнению с 2.59 или на 14%, если сравнивать с исходным 2.5. Больше и удачнее остальных операций (практически без увеличения размера) ускорилось деление. Очень не хватает команд и регистров более развитых процессоров.Код:10 FORI=1TO10000
20 A=I*I/I+I-I
30 NEXT
40 STOP
Добавил в предыдущий пост архив с бейсиком 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. Может пропустить явную ошибку
2. Может найти ошибку там, где ее нетКод:10 A="1"
3. Кое-что может неправильно вычислитьКод:10 A=1
20 PRINT A-2
Бейсики из этой темы, например 2.60 или более ранний в картотеке (обычный, дисковый) работают без ошибок.Код:PRINT SGN(-1)
Надо бы пересобрать 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-килобайтным загрузчиком вместо 2.5?
Давно собираюсь, надо бы сделать.
- - - Добавлено - - -
Может и монитор заменить, например на дос (только надо выбрать - какой именно)? Тест техпрогона пожалуй стоит оставить.
Может просто замените сам бейсик? ))) В котором хотелось бы увидеть обозначение, что он 2.61 ,а не какой-то там нонейм )))Цитата:
Сообщение от ivagor
Я тогда и заменил (без надписи 2.61 при старте).Цитата:
Сообщение от dbk
Может в Бейсик внедрите надпись? ) Прошивка без монитора, увы - не мой вариант.Цитата:
Сообщение от ivagor
Наверняка я вернусь к этой теме. Правда у меня на первом месте в момент окончания предыдущего бейсиковского обострения стояла задача сделать дисковую версию, хотя бы свой вариант 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 после выхода в эфир недостает индекса для навигации.
Как идея для пока мерцающей где-то в далеком будущем надежды на каталогизацию Бейсиковского софта: ссылку на ютуб + временную метку можно было бы вставлять в описание программы.
Да идея уже не мерцает. Процесс потихоньку пошел. Пока правда в текстовом файлике, с указанием названия, даты, автора (если есть информация), краткого описания и тегов по жанру и принадлежности. Делаю по два скриншота, один из них с заставкой (титульником). Сортирую файлы пока двумя вариантами - по авторам, и по жанрам. Попадается много дублей, причем некоторые с разным размером. По хорошему, нужно разбираться, чем отличаются. По возможности, просматриваю, стараюсь определить в чем разница. По завершению, могу бросить Вам собранную информацию, и если будет желание - её можно будет добавить в картотеку.
На стримах несколько раз упоминалась тема конверсии TXT->BAS и в этой связи вспоминали несомненно заслуженную, но не очень удобную для кросс-разработки утилиту BT.COM. Напомню, что есть современная утилита svofski на питоне.
К седьмому стриму. Переделал kombin.dba в cas, такой вариант можно грузить в эмуляторе в кассетный бейсик.
- - - Добавлено - - -
К крестикам-ноликам от 11.87. RB7GA - Аркадий Григорьевич Ройтван, а 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, который, как я уже писал, является бейсиком 1.3 с небольшими косметическими изменениями. Интересный момент - программа не рисует то, что изображено на экране компьютера на обложке, она рисует примерно вот это (до вывода надписей). Т.е. это как раз пример фрагмента, заимствованного в рекламе для 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 - это далеко не предел возможностей вектора.
Так ещё в те годы был БЕЙСИК-М, который в разы (а то и десятки раз) обгонял 2.5 по скорости вывода текста, да и по другим параметрам тоже... Или это опечатка, имелся в виду 2.61?Цитата:
Сообщение от ivagor
Вывод символов в бейсике-м не быстрее, чем в 2.5, а основной цикл интерпретации даже немного медленнее. Когда модифицировал бейсик для ВМ1 и 48k я замерял и получилось, что заполнение экрана символами в -м примерно на 3.5% медленнее, чем в 2.5. Там внутренние резервы использовали для добавления новых возможностей, на радикальное ускорение вывода символов места не осталось.
Что в -м быстрее, так это скролл при выводе текста в нижнюю строку, поэтому листинг длинной (занимающей много экранов) программы будет выводится раза в 2 быстрее. Это сделано просто убиранием "лишнего" торможения, оборотная сторона - пострадал внешний вид, скролл с "заворотом", в 2.5 выглядит аккуратнее. Спорное решение, возможно стоило сделать управление скоростью скролла, хотя бы два варианта - как в 2.5 и максимальный разгон, как в -м.
- - - Добавлено - - -
Кстати о скролле. Совершенно забыл, в версии для ВМ1 и в 48k я же его тоже разогнал, но не до упора, как в -м, а до упора без заворота. В итоге 48k на ВМ85 (а без ВМ85 он не работает) скроллит как -м (разницу в торможении отыгрывает за счет более быстрого проца), а версия для ВМ1 скроллит быстрее -м процентов на 15 (там еще и вывод графики и символов оптимизирован, но максимум на десятки процентов, не в разы, как я уже писал), и это все без заворорачивания.
В 2.61 я про это забыл, может и там надо было сделать.