Это я нашёл и везде поправил. Но, видимо, где-то ещё есть ошибки. JR и ещё 11 отличных от Z80 команд тоже поменял, но пока BASIC не стартует.
Вид для печати
CityAceE, если ты вдруг пропустил.
CityAceE, возможно текущая правильность эмуляции команд только кажущаяся, лучше проверить эксисайзером. Например вот вариант адаптированный для специалиста HardWareManом, только этот еще с патченым стеком, чтобы не вылетал при скролле.
8080ex1 - это прямо то, что нужно было! Спасибо HardWareMan'у за адаптацию под Специалист, а ivagor'у за то, что поделился!
Запустил и тут же получил вот это:
https://pic.maxiol.com/images/154544...0validator.png
А после того, как профиксил логику флага полупереноса, которую я подглядел здесь, получил уже другой результат:
https://pic.maxiol.com/images/154544...validator2.png
Задолбался искать что не так. В итоге никак не получается победить ALUOP. В двух последних тестах ошибка. Вернее ошибка точно есть в тесте ALUOP NN, а результатов последнего теста я так и не смог дождаться. Часа 4 ждал и бросил. Начала теста ALUOP приходится ждать примерно 1,5 часа после запуска.
https://pic.maxiol.com/images/154556...lidatornew.png https://pic.maxiol.com/images/154556...idatornew2.png
Но зато сейчас работает всё то, что не работало до этого:
https://pic.maxiol.com/images/154556...878.adskok.png https://pic.maxiol.com/images/154556...3878.chess.png
Осталось чуть облагородить исходники и выложить всё это безобразие на GitHub.
b2m, если у него падает ALUOP NN и ALUOP (REGLIST), то флаги всех команд ALU надо смотреть. Напомню, что INR/DCR и DAD прогоняются через ALU (для INR загружается константа 0х01 а для DCR - 0xFF). Т.е., действительно следует проверить логику работы логических а не арифметических операций. Скорее всего опять же флаги AC/C в этих командах, т.к. остальные флаги слишком тупые.
HardWareMan, да кэп.
Сегодня произвёл серьёзный рефакторинг код, выделив все повторяющиеся части всех логических и арифметических операций в отдельные функции в ущерб и так никакой производительности скрипта. Несколько раз самым внимательным образом сравнил собственную эмуляцию с эталонным эмулятором. Но ALUOP NN, как и прежде, выдаёт ошибку. Даже не знаю в какую сторону копать. Наверное просто глаз замылился и я что-то упускаю.
Ну вот, например, так сейчас у меня выглядит эмуляция команды ORI на Python:
А вот для сравнения как эмуляция той же команды выглядит в эталонном эмуляторе на С:Код:def or_a(reg):
global reg_a, flag_p, flag_h, flag_c, flag_z, flag_s
reg_a |= reg
flag_s = bool(reg_a & 0b10000000)
flag_z = not reg_a
flag_h = False
flag_p = parity[reg_a]
flag_c = False
fflag_n(False)
fflag_3(bool(reg_a & 0b00001000))
fflag_5(bool(reg_a & 0b00100000))
return
def b11110110(): # OR A,d
global pc, ticks
or_a(read_mem(inc_pc()))
pc = inc_pc2()
ticks += 7
return
Как видите, на выходе получилось практически идентично. И всё равно тест проваливается.Код:#define ORA(val) \
{ \
A |= (val); \
S_FLAG = ((A & 0x80) != 0); \
Z_FLAG = (A == 0); \
CLR(H_FLAG); \
P_FLAG = PARITY(A); \
CLR(C_FLAG); \
}
case 0xF6: /* ori data8 */
cpu_cycles = 7;
work8 = RD_BYTE(PC++);
ORA(work8);
break;