Мне сначала надо бы ознакомиться с упомянутыми тобой материалами (жел-но со всеми). Затем нужно получить побольше информации, я должен более расширенно понять, что тебя интересует. А то есть риск написать не то что тебе интересно.
Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
Выражение «Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество. К сожалению вот только ответы давать не все хотят/умеют/могут…»
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
Любопытный тред. Спасибо. Надо будет сходить на zx.pk.ru, давно там не был. Мне интересно, как ты измеряешь время/производительность/такты чтобы выстроить график. Научи?
Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество.
К сожалению вот только ответы давать не все хотят/умеют/могут…
Посмотрел, нашел 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.
> в том, что минимальный размер экрана не означает экономного расходования памяти
Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.
Мы, может, не поняли друг друга? Что именно названо «страданием»? Страдание при реализации или страдание от незнания окончательной правды? Похоже что в моем случае первое, а в твоем случае последнее, хотя дела обстоят, конечно, не столь трагично. Люди просто не знали этого 100% точно и всё.
Надо было сразу спрашивать у знающих людей. :) Спрашивать надо конечно же у разрабов железа, а не у программистов. Все свои непонятки я развеял сразу же, когда увидел книжку Chris Smith. Хотя раньше и так было понятно что биты контролера перепутаны не из-за софтварной блажи. Ранее я считал что тому виной:
1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA
Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.
Это не locate pixel, это locate byte, допустим для вывода спрайта.
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса
Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
ld h, htable ; 7
ld l, y ; 4
ld a, (hl) ; 7
inc h ; 4
ld h, (hl) ; 7
add a, x ; 4
ld l, a ; 4
37 тактов и 512 байт памяти
LD BC, port ; 10
out (c), reg ; 12
in l, (c) ; 12
inc b ; 4
out (c), reg ; 12
in h, (c) ; 12
62 такта, что к следующему порту можно перейти так.
или в случае 8-битых портов
ld a, reg ; 4
out (port), a ; 11
in a, (port) ; 11
ld l, a ; 4
ld a, reg ; 4
out (port), a ; 11
in a, (port) ; 11
ld h, a ; 4
60 тактов
Но дело в другом, такое не принято исходя из соображений здравого смысла. Проблемы вычислений адреса — это по-логике проблемы процессора, проблемы даже алгоритма, а не аппаратуры. Такого не было, даже на PC-шных EGA/CGA/VGA видекартах с их чумовейшими битпланами, на амигах/атарях, на консолях или на монструозных arcade game board.
Однако это не значит что данный подход плох или не работает. Работает, и такая идея и меня давно посещала также, и для вычисления адреса, и позже — для выполнения умножения/деления, либо для более генеральных вещей — для общения с «сопроцессором». Подобное весьма активно использовалось на NES/SNES, в дополнительных RISC-микропроцессорах стоящих на картридже игры, только работало не через OUT, а через запись в ячейки памяти и/или DMA.
down_hl, как раз, занимает всего лишь 4 такта при правильной готовке. И выполняется так с вероятностью 7/8, то есть 87.5%
Это не делает его удобнее или быстрее чем при постолбцовой раскладке где столбцы 256 байт, но ситуация не так уж и печальна. Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.
Иными словами, вычислять экранный адрес по двум координатам?
Это не имеет смысла, так как он и так быстро вычисляется по таблице 512 байт, если расположить её в памяти с адреса кратного 256:
ld h, htable ; 7
ld l, y ; 4
ld a, (hl) ; 7
inc h ; 4
ld h, (hl) ; 7
add a, x ; 4
ld l, a ; 4
Экранчик столбцами весьма интересен, согласен.
У экранчика столбцами есть одно интересное (и я уверен — мало кому известное) свойство. Дело в том, что tearing графики на нём наблюдается весьма интересно, потому что графика «рвётся» лучом не пополам как на построчном экране (что юзеру хорошо заметно глазом), а иначе. Сложно рассказать как, но плюс в том, что заметность «разрывов» или глюков при движении спрайтов гораздо меньше, эти дефекты иного уровня.
На «Специалисте» или «Орионе» прерываний нет вообще. То есть о синхронизации посредством halt/прерывания там никто никогда не знал. А между тем, игрушки выглядят и работают вполне нормально.
Был бы очень тебе благодарен, если бы ты указал мне способ где и как их найти. Я конечно пытался кое-что читать на zxpress, но там беда в том что всё раскидано по журналам и упорядочено по темам очень поверхностно, многое можно и пропустить… Есть и другие трудности.
А так, напишу запись в блог, хорошо, я понял.
надо понимать во многих смыслах — в том что надо учитывать и время (1981 год) и деньги, и то что думали, и учитывать также и то, что хорошо сейчас судить, из будущего. А тогда ничего не было известно, поэтому крутились как могли. То есть хороша предельная теория («хотели как лучше»), но практика и исторические обстоятельства диктуют своё («получилось как всегда».)
Удивлен что эта процедура линии до сих пор вызывает интерес. Эх, если бы знать, приложил бы больше старания. Да и вообще, тема занимает внимание людей, недавно на Facebook поднималась.
К сожалению, никакой оптимизации или чего-то там я не добивался. По одной простой причине — это был практически последний мой код (+- несколько дней) на ZX Spectrum… Далее я ничего серьезного не писал.
К сожалению вот только ответы давать не все хотят/умеют/могут…
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.
Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.
Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips
1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA
Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.
Lord Vader Металлолом — о строении экрана 6912 с аппаратной точки зрения.
Так что в нынешнее время нужно тщательнее искать, тщательнее!
Всё уже сделано до нас.
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса
Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
Пчму? Пример сотен байтов-килобайтов?
> при ошибочном целеполагании
Объясни, о чем ты, в чем ошибочность, итд
37 тактов и 512 байт памяти
62 такта, что к следующему порту можно перейти так.
или в случае 8-битых портов
60 тактов
Но дело в другом, такое не принято исходя из соображений здравого смысла. Проблемы вычислений адреса — это по-логике проблемы процессора, проблемы даже алгоритма, а не аппаратуры. Такого не было, даже на PC-шных EGA/CGA/VGA видекартах с их чумовейшими битпланами, на амигах/атарях, на консолях или на монструозных arcade game board.
Однако это не значит что данный подход плох или не работает. Работает, и такая идея и меня давно посещала также, и для вычисления адреса, и позже — для выполнения умножения/деления, либо для более генеральных вещей — для общения с «сопроцессором». Подобное весьма активно использовалось на NES/SNES, в дополнительных RISC-микропроцессорах стоящих на картридже игры, только работало не через OUT, а через запись в ячейки памяти и/или DMA.
Это не делает его удобнее или быстрее чем при постолбцовой раскладке где столбцы 256 байт, но ситуация не так уж и печальна. Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.
Это не имеет смысла, так как он и так быстро вычисляется по таблице 512 байт, если расположить её в памяти с адреса кратного 256:
У экранчика столбцами есть одно интересное (и я уверен — мало кому известное) свойство. Дело в том, что tearing графики на нём наблюдается весьма интересно, потому что графика «рвётся» лучом не пополам как на построчном экране (что юзеру хорошо заметно глазом), а иначе. Сложно рассказать как, но плюс в том, что заметность «разрывов» или глюков при движении спрайтов гораздо меньше, эти дефекты иного уровня.
На «Специалисте» или «Орионе» прерываний нет вообще. То есть о синхронизации посредством halt/прерывания там никто никогда не знал. А между тем, игрушки выглядят и работают вполне нормально.