Мерцание - штука мало востребованная, возможно, лучше было бы иметь флаг яркости.Цитата:
Сообщение от SuperMax
Вид для печати
Мерцание - штука мало востребованная, возможно, лучше было бы иметь флаг яркости.Цитата:
Сообщение от SuperMax
на управление яркостью уже выделено по 5 бит на канал ;-)Цитата:
Сообщение от mdk
иначе говоря у нас есть техническая возможность отображать 15bit -> 32768 цветов
Вопрос по регистрам палитры
как я представляю:
для поддержки legacy режима 256х256
сделаю 4 регистра с палитрой (соответственно на каждую пару бит)
их можно будет крутить как угодно - выставляя лбое 15бит значение
(теперь можно будет менять цвет фона)
адреса - к примеру
177400-177406
для 512х256 будет работать пара 177400 (точка) и 177406 (нет точки)
при установки палитры через legacy регистр 177662, регистры 177400-177406 будут заполняться значениями соответствующими стандартной палитре БК11М
тем самым сохраняется полная совместимость с гибкостью
однако не все так просто:
рассматривая видеорежимы с большим числом цветов приходит понимание, что расходовать адресное пространство под регистры палитры не самая хорошая идея и тем более не правильно расходовать ресурсы ПЛИС под эти регистры.
Соответственно рождается другая концепция
два регистра
первый - адрес ячейки палитры
второй - значение палитры 15bit
получается, что для режима с 16тю цветами будут актуальны первые 16 палитр, для 256 цветов - 256ячеек
концепция совместимости с заполнением стандартными значениями сохраняется.
недостаток этой концепции один - для изменения значения палитры потребуется 2 операции - установка адреса и уже потом установка ее значения
нет возражений/предложений ?
вопрос - критично ли доступность этой палитры на чтение ?
----------
далее размышляя над возможностями видеосистемами, приходит идея с адресами строк: [как я понимаю в союз-неоне это как раз и сделано?]
те получается еще 3 регистра:
1. номер строки - 0-767
2. адрес - старшие 8bit
3. адрес - младшие 16bit
иначе говоря можно адресовать все 32МБ памяти как видеопамяти [за исключением служебной части, возможно будет сделано разделение банков]
нет возражений/предложений ?
Желательно, так можно будет не хранить копию таблицы палитр в основной памяти, а модифицировать значения прямо в регистрах.Цитата:
Сообщение от SuperMax
Про видеосистему.
Аппаратный вертикальный, горизонтальный скроллинг планируется?
Битпланы реализовать возможно? С независимым скроллингом. Чтобы прям аппаратно спрайты двигать.
А ещё можно оставить на адрес только один регистр 16 бит, там будет не абсолютный адрес, а смещение, padding, или как там его.
{Абс.адрес строки} = padding * {ширина строки в байтах}
Что-то типа сегментного регистра в 80286. Потому что у строки есть фиксированная ширина, и предполагается, что строки не должны пересекаться.
okЦитата:
Сообщение от gid
вертикальный - штатный регистр 177662Цитата:
Про видеосистему.Аппаратный вертикальный, горизонтальный скроллинг планируется?
обдумаюЦитата:
Битпланы реализовать возможно? С независимым скроллингом. Чтобы прям аппаратно спрайты двигать.
тк я изначально хотел сделать спрайты отдельно
мысль понял. обдумываю,Цитата:
А ещё можно оставить на адрес только один регистр 16 бит, там будет не абсолютный адрес, а смещение, padding, или как там его.
{Абс.адрес строки} = padding * {ширина строки в байтах}
Что-то типа сегментного регистра в 80286. Потому что у строки есть фиксированная ширина, и предполагается, что строки не должны пересекаться.
у строки будет задаваться максимальная длина, а в остальном без ограничений
Неужели будет поддержка AZ в вашем эмуляторе? :)Цитата:
Сообщение от gid
Мысль такая есть. Пока я жду, когда сформируется ТО на изделие, чтобы иметь представление, как оно должно функционировать, и с какого боку к нему подступиться. А заодно отдыхаю от умственных нагрузок, поэтому не хочу бежать впереди паровоза.
Попытка прикрутить эмулятор Менестреля, которая успехом не увенчалась, - показатель того, что я пока не в состоянии нормально функционировать.
Это было бы шикарно :) На реальной БК писать можно, конечно, но в эмуляторе средств отладки значительно больше.Цитата:
Сообщение от gid
c палитрой будет так:
нумерация кодов цветов
палитра коды цветов (адреса ячеек палитры)
256 0-256
16 256-272
4 273-276
2 277-278
разделение палитр без пересечения исключит необходимость перегрузки палитры при каждом изменении отображения
для инициализации палитр при старте сделал калькулятор
https://forum.maxiol.com/index.php?a...t=0#entry55113
он также пригодится для разработчиков тк упаковывает RGB в 15bit цвет
ВП1-37 вообще не выдаёт никаких бит. Через неё проходит только шина адреса. Всё, что она делает -- это раз в 8 тактов частоты 6 МГц выдаёт строб записи в регистр видеовывода. Дальнейшие события к ней не имеют никакого отношения.Цитата:
Сообщение от Manwe
Конкретно в БК-0010 сделано так: параллельно стоят два 8-битных сдвиговых регистра, один из которых содержит чётные, а второй -- нечётные биты слова. Они оба сдвигаются вправо с частотой 6МГц. Младшие два бита определяют цвет одной точки на "цветном" выходе, либо яркость двух точек на чёрно-белом через мультиплексор, управляемый фазой частоты 6 МГц.
Дополнительно, в 11М "цветной" двухбитовый код используется как часть адреса ПЗУ палитр. Кстати, в ПЗУ использована только четверть ёмкости, остальное забито нулями.
Частота 12 МГц нигде в БК не используется и есть только внутри генератора тактовой частоты.
- - - Добавлено - - -
Логика 037 построена вокруг словных циклов, с частотой следования 6МГц/8. В строке таких циклов 48, что даёт стандартную длительность ТВ строки в 64мкс. 32 цикла используются для построения изображения, остальные 16 -- горизонтальное гашение. В каждом цикле одна половина отдаёётся видеоконтроллеру, даже на полях гашения, вторая может быть отдана процессору.Цитата:
Сообщение от SuperMax
Это место, кстати, сделано криво, и 037 никак не может отдать процессору более половины временных окон доступа. Конкретно в десятке процессору достаётся максимум одна треть, что и определяет минимальное время исполнения команды в 12 тактов частоты 3 МГц. При более вменяемой реализации контроллера памяти можно было бы иметь пиковое быстродействие в полтора раза больше, если не ошибаюсь.
Статус на сегодня:
0. палитры работают как и описано ранее.
1. куча автоматов контроллера памяти SDRAM заработала
обслуживаются 3 запроса
- простое чтение слова
- пакетное чтение
- запись слова/байта
2. запросы будут поступать от
- чтение МПИ [уже работает]
- запись МПИ [уже работает]
- пакетное чтение строки для VGA [уже работает]
- чтение STM32 [в этапе проектирования]
- запись STM32 [в этапе проектирования]
3. арбитраж запросов - обслуживание запросов к оперативке согласно приоритета
максимальное ожидание данных ~600нс в случае конкуренции с уже выполняющимся длинным запросом
цикл записи - полностью синхронный - те RPLY идет сразу
цикл чтения - 120нс
+ есть еще поле для оптимизации
4. сейчас делаю маппер памяти - придумываю как сделать его универсальным тк стоит задача:
- область перехвата - те копия станиц оперативки
- область эмуляции ROM - выделил 256КБ под всякие ПЗУ которые будут подключаться как в эмуляторе из меню
- 512КБ под SMK
- и вся остальная память
5. если интересно есть промежуточная версия которая грузит модифицированное ПЗУ КНГМД + работает с диском (образом дискеты)
сейчас ближайший план такой
- полный перехват ОЗУ в SDRAM - дабы можно было вывести на экран любую страницу памяти - как минимум для отладки
- полный вывод VGA уже из SDRAM [тк сейчас из внутриплисовой памяти]
[пока без новых режимов но они уже заложены в архитектуру]
- подключение STM к оперативке и операции с ней, загрузка ПЗУ
Можете меня поздравить! я таки запилил ф-ю ручного переключения видеорежимов!!!!
использую сочетание AR2 + KT
те можно будет перейти в монохром там где надо и в цвет где надо
- - - Добавлено - - -
Статус на сегодня:
добавилось:
1. полная теневая память БК11М в SDRAM
2. ручное переключение видеорежима (циклическое 1-2-3-4) по сочетанию AR2+KT
3. сделан маппер памяти + разделение по сегментам:
- область перехвата - те копия станиц оперативки
- область эмуляции ROM - выделил 256КБ под всякие ПЗУ которые будут подключаться как в эмуляторе из меню
- и вся остальная память
4. полный вывод VGA уже из SDRAM, переключение страниц
[пока без новых режимов, но они уже заложены в архитектуру]
5. проведен рефакторинг кода VGA-модуля, унификация под 65MHz и отказ от 130MHz
план ближайший:
- перехват переключения палитр БК11М
- доступ к памяти палитр с шины, чтение+запись
- подключение STM к оперативке и операции с ней, загрузка ПЗУ согласно конфига
Супер! Ждем дальнейших успехов! )
Переделал палитры
концепция прежняя - полная гибкость, но я ее еще расширил:
управление палитрами будет через 2 регистра палитры первый - адрес ячейки палитры
второй - значение палитры 15bit
адреса ячеек палитры будут начинаться с большей
так получается полностью независимые палитры без пересеченийКод:нумерация кодов цветов
палитра коды цветов (адреса ячеек палитры)
256 0-255
4x16 320-335
16 256-319
2 336-337
+ явный дубль стандартного функционала палитр, те можно переключать палитры как и ранее, но теперь доступна опция настройки каждой штатной палитры!
и как следствие палитры не надо будет перегружать при переключении видеорежима
для удобства формирования палитр сделал эксельку
https://forum.maxiol.com/index.php?s...ndpost&p=55113
основная задача этой эксельки - сформировать файл mif для загрузки дефолтной палитры при старте ПЛИС
также она пригодится разработчикам для пересчета цветов в 15bit
пояснения к блоку 4x16 320-335
это 16 наборов палитры, изначально туда грузятся штатные значения, но их можно менять на любые!
нумерация прямая - те нулевая палитра это 320-321-322-323 ячейки
следующие 4 ячейки это 1ая палитра и так далее
Концепция работы с памятью
https://forum.maxiol.com/index.php?s...ndpost&p=55394
предложения принимаются
Статус на сегодня
0. палитры, сделано расширение функционала механизма палитр
подробнее https://forum.maxiol.com/index.php?showtopic=5556
1. куча автоматов контроллера памяти SDRAM заработала
обслуживаются 3 запроса
- простое чтение слова
- пакетное чтение
- запись слова/байта
- чтение STM32
- запись STM32
2. запросы будут поступать от
- чтение МПИ [уже работает]
- запись МПИ [уже работает]
- пакетное чтение строки для VGA [уже работает]
- чтение STM32 [в процессе отладки]
- запись STM32 [в процессе отладки]
- чтение "DMA" для фоновых процессов - музыка итд
3. арбитраж запросов - обслуживание запросов к оперативке согласно приоритета
максимальное ожидание данных ~600нс в случае конкуренции с уже выполняющимся длинным запросом
цикл записи - полностью синхронный - те RPLY идет сразу
цикл чтения - 120нс
+ есть еще поле для оптимизации
4. реализовано ручное переключение видеорежима (циклическое 1-2-3-4) по сочетанию AR2+KT
те можно спокойно переключать его в зависимости от программы не напрягаясь!
5. сделан маппер памяти + разделение по сегментам:
- область перехвата - те копия станиц оперативки
- область эмуляции ROM - выделил 256КБ под всякие ПЗУ которые будут подключаться как в эмуляторе из меню
- и вся остальная память
6. полный вывод VGA уже из SDRAM, переключение страниц
[пока без новых режимов, но они уже заложены в архитектуру]
7. проведен рефакторинг кода VGA-модуля, унификация под 65MHz и отказ от 130MHz
8. перехват переключения палитр БК11М
- доступ к памяти палитр с шины, чтение+запись
9. Генератор псевдослучайных чисел - технически это LFSR длиной 128бит, младшие 16 в регистре доступном программно.
сдвиг идет с частотой 50MHz (или 65Mhz-посмотрим) как следствие полностью новое слово доступно будет каждый такт
Сейчас процессе:
- STM и операции с ней, загрузка ПЗУ согласно конфига
Обновление документации: консоль и секция загрузки ПЗУ
Контроллер AZ BK: Документирование процесса разработки
Выпустил прошивку - дабы уже можно было побаловаться палитрами и прочим
Контроллер AZ BK: Прошивка 00002
На БК11М и СМК невозможно из программы узнать текущее распределение памяти, приходится самому хранить информацию какие страницы куда включены и надеяться, что это так :) Хорошо бы такую возможность в AZ сделать )
да, в SMK есть такое упущениеЦитата:
Сообщение от grf
я планирую утрясти запросы SMK в модель управления памятью AZ где вся память управляется через явные регистры окон
соответственно если это получится, то состояние мапирования через SMK можно будет считать через регистры маппера AZ
С СМК есть проблема: http://bk0010.forum20.ru/forum/?id=37741
AZ не будет страдать таким глюком?
как я понимаю да ибо придется тащить всю логику с SMK втч иЦитата:
Сообщение от grf
"В режимах 160 и 120 по адресам 140000-157777 происходит наложение ОЗУ СМК на ПЗУ БОС БК11."
что изначально должно вызывать глюки
но можно отказаться от наложения и подсовывать окна памяти только туда, куда можно не вызывая конфликтов
Глюки происходят только на новоделе + СМК, а оригинальная БК с СМК работает как положено. Так что сэмулировать надо правильное поведение ОЗУ, на возникающие глюки никто не затачивает программы )Цитата:
Сообщение от SuperMax
Я, собственно, спрашивал о том, не окажется ли AZ в такой же ситуации, что новодел с быстрой памятью тоже не сможет из него читать без всяких режимов эмуляции СМК?
Ещё вы не учитываете такой нюанс: у СМК 8 режимов работы, из них 4 предназначены для работы с БК10, и остальные 4 - для БК11.
То, что режимы работы с БК10 на БК11 использовать можно, ещё не означает, что это правильно и целесообразно.
И вообще, если бы делать по-нормальному, надо было бы делать не 16 страниц по 32 кб, из которых можно использовать по назначению только половину в каждый момент времени, а делать 32 страницы по 16 кб, и два независимых окна, на 100000-137777 и 140000-177777 с той же логикой, что и сейчас. Но тогда нужно делать отдельный регистр, т.к. в 177130 битов на такое не хватает. И если бы так сделали изначально, то плата получилась бы в 2-2,5 раза больше по площади и по корпусам больше примерно в столько же. Тогда бы такой контроллер стоил сильно дороже и его мало кто купить смог бы.
я возможно не совсем понял ситуацию - прошу поправить меня если я не прав:Цитата:
Сообщение от grf
1. SMK изначально работает некорректно накладывая ОЗУ и ПЗУ. Само по себе наложение уже есть источник конфликта.
те кто первый выставит RPLY, те данные будут приняты процессором, НО это прокатит только в том случае, если опоздание у второго абонента (как я понял это ОЗУ) будет достаточно большим
иначе, будет наложение информации в ответе будет мусор.
2. на обычной машине ПЗУ быстрее, чем ОЗУ, и как следствие разница во времени выставления RPLY достаточная и на чтение успешно отвечает ПЗУ, а ответ ОЗУ маскируется.
3. на быстром ОЗУ ответ идет почти одновременно и возникает конфликт на шине.
Соответственно в AZ конфликт устранить просто:
те я просто не буду отвечать на чтение в ОЗУ если у нас есть ПЗУ. В случае реплики, конфликт изначально не возможен тк ПЗУ у меня эмулируется той же памятью и одновременный ответ в принципе не является возможным.
И у меня вопрос а зачем наложение-то ? те какое практическое применение ?
- - - Добавлено - - -
я сейчас сделал разбивку всего адресного пространства на окна по 4кБ - те всего 16 оконЦитата:
Сообщение от gid
и каждому окну соответствует регистр с адресом (и дискретность получается в 4кБ)
так, я думаю будет удобно работать
на счет модели с ПЗУ думаю
может сделаю масочный регистр который будет задавать тип ответа на обращение
но сейчас при нагрузочном тесте оперативки из STM32 обнаружили глюки, соответственно ловим. а пока принимаются идеи.
Нет, СМК не работает некорректно, он изначально так задуман, это такая фича. И те, для кого наложение есть источник конфликта, сами и виноваты, надо использовать изделие не произвольно, а строго так, как было задуман разработчиком. А то, что рамки использования при этом резко сужаются, ну, зато не заоблачно дорого. Помните, в какое время контроллер разрабатывался? Какие цены и какая инфляция тогда была, все миллионерами были.Цитата:
Сообщение от SuperMax
Так и есть, это подтверждается разной работой реплики СМК и оригинального СМК-64 с оригинальной БК-11М. Причём как раз, то, что в реплике наложения не ощущается, очень расслабляет, а потом встреча с реальностью становится более тяжёлой.Цитата:
Сообщение от SuperMax
Нет, такой ситуации не возникает.Цитата:
Сообщение от SuperMax
там в оригинальном СМК использовалось ОЗУ, что-то типа HM64256LP-15, а RPLY выставляется логикой серии 555, что получается примерно как у БК по времени. Поэтому на шине получается электрическое ИЛИ из данных ПЗУ и ОЗУ.Цитата:
Сообщение от SuperMax
А в реплике СМК RPLY выставляется ФПГА, делается это достаточно быстро, так, что ПЗУ БК ещё не успевает выставить своё RPLY поэтому с шины успевают прочитаться данные из ОЗУ СМК
Кстати, там не только на ПЗУ наложение, в режиме 100 на БК11 происходит наложение ОЗУ СМК на ОЗУ БК, правда как раз этот режим и предназначен для БК10 и на БК11 не рекомендуется.
Низачем, ну вот так вот получилось. Потому что, для всего этого используется одна единственная микросхема К555ТМ9, она хранит код режима, и один из битов (бит 6) является сигналом к отключению ПЗУ. Если усложнять схему, то получится дороже, больше корпусов, двухэтажная плата. Дорого. Вот насколько я помню, СМК-128 уже не взлетел, было продано единичное кол-во экземпляров, а там всего лишь вторым этажом было напаяно ещё две микросхемы ОЗУ на ОЗУ.Цитата:
Сообщение от SuperMax
Тут, это, чем больше окон и чем они меньше, тем большее время тратится на переключение страниц в окнах. Иногда это бывает критично, в демках например.Цитата:
Сообщение от SuperMax
Может лучше сделать 8 окон по 8Кб как заповедовано традициями архитектуры PDP? Хотя я считаю, что конкретно для БК11 нужны окна по 16Кб, это соответствует самой архитектуре БК11, хоть и неправильно, не по PDPшному.
не думаю, что это будет сильно критично, но я не спец по демкам.Цитата:
Сообщение от gid
поясню откуда 4кБЦитата:
Может лучше сделать 8 окон по 8Кб как заповедовано традициями архитектуры PDP? Хотя я считаю, что конкретно для БК11 нужны окна по 16Кб, это соответствует самой архитектуре БК11, хоть и неправильно, не по PDPшному.
минимальный юнит согласно разбивке СМК получается как раз 4кБ:
ибо к примеру у нас со 160000 до 167777 ПЗУ
а потом уже к примеру ОЗУ со 170000
на счет 16кБ согласен, я изначально тоже прикидывал, что будет удобнее манипулировать 16кБ страницам, но вот SMK тут все испортил ибо совместимость с ним надо делать.
сейчас в AZ будет доступно 8 окон, младшие 8 - на вырост, те когда отцепим от шины 37ую
или сделаем другую БК
те мне правильно эмулировать эту ситуацию явно блокируя чтение из ОЗУ при наличии ПЗУ там ?Цитата:
Низачем, ну вот так вот получилось. Потому что, для всего этого используется одна единственная микросхема К555ТМ9, она хранит код режима, и один из битов (бит 6) является сигналом к отключению ПЗУ. Если усложнять схему, то получится дороже, больше корпусов, двухэтажная плата. Дорого. Вот насколько я помню, СМК-128 уже не взлетел, было продано единичное кол-во экземпляров, а там всего лишь вторым этажом было напаяно ещё две микросхемы ОЗУ на ОЗУ.
а запись в пусть остается ? или тоже заблокировать?
Да. Да. Нет.Цитата:
Сообщение от SuperMax
Вообще, если ресурсы позволят, я бы сделал 2 в одном: смоделировал СМК прям как есть 1 в 1, со всей его кривостью, чисто для совместимости, и параллельно - нормальный менеджер памяти, с продуманной логикой работы и режимами.
- - - Добавлено - - -
Ну да, именно отсюда, из-за того, что для работы с HDD нужно иметь ОЗУ, и его воткнули в адреса 170000-176777 и получился сегмент в 4 кБ, но фактически в СМК манипуляции делаются пачками по 4 сегмента, 16 кбайтными кусками памяти.Цитата:
Сообщение от SuperMax
Не знаю, возможно ли это, но было бы лучше делать размер сегментов 8кБ, но один спец. сегмент делать из 4кб ПЗУ и 4 кб ОЗУ (если такое возможно), садящийся в BS7 и только когда пользователю очень надо, он сам в BS7 подключает какой-нибудь свой сегмент ОЗУ, на свой страх и риск. Причём для BS7 делать аппаратное обрубание последних полкилобайта, чтобы регистрам не мешало.
Только пока не знаю, как с такой стратегией сделать модификацию адреса запуска в 177716, то ли в этом же спец сегменте делать стартовый спец режим, с набором исключений, типа последние полкилобайта не отрубать, а ПЗУ продублировать, как в СМК сделано, то ли ещё чего придумывать.
а мы таки с AFZ победили интерфейс с STM к оперативке
нашли одну ошибку
много оптимизировали и только под конец обнаружили, что два таймера нам ломали цикл обмена
что давало 6-15 ошибок на 32мегабайта
соответственно завтра займусь прошивкой для новодела БК
и на счет блиттера, я честно не понял что именно надо сделать
(те я понимаю что речь о наложении )
но вот как это надо сделать удобным для программирования - не представляю
соответственно прошу придумывать ТЗ на блиттер
Сегодня утром зафиксировал баг в квартусе, точнее в его оптимизаторе автоматов состояний: эта зараза так оптимизирует автомат, что может его тупо остановить.
Короче еще успешный шаг вперед.
upd: точнее это не баг, а следствие действий оптимизатора, который делает автомат в onehot и как следствие у него появляются запрещенные состояния, в которые он и влетает
лечится явной установкой кодирования автомата или установкой safe
Макс, а ты на каком языке пишешь? В VHDL для этого есть ветка others, в Verilog -- default. Нормальные компиляторы ругаются на их отсутствие.Цитата:
Сообщение от SuperMax
verilogЦитата:
Сообщение от Sandro
ветка конечно описана, но (!) оптимизатору на нее пофиг
Мне помогало никогда не проверять на то значение, которое onehot.Цитата:
Сообщение от SuperMax
тут речь немного о другом - изначально автомат обычный:Цитата:
Сообщение от Hunta
но оптимизатор переделывает автомат в onehotКод:localparam STATE_STM_WAIT = 3'd0; // ждем =0 на STM_U_QBUS_IN_L
localparam STATE_STM_CLANK1= 3'd1; // антизвон
localparam STATE_STM_CLANK2= 3'd2; // антизвон
localparam STATE_STM_CLANK3= 3'd3; // антизвон
localparam STATE_STM_FLAG = 3'd4; // ждем установки флагов операции
localparam STATE_STM_DATA = 3'd5; // запоминаем данные для команды
localparam STATE_STM_OPER = 3'd6; // выполняем операцию
localparam STATE_STM_END = 3'd7; // ждем завершения - снятия синка
reg [2:0] state_stm /* synthesis syn_encoding="safe" */;
reg [2:0] next_state_stm;
always @ (posedge CLK)
begin
state_stm<=next_state_stm;
end
//
wire stm_sync=STM_DA_OUT[8];
always @ *
begin
case (state_stm)
STATE_STM_WAIT:
if(STM_U_QBUS_IN_L==0)
next_state_stm=STATE_STM_CLANK1;
else
next_state_stm=STATE_STM_WAIT;
STATE_STM_CLANK1:
next_state_stm=STATE_STM_CLANK2;
....
default:
next_state_stm=STATE_STM_WAIT;
endcase
end
и если работать без /* synthesis syn_encoding="safe" */;
и так как управляющие сигналы - асинхронщина, то шанс влететь в запрещенное состояние становится очень большим
соответственно можно или сказать
/* synthesis syn_encoding="safe" */; - те сделать защитную логику
или вообще указать тип кодирования явно
да, собирая грабли я таки вычистил тормозящие куски и теперь оперативка на 130MHz полноценно пашет
А зачем? Зачем прибивать разрядность палитры к диапазону адресов? Я бы просто сделал начальный адрес палитры и разрядность цвета. И пусть программист сам делит доступный ему бюджет регистров палитры, как хочет.Цитата:
Сообщение от SuperMax
Зачем это прокрустово ложе?
- - - Добавлено - - -
Интересные дела. То есть, почему onehot -- понятно, в большинстве случаев это сильно упрощает автомат. Но вот такое поведение -- это явно некорректная опимизация при указанном default.Цитата:
Сообщение от SuperMax
Я предполагал классические косяки с casex, но для них тут нет места. Хм. Про комбинаторику даже не знаю, что сказать, это какой-то позор в синтезаторе.
Тем не менее, я бы переписал на синхронный код. Тут у синтезатора гораздо меньше шансов проявить свободу своей хулиганской воли.
PS: Вообще, когда я только начал работать на реальный кремний (2004), мне было сразу сказано, что /* synthesis ... */ в коде -- это заметание мусора под ковёр. Ни одного опровержения по сей день не видел.
поясни идеюЦитата:
Сообщение от Sandro
чем плохо наличие персональной палитры у каждого цвета у каждого видеорежима и штатной палитры?
это явно дает гибкость и сохраняет полную совместимость с легаси
к примеру новое ПО использует штатный видеорежим, и штатные палитры
но в AZ задаются более точные цвета - фон к примеру
программа получается будет просто более красиво выглядеть на AZ
или (что более вероятно) будет добивка кода в старое ПО где будет задаваться расширенная палитра и режим отображения
к примеру в land вставить явное переключение в мнохром и сделать фон не черным а темнокрасным
и менять его от уровня к уровню
тут 2 варианта решения - или safe или явное указание кодирования, последнее концептуально более правильно тк в прямом кодировании нет запрещенных состояний у этого автоматаЦитата:
Интересные дела. То есть, почему onehot -- понятно, в большинстве случаев это сильно упрощает автомат. Но вот такое поведение -- это явно некорректная опимизация при указанном default.
Я предполагал классические косяки с casex, но для них тут нет места. Хм. Про комбинаторику даже не знаю, что сказать, это какой-то позор в синтезаторе.
Тем не менее, я бы переписал на синхронный код. Тут у синтезатора гораздо меньше шансов проявить свободу своей хулиганской воли.
PS: Вообще, когда я только начал работать на реальный кремний (2004), мне было сразу сказано, что /* synthesis ... */ в коде -- это заметание мусора под ковёр.
Ни одного опровержения по сей день не видел.
если говорить о правильности то вообще надо сделать иначе
Занялся разработкой стартовой "ПЗУ"
Возникли вопросы:
1. есть ли готовый код определения типа БК ?
2. правильно ли я насчитал варианты:
;БК-10
;- с неотключаемым фокалом
;- с отключаемым бейсиком
;- с отключаемым бейсиком и монитором
;БК-11
;?
;БК-11М
;- обычная
;- новодел с отключаемым монитором
или есть еще варианты ?
особо волнует новодел БК11 тк его у меня нет
В смысле? Что тут пояснять? rgb = palette[colorIndex + paletteOffset];Цитата:
Сообщение от SuperMax
Бесполезностью. Бессмысленная трата адресного пространства палитр, которое и так маленькое. Искусственное ограничение, которое не приносит никакой пользы, но потенциально может принести много вреда.Цитата:
Сообщение от SuperMax
Наоборот, это даёт жёсткость. Гибкость -- это то, что предлагаю я.Цитата:
Сообщение от SuperMax
Мой вариант -- тоже сохраняет полную совместимость.Цитата:
Сообщение от SuperMax
Напоминаю, что штатно в БК НЕТ программного выбора видеорежима. Вообще нет. Это не УКНЦ.Цитата:
Сообщение от SuperMax
оно еще проще:Цитата:
Сообщение от Sandro
цвет на выходе = VideoModeOffset + PaletteOffset + ColorIndex ;
поясни в чем ограничениеЦитата:
Бесполезностью. Бессмысленная трата адресного пространства палитр, которое и так маленькое. Искусственное ограничение, которое не приносит никакой пользы, но потенциально может принести много вреда.
штатно - нет и это недостаток который я устраняюЦитата:
Напоминаю, что штатно в БК НЕТ программного выбора видеорежима. Вообще нет. Это не УКНЦ.
Есть, классика - запись в регистр 177662:Цитата:
Сообщение от SuperMax
Код:BK10=0 ;флаг машины БК10
BK11=1 ;флаг машины БК11
mov #bk10, @#4
mov #40000, @#177662 ;на БК10 будет trap to 4
mov #BK11, Machine
br go_next
bk10: mov #BK10, Machine
go_next: ...
обычная БК11М с отключаемым монитором, в принципе и обычная БК11 с отключаемым монитором, т.к. это - необходимая доработка для работы с любым контроллером АльтПро. (то, что на БК11 без М работать с контроллерами АльтПро неудобно и сложно, но можно, другой вопрос)Цитата:
Сообщение от SuperMax