Просмотр полной версии : Вопрос по экранной области памяти
Здравствуйте! В последнее время увлекся изучением программирования для ZX Spectrum. Меня интересует вопрос, который возник в процессе прочтения книги издательства "ПИТЕР":
1) Почему размер файла-изображения, созданного в Art Studio, составляет 6912 байт?
2) Разрешение экрана 256*176 глубина цвета 3 бита (8 цветов). Итого вес матрицы должен составить 135 168 бит (16 896 байт). Я правильно думаю?
[bETA]mEN
19.09.2008, 00:25
2) Разрешение экрана 256*176 глубина цвета 3 бита (8 цветов). Итого вес матрицы должен составить 135 168 бит (16 896 байт). Я правильно думаю?
нет
http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes
Более чем понятно. Это изображение грузится в область символов, определяемых пользователем, емкостью 32*24*9 = 6912 байт. Буду разбираться дальше. Спасибо.
грузится в область символов, определяемых пользователем не, в экранную область. в то что называют "область символов, определяемых пользователем" атрибуты не загрузишь, и структура данных другая, и символов не хватит.
(256*192) / 8 бит = 6144 байт монохромной графики
(256*192) / 64 пиксела в блоке 8х8 = 768 байт цветовых данных
6144+768 = 6912 байт всего
boo_boo, Ясно. Адрес начала области UDG я смогу найти
(let a = usr chr$(0)), там можно разместить всего 49152 бит своих монохромных блоков 8х8.
А как найти адрес области памяти, куда можно записывать атрибуты каждого из блоков (3 бита цвет знака, 3 бита цвет фона, 1 бит повышенной яркости и 1 бит мерцания знакоместа)?
забудь про UDG
экран начинается с $4000 = 16384
атрибуты $5800 = 22528
poke 16384,128 - точка в левом-верхнем
poke 22528,0 - черный inc/paper в левом-верхнем
(let a = usr chr$(0)) ага, skyther дело говорит, забудь про UDG :)
UDG -- абстракция, существующая на уровне бейсиковских процедур печати, железо ни о каком UDG не знает, оно знает только о области памяти начинающейся с 16384 и длиной 6912 байт. сначала идут 6144 байт монохромных пикселов (причем нелинейно, увидишь, если сделаешь в цикле poke 16384+i, 255). потом 768 байт цвета познакоместно, линейно.
подробно см например в http://trd.speccy.cz/book/ZX_TRDOS.ZIP (архитектура ZX Spectrum -- организация памяти -- экранная область памяти)
skyther,
boo_boo, Большое вам спасибо!
Лучше почитай книгу "Как написать игру на Ассемблере" издательства Питер...
rasmer, Я начал читать предыдущую, ту что на бейсике. Думаете, что ее следует пропустить?
Я начал читать предыдущую, ту что на бейсике. Думаете, что ее следует пропустить?
Думаю, что да. Я, например, читал только вторую и получил достаточно информации об устройстве спектрума для того, чтобы начать программировать. Знания, полученные из первой книги, в большинстве своем, будут ограничены сверху возможностями самого языка. В первую очередь, по скорости
multimax
20.09.2008, 17:59
ipaSoft, не, читай всё. Полезное чтиво.
Максагор
20.09.2008, 23:37
Читай все. Книжка про Бейсик тоже очень полезная. Особенно если ты с нуля начал разбираться в Спектруме, этот язык тебе очень по нему поможет. Ну а потом, как следующая ступенька, можно и броситься в океан Ассемблера.
Кароч - самый лучший способ понять как устроен экран спека (не набивая никаких программулек), это посмотреть как с тапки загружается экран...
Evgeny Muchkin
23.09.2008, 09:23
ту что на бейсике. Думаете, что ее следует пропустить?
Определенно! Я читал именно вторую книгу, имхо, этого достаточно для понимания основных вещей, ну а потом уже личное творчество начинается ;)
Так же в качестве справочника иммет смысл пользоваться книгой ZX Spectrum для пользователей и программистов + TR-DOS. С двумя этими книжками практически море по колено ;)
Evgeny Muchkin, ну и не стоит забывать инфоркомовский трёхтомнег...
Это все очень интересно. Так же было бы занимательно написать квест на русском языке для Спекки. Постараюсь) Спасибо за советы.
С тапки ни разу не загружался. Я работаю с эмулятором. Хотя у меня есть 3 компьютера Daewoo CPC-300. Там стоит DiskBasic 1.0. Он очень похож на Турбо Бейсик для ПЦ. Микропроцессор Z80A и скромная документация по эксплуатации.
Я начинал чтение с "Как написать... на ассемблере". Было занимательно, понятно, почти все примеры заработали с пол-дебага.
А потом добыл первую книжку. После второй уже не так полезна, с нее хорошо начинать, но эффективности, как уже выше сказали Vitamin и Evgeny Muchkin , небогато. Вот разве, взять оттуда все игры и для практики перевести на асм, пользуясь вторым томом - это да. А потом еще все это улучшить крутой графикой и эффектами - ну, тогда вообще, много сэнков, потому что игры в первом томе, как ни странно ;) занимательные все до одной. Сразу видна школа!
Splinter
27.11.2008, 14:51
Самое интересное по ассемблеру я находил в электронных изданиях, таких как Depth, ZX Format например, SE, Demo or Die.
demon_zx
28.11.2008, 14:12
Черная Ворона и DejaVu
Интересно,а почему последовательность пикселов сделали нелинейно.Изза упрощения схемо техники чтоли или что то типа защиты ULA от копирования?
с точки зрения программирования скорее всего... просто такая последовательность очень удобна - особо если работать только с спрайтами кратными 8х8
Интересно,а почему последовательность пикселов сделали нелинейно.Изза упрощения схемо техники чтоли или что то типа защиты ULA от копирования?
Существует версия, что такая нелепая последовательность пикселов произошла из-за ошибки при проектировании или изготовлении микросхем ULA (БМК) на заводе компании Ferranti и спешки Синклера.
Микросхема ULA содержит в себе большую часть схемы Спектрума, а не только схему видео. Своеобразный "чипсет", едрен батон.
Было решено применять микросхему ULA Ferranti в целях снижения себестоимости компьютера. Такие микросхемы заказывались и изготавливались партиями в тысячи, а то и в десятки тысяч штук.
Вкратце:
В компании Ferranti мистер Синклер и Ко заказал партию микросхем, хотя сам компьютер и программное обеспечение ПЗУ Спектрума еще не было готово. Работа над доводкой схемы и программой ПЗУ велась параллельно с штамповкой ULA.
Было официально обьявлено, что выпуск ZX Spectrum начнется в апреле 1982 года, но, как выяснилось позже, что и к маю 1982 года Синклер не успевал создать законченный продукт. Выпуску мешали многочисленные несостыковки.
Например, несколько десятков тысяч выпущенных микросхем ULA Ferranti содержали в себе несколько ошибок. В их числе и перепутанный бит адресации экрана. Переделывать микросхемы было поздно - поджимали сроки, было решено править программное обеспечение в ПЗУ, благо оно все еще находилось в процессе разработки.
Вот и имеем мы такую кривую адресацию экрана. Не ясно, ругать Ferranti и Синклера с Компанией или хвалить за это...
Не ясно, ругать Ferranti и Синклера с Компанией или хвалить за это...
- после драки кулаками не машут
- победителей не судят
- итд
Splinter
29.11.2008, 09:56
Оченно познавательно.
И между тем при выводе символа очень удобно двигаться по его восьми байтам с INC H / DEC H . Или другой старший регистр. :)
Хотя, конечно, не менее очень неудобно двигаться из этого символа вверх и вниз. :(
Вот и имеем мы такую кривую адресацию экрана. Не ясно, ругать Ferranti и Синклера с Компанией или хвалить за это...
Ругать, конечно, уж нечего. Хвалить ли - именно за это - непонятно.
Ругать, конечно
Толку ругать то, что сделано то сделано, поздно уже жаловаться... (четверть века назад надо было жаловаться)
Второй экран в в MSX весьма похож на ZX: те же три трети. Только адресация линейная: в пределах трети - как в знакогенераторе: по 8 байт сверху вниз.
А я себе такую штуку придумал для удобства расчёта адреса:
H L
010SGPIX STRSTOLB
Регистровая пара HL. 010 Это в регистре H. Это просто код #40. Адрес начала экрана. SG - это номер сегмента. Их три. 00, 01 и 10. Есть ещё "виртуальный", четвёртый, но он не виден. Потом PIX. Это текущая пиксельная линия...
Регистр L: STR - строка. Приращение = 32. Или #20. Что удобнее... Ну и STOLB. Столбец. Номер напрямую.
Только к сожалению такая здоровская формула ну блин никому не понятно... Наверное объяснять не умею... Но если кто разберётся, то никаких проблем с адресацией не будет... Можно влёт называть ЛЮБОЙ адрес на экране... Честно! Бывалый синклерюга поймёт, остальные - пожалуйста! Учитесь! Только с BIN, HEX и DEC системами потрудитесь разобратся...
CityAceE
02.12.2008, 09:24
А я себе такую штуку придумал для удобства расчёта адреса:
:) Всё уже давно придумано до тебя :)
010 Это в регистре H. Это просто код #40.
Вообще-то это трактуется не просто как код #40, а как номер экрана :) Так как второй экран находится по адресу #C000.
Splinter
02.12.2008, 10:16
ИНФОРКОМ, Элементарная графика. 1993 год 8)
Добавлено через 1 минуту
тот же алгоритм расчета разжованый на 3 листа....
Ясен палец, придумано...
Но каждый вновь сам для себя велосипед изобретает (тратя на это время = свою жизнь). По кусочку от каждого = кто-то живёт вечно???
Короче тут Shadow Maker в соседней теме ругается, и как раз по этому поводу...
Не буду спорить...
Как хотите...
P.S. Я просто хотел максимумом что знаю сразу поделится...
А про второй экран я тож в курсе, спасибо...
Splinter
02.12.2008, 20:54
ну прям обиделся 8))))... мы тебе про то, что мож ты не знал ?....
mishutka
03.12.2008, 00:12
Существует версия, что такая нелепая последовательность пикселов произошла из-за ошибки при проектировании или изготовлении микросхем ULA (БМК) на заводе компании Ferranti и спешки Синклера.
Микросхема ULA содержит в себе большую часть схемы Спектрума, а не только схему видео. Своеобразный "чипсет", едрен батон.
Было решено применять микросхему ULA Ferranti в целях снижения себестоимости компьютера. Такие микросхемы заказывались и изготавливались партиями в тысячи, а то и в десятки тысяч штук.
Вкратце:
В компании Ferranti мистер Синклер и Ко заказал партию микросхем, хотя сам компьютер и программное обеспечение ПЗУ Спектрума еще не было готово. Работа над доводкой схемы и программой ПЗУ велась параллельно с штамповкой ULA.
Было официально обьявлено, что выпуск ZX Spectrum начнется в апреле 1982 года, но, как выяснилось позже, что и к маю 1982 года Синклер не успевал создать законченный продукт. Выпуску мешали многочисленные несостыковки.
Например, несколько десятков тысяч выпущенных микросхем ULA Ferranti содержали в себе несколько ошибок. В их числе и перепутанный бит адресации экрана. Переделывать микросхемы было поздно - поджимали сроки, было решено править программное обеспечение в ПЗУ, благо оно все еще находилось в процессе разработки.
Вот и имеем мы такую кривую адресацию экрана. Не ясно, ругать Ferranti и Синклера с Компанией или хвалить за это...
жесть какая. адресация явно тщательно продумана и четко состыкована и Викерсом и Альтвассером
Существует версия, что такая нелепая последовательность пикселов произошла из-за ошибки при проектировании или изготовлении микросхем ULA (БМК) на заводе компании Ferranti и спешки Синклера.
Например, несколько десятков тысяч выпущенных микросхем ULA Ferranti содержали в себе несколько ошибок. В их числе и перепутанный бит адресации экрана. Переделывать микросхемы было поздно - поджимали сроки, было решено править программное обеспечение в ПЗУ, благо оно все еще находилось в процессе разработки.
Вот и имеем мы такую кривую адресацию экрана. Не ясно, ругать Ferranti и Синклера с Компанией или хвалить за это...
Возможно такая версия кому-то в голову и пришла. Но видимо этот "кто-то" не сильно старался изучить имеющиеся факты. Дело в том, что имеющееся в настоящее время адресация экрана ZX Spectrum была запатентована. И патент оформлен на Ричарда Альтвассера. Согласитесь, было бы странно, если еще на этапе разработки и подготовки к выпуску (а Альтвассер покинул Sinclair Research Ltd. именно в этот период в начале 1982) ошибку запатентовали, а потом оформили "в железе".
Нелепо выглядит и предположение "о правке кода в ПЗУ" под эту "запатентованную ошибку". Чего править то, если о том как "оно будет" давно известно.
Код ПЗУ не доработали лишь потому, что не был готов в железе Interface 1. Именно под него оставалось зарезервированно место.
процедура трансляции координат байта в экранный адрес проста. Там просто берешь и передвигаешь биты (хорошо рассмотрев экран, это доступно).
Чтобы проц не напрягать, делаешь таблицу. А по смещению из нее читаешь адрес.
координаты байта:
D = Y
E = X
выход
HL = адрес
с адреса #5800 начинаются 768 байт цветовых атрибутов.
одни из самых часто используемых процедур переход к след байту вниз/вверх и вычисление адреса атрибутов по байту графики... вариантов море и быстрые и короткие и с табличками и без...
Всётаки если была линейная адрессация былоб гораздо лучше!
Что-то накидал по рисунку своему. Для расчета таблиц должно подойти:
-----
LD A,E
AND #1F
LD L,A
LD A,D
RLA
RLA
AND #E0
OR L
LD L,A
LD A,D
AND #7
LD H,A
LD A,D
AND #C0
RRA
RRA
RRA
OR H
OR #40
LD H,A
----
Надеюсь не ошибся :-)
Lethargeek
03.12.2008, 07:30
Всётаки если была линейная адрессация былоб гораздо лучше!
Линейная адресация в целом хуже. Лучше была бы только "столбцовая".
Идеальный вариант, имхо, 256 байт на строку. Окно вывода задается через внешний аппаратный регистр. Тут тебе и расчет простой и аппаратный скролл по горизонтали.
James DiGreze
03.12.2008, 07:57
Линейная адресация в целом хуже. Лучше была бы только "столбцовая".Скорее знакоместная. Хотя, ты считал, тебе видней.
Идеальный вариант, имхо, 256 байт на строку. Окно вывода задается через внешний аппаратный регистр. Тут тебе и расчет простой и аппаратный скролл по горизонтали.Для 82 года слишком наворочено.
Lethargeek, абсолютно согласен. Такая адресация была на "Специалист"е. Зато как красиво грузится некомпрессированная заставка с магнитофона. :-)
Lethargeek
03.12.2008, 21:52
Для 82 года слишком наворочено.
И слишком дорого, блин тогда еще на компы по 16К ставили
Такая адресация была на "Специалист"е.
На Векторе вроде тоже. Вот интересно, а буржуи додумались? Я не нашел таких забугорных компов.
Идеальный вариант, имхо, 256 байт на строку. Окно вывода задается через внешний аппаратный регистр. Тут тебе и расчет простой и аппаратный скролл по горизонтали.
имеешь в виду по знакоместам, столбиками по 8 байт? или линиями?, а атрибуты?
Lethargeek
04.12.2008, 08:04
имеешь в виду по знакоместам, столбиками по 8 байт?
Так на комоде - столбик на знакоместо, сами знакоместа линейно. Ни рыба, ни мясо.
А Vitamin видимо предлагает действительно идеальный :) вариант (байт на точку) по типу спринтера
вариант идеальный - но нужен в разы боле мощный процессор, чтобы успевать перестраивать экран. либо у нас 7К, либо тут только видимая область 256х192 будет 48К. Не говоря о том, что оригинальный спектрум 82го года выпуска и был 48м...
Идеальный вариант, имхо, 256 байт на строку. Окно вывода задается через внешний аппаратный регистр. Тут тебе и расчет простой и аппаратный скролл по горизонтали.
Ну, хотя бы линейная познакоместно, а байты все таки вертикальные 8 точек объединяют.
И, крмое других достоинств вертикальности - шрифт узкий на раз...
Когда ATMeg'у программировал по работе, один ЖКИ фирмы Bolymin раз удобно оказалось на бок положить... тогда я понял, какая адресация лучшая!..
Да, что гадать. Вывод на ZX расчитан как раз на знакоместную графику, со всеми своими пиксельными (INC/DEC H от байта к байту) и атрибутными (2 атрибута/знак) условностями. Знакоместо очень быстро выводится, а ходить из него куда-то тяжело.
Добавлено через 2 минуты
Lethargeek, абсолютно согласен. Такая адресация была на "Специалист"е. Зато как красиво грузится некомпрессированная заставка с магнитофона. :-)
+1.
James DiGreze
05.12.2008, 10:08
Вертикальный байт хорош для программиста, но чреват увеличением количества чтений из памяти формирователем видеосигнала в 8 раз, и примерно во столько же раз будет увеличено время торможения процессора, что крайне неблагоприятно скажется на общем быстродействии системы.
да, тогда и развертка должна быть соответствующая...
James DiGreze
07.12.2008, 07:31
да нет, как раз развертка может быть сохранена.
в текущем варианте схема работает как? читаем 1 байт в сдвиговый регистр и потом можем к памяти не возвращаться, т.к. сдвиговый регистр будет нам 8 пикселей рисовать. В случае разворота знакоместа получается, что для рисования этих же 8 пикселей нам нужно будет дёргать память 8 раз при инкременте адреса, хотя в обоих случаях частота пиксельклока будет одинаковая. Проблему можно решить физически выделив память в 256 байт для буфера пикселей, но даже при таком раскладе буфер надо сначала заполнить из основной памяти, правда только один раз для восьми строк на экране.
Я имел в виду - вертикальную постолюцовую развертку.
Но это нереально. Как и буфер (со своими, кстати, проблемами).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot