128 basic

[vlad-kras]

Самый простой пример - использование RST #10 при выводе знакоместа для динамической графики. Или процедур калькулятора Бейсика для обсчета 3d. Или процедур ПЗУ для рисования динамического 3d - а ведь они написаны на ассемблере.

Но как-то (сносно) это работает, играть можно, даже если используются неоптимальные процедуры из ПЗУ? Или прямо каждая игра по скорости отрисовка - как "борщ" на 3.5 МГц ?

Побитный скроллер на Спектруме это почти всегда тормоза, если это не бегущая строка, а более-менее значительная часть экрана.

Уперлись в ограничения аппаратной платформы? Логично, что 3.5 МГц значительно медленнее, чем 28. Но ведь куча игр вполне динамичны. А если не использовать более-менее значительную часть экрана, а использовать какое-то не очень большой число спрайтов, все же тогда по скорости нормализуется?

Да и познакоместный на весь экран может быть тормозным - можете оценить в игре Quazatron, например.

А можно ли там быстрей сделать?

Графическая заливка на Спектруме - тормоза.
3d на Спектруме это тоже почти гарантированные тормоза, особенно с заливкой, пример - Total Eclipse и Elite, когда на экране одновременно несколько объектов.

Трехмерки с заливкой. Тут опять же уперлись в ограничение по скорости - ничего удивительного. Про трехмерки с каркасными моделями не помню, там может получше.

Любой, кто писал на ассемблере что-то более-менее сложное, знает, что вера в бесконечность быстроты ассемблера очень быстро разрушается.

А вот с этим утверждением согласен полностью. Ассемблер быстрый, но не бесконечно быстрый. Только этого утверждения в начальном варианте я не увидел, а увидел другое - бейсик тормозной и ассемблер тоже тормозной.

[Advertiser]

[Spectramine]

Между

бейсик тормозной и ассемблер тоже тормозной.

и

Да и написать тормозной код вполне можно и на ассемблере, зависит от задачи и навыков программиста.

все же, мне кажется, есть разница.

Но как-то (сносно) это работает, играть можно, даже если используются неоптимальные процедуры из ПЗУ? Или прямо каждая игра по скорости отрисовка - как "борщ" на 3.5 МГц ?

Нет, сносно это не работает. Это может быть использовано только для вывода текста, когда спешить некуда, примитивных игр типа Питон с минимумом перестроения экрана, и построения статических изображений в текстовых играх.

Уперлись в ограничения аппаратной платформы? Логично, что 3.5 МГц значительно медленнее, чем 28. Но ведь куча игр вполне динамичны. А если не использовать более-менее значительную часть экрана, а использовать какое-то не очень большой число спрайтов, все же тогда по скорости нормализуется?

Всегда можно что-то оптимизировать, я привел примеры тормозного кода на ассемблере, когда решение задачи в лоб приводит к тормозам.

А можно ли там быстрей сделать?

Скорее всего да. Это тоже был пример тормозного кода на ассемблере.

[CPLx]

Всегда можно что-то оптимизировать, я привел примеры тормозного кода на ассемблере, когда решение задачи в лоб приводит к тормозам.

Я не думаю что печать символов там решена влоб, иначе работала бы быстрее. Обычно когда я вижу жуткие тормоза, то именно потому что задача решена не влоб, а с помощью какой-то сложной "программной инженерии", "современных паттернов проектирования", "последних технологий из computer science" и тому подобного. Потом я делаю решение влоб, оно работает в разы быстрее, а я сижу ломаю голову как можно было сделать так медленно. Это не только Спектрума касается, я это постоянно на PC вижу.
Чтобы ассемблер тормозил это надо либо использовать неэффективный алгоритм (и тогда это вообще не проблема языка - на бейсике будет еще медленнее), либо маяться дурью со всякими паттернами и прочим бредом.

[Spectramine]

Это не только Спектрума касается, я это постоянно на PC вижу.

