|
Pentagon by Northwood
|
|
| Black_Cat | Дата: Среда, 01.07.2020, 16:12 | Сообщение # 1 |
 Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| 1. Сигналы DOS/, IODOS/ для NemoBus v.1.2
Цепи DOS/, DOS на выходе DD29 идущие на дешифрацию портов разорвать, и в разрыв врезать схему. Цепи, идущие на выборку ПЗУ оставить как есть.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Воскресенье, 27.09.2020, 11:19 | Сообщение # 201 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood (  ) При обращении к AY через OUT (#FD),A у тебя максимальный путь прохождения значих адресных сигналов A14 и A15 составляет целых 6 каскадов, один из которых ИД7. У меня только 4 каскада, один из которых ИД7.При обращении к порту #DFFD у тебя максимальный путь прохождения адресных сигналов составляет 4 каскада, один из которых ИД7. У меня только 2 каскада, один из которых ИД7.
Значение имеют только задержки после сигналов IORQG/, RD/, WR/, т.к. они укорачивают сигнал, поэтому мои схемы полюбому быстрее. Задержки до этих сигналов полностью, либо частично компенсируются более ранней валидностью адресов, и их надо считать токо на 14МГц, т.к. там валидность адресов наступает ранее, всего на ~30нс. Тем более что почти все безвейтовые порты у тебя пишутся по переднему фронту, что исключает проблемы с задержкой даж на 14МГц. А вот AY, и порты на чтение, как раз доступны токо по заднему фронту, и им задержки критичны. Чтение AY можно так исправить:
ЛЛ1 по любому быстрее ИД7 будет :) . Если в будущем где-то удастся сэкономить ЛА4+ЛЕ1, то задержку можно будет уменьшить в 2 раза.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Воскресенье, 27.09.2020, 11:47 | Сообщение # 202 |
 80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| 14) Где ты увидел конфликт с NemoIDE в моей схеме ?
