Компьютер ZXM-777

[Mick]

ЭЭ, а как же цикл подтверждения прерывания - когда IORQ и M1 активны вместе? если сопроцессор случайно откликнется (ну малоли, адрес мог и совпасть) и выдаст на шину данные, то они прочитаются вместо FF, соответственно вектор прерывания будет другой в IM0 и IM2.
В большинстве софта это учтено 257-байтной таблицей векторов прерываний, но вдруг именно тут - нет?

Ну в оригинальном компе было без M1, но похоже у меня немного другие тайминги получились. Давно слышал про эти таблицы, даже сам когда то делал в своих прогах. Только уже не помню - это делалось из-за возможных нестабильностей шины данных или как? (сам уже не вспомню).
Вот кусок инициализации из этой демки. Сюда приходит после загрузки.

seg000AC0 di
seg000AC1 ld a, 3Bh ; ';'
seg000AC3 ld i, a
seg000AC5 im 2
seg000AC7 ld a, 18h
seg000AC9 ld (0FFFFh), a
seg000ACC ld a, 0C3h ; '├'
seg000ACE ld (0FFF4h), a
seg000AD1 ld hl, loc_0_DB0E
seg000AD4 ld (0FFF5h), hl

[Advertiser]

[AlexCrush]

seg000AC0 di
seg000AC1 ld a, 3Bh ; ';'
seg000AC3 ld i, a
seg000AC5 im 2

Значит I=0x3b, а по 0x3b00 -0x3C00 в фирменном 48ROM - FF-ки. Т.е. на первый взгляд всё в порядке, при любом векторе прочитанном по M1+IORQ все должно быть идентично.

Однако, в Unreal 0.30 галочка "Unstable Data Bus" тоже вешает Lyra2-бутылочку ...

Глянул исходники Unreal - там эта галочка действует так:
1. если выключена, то адрес, откуда читается вектор прерываний = I*0x100 + 0xFF.
2. Если включена, то адрес = I*0x100 + случайное число.

В случае если ROM оригинальный - все работает хорошо. Если же там по адресам 3b00-3c00 не FF - то вешается.
Вроде как бы все ясно...

[Mick]

Значит I=0x3b, а по 0x3b00 -0x3C00 в фирменном 48ROM - FF-ки. Т.е. на первый взгляд всё в порядке, при любом векторе прочитанном по M1+IORQ все должно быть идентично.

Однако, в Unreal 0.30 галочка "Unstable Data Bus" тоже вешает Lyra2-бутылочку ... Я пока не понял почему

Вот и я не пойму, в прерывание он же входит, запихивает в врегистры муз сопроца, выходит из плеера, а куда фиг его знает

[AlexCrush]

Проверь свою ПЗУ - я выше пост поправил. У меня вышло, что
1. если ПЗУ модифицированное (по адресам 3BXX не FF) и стоит галочка Unstable Data Bus - вешается.
2. если ПЗУ модифицированное (по адресам 3BXX не FF) и НЕ стоит галочка Unstable Data Bus - не вешается.
3. если ПЗУ оригинальное то не вешается в любом случае.

Вобщем, мой вывод: по-правильному, M1 нужно заводить на схему выборки музпроцессора, об этом еще в ЗХ-Ревю писали в 1995м годе. То что в оригинале было не так - это проблемы оригинала

[Mick]

Проверь свою ПЗУ - я выше пост поправил. У меня вышло, что
1. если ПЗУ модифицированное (по адресам 3BXX не FF) и стоит галочка Unstable Data Bus - вешается.
2. если ПЗУ модифицированное (по адресам 3BXX не FF) и НЕ стоит галочка Unstable Data Bus - не вешается.
3. если ПЗУ оригинальное то не вешается в любом случае.

Вобщем, мой вывод: по-правильному, M1 нужно заводить на схему выборки музпроцессора, об этом еще в ЗХ-Ревю писали в 1995м годе. То что в оригинале было не так - это проблемы оригинала

Короче я попробую посадить M1 муз процу. Но тогда вопрос. Если подтверждение прерывания происходит по IORQ и M1, то логичнее всего M1 подавать на дешифратор портов. А то така штука может случится с любым совпадающим портом на чтение.
ПЗУ вроде нормальное.

[AlexCrush]

Если подтверждение прерывания происходит по IORQ и M1

Без всяких "если" - это факт, указанный в доках Z80.

то логичнее всего M1 подавать на дешифратор портов. А то така штука может случится с любым совпадающим портом на чтение.

Да, нужно заводить на дешифратор портов. Если где-то это не сделано - то это ошибка, так как IORQ+RD не гарантирует, что идет чтение порта, быть может идет подтверждение прерывания.
Кстати, M1+IORQ можно использовать для генерации сигнала INT с плавающей длительностью и гарантией однократного захода в прерывание в любом случае. Т.е. логика INT:
1. по КСИ устанавливаем INT
2. Сбрасываем по
а) истечении 64х тактов (можно юзать один из счетчиков гориз. развертки)
б) по M1+IORQ
Имхо, это самая надежная схема формирования INT (была тут тема про INT в турборежиме...)

ПЗУ вроде нормальное.

Вроде ?
10 FOR I FROM 0 TO 255
20 PRINT PEEK (15104+I)
30 NEXT I
Должны быть только 255

[caro]

б) по M1+IORQ
Имхо, это самая надежная схема формирования INT (была тут тема про INT в турборежиме...)

Такая схема применялась в первых Балтиках,
в результате многие программы отказывались работать.
Приходилось делать доработку.

[Evgeny Muchkin]

Такая схема применялась в первых Балтиках,
в результате многие программы отказывались работать.
Приходилось делать доработку.

Ой... caro, Ты меня смутил. Получается на ИР16 это далеко не лучший вариант формирователся ИНТ?

[Mikka_A]

Ой... caro, Ты меня смутил. Получается на ИР16 это далеко не лучший вариант формирователся ИНТ?

Евгений - у вас паранойя....

Читаем зонова.....

"........."..........Сигнал INT теперь формируется цифровым способом , его длительность жестко задана и равна 9mks, причем сделано так, что в программах, чувствительных к длительности сигнала INT и ранее работавших неправильно в режиме Turbo из-за повторного захвата прерывания, теперь этого не происходит. Во всех других моделях ”компьютеров, которые мы выбираем”, этот дефект, по нашим сведениям, присутствует..........."

[caro]

Ой... caro, Ты меня смутил. Получается на ИР16 это далеко не лучший вариант формирователся ИНТ?

Схема на ИР16 после подтверждения прерывания еще не снимает INT,
добавляется еще один машинный цикл, что и достаточно для нормальной работы.