БК-0010 + SMK-512 + образ CF

[Woland]

Поддерживаю.

Прошивку поправил gid, насколько это позволило предположение о причинах проблемы: v1.2.rar

Теперь в режиме 20, если выключить регистры 177130 177132 по чтению, не портятся ячейки 177130 177132 в ОЗУ, т.е. читается именно содержимое этих ячеек, а не смесь из ячеек и регистра, что подтверждается новой версией 4.75F теста СМК от gid.

Но, это не помогло Бейсику, он по-прежнему не работает! И что там править теперь - некому не понятно, так что исправление проблемы в ближайшее время ждать не стоит. Процитирую gid'а: теперь нужно написать свой отладчик для БК и посмотреть, в чём дело. Потому что существующие отладчики не справляются с emt 14 и там с точками останова очень плохо.

Попутно обновил образ CF для СМК512: 1gb_cf_dump_2019_03_19

Загрузочные лог. диски MK-DOS теперь на БК10-01 работают корректно, в папку с тестами СМК512 добавлена новая версия 4.75F.

Два вопроса к общественности:
1. Есть ли исходники этого дискового бейсика для БК10-01+СМК ?
2. Может ли кто-то проверить работоспособность этого бейсика на реальной БК10-01+СМК64 ?

[AlexMik]

Alex_LG пообещал протестировать как только поправится и доберется до компа.
Свой СМК-64 он как раз успешно запустил.

[Woland]

Alex_LG пообещал протестировать как только поправится и доберется до компа.
Свой СМК-64 он как раз успешно запустил.

Собрал свой стендовый и проверил сам - работает. Надо выяснять причину, почему в связке с СМК512 не работает, наверняка она очень проста, но трудно диагностируема, как обычно.

[gid]

Разобрался я таки в чём проблема.
Основная проблема - из-за того, что хоть и должно, но не происходит наложение ОЗУ СМК, на ОЗУ/ПЗУ/регистры БК.
В результате, всегда читается ОЗУ СМК вместо смеси данных СМК+БК.
Вот и в режиме 20 получается то же самое. Там ОЗУ накладывается на область 177600-177777 и в результате ничего нельзя прочесть из регистров 177660, 177662, 177664. А вот из 177716 и предположительно из 177714 (я вчера не догадался подключить джойстик и пошевелить им) данные читаются.
Поэтому после запуска бейсика любое нажатие клавиши приводит к застопориванию работы. Затык происходит по адресу 101270 в обработчике прерывания от клавиатуры, там такой код:

101270$:TSTB @#177660 ; проверка нажатия клавиши 
101274$:BPL 101270    ; продолжать проверять (ждать нажатия клавиши)

А поскольку по адресу 177660 читается ОЗУ, которое обнулено, т.е. читается всегда 0 и происходит зацикливание навсегда.

Решение я предполагаю такое: нужно выдавать RPLY чуть позже, чем оно сейчас выдаётся. А сейчас оно выдаётся сразу после установки DIN/DOUT. Это несколько замедлит память, и думаю, что регистры 177660-177664 успеют выдать на шину свои данные и в результате мы таки получим наложение ОЗУ СМК на ОЗУ/ПЗУ/регистры БК. И в демках от Lasoft может появиться рассинхрон. А может и нет, эксперимент покажет.

[AlexMik]

Разобрался я таки в чём проблема.

Супер!
Снимаю шляпу )
Поэтому БК жива. И жить будет. Даже не сомневаюсь.

Решение я предполагаю такое: нужно выдавать RPLY чуть позже, чем оно сейчас выдаётся.

эксперимент покажет

Ждемс. С надеждой.

ЗЫ: А пока такой вопрос. USB-бластер покупать для заливки в СМК новой (исправленной) прошивки? Это будет влиять на работу Бейсика?

[gid]

USB-бластер покупать для заливки в СМК новой (исправленной) прошивки?

Бластер вообще вещь в хозяйстве полезная, не тут, так в другом месте пригодится. Может и можно покупать.

Это будет влиять на работу Бейсика?

прошивка v1.2 пока никак не помогает работе бейсика, она устраняет проблему, которая возникла бы, если бы бейсик работал.
А эксперимент показал, что у меня не хватает знаний в VHDL и квартусе и мультисиме. Очевидное, с моей точки зрения, решение, которое я применил, сделало прошивку полностью неработоспособной, хотя в симуляции всё выглядело красиво.
Так что ещё нескоро проблема решится.

[Advertiser]

[Woland]

