Простой вопрос про SMUC.

[Ewgeny7]

а так никаких конфликтов не будет?

Пока не замечал глюков

Кстати Глюк с RTC будет работать?

Работает, друг другу не мешают

[Black_Cat]

Работает, друг другу не мешают

Не, он поддерживает смуковские часы?

[Ewgeny7]

Ты под Глюком имеешь ввиду бут? СМУК ставится только на Скорпи, глюка-бут на нем не ставили. Соответственно, и поддержки RTC в глюке отсутствуют.

[Black_Cat]

СМУК ставится только на Скорпи, глюка-бут на нем не ставили

Я так понял со слов spensor'а, что Глюк умеет поддерживать СМУК..

[spensor]

а так никаких конфликтов не будет? ведь неспроста изначально точки входа сделали через TR-DOS?

Изначально сделали. Но во-первых, скорее всего чтобы сделать какую-никакую защиту от криворуких программеров, винт то поценнее дискеты будет, жалко потерять всю информацию; во-вторых, чтобы ввесли хоть какую-то культуру программирования (вызов как бы через системные прерывания). Возможно что еще от порчи винта в случае конфликта адресов портов. Но после открытия портов напрямую софт работает и сбоев замечено не было.

а как он будет себя вести если SMUC будет выбран всё время? И как правильней подклюсать?

Будет работать и напрямую, и в случае обращения через TRDOS. А как правильно, это вопрос филосовский, так же как и в случае ответа на вопрос "как жить". Программировать можно и так и так. С точки зрения стандартизации, работы на перспективу правильнее через точки входа, с точки зрения скорости - обращаться к портам напрямую.

тогда зачем делать постоянную выборку?

Постоянную выборку для быстроты - если пересылать массив данных, то для пересылки каждого байта прийдется юзать относительно длинную процедуру с пересылкой байт через точку входа, или же одну двухбайтную команду OUTI/OUTD или INI/IND. Скорость пересылки массивов данных меняется в разы.

Кстати Глюк с RTC будет работать?

Глюк будет работать с часами подключенными по схеме Глюка, часы подключенные по схеме SMUC прошивка Глюка не видит, разве что с коррекцией прошивки.

Я так понял со слов spensor'а, что Глюк умеет поддерживать СМУК...

Глюк и в частности TRDOS начиная с версии 5.13f никаким образом не связанны со SMUC. Я сказал что в этих прошивках, как и в прошивке TRDOS-Scorpion есть две точки входа, примерно такого вида OUT(C),A:RET и IN A,(С):RET. Задуманны они были для псевдопрямого программирования портов ВГ93. Эти же точки используются для программирования SMUC. Если вы подключите SMUC к любому другому клону отличному от Scorpion и у вас не будет при этом ПрофПЗУ, то программы типа CD-Walk, WDC смогут работать на таком клоне. Если же при этом SMUC будет реализован так, что обращение к его портам будет происходить только через TRDOS, то работа на клоне также будет возможна, но с оговоркой, что прошивка TRDOS содержит точки входа. Правда при отсутствии ПрофПЗУ не будет возможности загружаться с винчестера, и вообще вся работа будет возможна только через софт загружаемый через дисковод.

[Black_Cat]

С точки зрения стандартизации, работы на перспективу правильнее через точки входа

А какие критерии стандартизации? Совместимость с оригинальным SMUC? Как понимаю, теневой вход в SMUC сделан для устранения конфликтов ISA устройств с портами клавиатуры, ну и заодно для упрощения его подключения неквалифицированными юзерами к левым клонам с неизвестной дешифрацией. Т.е. фактически использование теневых портов - это результат криворукости разработчиков СМУКА, которые не смогли выбрать правильно порты чтоб небыло конфликтов. Полагаю, что если эту проблему устранить, то в теневых портах вообще не будет никакой необходимости. По нынешним временам, когда производится только один клон с шиной NemoBus (умеющей корректно разделять порты), а оригинальный SMUC давно не производится, то не проще-ли сразу решить все проблемы на этапе производства нового SMUC? Или тут есть какие проблемы о которых я не догадываюсь? Кстати и в регистре версии это можно отразить, например чётная версия - с постоянной выборкой, нечётная - через TR-DOS..

[spensor]

А какие критерии стандартизации? Совместимость с оригинальным SMUC?

Нет, совместимость в более широком смысле. Допустим если бы работа с TRDOS производилась бы только через 3D13, то проблем бы с совместимостью и работом софта из под винчестера/флэш-карт было бы гораздо меньше - работа ведеться через системные вызовы и до железной реализации накопителя программисту дела нет. Также и в этом случае - если надо можно изменить железо SMUC (перевести работу допустим с ATA протокола на USB), то по точкам вызова ставятся программные перехватчики, а дальше выполняется эмуляция старого железа на новом.

Т.е. фактически использование теневых портов - это результат криворукости разработчиков СМУКА, которые не смогли выбрать правильно порты чтоб небыло конфликтов.

