Ошибку с избыточным инкрементированием нашёл.
Первые 2 строки исправились, а третья что-то не хочет:
Вид для печати
Ошибку с избыточным инкрементированием нашёл.
Первые 2 строки исправились, а третья что-то не хочет:
NF надо сбрасывать. В обеих инструкциях.Цитата:
Сообщение от Lisitsin
Такая хорошая погода на улице. Весна: солнышко, птички ...
А слово FAILED всё настроение портит.
HF тоже сбросьте, и настроение поднимется. :)Цитата:
Сообщение от Lisitsin
И вправду !!! Слово PASSED на настроение влияет с обратной логикой.
Условие для "BIT n, (HL)": PC=#8858 ИЛИ #885A ИЛИ #885D ИЛИ #885F ИЛИ #8862 ИЛИ #8864 ИЛИ #8867 ИЛИ #8869 ИЛИ #886C ИЛИ #886E ИЛИ #8871 ИЛИ #8873 ИЛИ #8876 ИЛИ #8878 ИЛИ #887B ИЛИ #887D. Регистры PC, HL, AF.Цитата:
Сообщение от Lisitsin
Я условие сделал #8858<=PC<=#887d
Во второй строке неправильно установлены флаги 3 и 5.Цитата:
Сообщение от Lisitsin
Как устанавливать эти флаги:
- Для "BIT n, r" -- копируются разряды 3 и 5 регистра "r".
- Для "BIT n, (HL)" -- копируются разряды 3 и 5 старшей половины MEMPTR. Сам MEMPTR при этом не меняется.
- Для "BIT n, (i+d)" -- тоже копируются разряды 3 и 5 старшей половины MEMPTR. Но поскольку это индексная инструкция, MEMPTR получает значение адреса (i+d). Копировать разряды из MEMPTR следует после присваивания ему (MEMPTR) значения адреса.
А у меня MEMPTR ущё и не после каждой команды отрабатывается, после которой его нужно обрабатывать. BIT (IX/Y+d) исправил. BIT n (HL) и BIT n,r в отношении битов 3 и 5 прописаны.
Процедура тестирования для "BIT n, (HL)" начинается по адресу #8855. Вызывается она инструкцией "CALL #8855". Эта инструкция копирует #8855 в MEMPTR, поэтому тестирование всегда начинается с этого значения MEMPTR.Цитата:
Сообщение от Lisitsin
Во второй строке у вас F=#38 вместо #18. Старшая половина пправильного значения MEMPTR = #88 = %10001000 -- 3-й и 5-й разряды сброшены.
Если MEMPTR для "CALL #nn" не реализован, то сейчас самое время.
Так оно по-лучше?
Немножко. Чтобы увереннее определить проблему нужно в дополнение к PC, HL и AF вывести еще MEMPTR.Цитата:
Сообщение от Lisitsin
Можно и с MEMPTR:
Отлично. "RET" (условный и безусловный) должны присваивать MEMPTR адрес передачи управления, т.е. то, что они извлекают из стека.Цитата:
Сообщение от Lisitsin
Готово.
Здесь все прошли. Видимо, нужно гораздо больше строк.Цитата:
Сообщение от Lisitsin
Всё. Прошло. Следующая BIT r (IX/Y+d):Цитата:
Сообщение от Higgins
Условие: PC=от #888D до #88C2 включительно. Регистры PC, AF, IX.Цитата:
Сообщение от Lisitsin
Странное дело. Он пролетает один проход и больше не возвращается:
Господа, я всё понимаю, процесс отладки. Но всё же не могли бы вы переписываться через личку, а сюда уже представить готовый результат. А то более 300 постов идёт диалог, никто в нём кроме вас двоих не участвует.
Этот диалог может быть полезен другим эмулеписателям.
Да дело к развязке. История она так и делается - чтобы все видели и знали.Цитата:
Сообщение от fifan
Higgins помогает мне нереально. Да не забудется его труд !!!
я за то, что бы оставить и продолжать сей диалог.:)
Ну хорошо... Как сказал Ewgeny7, Вы простых путей не ищите. Интересно всё же увидеть Спектрум на железной эмуляции процессора!
Для Higgins: отпустил я его в свободный полёт с адреса #888D. В итоге где-то сбой: мне кажется где-то здесь у меня реальный глюк: (TRACE_GLUK.txt). Шлю PC : BC : DE : HL : AF : IX : IY : SP;
Ещё весь мир увидит !!!Цитата:
Сообщение от fifan
Я придумал как ещё одну микросхему из проекта выбросить вместе с обвязкой. Так что любой радиолюбитель собирать будет.
z80 на atmel бы отладить, а потом выбрасывать. Слежу внимательно за развитием событий, вот только жаль, что помочь ничем не могу:(
---------- Post added at 19:46 ---------- Previous post was at 19:46 ----------
От сюда еще можно вывести на будущее все нюансы недокументированные или плохо документированные.
Вижу проблему с инструкциями "BIT n, (IX+d)", которые исполняются в цикле тестирования. Они исполняются так, будто они размером 5 байтов вместо четырех. Вторая строка в трейсинге должна быть для PC=#8891, а у вас она для PC=#8892. В результате после проверки бита вызывается не процедура обновления контрольной суммы, а случайный код. По этой же причине не происходит выход из процедуры тестирования, которая вызывается для каждой итерации.Цитата:
Сообщение от Lisitsin
---------- Post added at 20:25 ---------- Previous post was at 20:23 ----------
А могли бы и поучаствовать. :)Цитата:
Сообщение от fifan
А какая там конкретно команда BIT и что после неё? Прогнал в AVRStudio - всё нормально. Бейсик без этой команды просто повесился бы, вот что странно ...
Код выглядит так:Цитата:
Сообщение от Lisitsin
#888D BIT 0, (IX+#00)
#8891 CALL #94FD
#8894 BIT 1, (IX+#7F)
#8898 CALL #94FD
...
Нужно найти причину, по которой во второй строке трейсинга выводится #8892 вместо #8891. Может быть оно и правильно исполняется, но по трейсингу пока этого не видно.Цитата:
Сообщение от Lisitsin
Поймал:
В строке 16. "BIT 7, (IX - #01)" по #88BE должен взводить SF, если тестируемый бит взведен.Цитата:
Сообщение от Lisitsin
Идёт !!! вместе с IY !!!!!!!
LDI failed.
Условие: PC=#89AE ИЛИ #89B0. Регистры PC, BC, DE, HL, AF.Цитата:
Сообщение от Lisitsin
Флаги для всего семейства LDI, LDD, LDIR и LDDR:
- SF, ZF и CF не меняем.
- Флаги 3 и 5. Если принять r за значение ячейки, которое читается из (HL) и пишется в (DE), то разряд 3 (считая от 0) суммы r+A (где A -- это регистр A) даст значение для флага 3, а бит 1 этой суммы даст значение для флага 5.
- PF взведен, если BC (после декремента) не равен нулю.
- HF и NF сброшены.
Если это инструкция с повторением (LDIR, LDDR) и если она должна быть повторена (то есть BC после декремента не равен нулю), тогда PC уменьшается на два, то есть, становится на начало той же инструкции, и MEMPTR получает PC+1, где PC -- это уже уменьшенное на два прежнее значение PC. MEMPTR устанавливается только в этом случае. Если это инструкция без повтора или если повтора нет, MEMPTR остается прежним.
LDI, LDD, LDIR, LDDR Passed. CPI, CPD FAILED:
Условие: PC=#89AE ИЛИ #89B0. Регистры PC, BC, HL, AF.Цитата:
Сообщение от Lisitsin
Обратите внимание, что условие то же, что и для LDI. Чтобы поймать именно CPI нужно выводить трейсинг только после того, как управление пройдет по адресу PC=#8966.
Флаги:
- SF, ZF и HF выставляются так же, как в инструкции "CP n", где в роли "n" -- значение ячейки в (HL).
- Флаги 3 и 5. Вычисляем значение r = A - n - HF. Здесь "A" -- это регистр A, "n" -- значение ячейки, "HF" -- значение флага HF (0 или 1). Здесь берется не значение HF на входе, а значение этого флага уже после выполнения "CP n". Как и в случае с LDI, во флаг 3 копируем разряд 3 значения "r", а во флаг 5 -- разряд 1 того же значения.
- PF устанавливаем так же, как в LDI.
- NF нужно взвести.
- CF не меняем (то есть, он должен быть такой же, как на входе, а не такой, как после "CP n").
MEMPTR:
CPI и CPIR увеличивают MEMPTR на 1.
CPD и CPDR уменьшают MEMPTR на 1.
Но: если исполняется CPIR или CPDR и нужное значение не найдено (сравнение дало сброшенный ZF) и BC не равно 0, тогда PC уменьшается на 2, после чего MEMPTR получает значение PC+1. Во всех остальных случаях MEMPTR остается прежним.
Ваши консультации бесценны !
CPI, CPD прошли. CPDR и CPIR я прописал, но следом за CPD в тесте идёт INI, которая у меня пока не реализована. Может продолжем с ввода-вывода?
А CPIR и CPDR в тесте и нету, поэтому будем продолжать по списку.Цитата:
Сообщение от Lisitsin
Пока пишу про группу INI, несколько вопросов. Есть ли подвижки в правильности/стабильности работы Бейсика? Осталась ли проблема с загрузкой программ с ленты? Можете ли загрузить zexall? Если можете, подтверждает ли он наш прогресс? И как с загрузкой и работой игр, с которыми раньше были проблемы?
---------- Post added at 19:20 ---------- Previous post was at 18:54 ----------
Условие для INI то же, что для CPI, но для начала трассировки управление должно пройти через PC=#8976.
Для этих инструкций лучше MEMPTR посчитать до вычисления флагов. Для INI и INIR MEMPTR получает значение BC-1, для IND и INDR -- значение BC+1. Здесь BC -- это значение регистра до декремента B.
Флаги:
- SF и флаги 3 и 5 копируются из соответствующих разрядов регистра B (после его декремента).
- ZF выставляется как результат проверки регистра B (после его декремента) на равенство нулю.
- PF выставляется как флаг четности для 8-разрядного значения, которое вычисляется так. Берем младшую половину MEMPTR (после его установки как описано выше), прибавляем к нему значение, прочитанное из порта. Назовем эту промежуточную сумму "cf". Затем берем три младших разряда этой суммы и делаем XOR с регистром B (после его декремента). Вот для этого сумасшедшего числа и считаем четность, и выставляем PF.
- HF и CF. Если сумма "cf" дает переполнение (то есть, было переполнение при 8-разрядном сложении младшей половины MEMPTR с регистром B), тогда взводим HF и CF. Иначе, оба флага сброшены.
- NF копируем из старшего разряда значения, прочитанного из порта.
Значит дело такое: самая большая продвижка по бейсику была последняя - страниц 15 назад. Бейсик вообще был нестабилен. Сейчас стоит как вкопанный. Есть один постоянный глюк, проявляется при загрузке с ленты: с первого раза нет автоматического старта загрузчика. Zexall вообще не грузится (приложение). ROBOCOP при старте игры или виснет или сбрасывается в бейсик. Есть простенькая игрушка - feenix - она работает.
Вопрос: а куда читается при этом байт из порта? В А?