Если в системе все синхронизируется кварцем, то разбросы в определенных пределах вообще не имеют значения.Цитата:
Сообщение от Hunta
Если же во времязадающих цепочках стоят емкости, то там да, может плавать. И от нагрева в том числе.
Вид для печати
Если в системе все синхронизируется кварцем, то разбросы в определенных пределах вообще не имеют значения.Цитата:
Сообщение от Hunta
Если же во времязадающих цепочках стоят емкости, то там да, может плавать. И от нагрева в том числе.
Тактовая частота процессора не выходит на QBUS, поэтому проц и внешние устройства никак не синхронизированы клоком. И за какое время внешнее устройство ответит на запрос процессора - зависит только от разброса параметров внешнего устройства.Цитата:
Сообщение от Titus
Откуда у штатных устройств УКНЦ, которые все известны, разброс параметров?
То есть все микросхемы, все резисторы, конденсаторы и т.п. - идеально изготовлены? Удачи.
Зачем мешать все в одну кучу?Цитата:
Сообщение от Hunta
Возьми для примера спектрум Пентагон. На чем его не собирай, растактовка всегда одинаковая. Все демы, всякая синхронизация мультиколорных эффектов будет одинаковой, без плавания.
Единственная цепочка, в которой могут быть допуски - это длина сигнала INT, в цепи которой стоит конденсатор.
- - - Добавлено - - -
Говоря иначе, в системах, синхронизированных точным тактированием (кварцевый генератор), плавание цифровых параметров в определенных пределах не скажется ни на чем.
Окей. Вопрос, а вот это тогда что?Цитата:
Сообщение от Titus
Цитата:
Сообщение от Arseny
Я думаю, что это та самая емкостная линия задержки в какой-то из цепей. Нагреваясь, параметр меняется, и вместо, допустим, 16 тактов на команду, становится 20 (если говорить о ПП, т.к. его скорость кратна 4 тактам).Цитата:
Сообщение от nzeemin
Цитата:
Сообщение от Titus
Ткните пальцем - где? Пока я вижу только кофейную гущу.Цитата:
Сообщение от Titus
А заодно объясните эффект - на выходе RPLY ОК - скорострельность 1280 коп/с, на выходе RPLY 3С - скорострельность 1600 коп/с. Кварц один и тот же.
А вообще не надо, не объясняйте - догадки и гадания - я их и сам могу нарисовать
Да, но нет. Работы нужно много, начиная с переписывания cpu core, шины и далее везде. Черновой вариант (конец 2016 года) -- https://github.com/shattered/mame/commits/gitwip (тут не только УКНЦ, но и МС1201 с КЦГД). Cам этим заниматься не планирую, но могу залить более свежие исходники и обрисовать планы тем, кто захочет продолжить.Цитата:
Сообщение от nzeemin
Собрал и выложил утилиты для эмулятора УКНЦ - https://github.com/nzeemin/ukncbtl-u...s-20200118.zip
Как бы ничего нового (последние правки были в октябре 2019), просто чтобы было на гитхабе - не все сидят на этом форуме.
Папка эмулятора в общедоступном "хламничке"Цитата:
Сообщение от nzeemin
{чего там только не было - чего там только нет ;-) }
http://hobot.pdp-11.ru/EMULATORS/UKNCBTL_HDD/
+ тема с играми на этом форуме читайте первое сообщение, там дополнительные ссылки на игры и сохранения (SaveState)
для UKNCBTL.
В этой версии немного изменений:
1. Поправлена таблица перекодировки из набора символов УКНЦ в Юникод - влияет на команду Screen to Text и на изображение символов в окне Memory.
2. Меня всё-таки убедили что GRB это правильная палитра, поэтому она сделана дефолтной в эмуляторе.
Скачать: https://github.com/nzeemin/ukncbtl/r...tl-644-exe.zip
nzeemin, хотел узнать твоё мнение по такому вопросу:
В архиве часть ПО, которое требует стандартной сети УК-НЦ (как в школе), какова возможность
включить\добавить в новой версии эмулятора - виртуальную РМУ - по галочке (подкл\откл).
У которой СА вместо КМД и слотов ПЗУ и соотв. окно, а СА слухает только основное окно эмулятора.
Тогда по вкл. на экране РМУ всегда "*ЗАГРУЗКА ИЗ СЕТИ*", пока пакетики не полетят от РМП (основного окна UKNCBTL),
это не хотелка\не просьба - обсуждение возможности\идеи такой реализации?
Спасибо.
http://s17.rimg.info/125c350d70ce1ef...3e54d23c7f.gif
зы: в плане интерфейса - просто представь, что в родительском окне две вкладки РМП (это текущая допустим 644 УК-НЦ ) и
РМУ ( это по умолч. не активная сетевая 644-машинка у которой все те же экранные настройки, только нет никаких дискет и слотов).
Как-то так?
Этот момент поправил. Теперь DIR/FIL/BAD в эмуляторе проходит за ~34 секунды.Цитата:
Сообщение от Alex_K
Кроме того, в этой версии добавлена команда File > Screenshot to Clipboard.
- - - Updated - - -
Пока развитие сети не в приоритете.Цитата:
Сообщение от hobot
Как-то быстровато. Насколько я понимаю, при смене стороны/дорожки головка оказывает сразу в начале дорожки. Тогда да, полная дискета прочтется где-то за 32 сек.Цитата:
Сообщение от nzeemin
- - - Добавлено - - -
Посмотрел на github. Да, всё правильно. После чтения последнего сектора ещё остаётся промежуток GAP4 до конца дорожки и GAP1 в начале следующей. За это время драйвер дисковода успевает сделать подготовительные операции для чтения первого сектора на следующей дорожке. А когда позиция обнулялась, то размера GAP1 не хватало и первый сектор пропускался, в итоге - лишний оборот.Цитата:
Сообщение от Alex_K
- - - Добавлено - - -
У меня на реальной машине около 52 сек. Но на контроллере не стоит перемычка, временные параметры для НГМД-6022, а они там большие. Надо будет попробовать с перемычкой.
Лучше поздно чем никогда - улучшил цвета в тёмной теме в Qt-версии эмулятора, проверял под kubuntu.Цитата:
Сообщение от randomizer
Не идеально, но теперь хотя бы основной текст стал читаемым.
https://user-images.githubuserconten...2ae6d3916f.png
Огонь! QT версия почти готова стать основным инструментом. :v2_dizzy_punk:Цитата:
Сообщение от nzeemin
Кстати, обнаружил баг/особенность эмулятора.
Касается это регистра управления адресным пространством ПП.
С помощью этого регистра можно подставлять ОЗУ выше 0100000 в адресное пространство ПП, но как это работает из тех описания не очень понятно.
Как в итоге я выяснил, когда выставляешь в регистре разряды замены банков ПЗУ банками ОЗУ.
Это позволяет напрямую писать в ОЗУ, но читается не то что записал(подозреваю что чтение производится из ПЗУ)
Чтобы читать из ОЗУ, необходимо отключать сестемное ПЗУ. Но это возможно только для диапазона 100000-117777
А в эмуляторе достаточно выставить любой разряд замены и можно как писать в подставленное ОЗУ, так и читать из него.
Вроде бы баг, но когда знаешь о нём, он в общем то не мешает.
Это хорошо понятно из реверса чипов в соответствующей теме)Цитата:
Сообщение от randomizer
Да, эмулятор в этом плане работает некорректно.Цитата:
Сообщение от randomizer
При подставлении ОЗУ в области ПЗУ на реальной машине работают одновременно и ПЗУ и ОЗУ. Т.к. ПЗУ поддерживает только чтение, то в ОЗУ можно спокойно писать командами MOV, CLR. А вот при чтении одновременно работают и ПЗУ и ОЗУ. Т.к. ПЗУ быстрее, то оно сразу выставляет на шину данные и сигнал RPLY. А с контроллером ОЗУ возникает следующий эффект: чтение с ОЗУ в области ПП происходит за два захода - сначала читается младший байт, потом старший. Но контроллер ОЗУ при команде чтения сразу же выставляет свой буферный регистр на шину, в том регистре результат предыдущего чтения с ОЗУ. Потому в качестве результата оказывается сложенное по ИЛИ значение чтения с ПЗУ и результат предыдущего чтения с ОЗУ. Иногда контроллер ОЗУ за это время успевает прочесть младший байт с ОЗУ, в итоге результатом чтения будет значение чтения с ПЗУ и сложенное по ИЛИ значение старшего байта предыдущего чтения с ОЗУ и значение младшего байта текущего чтения с ОЗУ.
В окне 100000-117777 ПЗУ можно отключить. Тогда с ОЗУ можно полноценно работать. Но это только в том случае, если в разъемы ВУ не установлен контроллер IDE или электронный диск от ЭР.
А почему так? Ведь выборка внешнего ПЗУ тоже управляется установкой разрядов в соответствующем регистре.Цитата:
Сообщение от Alex_K
Можно его деактивировать при необходимости, или изначально не подключать банки внешнего ПЗУ.
Обе схемы изначально разрабатывались ЭЛЕКТРОННЫМИ РАБОТАМИ. Там выбор платы сделан довольно простым способом - запрет системного ПЗУ сигналом CE0 и выбор соответствующего слота сигналом CE3. Состояние сигналов CE1 и CE2 роли не играет. Так что возможен такой вариант, что отключили системное ПЗУ в окне 100000-117777, а туда сразу же может встать контроллер IDE, в зависимости от состояния сигнала CE3.Цитата:
Сообщение от randomizer
Как я понимаю, эта же проблема уже описана тут - https://zx-pk.ru/threads/31349-uknts...ulyatsiya.htmlЦитата:
Сообщение от Alex_K
Записал в бэклог, пока не занимался совсем.
О, видимо тема быстро ушла с первой страницы форума. Как раз в отпуске тогда был.Цитата:
Сообщение от nzeemin
Да, там она описана. Я тоже там высказывался. Единственно, что я говорил, что команды MOVB и CLRB лучше не употреблять. Но скажу, что всё таки эти команды употреблять можно, т.к. у этих команд чтение фиктивное и его результаты не используются.Цитата:
Сообщение от nzeemin
randomizer, в Qt-версии исправил проблему с палитрами, проверьте у себя пожалуйста.
Теперь всё корректно. Спасибо!Цитата:
Сообщение от nzeemin
Но по цветам ещё есть замечание - в эмуляторе, значения яркости задаваемые регистром палитры слабо заметны.
Например если, если понизить яркость зелёного этим регистром, то на ЭЛТ мониторе вместо жёлтого, я вижу оранжевый.
Глядя на изображение в эмуляторе, если не знаешь, то сразу и не скажешь что на экране не чисто желтый, а оранжевый.
Последний коммит обратил внимание на то, что для повышенной яркости используется значение 0xFF, для обычной 0x80, а вот для пониженной 0x60 и 0xDF.
Т.е. обычная и пониженная яркость отличаются 33%
А если вглянуть на схему, то для обычной яркости стоит резистор 390 Ом, для пониженной 820 Ом, отличие на 50%
Правильней было бы вместо значений 0x60 и 0xDF использовать 0x40 и 0xC0
Насколько я помню, уровни яркости в частности и цвета вообще подбирались так чтобы соответствовать полной палитре из TSTPAL от @Titus:Цитата:
Сообщение от randomizer
https://github.com/nzeemin/ukncbtl-d...altst-ygrb.png
См. тему https://zx-pk.ru/threads/20686-mnogo...na-uknts!.html
Как подбирались? Визуально? К какому монитору подключалась УКНЦ, CRT или LCD?Цитата:
Сообщение от nzeemin
По схеме УКНЦ можно четко определить как по уровню отличается сигналы с обычной, пониженной, и повышенной яркостями.
Мною подбирались. Не на основе уровней сигналов, а на основе субьективного понимания, какие должны быть оттенки пониженной яркости, чтобы от них был какой-то прикладной смысл. Не слишком темные, но они и не должны сливаться с полными яркостями.Цитата:
Сообщение от randomizer
А как же реальные УКНЦ?Цитата:
Сообщение от Titus
Переделываем на основе субъективного понимания?
Так оно свое у каждого.
На реальной УКНЦ оно смотрелось похоже. Но моники разные, особенно старые. Там и гамма нелинейная, скорее всего, и все такое прочее. По ним сложно сделать оценку.Цитата:
Сообщение от randomizer
А на реале не у каждого своё, все УКНЦ одинаковые? :-)Цитата:
Сообщение от randomizer
Напомню цитату (Худяков Р.К. Практика работы с периферийным процессором УКНЦ, "ИНФО", начало 1993 года_:
Цитата:
Здесь следует заметить одну деталь. На машинах з-да "КВАНТ" литеры 5 из схемы контроллера цветного монитора удалена ИС 155ЛП9 , поэтому изменения яркостного бита ни к чему не приводят, а на почти половине машин з-да "СЭМЗ" ИС 155ЛП9 заменена на ИС 155ЛН2 поэтому в яркостный бит для получения 100% яркости нужно записать 0 , а для 50% - 1 , но опять же все выше сказанное справедливо только для цветного монитора. На отображение градаций яркости на черно-белом мониторе этот бит не влияет. Так же последние полтора года изменена схема подключения цветного монитора (поменяны между собой выходы красного зеленого цветов). Это тоже следует иметь ввиду.
На физические уровни сигналов не влияют ни искажения монитора, ни субъективное восприятие :v2_wink2:Цитата:
Сообщение от Titus
Субъективно, градации которые я вижу на Sony PVM имеют смысл.
Если смотреть на то как это в эмуляторе выглядит, впечатление - просто не стоило заморачиваться с переключением палитр.
- - - Добавлено - - -
То какая ИС установлена не влияет на номиналы резисторов. Именно они определяют уровень сигнала.Цитата:
Сообщение от nzeemin
От ИС только зависить при 0 или при 1 этот резистор задействован будет.
На Sony PVM и вашей конкретной УКНЦ - вероятно имеет смысл. Для среднего пользователя с рандомным телевизором - вероятно нет.Цитата:
Сообщение от randomizer
Как вариант, могу сделать в эмуляторе ещё две палитры - для 16 цветов (8 цветов в двух градациях яркости), RGB/GRB.
Есть конкретные УКНЦ, есть конкретные схемы. На них и я предложил ориентироваться. А не на субъективное мнение.Цитата:
Сообщение от nzeemin
Палитра с шагом яркостей каждой компоненты цвета в 25%. Или 0x40, 0x80, 0xC0 0xFFЦитата:
Сообщение от nzeemin
Было бы здорово :v2_dizzy_yes:
- - - Добавлено - - -
Кстати :v2_dizzy_biggrin2:
Инверсные или неиверсные яркости - это можно переключать в программе.
RGB/GRB - переключение, тоже можно добавить в свою программу.
А вот подкорректировать физические уровни цветовых компонент - увы, без паяльника никак.
Ты просто не видел скрины под расширенную палитру. Поищи в той теме скрины от супер-марио, например.Цитата:
Сообщение от randomizer
Не поленился, нашел https://zx-pk.ru/threads/20686-mnogo...l=1#post570173Цитата:
Сообщение от Titus
Подозреваю что здесть тоже изображение субъективно подобранными цветами
Интересно на это посмотреть на реальной машине, а не в таком виде.
На мой взгляд отсутствие чистого белого портит всю картину.
У меня даже есть идея сделать так, чтобы вместо черного с установленным битом яркости отображался чисто белый.
Т.е. из двух черных в палитре, один использовать под вывод чистого белого.
Это не единственная картинка) В теме есть еще.Цитата:
Сообщение от randomizer
Она в палитре из моего эмулятора.
- - - Добавлено - - -
Ты хочешь переделать схему формирования цвета в УКНЦ?)Цитата:
Сообщение от randomizer
Не переделать, а доработать. Два черных цвета в палитре, это роскошь которую мы не можем себе позволить. :v2_smile:Цитата:
Сообщение от Titus
Это же не перекраивание палитры на свой лад.
Давайте про аппаратные доработки обсуждать в другой теме.Цитата:
Сообщение от randomizer
И да, это перекраивание палитры на свой лад.