Comments 85
256x176
256x192
не существует вызовов функций, только
GO TOиGO SUB;
А DEF FN как же?
Кажется, в BASIC 2 строки внизу экрана были зарезервированы, поэтому доступная высота сокращалась до 176.
А DEF FN как же?
А никак. Это собственные расширения некоторых бейсиков. В DOS Microsoft'овском было "DECLARE SUB"/"DECLARE FUNCTION".
Но в большинстве всё, на что вы могли рассчитывать это GOSUB/RETURN.
Это в ZX80, у Спектрума уже точно был DEF FN:
Эта реализация не предполагает управления потоком выполнения
Да, официально они statement-ы, однострочники в стиле Фортрана IV – но можно же было абьюзить, вызывая машинный код через USR.
Да проще тогда все на ассемблере делать
Но всё равно иногда был нужен интероп, это вот он и был. С USR удивительные штуки делали, шахматы вот в 1К. Типа на Бейсике )
https://archive.org/details/YourComputer_198302/page/n99/mode/2up?view=theater
Спасибо, дополню про графический режим
У меня одного отображается только одна (самая первая) иллюстрация?
Это был интересный проект на выходные. Совершенно бесполезный, но интересный!
Хабр торт. Действительно было очень интересно. Особенно впечатлило, что самый первый вариант с атрибутами столь простой по коду и отработал так быстро - вполне можно было дождаться на реальном компьютере, без эмуляторных ускорений в тысячи раз.
Хабр торт.
@PatientZeroделает очень хорошую работу по отыскиванию и переводу интересных статей, спасибо ему! Но хабр был бы тортом, если бы такие статьи появлялись сперва на хабре, не были бы вторичными :(
Э, я тоже стараюсь интересные проекты делать((
Вот сейчас с @dlinyj скооперируюсь и запилю материал об аппаратном моддинге x86 машин с самопальными картами расширений
А я разве обратное говорил? Мой плюс в вашу карму проставлен давно :)
Но это не значит, что оригинального качественного контента на хабре много. И конкретно с переводами мне лично не очень понятно, насколько посетителям хабра нужен перевод, обычно айтишники английским владеют и ссылки хватает. А вот отсутствие автора в комментариях - это очень серьёзный минус.
На самом деле, сегодня качественного контента сильно больше, куча прям топовых статей. Но и объёма материала стала больше, и в этом информационном шуме просто не видно "тех статей".
Ну и потом, сейчас сложнее удивить, чем 10 лет назад. Я обратил внимание, что то что бы взлетело в космос 10 лет назад, сейчас воспринимается с прохладцей
Вот сейчас с @dlinyj скооперируюсь
Эт вряд ли.
Спасибо за статью ! А вы не знаете случайно ? Несколько лет назад, я натыкался на новость, что какой то есть официаьный порт zx-spectuma, что бы запускать виртуально на компьютере.
Есть ли какой то официальный эмулятор ?
Тут, конечно, надо ассемблер использовать. Машина слабая, Бейсик не вывозит.
Кросскомпилятор Basic для Спектрума вроде сущевствует?
Есть несколько вариантов таких компиляторов, но они не любой код могут переварить (например, вычисляемое GOTO) и не так уж ускоряют работу: в лучшем случае раз в 10, а то, что само по себе медленно - графические функции, вывод на экран и вычисление всякой тригонометрии - и вовсе не ускоряет.
Честно говоря не могу понять проблему с вычисляемым ON GOTO (GOSUB)
на псевдоассемблере On GOTO
в регистре А вычисляемое значение выбора в ON GOTO
загрузить в HL адрес таблицы переходов
загрузить в ВС номер максимального перехода
сравнить А и С между собой
перейти к оператору следующему за on goto если А больше С
;иначе
сдвинуть С влево на один разряд дополнив младший разряд нулем (*2)
сложить HL и BC ; получаем адрес в таблице переходов
перейти по адресу на который указывает HL
Следующий оператор за ON GOTOК сожалению я подзабыл ассемблер Z80 и не могу привести прямой код на нем. :(
да всего делов то - табличку составить. только такой код состоит из портянки всяких процедур, табличку может быть хлопотно составить, или еще что, а может и сроки давили это все отлаживать. взяли и забили :)
Про забИли или забЫли, это точно подмечено.;)
Иногда второе порождает первое, а иногда первое порождает второе, а в общем они впадают в рекурсию %)) Вот такой круговорот уробороса в программировании.
А так, это дело компилятора, составить таблицы переходов, отводить память под переменные и массивы, заниматься выделением и освобождением памяти, вести портянки списков процедур, оптимизировать код и делать прочую скучную мутотень. ;)
Был вроде бы, я даже пользовался в свое время, но там тоже ньюансы были. Для Спекки, насколько я помню, лучший вариант был, когда нужно было добиться максимальной производительности - это ассемблер.
В принципе еще возможен гибридный вариант - самые проблемные части написать на асме, и вызывать их из Бейсика. Тогда некоторые игры так были написаны, хотя, чаще всего, конечно, Бейсик для игр использовался только в качестве загрузчика и для запуска бинарного кода.
Само собой, что ассемблер это максимально достижимая производительность. Но и требование к программеру на порядки больше.
Да, но в принципе не страшно, ассемблер у Z80 простой сравнительно, освоить можно, как по мне даже интересно. Сейчас бы с удовольствием чем-либо таким позанимался, вместо обычного крудошлепства, да жаль за это денег не платят, или платят но очень мало, а в качестве хобби - пока не до того..
Так естественно что ассемблер простой, проще него только хексы 8D, вот только в голове приходилось держать кучу нюансов. И мнемоники ассемблера в стиле Zilog мне больше нравились, были более логичными по сравнению с Intel
Но к сожалению, активно на ассемблере Zilog я писал в начале 90-х, так что если что то начать писать заново, то будет нужно садится обратно за парту. :) Все по забыл:(
Насколько помню обычно мы в BASIC нумеровали строки с шагом 10 на всякий случай: 10 20 30 40 ...
И у многих реализаций BASIC была команда перенумерации всего кода с заданным шагом.
Были диалекты и вовсе без нумерации, но это уже позднее, не на Спектруме.
Я на Спекки даже на Паскале писал, правда это было развлечение не для слабонервных, надо было сначала компилятор со встроенным редактором, с кассеты загрузить, потом программу вбить, причем редактор строчный был. Потом скомпилить и запустить, помню там еще сложности какие-то были с тем, что компилятор не на все 100% поддерживал ЯП, и памяти мало оставалось, но тем не менее..
Эот на случай, если что-то надо добавить, то можно было вставить строку между
переносит поток управления к подпроцедуре (subroutine)
к подпрограмме
и 48 КБ ОЗУ
На самом деле фактически всего 41 Кб ;)
Вроде половина из 48К была ПЗУ+Экран, так что под код оставалось всего 24К
Из 64K было 16К ПЗУ, 6912 байт видеопамять
То есть было 48 КБ ОЗУ, содержимое 6912 байт из которых отображалось на экран, их тоже можно было использовать под код и данные, но на практике так, наверное, делали только копировщики, которым надо было за 1 проход утрамбовать в память игру вместе с заставкой
Ещё часть ОЗУ использовалась под стек
какая вторая половина?
Имеется ввиду что всего 64 кбайта памяти, из которой 16 - пзу. То есть 48 кб - это доступная память, часть которой - (6912) экран, и в конце стек, который рос вниз, поэтому если сделаешь бесконечную рекурсию, она затрет твой выполняемый код
так как все пространство памяти было одной страницей с прямым доступом, то экранная память - тоже часть ОЗУ.
Некоторые программы в экранной памяти и сидели и выполнялись (например copycopy)
ОЗУ в 48КБ Спектруме состоит из двух страниц по 16 килобайт, находящихся в физически разных чипах ОЗУ - два набора по 8 однобитных чипов DRAM. В младшей странице, где экран, процессор тормозится во время работы видеоконтроллера, в старшей - не тормозится. В ранних отечественных клонах эта особенность повторена, в последующих, где 8 микросхем ОЗУ по 64 килобита каждая, её упразднили.
Как они лежат физически - это другой вопрос, а софтварно 64 кбайта аресуются напрямую двумя байтами без каких-либо дополнительных переключений, и в первые 16 кбайт при старте туда копируется из пзу встроенный бейсик и вспомогательные данные, типа шрифт (в классическом спектруме). Эти 16 кбайт недоступны для записи, поэтому их образно тоже называют ПЗУ.
Остальные 48 кбайт доступны для записи, но следующие после первых 16 - это экранная память, затем небольшая область переменных самого бейсика (для программ исполняемых в машинном коде эту область можно свободно использровать). Стек - в конце памяти.
Ну нет, никуда ничего не копируется (да и чем бы оно копировалось?). ПЗУ просто находится в младших 16К адресов. ОЗУ у оригинального Спектрума в базовой конфигурации ровно 16К, у 'расширенной' (по тем временам) 48К - плюс ещё 32К (то самое второе поле, без торможения), которые в базовой просто не установлены на плату. Переменные Бейсика и положение стека - это личное дело Бейсика, если работать в машкоде, стек можно располагать где нравится. И из самого Бейсика стек тоже можно подвинуть оператором CLEAR. Собственно, на 16K модели он и будет при сбросе в результате тестирования памяти стартовым кодом в ПЗУ расположен не в конце адресного пространства, а в середине, где кончается физическая память.
Все-таки графический режим Спекки - 256х192. А если писать на асме и немного извратиться, используя бордюр, то можно расшириться до 320х240. Рекомендую поискать в сети и посмотреть демки 64к. Там ребята вытворяли невероятное.
Это как же немного надо извратиться, чтобы получить 320x240 на обычном ZX?
Немного.
https://www.youtube.com/watch?v=dl3wWxJmIZw&t=191s
Только там не 320x240, а 352x288(?) Не припомню.
Ну и пиксели на бордюре 2x1, потому как 1 такт z80 это два пикселя.
Произвольное изображение на бордюре вывести нельзя, минимальная ширина блоков в бордюрных эффектах 22-24 пикселей растра (out a минимум 11 тактов, практичный out c 12 тактов). В Rage сконструирован такой эффект, чтобы сменить цвет только в нескольких точно заданных местах за строку, смещённых от начала строки выравниванием по единичным тактам, но это работает только на Пентагоне. На оригинальных моделях эффект не повторить, там цвет бордюра меняется только раз в 4 такта.
на моем оригинальной спектруме (48), я видел буквы на бордере в какой-то игре
Произвольное изображение на бордюре вывести нельзя
Я не заявлял о возможности вывода произвольного изображения на бордюр.
А демка делает то, что нужно для достижения нужного эффекта, минимальными средствами.
но это работает только на Пентагоне
Правильно, Rage был сделан под Пентагон.
Я один из кодеров этой демки.
На оригинальных моделях эффект не повторить
Оригинальный спектрум это так себе демомашина - с медленным ОЗУ, снегом на экране и убогим бордером.
Из позвежее https://www.youtube.com/watch?v=b-kkzl2foaQ
Только там не 320x240, а 352x288(?) Не припомню.
Полный размер экрана "гуляет" в зависимости от клона.
я уже только после того как ушел со спектрума на x86, увидел что оказывается компьютеры одного бренда могут быть разными по производительности и возможностям. И задумывался как же программистам нужно писать софт, чтобы он работал нормально, учитывая все варианты
как как.. написали Android меньше 9го и windows меньше 10 не поддерживается - сократили, так сказать варианты
не, я имел ввиду что были моменты, когда программисты не привязывались к внутреннему таймеру, видимо либо не знали, либо привыкли к "стабильности" производительности, в результате на разных x86 машинах игры могли то бегать как сумасшедшие, то медленно ползать. А иногда выключение "турбо" позволяло пройти сложные места.
Или этот прикол, когда текстовый режим в Поиске работал ужасно медленно по сравнению с другими аналогами, а в графическом нормально.
Эх, ностальгия... Временя когда компьютеры были маленькими, а дискеты большими! ;)
Эх, молодёшь... А я вот помню время, когда компьютеры были большими!
;) Перфокарты и перфолента наше всё! А такие "большие машины" я видел в рабочем состоянии лишь пару раз в жизни. А потом только в виде металлолома :(
Дольше всех за жизнь держалась АЦПУ, для неё(него) даже сопряжение с писюком сделали и она(оно) печатало, печатало и печатало пока на складе была перфорированая бумага. :))
Дискеты? Да вы мажор! Только кассеты, только хардкор!
вопрос по времени выполнения - вы крутили код на реальном железе? а для чего? я понимаю что в самом конце можно так сделать, но разработку проще делать на эмуляторе, например там можно убрать лок по частоте Z80 и выполнить даже Бейсик раз в 1000 быстрее.
Производительность Спектрумовских Бейсик-программ можно увеличить минифицировав количество строк в многократно используемых участках. Строки заново интерпретируются при каждом обращении
То есть код по возможности пишем не так:
10 [Оператор]
20 [Оператор]
30 [Оператор]
А так:
10 [Оператор]:[Оператор]:[Оператор]
Такой код будет заметно быстрее:
10 [Оператор]:[Оператор]:[Оператор]:GO TO 10
Чем
10 [Оператор]
20 [Оператор]
30 [Оператор]
40 GO TO 10
А за счёт чего тут ускорение? Я бы в своей наивности предположил, что Бейсик просто смотрит на текущий код команды и переходит на подпрограмму выполнения, которая подтягивает аргументы. Затем возвращается и продолжает разбор строки дальше. Но это всё уже давно было, я могу ошибаться. Когда-то у меня была распечатка ПЗУ Спекки с коментариями.
Но как же адски при этом тормозит строчный редактор - до сих пор вспоминаю. Если набрать достаточно длинную строку, а потом попытаться отредактировать, курсор может сдвигаться раз в секунду, или даже медленнее.
в данном случае можно было бы расчеты переписать на ассемблере и вызывать из бейсика через usr
Благодарю за ностальгию, назад в прошлое более чем 30 лет!
Интересное возвращение в прошлое.
Но трассировку лучей делал уже на пентиуме, на спектруме делал отрисовку ребрами (совсем забыл термины, могу назвать неправильно).
Было мне доступно несколько книжек по графике в то время и сочетая в библиотеках книги по машинной графике и дома книжки по спектруму - рисовал монохромные картинки.
Это всё делалось до 1994 года, потом сначала смена страны, потом поступление в вуз.
До сих пор остался навык записывать интересные короткие заметки в тетрадь.
люто плюсую статью! Статья - огонь! На выходных достану клон Спекки, попробую вживую повторить ! :)
А зачем такая сложность с poke и вычисление адреса в памяти под атрибут цвета, вроде же для этого была графическая команда?
Я думаю, что это хобби можно развить на более интересном железе, но таким же простым способом. Я имею ввиду, Agon light™ или Color Maximite 2. Та же простота бейсика, но на порядки быстрее.
Для каждого из блоков 8x8 трассируем лучи в четырёх углах, и если цвет во всех углах одинаков, то закрашиваем блок целиком. В большинстве случаев это требует четырёх лучей на блок вместо 64, то есть ускоряет рендеринг в 16 раз.
Можно ускорить ещё в 4 раза (пустые участки), если три угла из четырёх брать из соседних блоков.
Пишем трассировщик лучей для ZX Spectrum