Одна из ошибок, которая чуть было не заставила меня выкинуть z88dk в окно раньше, чем я увидел первый результат, была исправлена четыре дня назад.Цитата:
Сообщение от ivagor
Вид для печати
Одна из ошибок, которая чуть было не заставила меня выкинуть z88dk в окно раньше, чем я увидел первый результат, была исправлена четыре дня назад.Цитата:
Сообщение от ivagor
оффтоп про z88dk
Скачал последнюю версию - чуда не случилось, исходный неправленый вариант библиотеки picojpeg не переваривает. Зато правленый вариант текущий z88dk делает на 917 байт короче и на 16% быстрее (это вариант без ассемблерных вставок)! Прогресс за 2 года ощутимый, еще бы работу с арифметикой доработали.[свернуть]
- - - Добавлено - - -
Извините, заканчиваю с оффтопом, но авторам компиляторов на заметку - как надо использовать возможности 8085. Один и тот же декодировщик jpeg c Леной, чисто Сишная версия без ассемблерных вставок (z88dk 20230414, sccz80):
8080 (29321 байт) 48 секунд
8085 (26962 байта) 34 секунды
z80 (28952 байта) 40 секунд
Это все с векторовским торможением, но абсолютные цифры не так важны, интересны соотношения.
Вчера ошибся в размере версии 8080, исправил. Дополнение: попробовал вариант с ассемблерными вставками - в отличие от чисто Сишного он почти не ускорился, всего на 0.1 секунды, зато размер меньше на 503 байта. Надо смотреть библиотеки, они наверно оптимизировали арифметику, в первую очередь умножение, а в версии с ассемлерными вставками вся критичная арифметика в них.
В MSX-BASIC имя переменной это два байта. Тип хранится отдельно и по совместительству является размером. По умолчанию A, A%, A$, A() -- разные переменные, потому что имеют разные типы. Если вызвать DEFINTA, A становится эквивалентом A%.
Можно без потерь сделать имена переменных трехбуквенными, если закодировать их в RADIX-50: в те же два байта помещаются 3 буквы и цифры. Подчеркивание не в стандарте RADIX50, но можно использовать вопросик или точку. Преобразования не самые удобные, правда.
В BASIC 2.5 я не залезал глубоко, но по-моему дела обстоят немного иначе -- мне показалось, что признак строковости это старший битик в имени переменной ($00,$41 = A, $80,$41 = A$, $C1,$41 = AA$). Так конечно RADIX50 не вклячишь.
Типы переменных в 2.5 Евгений Филиппов описал в Vector-User 10.
MSX Basic при большом желании можно портануть с ПК8002, но есть неприятные дополнительные требования и ограничения. Из экранных режимов скорее всего получится эмулировать текстовые. Спрайтов не будет. Если с квазом Баркаря, то можно попробовать сделать SCREEN 2. Толку без спрайтов наверно в этом нет. Для любителей расширенной математики с диском есть MBASIC и комания, для магнитофонщиков - Бейсик-Корвет.
Понимаю что я немного не в теме, всё же осмелюсь предложить посмотреть на
MSX Basic Compiler
https://github.com/leonhad/msx-bcc
-- подозреваю, что в нём можно заменить codegen часть + допилить рантайм -- и получить тем самым тот же язык для Вектора.
На мой поверхностный взгляд это близко по сложности к перепиливанию спековского Boriel - готового рантайма для вектора нет и z80.
Уголок любителей истории. Оказалось, что circle в 2.5 и драйверах устройств адаптирован с Ириши. Процедура быстрее корветовской, но довольно громоздкая. У Вектора сравнительно быстрый circle и неторопливая заливка, у Корвета наоборот.
По-моему ты оптимизировал заливку на Векторе, или это было только в одной из версий для альтернативных процессоров?Цитата:
Сообщение от ivagor
Заливку оптимизировал (отсюда и далее), но отдельно, а в бейсик не встраивал (там места не хватает).
- - - Добавлено - - -
В процитированном фрагменте "У Вектора" надо понимать в контексте сообщения, т.е. "в 2.5 и драйверах устройств".
Эта дэмка нарисовалась в ходе продолжения экспериментов с палитрой.
В данном случае целью было показать что можно сделать на Бейсике на Вектор-06Ц.
Всё что вы видите это использование программируемой палитры Вектора
и написано полностью на Бейсике (без использования машинных кодов).
В целом данный эксперимент удался, хотя первоначальный "сценарий" картинки был поинтересней,
но его не удалось реализовать. Глюк с мельницей (в правом верхнем углу) оставил - мне показалось
это подходящая нотка для дэмки в тему дождя (молния в дали освещает мельницу).
Картинку собирал с помощью PaintNet + конвертор в дату + Pretty 8080 Assembler c новой возможностью сохранять в TAPE (спасибо svofski).
Тестировал на Бейсике 2.71 (спасибо ivagor).
Порядок загрузки.
1. Грузим Бейсик
2. Грузим DINOSINT.cas и запускаем RUN
3. Программа запросит файл - грузим PATHDINO.cas
Добавил ещё две версии дэмки.
Архив DINO2 - прибавил музыку (не свою) и отблеск молнии на "картине".
Архив DINO3 - прибавил музыку (не свою) и отблеск молнии на "картине" + бордюр.
https://www.youtube.com/watch?v=YE8GAIis7HM
Порадовал :D Спасибо!
Здорово! И радует, что хорошо работает в классическом 2.5
Замечательно!
Появилась добавка.... :)
https://zx-pk.ru/threads/30566-bejsi...=1#post1177002
metamorpho, с музыкой лучше (в DINO3 на мой вкус перебор спецэффекта).
А я довел бейсик до исчерпания свободного места, осталось байт 20. Главная фишка 2.72 - более быстрый PAINT, в котором налево строку закрашивает пиксельно-байтово. Ситуация примерно как с триммером, когда побрил половину лица и сел аккумулятор, направо осталась пиксельная заливка. Тем не менее в 2.72 PAINT в среднем на 36% быстрее чем в 2.5, это заметно. Дальше уже придется или оставить как есть или начать убирать ненужные элементы бейсика.
- - - Добавлено - - -
Добавлю, что прогон Рекламы в 2.72 быстрее чем в пзушном бейсике 6128 и бейсике 2.60ВМ1.
Upd 22.04.2023: Резко разогнал PAINT, теперь он почти в шесть с половиной раз быстрее 2.5.
Остальные минусы и плюсы:
1. Убрал быстрый набор по УС+СС.
2. CIRLCE медленнее 2.72 на 0.2-0.5% (но быстрее 2.5 примерно на 9.5%).
3. В 2.72 заметил ошибку PAINT, которая могла проявляться при заполнении экрана с заворотом за край, поэтому 2.72 убрал, в 2.80 ошибка исправлена.
4. За счет пунктов 1 и 2 в упакованном виде бейсик стал на 226 байт короче.
Клёвый эксперимент! Отдельное спасибо за музычку и видео!
Еще пара слов про paint в 2.72. Из-за особенностей процедуры в основном используется заливка налево и перевод правой заливки на байты, как оказалось, дает очень маленькую прибавку скорости. На вопрос - "а почему тогда скорость намного меньше чем у процедур в ветке Программирование на ассемблере?" ответ такой - в paint для определения цвета используется пусть и разогнанная, но пиксельная процедура определения цвета, а в самых быстрых paintах - байтовое определение цвета. То, что в 20 оставшихся в 2.72 байт не влезает правая байтовая заливка - не критично, но, к сожалению, в 20 байт не влезут и процедуры байтового определения цвета.
В саге про paint не хватало оценки влияния байтовых проверок цвета на скорость. В качестве теста простая программка
Скрытый текст
1 CLS
2 COLOR15
3 CIRCLE128,128,127
4 PAINT128,128,10,15
5 STOP[свернуть]
Время выполнения от RUN до STOP:
1) 2.5 - 29.3 секунды
2) 2.72 - 18.7 секунды
3) 1 из 5 - 14.4 секунды
4) 2 из 5 - 12 секунд
5) 3 из 5 - 9.6 секунды
Под номерами 3-5 это 2.72 с удаленным быстрым набором по УС+СС и разогнанным (не до упора) paint. Не до упора, т.к. опять закончилось свободное место. Там 5 веток, в которых стоит использовать байтовые проверки, а мне хватило места на 3 из 5. Очевидный вывод, что довольно быстрый paint в векторовском бейсике возможен, было бы где его разместить.
Upd 22.04.2023: Расчистил место и довставлял байтовые проверки:
6) 4 из 5 - 7.1 секунды
7) 2.80 (5 из 5) - 4.5 секунды
Это не абсолютный рекорд для вектора, процедуры из Программирования на ассемблере быстрее. В бейсике компромисс для сокращения размера и совместимости - внутри процедуры используются координаты, а в самых быстрых вариантах полный переход на адреса+маски. Но такой переход кроме увеличения размера процедуры требует еще и больше стека, пришлось отказаться.
А по АР-2 быстрый набор сохранится? если да, то я за то чтобы пожертвовать (я УС+СС никогда не пользовался).Цитата:
Сообщение от ivagor
Да, сохранился. "Новый" по УС+СС - 335 байт, "старый" по АР2 - 79 байт. Есть еще резервы - таблицу синусов для дуг (256 байт) в CIRCLE можно сократить вдвое, а промежуточные значения вычислять линейной интерполяцией. Дальше сложнее. Можно убрать принтерные процедуры, выигрыш не оценивал. Ну и есть две таблицы по 256 байт для вычисления адресов и масок точек. Их в крайнем случае можно сократить (в basic48k сократил таблицу масок до 8 байт), но это приведет к замедлению графики. Вопрос в приоритетах, что важно, а что не очень.Цитата:
Сообщение от Ramiros
По поводу быстрых наборов: активно пользовался и тем, и другим, но чаще через УС+СС, и заметил ещё с версии 2.50, что команды там выводятся немного по-разному, например по УС+СС+<запятая> выводит CLOAD с пробелом и кавычками в конце, а по АР2,[ -- без кавычек и пробела. Может если как-то объединить оба этих набора, то это немного сократит код?Цитата:
Сообщение от ivagor
"Классический" быстрый набор (АР2+), унаследованный от РКшного бейсика, выдает операторы и функции из таблицы токенизатора. А "новый" (УС+СС) пользуется собственной отдельной таблицей, куда в принципе можно ввести что угодно. В примере с cload его можно убрать из УС+СС, но не из АР2 (если запретить выдачу cload в АР2, то это не сократит, а увеличит соответствующую процедуру). Оба быстрых набора сегодня лично мне кажутся не очень нужными, особенно учитывая наличие современных утилит конверсии txt<->bas/cas, но я догадываюсь, что не все со мной согласны, поэтому в 2.55-2.72 я их не трогал. Если уж убирать, то ради какой-нибудь очень нужной штуки.
Есть идея усовершенствовать ANTIGRAV - ускорить человечика и взлёт ракеты, а также уровень при загрузке не рисовать постепенно, а быстро загрузить через BLOAD.
1. Вывод человечика идёт через POKE. По совету ivagor-а я уже заменил десятичные данные на шестнадцатеричные - немного ускорения уже есть.
И осталась идея в команде POKE отключить проверку адреса куда заносятся данные - это будет ещё + в ускорение.
Как можно это реализовать через ассемблерный код вставленый в тело моей программы (подобно тому как вставлен альтернативный опрос клавиатуры) ?
2. Ускорить вывод ракеты - он происходить через PUT. ivagor написал что PUT можно ускорить при ширине фрагмента кратной 8 точек.
Если нежелательно изменить это в Бейсике (для сохранения совместимости), то можно ли это реализовать через ассемблерный код вставленый в тело моей программы,
чтобы это было особенностью только моей программы, а не изменения Бейсика (это для сохранения совместимости) ?
Также есть проблема что PUT неправильно выводит данные, если при аппаратном скроллинге есть переход через границу адреса FF на 00 (в столбике).
Можно ли как-то это устранить ?
3. Загрузка уровня через BLOAD - можно реализовать уже сейчас без видоизменения Бейсика.
Таким образом можно сделать несколько различных уровней.
И так можно очень сильно сэкономить памяти т.к. всё что рисовалось через операторы Бейсика,
будет уже нарисовано и в готовом виде загружено в экранную-память (8000-FFFF).
При этом графика уровня уже может быть более разнообразной т.к. она не занимает память, а грузится сразу на своё место.
А ещё можно данные уровня тоже грузить через BLOAD (заодно с картинкой уровня) например с 7F00-FFFF.
Таким образом нет необходимости хранить все уровни в коде программы - это тоже сэкономит память.
Это очень-очень маленькое ускорение, могу гарантировать, что заметно не будет.Цитата:
Сообщение от metamorpho
Да, это сравнительно простой вариант. В сложном, если очень заморочиться, можно сделать быстрый PUT с любыми размерами, но при некоторых неудобных значениях ширины придется сочетать байтовый и пиксельный вывод. На руку играет ошибка в описании бейсика, где приведена формула размера массива для GET, дающая во многих случаях завышенные значения. Возможно это для компенсации неаккуратного get, который иногда использует лишние байты. Проблема с быстрыми GET и PUT в том, что если не убрать все "лишнее" из бейсика, то они не поместятся. Вариант с кратностью 8 точкам проще, но менее интересен, т.к. во многих игрушках ширина фрагментов не подходит и они не ускорятся.Цитата:
Сообщение от metamorpho
Можно переделать обрезание на заворот, но это создает потенциальную несовместимость с имеющимися программами, вдруг есть игрушки, которые используют эту фичу.Цитата:
Сообщение от metamorpho
Лучше использовать ассемблерную процедуру.
- - - Добавлено - - -
Обращу внимание, что загрузка 32 килобайт в формате монитора на стандартной скорости - это в районе 200 секунд. Сейчас в ANTIGRAV от RUN до завершения построения уровня проходит 164 (2.5) или 134 (2.71-2.72) секунды. Но экономия памяти для программы на бейсике при использовании bload несомненная.Цитата:
Сообщение от metamorpho
Не, я имел в виду не сокращать как-то количество команд, а сделать для обоих вариантов один общий метод вывода команды из одной таблицы, отдельной или токенизатора.Цитата:
Сообщение от ivagor
Может и так, если не писать программы непосредственно в Бейсике. :)Цитата:
Сообщение от ivagor
Технически можно убрать отдельную таблицу для УС+СС и задублировать выдачу по AР2+ и УС+СС+, но мне это кажется излишним.Цитата:
Сообщение от Improver
Заменил 2.72 на 2.80. Дополнил результаты тестирования PAINT.
Ну это, может быть, зря, я предлагал объединить их с АР2, а не сократить... Можно как-то вернуть хотя бы основные команды, RUN, LIST, NEW, EDIT, CLOAD/CSAVE и BLOAD/BSAVE?Цитата:
Сообщение от ivagor
Комбинации по АР2 перечислены в конце документации Векторовского бейсика, тут проблем нет, просто по УС+СС легче запоминаются, например, УС+СС+R == RUN, УС+СС+L == LIST и т.п., я их до сих пор помню. :)Цитата:
Сообщение от ivagor
- - - Добавлено - - -
Хотя, если это только мне нужно -- забейте, пусть лучше будет paint быстрее.
Чисто теоретически есть вариант с залезанием бейсика в кваз Баркаря. Если ориентироваться на сохранение скорости графики, то оставляем экран все время включенным, а в область E000-FFFF кваза выносим что-то некритичное для быстродействия или редкое (например быстрый набор, принтер, возможно высшую математику) и щелкаем страницей по мере необходимости. Ограничение - программе нельзя делать HIMEM выше E000, скорее всего таких программ (по крайней мере распространенных) и не было. Но это уже принципиальный шаг от голого вектора к использованию кваза, всерьез на эту тему не думал.
У меня ложные воспоминания, что вроде я видел краткое описание дискового бейсика для РДС. Найти не могу, кто-нибудь помнит такое описание? Возможно я залезал внутрь, но базы иды тоже нет, максимум смотрел в отладчике.
А разве был такой?Цитата:
Сообщение от ivagor
Вот тут ничего похожего нет? https://github.com/Vitaly-Vyunov/vector
basic25d.com 17792 байта. Руководства пользователя и программиста я смотрел, про бейсик там не заметил. Отстутствие описания в данном случае не проблема, но придется потратить дополнительное время.
- - - Добавлено - - -
Память была не ложной, нашел описание.
Глянул дисковый бейсик Виталия Вьюнова для РДС. Он получен патчением оригинального 2.5, что позволяет сравнительно просто вычленить изменения для работы с диском в РДС. На этом пока отложил в сторону, т.к. сильной потребности в дисковых "новых" бейсиках нет и мне эта тема кажется скучной. Еще отмечу, что basic25d несовместим с z80, как и многие его собратья. С 8085 тоже несовместим, но на 6128 не работала РДС в связи с отсутствием сигнала СТЕК и квазидиска.
Для удовольствия в очередной раз покопался в математике. Крупные оптимизации сделаны ранее, но удалось чуть-чуть ускорить и при этом немного сократить.
Для смотревших дизассемблер альтаирского бейсика не будет новостью, что мантисса - 3 байта, но в части вычислений добавляют 4й младший байт, который потом используется для округления. В принципе можно операции с этими "лишними" байтами поудалять и округления убрать, для игрушек скорее всего точности хватило бы. Но на такую несовместимость у меня рука не поднимается, это надо было в конце 80х - начале 90х делать альтернативный заточенный под игрушки бейсик.
Может быть можно каким-нибудь странным образом сделать поддержку цвета в Бейсике-Корвет?
Сугубо теоретические капитанские варианты:
1. Без кваза - 4 цвета с разрешением 256x256.
2. С квазом Баркаря (или для 6128) - 4 цвета с разрешением 512x256 или 16 цветов 256x256.
Основная проблема в том, что малой кровью это может сделать тот, у кого уже есть дизассемблер корветовского бейсика (у меня нет). Его можно дизассемблировать, есть забугорная книжка (где-то здесь я приводил ссылку) с дизассмом примерного прототипа, но это надо захотеть.
Эх, все непросто. Когда-нибудь я дозрею испечь свой Бейсик.
Будет очень здорово, если дозреешь.