Lisitsin, я думаю, говорить об изготовлении плат пока что рано... Думаю, там ещё будет не одно изменение.

Так это процесс очень долгий, практически бесконечный ...

---------- Post added at 21:08 ---------- Previous post was at 20:50 ----------

Вот тут ещё есть вторая часть ROBOCOPa:
http://www.youtube.com/watch?v=68EqwRTNVWs

Lisitsin, я думаю сейчас, не помешало бы убрать помехи видеопроцессора :)

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

Шрифт похоже начинается с 5B00, конкретно буква N по адресу 5C00.

Аппаратно память доступна и чтение / запись корректны. При старте бейсика даже есть коротенький тест всего ОЗУ. Дело в эмуляции.

---------- Post added at 17:20 ---------- Previous post was at 17:18 ----------

Для выявления глюка нужна программка по-проще.

пошло дело:) я не могу просмотреть, все ли инструкции проходят? или творческий перерыв?:)

Сейчас эти строки работают как следуют? Если нет, изменилось ли печатаемое значение?

Альтернативный набор регистров BC', DE', HL' и AF' тоже в регистрах храните?

Нужно собраться с мыслями.

Вопрос к Lisitsin: насколько сложно убрать помехи при построении изображения? Я вижу, что помехи есть только если процессор нагружен. И, к слову, почему на разных видео разная контрасность? На скриншотах ROBOCOP, которые я выкладывал разница в контрастности очень заметная.

PRINT PEEK (65349) как давал так и даёт 255. Альтернативный набор регистров храню в регистрах общего назначения. Помехи убрать реально, но прийдётся повозиться. Контрастность изменилась чисто из-за устранения аппаратного дефекта - просто появился красный цвет (припаял резистор). Помехи действительно зависят от частоты обращения центрального процессора к памяти (на данный момент).

Давайте разберемся с zexfix. Не помню, давал ли я пофикшенную версию или исходную, поэтому на всякий случай прилагаю архив.

Посмотрите, проходит ли управление через PC=#9BEF. Если проходит, нужно сделать трейсинг начиная с этого момента и далее со всеми регистрами. Хотя бы пару тысяч строк.

Ой. У меня .z80 не конвертируется в аудиоформат. Есть у меня в .tap формате, это он или нет?

Я просто помню что был прикол с половинками адресов. типа при некоторых операциях один регистр не прогружался. вот и предположил что тут какаято похожая бяка.

Прилагаю в .tzx.

Адрес 9BEF вижу, код в приложении:

Сверил. Это он.

Здесь прошли все.

Первая строка тестируется аж 12 минут. Может, вы просто не дождались?

Запустил ZEXALL заново. Доходит до пятого теста и виснет (по крайней мере часа пол на нём стоит). Первые 4 теста - OK:

Появилось одно странное явление: при старте бейсика вертикальные полоски (тест RAM) появляются дважды, а раньше - только один раз:

Судя по видео, он доходит до шестого теста. Шестой тест идет очень долго. Запускайте на ночь. :)

UPDATE: У меня получилось, что шестой тест идет около ста минут.

Частов за десять доходт сюда: (может по-дольше подождать?)

Но бейсик реально тест памяти два раза делает. Не спроста это. Может трейсинг сделать ему? Интересно, что там после первого теста происходит ...

За десять часов он должен был подальше уйти. Но уже сейчас видно, что есть над чем работать.

Zexall отличается от z80tests тем, что в первом тестируются инструкции с разными операндами, а во втором с одними и теми же. Тесты на "alu #nn" у вас проходят, а те же alu с регистрами уже не работают, хотя результат и флаги у них вычисляются совершенно одинаково. Значит, прежде всего нужно найти различия в реализациях этих инструкций и устранить их.

Не понял, а что это за alu #nn? (простите мне мою неграмотность)

Речь идет об операциях ALU с ргеистром A: ADD, ADC, SUB, SBC, AND, XOR, OR и CP. Судя по видео, варианты с непосредственным операндом у вас работают как положено, а с операндами-регистрами и (HL) -- нет.

Да ... Так просто к этому делу не подлезть ...:v2_conf2:
А со стартом вы мне можете помочь? Может там глюк и сдастся?

Большая проблема с ZEXALL в том, что после каждой правки он потребует уйму времени для проверки.

OK, подумаем, что еще можно сделать.

Давайте попробуем. Начиная с PC=#11EF со всеми регистрами. Много строк, наверное, не понадобится.

Вот здесь он снова в RAM-FILL сваливается:

По первой же строки видно, что тест памяти проходит только от #FFFF до #5C01. Аппаратные проблемы?

Странное дело ... если проблемы были бы аппаратные то он и во второй раз бы этот тест не проходил. А он со второго раза стартует и нормально ... Мне кажется это опять что-то внутри AVR.

Это возможно. Тогда такой вопрос: он при каждом сбросе ведет себя совершенно одинаково? И при каждом сбросе первая строка в трейсинге с HL=#5C00?

Вот я сделал ещё один проход, но немного раньше RAM-DONE. Получается так, что вдруг перестаёт выполняться команда JR Z и при Z=1 перехода не происходит:
Ведёт себя каждый раз одинаково при каждом сбросе - вертикальные полоски появляются дважды, потом стартует BASIC.

Отличная идея. Но взведенного ZF я в трейсинге не увидел. :)

Смотрите, вот пара строк для ячейки #5BFF, для которой тест проходит:

Это состояния после первого и второго "DEC (HL)". После первого ZF не должен быть взведен, а после второго -- должен быть взведен. Для этой и всех предыдущих ячеек так и есть.

А для следующей ячейки мы получаем не только неверный ZF, но и вообще странные значения регистра F:

Что если добавить к регистрам в трейсинге значение ячейки (HL)?

Легко !

Готово. (HL) шлю в последнюю очередь.

Что-то совсем не похоже на правду. :) Как минимум, значение ячеек не уменьшается.

Прошу прощения:). Что-то у меня тактовая частота нейроимпульсов сегодня понижена.

Вот что происходит для ячейки #5BFF:

А вот что происходит для ячейки #5C00:

Во втором случае исходное значение ячейки не #02, а #FF, чего не должно быть, если все работает как положено. Значит, дело не в эмуляции "DEC (HL)", а в том, что ячейка #5C00 не уберегла свое значение.

Очень хорошо было бы вывести все случаи модификации этой ячейки в формате PC:старое_значение:новое_значение. Если это сложно, то можно вместо ячейки (HL) в трейсинге вывести ячейку (#5C00) и посмотреть в каком месте она сбрасывается в #FF.

Разница где-то в софте. Шью старую версию - там всё нормально. Сейчас буду подбрасывать поочерёдно все страницы кода и смотреть в какой из них глюк.

Короче разобрался. Сам виноват. Гонял тест и забыл вернуть начальную инициализацию PC в ноль. Стартовал с адреса 0x04, отсюда и эффект. Сейчас исправил, но проблемы как были так и остаются. Попробую снова запустить zexall.

А проблеммка с видео оказалась по-сложнее, чем я думал. Картинку засинхронизировать удалось, но грязи ужасно много. прийдётся вводить в схему дополнительный провод от центрального процессора к видеопроцессору и дёргать за него, когда центральный обращается к памяти.
Вот как сейчас выглядит картинка:
http://www.youtube.com/watch?v=m1Wujk6t4QY

Есть какие-нибудь результаты?