ZX Spectrum: аппаратная реализация на восьми микросхемах

[Higgins]

TRACE_9426_1.zip

Мда. В строке 17131 у нас различие в регистре F. Это после исполнения "BIT 0, (HL)". Причем различие не во флагах 3 и 5, а в ZF и PF. То есть, снова что-то не то читается из памяти. В момент чтения HL равен #FF45. До строки 17131 эта ячейка ни разу не модифицируется. Значение этой ячейки до первой модификации должно быть равно #0E=%1110. Нулевой бит сброшен. У меня на эмуляторе после проверки бита ZF и PF взведены, что и должно быть, если значение ячейки равно #0E. У вас в трейсинге оба флага сброшены. При этом, судя по тесту на флаги, сама инструкция реализована верно. Остается грешить на память?

Что можно попробовать. Можно вывести тот же трейсинг, скажем, первые 18000 строк, но в каждую строку добавить текущее значение в ячейке #FF45.

[Lisitsin]

Попробую включить ячейку памяти ff45 в трейсинг. Как я понял, IX, IY, SP сейчас особенного значения не играют. Может сделать трейсинг такого вида: PC : BC : DE : HL : [FF45] ? И если да - то с какой точки лучше начать трейсинг ?

---------- Post added at 12:10 ---------- Previous post was at 11:55 ----------

Оппа-па !
Пишу в бейсике:
10 POKE 65349,0
20 PRINT PEEK (65349)

В ответ : 255.

Работаю ...

[Higgins]

Попробую включить ячейку памяти ff45 в трейсинг. Как я понял, IX, IY, SP сейчас особенного значения не играют. Может сделать трейсинг такого вида: PC : BC : DE : HL : [FF45] ? И если да - то с какой точки лучше начать трейсинг ?

Лучше с той же.

В ответ : 255.

Вот-вот.

[Lisitsin]

Прогнал тест RAM. Всё чисто. Проблемы эмуляции (приложение: экранная область заполнялась различными значениями, читаемыми из RAM. Горизонтальная граница соответствует адресу FFFF, выше - ОЗУ).
Трейсинг готовлю.

[goodboy]

раньше многие эмули выдавали неверное значение в HL при выполнении LD HL,(65535).

[Lisitsin]

раньше многие эмули выдавали неверное значение в HL при выполнении LD HL,(65535).

По-моему такой же случай.

[Lisitsin]

Уже в начале значение [ff45] равно 0x47.
Шлю PC: BC: DE: HL: AF: [ff46]:[ff45] ([ff46] корректна только младшая тетрада).
Если загрузить z80tests и нажать "3", затем из бейсика PRINT PEEK 65349 (0xff45) то тоже получаем 71 (0x47).
После старта бейсика непосредственно PRINT PEEK 65349 даёт 255 . А должно быть 0. Такое ощущение, что туда стек заползает. Может старт бейсика потрейсить?

[Higgins]

После старта бейсика непосредственно PRINT PEEK 65349 даёт 255 . А должно быть 0. Такое ощущение, что туда стек заползает. Может старт бейсика потрейсить?

Сразу после старта Бейсика значение в 65349 скачет (очевидно, во время ожидания ввода стек топчется по этой ячейке).

Значение 14 в 65349 для z80tests кладет его Бейсик-загрузчик через исполнение "CLEAR 32767". Если после старта Бейсика набрать эту команду, и затем сделать "PRINT PEEK 32767", то мы должны получить именно 14. У вас это так или нет?

[Lisitsin]

"CLEAR 32767". Если после старта Бейсика набрать эту команду, и затем сделать "PRINT PEEK 32767", то мы должны получить именно 14. У вас это так или нет?

В смысле потом набрать PRINT PEEK 65349?
Всё равно 71:
http://www.youtube.com/watch?v=hDMz6wEdJgI
А PRINT PEEK 32767 даёт 62 (0X3E)

[Higgins]

В смысле потом набрать PRINT PEEK 65349?

Да, опечатка.

Всё равно 71.

Копания показали, что ячейка модифицируется обработкой прерывания. В нее кладется старшая половина адреса возврата.

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

Давайте вернемся к тесту на MEMPTR. Около ста тысяч строк есть. Сколько там еще до выхода в Бейсик с ошибкой? Если возможно, выкладывайте остальное.