VOGONS

Common searches


Search results

Display options

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: …

Re: Common log format

Got a good point there about showing all registers, they have values after all(initialized to zeroes by default/reset). Although real mode can't use some of them(LDTR, TR). Forgot about FS/GS: You're right about those.

Re: Common log format

This is what I currently use with UniPCemu(it logs all registers as well as some extra state info such as HLT and reset(first instruction after the CPU has been reset) status): OPTINLINE char decodeHLTreset(byte halted,byte isreset) { if (halted) { return 'H'; //We're halted! } else if (isreset) { …

Re: Common log format

I'm just thinking, shouldn't we add some kind of register dump/memory accesses to the logs? That way we can see exactly what goes wrong when executing instruction, instead of just execution path? UniPCemu can already log those, but it's currently disabled for the common log format(since we haven't …

Re: test386.asm CPU tester

You say a mov to [ESP], but according to https://pdos.csail.mit.edu/6.828/2016/readings/i386/s17_02.htm that doesn't exist? My emulator also uses 0 instead of ESP when addressed that way(base only, index still uses esp). Look at https://bitbucket.org/superfury/unipcemu/src/ …

Re: test386.asm CPU tester

The list file is unchanging, though(only if source code is changed in the testsuite, which is only the base constants and the additional logging code): Filename test386.lst.zip File size 63.42 KiB Downloads 56 downloads File comment LST file of the executable I'm using.

Re: test386.asm CPU tester

Strange: I only see UniPCemu emitting one 32-bit DIV instruction, which isn't overflowing or divide by 0? 0x245af920e27415a5 / 0x88776655 = 0x44332211 remainder 0. After the final IMUL32 D entry, it ends up at a interrupt-disabled HLT instruction? No DIV instruction is executed at all. test386_ …

Re: test386.asm CPU tester

Looking at the 0xEE output, the last line starts with "IMUL32 D EAX=FFFFFFFF EDX=FFFFFFFF PS=0000", which only appears once in the reference file. So the problem happens after returning from logging, but before the "DIVDL B EAX=00000000 EDX=00000000 PS=0000 #DE EAX=00000000 EDX=00000000 PS=0000" …

Re: test386.asm CPU tester

Looking at the debugger, the CPU seems to be idling during a JNZ rel32 instruction. Why? Because the BIU and EU are infinitely waiting for each other: The BIU Prefetch waits for the EU to load the TLB entry for the current byte address to continue fetching. The EU on the other hand, refuses to read …

Re: test386.asm CPU tester

Just pulled the latest changes: the lea tests(post E) seems to fail now? It didn't crash on the last build(ran within 0xEE before the latest commits)? Filename test386.zip File size 69.61 KiB Downloads 54 downloads File comment lst and bin file

Re: test386.asm CPU tester

Some simple Port E9 hack support(untested, but compiling with current masm): ; Port E9 hack support, with autodetection push eax ;Backup for autodetection in al, 0xE9 cmp al, 0xE9 jnz .noE9hack pop eax ; Restore register out 0xE9, al jmp .finishE9hack .noE9hack: pop eax ; Restore register . …

Page 179 of 274