Компьютер "ZXM-Zephyr" - Обсуждение

[Mick]

Еще о портах

Порт системный (цвет бордюра, бипер, магнитофон) xxFEh - на запись.
[7] - reserve
[6] - reserve
[5] - Border_Y
[4] - Tape_out
[3] - Beep
[2] - Border_G
[1] - Border_R
[0] - Border_B

где
Border_Y - дополнительный бит цвета бордера, иными словами бит интенсивности цвета. Активизируется только при установки бита Enable_BorderY порта EFFCh
Остальные биты порта штатные.


Порт управления режимами видео вывода информации EFFCh - на запись.
[7] - reserve
[6] - reserve
[5] - GScreen
[4] - reserve
[3] - reserve
[2] - Enable_BorderY
[1] - Enable_flash
[0] - Enable_MLT

где
Enable_MLT - бит управления режимом аппаратного мультиколора
При лог "0" режим выключен, при лог "1" режим включен.
Enable_flash - бит управления режимом мерцания. При лог "0" режим мерцания включен, при лог "1" мерцание выключено и вместо него подключается бит яркости.
Enable_BorderY - бит управления режимом расширенного цвета бордера.
При лог "0" режим выключен, т.е. бордер 8 цветный, при лог "1" режим включен и 16 цветов бордера.
GScreen - включение режима так сказать стеклореза мониторного или гигаскрина. Т.е. происходит аппаратное переключение экранов основного и дополнительного ("0" - режим выключен, "1" - режим включен)
При активном сбросе эти биты устанавливаются в лог "0", тоесть штатный Спектрум.

Кроме того стоит отметить, что бит 3 этого порта отвечает за включение или отключение палитры. В данном компьютере палитра так сказать не отключаемая, поэтому этот бит не используется, но опять же не занимаем его.
Стоит еще немного рассказать про организацию аппаратного мультиколора в данном компьютере. Когда режим включен, то строение экрана меняется. Информация о пикселях остается на своих местах 4000...57FFh, а вот область атрибутов меняется и становится 6000...77FFh. При этом атрибуты соответствуют как 2 цвета на 8 точек, в отличии от штатного где 2 цвета на 64 точки.
Это же относится и к дополнительному экрану в 7 странице ОЗУ.

Вот где то так.

[shurik-ua]

Стоит еще немного рассказать про организацию аппаратного мультиколора в данном компьютере. Когда режим включен, то строение экрана меняется. Информация о пикселях остается на своих местах 4000...57FFh, а вот область атрибутов меняется и становится 5800...6FFFh.

Насколько помню был какой-никакой стандарт подобного мультиколора, только там информация о цвете располагалась по адресам 6000 .. 77FF? опять же аппаратно это было сделать проще - зачем вводить ещё один стандарт?

[Дмитрий]

shurik-ua, был еще стандарт расширенного цветного режима у Профи, который больно похож по структуре на приведенный тут. Только у Профи еще по вертикали на 48 пикс увеличивается и по горизонтали в 2 раза
Но рулить таким экраном достаточно сложно на 3.5 МГц, на 7 куда ни шло, но все равно в сложно в Int уложиться.

[Mick]

Насколько помню был какой-никакой стандарт подобного мультиколора, только там информация о цвете располагалась по адресам 6000 .. 77FF? опять же аппаратно это было сделать проще - зачем вводить ещё один стандарт?

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

[Дмитрий]

как бы область линейная и не дырявая

Так если линейность присутствует, то может стоит и линейность строк поправить? Дабы избавиться от UP_HL, DOWN_HL подпрограмм?

[Mick]

Но рулить таким экраном достаточно сложно на 3.5 МГц, на 7 куда ни шло, но все равно в сложно в Int уложиться.

На сам копе чуваки 24кб экран окучивают на 6мгц и ничего, демки неплохие

---------- Post added at 13:59 ---------- Previous post was at 13:57 ----------

Так если линейность присутствует, то может стоит и линейность строк поправить? Дабы избавиться от UP_HL, DOWN_HL подпрограмм?

Под линейностью, я подразумевал что нет дырки в области с 5800 по 5FFF как у предыдущего оратора.
Но думаю, что не трудно будет изменить строение экрана на более линейное чем в спектруме, если в этом возникнет необходимость

[Advertiser]

[Дмитрий]

Mick, одно дело окучивать в демках, другое - смотреть как прорисовывается GUI в системках, где нет возможности развернуть цикл прорисовки из-за экономии места.

[shurik-ua]

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

Вот нашёл откуда инфа:

[Mick]

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

Вот с этого места по подробнее. Много ли написано под тот режим.
И чем так неудобен будет мой режим.

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

[shurik-ua]

Написано может и немного - но если режим есть, то есть ненулевая вероятность того что кто-то под него что-то напишет - иначе зачем этот режим вообще вводить )
Твой режим неудобен тем что теперь их(режимов) будет два вместо одного и к примеру гипотетический кодер, решивший написать прогу в этом режиме, вынужден будет учитывать что на некоторых компьютерах его картинка будет отображаться неверно и вынужден будет писать процедуры под оба режима - поэтому зачем на ровном месте создавать преграды и без того уже немногочисленным кодерам. )
И да дырка в адресном пространстве только к лучшему - там бейсик ещё иногда бывает, а где бейсик там и переменные tr-dos )