вот такая штука. Стал смотреть что у меня по тесту неверно с командами CPD[r], CPI[r]. Нашел ошибку, исправил. Стало совпадать. Но по дороге качнул исходник US 0.34b, и посмотрел, так же он делает как я с этими командами. Оказалось, что совсем не так. У SMT в коде для CP к примеру:
void __fastcall ope_A9(Z80 *cpu) { // cpd
cpu->t += 8;
unsigned char cf = cpu->f & CF;
cp8(cpu, rm(cpu->hl--));
cpu->f = (cpu->f & ~(CF|PV)) | cf;
if (--cpu->bc16) cpu->f |= PV;
}
флажки XF и YF строятся на основании результата сранения A-(HL). А у меня по Янгу: YF=bit1 of n, XF=bit3 of n, где n=A-(HL)-HF. Результат "всеобъемлющего" теста тем не менее совпадает в обоих случаях. Какой же это тогда "всеобъемлющий" тест?
Разбирясь с тем, как выполняет Spectaculator команду bit 0,b (первую же в этом тесте, я наткнулся вот на какую штуку. [...вырезано: LD SP,(addr) нет в списке влиящих на memptr, еще надо найти, какая же команда установила memptr перед попаданием на 9C09h, мда] Факт, однако: тест zexall по команде bit n,(HL) Spectaculator проходит, т.е. его контрольная сумма совпадает с результатами колонки Z80(real) для этой команды (замечу: у единственного из всех эмуляторов. Правда, у него есть другие ошибки, но на прошлой неделе это впрямь был самый точный среди всех).
Сейчас пытаюсь "прогнать" еще и Spin. Ага, есть результаты. Вот обновленная табличка.
(Я свой EmuZWin пока не обновляю, хочу еще посмотреть чего-нибудь, и надо для случая fast CPIR/CPDR код поправить).
Кстати, у кого под рукой линукс, не займетесь пополнением инфы для тамошних эмуляторов? Лично меня особо интересует Fuse, можно и глюкалку прогнать (так, кажется называется альтернатива на той платформе?).
Ответить с цитированием