А поскольку по адресу 177660 читается ОЗУ, которое обнулено, т.е. читается всегда 0 и происходит зацикливание навсегда.

А в тест смк добавить диагностику этой проблемы возможно?

Разработчик не смог понять замысел с RPLY, прокомментировал так:

При таком раскладе проще те самые адреса запретить в режиме 20 для памяти, хотя тогда не совсем понятно, как в оригинальном СМК это не конфликтует. Просто задерживать RPLY толку не видно, все равно сначала выставляются нужные данные на шину, потому уже RPLY в конце, а процессор по RPLY читает уже то, что выставлено.

На вопрос, что же делать, он ответил:

Адреса блокировать в режиме 20, если там свободные макроячейки еще есть для дополнительной логики. Но дело в том, что мне вообще неясно, как там могут быть конфликты на пространстве внешних устройств и почему это вообще кто-то допустил. Но если конфликт реально есть, то не факт, что все ограничится вот этим набором адресов, это просто именно что при прерывании к ним обращение идет. Бодание двух стройств на шине - это не есть хорошо, даже если ничего не сгорит при этом. В оригинальной шине QBUS все драйверы с открытым коллектором и на данных вроде тоже, так что ничего не может сгореть в принципе, но в СМК это не так.
Я попробую придумать, как там поделикатенее блокировать адреса, но впорос в том, какие на самом деле блокировать кроме тех, что уже себя проявили.

[gid]

А в тест смк добавить диагностику этой проблемы возможно?

Нет. Потому что чтение нулевого значения, абсолютно валидная операция, просто не всегда должен читаться 0, а когда подразумевается логикой работы устройства.

Разработчик не смог понять замысел с RPLY,

Замысел с RPLY оказался ошибкой, что я только не делал, даже отключал выдачу RPLY по адресам 177660-177667, чтобы по этим адресам RPLY выдавали ВПшки, и всё равно фиг. Нули читаются, видимо ОЗУ, или через чё там с ОЗУ данные на шину попадают, электрически сильнее и перебарывает своим +5В 0В данных с ВПшек, поэтому всегда читаются нули. Однако, по адресам 177714 и 177716 спокойно читается смесь данных из ОЗУ и портов БК. Вот поэтому я и думал, что надо поиграть с задержкой выдачи RPLY, т.к. от заднего фронта RPLY начинается отсчёт, когда процессору снимать с шины данные при чтении.

Адреса блокировать в режиме 20,

Я тож пришёл к этому выводу, но случился облом. Добавил блокировку и теперь квартус ругается такими ошибками:
"Error (163105): Cannot route source node "..." of type max_mcell to destination node "..." of type max_mcell"
На все мои действия, таких ошибок получается то много, то очень много. Свободных ячеек есть, Total macrocells 252 / 256 ( 98 % ) а вот маршрутов от ноды к ноде закончилось. И как это обойти я без понятия.
Блокирование адреса делается просто. Так - чтобы заблокировать 177660-177667

	xrd_d_n <= '1' when a_n(15 downto 3) = "0000000001001" else (xrd_n and xrd_del6);

А вот так, чтобы заблокировать 177660-177665, а 177666,177667 читались. Чтобы в режиме 160 маловероятный случай необходимости доступа к этой ячейке ПЗУ был.

	xrd_d_n <= '1' when a_n(15 downto 3) = "0000000001001" and 
						(a_n(2) = '1' or (a_n(2) = '0' and a_n(1) = '1')) 
			else (xrd_n and xrd_del6);

Особо выделять режим 20 смысла нет, т.к. чтение по адресам 177600-177777 делается только в режимах 160 и 20, в остальных режимах там или пусто, или ОЗУ в режиме только записи.

как там могут быть конфликты на пространстве внешних устройств и почему это вообще кто-то допустил.

Спокойно могут быть, логика общей шины это допускает, но не рекомендует. Результат складывается по ИЛИ из множества сигналов (добавлю: электрически по И, просто на шине лог.0 это +5В, а лог.1 это 0В, то рассматривая в привычном виде, получается ИЛИ после инвертирования) Это не конфликт даже, почти.
А допустил это тот, кому надо было сделать максимально дешёвое устройство, которое можно было собрать и продать в то непростое время.

[S_V_B]

Ребят,вам бы maxvela . в помощь, мы с ним уже год назад эту проблему заметили... но чет.. зарегится не может.. а я свалил на УКНЦ.. он уже много чего написал.
smolyakiv@bk.ru
(весьма не общителен. но если попрет\2)

[Руслан]

Можно список игр на карточке?