VOGONS

Common searches


Search results

Display options

Re: test386.asm CPU tester

I'm just asking to be sure: to the CPU, does a 2-operand opcode 69/6B(IMUL r16,imm8/16) even exist? Or does it always decode to 3 operands, with r/m and immediate being multiplied and stored into the reg operand? Didn't we discuss this previously? The AX register as destination parameter is …

Re: test386.asm CPU tester

@vladstamate: Add another one with SIB disp32 variant for the full 12 byte instruction length? Or another one for 32-bit 66h 0Fh OP modrm SIB disp32 imm32? Isn't that more than 12(13)? Although only newer CPUs have such 0F opcodes?

Re: test386.asm CPU tester

I'm just asking to be sure: to the CPU, does a 2-operand opcode 69/6B(IMUL r16,imm8/16) even exist? Or does it always decode to 3 operands, with r/m and immediate being multiplied and stored into the reg operand?

Re: test386.asm CPU tester

There's something I notice about the test386.asm repository: it does seem to have a EE file(test386-EE-reference) for normal logs, but not another one for the logs for the undefined flags as well(the TEST_UNDEF enabled test)? Also, looking at the normal log(the undefined logs HLTs when enabled?), by …

Re: test386.asm CPU tester

This is the code DAS executes: byte CPU8086_internal_DAS() { INLINEREGISTER byte tempCF, tempAL; INLINEREGISTER word bigAL; bigAL = (word)(tempAL = REG_AL); tempCF = FLAG_CF; //Save old values! CPUPROT1 if (((bigAL&0xF)>9) || FLAG_AF) { oper1 = bigAL = REG_AL-6; REG_AL = oper1&255; FLAGW_CF(tempCF …

Re: test386.asm CPU tester

I've just tried running the current version(with my own patch which is posted at https://github.com/barotto/test386.asm/issues/2 for logging in UniPCemu(and Bochs)). There are differences in the IMUL8 W section all the way to the DIVDL B section, which seems to still crash somehow before logging …

Re: Common log format

You still forgot to update one thing: the DR5&7 on the full log example, which is supposed to be DR7. Edit: We also still need to do something about the memory access logging, as it's essential to things like instructions that have memory operands(their input and output has effect on execution after …

Re: Common log format

I've modified the logging as follows now: CR5-7 are removed from logging, only CR4 is left on that line(only with 80486+). DR4-5 are ommitted from logging, only DR6 and DR7 are logged(no 5&7 anymore). I see that on your website the DR5&7 is still mentioned(which should be DR7 only now). I still …

Re: Common log format

CR4 seems to exist on some later 80486 models(e.g. 80486-DX2) with PSE. As far as I can see, the plain 80486(SX/DX) doesn't have it? I'm emulating a plain 80486SX/DX, so no CR4 exists?

Re: Common log format

Don't DR4&5 both either redirect to DR6&7 or both fault, depending on DE in CR4(Pentium+). DE set makes it fault, while cleared gives 80386-compatible redirection. Essentially always 'cleared' on pre-Pentium, so DR4&5 don't exist anyway(no way to actually access them due to #UD). So it's just CR0, …

Re: Common log format

Well, that's the odd one: registers 5&7 map to the same register(DR7), or fault depending on DE in CR4. DR4 doesn't exist depending on DE bit and CPU? http://www.felixcloutier.com/x86/MOV-2.html https://stackoverflow.com/questions/21901742/ … r5-are-not-used

Re: Common log format

Yes, it's the address that goes through Paging translation unit to RAM/hardware after all(linear->physical translation layer logging). Currently Paged accesses are usually prefixed(reads) or suffixed(writes) with the RAM layer(or none when accessing hardware, since hardware doesn't log anything, …

Re: Common log format

OK. I've made a little log of the first BIOS ROM executions with the full memory log enabled(seperate line for each layer, used with the normal debugging log modes in UniPCemu): Reading from physical memory: FFFFFFF0=EA (ê) Reading from paged memory: FFFFFFF0=EA (ê) Reading from physical memory: …

Re: Common log format

OK. Now the entire universal log format is in lower case(except register names, which are in upper case). The only thing still left in upper case is the instruction opcode bytes themselves(e.g. 5b for an POP BX instruction, which follows the instruction address itself). Now, what do we do about …

Re: Common log format

If that's correct for register state(it contains all register states now after all, depending on the CPU), we still have the issue of the memory accesses. Currently, all memory accesses are dumped during the cycle they occur(one liner or multiple lines, depending on the debugging mode). It either …

Re: Common log format

Just implemented all of those 4 points. All that's left is reversing the flags. Edit: One strange thing though: representing the IOPL value in the flags. Reversing those would make you read them backwards instead(as a binary value)? Edit: Reversing complete: F000:0000FFF0 EA 45 00 00 F0 jmp f000: …

Re: Common log format

1,3&4: You're right, I'll fix those right away. 2: The difference is in the register type: TR and LDTR are essentially segment registers, just like the CS/DS/ES/FS/GS? IDTR/GDTR on the other hand are just simple pointers with limits, nothing more, unlike the others.

Re: Common log format

I've imptoved the logging, not requiring protected mode and only depending on the CPU when logging: F000:0000FFF0 EA 45 00 00 F0 jmp f000:00000045 Registers: EAX: 00000000, EBX: 00000000, ECX: 00000000, EDX: 00000308 ESP: 00000000, EBP: 00000000, ESI: 00000000, EDI: 00000000 CS: F000, DS: 0000, ES: …

Page 179 of 275