Lisitsin, я думаю, говорить об изготовлении плат пока что рано... Думаю, там ещё будет не одно изменение.
Вид для печати
Lisitsin, я думаю, говорить об изготовлении плат пока что рано... Думаю, там ещё будет не одно изменение.
Так это процесс очень долгий, практически бесконечный ...
---------- Post added at 21:08 ---------- Previous post was at 20:50 ----------
Вот тут ещё есть вторая часть ROBOCOPa:
http://www.youtube.com/watch?v=68EqwRTNVWs
Lisitsin, я думаю сейчас, не помешало бы убрать помехи видеопроцессора :)
насчет шрифта в робокопе - а гляньте где он вообще лежит. ощущение что проблема доступа к памяти в определенных адресах.
Аппаратно память доступна и чтение / запись корректны. При старте бейсика даже есть коротенький тест всего ОЗУ. Дело в эмуляции.
---------- 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 формате, это он или нет?
Адрес 9BEF вижу, код в приложении:
Запустил ZEXALL заново. Доходит до пятого теста и виснет (по крайней мере часа пол на нём стоит). Первые 4 теста - OK:
Появилось одно странное явление: при старте бейсика вертикальные полоски (тест RAM) появляются дважды, а раньше - только один раз:
За десять часов он должен был подальше уйти. Но уже сейчас видно, что есть над чем работать.
Zexall отличается от z80tests тем, что в первом тестируются инструкции с разными операндами, а во втором с одними и теми же. Тесты на "alu #nn" у вас проходят, а те же alu с регистрами уже не работают, хотя результат и флаги у них вычисляются совершенно одинаково. Значит, прежде всего нужно найти различия в реализациях этих инструкций и устранить их.
Да ... Так просто к этому делу не подлезть ...:v2_conf2:
А со стартом вы мне можете помочь? Может там глюк и сдастся?
Вот здесь он снова в RAM-FILL сваливается:
Вот я сделал ещё один проход, но немного раньше RAM-DONE. Получается так, что вдруг перестаёт выполняться команда JR Z и при Z=1 перехода не происходит:
Ведёт себя каждый раз одинаково при каждом сбросе - вертикальные полоски появляются дважды, потом стартует BASIC.
Отличная идея. Но взведенного ZF я в трейсинге не увидел. :)
Смотрите, вот пара строк для ячейки #5BFF, для которой тест проходит:
Это состояния после первого и второго "DEC (HL)". После первого ZF не должен быть взведен, а после второго -- должен быть взведен. Для этой и всех предыдущих ячеек так и есть.Цитата:
11ea 3f68 ffff 5bff 3f03 0000 0000 4002
11ed 3f68 ffff 5bff 3f43 0000 0000 4002
А для следующей ячейки мы получаем не только неверный ZF, но и вообще странные значения регистра F:
Что если добавить к регистрам в трейсинге значение ячейки (HL)?Цитата:
11ea 3f68 ffff 5c00 3fab 0000 0000 4002
11ed 3f68 ffff 5c00 3fab 0000 0000 4002
Готово. (HL) шлю в последнюю очередь.
Прошу прощения:). Что-то у меня тактовая частота нейроимпульсов сегодня понижена.
Вот что происходит для ячейки #5BFF:
А вот что происходит для ячейки #5C00:Цитата:
11e9 3f59 ffff 5bff 3f19 0000 0000 4002 02
11ea 3f59 ffff 5bff 3f03 0000 0000 4002 01
11ed 3f59 ffff 5bff 3f43 0000 0000 4002 00
Во втором случае исходное значение ячейки не #02, а #FF, чего не должно быть, если все работает как положено. Значит, дело не в эмуляции "DEC (HL)", а в том, что ячейка #5C00 не уберегла свое значение.Цитата:
11e9 3f59 ffff 5c00 3f19 0000 0000 4002 ff
11ea 3f59 ffff 5c00 3fab 0000 0000 4002 fe
11ed 3f59 ffff 5c00 3fab 0000 0000 4002 fd
Очень хорошо было бы вывести все случаи модификации этой ячейки в формате PC:старое_значение:новое_зна чение. Если это сложно, то можно вместо ячейки (HL) в трейсинге вывести ячейку (#5C00) и посмотреть в каком месте она сбрасывается в #FF.
Разница где-то в софте. Шью старую версию - там всё нормально. Сейчас буду подбрасывать поочерёдно все страницы кода и смотреть в какой из них глюк.
Короче разобрался. Сам виноват. Гонял тест и забыл вернуть начальную инициализацию PC в ноль. Стартовал с адреса 0x04, отсюда и эффект. Сейчас исправил, но проблемы как были так и остаются. Попробую снова запустить zexall.
А проблеммка с видео оказалась по-сложнее, чем я думал. Картинку засинхронизировать удалось, но грязи ужасно много. прийдётся вводить в схему дополнительный провод от центрального процессора к видеопроцессору и дёргать за него, когда центральный обращается к памяти.
Вот как сейчас выглядит картинка:
http://www.youtube.com/watch?v=m1Wujk6t4QY