Просмотр полной версии : Реверс-инжиниринг УКНЦ (1515ХМ1&2, 1801ВП1, 1801ВМ2)
Страницы :
1
2
[
3]
4
5
6
7
Столбцы 20 и 21 из 22.
Из интересненького:
1. Репутация данного чипа, как самого мульиплексорного и регистрового подтвердилась. Их в нем миллиарда два, не меньше.
2. Очень много соединений. Причем, я их рисую уже выпрямленными, тогда как на деле они трассируются очень затейливо, и даже иногда кругами.
3. После дорисовки всего, можно будет начать восстанавливать отколотые кусочки.
Скачать с Яндекс.Диска (https://yadi.sk/i/XVbW_G_aXaO3GA)
CodeMaster
03.06.2020, 22:29
p.s.: Следующие столбцы не раньше следующей недели.
Но, зато ударными темпами!
Столбцы 20 и 21 из 22.
Даёшь пятилетку за 4 дня!
Даёшь пятилетку за 4 дня!
Даешь сто норм, Стаханов!
https://www.youtube.com/watch?v=b62Dm6VBzFs
- - - Добавлено - - -
На самом деле, я просто перевожу уже схему не глядя в шпаргалки, как выглядит тот или иной элемент, потому что помню все наизусть) Смотрю на кристалл, и сразу рисую.
То, что долгие годы ждала мировая общественность (в лице двух с половиной апологетов УКНЦ) - свершилось! Последний из четырех чипов отреверсен.
Конечно, это еще не все, и без вскрытия альтернативных версий чипов не все тайны УКНЦ будут нами познаны, но уже сейчас каждый житель нашей страны сможет три года отдыхать на Канарских островах создать клон УКНЦ на ПЛИС, либо же написать абсолютно точный эмулятор.
Конечно, схема еще требует перевода в человеческий вид.
p.s.: Из всех предыдущих БМК от УКНЦ - этот самый навороченный.
p.p.s.: Все места, где соединения восстановлены (из-за сколов) помечены на всякий случай вопросительными знаками.
Схема в PDF (https://yadi.sk/d/lRBz-M3GdH4kxw)
Схема в формате P-CAD (https://yadi.sk/d/TjqjSM_ipNiAZA)
- - - Добавлено - - -
Дорисовал недостающее, и получилась ревизия 23. Вроде бы больше висящих в воздухе ножек нет.
Высяснилась следующая особенность - шины /AG и шины /DC имеют взаимоинверсную полярность.
Итак, уважаемые знатоки, внимание, вопрос. Какая из них инверсная, а какая прямая?
Интересный 16-битный счетчик (D4, E4 и т.д.). Он инверсный (понятно, т.к. это проще) состоит из нескольких секций по 3 бита в каждой, причем, каждая секция с ускоренным переносом.
По структуре 3+3+3+3+3+1 = 16
Плюс, он еще с загрузкой произвольного значения, поэтому и выглядит так монстренько)
Высяснилась следующая особенность - шины /AG и шины /DC имеют взаимоинверсную полярность.
Итак, уважаемые знатоки, внимание, вопрос. Какая из них инверсная, а какая прямая?
В общих чертах разобрался, похоже, что так:
AG, AC, DG - инверсные
DC8..15 - прямая
DC0..7 - опять инверсная
Высяснилась следующая особенность - шины /AG и шины /DC имеют взаимоинверсную полярность.
Итак, уважаемые знатоки, внимание, вопрос. Какая из них инверсная, а какая прямая?
По схеме УКНЦ линии адреса прямые, а линии данных - инверсные.
- - - Добавлено - - -
В общих чертах разобрался, похоже, что так:
AG, AC, DG - инверсные
DC8..15 - прямая
DC0..7 - опять инверсная
DC0..DC7 и DC8..DC15 - это линии данных ОЗУ ЦП. По схеме они инверсные. Да и не может быть, что младший байт инверсный, а старший - прямой.
В общем по AC и DC должно быть также, как и в 1515ХМ2-003(1515ХМ1-039), а по AG и DG также, как и в 1515ХМ2-002(1515ХМ1-032).
При этом AG и DG ещё работают для передачи данных ОЗУ ЦП для контроллера ПП 1515ХМ2-002(1515ХМ1-032) по линиям запроса RQ, CC0, CC1.
Обьясню, как определял.
Регистр, в который загружается адрес 0xB8, в него так же загружаются данные из DG. Таким образом выясняем полярность DG, она инверсная.
Так же из DG загружаются данные в счетчик адреса. Это тоже подтверждает полярность DG.
Данные из DG идут на AC не меняя полярности, значит AC тоже инверсная.
Данные из AG идут на AC не меняя полярности, значит AG тоже инверсная.
Данные DC8..DC15 идут на AG меняя полярность, значит DC8..DC15 - прямая.
Данные DC0..DC7 идут на DG не меняя полярности, значит DC0..DC7 - инверсная.
Это пока что предварительно так.
Обьясню, как определял.
Регистр, в который загружается адрес 0xB8, в него так же загружаются данные из DG. Таким образом выясняем полярность DG, она инверсная.
Так же из DG загружаются данные в счетчик адреса. Это тоже подтверждает полярность DG.
Данные из DG идут на AC не меняя полярности, значит AC тоже инверсная.
Данные из AG идут на AC не меняя полярности, значит AG тоже инверсная.
Данные DC8..DC15 идут на AG меняя полярность, значит DC8..DC15 - прямая.
Данные DC0..DC7 идут на DG не меняя полярности, значит DC0..DC7 - инверсная.
Это пока что предварительно так.
Вы определяли по пути запроса данных ОЗУ ЦП в контроллер ПП. Естественно, что в данном случае младший байт инверсный, а старший - прямой. Всё дело в том, что ОЗУ ЦП 16-разрядное, а ОЗУ ПП - 8-разрядное. Но надо как-то передать 16-разрядные данные в контроллер ПП. И в этом случае младший байт передаётся по линиям DG, а старший по линиям адреса AG. Вот и получается разная полярность.
Да, похоже, старшая часть DC тоже инверсная, но иногда используется, как неинверсная. Отсюда и пошли сомнения.
Тогда как AC, AG и DG пока что четко инверсные.
Интересно, как устроен битовый конвейер для битпланов. Можно было бы представить, что там обычные сдвиговые регистры, которые загружают 8 бит данных из битплана, а потом последовательно их выдвигают. Но здесь такого нет. Здесь вложенные мультиплексоры, которые позволяют извлечь сразу нужный бит из регистра. Мультиплексор первого уровня выбирает четный или нечетный бит. Мультиплексор второго уровня выбирает из получившихся 4-х битов тоже четные/нечетные. Остается два бита, из которых выбирает мультиплексор третьего уровня.
- - - Добавлено - - -
Некоторый прогресс по переводу схемы в человеческий вид.
Собрал большинство регистров, расчистив процентов 40 схемы.
Разумеется, регистры - это самое легкое, т.к. занимают много место, регулярны и понятны почти сразу.
Вот схемы тактирования и мелкой логики - это да, там придется повозиться.
Перерыв на недельку.
Здесь вложенные мультиплексоры, которые позволяют извлечь сразу нужный бит из регистра.
Это стандартный блок цифрового дизайна - "barrel shifter" называется. Как видим - изобретен не вчера :)
Это стандартный блок цифрового дизайна - "barrel shifter" называется. Как видим - изобретен не вчера
Сдвига там нет, поэтому скорее правильно обозначит блок, как просто мультипкексор 8 -> 1.
Сдвига там нет
А это что написано:
Можно было бы представить, что там обычные сдвиговые регистры
"barrel shifter" это именно комбинационная логика для замены сдвиговых регистров.
Это я к чему - все уже украдено придумано до нас, есть устоявшаяся терминология, желательно ей следовать.
А это что написано:
Потому что там не сдвиг, а извлечение нужного бита из регистра.
А barrel shifter, на сколько я понял, все же производит сдвиг.
То, что долгие годы ждала мировая общественность (в лице двух с половиной апологетов УКНЦ) - свершилось! Последний из четырех чипов отреверсен.Не расслабляйся! Еще осталась ХМ2-002. Почты, вроде-бы, заработали, на днях отправлю.
Не расслабляйся! Еще осталась ХМ2-002. Почты, вроде-бы, заработали, на днях отправлю.
Замечательная новость) Хотя, она выбивается из теперь привычной линейки ХМ1. У ХМ2 хотя и приятней схема на глаз, но больше вариативности в элементах.
Но ХМ2-002 - это не единственное, что не сфоткано. Есть еще ХМ1-33, 36 и 31. Так что надо изыскать и послать на фотканье.
Замечательная новостьОтправил. Сегодня днем. На почте, правда, сказали, что поедет наземным путём - у Казпочты нет авиасообщения с Украиной. Когда доедет - хрен его знает...
Есть еще ХМ1-33, 36 и 31. Так что надо изыскать и послать на фотканье.У меня их нет...
Отправил. Сегодня днем. На почте, правда, сказали, что поедет наземным путём - у Казпочты нет авиасообщения с Украиной. Когда доедет - хрен его знает...
Главное, чтобы доехал) Даже если, как ходоки, пешком) За три года) Но лучше, конечно, не три) Месяцок-два очень неплохо бы, потому что, боюсь, основная задержка будет на этапе фотографирования нашим уважаемым господином Vslav'ом)
Ребят, а скажите мне, не очень понимающему в аппаратных материях.
Вроде бы минимальный набор реверснутых микросхем у нас уже есть.
Какой следующий шаг?
Правильно ли я понимаю, что это - расписать на Verilog всё что реверснуто, то есть все БМК?
И кто это может сделать? чего для этого нехватает?
И второй вопрос - с учётом сложности всех микросхем, включая два процессора и все БМК, плюс какой-то запас может быть ещё на эмуляцию контроллеров НГМД и винчестера, на формирование цифрового видео - в какие из популярных FPGA всё это поместится? например, можно ли будет на тот же MiST FPGA сделать конфигурацию УКНЦ?
Следующий шаг - другие микросхемы..
Конкретно УКНЦ мало кому интересна и ты будешь первый кто сведет это воедино :)
Здесь вообще конкретные вещи мало кому интересны :(
Ребят, а скажите мне, не очень понимающему в аппаратных материях.
Вроде бы минимальный набор реверснутых микросхем у нас уже есть.
Какой следующий шаг?
Правильно ли я понимаю, что это - расписать на Verilog всё что реверснуто, то есть все БМК?
И кто это может сделать? чего для этого нехватает?
И второй вопрос - с учётом сложности всех микросхем, включая два процессора и все БМК, плюс какой-то запас может быть ещё на эмуляцию контроллеров НГМД и винчестера, на формирование цифрового видео - в какие из популярных FPGA всё это поместится? например, можно ли будет на тот же MiST FPGA сделать конфигурацию УКНЦ?
Я мог бы кое-что сделать. Например описать эти м/с на VHDL (с Verilog-ом не дружу).
Но одному туговато. Еще бы парочку энтузиастов.
Следующий шаг - другие микросхемы..
Конкретно УКНЦ мало кому интересна и ты будешь первый кто сведет это воедино :)
Здесь вообще конкретные вещи мало кому интересны :(
Вам это не интересно - ну окей.
Мне бы хотелось получить FPGA-клон УКНЦ.
К тому же на этом форуме "железячников" довольно много. Думаю найдутся желающие.
- - - Updated - - -
Я мог бы кое-что сделать. Например описать эти м/с на VHDL (с Verilog-ом не дружу).
Но одному туговато. Еще бы парочку энтузиастов.
Думаю что имеет смысл использовать тот же язык, что и для описания уже имеющегося реверса ВМ2:
https://github.com/1801BM1/cpu11/tree/master/vm2
Вам это не интересно - ну окей.
Простите, но мне тоже очень это интересно, но просто я уже не первый год наблюдаю за происходящим...
Вот вы например, великий ГУРУ хоть раз поделились со мной "сокровенным"... только подтверждаете то, что я мучительно родил сам.. "в виде трехколе6сного велосипеда"
Честно, не очень понял о чём это.
Оооочень сильный оффтопик (грохну свой пост через пару дней или после прочтения), но Ваша помощь в эмуляции 85-й машинки была бы супер востребованной :)
К сожалению голосовалка о Вашей дальнейшей "точки приложения сил", в сторону некой 16-битной ПК типа МС-0585 ;) похоже не нашла должного отклика :)
Если помните была проблема в лицензии открытых исходников XHomer на базе SIMH Тарика Исани, в данный момент это решается с правообладаетелем. В переписке он не против всех предлагаемых правок (но, тем не менее, пока этого ещё нет в его финальных сорцах).
Да я не против Вас, про другое.. вы кстати тоже не откликаетесь на новые идеи... сидите и смотрите, чтоб не ляпнуть лишнего :)
Ну что нового произошло за последние надцать.. месяцев... (я согласен у вас работы на много месяцев вперед).. но все же.
Хотя бы на то, происходит в соседних темах....
Или я на столько крут., что собрал все платы... .03 (или усраться 04) ... и все, связал свои аж.. две маштны, а что дальше?
Да я не против Вас, про другое.. вы кстати тоже не откликаетесь на новые идеи... сидите и смотрите, чтоб не ляпнуть лишнего :)
Ну что нового произошло за последние надцать.. месяцев... (я согласен у вас работы на много месяцев вперед).. но все же.
Хотя бы на то, происходит в соседних темах....
Или я на столько крут., что собрал все платы... .03 (или усраться 04) ... и все, связал свои аж.. две маштны, а что дальше?
У нас тут пока получается типа чатика, потом поскипаю, но, имхо, Вы не совсем правы в некоторых своих суждениях.
То что Вы кладете на GitHub .. слабо даже для новичка.. к большому сожалению..
То что вы следите не всегда за форумом, наверно связано с вашей большой занятостью..
Но все таки я пишу не первый год.. и реальной поддержки так и не увидел... только .. блин микросхемами и меряются ?)
- - - Добавлено - - -
Вы не совсем правы в некоторых своих суждениях.
Кто из нас?
CodeMaster
12.06.2020, 20:26
Вот вы например, великий ГУРУ хоть раз поделились со мной "сокровенным"...
То что Вы кладете на GitHub .. слабо даже для новичка.. к большому сожалению..
Я типа вообще не в теме, просто слежу как течёт вода работает Dr. Titus, но где-то между этими постами возник когнитивный диссонанс.
Конкретно УКНЦ мало кому интересна
???
Здесь вообще конкретные вещи мало кому интересны
????
кто или что так допекло собрата по форуму, что он откровенную чушь постить начал?
???
кто или что так допекло собрата по форуму, что он откровенную чушь постить начал?
Очень надеюсь, что простое пятничное пиво..
CodeMaster
12.06.2020, 20:29
кто или что так допекло собрата по форуму, что он откровенную чушь постить начал?
Пятница, вечер, S_V_B наверное чуть антистрессового допинга принял ;-)
, но, имхо, Вы не совсем правы в некоторых своих суждениях.
И в чем же я не прав?
тем не менее, самый главный и важный вопрос (в моём понимании) Никита задал
https://zx-pk.ru/threads/30964-revers-inzhiniring-bmk-1515khm1-2.html?p=1067945&viewfull=1#post1067945
Очень надеюсь, что простое пятничное пиво..
Пива не было..., а болтун Хобот, пусть напишет посты где он реально помог :) ладно пусть найдет три поста которые мне помогли :)
И второй вопрос - с учётом сложности всех микросхем, включая два процессора и все БМК, плюс какой-то запас может быть ещё на эмуляцию контроллеров НГМД и винчестера, на формирование цифрового видео - в какие из популярных FPGA всё это поместится? например, можно ли будет на тот же MiST FPGA сделать конфигурацию УКНЦ?
Для УКНЦ есть небольшая проблема - по-хорошему, ему нужна бы двухканальная память - отдельные каналы для ЦП и ПП. Для хорошей ДВК с КЦГД - тоже. На большинстве отладочных плат и проектов типа Reverse-U16 - память одноканальная. Выкрутиться можно, но со снижением скоростных характеристик. Впрочем, родную машинку перекроет все равно в разы.
Если интерес к УКНЦ есть - я бы взялся за реализацию, с консультациями по архитектуре от местных гуру. Самое сложное - время, у меня его сейчас немного свободного, увы.
- - - Добавлено - - -
Оооочень сильный оффтопик (грохну свой пост через пару дней или после прочтения), но Ваша помощь в эмуляции 85-й машинки была бы супер востребованной :)
Пооткрывал уже 1811, но не фотаю. Надо закрыть М4 и ВМ3, 1811 уже пойдет после них. Есть надежда что удастся сделать считывалку ROM и PLA из 1811ВУxx, там под это дело специальная тестовая нанокоманда предусмотрена, так что объемы реверса возможно получится сократить заметно.
Я типа вообще не в теме, просто слежу как течёт вода работает Dr. Titus, но где-то между этими постами возник когнитивный диссонанс.
Ну и следи дальше за доктором Титусом... (эмулятор.. работает раза в два быстрее..., таймер врет (я уже писал об этом).. и вообще плевать Титусу на УКНЦ)....
- - - Добавлено - - -
Я к тому, что для удобства подключил Титусовский эмулятор, автоматом и был неприятно поражен.. что в итоге на реале получилось..
В итоге nzeemin рулит, хотя загрузка через жопу получается.
Очень надеюсь, что простое пятничное пиво..
Ну если надо таким образом расслабляться, то это уже... как минимум странно.
Потому что от хобби - расслабляться не надо, хобби - оно само расслабляет
И вдогонку... адептам типа Хобота..грузиться можно даже с винта (без участия RT-11) вот блин чудо? (я скорее всего так и сделаю... без RT-11, память нужна- Rt11-НЕТ)
- - - Добавлено - - -
Потому что от хобби - расслабляться не надо, хобби - оно само расслабляет
Да бростье сказать - "ХОББИ"..думал чтобы с вами сровнятьсься.. купить рухляди чуток ДВК, а как выяснилось ХУНТА скупает все платы которые появляются за любые деньги.. я не готов с Вами воевать.
(обидно.. я этого говна вынес в 90м.. дофига пока золотокопатели не пришли, ктоб знал:()
ХУНТА скупает все платы
Аха, конечно.
пока золотокопатели не пришли
Уже одна эта фраза многое говорит.
Уже одна эта фраза многое говорит.
Тогда я даже подумать не мог.. что это какой-то эквивалент :( (Хотя были мудаки (начальник ВЦ.. которые по занавес сели))
Ну и следи дальше за доктором Титусом... (эмулятор.. работает раза в два быстрее..., таймер врет (я уже писал об этом).. и вообще плевать Титусу на УКНЦ)....
Эмулятор был написан в 2006 году без знания многих подробностей о чипах и процессоре, и с тех пор ядро принципиально не менялось. Просто подкручивать всякие гайки и тайминги по ходу - это пустое дело. Если переделывать, то заново с учетом всех подробностей о процессоре и чипах.
- - - Добавлено - - -
Точно, плевать на УКНЦ) И чипы я реверсю для папы Карло)
- - - Добавлено - - -
Ребят, а скажите мне, не очень понимающему в аппаратных материях.
Вроде бы минимальный набор реверснутых микросхем у нас уже есть.
Какой следующий шаг?
Правильно ли я понимаю, что это - расписать на Verilog всё что реверснуто, то есть все БМК?
И кто это может сделать? чего для этого нехватает?
Я думаю, что сперва надо привести в человеческий вид реверсы всех чипов, а потом смотреть.
И чипы я реверсю для папы Карло)
Наверно :) Тыж сам сказл.. чото в восмеричной считать неудобно :)...Я тебе уже давно сказал, то в твоем эмуле не так. (что-то с программируемым таймером иле его запуском)
И вдогонку... адептам типа Хобота..грузиться можно даже с винта (без участия RT-11) вот блин чудо? (я скорее всего так и сделаю... без RT-11, память нужна- Rt11-НЕТ)
а что ты нового сообщил?
Группа программистов для издания\поставки ИТО "ИГРУШКА-1" и "ИГРУШКА-2" в своё время так и сделали, причём в 2-ух вариантах :
- для класса УК-НЦ - сетевой вариант
_ для РМП - вариант для отдельной машины
Возможность делать копии была только у спец.варианта пакетов и кол-во возможных копий было ограничено
Всё там очень стильно в одном ключе оформлено, сетевой вариант в архиве отсутствует.
Появилось свободное время, продолжил.
Разобрал примерно 75% схемы. Кому интересно, уже может посмотреть, как реализована палитра и видеовыход. Интересно, что при ресете, все цвета палитры устанавливаются в последовательные значения 0, 1, 2, 3, 4, 5, 6, 7. Достаточно бесполезная инициализация, на мой взгляд, учитывая, что все равно система будет прописывать свои цвета.
- - - Добавлено - - -
Интересно какая такая работа над ошибками? У меня на УКНЦ со 136-й есть глюк с цветом курсора. Он не замещает текущее изображение, а накладывается по ИЛИ, потому черного курсора и не видно.
Заодно и выяснилось, почему этот глюк) Смотрите U36. Цвет курсора действительно накладывается на цвет изображения по OR.
Интересно, что при ресете, все цвета палитры устанавливаются в последовательные значения 0, 1, 2, 3, 4, 5, 6, 7. Достаточно бесполезная инициализация, на мой взгляд, учитывая, что все равно система будет прописывать свои цвета.
Для каких-нибудь ранних тестов без полноценной прошивки вероятно имело смысл.
Для каких-нибудь ранних тестов без полноценной прошивки вероятно имело смысл.
В принципе, схему это особо не усложняет в плане логических элементов, добавляются только дополнительные линии сброса, которых нужно на это дело 32 штуки.
Еще немного поразбирался.
Никаких недокументированных бит в регистрах управления отображением не найдено.
Биты масштаба при инициализации сбрасываются в 0, биты PB, PG, PR - имеют произвольные значения.
Кроме того PB, PG, PR, в отличие от R, G, B, выводятся в инверсном виде.
Так же никаких неизвестных особенностей 128-цветного режима не найдено.
Интересно, что при ресете, все цвета палитры устанавливаются в последовательные значения
Биты масштаба при инициализации сбрасываются в 0, биты PB, PG, PR - имеют произвольные значения.
А как происходит сброс? Знаю, что при включении питания подаётся импульс на вход MO. А при обратном ходе по кадру сброс происходит?
А как происходит сброс? Знаю, что при включении питания подаётся импульс на вход MO. А при обратном ходе по кадру сброс происходит?
Еще немножко не дошел до этого.
Очень интересная и сложная система тактирования.
Пиксель клок для разрешения 640, равен 12.5Мгц,
для разрешения 320 - равен 6.25МГц.
А вот для разрешений 160 и 80 равен 3.125Мгц и 1.5625МГц, сооветветственно, но при этом может приостанавливаться, если CC1 = 1, а MO = 0.
- - - Добавлено - - -
Теперь можно посмотреть схему формирования курсора (текстового и графического), а так же часть схемы тактирования, и схему дополнительных цветов.
Разбираю счетчик точек по горизонтали.
Он очень навороченный в том плане, что распределенный, является как минимум 11-разрядным, причем при этом он является счетчиком с ускоренным переносом, и при этом он явно считает не по кругу, а до какого-то значения. Стоит ошибиться в полярности какого-то сигнала или элемента, и число до которого он считает, окажется неверным)
Разбираю счетчик точек по горизонтали.
Он очень навороченный в том плане, что распределенный, является как минимум 11-разрядным, причем при этом он является счетчиком с ускоренным переносом, и при этом он явно считает не по кругу, а до какого-то значения. Стоит ошибиться в полярности какого-то сигнала или элемента, и число до которого он считает, окажется неверным)
А зачем 11 разрядов? Всего, с учётом обратного хода по строке, длина строки составляет 800 точек, из них видимых только 640. Вроде достаточно 10 разрядов.
Стоит ошибиться в полярности какого-то сигнала или элемента, и число до которого он считает, окажется неверным)
Это потому что гранаты у тебя не той системы. Когда я реверсил ВП1-037, то просто построил автоматически модель (сгенерировал Верилог из списка цепей PCAD своей утилитой), потом написал простенький тестбенч - и вся растактовка на диаграммах вылезла cама. Не бережете Вы себя, Юрий Бенедиктович, ой не бережете :)
А зачем 11 разрядов? Всего, с учётом обратного хода по строке, длина строки составляет 800 точек, из них видимых только 640. Вроде достаточно 10 разрядов.
Пока еще не знаю) Возможно там и 12 разрядов.
Так же непонятно, почему счетчик для позиции курсора в знакоместе (0..7) в графическом режиме курсора, сделан с учетом горизонтального разрешения, т.е. зависит от двух бит ширины точки по горизонтали, а счетчик знакомест устроен иначе, и имеет зависимость от горизонтального разрешения только в младших трех своих разрядах, а старшие 4 разряда почему-то от горизонтального разрешения не зависят. Но это предварительно.
- - - Добавлено - - -
Не бережете Вы себя, Юрий Бенедиктович, ой не бережете
Не владеем мы верилогами, не обучены)
Мне удобно воспринимать схему. Если она хорошо составлена, то любой человек глядя на нее сразу поймет, как и что работает. Для этого я ее таковой и рисую. А все сложности преобразования оставляем за кадром.
LeoN65816
17.06.2020, 19:16
Для УКНЦ есть небольшая проблема - по-хорошему, ему нужна бы двухканальная память - отдельные каналы для ЦП и ПП.
Двухканальная или двухпортовая?
Двухканальная или двухпортовая?
Двухканальная. Фактически надо два независимых контроллера памяти, со своими отдельными микросхемами. Двухпортовая это частный случай, когда два (или более) каналов обращаются с тем же самым данным.
Так же непонятно, почему счетчик для позиции курсора в знакоместе (0..7) в графическом режиме курсора, сделан с учетом горизонтального разрешения, т.е. зависит от двух бит ширины точки по горизонтали, а счетчик знакомест устроен иначе, и имеет зависимость от горизонтального разрешения только в младших трех своих разрядах, а старшие 4 разряда почему-то от горизонтального разрешения не зависят. Но это предварительно.
Координата курсора на экране (знакоместо) указывается относительно разрешения 80 символов в строке. Т.е. для разрешения 640 точек (80 символов) это будут значения 0, 1, 2, 3 и т.д. При разрешении 320 точек (40 символов) младший бит не учитывается, соответственно будут значения 0, 2, 4, 6 и т.д. При разрешении 160 точек (20 символов) уже не учитываются два младших бита, т.е. значения будут 0, 4, 8, 12 и т.д. Ну и соответственно при разрешении 80 точек (10 символов) не учитываются три младших бита, координаты будут 0, 8, 16, 24 и т.д.
Ну и соответственно при разрешении 80 точек (10 символов) не учитываются три младших бита, координаты будут 0, 8, 16, 24 и т.д.
Да, по схеме видно, что младшие 3 бита в зависимости от разрешения маскируются.
LeoN65816
17.06.2020, 20:01
Фактически надо два независимых контроллера памяти, со своими отдельными микросхемами.
Ага, вот теперь понятно, что ты имел ввиду. Просто двухканальность в привычном для нас понимании из мира PC - это всего лишь удвоенная ширина шины данных памяти. Ты же говоришь о двух независимых банках памяти.
Тогда можно для ЦП использовать основную память девборды, а для ПП использовать внутреннюю память FPGA (её объёма многих FPGA вполне достаточно для ПП) в двухпортовом режиме, потому как там ещё и видеоконтроллер расшаривает её для видеовыхлопа.
Так же непонятно, почему счетчик для позиции курсора в знакоместе (0..7) в графическом режиме курсора, сделан с учетом горизонтального разрешения, т.е. зависит от двух бит ширины точки по горизонтали
А в каком плане зависят? Вроде бы при смене разрешения меняется количество точек и соответственно знакомест в строке, но ширина знакоместа всегда равна восьми точкам.
Ага, вот теперь понятно, что ты имел ввиду. Просто двухканальность в привычном для нас понимании из мира PC - это всего лишь удвоенная ширина шины данных памяти.
Нет, как раз в PC два канала - это именно тоже два канала, а не удвоенная ширина. Каналы независимые, свои шины адреса/управления/данных. И работают независимо по фазе.
Alex_K, про курсор УК-НЦ , откуда берётся глюк, когда позиция курсора левый верхний угол экрана и запускается графика, курсор вдруг бац и начинает отображаться во всю высоту экрана мигающим столбиком ?
Alex_K, про курсор УК-НЦ , откуда берётся глюк, когда позиция курсора левый верхний угол экрана и запускается графика, курсор вдруг бац и начинает отображаться во всю высоту экрана мигающим столбиком ?
Не видел такого глюка. Можно конкретный пример.
А так курсор включается и выключается, а точнее переключается, установкой младшего бита в списке видеострок. На одной строке включили, на другой выключили.
Не видел такого глюка.
не знаю как его воспроизвести...это реально на любой живой машинке случается происходит, выход-прекращение работы игры иногда помогает иногда нет, курсор так и остаётся столбиком в один символ и во всю высоту...в эмуляторе кстати то же самое )
А в каком плане зависят? Вроде бы при смене разрешения меняется количество точек и соответственно знакомест в строке, но ширина знакоместа всегда равна восьми точкам.
Все так.
- - - Добавлено - - -
не знаю как его воспроизвести...это реально на любой живой машинке случается происходит, выход-прекращение работы игры иногда помогает иногда нет, курсор так и остаётся столбиком в один символ и во всю высоту...в эмуляторе кстати то же самое )
Это скорее программный глюк, если и на эмуляторах тоже.
Это скорее программный глюк, если и на эмуляторах тоже.
ок! когда "поймаю" в очередной раз сделаю скриншот, графическую твердокопию экрана и дамп ОЗУ ПП и ЦП и видео ОЗУ ))))
Кто-нибудь видел, как на реале выглядит графический курсор? Судя по всему это должна быть вертикальная полоска (а не знакоместо), шириной 1 пиксель для выбранного разрешения.
Кто-нибудь видел, как на реале выглядит графический курсор? Судя по всему это должна быть вертикальная полоска (а не знакоместо), шириной 1 пиксель для выбранного разрешения.
Всё так и есть. 0 - слева, 7 - справа. Можно посмотреть, если записать в ячейку 022746. Формат её младшего байта соответствует формату младшего байта первого слова регистра управления отображением. Ячейка 022746 является частью таблицы видеопараметров экрана пользователя. Т.е. если в режиме УСТАНОВКА выйти в отладчик ПП и изменить ячейку, то при возврате на экран пользователя мы увидим изменения.
Всё так и есть. 0 - слева, 7 - справа. Можно посмотреть, если записать в ячейку 022746.
Просто проверить на реале не могу пока что.
Интересно, что я не встречал ни одной программы, которая такой курсор использовала. Были ли они?
Просто проверить на реале не могу пока что.
Интересно, что я не встречал ни одной программы, которая такой курсор использовала. Были ли они?
Ну во всяком случае в обоих эмуляторах это реализовано - и в UKNCBTL, и в EmuStudio. Таких программ я не видел.
Интересно еще узнать у реальщиков, как накладывается курсор в 036 прошивке. Тоже по OR, как в 136, или же иначе.
Интересно еще узнать у реальщиков, как накладывается курсор в 036 прошивке. Тоже по OR, как в 136, или же иначе.
В 1515ХМ1-036 курсор полностью замещает собой изображение.
В 1515ХМ1-036 курсор полностью замещает собой изображение.
Интересно, изменение модели наложения курсора может ли быть желанием чего-то улучшить, либо же скорее ляп?
Интересно, изменение модели наложения курсора может ли быть желанием чего-то улучшить, либо же скорее ляп?
А вот это мы уже наверное никогда не узнаем. Я сначала думал, что в -136 наверное есть неописанные биты в регистре отображения, чтобы делать режим наложения курсора, типа MOV, AND, XOR, OR. Но установка неиспользуемых битов ни на что не повлияла. Да и реверс-инжиниринг подтвердил, что их нет.
А вот это мы уже наверное никогда не узнаем.
Поэтому мы можем порассуждать логически. Например, есть ли какая-то польза от такого курсора? Например, то, что он будет не замещать какой-то символ, а выделять его другим цветом, мигая.
Поэтому мы можем порассуждать логически. Например, есть ли какая-то польза от такого курсора? Например, то, что он будет не замещать какой-то символ, а выделять его другим цветом, мигая.
Логически чёрный курсор в этом случае мы никогда не увидим, так что таким образом его можно отключать. А в курсоре промежуточных цветов (не чёрный и не белый) мы всегда будем видеть белый символ.
- - - Добавлено - - -
Да, надо реверс-инжиниринг 1515ХМ1-036, чем она отличается от -136.
Ну и аппаратно наложение по ИЛИ наверное легче сделать, чем мультиплексор. Возможно что-то в -136 улучшили и мультиплексоров уже не осталось, пришлось делать по ИЛИ.
Да, надо реверс-инжиниринг 1515ХМ1-036, чем она отличается от -136.
Тут вопрос к владельцам 036, почему они не спешат слать на фотографирование товарищу Vslav'у.
Тут вопрос к владельцам 036, почему они не спешат слать на фотографирование товарищу Vslav'у.
У меня есть, кажется, 036. Это она?
https://pic.maxiol.com/thumbs2/1592493593.1845267016.20200618181624.jpg (https://pic.maxiol.com/?v=1592493593.1845267016.20200618181624.jpg&dp=2)
Только я не знаю, как отослать на Украину. И можно ли?
У меня есть, кажется, 036. Это она?
А что там еще есть из нереверсенных 1515?
Напомню, что отреверсены: ХМ2-001, ХМ2-003, ХМ1-136, ХМ1-032.
Нужно: ХМ1-002 (вроде отослали уже), ХМ1-036 (выше на фотке), ХМ1-031 (обязательно преобязательно), ХМ1-033 (раритетная УКНЦ, осеня надо, насяльнике), ХМ1-039.
Вот что у меня есть.
https://pic.maxiol.com/thumbs2/1592537233.1845267016.20200619062448.jpg (https://pic.maxiol.com/?v=1592537233.1845267016.20200619062448.jpg&dp=2)
Все по одной.
Так что, остальные тоже отослать Vslav-у?
Все по одной.
Так что, остальные тоже отослать @Vslav-у?
Из них нужен 036, 039 и 031.
И останется уговорить кого-нить выковырять из раритетной УКНЦ чип 033.
Интересно, что CAS2 и CAS1 полностью идентичны.
Те же самые данные выводятся и на CAS0, но этот выход переводится в Z-состояние по другому алгоритму.
Интересно, что CAS2 и CAS1 полностью идентичны.
Те же самые данные выводятся и на CAS0, но этот выход переводится в Z-состояние по другому алгоритму.
Ну CAS2 и CAS1 - это выбор столбцов памяти ЦП. Память 16-разрядная, потому и выбор младшего и старшего байта. CAS0 - это выбор памяти ПП. Память ПП видеоконтроллер только читает. А вот память ЦП может быть прочитана и записана по запросу от контроллера ОЗУ ПП (ХМ1-032 или ХМ2-002). Соответственно при запросе на память ЦП память ПП не используется, перевод в Z-состояние. А вот CAS2 и CAS1, да, вероятно полностью идентичны. Даже при байтовой записи в контроллере ПП, сам он передаёт полное 16-разрядное слово для видеоконтроллера по запросу.
CAS2 и CAS1, да, вероятно полностью идентичны
Полностью. Странно, что для них сделали отдельные выходы. Может просто для повышения нагрузочной способности, чтобы на каждый выход пришлось по половине корпусов.
Полностью. Странно, что для них сделали отдельные выходы. Может просто для повышения нагрузочной способности, чтобы на каждый выход пришлось по половине корпусов.
Ну их нельзя замыкать. При доступе в ОЗУ со стороны ЦП через 1515ХМ1-039 (1515ХМ2-003) там можно отдельно записывать и младший и старший байт. Если байт не записывается, то на него не подаётся соответствующий CAS. А если бы CAS2 и CAS1 были бы замкнуты, то и байтовой записи не было бы.
Из них нужен 036, 039 и 031.
Отправил все по одной. Больше не было.
А как происходит сброс? Знаю, что при включении питания подаётся импульс на вход MO. А при обратном ходе по кадру сброс происходит?
Сброс и инициализация регистров начальными значениями происходит по любому из следующих условий:
1. EVNT (событие таймера 50Гц)
2. CC0 = 1, и MO = 0.
- - - Добавлено - - -
Горизонтальные и вертикальные счетчики инициализируются только по второму событию (CC0 = 1, и MO = 0). Оно и понятно, т.к. первое событие (EVNT) генерируется самими счетчиками.
Горизонтальные и вертикальные счетчики инициализируются
А как они инициализируются? Обнуляются или какая-то константа загружается?
А как они инициализируются? Обнуляются или какая-то константа загружается?
Вертикальный обнуляется, а в горизонтальный загружается 0x280 (640 в десятичном). Причем, самый младший бит не инициализируется вообще.
Вертикальный обнуляется, а в горизонтальный загружается 0x280 (640 в десятичном). Причем, самый младший бит не инициализируется вообще.
А размерности счетчиков какие? Интересно, а как горизонтальный счетчик считает обратный ход по строке? Ведь это 160 точек. И с чем сравнивается вертикальный счетчик для обнуления?
А размерности счетчиков какие? Интересно, а как горизонтальный счетчик считает обратный ход по строке? Ведь это 160 точек. И с чем сравнивается вертикальный счетчик для обнуления?
Я еще не разрисовал их до конца, т.к. из-за сложной конструкции (ускоренный перенос, разброс логики по куче элементов, комплексная система сравнения), они еще не приняли финальный вид.
Обратный ход он считает продолжая считать после 640 до 799.
Обратный ход он считает продолжая считать после 640 до 799.
Так в каком направлении он считает, если в него загружается 640?
Так в каком направлении он считает, если в него загружается 640?
Только вперед) В плюс.
Только вперед) В плюс.
Тогда непонятно. В каком диапазоне обратный ход по строке, а в каком видимая часть в 640 точек?
Тогда непонятно. В каком диапазоне обратный ход по строке, а в каком видимая часть в 640 точек?
От 640 до 799 - обратный ход, а от 0 до 640 видимый.
А константы вертикального счётчика известны?
А константы вертикального счётчика известны?
Пока что разбираюсь с этим. Как станет известно, скажу.
Вход MO (сброс при начальном старте компьютера, генерируемый ГФ24), на самом деле имеет активный уровень низкий, поэтому на схеме я его изменю с MO на /MO.
- - - Добавлено - - -
Кстати, у CC0 и CC1 тоже, похоже, активным стоит считать низкий уровень.
При сбросе ХМ1-032, на CC0 - '1'.
'0' появляется лишь кратковременно при записи в раритетный регистр, либо же при записи в регистр данных планов 1 и 2.
Кроме того, сброс счетчиков ХМ-136 происходит только во время ресета по MO, при этом необходимо, чтобы на CC0 была '1', иначе сброса не произойдет. Непонятно, зачем это сделано вообще.
- - - Добавлено - - -
Похоже, CC0 = '0' в комбинации с активным сигналом сброса по линии МО используется для каких-то тестовых стендовых целей. Потому что, при этой комбинации:
1. Не произойдет начального сброса счетчиков - а это произвольная какофония в счете.
2. Вертикальный счетчик будет тактироваться не от переполнения горизонтального, а частотой 6.25МГц.
- - - Добавлено - - -
Это к слову о том, что им не хватало элементов на нормальное наложение курсора) Т.е. на такие вот тесты хватало, а на курсор не хватало. Не верю! )
Это к слову о том, что им не хватало элементов на нормальное наложение курсора) Т.е. на такие вот тесты хватало, а на курсор не хватало. Не верю! )
Вот будет вскрыт -036, тогда можно увидеть отличия. Но в -036 для вывода курсора вероятно стоит мультиплексор, либо вывод изображения, либо вывод курсора.
- - - Добавлено - - -
'0' появляется лишь кратковременно при записи в раритетный регистр
Вот это интересно. Видел это в -032, но запись в этот регистр воздействует на оба вывода CC0 и CC1. Интересно, не передавал ли -032 таким образом информацию для старого видеоконтроллера -033?
Вот это интересно. Видел это в -032, но запись в этот регистр воздействует на оба вывода CC0 и CC1. Интересно, не передавал ли -032 таким образом информацию для старого видеоконтроллера -033?
Скорее всего эти выводы в этом участвовали. Но сейчас они участвуют вообще в транзакциях между 032 и 136.
Скорее всего эти выводы в этом участвовали. Но сейчас они участвуют вообще в транзакциях между 032 и 136.
Да, через выводы CC0, CC1, RQ производится обмен между -032 и -036(-136). Таким образом -032 получает и передаёт информацию в ОЗУ ЦП. Об этом описано в ПК УКНЦ №1/95. При записи в РА 0177010 адрес передаётся в видеоконтроллер по линиям D7-D0, A7-A0 при активном низком RQ и неактивных высоких CC0, CC1. Далее по запросу RQ, CC1 читаются данные планов 1 и 2 по линиям A7-A0, D7-D0 в регистр РД 0177014. Соответственно при чтении регистра 0177014 со стороны процессора, обращения к ОЗУ не производится. Ну а т.к. при записи РА 0177010 он уже был передан видеоконтроллеру, то при записи в РД 0177014 только даётся запрос по линиям RQ, CC0 для записи данных в ОЗУ ЦП.
- - - Добавлено - - -
А вот при записи в раритетные регистры 0177030-0177052 в активном состоянии будут все выводы RQ, CC0, CC1. Сам адрес передается по линиям A7-A0, а данные по линиям D7-D0. Вот это уже становится интересным. Вероятно -036, как и -136, не обрабатывают эту комбинацию. А вот -033 скорее всего обрабатывало. Вот таким образом и передавалась информация в видеоконтроллер.
активном состоянии будут все выводы RQ, CC0, CC1
Т.е. фактически мы можем обозначить все эти выводы инверсными /RQ, /CC0, /CC1, т.к. у всех них активный уровень низкий?
Т.е. фактически мы можем обозначить все эти выводы инверсными /RQ, /CC0, /CC1, т.к. у всех них активный уровень низкий?
Ну как тут сказать... Да, активным является низкий уровень, но ведь логика по данным линиям не инверсная.
но ведь логика по данным линиям не инверсная.
В каком смысле?
Если у сигнала активным является низкий уровень, значит он обозначается как инверсный. Все просто.
В каком смысле?
Если у сигнала активным является низкий уровень, значит он обозначается как инверсный. Все просто.
Сигнал, да. А логика у -032, судя по оптимизированной схеме, не инверсная.
Сигнал, да. А логика у -032, судя по оптимизированной схеме, не инверсная.
Я не понимаю формулировки 'логика не инверсная'. Это относится к логики принятия решения или же к типу применяемых логических элементов?
Я не понимаю формулировки 'логика не инверсная'. Это относится к логики принятия решения или же к типу применяемых логических элементов?
К типу применяемых логических элементов.
К типу применяемых логических элементов.
Это не имеет значение, т.к. они прошли через оптимизацию)
Появились подробности точной работы горизонтального счетчика:
Счетчик 10-разрядный. Плюс 11 разряд - это HBLANK (горизонтальный интервал гашения).
При сбросе счетчик устанавливается в значение 0x280 (640), а HBLANK в '1'.
Далее идет счет от 640 до 799, после чего счетчик обнуляется, и также обнуляется разряд HBLANK.
Далее идет счет от 0 до 639, и все повторяется по кругу.
Счетчик 10-разрядный. Плюс 11 разряд - это HBLANK (горизонтальный интервал гашения).
При сбросе счетчик устанавливается в значение 0x280 (640), а HBLANK в '1'.
Далее идет счет от 640 до 799, после чего счетчик обнуляется, и также обнуляется разряд HBLANK.
Далее идет счет от 0 до 639, и все повторяется по кругу.
Обалдеть! Это значит, что есть как минимум один компаратор для 799 или 800. А для 640 компаратор есть? Для установки HBLANK.
Для интересующихся выкладываю временную схему.
На ней уже можно посмотреть оптимизированный горизонтальный счетчик. Вертикальный пока смотреть на надо, он в виде набросков.
Много еще чего можно посмотреть. Я бы сказал, что процентов 85 уже оптимизировано и подписано понятно.
- - - Добавлено - - -
Обалдеть! Это значит, что есть как минимум один компаратор для 799 или 800. А для 640 компаратор есть? Для установки HBLANK.
Полноразрядных компараторов там нет, но используются части схемы ускоренного переноса в том числе для определения перехода к значению 640, и для определения перехода к значению 800.
Разряды счетчика такие:
D0 - /PCLC_2
D1 - /PCLC_4
D2 - /PCLC_8
D3 - /PCLC_16
D4 - /PCLC_32
D5 - /PCLC_64
D6 - /PCLC_128
D7 - /PCLC_256
D8 - /PCLC_512
D9 - /PCLC_1024
Обалдеть! Это значит, что есть как минимум один компаратор для 799 или 800. А для 640 компаратор есть? Для установки HBLANK.
Ну, для счёта до 780 достаточно сравнивать 4 бита при асинхронном сбросе счётчиков - сам так делаю у себя.
А для 640 - ещё проще, всего-то 3 бита сравнивать.
Разгадана загадка (хотя загадки никакой и не было) вертикального счетчика линий.
Он тоже с ускоренным переносом, и весь такой запутанный и навороченный со сложной логикой работы (пока его не приведешь в понятный человеку вид).
У него есть три зоны счета. От 0..255, затем от 256 до 287, затем о 288 до 311.
Первые две зоны можно условно обьединить в общую от 0..287. А во время счета от 288 до 311 генерируется сигнал VBlank.
В общем, никаких секретных строк за пределами известного нам экрана (288 линий в высоту) нет.
У него есть три зоны счета. От 0..255, затем от 256 до 287, затем о 288 до 311.
Первые две зоны можно условно обьединить в общую от 0..287. А во время счета от 288 до 311 генерируется сигнал VBlank.
В общем, никаких секретных строк за пределами известного нам экрана (288 линий в высоту) нет.
Ну почему нету. Есть! На обратный ход по кадру, как и надо, приходится 24 линии. Здесь всё нормально. Но почему при чтении таблицы видеострок из ОЗУ не отображаются только первых девятнадцать видеострок, а не двадцать четыре? Из-за этого на видеотюнерах не видно пять верхних строк.
Соответственно вопрос. В какой момент начинается сканирование таблицы видеострок, т.е. чтение с ячейки 0270? Понятное дело, что читать он её будет во время обратного хода по строке, но на строке с каким номером?
Ну почему нету. Есть! На обратный ход по кадру, как и надо, приходится 24 линии. Здесь всё нормально. Но почему при чтении таблицы видеострок из ОЗУ не отображаются только первых девятнадцать видеострок, а не двадцать четыре? Из-за этого на видеотюнерах не видно пять верхних строк.
Инициализация регистров, в том числе указателя на начало таблицы строк, происходит по событию EVNT.
А одно из его условий, это число 292 в счетчике строк. А это как раз 4-я линия VBLANK.
- - - Добавлено - - -
Чем отображение через видеотюнер отличается от изображения на обычном мониторе?
- - - Добавлено - - -
Еще точнее будет так:
1. Во время строк 291, 292, 293, генерируется некий сигнал, который подмешивается по XOR предположительно к сигналу HBLANK, и выводится все это на VSYN.
2. Во время строки 292, и во время горизонтальной позиции 0..511 формируется сигнал EVNT (таймер 50Гц), по которому инициализируются все регистры.
Ну и точная частота кадровой развертки - 50,080128205128205128205128205128Гц.
А частота строчной развертки - 15625Гц.
- - - Добавлено - - -
Теперь подробнее о VSYN:
1. Во время всех строк, кроме 291, 292, 293, на этом выводе формируется импульс горизонтальной синхронизации начиная с горизонтальной позиции 673, и выключается в позиции 737 (как раз 5.12мкс, как положено по стандарту).
2. Во время строк 291, 292, 293, на этом выводе формируется импульс вертикальной синхронизации, на который по XOR накладываются зачем-то два импульса горизонтальной синхронизации - первый включается в горизонтальной позиции 161, а выключается в позиции 225. А второй включается в позиции 673, и выключается в позиции 737.
Второе условие выглядит странновато, поэтому его надо еще раз будет перепроверить.
- - - Добавлено - - -
Не путать внутренние сигналы HBLANK и VBLANK, с внешними, подающимися на выход VSYN.
Выборка элементов из таблицы строк происходит во время позиции горизонтального счетчика 704..767 (64 такта пиксельклока).
- - - Добавлено - - -
Эти 64 такта раскладываются на 8 фаз по 8 тактов, из которых:
Для 4-хсловного элемента списка:
Первые 4 фазы, если загружается регистр управления отображением:
F0: Загружается младшая часть регистра CUR_CON (1-е слово регистра управления отображением)
F1: Загружается старшая часть регистра CUR_CON (1-е слово регистра управления отображением)
F2: Загружается младшая часть регистра DISP_CON (2-е слово регистра управления отображением)
F3: Пустой цикл, загрузка идет в никуда
Первые 4 фазы, если загружается регистр управления цветом:
F0: Загружается младшая часть регистра COL_CON_1 (1-е слово регистра управления цветом)
F1: Загружается старшая часть регистра COL_CON_1 (1-е слово регистра управления цветом)
F2: Загружается младшая часть регистра COL_CON_2 (2-е слово регистра управления цветом)
F3: Загружается старшая часть регистра COL_CON_2 (2-е слово регистра управления цветом)
Последующие 4 фазы:
F4: Загружается младшая часть регистра LINE_ADR (регистр адреса начала строки)
F5: Загружается старшая часть регистра LINE_ADR (регистр адреса начала строки)
F6: Загружается младшая часть регистра ENTRY_ADR (регистр адреса следующего элемента списка)
F7: Загружается старшая часть регистра ENTRY_ADR (регистр адреса следующего элемента списка)
Для 2-хсловного элемента списка все тоже самое, за исключением того, что в первые 4 фазы загрузка из памяти происходит в никуда.
Чем отображение через видеотюнер отличается от изображения на обычном мониторе?
ТВ-тюнер анализирует видеосигнал, и на основе этого строит изображение. Соответственно с началом обратного хода по кадру он должен отсчитать 24 видеостроки, а следующие выводить. У меня ТВ-тюнер Beholder, он не выводит верхние четыре-пять строк. Такая же ситуация и у других форумчан, ТВ-тюнеры могут быть другими. В Beholder есть параметр синхронизации кадров - нормальный трекинг, быстрый трекинг и нет синхронизации. При отсутствии синхронизации программа ТВ-тюнера не следит за сигналом обратного хода по кадру, а просто выводит в двух полукадрах 576 линий из 625 линий. В этом случае возможно, что наверху нижняя часть кадра, а внизу - верхняя часть кадра, между частями - чёрный фон. Но изображение стоит, т.к. в двух полукадрах 625 линий. А в УКНЦ в двух полукадрах 624 линии, потому изображение медленно плывёт вверх. В плывущем изображении соответственно всё выводится.
Но изображение стоит, т.к. в двух полукадрах 625 линий. А в УКНЦ в двух полукадрах 624 линии
Так сделано в большинстве видеорежимов для домашних компьютеров - отсутствие интерлейса (четное и нечетное поля одинаковые).
Для 2-хсловного элемента списка все тоже самое, за исключением того, что в первые 4 фазы загрузка из памяти происходит в никуда. Т.е. два раза повторяется загрузка адреса начала строки, и адреса следующего элемента списка, но первый раз данные нигде не остаются.
А вот это странно. Если загрузили адрес списка, то этот адрес для чтения элементов должен инкрементироваться. А тут возникает, что загрузили адрес, он вхолостую прочитал четыре байта, а потом адрес как-то уменьшился на четыре и уже читаются снова следующие четыре байта.
А вот это странно. Если загрузили адрес списка, то этот адрес для чтения элементов должен инкрементироваться. А тут возникает, что загрузили адрес, он вхолостую прочитал четыре байта, а потом адрес как-то уменьшился на четыре и уже читаются снова следующие четыре байта.
Адрес не инкрементируется. На младшие три бита старшего байта адреса всегда выдаются 3, 4 и 5 (если элемент двухсловный) биты горизонтального счетчика. А на старшие 5 бит выдается содержимое регистра ENTRY_ADR. Таким образом, для чтения 4-словного элемента (8 байт) младшие три бита будут прокручены 0, 1, 2, 3, 4, 5, 6, 7.
А для чтения 2-словного элемента (4 байта (не используются) + 4 байта) младшие два бита будут прокручены 0, 1, 2, 3, 0, 1, 2, 3, а в третьем бите будет соответствующий бит адреса из регистра ENTRY_ADR.
- - - Добавлено - - -
Меня больше смущает двойной строчный импульс во время VBLANK. Ошибки вроде нет, но непонятно, зачем он такой)
- - - Добавлено - - -
Также интересно, что сигналы PSG и PSC абсолютно синхронны. Активный уровень (высокий), когда на младших 3-х битах горизонтального счетчика значения 7, 0, 1, 2, а низкий уровень, когда на младших 3-х битах горизонтального счетчика значения 3, 4, 5, 6.
Причем, PSG ничем не маскируется, а PSC может быть замаскирован неким запросом к памяти CPU(?) по линиям RQ, CC0, CC1.
Также интересно, что сигналы PSG и PSC абсолютно синхронны. Активный уровень (высокий), когда на младших 3-х битах горизонтального счетчика значения 7, 0, 1, 2, а низкий уровень, когда на младших 3-х битах горизонтального счетчика значения 3, 4, 5, 6.
Причем, PSG ничем не маскируется, а PSC может быть замаскирован неким запросом к памяти CPU(?) по линиям RQ, CC0, CC1.
Сигналы PSG и PSC - это сигналы арбитра доступа к ОЗУ контроллерам ОЗУ ЦП и ПП. А PSC маскируется, когда контроллер ОЗУ ПП загружает значение в РА 0177010. После загрузки адреса контроллер ПП по запросам по линиям RQ, CC0, CC1 передаёт адрес видеоконтроллеру. Видеоконтроллер, получив адрес, читает по данному адресу ОЗУ ЦП. В этот момент и маскируется сигнал PSC.
Всё описано в журнале ПК УКНЦ №1/95.
Сигналы PSG и PSC - это сигналы арбитра доступа к ОЗУ контроллерам ОЗУ ЦП и ПП.
Только, наверное, наоборот - PSG - это доступ к ОЗУ ПП, а PSC - к ОЗУ ЦП.
- - - Добавлено - - -
Всё описано в журнале ПК УКНЦ №1/95.
Где скачать журнал?
Меня больше смущает двойной строчный импульс во время VBLANK. Ошибки вроде нет, но непонятно, зачем он такой)
В смысле "с удвоенной частотой" ?
У меня как всегда "склероз" - нет книжки под рукой. Сиё часом сделано не "сдвига" полей видеокадра по вертикали ? другими словами чтоб строки (чёт нечет) физически чередовались по вертикали. По хорошему надо смотреть стандарт на видеосигнал.
В смысле "с удвоенной частотой" ?
Не с удвоенной, а просто два импульса, в начале строки и в конце. Но это, повторюсь, если я не ошибся в схеме, но пока что ошибки не нахожу.
Нет, не думаю, что это сделано для сдвига, он делается иначе. И интерлейса на УКНЦ у нас нет)
Где скачать журнал?
Да как обычно - на нафиг никому не нужном и не интересном сайте УКНЦ & PDP-11 (http://uknc.narod.ru/DOC/index_old.htm)
Где скачать журнал?
Всему поможет Яндекс с Гуглом. Смотрите и качайте (http://oldpc.su/lib/magaz/pcuknc/).
Всему поможет Яндекс с Гуглом. Смотрите и качайте.
Очень полезный журнал. Благодаря ему, стало понятно, что я расшифровал схему формирования видеосигнала правильно)
https://pic.maxiol.com/images2/1593117638.531439263.01.png
Тут все видно, что после 288 линий экрана идут 3 пустые строки (строчный синхроимпульс отрицательный), затем идут 3 строки кадрового синхроимпульса, во время которого идут инверсные строчные синхроимпульсы, как мне видится, все же удвоенной частоты. Ну а затем опять 18 строк пустых. Всего 24 строки VBLANK. Все тайминги определил правильно, все строки правильно. Ура) Теперь надо найти стандарт на сихнросмесь, чтобы понять, зачем во время кадрового синхроимпульса, строчные инверсные и удвоенные.
Теперь надо найти стандарт на сихнросмесь, чтобы понять, зачем во время кадрового синхроимпульса, строчные инверсные и удвоенные.
Возможно, это уравнивающие врезки.
Да, посмотрел свои скриншоты с ТВ-тюнера. Насчёт пяти строк погорячился. У меня режет две верхние. А также слева и справа есть дополнительное место.
Возможно, это уравнивающие врезки.
Что это есть такое и где про них почитать?
- - - Добавлено - - -
Да, посмотрел свои скриншоты с ТВ-тюнера. Насчёт пяти строк погорячился. У меня режет две верхние. А также слева и справа есть дополнительное место.
Ну вот на сколько строк запаздывает кадровых синхроимпульс (на 3), столько строк, видимо, тюнер и режет.
- - - Добавлено - - -
Да, через выводы CC0, CC1, RQ производится обмен между -032 и -036(-136). Таким образом -032 получает и передаёт информацию в ОЗУ ЦП. Об этом описано в ПК УКНЦ №1/95. При записи в РА 0177010 адрес передаётся в видеоконтроллер по линиям D7-D0, A7-A0 при активном низком RQ и неактивных высоких CC0, CC1. Далее по запросу RQ, CC1 читаются данные планов 1 и 2 по линиям A7-A0, D7-D0 в регистр РД 0177014. Соответственно при чтении регистра 0177014 со стороны процессора, обращения к ОЗУ не производится. Ну а т.к. при записи РА 0177010 он уже был передан видеоконтроллеру, то при записи в РД 0177014 только даётся запрос по линиям RQ, CC0 для записи данных в ОЗУ ЦП.
- - - Добавлено - - -
А вот при записи в раритетные регистры 0177030-0177052 в активном состоянии будут все выводы RQ, CC0, CC1. Сам адрес передается по линиям A7-A0, а данные по линиям D7-D0. Вот это уже становится интересным. Вероятно -036, как и -136, не обрабатывают эту комбинацию. А вот -033 скорее всего обрабатывало. Вот таким образом и передавалась информация в видеоконтроллер.
ХМ1-136 обрабатывает несколько комбинаций RQ, CC0, CC1.
А именно (активным считаем низкий уровень).
1) RQ - активен, CC0, CC1 - произвольны. По данному условию мультиплексоры переводятся в состояние, при котором данные с AG (старший байт) и DG (младший байт) готовы защелкнуться в буферном регистре для последующего вывода на DC.
2) RQ - активен, CC0 - неактивен, CC1 - активен
3) RQ - активен, CC0 - активен, CC1 - неактивен
4) RQ - активен, CC0 - неактивен, CC1 - неактивен.
5) CC0 - активен во время сброса по MO (тестовый режим для испытательного стенда).
Что это есть такое и где про них почитать?Это для чересстрочной развертки. На четном полукадре начало кадрового синхроимпульса совпадает с началом строки, на нечетном кадровый СИ начинается посередине строки. Старинные примитивные ламповые схемы синхронизации и генерации кадров от этого вели себя не вполне адекватно и, чтобы закрыть проблему, в стандарт ввели уравнивающие импульсы двойной строчной частоты перед кадровым СИ. В нечетном полукадре их 3, в четном - 4. Если не пользоваться чересстрочной разверткой, они, в общем-то, необязательны.
И вообще, в компьютерных видеоадаптерах с телевизионным стандартом обращаются достаточно вольно. Допустим, во время передачи кадрового СИ положено передавать строчные СИ, как писали в старых учебниках, чтобы частота задающего генератора строчной развертки, предоставленного самому себе, не уползла за время кадрового СМ. Тем не менее, проектировщики КЦГД на это наплевали, А что: микросхема 174ХА11, стоящая в штатных мониторах ДВК (6105, 6106) воспринимает такую синхронизацию вполне нормально. Когда же я попытался подать видеосигнал с КЦГД на монитор от дисплея ВТА 2000-15М, проблема вылезла в полный рост - за время ОХК частота строчного генератора заметно уползала и верхние строки были перекошены - курсив своего рода, потихоньку выправляясь по кадру, уже 5-я или 7-я строки были нормальными. Я эту проблему так и не решил. Собирался прицепить туда ту самую 174ХА11, еще что-то прикидывал, но руки так и не дошли.
в стандарт ввели уравнивающие импульсы двойной строчной частоты перед кадровым СИ. В нечетном полукадре их 3, в четном - 4. Если не пользоваться чересстрочной разверткой, они, в общем-то, необязательны.
Отлично. Значит я расшифровал схему правильно.
У нас 3 двойных импульса, значит у УКНЦ все кадры нечетные.
Возможно, для систем с нестандартной генерацией видеосигнала можно сделать простой преобразователь на простом микроконтроллере, на вход которого подается синхросмесь неверная, а получается верная. Или даже разделенный СС и КС.
Какие еще бывают проблемы с тюнерами, телевизорами и скандаблерами при подключении УКНЦ, кроме как обрезания верхних строк? Что-то там еще по бокам у кого-то обрезалось вроде?
Возможно, для систем с нестандартной генерацией видеосигнала можно сделать простой преобразователь на простом микроконтроллере, на вход которого подается синхросмесь неверная, а получается верная. Или даже разделенный СС и КС.
пусть он ещё снимки экрана делает и потоковое видео пишет )
- - - Добавлено - - -
проблема вылезла в полный рост
на ВМ-12 и Советском цв. телевизоре, при подключении через ДЦМ верхняя часть кадра смещалась с наклоном, если кассета была записана в системе PAL,
решалось ТОЛЬКО - установкой ПАЛ-Декодера в телевизор )
пусть он ещё снимки экрана делает и потоковое видео пишет )
Давно уже я видел проект у кого-то - что припаивается несколько проводочков на плату УКНЦ, и передаются цифровые сигналы на PC, а там программа расшифровки этих сигналов и в окошке картинка без каких-либо искажений - ну и там уже хоть скриншоты хоть видео снимай.
В будущем УКНЦ на FPGA конечно хотелось бы HDMI либо VGA.
- - - Updated - - -
Отлично. Значит я расшифровал схему правильно.
В идеале бы ещё осциллографом сигналы на живой УКНЦ посмотреть.
В идеале бы ещё осциллографом сигналы на живой УКНЦ посмотреть.
Да, было бы полезно. Но судя по всему, уже не обязательно, т.к. теория совпала с графиком, значит можно признать ее правильной.
- - - Добавлено - - -
Давно уже я видел проект у кого-то - что припаивается несколько проводочков на плату УКНЦ, и передаются цифровые сигналы на PC, а там программа расшифровки этих сигналов и в окошке картинка без каких-либо искажений - ну и там уже хоть скриншоты хоть видео снимай.
В будущем УКНЦ на FPGA конечно хотелось бы HDMI либо VGA.
На плату припаиваться не все бы хотели, я думаю. В принципе, на выходе есть все, что надо R, G, B, синхросмесь. В цифровом виде, конечно, лучше.
Давно уже я видел проект у кого-то - что припаивается несколько проводочков на плату УКНЦ
я то же видел и все заинтересованные, единственное , что смущает \ отвергает - необходимость паять проводки к контактам на плате.
Там даже в шапке темы было строго указано, "всё должно быть снаружи!!!" - речь шла о каком-то абстрактном конверторе картинки.
Всё закончилось "как всегда".
В будущем УКНЦ на FPGA конечно хотелось бы HDMI либо VGA.
там наверное можно цифровой без паяльника выводить я предполагаю?
- - - Добавлено - - -
пусть он ещё снимки экрана делает и потоковое видео пишет )
что бы не возиться с камерой снимая экран )
Там даже в шапке темы было строго указано, "всё должно быть снаружи!!!" - речь шла о каком-то абстрактном конверторе картинки.
Всё закончилось "как всегда".Если что, это творил Ярослав (Jarik65535). Какая-то готовая ходовая китайская платка с USB, ПЛИС и клоном 8051 на борту, причем этот клон только программирует ПЛИС, а дальше эта ПЛИС сама по USB отправляет картинку на писюк, который ее и рисует. Красиво. Но, без писюка не выйдет. Все потрындели, и успокоились...
Если что, это творил Ярослав (Jarik65535). Какая-то готовая ходовая китайская платка с USB, ПЛИС и клоном 8051 на борту, причем этот клон только программирует ПЛИС, а дальше эта ПЛИС сама по USB отправляет картинку на писюк, который ее и рисует.
Да, я про это как раз говорил - https://zx-pk.ru/threads/27779-podklyuchenie-vcaptfx2-k-uknts.html
Все потрындели, и успокоились...
потому что в ТЗ изначально было оговорено: чтрого всё снаружи, без участия ПК. То есть независимая железяка - втыкай куда хочу!
Арсений и ещё несколько человек для себя проблему решили, у меня тут местечковое решение от собрата по форуму и соседа по
городу, и я ещё отпишу подробнее, но в случае "УКНЦ на FPGA" надо делать цифровой видеовыход, так? И, что ещё важнее, раскладка клавиатуры должна быть хорошей как в УК-НЦ (эмулятор Никиты, только один символ подводит ^ в Лоде с ИГРУШКИ-1 не поиграть), а не как сделал Титус =- это издевательство !!!
но в случае "УКНЦ на FPGA" надо делать цифровой видеовыход, так?Именно. И это ТЗ для того, кто будет сочинять прошивку ФПГА - сделать так, чтобы для процессоров УКНЦ оно оказалось неразличимым с оригинальным оборудованием УКНЦ, а для интерфейса с монитором - совместимым с VGA или HDMI. Задача, скажем так, нетривиальная...
Задача, скажем так, нетривиальная...
то есто виртуально те же самые проводки припаять сложнее реала - не верю ))) противоречит всему, всему всему про роботов!!!!
не верю
То же мне - Склифосовский :)
AFZ, и зачем вы так усложняете ситуацию? Проц УК-НЦ тут вообще не причём, мы виртуальные проводки куда то подвели и сняли кадр - причём тут сам вычислитель то??? он работает и работает и знать ему не интерестно про видео входы\выходы свои аки и реальная машинка !!!
И, что ещё важнее, раскладка клавиатуры должна быть хорошей как в УК-НЦ (эмулятор Никиты, только один символ подводит ^ в Лоде с ИГРУШКИ-1 не поиграть), а не как сделал Титус =- это издевательство !!!
Моя раскладка для тех, кто привык к PC-клавиатуре. А не для зубров вроде тебя.
Но это оффтопик для темы, не будем отклоняться от реверса.
Но это оффтопик для темы, не будем отклоняться от реверса.
Никита коснулся по теме реплики и я подчеркнул очень важный момент, ты можешь оправдывать себя как угодно,
но если у реплики будет кривая клава где ; по умолчанию на букве Ж - это капут и в топку !!!
- - - Добавлено - - -
Моя раскладка для тех твоя раскладка для тех кто живой УК-НЦ никогда не щупал.
твоя раскладка для тех кто живой УК-НЦ никогда не щупал.
Именно.
- - - Добавлено - - -
Никита коснулся по теме реплики и я подчеркнул очень важный момент, ты можешь оправдывать себя как угодно,
но если у реплики будет кривая клава где ; по умолчанию на букве Ж - это капут и в топку !!!
На репликах и эмуляторах можно сделать любую раскладку. Хоть переключаемую по выбору.
На репликах и эмуляторах можно сделать любую раскладку. Хоть переключаемую по выбору.
у Никиты не так, но близко ) А вообще НЯП раскладкой больше времени терял Alex_K
https://pic.maxiol.com/images2/1593253005.787615700.064346af64489al.jpg
у Никиты не так, но близко ) А вообще НЯП раскладкой больше времени терял Alex_K
https://pic.maxiol.com/images2/1593253005.787615700.064346af64489al.jpg
Хм ... Картинка маловата, но клава вроде моя (https://yadi.sk/mail/?hash=dykmRXVXSg%2FRRVFOv88wW3s4Sf5eskVdeJG23LO0O% 2BkMldWmnfUgTYS4M0zYuBs5q%2FJ6bpmRyOJonT3VoXnDag%3 D%3D) - для переходника PS2-УКНЦ.
то есто виртуально те же самые проводки припаять сложнее реала - не верю ))) противоречит всему, всему всему про роботов!!!!Ты не понял. Вывести эти сигналы, чтобы прицепить к ним какой-то сторонний конвертер - не вопрос. А вот переделать схему генерации изображения так, чтобы она рисовала не в дремучем стандарте образца 1949-го года с обратным ходом по строке 12 мкс из общих 64 мкс, а в чем-то, понятном современным ЖКИ-мониторам и/или телевизорам, в то же время, со стороны процессоров УКНц оставаясь тем же самым набором периферии и памяти, чтобы программы на УКНЦ не заметили подмены, да еще и добиться, чтобы картинка на этих ЖКИ, во-первых, не размазывалась и, во-вторых, не искажались соотношения сторон - вот это не так просто!..
Ты не понял. Вывести эти сигналы, чтобы прицепить к ним какой-то сторонний конвертер - не вопрос. А вот переделать схему генерации изображения так, чтобы она рисовала не в дремучем стандарте образца 1949-го года с обратным ходом по строке 12 мкс из общих 64 мкс, а в чем-то, понятном современным ЖКИ-мониторам и/или телевизорам, в то же время, со стороны процессоров УКНц оставаясь тем же самым набором периферии и памяти, чтобы программы на УКНЦ не заметили подмены, да еще и добиться, чтобы картинка на этих ЖКИ, во-первых, не размазывалась и, во-вторых, не искажались соотношения сторон - вот это не так просто!..
Мне кажется - это как раз не проблема. На любом быстром микроконтроллере такое преобразование возможно.
Мне кажется - это как раз не проблема. На любом быстром микроконтроллере такое преобразование возможно.Ага, оборудованным набортным видеоадаптером. Иначе, кто будет генерить VGA и/или HDMI ? Генерить картинку на обычном STM32, его средствами, упаришься, и хорошо не выйдет.
Иначе, кто будет генерить VGA и/или HDMI ? Генерить картинку на обычном STM32, его средствами, упаришься, и хорошо не выйдет.
С VGA такого скромного разрешения, я думаю, справится.
Ты не понял нет, я не понял (наверно просто не могу понятно объяснить) в чём сложность, зачем переделывать УК-НЦ?
Есть некие точки куда паяют проводки аналоговые, вот пусть у нас классическая УК-НЦ пашет как и должна, без изменений, а четыре (или сколько там) проводка (только виртуальные) параллельно программируются по схеме вычислителя? Или это не возможно?
- - - Добавлено - - -
как я это вижу и в чём я ошибаюсь???
https://i.ibb.co/NsyrdyJ/image.png (https://ibb.co/NsyrdyJ)
как я это вижу и в чём я ошибаюсь???
https://i.ibb.co/NsyrdyJ/image.png (https://ibb.co/NsyrdyJ)
Хобот как обычно - "вижу цель и пофиг препятствия".
Твоя схема правильная и понятная, вот только в качестве "монитора" тогда должен использоваться МС-6106 (который цветной). Последствия понятны? А если схема будет "виртуальный вычислитель => ... => VGA (HDMI, DVI, etc)", то вместо точек должен быть модуль преобразующий на лету картинку УКНЦ в VGA стандарт. Собственно то, что все мы до сих пор ищем с переменным успехом, в железе. Или нужно переделывать видео вывод УКНЦ - что тебе и пытаются донести аксакалы.
Хобот как обычно - "вижу цель и пофиг препятствия".
тогда вы (аксакалы) не правильно используете термин "цифровой, цифровая" в каком-то "своём чтении" - и почему он подходит только для цветного 6106?
Цифра (как со звуком) везде цифра ))) Если в "виртуальной новой УК-НЦ" все те же проблемы с картинкой - смысл такой реинкарнации стремится к нулю ИМХо.
- - - Добавлено - - -
Arseny, то есть те проводки с разных ножек с платы давали цифровую картинку, которую куда можно вынести? Как третий видеовыход можно?
тогда вы (аксакалы) не правильно используете термин "цифровой, цифровая" в каком-то "своём чтении" - и почему он подходит только для цветного 6106?
Неа. Это ты не понимаешь о чем говорят специалисты. Точная цифровая модель УКНЦ будет на выход давать тот же результат, что и железная. А к железной без проблем подключается (по 4 проводам) - 6106. Ну, или ч/б по одному (видео). Если схему (модель) цифровой УКНЦ переделать - результат тоже будет другой.
Цифра (как со звуком) везде цифра ))) Если в "виртуальной новой УК-НЦ" все те же проблемы с картинкой - смысл такой реинкарнации стремится к нулю ИМХо.
Вот эту мысль (по поводу цифры в звуке) я не понял. У "виртуальной новой УК-НЦ" пока ровно одна проблема - её нет.
Arseny, то есть те проводки с разных ножек с платы давали цифровую картинку, которую куда можно вынести? Как третий видеовыход можно?
Для понятности - смотри на ZXKit1 и девайс Ярика. Они как раз берут цифровые части видеосигнала и преобразуют на лету в VGA и USB. С USB получилось хорошо (оно работает), с VGA - не очень (оно работает только в теории, с практикой не задалось). В виртуальной УКНЦ можно (нужно) сделать что-то подобное, но и трудности будут те же самые - нужно за ограниченное количество времени (пока рисуется кадр) понять (обработать) и перерисовать полученный кадр в VGA формате.
но в случае "УКНЦ на FPGA"
она не должна "детские болезни" Классической машинки иметь - иначе ЗАЧЕМ? )
Вот эту мысль (по поводу цифры в звуке) я не понял.
моя ошибка видимо - это я изначально воспринял проводочки припаянные к разноножкам на плате как готовую ЦИФРОВУЮ-видеокартинку,
это как "оптика" для звука размечтался я )))
она не должна "детские болезни" Классической машинки иметь - иначе ЗАЧЕМ? )
Никто не говорит что это невозможно. Просто сопряжено с рядом трудностей, которые нужно будет решать. А это, соответственно, увеличит сложность проекта и длительность разработки.
моя ошибка видимо - это я изначально воспринял проводочки припаянные к разноножкам на плате как готовую ЦИФРОВУЮ-видеокартинку,
это как "оптика" для звука размечтался я )))
Это, опять таки, от непонимания устройства и принципа работы. Звук из аналога в цифру и обратно гонится без изменений (только кодирование). Т.е. - на входе оцифровки играет пианино, и на выходе - пианино.
Звук из аналога в цифру и обратно гонится без изменений
Совсем не так.
Всегда есть точность оцифровки.
И из цифры в аналог получатся лесенка, которую потом сглаживают, то есть опять не точный процесс
Совсем не так.
Всегда есть точность оцифровки.
И из цифры в аналог получатся лесенка, которую потом сглаживают, то есть опять не точный процесс
Точность кодирования - это другой вопрос. Речь о том, что на входе и выходе звук один и тот же. У нас же, схема УКНЦ генерирует CGA, а монитор понимает VGA. Как тут не цифруй, без преобразования чего-то во что-то - никак. Либо CGA в VGA, либо генератор УКНЦ в VGA.
Кстати, как ты в своем КЦГД на FPGA генерировал видео сигнал (у тебя же вроде VGA выход)?
У нас же, схема УКНЦ генерирует CGA, а монитор понимает VGA. Как тут не цифруй, без преобразования чего-то во что-то - никак. Либо CGA в VGA, либо генератор УКНЦ в VGA.
VGA несколько старовато уже. Скоро не будет современных мониторов, имеющих этот разьем, совсем.
HDMI хорошо, но затратно в плане реализации.
Так же из минусов VGA, что 50Гц, на сколько я понимаю, многие мониторы могут и не поддержать.
Тогда как для HDMI 50Гц это вполне себе норма.
Кстати, как ты в своем КЦГД на FPGA генерировал видео сигнал (у тебя же вроде VGA выход)?
Ну, во первых, КЦГД (ещё) не мой :) Во вторых - пока это только концепт, который толком пока не запустился. И он отложен в сторону, скорее всего до момента, когда ко мне в руки попадёт :)
Ну, а сама по себе генерации VGA сигнала на FPGA - не сложно дело
- - - Добавлено - - -
Скоро не будет современных мониторов, имеющих этот разьем, совсем.
Да да, я это слышал здесь уже года так примерно два, если не три, назад.
Но воз и ныне там.
VGA несколько старовато уже. Скоро не будет современных мониторов, имеющих этот разьем, совсем.
HDMI хорошо, но затратно в плане реализации.
Доступны преобразователи VGA 2 HDMI. Стоят копейки.
Доступны преобразователи VGA 2 HDMI. Стоят копейки.
В случае перфекционистическом, это не очень хороший вариант - сперва получать аналог (VGA), а потом это конвертировать в HDMI.
Если использовать HDMI, то надо сразу сигнал в цифре на него гнать.
Хорошо, что я не перфекционист. У меня старенький моник к более-менее новой видюхе через переходник hdmi 2 vga подключен. Не страдаю от этого.
Если использовать HDMI, то надо сразу сигнал в цифре на него гнать.
тем более, что плата такой сигнал выдаёт же?
На всякий случай сообщаю, что я не забросил оптимизацию ХМ1-136. Пока что временно вернулся к оптимизации ХМ1-032, совершив в ней определенный рефакторинг, т.к. встал вопрос, как же именно работают линии связи RQ, CC0 и CC1. Все стало намного понятнее. Тактовые генераторы, которых было 3 штуки, плюс одновибратор для раритетного регистра, превратились в тактовые автоматы, для:
1. Записи в регистр адреса планов (5 ступеней)
2. Записи в регистр маски октета (3 ступени)
3. Записи в регистр планов 1&2 (2 ступени)
4. Записи в раритетный регистр (2 ступени).
Последняя ступень каждого автомата - это сброс автомата в исходное состояние.
Каждая ступень тактируется сигналом PS.
На всякий случай сообщаю, что я не забросил оптимизацию ХМ1-136.
Прекрасная новость!!!
Пока что временно вернулся к оптимизации ХМ1-032, совершив в ней определенный рефакторинг, т.к. встал вопрос, как же именно работают линии связи RQ, CC0 и CC1.
По смыслу RQ = Request - запрос. CC, скорее всего Command Code - код команды, возможны четыре варианта.
RQ = LOW, CC1 = CC0 = HIGH - передача адреса от контроллера ПП видеоконтроллеру. Видеоконтроллер принимает адрес и прочитывает по данному адресу слово из ОЗУ ЦП;
RQ = LOW, CC1 = LOW, CC0 = HIGH - передача прочитанных данных от видеоконтроллера в контроллер ПП (чтение);
RQ = LOW, CC1 = HIGH, CC0 = LOW - передача данных от контроллера ПП видеоконтроллеру. Видеоконтроллер записывает данные в ОЗУ ЦП по ранее переданному адресу (запись);
RQ = LOW, CC1 = CC0 = LOW - запись раритетного регистра (0177030 - 0177052).
По смыслу RQ = Request - запрос. CC, скорее всего Command Code - код команды, возможны четыре варианта.
RQ = LOW, CC1 = CC0 = HIGH - передача адреса от контроллера ПП видеоконтроллеру. Видеоконтроллер принимает адрес и прочитывает по данному адресу слово из ОЗУ ЦП;
RQ = LOW, CC1 = LOW, CC0 = HIGH - передача прочитанных данных от видеоконтроллера в контроллер ПП (чтение);
RQ = LOW, CC1 = HIGH, CC0 = LOW - передача данных от контроллера ПП видеоконтроллеру. Видеоконтроллер записывает данные в ОЗУ ЦП по ранее переданному адресу (запись);
RQ = LOW, CC1 = CC0 = LOW - запись раритетного регистра (0177030 - 0177052).
Вот это все должно выйти из схемы. Я опираюсь только на реверс, и ни на что больше. Иначе можно подогнать желаемое за действительное.
Замечания по поводу оптимизированной схемы контроллера ПП 1515ХМ1-032 rev.30:
1. Триггер R84...R88. У него есть вход сброса R, а вход данных D сидит на земле. Получается, что триггер можно только сбросить и нельзя установить.
2. Неизвестное UNK - это обращение к ОЗУ.
2. Неизвестное UNK - это обращение к ОЗУ.
Это я уже определил в более новой редакции.
Это я уже определил в более новой редакции.
А когда новая редакция будет выставлена на всеобщее обозрение?
Раз уж есть интерес, выложу текущую версию ХМ1-032, где уже много чего переработано (но, разумеется, это еще не финальная): 1515ХМ1-032-Optimized - rev 35 на Яндекс.Диск (https://yadi.sk/i/Gdi25U3-hcxV8w)
Titus, вопрос по работе регистра октета точек 0177024. По описанию из ТО, при чтении регистра октета 0177024 из него читается ноль, а в регистры кода цвета фона 0177020 и 0177022 загружается содержимое трёх планов ОЗУ. Как я понял из схемы, реального обращения к ОЗУ не происходит, а в регистры 0177020 и 0177022 загружаются значения регистров данных 0177012 и 0177014.
А при записи в регистр октета точек 0177024 реально устанавливаются регистры данных 0177012 и 0177014 из значений регистров 0177016, 0177020 и 0177022 в соответствии с установленными битами при записи, затем регистры данных записываются в ОЗУ.
- - - Добавлено - - -
Раз уж есть интерес, выложу текущую версию ХМ1-032, где уже много чего переработано (но, разумеется, это еще не финальная): 1515ХМ1-032-Optimized - rev 35 на Яндекс.Диск (https://yadi.sk/i/Gdi25U3-hcxV8w)
Ещё осталась BUF_UNK_DATA.
Titus, вопрос по работе регистра октета точек 0177024. По описанию из ТО, при чтении регистра октета 0177024 из него читается ноль, а в регистры кода цвета фона 0177020 и 0177022 загружается содержимое трёх планов ОЗУ. Как я понял из схемы, реального обращения к ОЗУ не происходит, а в регистры 0177020 и 0177022 загружаются значения регистров данных 0177012 и 0177014.
А при записи в регистр октета точек 0177024 реально устанавливаются регистры данных 0177012 и 0177014 из значений регистров 0177016, 0177020 и 0177022 в соответствии с установленными битами при записи, затем регистры данных записываются в ОЗУ.
Еще пока подробно не анализировал. Когда проанализирую, опишу.
Тут просто много работы всяческой, отвлекает от реверса.
Наверняка найдутся интересные особенности, не описанные в ТО.
Наверняка найдутся интересные особенности, не описанные в ТО.
Это вряд ли. Особенностями будут работы регистров, например по описанному выше регистра 0177024. Также из особенностей узнал, что при записи в раритетные регистры 0177030-0177052, они передаются в видеоконтроллер. Но текущие видеоконтроллеры -036 и -136 не поддерживают раритетные регистры, их поддерживает видеоконтроллер прототипа -033.
Приехали XM1-031,036,039 от Ynicky, 032 у меня есть своя.
Пока бросил их в Диму-Токсин, посмотрим, вдруг возьмет. Нет - поедут к химику.
Еще ожидаются ХМ2 от AFZ.
Приехали XM1-031,036,039 от Ynicky, 032 у меня есть своя.
Пока бросил их в Диму-Токсин, посмотрим, вдруг возьмет. Нет - поедут к химику.
Еще ожидаются ХМ2 от AFZ.
Здорово!
032 же мы уже отреверсили.
Здорово!
032 же мы уже отреверсили.
Да, там в коробочке вместо 032 лежит 136, чтобы попытаться вскрыть и переснять неколотую.
Да, там в коробочке вместо 032 лежит 136, чтобы попытаться вскрыть и переснять неколотую.
Я думаю, в этом смысла мало, т.к. все отколотые дорожки я логически восстановил, и вряд ли в них может быть ошибка.
Я думаю, в этом смысла мало
Я просто хочу иметь нормальную фотографию.
Сделал проект УКНЦ на FPGA для отладки отреверсенных микросхем. Пока подключил ПП, CGM(ХМ1-032), CK(ХМ2-001) и одну ПЗУ(208/o160000). При старте видно, как программа начинает работать и писать по адресам ОЗУ данные. Для подключения ОЗУ не хватает сигнала RAS, который формируется в CSM(ХМ1-136). CSM в свою очередь подключена к ЦП. Получается, что я не могу отладить ПП, пока не подключу ЦП и соответствующие м/c? И еще вопрос. Какое начальное состояние системного регистра управления по адресу о177716 в CK(ХМ2-001)?
https://pic.maxiol.com/thumbs2/1595320553.1845267016.msimukncprj1.jpg (https://pic.maxiol.com/?v=1595320553.1845267016.msimukncprj1.jpg&dp=2)
Какое начальное состояние системного регистра управления по адресу о177716 в CK(ХМ2-001)?
В эмуляторе - начальное значение 0, по RESET сбрасываются биты 0117461(octal).
Сделал проект УКНЦ на FPGA для отладки отреверсенных микросхем. Пока подключил ПП, CGM(ХМ1-032), CK(ХМ2-001) и одну ПЗУ(208/o160000).
Ты переводил в FPGA те схемы, которые я отреверсил?
Если да, то там вполне могут быть еще ошибки.
- - - Добавлено - - -
Какое начальное состояние системного регистра управления по адресу о177716 в CK(ХМ2-001)?
По схеме же видно, что по INIT сбрасываются биты 1, 7, 13, а по DCLO сбрасываются биты, 4, 5, 15.
Остальные биты произвольны.
Ты переводил в FPGA те схемы, которые я отреверсил?
Если да, то там вполне могут быть еще ошибки.
Потому я и стал моделировать (проверять).
По схеме же видно, что по INIT сбрасываются биты 1, 7, 13, а по DCLO сбрасываются биты, 4, 5, 15.
Остальные биты произвольны.
Так это и сделано. Значит остальные можно сбросить в 0, а то без сброса они шли крестом и портили начальную картину.
Для подключения ОЗУ не хватает сигнала RAS, который формируется в CSM(ХМ1-136). CSM в свою очередь подключена к ЦП. Получается, что я не могу отладить ПП, пока не подключу ЦП и соответствующие м/c?
1515ХМ1-136 является видеоадаптером и арбитром доступа к ОЗУ. И она не подключена к ЦП, она даже на шину МПИ не выходит. К ЦП подключен контроллер 1515ХМ1-039(ХМ2-003).
1515ХМ1-136 является видеоадаптером и арбитром доступа к ОЗУ. И она не подключена к ЦП, она даже на шину МПИ не выходит. К ЦП подключен контроллер 1515ХМ1-039(ХМ2-003).Хорошо, она (136) подключена к 039 и является арбитром доступа ПП и ЦП к ОЗУ, а так же регенерирует общую динамическую память. От этого не легче.
а то без сброса они шли крестом и портили начальную картину.
Каким крестом??? )
Каким крестом??? )Это, наверное, не критично, но все равно хочется определенности при проверке.
https://pic.maxiol.com/thumbs2/1595393246.1845267016.msimukncprj2.jpg (https://pic.maxiol.com/?v=1595393246.1845267016.msimukncprj2.jpg&dp=2)
- - - Добавлено - - -
Попробую добавить в проект 136.
Попробую добавить в проект 136.
С одной стороны, я бы порекомендовал подождать, пока я причешу реверсы, т.к. 32 и 136 еще в процессе.
Но с другой стороны, зачем удерживать активную фазу творчества. Наоборот, может ты ошибки найдешь интересные раньше меня.
Приехали 1515ХМ2-0002 от AFZ.
Дима-токсин корпуса этих ХМ-ок не берет, надо пилить и везти химику.
Дима-токсин корпуса этих ХМ-ок не берет, надо пилить и везти химику.
А в прошлые разы как ты вскрывал?
А в прошлые разы как ты вскрывал?
XM2 открылись диметилсульфоксидом начисто. ХМ1 отдавал травить кислотой.
XM2 открылись диметилсульфоксидом начисто. ХМ1 отдавал травить кислотой.
Не знаком с этими названиями, поэтому не понимаю, что в этот раз с корпусами. Они не открываются по старой схеме? Или ты попробовал по новой схеме, они не открылись, и придется отдавать травить по старой схеме?
- - - Добавлено - - -
1. Триггер R84...R88. У него есть вход сброса R, а вход данных D сидит на земле. Получается, что триггер можно только сбросить и нельзя установить.
Конечно вход должен сидеть на плюсе, а не на земле. Это ошибка, исправил ее.
не понимаю, что в этот раз с корпусами
В зависимости от материала корпуса "растворять" его надо разными химикатами. Диметилсульфоксид попроще, кислота пожёстче
Не знаком с этими названиями, поэтому не понимаю, что в этот раз с корпусами.
Разный состав компаунда. Сначала пробуем щадящий метод, если не проходит - отдаем варить в кислоте. Почему так - это вопрос к производителям.
Вопрос к Vslav и Alex_K - сколько тактов CLCI длится цикл DOUT у процессора, если сигнал RPLY пришел сразу же по переднему фронту DOUT?
Вопрос к Vslav и Alex_K - сколько тактов CLCI длится цикл DOUT у процессора, если сигнал RPLY пришел сразу же по переднему фронту DOUT?
Извините за вклинивание. При моделировании задал сигнал RPLY на процессор от DOUT.
DOUT при этом активным держится 3 такта.
Извините за вклинивание. При моделировании задал сигнал RPLY на процессор от DOUT.
Какая именно моделировалась модель? У Vslav'а их несколько, начиная от асинхронной оригинальной, и кончая всякими разнообразностями)
С одним клоком на входе.
vm2\hdl\org\rtl
С одним клоком на входе.
Так это... он и так с одним)
Лучше давать полную ссылку)
Вопрос к Vslav и Alex_K - сколько тактов CLCI длится цикл DOUT у процессора, если сигнал RPLY пришел сразу же по переднему фронту DOUT?
А какой процессор-то? У нас их уже много всяких. 1801ВМ2? Оригинальная модель показывает три такта.
http://www.1801bm1.com/files/images/vm2_dout.png
А какой процессор-то? У нас их уже много всяких. 1801ВМ2?
Меня интересуют только оригиналы.
Так это... он и так с одним)
Лучше давать полную ссылку)
https://github.com/1801BM1/cpu11/tree/master/vm2/hdl/org/rtl
Меня интересуют только оригиналы.
У оригинальной асинхронной модели вкус идентичный натуральному :)
Оригинальная модель показывает три такта.
На рисунке как раз вырезан тот фрагмент, где активен DOUT)
- - - Добавлено - - -
У оригинальной асинхронной модели вкус идентичный натуральному
Есть натуральная ваниль, есть натуральный ароматизатор ванили, а есть искусственный, идентичный натуральному... Я бы купил первое или второе)
На рисунке как раз вырезан тот фрагмент, где активен DOUT)
Он не вырезан, я специально для тебя курсоры поставил, чтобы ты такты мог лично пащитать.
Он не вырезан, я специально для тебя курсоры поставил, чтобы ты такты мог лично пащитать.
О как.
Я вижу он 3 такта CLK. А что тогда F1 и F2. Ибо можно перепутать с такими же тактовыми сигналами на схеме УКНЦ.
Я вижу он 3 такта CLK. А что тогда F1 и F2. Ибо можно перепутать с такими же тактовыми сигналами на схеме УКНЦ.
Модель процессора ничего не знает об УКНЦ, и о ДВК, и даже о пишмашинке "Ромашко" никогда не слышала. Поэтому никаких F1/F2 относящихся у УКНЦ тут быть не может. Логично?
А схему процессора 1801ВМ2 ты же притащил, если ты ее откроешь то увидишь фи1, ~фи1, фи2, ~фи2. Греческих букв для именований цепей в пикад не завезли в это раз, так шо - звыняй :)
randomizer
23.07.2020, 19:49
Недавно как раз замерял (точнее тестировал на каких таймингах будут работать AY-3-89xx)
При частоте процессора 10МГц, DOUT висит 300ns, как раз три такта.
По тех. описанию, 1.5 такта CLCO. Все совпадает :v2_smile:
Набросал растактовку записи в регистр планов 1&2 для ХМ1-032.
Все нарисовано и описано чисто теоретически, глядя на отреверсенную схему, без моделирования.
https://pic.maxiol.com/images2/1595524801.2151951582..png
Описание:
Наименоваия сигналов:
CLC1 - тактовый сигнал 6.25МГц (F1), он же тактовый сигнал CLCI для PPU (ПП)
CLC2 - тактовый сигнал 6.25МГц (F2), повторяет CLC1 со смещением на 1/4 такта.
PCLC - тактовый сигнал 12.5МГц (Pixel clock), получаемый из CLC1 и CLC2 внутри большинства чипов. Также является тактовым сигналом видеоконтроллера (ХМ1-136). Один такт PCLC соответствует одной точке экрана в разрешении 640. В дальнейшем тактовым сигналом будет называться именно PCLC.
PS - сигнал арбитра доступа к памяти PPU. Генерируется видеоконтроллером (сигнал PSG). Низкий уровень устанавливается во время точек 1, 2, 3, 4. В этой фазе шиной ВОЗУ владеет PPU. Высокий уровень устанавливается во время точек 5, 6, 7, 0. В этой фазе шина ВОЗУ свободна, и может использоваться для передачи данных между ХМ1-032 и ХМ1-136. Наружу сигнал выводится в инверсном виде (/PSG).
CLCA - сигнал арбитра PS со смещением на 1 такт. Каждый цикл начинается с низкого уровня.
ACT_WRITE - устанавливается по фронту записи в регистр планов. Сбрасывает по CLCA2_F1 (фаза завершения).
CLCA2_F0 - фаза F0. Запись данных на шины D0..D7 и A0..A7. Активна весь цикл CLCA.
CLCA2_F1 - фаза F1. Завершение. Активируется по завершению цикла CLCA.
RQ - сигнал запроса обмена с видеоконтроллером. Повторяет CLCA2_F0. Наружу выведен в инверсном виде (/RQ).
CC0 - сигнал запроса записи в планы 1 и 2. Повторяет ACT_WRITE. Наружу выведен в инверсном виде (/CC0).
Описание работы:
Запись в регистр планов 1&2 (PLANE12, адрес 177014) начинается по переднему фронту DOUT. Одновременно с этим устанавливается сигнал подтверждения записи RPLY. Таким образом, запись в регистр планов имеет для процессора нулевую задержку. Одновременно с этим устанавливается сигнал CC0. Также во время активного DOUT данные с шины AD защелкиваются в регистре PLANE1_DATA (младший байт), и регистре PLANE2_DATA (старший байт). Если происходит байтовая запись (активен WTBT), то при записи по четному адресу, блокируется запись в регистр PLANE2_DATA, а при записи по нечетному адресу блокируется запись в регистр PLANE1_DATA. Это означает, что в случае байтовой записи, незадействованная часть регистра планов сохраняет свое предыдущее значение.
По отрицательному фронту CLCA (такт 4) устанавливается сигнал RQ.
По положительному фронту CLCA (такт 8) на шину A0..A7 выводится содержимое регистра PLANE2_DATA.
Через пол-такта (такт 8.5) на шину D0..D7 выводится содержимое регистра PLANE1_DATA. Задержка вывода на пол-такта, очевидно, снижает шум на шинах.
Еще через пол-такта по внутреннему сигналу видеоконтроллера A_D_LATCH (такты 9 и 10), содержимое шин A0..A7 и D0..D7 защелкивается видеоконтроллером с шин AG0..AG7 и DG0..DG7 в регистрах DC_H, и DC_L, соответственно.
И еще через один такт (такт 12) процесс завершается.
Шины A0..A7, D0..D7 освобождаются, сигналы RQ, CC0 переводятся в неактивное состояние.
- - - Добавлено - - -
Как видно из растактовки, циклы несколько отличаются от того, что описано в журнале ПК УКНЦ 1'95.
Где-то я такие шрифты видел... Ты что, в пикаде картинку рисовал?
Dia возьми, бесплатная, крутая и изучается за 10 минут.
Хотя... Как рисунок на схеме - норм.
Где-то я такие шрифты видел... Ты что, в пикаде картинку рисовал?
Dia возьми, бесплатная, крутая и изучается за 10 минут.
Хотя... Как рисунок на схеме - норм.
Это и есть кусок со схемы в PCAD'е.
Как видно из растактовки, циклы несколько отличаются от того, что описано в журнале ПК УКНЦ 1'95.
А поподробней можно?
А поподробней можно?
Ну, например:
1. CC0 устанавливается раньше RQ.
2. Данные на шине A и D устанавливаются не одновременно, а с задержкой в пол-такта.
3. Передача данных по шине A и D длится на такт дольше, чем заканчивается PS, и начинается на такт позже.
Где-то я такие шрифты видел... Ты что, в пикаде картинку рисовал?
Dia возьми, бесплатная, крутая и изучается за 10 минут.
Хотя... Как рисунок на схеме - норм.
Немного оффтопик конечно, да и каждому своё, но -
На мой взгляд, самые красивые диаграммы сигналов делаются вот этим онлайн-редактором: https://wavedrom.com/
То, о чем 35 лет подряд мечтали миллионы УКНЦ'шников (в лице 5-10 особенно заинтересованных форумчан) свершилось! Загадка записи в раритетные регистры полностью разгадана!
1. Почему запись в раритетные регистры медленнее, чем запись в другие регистры?
2. Происходит ли хоть что-нибудь при записи в раритетные регистры?
Все это вы узнаете в этой серии расследования.
https://pic.maxiol.com/images2/1595543426.2151951582.01.png
Наименоваия сигналов:
CLC_RARE_F0 - фаза F0. Запись данных на шины D0..D7 и A0..A7. Активна вторую половину цикл CLCA.
CLC_RARE_F1 - фаза F1. Завершение. Активируется по завершению цикла CLCA.
RQ, CC0, CC1 - сигналы обмена с видеоконтроллером.
Описание:
Запись в любой раритетный регистр (RARE_REG, адреса 177030..177057, за исключением регистров 177054 и 177055) начинается по переднему фронту DOUT.
По отрицательному фронту CLCA (такт 4) запускается тактовый автомат.
Во время низкого уровня CLCA (такты 4..7) ничего не происходит (шина находится в пользовании видеоконтроллера).
По положительному фронту CLCA (такт 8) на шину A0..A7 выводится и удерживается младший байт адреса раритетного регистра, защелкнутый в LATCH_ADR по сигналу SYNC. Причем, если запись была словная, то младший бит (A0) обнуляется.
Также устанавливаются сигналы RQ, CC0, CC1.
Через пол-такта (такт 8.5) на шину D0..D7 выводится и удерживается младший байт с шины данных (AD0..AD7).
По окончанию цикла CLCA (такт 12) выдается сигнал RLPY, а так же освобождаются шины A0..A7, D0..D7.
В ответ на сигнал RPLY, процессор снимает сигнал DOUT, после чего снимаются сигналы RQ, CC0, CC1.
Итак, ответы на животрепещущие вопросы:
1. Запись в раритетный регистр медленнее, чем запись в регистр планов из-за того, что сигнал RPLY выдается по окончанию цикла CLCA, что продлевает цикл записи на 2..5 тактов процессора, в зависимости от момента наступления цикла CLCA. Данная задержка выставления сигнала RPLY сделана потому, что при записи в раритетный регистр не предусмотрена буферизация в промежуточном регистре, поэтому данные на шине AD должны удерживаться до окончания цикла передачи данных в видеоконтроллер (CLCA).
2. В видеоконтроллере ХМ1-136 (в отличие от раритетного ХМ1-033) функция записи в раритетный регистр никак не реализована, поэтому на цикл RQ=1, CC0=1, CC1=1 он никак не отвечает.
- - - Добавлено - - -
Я думаю, что комбинацию сигналов RQ, CC0, CC1 можно расшифровать, как Request (о чем всем и так понятно) и Command_Code_0 и Command_Code_1.
SuperMax
24.07.2020, 11:12
нашел несколько новых КА1515ХМ1-136 от 9203
среди них одна с компаундом сверху
я правильно понял что уже не нужны для вскрытия ?
нашел несколько новых КА1515ХМ1-136 от 9203
среди них одна с компаундом сверху
я правильно понял что уже не нужны для вскрытия ?
В принципе мне не нужны, т.к. вскрыты и отреверсены.
нашел несколько новых КА1515ХМ1-136 от 9203
среди них одна с компаундом сверху
я пранильно понял что уже не нужны для вскрытия ?
Нет, фотка со сколом уже отреверсена, и есть еще один экземпляр ожидающий вскрытия чтобы перефотографировать. Если там не получится - может подумать об еще парочке 136-ых. Но пока - не надо и есть вероятность что не понадобится.
С позволения Vslav'а, сделал оптимизированную версию реверса 1801ВП1-120 в стиле отреверсенных 1515ХМ2.
Titus, Будет время, поправь нумерацию выводов в 120й.
CPU:
DOUTC=>4
DINC=>5
INITC=>9
IAKOC=>8
ARC=>12
RPLYC=>11
PPU:
SYNCP=>30
INITP=>35
DOUTP=>32
A0=>33
A1=>28
https://pic.maxiol.com/images2/1595608458.2151951582..png
Наименования сигналов:
ACT_WRITE - устанавливается по фронту записи в регистр октета. Сбрасывает по CLCA3_F3 (фаза завершения).
CLCA3_F1 - фаза F1. Передача данных видеоконтроллеру, аналогично записи в регистр планов 1 и 2.
CLCA3_F2 - фаза F2. Запись данных плана 0 в ОЗУ ПП.
RQ - сигнал запроса обмена с видеоконтроллером. Повторяет CLCA3_F1.
CC0 - сигнал запроса записи в планы 1 и 2. Повторяет ACT_WRITE.
Описание:
Запись в регистр октета (адрес 177024) начинается по переднему фронту DOUT. Одновременно с этим устанавливается сигнал подтверждения записи RPLY. Таким образом, запись в регистр октета имеет для процессора нулевую задержку. Одновременно с этим устанавливается сигнал CC0. Также во время активного DOUT производятся логические операции с младшим байтом, выставленным на шине AD0..AD7. Назовем этот байт OCTET.
1) if (MASK_Q0 == 1), then PLANE0_DATA = (OCTET & INC_COLOR_Q0) | (~OCTET & [PAPER_H_Q12.Q8.Q4.Q0.PAPER_L_Q12.Q8.Q4.Q0])
2) if (MASK_Q1 == 1), then PLANE1_DATA = (OCTET & INC_COLOR_Q1) | (~OCTET & [PAPER_H_Q13.Q9.Q5.Q1.PAPER_L_Q13.Q9.Q5.Q1])
3) if (MASK_Q2 == 1), then PLANE2_DATA = (OCTET & INC_COLOR_Q2) | (~OCTET & [PAPER_H_Q14.Q10.Q6.Q2.PAPER_L_Q14.Q10.Q6.Q2])
В итоге в регистрах данных планов, для которых MASK_Qx = 1, защелкиваются новые вычисленные значения.
По отрицательному фронту CLCA (такт 4) устанавливается сигнал RQ.
По положительному фронту CLCA (такт 8) на шину A0..A7 выводится содержимое регистра PLANE2_DATA.
Через пол-такта (такт 8.5) на шину D0..D7 выводится содержимое регистра PLANE1_DATA.
Еще через пол-такта по внутреннему сигналу видеоконтроллера A_D_LATCH (такты 9 и 10), содержимое шин A0..A7 и D0..D7 защелкивается видеоконтроллером с шин AG0..AG7 и DG0..DG7 в регистрах DC_H, и DC_L, соответственно.
Через один такт (такт 12) шины A0..A7, D0..D7 освобождаются для видеоконтроллера на 4 такта, сигналы RQ, CC0 переводятся в неактивное состояние.
По положительному фронту CLCA начинается процесс записи данных PLANЕ0 в ОЗУ ПП. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 16 - на шину A0..A7 выводится младшая часть адреса планов PLANE_ADR.
Такт 16.5 - на шину D0..D7 выводятся данные регистра PLANE0.
Такт 17 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса планов).
Такт 17.5 - на шину A0..A7 выводится старшая часть адреса планов PLANE_ADR.
Такт 18 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса планов).
Такт 19.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Такт 20 - завершение процесса.
Шины A0..A7, D0..D7 освобождаются, сигналы CAS и WE снимаются.
- - - Добавлено - - -
@Titus, Будет время, поправь нумерацию выводов в 120й.
Спасибо за наблюдательность. Иногда не обращаю внимания на номера ножек, т.к. они в глаза не бросаются, номера и номера)
1801ВП1-120-Optimized - rev 15 (https://yadi.sk/d/IR_HTvmNdonx5g)
- - - Добавлено - - -
Замечу, что рисуя диаграммы, я параллельно исправляю какие-то ошибки или неточности в оптимизированных схемах, так что если кто-то (например, Ynicky) строит FPGA-модель по ним, то надо иметь это в виду.
https://pic.maxiol.com/images2/1595618595.2151951582..png
Наименования сигналов:
ACT_WRITE - устанавливается по фронту записи в регистр адреса планов. Сбрасывает по CLCA4_F5 (фаза завершения).
CLCA4_F1 - фаза F1. Адрес планов записывается в видеоконтроллер.
CLCA4_F2 - фаза F2. Чтение данных плана 0 из ОЗУ ПП.
CLCA4_F3 - фаза F3. Чтение данных планов 1 и 2 из видеоконтроллера.
Описание:
Запись в регистр адреса планов (адрес 177010) начинается по переднему фронту DOUT. Одновременно с этим устанавливается сигнал подтверждения записи RPLY. Таким образом, запись в регистр адреса планов имеет для процессора нулевую задержку. Во время активного DOUT данные с шины AD0..AD15 защелкиваются в регистре адреса планов PLANE_ADR.
По отрицательному фронту CLCA (такт 4) устанавливается сигнал RQ.
По положительному фронту CLCA (такт 8) на шину A0..A7 выводится старшая часть регистра адреса планов PLANE_ADR.
Через пол-такта (такт 8.5) на шину D0..D7 выводится младшая часть регистра адреса планов PLANE_ADR.
Еще через полтора такта (такт 10) содержимое шин A0..A7 и D0..D7 защелкивается видеоконтроллером с шин AG0..AG7 и DG0..DG7 в регистрах DC_H, и DC_L, соответственно.
Через один такт (такт 12) шины A0..A7, D0..D7 освобождаются для видеоконтроллера на 4 такта, сигнал RQ переводится в неактивное состояние.
По положительному фронту CLCA начинается процесс чтения данных из ОЗУ ПП в регистр PLANE0_DATA.
Такт 16 - на шину A0..A7 выводится младшая часть адреса планов PLANE_ADR.
Такт 17 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса планов).
Такт 17.5 - на шину A0..A7 выводится старшая часть адреса планов PLANE_ADR.
Такт 18 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса планов). В течение активного сигнала CAS данные с шины D0..D7 защелкиваются в регистре плана 0 (PLANE0_DATA).
Такт 19.5 - снимается сигнал RAS.
Такт 20 - завершение процесса чтения.
Шины A0..A7 освобождается, сигнал CAS снимается.
Устанавливаются сигналы RQ и CC1.
Такт 24..26 - данные планов 1 и 2, предоставленные видеоконтроллером, защелкиваются с шины D0..D7 в регистре PLANE1_DATA, и с шины A0..A7 в регистре PLANE2_DATA, соответственно.
- - - Добавлено - - -
Не смотря на то, что задержка (latency) записи в регистры октета, планов 1&2, адреса планов нулевая, пропускная способность (throughput) для этих команд значительно ниже.
Подробней можно расписать только зная точную растактовку ВМ2, а также особенности работы контроллеров памяти ПП и ЦП.
Однако, знание нюансов работы контроллеров и процессора, значительно увеличивает возможность оптимизации работы с графикой УКНЦ по скорости.
https://pic.maxiol.com/images2/1595662806.2151951582.01.png
Описание:
Запись в регистр плана 0 (адрес 177012) начинается по переднему фронту DOUT. Если контроллер все еще занят операциями записи в регистр октета или в регистр адреса планов, то начало записи в регистр плана 0 задержится до окончания последнего цикла CLCA предыдущей операции. Во время всего активного цикла DOUT данные с шины AD0..AD7 защелкиваются в регистре плана 0 (PLANE0_DATA).
В последнем такте отрицалельного фронта CLCA (такт 7) происходит подготовка данных для записи.
По положительному фронту CLCA начинается процесс записи данных PLANЕ0 в ОЗУ ПП. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 8 - на шину A0..A7 выводится младшая часть адреса планов PLANE_ADR.
Такт 8.5 - на шину D0..D7 выводятся данные регистра PLANE0.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса планов).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса планов PLANE_ADR.
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса планов).
Такт 11.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Если была запись байта (WTBT = 1), то:
Такт 12 - выдается сигнал RLPY, а также освобождаются шины A0..A7, D0..D7, сигналы CAS и WE снимаются.
В ответ на сигнал RPLY, процессор снимает сигнал DOUT.
Если же была запись слова (WTBT = 0), то происходит полный повтор предыдущего цикла CLCA, записывается по тому же адресу тот же самый байт.
В такте 20 выдается сигнал RLPY, а так же освобождаются шины A0..A7, D0..D7, сигналы CAS и WE снимаются.
В ответ на сигнал RPLY, процессор снимает сигнал DOUT.
Замечание: Словная запись в регистр плана 0 является побочным эффектом использования механизма словной/байтовой записи в память. Двойная запись одного и того же байта по тому же адресу связана с тем, что при записи в регистр плана 0 не задействован механизм поочередной записи младшего/старшего байта по последовательным адресам.
Замечание: Словная запись в регистр плана 0 является побочным эффектом использования механизма словной/байтовой записи в память. Двойная запись одного и того же байта по тому же адресу связана с тем, что при записи в регистр плана 0 не задействован механизм поочередной записи младшего/старшего байта по последовательным адресам.
В обоих случаях медленно. При словной записи контроллер ПП делает двойную запись, а при байтовой записи для команд MOVB, CLRB, MFPS сам процессор сначала делает фиктивное чтение по записываемому адресу. Так что тут быстрее, наверное надо сделать тесты.
Диаграммы байтовой и словной записи полностью идентичны записи в регистр плана 0.
Описание:
Запись в ОЗУ ПП начинается по переднему фронту DOUT. Если контроллер все еще занят операциями записи в регистр октета или в регистр адреса планов, то начало записи в ОЗУ задержится до окончания последнего цикла CLCA предыдущей операции.
В последнем такте отрицалельного фронта CLCA (такт 7) происходит подготовка данных для записи.
Запись байта (WTBT = 1):
По положительному фронту CLCA начинается процесс записи данных в ОЗУ ПП. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 8 - на шину A0..A7 выводится младшая часть адреса (LATCH_ADR).
Такт 8.5 - на шину D0..D7 выводятся данные с AD0..AD7, если запись по четному адресу, и данные с AD8..AD15, если запись по нечетному адресу.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса (LATCH_ADR).
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса).
Такт 11.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Такт 12 - выдается сигнал RLPY, а также освобождаются шины A0..A7, D0..D7, сигналы CAS и WE снимаются.
В ответ на сигнал RPLY, процессор снимает сигнал DOUT.
Запись слова (WTBT = 0):
По положительному фронту CLCA начинается процесс записи младшего байта в ОЗУ ПП. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 8 - на шину A0..A7 выводится младшая часть адреса (LATCH_ADR). Младший бит принудительно равен 0.
Такт 8.5 - на шину D0..D7 выводятся данные с AD0..AD7.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса (LATCH_ADR).
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса).
Такт 11.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Такт 12 - шины A0..A7, D0..D7 освобождаются для видеоконтроллера на 4 такта, сигналы CAS и WE снимаются.
По положительному фронту CLCA начинается процесс записи старшего байта в ОЗУ ПП. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 16 - на шину A0..A7 выводится младшая часть адреса (LATCH_ADR). Младший бит принудительно равен 1.
Такт 16.5 - на шину D0..D7 выводятся данные с AD8..AD15.
Такт 17 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 17.5 - на шину A0..A7 выводится старшая часть адреса (LATCH_ADR).
Такт 18 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса).
Такт 19.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Такт 20 - выдается сигнал RLPY, а также освобождаются шины A0..A7, D0..D7, сигналы CAS и WE снимаются.
В ответ на сигнал RPLY, процессор снимает сигнал DOUT.
- - - Добавлено - - -
В обоих случаях медленно. При словной записи контроллер ПП делает двойную запись, а при байтовой записи для команд MOVB, CLRB, MFPS сам процессор сначала делает фиктивное чтение по записываемому адресу. Так что тут быстрее, наверное надо сделать тесты.
Я думаю, что практически нет смысла использовать запись в регистр плана 0, если видео-ОЗУ расположено в доступной части ОЗУ ПП (ниже адреса 0x8000, или же ниже адреса регистров 0xFE00, если страницы ОЗУ спроецированны в верхнюю память). И тут несколько причин:
1. Байтовая запись медленная из-за фиктивного чтения.
2. Словная запись медленная, т.к. занимает двойное время, но записывает один байт.
3. И, наконец, запись в регистр адреса планов (а ведь туда надо записать адрес) - это ОЧЕНЬ МЕДЛЕННАЯ операция, требующая чтения ОЗУ ПП, ОЗУ ЦП, и при этом еще и подтормаживающая в это время ЦП.
Словом, я бы рекомендовал программистам никогда не использовать запись в регистр планов 0.
Растактовка записи в ОЗУ ПП
Ждем растактовку чтения из ОЗУ ПП. Так как с точки зрения шины QBUS/МПИ байтового чтения нет, то должно всегда читаться за два прохода - сначала младший байт, потом старший.
Вообще, к разработчикам механизма работы с ОЗУ много вопросов. Я бы назвал придуманные ими конструкциями сложными, косячными и местами бесполезными. Множество ресурсов потрачено на регистровый доступ к памяти, и при этом вообще не предусмотрен никакой автоинкремент адреса. Относительно неплохие графические возможности без механизма быстрой переброски данных - это товарный поезд с дрезиной вместо тепловоза. А ведь в эти самые же потраченные ресурсы ПЛМ вполне можно было напихать подходящие для быстрой работы функции. Но, похоже, действительно, компьютер был задуман как чисто учебный, но никак не игровой.
Я думаю, что практически нет смысла использовать запись в регистр плана 0, если видео-ОЗУ расположено в доступной части ОЗУ ПП (ниже адреса 0x8000, или же ниже адреса регистров 0xFE00, если страницы ОЗУ спроецированны в верхнюю память). И тут несколько причин:
1. Байтовая запись медленная из-за фиктивного чтения.
2. Словная запись медленная, т.к. занимает двойное время, но записывает один байт.
3. И, наконец, запись в регистр адреса планов (а ведь туда надо записать адрес) - это ОЧЕНЬ МЕДЛЕННАЯ операция, требующая чтения ОЗУ ПП, ОЗУ ЦП, и при этом еще и подтормаживающая в это время ЦП.
Словом, я бы рекомендовал программистам никогда не использовать запись в регистр планов 0.
Медлительность сохранится и при прямой записи. При байтовой записи также будет фиктивное чтение, а чтение из ОЗУ всегда будет за два прохода, надо два байта прочесть, медленно однако. Запись тоже будет за два прохода, т.к. ОЗУ стоит на одной ноге. Да и к тому же при маппинге страниц ОЗУ на адреса выше 0100000, ПЗУ выше 0120000 не отключить, соответственно можно только применять команды MOV(B), CLR(B).
Медлительность сохранится и при прямой записи. При байтовой записи также будет фиктивное чтение, а чтение из ОЗУ всегда будет за два прохода, надо два байта прочесть, медленно однако. Запись тоже будет за два прохода, т.к. ОЗУ стоит на одной ноге. Да и к тому же при маппинге страниц ОЗУ на адреса выше 0100000, ПЗУ выше 0120000 не отключить, соответственно можно только применять команды MOV(B), CLR(B).
Не соглашусь. С точки зрения программиста колоссальная разница.
Если я использую регистровый механизм, я сперва даю команду записи в регистр адреса планов (а это >24 тактов ожидания ПП, и дополнительно 8 тактов торможения ЦП), затем команду записи в регистр плана 0 (а это 16 тактов ожидания, если запись словная). И при этом мы записали всего ОДИН байт!
Тогда как записывая просто в память мы тратим лишь 16 тактов ожидания (при словной записи), и при этом получаем два записанных байта.
Почувствуйте разницу, как говорится. Ради этого стоит разместить видеоОЗУ в доступной части ОЗУ ПП (ниже 0xA000).
- - - Добавлено - - -
Да и к тому же при маппинге страниц ОЗУ на адреса выше 0100000, ПЗУ выше 0120000 не отключить, соответственно можно только применять команды MOV(B), CLR(B).
Кстати, почему с 0xA000? У нас же системное ПЗУ начинается с 0x8000, а не с 0xA000. Ну и понятно, что хоть читаться будет ПЗУ, но писаться будет в ОЗУ, при соответствующем маппинге страниц верхнего ОЗУ.
Ждем растактовку чтения из ОЗУ ПП. Так как с точки зрения шины QBUS/МПИ байтового чтения нет, то должно всегда читаться за два прохода - сначала младший байт, потом старший.
Сам процессор ВМ2 выдает ли сигнал WTBT при байтовом чтении? Или не выдает?
Буду считать, что не выдает, т.к. WTBT - это Write Byte.
Сам процессор ВМ2 выдает ли сигнал WTBT при байтовом чтении? Или не выдает?
Буду считать, что не выдает, т.к. WTBT - это Write Byte.
На шине QBUS/МПИ нет байтового чтения. Читается всегда полное слово. А нужный байт в случае необходимости процессор уже выделяет сам.
На шине QBUS/МПИ нет байтового чтения. Читается всегда полное слово. А нужный байт в случае необходимости процессор уже выделяет сам.
Это я все понимаю. Но вдруг он выдает на шину WTBT, просто потому что чтение было байтовое, в виде побочного эффекта от байтовой записи. Именно это я и хочу уточнить.
Но вдруг он выдает на шину WTBT, просто потому что чтение было байтовое, в виде побочного эффекта от байтовой записи. Именно это я и хочу уточнить.
Это вряд ли. Тут уже точно ответит Vslav. Да и по идее на чтение сигнал WTBT не должен оказывать влияние.
Да, призываю в тему Vslav'а за уточнением.
Это вряд ли. Тут уже точно ответит Vslav. Да и по идее на чтение сигнал WTBT не должен оказывать влияние.
Как раз оказывает. Если при чтении будет выставлен WTBT, то контроллер ОЗУ ПП ответит иначе, а именно прочитает один байт, как и при записи.
Titus,
Сигнал «Байт» (WTBT) используется в двух случаях: при передаче
адреса, когда сигнал «Байт» указывает, что дальше будет следовать операция
вывода, а не ввода, и при передаче данных, когда этот сигнал указывает, что
выводится байт, а не слово.
https://pic.maxiol.com/images2/1595683287.2151951582.01.png
Описание:
Чтение из ОЗУ ПП начинается по переднему фронту DIN. Если контроллер все еще занят операциями записи в регистр октета или в регистр адреса планов, то начало чтения ОЗУ задержится до окончания последнего цикла CLCA предыдущей операции. На шину AD0..AD15 выставляется предыдущее слово прочитанное из памяти, и сохраненное в регистрах MEM_HIGH/MEM_LOW.
В последнем такте отрицалельного фронта CLCA (такт 7) происходит подготовка данных для чтения.
Чтение из ОЗУ всегда словное:
По положительному фронту CLCA начинается процесс чтения младшего байта из ОЗУ ПП.
Такт 8 - на шину A0..A7 выводится младшая часть адреса (LATCH_ADR). Младший бит принудительно равен 0.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса (LATCH_ADR). С этого момента шина данных D0..D7 выводится на AD0..AD7.
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса). После чего ОЗУ выставляет на шину данных D0..D7 значение из памяти.
Такт 11.5 - снимается сигнал RAS.
Такт 12 - шина A0..A7 освобождается для видеоконтроллера на 4 такта, сигнал CAS снимается, данные с шины D0..D7 защелкиваются в регистре MEM_LOW.
По положительному фронту CLCA начинается процесс чтения старшего байта из ОЗУ ПП.
Такт 16 - на шину A0..A7 выводится младшая часть адреса (LATCH_ADR). Младший бит принудительно равен 1.
Такт 17 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 17.5 - на шину A0..A7 выводится старшая часть адреса (LATCH_ADR). С этого момента шина данных D0..D7 выводится на AD8..AD15.
Такт 18 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса). После чего ОЗУ выставляет на шину данных D0..D7 значение из памяти.
Такт 19.5 - снимается сигнал RAS.
Такт 20 - шина A0..A7 освобождается, сигнал CAS снимается, данные с шины D0..D7 защелкиваются в регистре MEM_HIGH. На шине AD0..AD15 находится слово, прочитанное из ОЗУ. Выдается сигнал RPLY, в ответ на который процессор считывает данные с шины AD, и снимает сигнал DIN. Шина AD освобождается.
Как видно из графиков, данные на шине AD в процессе чтения меняются следующим образом:
Начало чтения (DIN установлен) - на шине AD0..AD15 выставляется предыдущее слово, прочитанное из ОЗУ.
Такт 9.5 - на шине AD0..AD7 - мусор, копируемый с D0..D7, AD8..AD15 - предыдущее значение.
Tакт 10..11 - на шину AD0..AD7 выставляется значение из памяти (младший байт), AD8..AD15 - предыдущее значение.
Такт 17.5 - на шине AD8..AD15 - мусор, копируемый с D0..D7, AD0..AD7 - младший байт.
Такт 18..19 - на шину AD8..AD15 выставляется значение из памяти (старший байт), AD0..AD7 - младший байт.
Но вдруг он выдает на шину WTBT, просто потому что чтение было байтовое, в виде побочного эффекта от байтовой записи.
Прошу прощения, я не понял вопрос, в какой момент процессор "вдруг выдает на шину WTBT"? Никаких отличий в поведении WTBT от документированного и ожидаемого не выявлено, в операциях чтения этот сигнал никогда не выдается.
Прошу прощения, я не понял вопрос, в какой момент процессор "вдруг выдает на шину WTBT"? Никаких отличий в поведении WTBT от документированного и ожидаемого не выявлено, в операциях чтения этот сигнал никогда не выдается.
Вот именно это я и хотел узнать.
Потому что контроллер ОЗУ ПП на него вполне себе реагирует, если выставить его во время чтения. Но я понял, что это побочный эффект универсальности схемы чтения/записи.
Начало чтения (DIN установлен) - на шине AD0..AD15 выставляется предыдущее слово, прочитанное из ОЗУ.
У меня это тоже получалось. Ставил опыты, делал маппинг ОЗУ при подключенном ПЗУ. И у меня было прочитано сложенное по ИЛИ значение ячейки ПЗУ и предыдущего чтения с ОЗУ, иногда прочитывался младший байт. При этом чувствовалось влияние предвыборки 1801ВМ2, т.к. в значение предыдущего чтения ОЗУ попадала следующая команда.
У меня это тоже получалось. Ставил опыты, делал маппинг ОЗУ при подключенном ПЗУ. И у меня было прочитано сложенное по ИЛИ значение ячейки ПЗУ и предыдущего чтения с ОЗУ, иногда прочитывался младший байт. При этом чувствовалось влияние предвыборки 1801ВМ2, т.к. в значение предыдущего чтения ОЗУ попадала следующая команда.
Не удивительно) Реверс все поставил на свои места)
На основе этого эффекта можно сделать супер-тест на совместимость с реальной УКНЦ)
Из интересного осталось чтение регистра октета 0177024. При его чтении значения регистров данных планов 0177012 и 0177014 просто раскидываются в регистры кода цвета фона 0177020 и 0177022.
Из интересного осталось чтение регистра октета 0177024. При его чтении значения регистров данных планов 0177012 и 0177014 просто раскидываются в регистры кода цвета фона 0177020 и 0177022.
Да, при чтении регистра октета, регистры планов 0, 1 и 2 раскидываются по регистрам фона 1 и 2. При этом процессор прочтет 0.
Непонятно зачем это сделано вообще)
Непонятно зачем это сделано вообще)
Это сделано, чтобы наложить изображение по старому фону. Если в регистр октета записать командой MOVB, то по фиктивному чтению сначала раскидаются данные в регистры кода цвета фона, а потом по записи наложится новое изображение на старый фон.
Это сделано, чтобы наложить изображение по старому фону. Если в регистр октета записать командой MOVB, то по фиктивному чтению сначала раскидаются данные в регистры кода цвета фона, а потом по записи наложится новое изображение на старый фон.
Это все понятно. Непонятно, зачем так раздельно сделали. Могли бы упихнуть это и в запись адреса планов, т.к. при этом записываются регистры планов 0, 1, 2 новыми значениями.
Это все понятно. Непонятно, зачем так раздельно сделали. Могли бы упихнуть это и в запись адреса планов, т.к. при этом записываются регистры планов 0, 1, 2 новыми значениями.
Этого нельзя делать, т.к. спрайтовый механизм используется для вывода символов. А при выводе символов цвет фона постоянный, регистры кода цвета фона 0177020 и 0177022 загружаются постоянными значениями. Если бы они загружались всё время при записи регистра адреса, то для вывода символа перед очередной записью в регистр октета всё время пришлось бы грузить регистры кода цвета фона. Вывод символов был бы очень медленным.
Этого нельзя делать, т.к. спрайтовый механизм используется для вывода символов. А при выводе символов цвет фона постоянный, регистры кода цвета фона 0177020 и 0177022 загружаются постоянными значениями. Если бы они загружались всё время при записи регистра адреса, то для вывода символа перед очередной записью в регистр октета всё время пришлось бы грузить регистры кода цвета фона. Вывод символов был бы очень медленным.
Для вывода на постоянном фоне не нужна загрузка планов из памяти, при установке нового адреса планов. Это совершенно лишнее медленное действие.
В общем, как не крути - косячно придумано.
Тогда уж следовало сделать так - при чтении октета - грузить планы из памяти. А при установке нового адреса планов, ничего не грузить. Но уже как сделано, так сделано.
Тогда уж следовало сделать так - при чтении октета - грузить планы из памяти. А при установке нового адреса планов, ничего не грузить. Но уже как сделано, так сделано.
А если мне не нужен спрайтовый механизм?
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot