AZ для БК-0010(01) и БК-0011М

[grf]

С СМК есть проблема: http://bk0010.forum20.ru/forum/?id=37741
AZ не будет страдать таким глюком?

[SuperMax]

С СМК есть проблема: http://bk0010.forum20.ru/forum/?id=37741
AZ не будет страдать таким глюком?

как я понимаю да ибо придется тащить всю логику с SMK втч и
"В режимах 160 и 120 по адресам 140000-157777 происходит наложение ОЗУ СМК на ПЗУ БОС БК11."
что изначально должно вызывать глюки

но можно отказаться от наложения и подсовывать окна памяти только туда, куда можно не вызывая конфликтов

[grf]

как я понимаю да ибо придется тащить всю логику с SMK втч и
"В режимах 160 и 120 по адресам 140000-157777 происходит наложение ОЗУ СМК на ПЗУ БОС БК11."
что изначально должно вызывать глюки

но можно отказаться от наложения и подсовывать окна памяти только туда, куда можно не вызывая конфликтов

Глюки происходят только на новоделе + СМК, а оригинальная БК с СМК работает как положено. Так что сэмулировать надо правильное поведение ОЗУ, на возникающие глюки никто не затачивает программы )
Я, собственно, спрашивал о том, не окажется ли AZ в такой же ситуации, что новодел с быстрой памятью тоже не сможет из него читать без всяких режимов эмуляции СМК?

[gid]

Ещё вы не учитываете такой нюанс: у СМК 8 режимов работы, из них 4 предназначены для работы с БК10, и остальные 4 - для БК11.
То, что режимы работы с БК10 на БК11 использовать можно, ещё не означает, что это правильно и целесообразно.
И вообще, если бы делать по-нормальному, надо было бы делать не 16 страниц по 32 кб, из которых можно использовать по назначению только половину в каждый момент времени, а делать 32 страницы по 16 кб, и два независимых окна, на 100000-137777 и 140000-177777 с той же логикой, что и сейчас. Но тогда нужно делать отдельный регистр, т.к. в 177130 битов на такое не хватает. И если бы так сделали изначально, то плата получилась бы в 2-2,5 раза больше по площади и по корпусам больше примерно в столько же. Тогда бы такой контроллер стоил сильно дороже и его мало кто купить смог бы.

[SuperMax]

Глюки происходят только на новоделе + СМК, а оригинальная БК с СМК работает как положено. Так что сэмулировать надо правильное поведение ОЗУ, на возникающие глюки никто не затачивает программы )
Я, собственно, спрашивал о том, не окажется ли AZ в такой же ситуации, что новодел с быстрой памятью тоже не сможет из него читать без всяких режимов эмуляции СМК?

я возможно не совсем понял ситуацию - прошу поправить меня если я не прав:

1. SMK изначально работает некорректно накладывая ОЗУ и ПЗУ. Само по себе наложение уже есть источник конфликта.

те кто первый выставит RPLY, те данные будут приняты процессором, НО это прокатит только в том случае, если опоздание у второго абонента (как я понял это ОЗУ) будет достаточно большим
иначе, будет наложение информации в ответе будет мусор.

2. на обычной машине ПЗУ быстрее, чем ОЗУ, и как следствие разница во времени выставления RPLY достаточная и на чтение успешно отвечает ПЗУ, а ответ ОЗУ маскируется.

3. на быстром ОЗУ ответ идет почти одновременно и возникает конфликт на шине.


Соответственно в AZ конфликт устранить просто:
те я просто не буду отвечать на чтение в ОЗУ если у нас есть ПЗУ. В случае реплики, конфликт изначально не возможен тк ПЗУ у меня эмулируется той же памятью и одновременный ответ в принципе не является возможным.


И у меня вопрос а зачем наложение-то ? те какое практическое применение ?

- - - Добавлено - - -

Ещё вы не учитываете такой нюанс: у СМК 8 режимов работы, из них 4 предназначены для работы с БК10, и остальные 4 - для БК11.
То, что режимы работы с БК10 на БК11 использовать можно, ещё не означает, что это правильно и целесообразно.
И вообще, если бы делать по-нормальному, надо было бы делать не 16 страниц по 32 кб, из которых можно использовать по назначению только половину в каждый момент времени, а делать 32 страницы по 16 кб, и два независимых окна

я сейчас сделал разбивку всего адресного пространства на окна по 4кБ - те всего 16 окон
и каждому окну соответствует регистр с адресом (и дискретность получается в 4кБ)
так, я думаю будет удобно работать

на счет модели с ПЗУ думаю
может сделаю масочный регистр который будет задавать тип ответа на обращение

но сейчас при нагрузочном тесте оперативки из STM32 обнаружили глюки, соответственно ловим. а пока принимаются идеи.

[gid]

1. SMK изначально работает некорректно накладывая ОЗУ и ПЗУ. Само по себе наложение уже есть источник конфликта.

Нет, СМК не работает некорректно, он изначально так задуман, это такая фича. И те, для кого наложение есть источник конфликта, сами и виноваты, надо использовать изделие не произвольно, а строго так, как было задуман разработчиком. А то, что рамки использования при этом резко сужаются, ну, зато не заоблачно дорого. Помните, в какое время контроллер разрабатывался? Какие цены и какая инфляция тогда была, все миллионерами были.

те кто первый выставит RPLY, те данные будут приняты процессором, НО это прокатит только в том случае, если опоздание у второго абонента (как я понял это ОЗУ) будет достаточно большим
иначе, будет наложение информации в ответе будет мусор.

Так и есть, это подтверждается разной работой реплики СМК и оригинального СМК-64 с оригинальной БК-11М. Причём как раз, то, что в реплике наложения не ощущается, очень расслабляет, а потом встреча с реальностью становится более тяжёлой.

2. на обычной машине ПЗУ быстрее, чем ОЗУ, и как следствие разница во времени выставления RPLY достаточная и на чтение успешно отвечает ПЗУ, а ответ ОЗУ маскируется.

Нет, такой ситуации не возникает.

3. на быстром ОЗУ ответ идет почти одновременно и возникает конфликт на шине.

там в оригинальном СМК использовалось ОЗУ, что-то типа HM64256LP-15, а RPLY выставляется логикой серии 555, что получается примерно как у БК по времени. Поэтому на шине получается электрическое ИЛИ из данных ПЗУ и ОЗУ.
А в реплике СМК RPLY выставляется ФПГА, делается это достаточно быстро, так, что ПЗУ БК ещё не успевает выставить своё RPLY поэтому с шины успевают прочитаться данные из ОЗУ СМК
Кстати, там не только на ПЗУ наложение, в режиме 100 на БК11 происходит наложение ОЗУ СМК на ОЗУ БК, правда как раз этот режим и предназначен для БК10 и на БК11 не рекомендуется.

И у меня вопрос а зачем наложение-то ? те какое практическое применение ?

Низачем, ну вот так вот получилось. Потому что, для всего этого используется одна единственная микросхема К555ТМ9, она хранит код режима, и один из битов (бит 6) является сигналом к отключению ПЗУ. Если усложнять схему, то получится дороже, больше корпусов, двухэтажная плата. Дорого. Вот насколько я помню, СМК-128 уже не взлетел, было продано единичное кол-во экземпляров, а там всего лишь вторым этажом было напаяно ещё две микросхемы ОЗУ на ОЗУ.

я сейчас сделал разбивку всего адресного пространства на окна по 4кБ - те всего 16 окон
и каждому окну соответствует регистр с адресом (и дискретность получается в 4кБ)
так, я думаю будет удобно работать

Тут, это, чем больше окон и чем они меньше, тем большее время тратится на переключение страниц в окнах. Иногда это бывает критично, в демках например.
Может лучше сделать 8 окон по 8Кб как заповедовано традициями архитектуры PDP? Хотя я считаю, что конкретно для БК11 нужны окна по 16Кб, это соответствует самой архитектуре БК11, хоть и неправильно, не по PDPшному.

[Advertiser]

[SuperMax]

Тут, это, чем больше окон и чем они меньше, тем большее время тратится на переключение страниц в окнах. Иногда это бывает критично, в демках например.

не думаю, что это будет сильно критично, но я не спец по демкам.