а) Порт #1F, чёрным я выделил разряды, участвующие в дешифрации в моей схеме (A3=1, A5=0, A7=0):
0001 1111 (#1F)
0001 0000 (#10)
0001 0001 (#11)
0011 0000 (#30)
0101 0000 (#50)
0111 0000 (#70)
1001 0000 (#90)
1011 0000 (#B0)
1101 0000 (#D0)
1111 0000 (#F0)
1100 1000 (#C8)
б) Порт #DF, чёрным я выделил разряды, участвующие в дешифрации в моей схеме (A0=1, A1=1, A2=1, A5=0, A6=1 и A12=1, A15=1):
1101 1111 (#DF)
0001 0000 (#10)
0001 0001 (#11)
0011 0000 (#30)
0101 0000 (#50)
0111 0000 (#70)
1001 0000 (#90)
1011 0000 (#B0)
1101 0000 (#D0)
1111 0000 (#F0)
1100 1000 (#C8)
|
| |
| |
| Black_Cat | Дата: Воскресенье, 27.09.2020, 12:43 | Сообщение # 203 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) 13) В моей схеме для достижения того же результата что и у тебя, достаточно просто заменить A6 на A1 и всё.
На запись замешивать A1 низзя! Поэтому нужно разделение.
Добавлено (27.09.2020, 12:51)
---------------------------------------------
Цитата Northwood ( ) 14) Где ты увидел конфликт с NemoIDE в моей схеме ?
Дело в том, что сам интерфейс NemoIDE не ограничивается портами самого жёсткого диска, и обращаться к нему можно во всём диапазоне адресов xxxxxxxx xxxxx000, и по адресам xxxxxxxx 0x0x1000 будет конфликт. Ты не учитываешь весь возможный диапазон железа, та же ошибка у тебя и с конфликтом клавиатуры и портов #xxFD.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Воскресенье, 27.09.2020, 13:29 | Сообщение # 204 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) На запись замешивать A1 низзя! Поэтому нужно разделение.
Кто сказал, что нельзя ? Чем обосновано ?Добавлено (27.09.2020, 13:43)
---------------------------------------------
Цитата Black_Cat ( ) та же ошибка у тебя и с конфликтом клавиатуры и портов #xxFD.
Это смешно слышать. Основной бит дешифрации порта клавиатуры #FE - A0=0, а порта #xxFD - A1=0. Этого достаточно для разделения портов клавиатуры и #xxFD.
Сообщение отредактировал Northwood - Воскресенье, 27.09.2020, 13:38 |
| |
| |
| Black_Cat | Дата: Воскресенье, 27.09.2020, 13:44 | Сообщение # 205 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Кто сказал, что нельзя ? Чем обосновано ?
Тем, что в оригинале у #FE только A0, а у #7FFD токо A15, A1, и этим пользовались программисты, обращаясь по #7FFC сразу к двум портам.
Добавлено (27.09.2020, 13:51)
---------------------------------------------
Цитата Northwood ( ) Это смешно слышать. Основной бит дешифрации порта клавиатуры #FE - A0=0, а порта #xxFD - A1=0. Этого достаточно для разделения портов клавиатуры и #xxF
Ещё раз говорю - твоя ошибка, что ты рассматриваешь не адресный диапазон, который допускает железо, а программный диапазон адресов конкретного устройства.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Воскресенье, 27.09.2020, 13:52 | Сообщение # 206 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Дело в том, что сам интерфейс NemoIDE не ограничивается портами самого жёсткого диска, и обращаться к нему можно во всём диапазоне адресов xxxxxxxx xxxxx000, и по адресам xxxxxxxx 0x0x1000 будет конфликт.
Это тоже смешно слышать. В схеме NemoIDE контроллера в дешифраторе в самом начале проверяются разряды A1=0, A2=0, и если там будет 1, то обращения к HDD вообще не будет. Поэтому обращение к джойстику #1F и к мышке #DF по определению не могут создать конфликт с NemoIDE.Добавлено (27.09.2020, 13:56)
---------------------------------------------
Цитата Black_Cat ( ) Тем, что в оригинале у #FE только A0, а у #7FFD токо A15, A1, и этим пользовались программисты, обращаясь по #7FFC сразу к двум портам.
Это наверно такие же программисты, как и те, которые при обращении к памяти 128 КБ через OUT (#FD),A выставляли A15=1 ? Зачем мне поддерживать этот идиотизм, как обращение к какому-то #7FFC ?
И мне интересно услышать имена таких программистов и названия их творений с обращением к портам по адресу #7FFC.
|
| |
| |
| Black_Cat | Дата: Воскресенье, 27.09.2020, 13:58 | Сообщение # 207 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Это тоже смешно слышать. В схеме NemoIDE контроллера в дешифраторе в самом начале проверяются разряды A1=0, A2=0, и если там будет 1, то обращения к HDD вообще не будет. Поэтому обращение к джойстику #1F и к мышке #DF по определению не могут создать конфликт с NemoIDE.
:) Да без проблем, хочешь спалить NemoIDE или джой, прочитай в диапазоне адресов 0x0x1000, хочешь спалить клаву, или порты #xxFD - прочитай в диапазоне #xxFC.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Воскресенье, 27.09.2020, 13:59 | Сообщение # 208 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Ещё раз говорю - твоя ошибка, что ты рассматриваешь не адресный диапазон, который допускает железо, а программный диапазон адресов конкретного устройства.
Потому что я не обязан поддерживать то что не описано в документации. Есть стандартные порты #FE и #FD. Нормальные программисты обращаются к ним, а не пишут костыли типа OUT (#FC),A.Добавлено (27.09.2020, 14:03)
---------------------------------------------
Цитата Black_Cat ( ) :) Да без проблем, хочешь спалить NemoIDE или джой, прочитай в диапазоне адресов 0x0x1000, хочешь спалить клаву, или порты #xxFD - прочитай в диапазоне #xxFC.
Та ну ты утрируешь уже. Прямо таки спалить при первом же обращении к несуществующим портам.
|
| |
| |
| Black_Cat | Дата: Воскресенье, 27.09.2020, 14:06 | Сообщение # 209 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Это наверно такие же программисты, как и те, которые при обращении к памяти 128 КБ через OUT (#FD),A выставляли A15=1 ? Зачем мне поддерживать этот идиотизм, как обращение к какому-то #7FFC ?
Нет, A15=1 это самодеятельность кулибиных, отключавших в дешифрации A15, а обрашение по #7FFC вполне законное, т.к. соответствует дешифрации оригинала.Добавлено (27.09.2020, 14:09)
---------------------------------------------
Цитата Northwood ( ) Та ну ты утрируешь уже. Прямо таки спалить при первом же обращении к несуществующим портам.
:) правильно спроектированное железо не может иметь адресов, обращение к которым приводит в выходу из строя оборудования.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Среда, 30.09.2020, 00:15 | Сообщение # 210 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| 16. Страдания с #EFF7.
Я специально не упоминал в "комплексной простыне" порт #EFF7. И не упоминал я его из-за его спорности. Этот порт ввёл AloneCoder, и т.к. длительное время на его МГТФном Пентагоне это был единственный припаянный порт с незанятыми разрядами, то что токо он туда не цеплял, каждый раз провозглашашая это как всемирный стандарт :) . В результате, большая часть разрядов этого порта не раз сменила своё назначение, и последний опус AloneCoder'а на тему стандарта этого порта отражён в его вики: https://speccy.info/%D0%9F%D0%BE%D1%80%D1%82_EFF7 :) . Учитывая то, что когда AloneCoder провозглашал свои всемирные стандарты, он был в столь нежном возрасте, что даж не подозревал, что ТТЛ выходы низзя замыкать на землю :) , а так же учитывая то, что часть этих стандартов он сам уже и не поддерживает, то я бы воздержался от безоглядной поддержки алонекодеровского творчества :) . Из всего, что "натворил" в этом порту AloneCoder, на сегодняшний день не вызывает споров только D0, и с некоторым натягом ещё D1 и D7 #EFF7. Всё остальное либо спорно, либо уже не поддерживается самим автором. В т.ч. автором не поддерживается аппаратный мультиколор на D5 и 384х304 на D6. Более того, аппаратный мультиколор вааще нет смысла вешать на D5, т.к. мало того, что AloneCoder больше его не поддерживает, дык и единственные его софты, юзающие мультиколор, прекрасно работают и без аппаратного мультиколора, только с программным :). А никакие другие софты, D5 #EFF7 для аппаратного мультиколора и не поддерживают. Поэтому, смысла вешать этот видеорежим на D5 #EFF7 нет абсолютно никакого. Аналогично и с т.н. видеорежимом 384х304 - аффтар его давно уже не поддерживает, а больше, никому это уродство, размазанное аж по 64к даром не упало, и ни в одной, выпускающейся сейчас аппаратной архитектуре он не поддержан :) . Поэтому я не вижу смысла тратить на этот т.н. видеорежим, микросхемы и место на плате здесь. То же можно сказать и про D3 #EFF7 - я не знаю ни одного софта под Спектрум, где это используется. А учитывая, что тот же функционал есть у D0 #1FFD, то и смысла в аппаратной поддержке D3 #EFF7 не вижу абсолютно никакого.
Что касаемо аппаратного мультиколора, то единственный способ его аппаратной поддержки, оправдывающий затраты на него микросхем и места на плате, является поддержка этого видеорежима в архитектуре клона Спектрума Timex 2048 через порт #FF, т.к. этот порт сейчас поддерживают все западные архитектуры, включая ZX Spectrum Next (которых уже произвели 3150 шт, и ещё произведут 5200 шт), не говоря уже о других западных архитектурах, где этот порт является обязательным. Конечно, это не значит, что все вдруг начнут писать софт под аппаратный мультиколор. Нет, писать, конечно не станут существенно больше чем до сих пор. И причина тут в том, что затраты на перерисовку вдвое большего экрана в аппаратном мультиколоре превышают затраты на перерисовку стандартного экрана при программном мультиколоре. И этот факт практически убил этот видеорежим, оставив ему токо статические картинки.
И коль речь дошла таки до оправданности затрат на видеорежимы, то нельзя не упомянуть т.н. аппаратный гигаскрин. Могу судить по себе, шо каждый, дорвавшийся до паяльника самоделкин, считает своим долгом впилить в Спектрум аппаратный гигаскрин. При том не просто мигающий по кадрам, а мигающий с особым изъёбом - как у кого хватит фантазии - от через строку знакомест, до через знакоместо с инверсией в каждой строке :) . И всё это кулибинство разбивается о представления художников, пишущих под гигаскрин, о том как должна моргать их картинка :) . Увы, но художники, в своём большинстве хотят видеть картинку исходя из своих эстетических представлений, а не из того, какую моргалку изобретёт очередной кулибин :) . А т.к. никакого стандарта на все эти аппаратные моргалки до сих пор не было, то все художники ориентируются исключительно на собственные программные моргалки, и им даром не нужно никакое аппаратное творчество :) . Поэтому все эти аппаратные моргающие гигаскрины - это бездарный, ничем не оправданный просер полимеров и места на плате, и самое главное - не нужный самим художникам, пишущим под этот режим. Единственным оправданным аппаратным гигаскрином мог бы быть такой, где аналогово складываются цвета :) . Но! Во-первых, на паре элементов это не реализуешь. И главное - во-вторых, о5 же художники будут недовольны теми цветами, которые получаются :) . Поэтому, аппаратный гигаскрин - в топку вместе с 384х304!
Выводы: 1) Выпиливаем напрочь никем не поддерживаемый кривой режим 384х304 и аппаратный гигаскрин.
2) На #EFF7 ставим ТМ8 и в пару к ней вторую ТМ8 на #EDF7, в которую переносим функционал D3-D5 #FE37. На простыне уже подготовлены сигналы дешифраторов #EFF7/#EDF7 портов на запись и на чтение.
3) Разряды D0-D2 #FE37 переносим в #FF.
4) Разряды D5, D7 #FC37 и D7 #FE37 распределяются между #FD37/#FF37.
P.S. В аттаче предлагаемая дешифрация портов в соответствии с простынёй.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Среда, 30.09.2020, 09:52 | Сообщение # 211 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Порт #EFF7 в этом виде поддерживается в эмуляторе Unreal уже много лет, единственное что оттуда выпилили в последних версиях, это видеорежим 384х304. Лично я ничего с #EFF7 выпиливать и переносить на какие-то вообще никому неизвестные порты #EDF7, #ECF7, #EEF7 и т.д. не буду. Аппаратный гигаскрин тоже останется, кому он не нужен, могут выключить его в BIOS-Setup, а кому нужен, будут пользоваться. По-умолчанию он в BIOS-Setup будет выключен. Тем более останется на своём месте аппаратный мультиколор. Про порт #FF, включающий данный видеорежим, почитаю, но обещать, что продублирую его на порт #FF, не буду.
P.s. по реализованным видеорежимам тема закрыта. Единственное от чего я бы не отказался, это от доработки видеорежима 384х304, чтобы собрать в одно место размазанные по всей памяти куски экрана.
Сообщение отредактировал Northwood - Среда, 30.09.2020, 10:26 |
| |
| |
| Black_Cat | Дата: Пятница, 02.10.2020, 13:40 | Сообщение # 212 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Порт #EFF7 в этом виде поддерживается в эмуляторе Unreal уже много лет, единственное что оттуда выпилили в последних версиях, это видеорежим 384х304.
Только в NedoPC-шном эмуляторе, и только потому, что этот порт часть АТМного клона PentEvo. В TS-конфе и TS-Unreal поддерживается токо D0 и D7 #EFF7.
Какое отношение клон, что ты делаешь имеет к АТМ? Никакого! Ну дык и какая разница что там в NedoPC-шном эмуляторе поддержано? В этом эмуляторе не поддержаны порты KAY, Scorpion, Profi, не поддержано открытие портов по IODOS/, не поддержаны твои самопальные усовершенствования видеорежимов - тебя же это не останавливает. Так почему тебя должны волновать какие-то АТМ-ные порты, которые, например, не волнуют TSL-а? А в Спектракуляторе #EFF7 вааще нет все годы его существования - и что? На этом основании требовать его везде выпилить?
Кароче - ссылка на поддержку чего-то в Unreal бессмысленна! У тебя другой клон, и насрать чо там в Unreal'е, или ещё где-то поддерживается, или не поддерживается. Надо не кивать на какие-то псевдоавторитеты, типа AloneCodera, или NedoPC, а анализировать объективные факты собственной головой. А объективные факты я тебе уже изложил - 5 из 8 бит #EFF7 никому не нужны кроме АТМ-щиков, аппаратный гигаскрин и 384х304 - вааще никому не нужны, даж автору этого уродства - AloneCoder'у :) , а вот что нужно - это порт #FF и видеорежимы Таймекса 2048.
Другое дело - зачем они тебе? Одна гигаскринная моргалка - это больше 2х корпусов, я молчу про мультиплексоры что занимает этот ужас 384х304 :) . Ладно бы были какие супер новые перспективные видеорежимы, под которые возможно чото сделают в будущем - дык нет же, самый отстой, который гарантированно никому не нужен, при чём это всем понятно кроме тебя. Тебя что, привлекает перспектива стать примером для других как не надо делать? У тебя же не FPGA, в которой можно полностью концептуально лажануться, а потом с нуля переделать всю концепцию компьютера. У тебя чистый DIP Punk, где нет права на концептуальную ошибку. И поэтому, архитектура должна быть заранее буквально вылизана концептуально. А что имели у тебя - рыхрый, не продуманный франкенштейн, без какой-либо стержневой идеи (твоё, вполне понятное желание сделать замену МГТФ-ному монстру, за стержневую идею принять нельзя при всём желании :) ), сшитый на скорую руку белыми нитками. Нет никакой обосновательной базы ни под что. Ну вот представь, что ты сдаёшь этот проект госкомиссии, где тебя просят обосновать применение каждого узла. И что ты расскажешь? Про то, что у тёти Мани из Мухосранска тоже припаян #EFF7? Это по твоему основание? И шо в этом случае будут говорить о профессионализме разработчика, т.е. тебя, если ты не можешь даже обосновать выбор используемых узлов?
И не надо рассказывать, шо это хобби, и потому всё может быть понарошку. Этот проект - это твоё лицо! Сделаешь как AloneCoder, который замыкал на землю выходы микросхем изобретая 384х304, и о тебе тож будут всю оставшуюся жизнь говорить типа - а, это тот Нортвуд, шо сделал плату-обогреватель аж на 170 корпусов, четверть из которых он и сам не может объяснить зочем припоял, и которые токо греют воздух, и приближают всемирную экологическую катастрофу! :) Я утрирую. :)
Ну, а если без шуток, то принцип должен быть следующим - чем выше степень обоснования - тем выше приоритет реализации. Хотелки без основания никто не запрещает, но токо после того, как будут реализованы более обоснованные задачи. Если тезисно, то приоритетом в разработке является:
1) Что бы соотношение затраты/практическая полезность для пользователя было возможно максимальным, т.е. должно быть больше того, что обосновано, и меньше хотелок с потолка.
2) Что бы плата была актуальна не только вчера, но и в перспективе, т.е. разработка должна быть в струе трендов развития архитектуры Спектрума.
3) Плата в обязательном порядке должна иметь инновационные новшества, выделяющие её из ряда всего, что существовало ранее, т.е. то, что будет наделять плату уникальными свойствами. Это нужно в обязательном порядке, т.к. плата архитектурно довольно переутяжелена за счёт необязательных хотелок, и единственно возможным оправданием выбора пользователем такой переутяжелённой платы должны стать её уникальные возможности.
Этот проект среди других проектов хотелкиных, которые появляются чуть ли не каждую неделю, отличает довольно большое количество корпусов. Это выделяет его, и чтоб не получилось, что гора родила мышь, проект должен быть хоть как-то сбалансирован. Это значит, что в проекте должно быть столько полезного и нового качества, чтобы оправдывалось это количество. Изначально, проект был не сбалансированным аморфным нечто. Кроме хотелок от балды, и желания избавиться от МГТФа, в нём не было ничего. В первой фазе приведения проекта к божескому виду, благодаря универсальному менеджеру, АВМ и NemoBus, мы дали проекту стержень - то, что отличает его от других клонов, скелет, на котором уже можно наращивать мышцы. Щаз, после того, как мы зачистили тылы, выпрямив менеджер памяти и дещифрацию, появилась возможность перейти ко второй фазе - наращиванию на скелет мышц. И здесь надо отдавать себе отчёт, что мышцы - это то полезное, что будет способствовать продвижению проекта в будущем, а твои хотелки аппаратного гигаскрина и 384х304 - это бесполезные атавизмы, типа хвоста, или аппендикса, от которых хоть и вреда нет особого, но и пользы в плане продвижения проекта - никакой, патамушто они никому кроме тебя не нужны (да и нужны ли тебе - тож вопрос). И никто со стороны под конкретно эту моргалку и 384х304 ничего делать не будет, патамушто затраты программистов не окупаются ни в каком виде, даж в виде морального удовлетворения. Пэтому, надо не категорические заявления делать, а вдумчиво сесть, обсудить, что поможет проекту иметь развитие, и реализовать это. А атавизмы - пожалуйста, пускай будут, НО! после того, как будет реализовано всё первоочередное, необходимое для продвижения проекта!
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Пятница, 02.10.2020, 23:17 | Сообщение # 213 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Все реализованные видеорежимы останутся на месте, потому что я так хочу. Когда я их добавлял, я отталкивался от разработок, сделанных ранее другими людьми, идея Alone Coder-а с портом #EFF7 мне понравилась, видеорежимы тоже. И теперь мне абсолютно всё равно на то, кто где это поддерживает или нет и на то, кто что по этому поводу думает.
Кроме этого, ты не учитываешь, что моя реализация видеорежимов сильно выигрывает по сравнению с реализацией, которую делал Alone Coder.
Например "16 Colors" - каждый пиксель своим цветом. Для этого видеорежима требуется в 2 раза больше чтений данных из ОЗУ. Если стандартный видеорежим за один период равный 4/3,5 МГц из ОЗУ данные читает 2 раза - один раз читаются пиксели, второй раз атрибуты, а оставшиеся другие 2 такта ОЗУ отдаются процессору, то "16 Colors" за этот же промежуток времени данные читает 4 раза - один байт описывает 2 пикселя, 4 чтения = 8 пикселей. Поэтому в реализации Alone Coder-а ему пришлось останавливать процессор сигналом BUSRQ/ на время отрисовки экранной области, что снижает производительность компьютера рвза в 2 при увеличенном в 3,5 раза количестве данных экрана. Именно поэтому его демка NedoDemo требует наличие КЕШ-памяти. Ещё один недостаток реализации AloneCoder-а - у него на экране теряется последний столбец из-за сложности преодоления возникших трудностей. Т.е. в строке у него не 256 пикселей, а 248.
В моей реализации память работает на частоте 7 МГц, что за этот же период 4/3,5 МГц даёт 8 тактов доступа вместо 4-х, это дало мне возможность не останавливать процессор даже в режиме Турбо 7 МГц в любом видеорежиме. В Турбо 7 МГц 4 такта идут на видеорежим и 4 такта процессору. Поэтому если в видеорежиме "16 Colors" включить Турбо 7 МГц, то по сравнению с AloneCoder-овским вариантом, мой работает примерно в 4 раза быстрее. WAIT-а нет (кроме как для медленных портов). Кроме этого, в моей реализации "16 Colors" доступна полностью вся экранная область - все 256 х 192 пикселей, без никаких потерь. Единственный нюанс, с которым я справился, это то что при включении видережимов "16 Colors" и "512х192" данные для экрана из турбированного ОЗУ читаются немного раньше и немного ранее выводятся на экран, поэтому мне пришлось при включении этих видеорежммов немного сместить бордюрную область влево, чтобы не усложнять схему дополнительным буфером экрана и при этом не потерять ни единого пикселя.
Ещё раз повторю, по видеорежимам тема закрыта. Обсуждать, что оттуда выкинуть, а что оставить, как перекроить порт #EFF7, я не буду. Всё останется как есть.
Если у тебя возникнут идеи, как доработать видеорежим 384х304 пикселей, чтобы в одно место собрать куски экрана, то с удовольствием выслушаю.
P.s. обнаружил и устранил ошибку в формирователе кадрового синхроимпульса. Ошибка заключается в том, что длительность KSI вместо положенных по стандарту 160 мкс, у меня была 173.7 мкс. Для исправления нужно на DD145:1 сигнал H4 заменить на H2.
Сообщение отредактировал Northwood - Пятница, 02.10.2020, 23:21 |
| |
| |
| Black_Cat | Дата: Суббота, 03.10.2020, 01:37 | Сообщение # 214 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Кроме этого, ты не учитываешь, что моя реализация видеорежимов сильно выигрывает по сравнению с реализацией, которую делал Alone Coder.
Ну, это не фокус :) . Это вполне естественная переделка, и она есть например у TSL в его TS-конфиге :) . И даж на Пенте 2.2, DDp устранял эти алонекодерские косяки с последним столбцом, остановкой процессора вместо захвата шины :) , просто Алонекодер, по ходу, не очень хорошо знал режимы работы Z80 :) . Хотя, более реальное объяснение состоит в том, что эти видеорежимы вааще не имеют к Алонекодеру никакого отношения, он их тупо скопипастил ничего не понимая из фидо, прикрутив на свободные разряды припаянного у него #EFF7, и пропиарил софтом как своё изобретение :) .
Объясни. а зачем конкретно тебе 384х304? Про не размазанный 384х304 даж не думал никогда, алонекодеровское недотворчество вызывает у меня чувство инженерной брезгливости :) . Зочем этот ужос, если есть 100500 всяких красивых, и самое главное - полезных реализаций усовершенствования спековских видеорежимов :)
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Суббота, 03.10.2020, 21:20 | Сообщение # 215 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Подробно проанализировал реализацию видеорежима 384x304 (кстати, реально доступное разрешение в моей схеме выходит 368x304 пикселя, остальные 12 пикселей в строке перекрываются строчным гасящим импульсом, 4 пикселя в начале экрана и 8 пикселей в конце, ещё какую-то часть может съесть сам телевизор).
Как минимум, можно внести 2 маленькие доработки, улучшающих видеорежим:
1) В оригинале по горизонтали, рассматриваем только середину по вертикали:
При включении этого видеорежима центральная область экрана - пиксели с атрибутами с адресов #4000-#5AFF переносится в адреса #6000-#7AFF.
Адреса #4000-#5AFF занимает боковая правая и левая части экрана, но только 50% от всего адресного пространства, целые занятые куски имеют размер по 8 байт, пробелы тоже имеют размер по 8 байт. Т.е. эта область напоминает голландский сыр. Поэтому незанятые 50% пространства использовать никак нельзя.
Единственное, что можно здесь сделать, это вернуть центральный экран на своё законное место в адреса #4000-#5AFF, поменяв его с боковой частью. Т.е. теперь адреса #6000-#7AFF будут занимать боковая правая и левая части и именно эта область будет напоминать голландский сыр. Для этого нужно на DD94 (КП12) на выв.4 подать инверсную версию сигнала H5.
2) В оригинале по вертикали, рассматриваем только середину по горизонтали:
Верхняя и нижняя части экрана занимают 4-ю страницу ОЗУ:
Верхняя часть экрана - пиксели занимают адреса неразрывно #C000 - #C7FF, но атрибуты вместо ожидаемого #D800-#D8FF занимают адреса #D000-#D0FF
Нижняя часть экрана - пиксели занимают адреса #D800-#DFFF, т.е. вместо ожидаемых атрибутов (но только 75% этого пространства, остальные 25% попадают под кадровый гасящий импульс), атрибуты же занимают адреса #D300-#D3BF
Т.е. такая раскладка экрана по вертикали - сущий ад для программистов.
Но можно сделать доработку:
а) От DD136 (КП11) от выв.13 отрываем сигнал "384_A11" и вешаем туда законные +5V;
б) Сигнал V7, перед тем как подать на DD79:1 (ЛЛ1) выв.1 и на DD136 (КП11) выв.6, пропускам через ключ: В случае, если включен видеорежим "384х304" и у нас вертикальный бордюр, то обнулять сигнал, во всех остальных случаях пропускаем сигнал.
Это даст следующие улучшения:
Верхняя и нижняя части экрана по прежнему занимают 4-ю страницу ОЗУ:
Верхняя часть экрана - пиксели занимают адреса неразрывно #C000 - #C7FF, атрибуты вернутся на своё законное место #D800-#D8FF;
Нижняя часть экрана - пиксели переместятся на адреса #C800-#CFFF, (но только 75% этого пространства), атрибуты вернутся на своё законное место - на адреса #D900-#D9BF (с учётом 75% доступной экранной области).
Т.е. мы получим соединение в единое целое 2-х кусов области пикселей - #C000 - #C8FF, и 2-х кусков области атрибутов #D800 - #D9BF, которые кроме этого, снова занимают законные адреса без выноса мозга программистам.
Если будет интересно детально узнать, что будет происходить в угловых частях экрана до и после доработок, можно будет посчитать это с помощью двоичной арифметики исходя из имеющихся данных.
Код С 1-й доработкой:
V-середина
Пиксели Атрибуты
H-правая H-левая H-правая H-левая
#6008 - #600F , #6018 - #601F #7808 - #780F , #7818 - #781F
#6028 - #602F , #6038 - #603F #7828 - #782F , #7838 - #783F
............................. .............................
#60E8 - #60EF , #60F8 - #60FF #78E8 - #78EF , #78F8 - #78FF
#6108 - #610F , #6118 - #611F #7908 - #790F , #7918 - #791F
#6128 - #612F , #6138 - #613F #7928 - #792F , #7938 - #793F
............................. .............................
#61E8 - #61EF , #61F8 - #61FF #79E8 - #79EF , #79F8 - #79FF
.............................
#7708 - #770F , #7718 - #771F #7A08 - #7A0F , #7A18 - #7A1F
#7728 - #772F , #7738 - #773F #7A28 - #7A2F , #7A38 - #7A3F
............................. .............................
#77E8 - #77EF , #77F8 - #77FF #7AE8 - #7AEF , #7AF8 - #7AFF
------------------------------------------------------------------
Без 2-й доработки:
V-верхняя, H-середина
Пиксели Атрибуты
#C000 - #C7FF #D000 - #D0FF
V-нижняя, H-середина
Пиксели Атрибуты
#D800 - #D8BF #D300 - #D3BF
#D900 - #D9BF
#DA00 - #DABF
#DB00 - #DBBF
#DC00 - #DCBF
#DD00 - #DDBF
#DE00 - #DEBF
#DF00 - #DFBF
----------------------------------
После 2-й доработки:
V-верхняя, H-середина
Пиксели Атрибуты
#C000 - #C7FF #D800 - #D8FF
V-нижняя, H-середина
#C800 - #C8BF #D900 - #D9BF
#C900 - #C9BF
#CA00 - #CABF
#CB00 - #CBBF
#CC00 - #CCBF
#CD00 - #CDBF
#CE00 - #CEBF
#CF00 - #CFBF
Я рассматривал вариант сделать в видеорежиме 384х304 полностью неразрывный экран, но понял, что это не реально:
а) Нужно полностью переделывать счётчики - по-другому реализовывать сброс горизонтальных и вертикальных счётчиков, смещать синхроимпульсы и импульсы гашения.
б) Т.к. в строке из 384 пикселей у нас будет 48 байт, что в 16-виде 0x30, а в двоичном 0011 0000, мы видим, что новая строка начинается единицами в двух разрядах, а это означает, что невозможно однозначно отделить биты адреса, отвечающие за столбцы, от битов адреса, отвечающих за строки. В компьютере "Орион-128" как-то справились с этой задачей, но очевидно, что в Спектруме это потребует колоссальных переделок и невероятно сложную коммутацию.
Поэтому сделать в Спектруме неразрывный экран разрешением 384х304 пикселей невозможно по определению.
Сообщение отредактировал Northwood - Воскресенье, 04.10.2020, 01:22 |
| |
| |
| Black_Cat | Дата: Суббота, 03.10.2020, 23:00 | Сообщение # 216 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Я рассматривал вариант сделать в видеорежиме 384х304 полностью неразрывный экран
Что в твоём понимании "полностью неразрывный экран"? Экран на все 8к?
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Суббота, 03.10.2020, 23:50 | Сообщение # 217 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Что в твоём понимании "полностью неразрывный экран"? Экран на все 8к?
При разрешении 384х304, пиксели без атрибутов занимают 14 КБ, да, чтобы эта область была одним целым.
|
| |
| |
| Black_Cat | Дата: Воскресенье, 04.10.2020, 01:23 | Сообщение # 218 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Странно, 384х304 самый непригодный ни для чего режим, и именно он почему-то тебя заинтересовал :) . Вертикальную прокрутку на 2к в пределах 8к позволяют делать графические режимы HiRes (512х192), HiColor (MultiColor), 16color, а так же гибрид HiRes&HiColor. Собсно последний - это расширенный цветной видеорежим Profi, у которого вместо прокрутки расширили экран по вертикали. Я как раз кроме порта #FF, хотел предложить тебе в том числе эмулировать экран Profi. Т.е. не расширять экран по вертикали, а эмулировать увеличенный экран сдвигом на треть, экрана на 192 строки. Кривовато, но зато элементарно реализуется. А добавив остаток сигналов DFFD, получаем практически Profi :) .
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Воскресенье, 04.10.2020, 01:49 | Сообщение # 219 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) а так же гибрид HiRes&HiColor. Собсно последний - это расширенный цветной видеорежим Profi, у которого вместо прокрутки расширили экран по вертикали.
У меня этот гибрид включается, если через #EFF7 одновременно включить оба видеорежима - 512х192 и мультиколор, а так же в BIOS-Setup через порт #FE37 включить цвет. Для расширенного экрана Профи не хватает только 4-й "трети" экрана по вертикали. Как я понимаю, дополнительная треть экрана должна занять адреса стандартных атрибутов, поэтому данный режим возможен исключительно в мультиколоре. Вот только смотреться этот смещённый вниз до края экран будет убого, нужно центровать по вертикали смещением кадровых сингроимпульсов и кадровых импульсов гашения.
Добавлено (04.10.2020, 02:18)
---------------------------------------------
Если добавить 4-ю треть, это будет 192 + 64 = 256 строк. Получится квадратный экран с разрешением 512 х 256, но при условии, если сдвинуть кадровые синхроимпульс и кадровый гасящий импульс, иначе последние 16 строк будут перекрываться кадровым гасящим импульсом и разрешение получится 192 + 48 = 240 строк, т.е. 512 х 240.
Сообщение отредактировал Northwood - Воскресенье, 04.10.2020, 02:27 |
| |
| |
| Black_Cat | Дата: Воскресенье, 04.10.2020, 11:33 | Сообщение # 220 |
|
Координатор
Группа: Координаторы
Сообщений: 718
Статус: Offline
| Цитата Northwood ( ) Если добавить 4-ю треть, это будет 192 + 64 = 256 строк. Получится квадратный экран с разрешением 512 х 256, но при условии, если сдвинуть кадровые синхроимпульс и кадровый гасящий импульс, иначе последние 16 строк будут перекрываться кадровым гасящим импульсом и разрешение получится 192 + 48 = 240 строк, т.е. 512 х 240.
Ты невнимательно читал, что я предлагал :) . Я не предлагал растягивать видимый экран по вертикали, т.к. это требует слишком много переделок. На ранних Windows была функция прокрутки экрана, если разрешение монитора было меньше разрешения видеокарты. Вот это я и предлагаю сделать. При том не плавную прокрутку, а упрощённую - либо отображение четвертей 1,2,3, либо 2,3,4. Костыльно конечно, но зато дёшево и сердито :) . В идеале - привязать это ещё к кнопке клавы, или кнопке колеса мыши, и получаем вполне юзабельный экран Profi с вменяемой навигацией при минимальных аппаратных затратах :) .
И такой функционал сдвига на четверть можно было бы применить ко всем перечисленным мною выше видеорежимам, получая программный экран 256х256 или 512х256 при реальном аппаратном окне токо в 192 строки, что является спектрумовским стандартом, изменять который не рационально, т.к. затратно. Вот так просто отпадает нужда во всяких кривых 384х304 :) .
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
|