Скорее, это только PC и касается. Решение в лоб может быть эффективным, а может быть неэффективным. Но если оно неэффективно, приходится его оптимизировать.

сложной "программной инженерии", "современных паттернов проектирования", "последних технологий из computer science" и тому подобного

Любой инструмент имеет свою сферу применения. Современные паттерны проектирования и технологии призваны, в первую очередь, помогать справляться с возрастающей сложностью проектов. Сложные задачи в лоб вообще не решаются.

Я не думаю что печать символов там решена влоб, иначе работала бы быстрее.

Не знаю, о чем именно вы здесь, если о коде RST #10 ПЗУ Спектрума, то там код слишком универсален, использует абстракции каналов и потоков, и естественно в связи с этим намного медленнее специализированного и оптимизированного кода вывода знакоместа на экран в играх.

Чтобы ассемблер тормозил это надо либо использовать неэффективный алгоритм (и тогда это вообще не проблема языка - на бейсике будет еще медленнее), либо маяться дурью со всякими паттернами и прочим бредом.

Чтобы ассемблер тормозил, достаточно взяться за задачу, решение которой будет упираться в ограничения железа. Либо использовать неэффективный для выбранной задачи алгоритм, либо неэффективные наработки, либо неэффективные для данной задачи высокоуровневые абстракции. И конечно же это вообще не проблема языка ассемблера, который в принципе теоретически может дать максимально эффективные для данного железа программы, это проблема квалификации программиста либо сложности решаемой задачи. Проблемы языка ассемблера другие - низкая скорость и высокая трудоемкость разработки, низкий уровень абстракций, слабая читабельность программ, непереносимость или плохая переносимость кода на другие платформы.

- - - Добавлено - - -

ну это примерно как сказать: "печать символа в координатах это для более высокого уровня программирования, а для начального вхождения рисование каждой буковки попиксельно по физическим экранным адресам идеально"

Нет, это совсем другое. Любой изучение нового предмета делается от простого к сложному, если сразу взяться за сложное, можно просто не осилить порог вхождения, посчитать, что это не для меня и т.п. Вот Бейсик с его пронумерованными операторами - это просто, ему можно сопоставить простейшие бытовые алгоритмы с пронумерованными действиями. А структуризация и т.п. - это сложно, это уже когда ты разобрался с базовыми понятиями и начинаешь понимать, что их недостаточно. Даже Бейсик никто не начинает изучать с процедур, массивов и циклов, начинают с простых операторов, литералов и переменных.

- - - Добавлено - - -

ну это примерно как сказать: "печать символа в координатах это для более высокого уровня программирования, а для начального вхождения рисование каждой буковки попиксельно по физическим экранным адресам идеально"

Это скорее примерно как сказать "печать символа в координатах это для более высокого уровня программирования, а для начального идеально простая печать символа в текущей позиции вывода".

[CPLx]

Да, в бейсике были удобства в том плане что если надо написать какой-то простой расчет по-быстрому, то это легко там можно было сделать. Вот именно что как калькулятор его использовать и можно было. Ну и более сложные расчеты наверное можно было делать, всё-таки бейсик произошел от фортрана. Большие программы на бейсике были, но это была редкость. В основном же, для подавляющего большинства программ, бейсик использовался только как загрузчик кодового файла. Какую программу или игру не возьми - на бейсике только загрузчик. Я вообще сейчас подумал что сама идея туда втулить интерпретатор бейсика была убыточной - куча денег на разработку этого интерпретатора, а по итогу он почти никем не использовался. А потом еще решили бейсик-128 добавить. Еще одно на мой взгляд совершенно неоправданное вложение. Может они думали что бейсиком мало кто пользуется из-за токенизированного ввода и решили исправить "ошибку"? Спектрум можно было сделать еще дешевле без этого бейсика.

С другой стороны, наличие фактически встроенной IDE сразу делало тебя программистом. Ну или как минимум если не заставляло им стать, то максимально помогало и подталкивало. Наверное поэтому именно Спектрум и породил много программистов.