На спектруме, не использую полную дешифрацию, любые порты будут неправильные, а разработчики которые не заведут на устройство все 16 адресных линий - криворукими. Один порт бордюра на спектруме имеет 32767 зеркал...
Выбор портов только из режима TRDOS это простой, хоть и ущербный, способ обойти эту проблему.

По нынешним временам, когда производится только один клон с шиной NemoBus (умеющей корректно разделять порты)

Угу, только ты сам противоречишь себе - если умеет корректно разделять порты, то не должно быть проблем с железом и портами. А если есть проблемы (случай с подключением GS к P1024SL), то значит компьютер не умеет корректно разделять порты. Да и не сможет. NemoBUS (ZXBUS) c использованием IORGE лишь частично решает проблему неполной дешифрации, не может быть решения в задаче, если не все исходные данные (полный физический адрес порта) известны.

Кстати и в регистре версии это можно отразить, например чётная версия - с постоянной выборкой, нечётная - через TR-DOS..

Изврат

[Black_Cat]

Также и в этом случае - если надо можно изменить железо SMUC (перевести работу допустим с ATA протокола на USB), то по точкам вызова ставятся программные перехватчики, а дальше выполняется эмуляция старого железа на новом.

А в реале как? Все программы используют системные вызовы при работе со СМУКом?

На спектруме, не использую полную дешифрацию, любые порты будут неправильные, а разработчики которые не заведут на устройство все 16 адресных линий - криворукими.

Я не вижу особых проблем найти нужный безконфликтный диапазон портов не прибегая к теневому режиму и чётным портам.

А если есть проблемы (случай с подключением GS к P1024SL)

GS юзает только 2 порта и с разделением там проблем нет, там проблемы со схемотехникой - т.е. опять же дело в недостаточной проработанности разрабатываемого железа, но т.к. это всё любительские разработки, то ожидать другого не приходится. Ошибки будут выявляться и устраняться, но должно пройти некоторое время активной эксплуатации устройства чтоб их выявить.

[Black_Cat]

И ещё вопросы по СМУКу:

1) какие существуют программы (в т.ч. и те что в ПЗУ), которые знают и используют SMUC RTC, SMUC 8259?
2) SMUC RTC, SMUC 8259 по умолчанию инициализируются при старте, или они должны инициализироваться отдельным софтом, этот софт есть?

Вопросы и замечания к составителям доки "SMUC на дискретных компонентах v0.0b" (к сожалению не знаю кто это):

1) замечание: несоответствие обозначений с оригиналом - вместо CS0,CS1 должно быть соответственно CS1Fx,CS3Fx;
2) с RTC выходит /INT0.. и никуда не приходит;
3) по записи D3=1 #FFBA как понимаю должно блокироваться прохождение сигнала INT59, те.фактически обработанных сигналов IRQ0(RTC), IRQ1(IDE). Это на схеме никак не отражено, как понимаю в этой упрощённой схеме SMUC по записи D3=1 #FFBA должно блокироваться прохождение /INT0??
4) замечание по придуманной аббревиатуре "SMUC" - Spectrum Multi Unit Controller - аббревиатура явно притянута за уши и очень неудобна, т.к. постоянно требует уточнения о каком SMUC речь. Было-бы проще идентифицировать эту разновидность как ZXSMuC - ZX Spectrum Multi Controller.
5) не указано происхождение сигнала /RES на RTC, как понимаю он должен формироваться из сигнала с NemoBus.
6) не нашёл в описалове как формируется сигнал подтверждения прерывания INTA Кто знает как это делалось?

[Ewgeny7]

1) какие существуют программы (в т.ч. и те что в ПЗУ), которые знают и используют SMUC RTC, SMUC 8259?
2) SMUC RTC, SMUC 8259 по умолчанию инициализируются при старте, или они должны инициализироваться отдельным софтом, этот софт есть?

Насчет 8259 незнаю, пользовался ли им хоть кто-нибудь. Да и на плате смука стояла пустая панелька под него.
RTC инициализируется при старте теневиком. Чтение-запись также из теневика. Просмотр состояния (времени) реализован в Реал Коммандере, TRDN, возможно, гдето еще. При неиспользовании сигнала ДОС RTC прекрасно читается-пишется даже из Бейсика. В теневике время/дата/день_недели показывается в нижней строке экрана.

Сигнал /RES на RTC заводится с баса.
Сигнал /INT0 (на схеме оригинала /IRQ0 ) должен идти на контроллер прерываний, поскольку его нет и нафиг ненадо, сигнал повешен в воздухе.
Авторы назвали СМУК смуком, теперь переименовывать поздно.
D3 #FFBA в дискретной схеме не используется. Ибо не испоьзуются навороты с контроллером прерывания и прочими ISA...

Автор описания v0.0b, он же автор этой версии - spensor.