Может лучше сделать 8 окон по 8Кб как заповедовано традициями архитектуры PDP? Хотя я считаю, что конкретно для БК11 нужны окна по 16Кб, это соответствует самой архитектуре БК11, хоть и неправильно, не по PDPшному.

поясню откуда 4кБ
минимальный юнит согласно разбивке СМК получается как раз 4кБ:
ибо к примеру у нас со 160000 до 167777 ПЗУ
а потом уже к примеру ОЗУ со 170000

на счет 16кБ согласен, я изначально тоже прикидывал, что будет удобнее манипулировать 16кБ страницам, но вот SMK тут все испортил ибо совместимость с ним надо делать.

сейчас в AZ будет доступно 8 окон, младшие 8 - на вырост, те когда отцепим от шины 37ую
или сделаем другую БК

Низачем, ну вот так вот получилось. Потому что, для всего этого используется одна единственная микросхема К555ТМ9, она хранит код режима, и один из битов (бит 6) является сигналом к отключению ПЗУ. Если усложнять схему, то получится дороже, больше корпусов, двухэтажная плата. Дорого. Вот насколько я помню, СМК-128 уже не взлетел, было продано единичное кол-во экземпляров, а там всего лишь вторым этажом было напаяно ещё две микросхемы ОЗУ на ОЗУ.

те мне правильно эмулировать эту ситуацию явно блокируя чтение из ОЗУ при наличии ПЗУ там ?
а запись в пусть остается ? или тоже заблокировать?

[gid]

те мне правильно эмулировать эту ситуацию явно блокируя чтение из ОЗУ при наличии ПЗУ там ?
а запись в пусть остается ? или тоже заблокировать?

Да. Да. Нет.

Вообще, если ресурсы позволят, я бы сделал 2 в одном: смоделировал СМК прям как есть 1 в 1, со всей его кривостью, чисто для совместимости, и параллельно - нормальный менеджер памяти, с продуманной логикой работы и режимами.

- - - Добавлено - - -

минимальный юнит согласно разбивке СМК получается как раз 4кБ:
ибо к примеру у нас со 160000 до 167777 ПЗУ
а потом уже к примеру ОЗУ со 170000

Ну да, именно отсюда, из-за того, что для работы с HDD нужно иметь ОЗУ, и его воткнули в адреса 170000-176777 и получился сегмент в 4 кБ, но фактически в СМК манипуляции делаются пачками по 4 сегмента, 16 кбайтными кусками памяти.

Не знаю, возможно ли это, но было бы лучше делать размер сегментов 8кБ, но один спец. сегмент делать из 4кб ПЗУ и 4 кб ОЗУ (если такое возможно), садящийся в BS7 и только когда пользователю очень надо, он сам в BS7 подключает какой-нибудь свой сегмент ОЗУ, на свой страх и риск. Причём для BS7 делать аппаратное обрубание последних полкилобайта, чтобы регистрам не мешало.
Только пока не знаю, как с такой стратегией сделать модификацию адреса запуска в 177716, то ли в этом же спец сегменте делать стартовый спец режим, с набором исключений, типа последние полкилобайта не отрубать, а ПЗУ продублировать, как в СМК сделано, то ли ещё чего придумывать.

[SuperMax]

а мы таки с AFZ победили интерфейс с STM к оперативке
нашли одну ошибку
много оптимизировали и только под конец обнаружили, что два таймера нам ломали цикл обмена
что давало 6-15 ошибок на 32мегабайта

соответственно завтра займусь прошивкой для новодела БК

и на счет блиттера, я честно не понял что именно надо сделать
(те я понимаю что речь о наложении )
но вот как это надо сделать удобным для программирования - не представляю

соответственно прошу придумывать ТЗ на блиттер

[SuperMax]

Сегодня утром зафиксировал баг в квартусе, точнее в его оптимизаторе автоматов состояний: эта зараза так оптимизирует автомат, что может его тупо остановить.

Короче еще успешный шаг вперед.

upd: точнее это не баг, а следствие действий оптимизатора, который делает автомат в onehot и как следствие у него появляются запрещенные состояния, в которые он и влетает
лечится явной установкой кодирования автомата или установкой safe