[Spectramine]

Фирменным софтом Бейсик мало использовался, но для основной задачи, под которую Синклер ориентировал свою линейку ZX - обучения программированию, он очень даже использовался. Бейсик очень хорошо помогал преодолеть порог вхождения в программирование. Понятно, что с развитием игрового софта многие стали использовать Спектрум чисто как игровую приставку, но всё же многие вошли в IT именно через Бейсик Спектрума. И ассемблер изучать на базе Бейсика намного проще. Бейсик в Спектруме - это не только язык программирования, а ещё и операционная система - интерактивная и дружественная к пользователю, с понятными командами на близком к естественному языке и содержательными сообщениями об ошибках.

Думаю, стартовый толчок для Спектрума в плане продаж дал именно встроенный Бейсик - когда игрового софта ещё почти не было, люди уже интересовались программированием и хотели приобрести компьютер для его изучения, разогретые предыдущими компьютерами Синклера. Это потом уже, когда появилась база пользователей Спектрума, игрописатели стали массово выпускать качественный игровой софт для него, и Спектрум многие стали покупать только ради игр.

- - - Добавлено - - -

с дичайшими погрешностями.

Видимо, для тех задач, которые решали люди на Спектруме, погрешности были приемлимыми. 2 десятимиллиардных это не так много)

[Lethargeek]

Фирменным софтом Бейсик мало использовался, но для основной задачи, под которую Синклер ориентировал свою линейку ZX - обучения программированию, он очень даже использовался. Бейсик очень хорошо помогал преодолеть порог вхождения в программирование.

плохо помогал, какой-нибудь лого (даже спековский каличный) намного лучше

Думаю, стартовый толчок для Спектрума в плане продаж дал именно встроенный Бейсик - когда игрового софта ещё почти не было, люди уже интересовались программированием и хотели приобрести компьютер для его изучения, разогретые предыдущими компьютерами Синклера. Это потом уже, когда появилась база пользователей Спектрума, игрописатели стали массово выпускать качественный игровой софт для него, и Спектрум многие стали покупать только ради игр.

даже если так (хотя во время роста брали что угодно, лишь бы недорого), то потом он только мешал, и не только играм (одно только "гениальнейшее" решение поместить пзу с нижних адресов чего стоит)

[Spectramine]

плохо помогал, какой-нибудь лого (даже спековский каличный) намного лучше

А не факт. Лого это чет такое вообще детское с его черепашкой. Глобальная распространенность Бейсика и малоизвестность Лого говорят сами за себя. Интересно, есть ли вообще люди, которые вошли в программирование через Лого)

даже если так (хотя во время роста брали что угодно, лишь бы недорого), то потом он только мешал, и не только играм (одно только "гениальнейшее" решение поместить пзу с нижних адресов чего стоит)

Интересно, а куда же надо было пихать ПЗУ, с учетом того, что после сброса Z80 в PC нулевой адрес? Решение как решение. Впрочем, тебе и организация видеоОЗУ Спектрума не нравится, и вообще "всё плохо, я бы сделал лучше"

[jerri]

А не факт. Лого это чет такое вообще детское с его черепашкой. Глобальная распространенность Бейсика и малоизвестность Лого говорят сами за себя. Интересно, есть ли вообще люди, которые вошли в программирование через Лого)

Лого для маленьких. Определенные понятия дает. На этом всё.

Интересно, а куда же надо было пихать ПЗУ, с учетом того, что после сброса Z80 в PC нулевой адрес? Решение как решение. Впрочем, тебе и организация видеоОЗУ Спектрума не нравится, и вообще "всё плохо, я бы сделал лучше"

На c64 както справились.

[M80]

Интересно, а куда же надо было пихать ПЗУ, с учетом того, что после сброса Z80 в PC нулевой адрес?

Ну, это ли проблема. Для этого нужно минимум железа - масса вариантов.)