ZX_Multi_Card

[skyther]

всё остальное тянут драйвера

а это как понимать? http://zx.pk.ru/showpost.php?p=110529&postcount=20

[Advertiser]

[Black_Cat]

http://www.zx.pk.ru/showpost.php?p=106945&postcount=29
как понимаю, через драйвера с мультикартой можно работать либо как с ZX MC ртц, либо как с глюк ртц

[skyther]

Похоже о разных вещах говорим...

[Black_Cat]

остаётся подождать caro и выяснить что он имел ввиду - физические порты, или драйвера.. по крайней мере в первом посте никаких других портов, кроме ZX MC ртц не упоминается..

[caro]

Как я понимаю новая версия платы тянет часы по схеме глюка?

Да, для этого в дешифраторе добавлен порт xxF7h.

А можно схему посмотреть? В смысле чего-там-в-пал...

Схему и исходник прошивки PAL обязательно выложу.

Добавлено через 4 минуты

остаётся подождать caro и выяснить что он имел ввиду - физические порты, или драйвера.. по крайней мере в первом посте никаких других портов, кроме ZX MC ртц не упоминается..

В первом посте пока информация только о предыдущей версии ZXMC.
А драйверами при работе программ, оперирующих физическими портами GLUKа не обойтись.
Имеются ввиду физические порты GLUK RTC.

[Black_Cat]

Камиль, предлагаю, пока ты не начал собирать мультяхи, выкинуть из RTC порт #EFF7, бит D7 которого понадобится для введения доп. видеорежимов. Отсутствие этого порта в дешифрации никак не скажется на работе часов, ввиду полной избыточности этого порта в схеме управления часами. Как понимаю введение этого порта было исключительно обусловлено не очень высоким уровнем знаний разработчиков и схема может прекрасно работать и без него, а сам он нужен в других устройствах. Сделай пожалуйста прямую выборку #DFF7, #BFF7 без учёта D7 #EFF7. На программной и аппаратной совместимости это никак не отразится, ввиду того, что по портам #DFF7, #BFF7, никаких других устройств кроме RTC нет. Для тебя это ничего не будет стоить (даже сэкономишь на месте в ПАЛе или однокристалке), а для развития Спектрума это очень важно.

[caro]

предлагаю, пока ты не начал собирать мультяхи, выкинуть
из RTC порт #EFF7, бит D7 которого понадобится для введения доп. видеорежимов.
Отсутствие этого порта в дешифрации никак не скажется на работе часов,
ввиду полной избыточности этого порта в схеме управления часами.
Как понимаю введение этого порта было исключительно обусловлено не
очень высоким уровнем знаний разработчиков и схема может прекрасно
работать и без него, а сам он нужен в других устройствах.

Во-первых мне бит D7 порта #EFF7 нужен, поскольку его установка в 1
означает начало работы с часами, а сброс в 0 - конец работы.
Дело в том, что в ZXMC используется RTC с последовательным доступом,
и для того, что бы прочитать информацию из часов и записать ее назад,
нужно время.
Поэтому парралельно с работой RTC тикают программные часы, реализованные
на одном из таймеров Меги.
Обновление информации, при наличии часов, происходит именно по признаку
установки в 1 бита порта #EFF7.
Запись обратно в RTC - при сбросе этого бита (если перед этим он устанавливался).

Во-вторых, наличие этого порта в ZXMC мне кажется никак не скажется на
работе схемы переключения видео-режимов,поскольку ZXMC блокирует только
порты чтения, а порты записи остальных устройств Спектрума работают.
Мало того, копия состояния регистра #EFF7 будет хранится в ZXMC, и ее можно
всегда прочитать, определяя текущее состояние этого порта.

Сделай пожалуйста прямую выборку #DFF7, #BFF7 без учёта D7 #EFF7.

Использование ATF16V8 не позволяет этого сделать, ввиду ограниченного количества
линий ввода.
Дешифрация идет только по младшим адресным линиям.

[Black_Cat]

Во-вторых, наличие этого порта в ZXMC мне кажется никак не скажется на
работе схемы переключения видео-режимов,поскольку ZXMC блокирует только
порты чтения, а порты записи остальных устройств Спектрума работают.
Мало того, копия состояния регистра #EFF7 будет хранится в ZXMC, и ее можно
всегда прочитать, определяя текущее состояние этого порта.

а если в следующих версиях в #EFF7 вообще ничего относящегося к RTC писать не будут?

Дешифрация идет только по младшим адресным линиям.

это не важно, имелось ввиду исключить #EFF7 там где он дешифрируется

Во-первых мне бит D7 порта #EFF7 нужен, поскольку его установка в 1
означает начало работы с часами, а сброс в 0 - конец работы.

а как-то придумать по другому, без использования #EFF7?? Тебе не хватит времени между обращением к адресному порту и порту данных?

Запись обратно в RTC - при сбросе этого бита

имеешь ввиду запись состояния первых 14 ячеек RTC?

[caro]

а если в следующих версиях в #EFF7 вообще ничего относящегося к RTC писать не будут?

Это будет не правильно, поскольку уже применяется, придется это учитывать.

это не важно, имелось ввиду исключить #EFF7 там где он дешифрируется

К сожалению важно, поскольку именно выходной сигнал дешифратора
определяет диапазон блокируемых адресов.

[QUOTE=Black_Cat]а как-то придумать по другому, без использования #EFF7??/QUOTE]Конечно можно, сейчас сделано именно по тому алгоритму, который заложен.

имеешь ввиду запись состояния первых 14 ячеек RTC?

Не только регистры часов, но и всю зону ОЗУ RTC.
И при чтении и при записи.

[Black_Cat]

Это будет не правильно, поскольку уже применяется

нет, это используется только в глюке, и решается перепрошивкой ПЗУ

Не только регистры часов, но и всю зону ОЗУ RTC.
И при чтении и при записи.

256 ячеек?