Я согласен, очень Векторовская картинка получилась.
Пока многопроцессорные Векторы не изобрели, можно сделать рендерфарм на локальной сети. Допустим 16 клиентов и один раздатчик.
Вид для печати
Я согласен, очень Векторовская картинка получилась.
Пока многопроцессорные Векторы не изобрели, можно сделать рендерфарм на локальной сети. Допустим 16 клиентов и один раздатчик.
И можно даже сделать в рамках существующих программных и аппаратных средств при участии оператора. Рендерфарм из 32 векторов. Каждый рендерит столбец 8x192 и сбрасывает через магнитофонный выход 3 файла (3 плоскости) по 256 байт на одну машину. Сам рендер займет чуть больше 5 минут (если 2.99), но потом еще возня с перекачкой. Со стороны наверно этот цирк выглядел бы забавно.
Вектор в некоторых аспектах несомненно крут, а мне было достаточно 1) захотеть; 2) найти где списать; 3) списать. Хотелось бы еще изобразить что-то вроде такого, причем на векторе можно в значительной степени "настоящими" цветами, без жесткого дизера.
Такое можно устроить из эмуляторов. Звук можно провести через Virtual Audio Cable. Надо только подумать о том, как сделать так, чтобы 32 Вектора не конфликтовали друг с другом.
Видимо так: мастер соединен со входами всех воркеров. Выходы воркеров сливаются в один провод, который идет в мастер.
Каждый воркер имеет свой номер xxx. Он делает BLOAD"TASKxxx". Получает задачу с номером столбца (можно даже диапазон строк, чтобы дробить задачи на мелкие). Считает задачу. По окончании задачи делает BLOAD"READYxxx" и ждет -- это будет от сервера команда готовности принять результат от этого воркера. Затем он делает BSAVE"RESULTxxx" и переходит к началу (ждет следующую задачу).
Сервер, когда не раздает задачи, просто делает BSAVE"READYxxx", затем BLOAD"RESULTxxx". Нужен таймаут на BLOAD. Если нет ответа через 5 сек, переходим к следующему запросу.
BLOAD по-моему может бесконечно ждать требуемого имени. Вот чего я не знаю, так это как сервер сделает BLOAD с таймаутом. Наверное для этого потребуется все-таки какая-то ассемблерная хирургия.
Если не гнаться за максимальной эффективностью, то можно обычным BLOAD без таймаута грузить результаты в жестко заданном порядке - сначала номер 1, потом 2 и т.д. до 32. Меня больше смущает физическая реализация проводки 1<->32, тут стандартным решением вряд ли обойдешься. Для 1<->2 в детстве была покупная коробочка, там кнопками можно выбирать.
А что если порядок окажется не тот? Время расчета всегда будет отличаться, хоть и не сильно. По-моему лучше наколдовать сервер чуть-чуть поумнее. Если он будет колдунский, он еще и сможет раздавать задачи для загрузки в воркеров с уже подставленными идентификаторами тоже сам. Только воркеров все же придется вручную по очереди запускать.
За физическую реализацию лучше особо пока не страдать. Тот, кто соберет комплект из 32 исправных Векторов, обязательно сможет разобраться с такой мелочью.
Если порядок окончания расчетов не совпадет с тем, что ожидает мастер, то на мой взгляд это приведет лишь к задержке по времени (снижению эффективности), но не к нарушению работы.
Отвлекаясь от векторпанка можно вспомнить про КУВТы, там была какая-никакая локалка и при большом желании можно было организовать распределенные вычисления.
Как ты видишь ситуацию, когда два воркера закончили +/- одновременно и стали делать BSAVE ? И как распределять задачи, если воркеров меньше 32 ?
Что-то ЛВС-ное мы запускали через EMU, но детали как-то подзабылись. Идея с магнитофонами мне нравится больше, потому что просто понятней с чем имеем дело.
Воркеры должны делать BSAVE только когда получат приглашение (через BLOAD) от мастера.
Если серьезно, то со всех точек зрения реалистичным мне представляется вариант с двумя векторами, соединенными через магнитофонный интерфейс. Мастер рендерит половину, посылает (BSAVE) приглашение второму, дальше проблем нет.
- - - Добавлено - - -
Все же добавлю про дальше. Когда второй (или 3й, 4й и т.д.) готов, то он посылает (BSAVE) мастеру ответ. И тогда мастер ожидает 3 файла собственно с картинкой.
Возвращаясь чуть ранее - мастер должен посылать копии приглашений второму (3му, 4му, ...) пока тот не ответит, на случай если воркер отстает со своей частью рендера.
- - - Добавлено - - -
Но тут потребуется патчнуть BLOAD на тему таймаута, как ты написал ранее.
Виртуальных Векторов мы можем насоединять и два и все 32. Правда в винде черт ногу сломит как это сделать, может быть под маком или линуксом это проще будет организовать.
Как в твоей схеме разрешается конфликт я все равно не понимаю. Если сервер отправит приглашение чуть раньше времени, получатель его не услышит и тогда сервер будет ждать ответа вечно. Ну никак не обойтись без таймаута.
- - - Добавлено - - -
А, вижу, ты тоже написал про таймаут. Ну вот.. Может быть проще тогда сервер сделать не на бейсике, раз уж такие дела.
Если решать частную задачу рендера на двух векторах, то проще всего переложить согласование на оператора. Когда мастер или воркер завершают рендерить свою часть они подают звуковой сигнал. Если первым завершил мастер, то переводим его в режим приема файлов с воркера. Если первым завершил воркер, то придется ждать мастера. И ничего не надо патчить, лишь бы оператор был рядом.
Оператора придется патчить напитками и проч. Ну и вообще описание процесса напоминает анекдот про комьютерный вирус из технологически отсталого региона.
Есть еще вариант -- сервер ждет загрузки без имени, то есть первого попавшегося. Когда веркер заканчивает, он начинает делать BSAVE со случайными интервалами между повторами. Рано или поздно всем достанется таймслот, но может быть придется ждать очень долго, в основном из-за того, что клиент не знает продолжать ему или таки наконец заткнуться. И надо позаботиться, чтобы рандомайз был разный на всех веркерах. Еще при таком подходе не понятно, как раздавать новые задачи, если веркеров меньше 32.
BLOAD ведь делает опрос клавиш для останова оператором. Нельзя поками сделать в этом месте патч с вызовом счетчика? Чтобы не новую версию Бейсика писать. Тут не нужен какой-то изощренный таймер. Нет ответа минуту, стоп.
BLOAD пропатчить можно, но все же я продолжаю пребывать в убеждении, что просто для иллюстрации принципиальной возможности годится вариант с оператором за еду, а для чего-то более серьезного нужна сеть. Вряд ли можно изобрести какой-то особенный велосипед, все нормальное на эту тему уже придумано, выбор зависит от приоритетов.
Принципиальная возможность очевидна, а картина с оператором не демонстрирует вообще ничего, кроме способностей оператора, к сожалению. И их тут никаких исключительных не потребуется. Вот когда автоматически куча машин работает в сговоре друг с другом -- это впечатляет.
Композиция "Сферы над планетой у звезды-гиганта". Вот это уже примерно то, что я ожидал и хотел получить от трассировки лучей на векторе.
Попутно заметил, что в 2.98 слегка поломал RENUM, пофиксил.
Upd 13.12.2023: Оптимизированная версия SPGIANTRTX2.cas
Время рисования в 2.99:
SPGIANTRTX.cas - примерно 3 часа 24 минуты
SPGIANTRTX2.cas - примерно 2 часа 57 минут
Вах!
:v2_jawdr: :v2_clapp:
Класс!
Всем спасибо, рад, что понравилось!
Но очень долго рисует. Моральных сил на ассемблерный вариант трассировщика с красивыми сферами не хватает, зато смог заметно разогнать версию на бейсике. Читабельность ускоренного варианта пострадала, поэтому оставил и предыдущий.
Подскажите - есть FDD (образ диска) на нём программы на Бейсике - загрузил его запустил появилась "зелёная оболочка" микродос похоже нажал команду D увидел каталог программ, а как дальше запустить программу на Бейсике и самое интересное можно ли эту записать в формате .bas или .cas чтобы не на дисковом Бейсике запускать ?
Интересуют программы обнаружил их в каталоге программ центра Байт:
- музыкальный редактор (автор Дашковский) .BAS
- музыкальный редактор МУЗА .BAS
и ещё
- игра The House .BAS
Если есть у вас такие программы можете выложить их куда-нибудь ?
Для запуска бейсиковских программ с диска два варианта
1. run.com (run и дальше название бейсиковской программы)
2. Дисковый бейсик. Есть еще версия для РДС, но надо искать ссылку.
Проще пойти другим путем - вытаскиваем с диска .bas и с помощью например программы thetrikа преобразуем в .cas
Сам пользуюсь плагинами для Windows Commandera (OdiWcx) или Fara (надо найти ссылку). При настройке плагина OdiWcx надо задать расширение fdd вместо (или вместе) odi, т.к. изначально он для ориона, но формат образов одинаковый.
https://caglrc.cc/scalar/ware/810/ но по-моему он только для 32-битного Фара.
Только что в соседней теме еще упоминал SteinBlume, которая подходит тем, кто не любит фары с плагинами.
Насколько мне было известно руководство по Бейсику было только в виде сканированных .pdf и .djvu файлов.
И вот как то в очередной раз заглядывая в отсканированное руководство по Бейсику и ломая глаза на плохом качестве текста, я решил сделать более читаемым текст руководства по Бейсику. Вооружившись trial версией известной OCR программы сконвертировал PDF в текст. Качество конечно не самое лучшее получилось, было много ошибок в тексте и всякой непонятности, но всё же местами текст был нормальным. Далее дело шло медленно, но стабильно - я преобразовывал полученный текст руководства в некий новый документ. И вот сейчас представляю его вам.
https://drive.google.com/file/d/1xOi...ew?usp=sharing
Данная версия докуммента конечно не идеальна и возможно содержит ошибки и неточности.
Если обнаружите ошибки или что-то посчитаете нужным добавить про различные хитрости и моменты Бейсика, то пишите здесь в теме про Бейсик или мне в личку и я буду вносить изменения в документ.
Навигация по PDF документу: Можно использовать гиперссылки. Я пользуюсь бесплатной версией программы (PDF XChange Editor) для просмотра PDF файлов. В ней легко перемещаться с помощью CTRL + HOME = в начало документа, CTRL + END = в конец документа, CTRL + F = поиск слова, в меню есть инструмент "Выделить текст" = можно выделить и скопировать любой текст.
Комодорщик обнаружил ошибку в старых MS бейсиках, подробности там.
В оригинальной документации с одной "е":
Вложение 79985
- - - Добавлено - - -
metamorpho, в параграфе 3.5, в описании пропущено FRE() и далее из-за этого в INT(), LOG() и LG() что-то напутано в формулировках... И символ "Пи" там же не правильно написан.
FRE() - определяет размер свободного пространства в ОЗУ
INT() - выделяет целую часть числа
LG() - десятичный логарифм
LOG() - натуральный логарифм
еще
EXP() - число e возводится в указанную аргументом степень
RENUM - перенумерует строки программы в памяти
USR() - обращается к заранее подготовленной подпрограмме на машинном языке
- знак минус
Насчет "Пробелы не допускаются:" - в клонах MS бейсиков 3.2 и 4.x они, к сожалению, много где допускаются. Извините, сейчас не буду искать, где я про это писал, но этот пункт желательно уточнить.
Подробные описания не смотрел, но надо учитывать, что в оригинальном руководстве не все соответствует действительности, например аргументы DELETE, про это тоже где-то писал.
Начиная с 2.61 такая возможность есть.
Спасибо всем за информацию об ошибках !!
Всё исправил и обновил ссылку на новое описание Бейсика.
https://zx-pk.ru/threads/30566-bejsi...=1#post1191025
ivagor, нашёл вот что - в посте #358 в этой теме:
1. например
FOR A=1 TO 10
FOR B=1 TO 10
NEXT B
NEXT A
т.е. можно не указывать NEXT B, NEXT A, а просто написать NEXT, NEXT ?
А что имелось ввиду "NEXT позволяет перечислить переменные через запятую" - как так через запятую, что за переменные ?
2. Пробелы в именах - это относится к Бейсику v.2.5 ?
---------
Ещё - можно ли в Бейсике (не применяя ассемблерных вставок) через OUT в порт 1 вывести синтезированную речь (возможно запретив прерывания) ?
Каким образом (как это выглядит в строках кода) через Bload можно загружать массивы для Put ?
Привет всём...
Через restore, read, data - спрайты рисовать,
много памяти уйдёт...
Хотелось бы по подробнее про загрузку
массивов для put через bload...
Насчёт сроков правильно написали...
Многие не помнят как команды работают,
а Вы за 2 месяца софтину хотите???
Да ещё приличную...
Ну я как бы начну, а там как получится...
можно NEXT B,A или NEXT:NEXT
Второе, насколько помню, чуть быстрее
Да, к 2.5 и всем его модификациям это тоже относится
К сожалению нет, частота дискретизации недостаточная, бейсик слишком медленный.
Попробуем без подробного кода
Генерация
1. Делаем HIMEM, чтобы выделить место под картинку
2. Рисуем на экране картинку и делаем GET в область между HIMEM и экраном
3. Делаем BSAVE сохраненной через GET картинки
Использование
1. HIMEM
2. BLOAD
Это похоже больше в тему конкурса подходит.
Всё же Бейсик не ассемблер, а тем более если раньше программировали на нём, то это как на велосипеде один раз научился, а потом спустя время навык намного легче восстановить, чем если бы вообще не знали Бейсика.
Так что 2 месяца вполне себе нормально, а если больше растягивать, то бывает вдохновение теряется :)
Оригинальный способ !!
А как быть если много разных картинок - спрайты анимации например - это надо же расположение каждой в памяти знать, иначе как PUT догадается откуда выводить из какого массива ?
Или же уже при записи вся структура (массивы) должна быть определена и она записывается при запоминании в GET ?
Он несколько более оригинальный, чем хотелось бы, в 2.5 так не получится.
Надо самому распланировать распределение памяти. Для этого надо считать, сколько займет каждая картинка. Самый простой вариант - берем формулу из описания 2.5
INT(Х*У/8+3/4)+1 и умножаем на 4 - это будет число байт на картинку. На самом деле можно и чуть поменьше, но пусть лучше будет с запасом.
Вместе с графическими данными хранятся еще два параметра - ширина и высота картинки.
Прикинул достижимую частоту дискретизации при выводе по OUT1,PEEK(I)
в 2.5 - 160-190 Гц
в последних модификациях - 300-320 Гц
А для речи надо раз в 10-20-30 больше.
Почитал ("по быстрому варианту") тему про подключение мыши к Вектору и вот такой вопрос появился:
Можно ли как-то сделать чтобы например в эмуляторе включить опцию МЫШЬ и в Бейсике или в других программах мышь например имитировала движение Векторовских "курсорных клавиш" и например нажатия "Пробела" и "ВК" ?
Т.е. в эмуляторе мы двигаем мышь (обыкновенную :) не PS/2 не COM ) и при эмуляция выдаёт код как-будто в Векторе произошло нажатие клавиши вверх вниз влево вправо (а также можно на любые клавиши повесить движение по диагонали) Пробел (левая кнопка мыши) ВК (правая кнопка мыши).
Что это может дать ? Например я в эмуляторе (на ассемблере или в Бейсике) сделал редактор графический или музыкальный - и там основное управление повесил на стрелки и Пробел и ВК, чтобы с помощью мыши было удобно редактировать.
Насколько трудно прикрутить к эмулятору такую опцию ?
Нет, это будет ужасно.