А не заменить ли нам КР580ВН59 на КР1818ВН19 (в девичестве AMD Am9519). Немножко подправить базовый софт и не ждать много лишних тактов на каждое прерывание
Требуется эмуляция идеи
А не заменить ли нам КР580ВН59 на КР1818ВН19 (в девичестве AMD Am9519). Немножко подправить базовый софт и не ждать много лишних тактов на каждое прерывание
Требуется эмуляция идеи
Последний раз редактировалось svinka; 20.07.2018 в 20:03.
Не советую, это уже не будет точной репликой.Сообщение от svinka
Не,.. конечно, режим интересный, удобный и быстрый для работы со спрайтами. В них нулевой цвет прозрачный - не записывает в память, когда присутствует в соответствующем поле (при глубине цвета 4 таких полей/пикселей в 16-ти битном слове 4, а при глубине 2 бита на пиксель - 8 полей, также работа с масками поддержана для и байтовых записей).
Под формирования масок записей целиком выделена микросхема V5, там под управление всего две пары сигналов: с процессора ~WTBT и A0 для гашения стробов записей (установки их в "1") при обычных операциях байтовых записей, а вторая пара сигналов приходит с микросхемы VA (VA.o13->V5.i8, VA.o12->V5.i9), состояние на них можно представить кодами:
В микросхеме V5 не хватает входов, чтобы завести все 16 бит с шины данных, поэтому в половине микросхемы V4 сделаны 4 обычных элемента ИЛИ, сигналы оттуда можно переименовать так:Код:VA-F5 => WEMODE0 (код строба записи в ОЗУ) VA-F4 => WEMODE1 WEMODE1 WEMODE0 v v-----------/ 0 0 - все стробы неактивны 0 1 - под условием гасятся записи пары бит (значение 00 не записывается) 1 0 - под условием гасятся записи четвёрок бит (значение 0000 не записывается) 1 1 - все стробы записи активны (решим маскирования не используется)
Что разработчикам помешало сделать режим маскирования с глубиной 8 бит, даже более полезный чем для 2 и для 4 bpp? Там ведь объёмы пересылаемых данных больше... Просто не хватило одного входа в V5, в принципе ещё один логический элемент снаружи, например для 8 и 9 бита AD, такую проблему решает... но нужно ещё искать один выход в VA... Уже сейчас на том же оборудовании за счет смены прошивки можно было бы сделать режимы маскирования, например, для 4 и 8 бит, но увы это будет не совместимо со всем тем огромным пластом ПО для ПК11/16к...Код:V4-12 => AD04OR05 V4-13 => AD06OR07 V4-19 => AD00OR01 V4-18 => AD02OR03
Самое плохое, что в документации написали, что маскирование для 4-х бит в ТО включается кодом 1X, тем самым усложнив возможно добавления сразу трёх режимов маскирования 2/4/8 бит (т.к. наверняка с такой документацией часть программ уже используют код 10, а другая часть - 11).Эта логика превращения кодов 10 и 11 с на сигналах MMWM4B/MMWM2B как раз реализуется на выводах 13 и 12 микросхемы VA (причем 12-й можно реализовать более простой формулой без сигнала i8). Ещё там замешивается сигнал DOUT (сигнал записи с процессора), а также используются выходы с частотам 2МГц и 1МГц, чтобы строб формировался в нужный момент.
P.S. И напоследок плохая новость - мой документ с формулами прошивок v20180711 содержит неверный трактовки для чипов P3, V5, V7 и VA (в произведениях все множители нужно проинвертировать). Дело в том, что чтобы получить логический формулы из JED файлов от микросхем КР556РТ2 (PLS100), я использовал свой велосипед сделанный на базе другого велосипеда - там был косяк, а проверить было не начем. Сейчас я перешел мопед MAME-довских товарищей, на программу jedutil, надеюсь там ошибок уже нет.
Можно же ведь прямо сейчас уже начинать делать сборку на FPGA, хотя бы в симуляторе чтобы погонять и увидеть явные проблемы с расшифровкой ХЛок...
С уважением, Александр.
Музей ретрокомпьютеров в Минске!
Здесь ничего нет => http://byteman.by
И здесь тоже --->>> http://bytespace.by
Новая версия: v20180723.pdf
Ещё более новая версия: pk11logic-v29180727.pdf (по результатам одновременного моделирования поведения чипов V1/V2/V9/V3/V4 перешёл на другие версии дампов прошивок PAL16R4/V9/07713384_neon1556hp4_v9_brd1.jed и PAL16R4/V4/379daf18_neon1556hp4_v4_add2.jed, - прошлая версия V9 просто криво работала, а V4 похоже была от варианта для 72Гц развёртки).
Вот как выглядит граф взаимосвязей V1/V2/V9/V3/V4: counters.pdf (построен почти автоматом из нетлиста принципиальной схемы и дизассемблера прошивок).
Вот граф взаимосвязей всех ПЛМ-ок: graph-all-no-fb.pdf (без обратных связей в самих чипах), graph-all.pdf (с обратными связями: зелёные через регистры, а красные через комбинаторику, которые потенциально могут также образовывать триггера). Домены на V... и P... чипах связаны слабо, вот они в виде отдельных графов: graph-Vx.pdf, graph-Px.pdf.
Вот поведенческая модель (да, да Си - так было удобнее, но я исправлюсь быть может...): V12934.zip
Последний раз редактировалось troosh; 27.07.2018 в 20:33.
Предлагаю выполнить такие переименования в схеме (да, только младшие разряды счетчиков X,Y неинверсные):
Сигналы MA_LO и MA_HI управляют буферами с третьим состояние ВУшек, за счет это реализовано мультиплексирование адресов динамической памяти (при моделировании вижу, что там изредка одновременно разрешаются обе половинки, а это конфликт приводящий к лишнему потреблению, перегреву и даже выходу вушек из строя,.. - пока не понял это косяк моей модели, сбой снятия дампа прошивки или задумка разработчиков).Код:V1-17 -> X0-8MHz V1-16 -> ~X1-4MHz V1-15 -> ~X2-2MHz V1-14 -> ~X3-1MHz V2-16 -> ~X4-500kHz V2-17 -> ~X5-250kHz V9-17 -> ~X6-125Hz V9-15 -> ~X7-62500Hz V9-16 -> ~X8-31250Hz V9-14 -> ~X9-15625Hz V2-14 -> ~MA_LO (Выдача младших бит адресов на модули памяти) V2-15 -> ~MA_HI (Выдача старших бит адресов на модули памяти) V3-13 -> Y0 V3-16 -> ~Y1 V3-14 -> ~Y2 V3-15 -> ~Y3 V3-18 -> ~Y4 V4-17 -> ~Y5 V4-14 -> ~Y6 V4-15 -> ~Y7 V4-16 -> ~Y8 V3-12 -> ~DAC_EN (разрешение работы видео ЦАПа или сигнал VBLANK) V3-17 -> VSYNC (сигнал кадровой синхронизации)
И за одно, на счёт "ИС регистрового файла К555ИР26 (D30-D33)"... Эти микросхемы образуют память на два порта: порт записи по 16 бит, порт чтения по 8 бит с выбором нужной половинки. Ёмкость этих микросхем используют только на половину для двойного буферирования считываемых слов из видеопамяти, которым предстоит стать пикселями или данными в "ОЗУ палитр" (т.к. входы RA посадили на землю, а WA используют как дополнительный сигнал разрешения записи - просто когда записывать не нужно, то пишут пишут в "молоко"). Соответственно такие замены:
Код:V6-16 -> ~VRF_WR (запись в видео RF слова для видеоконтроллера) V7-F0 -> ~VRF2CLUT_OE (пропуск данных из видео RF на шину данных "ОЗУ палитр") VA-F0 -> ~VRF_RD_LO (чтение младшей половины видео RF) VA-F6 -> ~VRF_RD_HI (чтение старшенй половины видео RF) VA-F7 -> ~VRF_A0 (выбор адреса при чтении RF)
С любовью к вам, Yandex.Direct
Микросхема VB выделяет отдельные пиксели с выхода видео регистрового файла. Тактируется она постоянно частой 16 МГц с выхода O13 чипа V2 (в схеме это проводник NET00063), причем там в прошивке просто повторитель со входе I2, где подключен кварц.
Итак, VB это несложная схема сдвигового регистра/мультиплексора, режим работы задаётся только тремя входами:
Сигнал VSYNC (раньше был V3-17) подключен ко входу OE микросхемы VB, что позволят отключать выходы регистра и тем самым реализовать протекание на резисторах R36,R37,R43,R73 значений сигналов X2..X6 (такой вот мультиплексор резисторах и буферах с третьим состоянием, на Спектруме из-за подобной схемотехники незапланированный порт атрибутов появился). Тем самым во время действия VSYNC (а это 11 телевизионных строк если я не напутал чего с симуляцией), происходит обновление ОЗУ палитр из памяти, все 4 Кбайта каждый кадр,.. но пока не разбирался с подробностями.Код:VB/i4 VA-F3 (переименовать в SHIFT_M0) VB/i5 VA-F1(переименовать в SHIFT_M1) i2 PF_VN0 (в зависимости от номера видео режима, определяет на сколько сдвигать текущее состояние регистра, на 1 или 2 бита). i5 i4 i2 0 0 0 Сдвинуть на 1 бит вправо (в сторону мл. разрядов) 0 0 1 Сдвинуть на 2 бита вправо 0 1 x Загрузка мл. 4 бит (VD0..VD3) 1 0 x Загрузка ст. 4 бит (VD4..VD7) 1 1 x Удерживать текущее состояние
Аналогичный трюк с "мультиплексорами" на резисторах R1, R2, R8, R11 (их бы "кучно" их переименовать бы), сделан для режима 8 бит/точку. Только в этом случае отключают буферы в микросхеме V9 сигналом VA-F2 (должен быть в нуле VSYNC, а сигналы PF_{PB,VN1,VN0} и сигнал со счетчика видеоотрезков в единице), тем самым для режима VM8 пропускается вся та хитрая логика на множества палитр у других режимов.
troosh, выполнено (ред. 28.07.2018).
Выводы
V4-14 -> ~Y6
V4-15 -> ~Y7
не используются (никуда не подключены).
Ну вот так, видимо не пригодились нигде...
Там логика такая: счетчик Y просто считает строки до тех пор пока 312 штук не насчитал, а в это время ВУшки сами инкрементируют адреса (в два уровня вложенности: для адресов строк и отрезков). Т.е. тут как в других компьютерах для доступа к видеопамяти позиция по вертикали (счетчик Y) не нужен, здесь применили видеоуказатели живущие своей жизнью.
Смотрю схему монитора МС6106, а именно лист UVO1.tif - там нагружается на 75 Омный резистор каждый цвет. Возможно стоит такие резисторы тут печатной плате поставить (но не запаивать сразу) - на случай, когда в каком-то ТВ или мониторе входное сопротивление будет другое (300 Ом например)... Хотя на SCART-е входное заявлено как раз 75 Ом.
Попытался прикинуть в электронной таблице что там на выходе видео ЦАПа зеленого цвета должно получаться в зависимости от кода (считая, что на выходе АП5 при "0" - 0.5В, а при "1" - 2.5В):
Вроде как всё правильно - размах 0,775, но нелинейность при такой точности резисторов...Код:0 0,194 8 0,505 16 0,747 24 0,891 1 0,237 9 0,535 17 0,767 25 0,905 2 0,277 10 0,563 18 0,786 26 0,917 3 0,317 11 0,592 19 0,805 27 0,929 4 0,357 12 0,620 20 0,824 28 0,940 5 0,394 13 0,646 21 0,841 29 0,951 6 0,427 14 0,670 22 0,856 30 0,960 7 0,461 15 0,693 23 0,872 31 0,969
Разработчики в номиналы резисторов заложили гамма-коррекцию монитора что ли?...
Но R-2R ЦАП тут всё равно технологичнее смотрелся бы...
На разъемы XS4 и XS5 (или только на один из них?), выведены проводами сигналы старших бит физадреса:
1) IMG_2099.JPG - PHА17, PHА18, PHА19
2) IMG_0088.JPG - PHА16, PHА18, PHА19
Мне первый вариант больше нравится своей последовательностью, хотя логично было уж выводить сразу все четыре линии 16-19, да что уж гулять так гудя 16-21...
Но не понятно зачем ещё вообще их стали заводить навесным монтажом-то? Вот у нас есть два разъема расширения с 16 разрядной шиной данных и адресные линии под 64 регистра. В принципе из шины адреса/данные можно было бы извлечь ещё дополнительные биты адреса, но они заводят старшие биты из регистров HR7 и UR7 "для управления работой расширителя ввода-вывода" (в ТО написали, а сразу не развели эти сигналы). Забавно в общем...
Кстати, просьба прозвонить контакты B16 этих разъемов - в ТО указывается, что там должен быть заведен сигнал A06, а на схеме такого соединения нет (правда есть и обратная ситуация: в ТО не упоминается -12В, а по схеме это напряжение завели).
На самом деле хороший вопрос - мощность резисторов в первом приближении я бы выбирал так: ставим резисторы 0.125 Ватт? - значит смотрим при каком сопротивлении будет выделяться такая мощность (при имеющихся у нас напряжениях 5В и 12В). Заветное R=(1/W)*U**2, т.е. для 5В резисторы должны быть сопротивлением не меньше 200 Ом, а для 12В - не меньше 1152 Ом. На самом деле лучше брать с запасом в раза полтора (300 Ом и 1700 Ом), всё что меньше нужно увеличивать мощность резисторов.
Например, пары резисторов R38+R39 и R13+R14 в группе риска. Их общее сопротивление 400 Ом, а учетом того, что они выходят на разъем, есть риск закоротив на землю ток через резисторы 180-220 Ом будет разогревать резисторы больших их номинальной мощности даже без запаса... Или вот странный резистор R28 в 1кОм заряжающий от +12В аккумулятор в 4.5 В, - если коротнут при установке или сама АКБ закоротиться, то данный резистор будет разогреваться выше номинального... Ещё там есть резисторы R32-R32, R68-R67 на RS-232, где 12В в обе стороны допускается... эти 510 Ом нужно бы поставить четвертушками...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
