(Я хоть и отвечаю на твое сообщение, но на самом деле это «реплика в сторону»).
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…
Мне сначала надо бы ознакомиться с упомянутыми тобой материалами (жел-но со всеми). Затем нужно получить побольше информации, я должен более расширенно понять, что тебя интересует. А то есть риск написать не то что тебе интересно.
Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
Лично мне было бы очень интересно почитать как ты думаешь о программировании на спектруме. Потому что стилей очень много, а вот задокументированных стилей осталось всего ничего: мне в голову приходят какие-то обрывочные комментарии Робуса, а так же некоторые статьи Flying — например, его заметка про Memory Management Library или, допустим, уникально компактные заметки Exploder.
Спасибо за поддержку! Исходники в процессе упихивания в 48к превратились в ужас :) так что пока они замаринованы. Честно новоря я не представляю что там может быть полезного, всё очень просто и в лоб
так это, смотрю в эмуле на счётчик тактов до/после call
график мой неточный, ломаной по нескольким точкам
поверх старых точных графиков топикстартера
и накинул щедро 500 тактов сверху на вход еще
по завершении должно получиться немного меньше
Так ответ на вопрос то не технику какую то эффективную даёт, а просто даёт ответ почему так перемешаны биты.
Это не даёт «эффективных техник», это просто ответ почему так.
И даже непрограммист на загрузке видеозаставки очередной игры видел эту нелинейность и потому конечно тоже без всякого совершенно ассемблера понимает о чём речь. И это реально оказался вопрос очень интересный людям. Более интересный, чем видеоначинка денди в которую все в детстве играли и так далее.
Надо понимать, что на этом нашем ресурсе большинство программирующих под ZX не ломает голову по поводу работы с этим в асме 20+ лет, т.к. вопрос давно изучен, разжёван в труху, эффективные техники широко известны. А на непрофильном ресурсе просто кто-то увидел более знакомое слово, и их интерес из области 'у меня тоже был такой компьютер'.
Выражение «Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество. К сожалению вот только ответы давать не все хотят/умеют/могут…»
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
Любопытный тред. Спасибо. Надо будет сходить на zx.pk.ru, давно там не был. Мне интересно, как ты измеряешь время/производительность/такты чтобы выстроить график. Научи?
Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество.
К сожалению вот только ответы давать не все хотят/умеют/могут…
Вопрос в самом деле хороший, но, глядя на обсуждение, хочется надеятся, что всё придет если даже и не к написанному коду или какому-то реально ощутимому проекту, то хотя бы к новому способу борьбы с клэшингом.
я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management) и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)
Посмотрел, нашел screen_inc.asm, посмотрел locate_pixel и другие вещи. Всё красиво, всё молодец. Могу тебе рассказать дальше, в чём беда подобных вещей. Потому что когда-то, очень-очень давно пришлось пройти по этим граблям. С подобного разумного, организованного (библиотечного) подхода, (типичного для PC/ассемблера x86) начинают многие. Эта «разумность» и «организованность» и подводит. К сожалению, подобный поход не работает на ZX Specrum в практическом плане, потому что оказывается слишком медленным. Тут парадигма программирования (приводящая к успеху) несколько иная. Могу рассказать, если есть интерес.
Я же подразумеваю иное. Мой разговор и мои мысли строятся вокруг исходного вопроса статьи — почему в Sinclair сложилась именно такая архитектуру железа и экрана?
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.
Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.
Честно говоря, смотрю со стороны как вы общаетесь (не вполне доброжелательно) и сожалею. Потому что у вас (даже у нас) есть общий интерес. К линии, допустим. Но из-за стиля общения вы не можете его реализовать. Вот и выходит, что каждый сам по себе, а общей работы нет. Но команда это не просто сумма отдельных людей, это нечто иное. Поэтому, грустно, ребята, эх…
Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
Ты придумал табличку? молодец. Я пока не придумал.
график мой неточный, ломаной по нескольким точкам
поверх старых точных графиков топикстартера
и накинул щедро 500 тактов сверху на вход еще
по завершении должно получиться немного меньше
Это не даёт «эффективных техник», это просто ответ почему так.
И даже непрограммист на загрузке видеозаставки очередной игры видел эту нелинейность и потому конечно тоже без всякого совершенно ассемблера понимает о чём речь. И это реально оказался вопрос очень интересный людям. Более интересный, чем видеоначинка денди в которую все в детстве играли и так далее.
несмотря на то, что по не зависящим от них причинам меньше «могли»
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
К сожалению вот только ответы давать не все хотят/умеют/могут…
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.
Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.