Well it loads to the top of available memory your int 12h tells it.
If you say you have 640kb of memory available, you don't have EDBA and it loads top of memory.
If you do have EDBA, you have 639kb of memory available, and it leaves the last 1kb with EDBA untouched and that is why it is loaded 1kb earlier.

OK, so the instructions are doing what they're supposed to do?

It seems to not read anymore sectors when it gets to reading 690:5400 (0x11(=17) sectors).

Anyone knows why (is it looping again)?

Jepael is correct regarding the int 12h - the high segment might not be exactly what I wrote. I should have been more clear.
There is nothing wrong with the current log, except that it stops too soon. There's a long rep movsw sequence which does not complete before the log ends.

The new log:

It seems to crash on an CO-processor (FPU) opcode, which isn't implemented. This gives a co-processor fault, which is, by default, not installed (just an IRET instruction). This hangs the CPU. Why doesn't MS-DOS install a coprocessor interrupt handler?

It's not the FPU, it's here:
0:01:06:97.9.0000: 02B7:1537 (871E7C05)XCHGW BX,[DS:057C]
The exchange was not performed. Shortly after it:
0:01:06:98.2.0000: 02B7:153F (36FF167C05)CALL [SS:057C]
Without the memory write, that pointer is garbage, and the call goes somewhere random.

Fixed the XCHGW bug.

I'm getting the wrong address, what's supposed to be

b72:10 (1)

Is:

10:01:08:42.3.0000: Function 02 called.
2
30:01:08:51.1.0000: Read 1/1 sectors from drive 00, start 0. Requested: Head: 0, Track: 0, Sector: 1. Start sector: 0, Destination: ES:BX=0070:00000281

For some reason it ends with a short jump to itself?

10:01:17:99.3.0000: 0247:479B (EBFE)JMP 479B

10:01:17:97.3.0000: 0247:4A2F (7415)JZ 4A46
20:01:17:97.3.0000: Registers:
30:01:17:97.3.0000: AX: 0236, BX: 367A, CX: 0003, DX: 0000
40:01:17:97.3.0000: CS: 0247, DS: 0070, ES: 0247, SS: 0247
50:01:17:97.3.0000: SP: 0870, BP: 03E6, SI: 0236, DI: 04E8
60:01:17:97.3.0000: IP: 4A2F, FLAGS: 0016
70:01:17:97.3.0000: FLAGSINFO:c1P0A0zstido0000

This branch is supposed to be taken so the above rep cmpsb is likely not working properly.

This is my REP instruction handling (executed after the opcode is retrieved and executed. CPU_resetOP sets up CS:(E)IP back to the start of the opcode for running it again.)

Is this correct? It seems to not reset at all in this case (after the REP, CX>0 and ZF=0).

1--CPU.registers->CX; //Decrease the counter!
2						if (CPU_getprefix(0xF2)) //REPNZ?
3						{
4							if (!CPU.registers->SFLAGS.ZF) //To reset the opcode (FLAG_ZF quits the loop)?
5							{
6								if (CPU.registers->CX) //Left to run?
7								{
8									CPU_resetOP(); //Retry!
9								}
10							}
11						}
12						else if (CPU_getprefix(0xF3))
13						{
14							if (REPZ) //REPZ?
15							{
16								if (CPU.registers->SFLAGS.ZF) //To reset the opcode (no FLAG_ZF quits the loop)?
17								{
18									if (CPU.registers->CX) //Left to run?
19									{
20										CPU_resetOP(); //Retry!
21									}
22								}
23							}
24							else //REP?
25							{
26								if (CPU.registers->CX) //Left to run?
27								{
28									CPU_resetOP(); //Retry!
29								}
30							}
31						}

0:01:16:48.6.0000: 0247:1E27 (AC)LODSB

There might be a problem at this point - the path is empty.
On my image, there is "A:\" here.
The code path differs greatly because of that.

Do you have an autoexec.bat? I don't on my image.

Here we go. We start with this:

0:01:14:36.6.0000: 0247:4A97 (8976FA)MOVW [SS:BP-06],SI
0:01:14:36.6.0000: Registers:
0:01:14:36.6.0000: AX: 0003, BX: 0001, CX: 367A, DX: 1C85
0:01:14:36.6.0000: CS: 0247, DS: 9DE1, ES: 0247, SS: 0247
0:01:14:36.6.0000: SP: 086C, BP: 0872, SI: 0000, DI: 0360
and
0:01:14:36.7.0000: 0247:4A9A (8C5EFC)MOVW [SS:BP-04],DS
0:01:14:36.7.0000: Registers:
0:01:14:36.8.0000: AX: 0003, BX: 0001, CX: 367A, DX: 1C85
0:01:14:36.8.0000: CS: 0247, DS: 9DE1, ES: 0247, SS: 0247
so
SS:BP-06=9DE1:0000

Then
0:01:16:44.2.0000: 0247:4B04 (C576FA)LDS SI,[SS:BP-06]
0:01:16:44.4.0000: CS: 0247, DS: 9DE1, ES: 0247, SS: 0247
0:01:16:44.4.0000: SP: 086C, BP: 0872, SI: 0000, DI: 0000

confirmed, but

0:01:16:45.1.0000: 0247:4B25 (C47EFA)LES DI,[SS:BP-06]
0:01:16:45.3.0000: CS: 0247, DS: 9DE1, ES: 8E26, SS: 0247
0:01:16:45.3.0000: SP: 086C, BP: 0872, SI: 0000, DI: 006E

Not anymore. My guess: DS: is being used instead instead of SS:.
[BP+xx] uses SS: implicitly, unless there's a different override.

A new log, with a bit of fixes in my debugger and CPU:

Edit: You're right about DS being used. The LDS/LES instructions just take the offset and read it using default segment DS instead of SS. I'm fixing that now (maybe I need to rewrite the ModR/M handling a bit, since it only supports normal 16-bit reads. So I need to add 2 to the ModR/M offset, need to add it to the parameters...

Edit: It's been adjusted and should be working properly now:

It keeps looping it seems. Is there a wrongly loaded INT13 destination?

There's doesn't seem to be anything wrong with the log, apart from it stopping too soon.
The loop is a search for config.sys, and then autoexec.bat. Finding neither, it will eventually execute date and time instead.

It continues running and now gives me a "Bad or missing Command Interpreter" message.

The latest log:

So it can't find the COMMAND.COM executable now? Why? It should be in the root directory, which is read again (sector 19). It's the third entry in the root directory.

Also, I seem to get a strange output to ports 0x2F2-0x2F7, all outputting 0xFF.

10:02:24:66.1.0000: 9DFD:0A4E (B0FF)MOVB AL, FF
2
30:02:24:66.1.0000: Registers:
4
50:02:24:66.1.0000: AX: A0C0, BX: 0004, CX: 0000, DX: A0C0
6
70:02:24:66.2.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
8
90:02:24:66.2.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
10
110:02:24:66.2.0000: IP: 0A4E, FLAGS: 0282
12
130:02:24:66.2.0000: FLAGSINFO:c1p0a0zStIdo0000
14
15
16
170:02:24:66.2.0000: 9DFD:0A50 (BAF202)MOVW DX, 02F2
18
190:02:24:66.3.0000: Registers:
20
210:02:24:66.3.0000: AX: A0FF, BX: 0004, CX: 0000, DX: A0C0
22
230:02:24:66.3.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
24
250:02:24:66.3.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
26
270:02:24:66.3.0000: IP: 0A50, FLAGS: 0282
28
290:02:24:66.3.0000: FLAGSINFO:c1p0a0zStIdo0000
30
31
32
330:02:24:66.4.0000: 9DFD:0A53 (EE)OUT DX,AL
34
350:02:24:66.4.0000: Registers:
36
370:02:24:66.4.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F2
38
390:02:24:66.5.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
40
410:02:24:66.5.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
42
430:02:24:66.5.0000: IP: 0A53, FLAGS: 0282
44
450:02:24:66.5.0000: FLAGSINFO:c1p0a0zStIdo0000
46
47
48
490:02:24:66.5.0000: 9DFD:0A54 (42)INC DX
50
510:02:24:66.6.0000: Registers:
52
530:02:24:66.6.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F2
54
550:02:24:66.6.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
56
570:02:24:66.6.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
58
590:02:24:66.6.0000: IP: 0A54, FLAGS: 0282
60

610:02:24:66.6.0000: FLAGSINFO:c1p0a0zStIdo0000
62
63
64
650:02:24:66.7.0000: 9DFD:0A55 (EE)OUT DX,AL
66
670:02:24:66.7.0000: Registers:
68
690:02:24:66.7.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F3
70
710:02:24:66.7.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
72
730:02:24:66.8.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
74
750:02:24:66.8.0000: IP: 0A55, FLAGS: 0206
76
770:02:24:66.8.0000: FLAGSINFO:c1P0a0zstIdo0000
78
79
80
810:02:24:66.8.0000: 9DFD:0A56 (42)INC DX
82
830:02:24:66.8.0000: Registers:
84
850:02:24:66.9.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F3
86
870:02:24:66.9.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
88
890:02:24:66.9.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
90
910:02:24:66.9.0000: IP: 0A56, FLAGS: 0206
92
930:02:24:66.9.0000: FLAGSINFO:c1P0a0zstIdo0000
94
95
96
970:02:24:67.0.0000: 9DFD:0A57 (EE)OUT DX,AL
98
990:02:24:67.0.0000: Registers:
100
1010:02:24:67.0.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F4
102
1030:02:24:67.0.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
104
1050:02:24:67.1.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
106
1070:02:24:67.1.0000: IP: 0A57, FLAGS: 0202
108
1090:02:24:67.1.0000: FLAGSINFO:c1p0a0zstIdo0000
110
111
112
1130:02:24:67.1.0000: 9DFD:0A58 (42)INC DX
114
1150:02:24:67.1.0000: Registers:
116
1170:02:24:67.2.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F4
118
1190:02:24:67.2.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
120
1210:02:24:67.2.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
122
1230:02:24:67.2.0000: IP: 0A58, FLAGS: 0202
124
1250:02:24:67.2.0000: FLAGSINFO:c1p0a0zstIdo0000
126
127
128
1290:02:24:67.3.0000: 9DFD:0A59 (EE)OUT DX,AL
130
1310:02:24:67.3.0000: Registers:
132
1330:02:24:67.3.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F5
134
1350:02:24:67.3.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
136
1370:02:24:67.4.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
138
1390:02:24:67.4.0000: IP: 0A59, FLAGS: 0206
140
1410:02:24:67.4.0000: FLAGSINFO:c1P0a0zstIdo0000
142
143
144
1450:02:24:67.4.0000: 9DFD:0A5A (42)INC DX
146
1470:02:24:67.4.0000: Registers:
148
1490:02:24:67.5.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F5
150
1510:02:24:67.5.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
152
1530:02:24:67.5.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
154
1550:02:24:67.5.0000: IP: 0A5A, FLAGS: 0206
156
1570:02:24:67.5.0000: FLAGSINFO:c1P0a0zstIdo0000
158
159
160
1610:02:24:67.6.0000: 9DFD:0A5B (EE)OUT DX,AL
162
1630:02:24:67.6.0000: Registers:
164
1650:02:24:67.6.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F6
166
1670:02:24:67.6.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
168
1690:02:24:67.7.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
170
1710:02:24:67.7.0000: IP: 0A5B, FLAGS: 0206
172
1730:02:24:67.7.0000: FLAGSINFO:c1P0a0zstIdo0000
174
175
176
1770:02:24:67.7.0000: 9DFD:0A5C (42)INC DX
178
1790:02:24:67.7.0000: Registers:
180
1810:02:24:67.8.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F6
182
1830:02:24:67.8.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
184
1850:02:24:67.8.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
186
1870:02:24:67.8.0000: IP: 0A5C, FLAGS: 0206
188
1890:02:24:67.8.0000: FLAGSINFO:c1P0a0zstIdo0000
190
191
192
1930:02:24:67.9.0000: 9DFD:0A5D (EE)OUT DX,AL
194
1950:02:24:67.9.0000: Registers:
196
1970:02:24:67.9.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F7
198
1990:02:24:67.9.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
200
2010:02:24:68.0.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
202
2030:02:24:68.0.0000: IP: 0A5D, FLAGS: 0202
204
2050:02:24:68.0.0000: FLAGSINFO:c1p0a0zstIdo0000
206
207
208
2090:02:24:68.0.0000: 9DFD:0A5E (B800F0)MOVW AX, F000
210
2110:02:24:68.0.0000: Registers:
212
2130:02:24:68.1.0000: AX: A0FF, BX: 0004, CX: 0000, DX: 02F7
214
2150:02:24:68.1.0000: CS: 9DFD, DS: 9DFD, ES: 098E, SS: 9DFD
216
2170:02:24:68.1.0000: SP: 0962, BP: 7440, SI: FFFF, DI: 0195
218
2190:02:24:68.1.0000: IP: 0A5E, FLAGS: 0202
220
2210:02:24:68.1.0000: FLAGSINFO:c1p0a0zstIdo0000

There seems to be a problem between here:

0:02:09:93.9.0000: 9DFD:0B56 (AB)STOSW
0:02:09:93.9.0000: Registers:
0:02:09:93.9.0000: AX: 3A41, BX: 0210, CX: 0005, DX: 0000
0:02:09:93.9.0000: CS: 9DFD, DS: 0247, ES: 0B75, SS: 9DFD
0:02:09:93.9.0000: SP: 0966, BP: 7440, SI: 7420, DI: 0000

0:02:09:94.2.0000: 9DFD:0B5B (AB)STOSW
0:02:09:94.2.0000: Registers:
0:02:09:94.3.0000: AX: 005C, BX: 0210, CX: 0005, DX: 0000
0:02:09:94.3.0000: CS: 9DFD, DS: 0247, ES: 0B75, SS: 9DFD
0:02:09:94.3.0000: SP: 0966, BP: 7440, SI: 7420, DI: 0002

0:02:09:94.3.0999: Registers:
0:02:09:94.5.0000: SP: 0966, BP: 7440, SI: 7420, DI: 0004

and here:

0:02:42:72.5.0000: 0247:1E3A (F2AE)REPNZSCASB
0:02:42:72.5.0000: Registers:
0:02:42:72.5.0000: AX: 0000, BX: 0362, CX: FFFF, DX: 0000
0:02:42:72.5.0000: CS: 0247, DS: 0247, ES: 0B75, SS: 0247
0:02:42:72.5.0000: SP: 0854, BP: 03E6, SI: 0360, DI: 0000
0:02:42:72.6.0000: IP: 1E3A, FLAGS: 0046
0:02:42:72.6.0000: FLAGSINFO:c1P0a0Zstido0000

0:02:42:72.6.0000: 0247:1E3C (F7D1)NOTW CX
0:02:42:72.6.0000: Registers:
0:02:42:72.6.0000: AX: 0000, BX: 0362, CX: FFFE, DX: 0000
0:02:42:72.7.0000: CS: 0247, DS: 0247, ES: 0B75, SS: 0247
0:02:42:72.7.0000: SP: 0854, BP: 03E6, SI: 0360, DI: 0001

because the memory was erased. Without the drive letter, DOS can't find any file.
If you watch for writes to B75:0000, it might be obvious what's going wrong, but I doubt that I'll see it in the log.

This seems to cause the override:

10:08:51:39.7.0000: Read from memory: 000007B4=00
2
30:08:51:39.8.0000: Read from memory: 000007B5=01
4
50:08:51:39.8.0000: Writing to memory: 00002C9C=70
6
70:08:51:39.9.0000: Writing to memory: 00002C9D=00
8
90:08:51:39.9.0000: Writing to memory: 00002C9A=D8
10
110:08:51:40.0.0000: Writing to memory: 00002C9B=0F
12
130:08:51:40.0.0999: Read from memory: 000007B4=00
14
150:08:51:40.0.0999: Read from memory: 000007B5=01
16
170:08:51:40.2.0000: Read from memory: 000007B6=00
18
190:08:51:40.2.0000: Read from memory: 000007B7=F0
20
210:08:51:40.3.0000: ModR/M address: 0070:00B4=000007B4
22
230:08:51:40.3.0000: 0070:0FD3 (2EFF1EB400)CALL [CS:00B4]
24
250:08:51:40.4.0000: Registers:
26
270:08:51:40.4.0000: AX: 0201, BX: 0010, CX: 0002, DX: 0100
28
290:08:51:40.5.0000: CS: 0070, DS: 0070, ES: 0B54, SS: 0247
30
310:08:51:40.5.0000: SP: 082E, BP: 0005, SI: 0522, DI: 0482
32
330:08:51:40.5.0999: IP: 0FD3, FLAGS: 0097
34
350:08:51:40.5.0999: FLAGSINFO:C1P0A0zStido0000
36
37
38
390:08:51:40.7.0000: Writing to memory: 00002C98=00
40
410:08:51:40.8.0000: Writing to memory: 00002C99=F0
42
430:08:51:40.9.0000: Writing to memory: 00002C96=05
44
450:08:51:40.9.0000: Writing to memory: 00002C97=01
46
470:08:51:40.9.0999: F000:0100 (9A060100F0)CALL f000:0106
48
490:08:51:40.9.0999: Registers:
50
510:08:51:41.0.0999: AX: 0201, BX: 0010, CX: 0002, DX: 0100
52
530:08:51:41.0.0999: CS: F000, DS: 0070, ES: 0B54, SS: 0247
54
550:08:51:41.2.0000: SP: 082A, BP: 0005, SI: 0522, DI: 0482
56
570:08:51:41.2.0000: IP: 0100, FLAGS: 0097
58
590:08:51:41.3.0000: FLAGSINFO:C1P0A0zStido0000
60

61
62
630:08:51:41.4.0000: ModR/M address: 0070:0532=00000C32
64
650:08:51:41.4.0000: F000:0106 (FE380800)<INTERNAL CALLBACK> 0008
66
670:08:51:41.4.0999: Registers:
68
690:08:51:46.0.0000: AX: 0201, BX: 0010, CX: 0002, DX: 0100
70
710:08:51:46.1.0000: CS: F000, DS: 0070, ES: 0B54, SS: 0247
72
730:08:51:46.2.0000: SP: 0826, BP: 0005, SI: 0522, DI: 0482
74
750:08:51:46.2.0000: IP: 0106, FLAGS: 0097
76
770:08:51:46.2.0999: FLAGSINFO:C1P0A0zStido0000

The final byte of the final sector overwrites the drive letter (A):

10:08:52:09.9.0000: Writing to memory: 0000B750=00
2
30:08:52:10.0.0000: Read from memory: 0000B750=00

This starts from B550 up to and including B750 (a difference of 512 bytes, or 1 sector read). Shouldn't this be 1 byte less? So B550-B74F=512 bytes written to memory)?

I've changed the INT13 handler to read a byte from disk until (!--left), where left starts with 512, instead of until (!left--), so:

1left = 512; //We have read 512 bytes from disk.
2for (;;)
3{
4read byte from disk
5write byte to RAM (@ES:offset++)
6if (!--left) break;
7++sectorindex; //Next sector byte!
8}

It kept running now, even getting undefined opcodes (0F00).

This was caused by an error because the INT13 didn't read 512 byte sectors into memory, but 513 bytes (512 bytes sector data plus 1 byte junk).
It reads 512 byte sectors into memory correctly now and reads multiple sectors OK too.

It now seems to go and try load COMMAND.COM correctly:

10:04:47:36.3.0000: Read from memory: 000027D3=43 C
2
30:04:47:36.3.0000: Read from memory: 000027D4=4F O
4
50:04:47:36.4.0000: Read from memory: 000027D5=4E N
6
70:04:47:36.4.0000: Read from memory: 000027D6=46 F
8
90:04:47:36.5.0000: Read from memory: 000027D7=49 I
10
110:04:47:36.5.0000: Read from memory: 000027D8=47 G
12
130:04:47:36.5.0000: Read from memory: 000027D9=2E .
14
150:04:47:36.6.0000: Read from memory: 000027DA=53 S
16
170:04:47:36.6.0000: Read from memory: 000027DB=59 Y
18
190:04:47:36.7.0000: Read from memory: 000027DC=53 S
20
210:04:47:36.7.0000: Read from memory: 000027DD=00

10:06:15:14.0.0000: Read from memory: 00002CDC=43 C
2
30:06:15:14.0.0000: Read from memory: 00002CDD=4F O
4
50:06:15:14.1.0000: Read from memory: 00002CDE=4D M
6
70:06:15:14.1.0000: Read from memory: 00002CDF=4D M
8
90:06:15:14.2.0000: Read from memory: 00002CE0=41 A
10
110:06:15:14.2.0000: Read from memory: 00002CE1=4E N
12
130:06:15:14.3.0000: Read from memory: 00002CE2=44 D
14
150:06:15:14.3.0000: Read from memory: 00002CE3=2E .
16
170:06:15:14.3.0000: Read from memory: 00002CE4=43 C
18
190:06:15:14.4.0000: Read from memory: 00002CE5=4F O
20
210:06:15:14.4.0000: Read from memory: 00002CE6=4D M
22
230:06:15:14.5.0000: Read from memory: 00002CE7=00
24
250:06:15:14.5.0000: 0247:1E3A (F2AE)REPNZSCASB
26
270:06:15:14.6.0000: Registers:
28
290:06:15:14.6.0000: AX: 0000, BX: 0362, CX: FFF4, DX: 0000
30
310:06:15:14.6.0000: CS: 0247, DS: 0247, ES: 0247, SS: 0247
32
330:06:15:14.7.0000: SP: 085C, BP: 0862, SI: 04F1, DI: 0877
34
350:06:15:14.7.0000: IP: 1E3A, FLAGS: 0006
36
370:06:15:14.8.0000: FLAGSINFO:c1P0a0zstido0000

After that it executes an infinite loop?

The log has become too big to upload here, so I've uploaded it at my own site:
http://superfury.heliohost.org/cplusplus/debu … 150321_1853.zip

As far as I can see, it's the final B30:10 read in the sector list.

Why does it keep looping back to the same point? It never executes the final INT13 call to read COMMAND.COM into memory.

Anyone knows what's going wrong?

I can't check for a couple of weeks. If no-one solves it before then, I'll take a look.

I've made a new log, the CPU hasn't changed, but some bugsfixes in the VGA memory window (atm all modes except 256 color mode work, but this is probably a problem in rendering, not a problem from the CPU's perspective) and ASCII characters of MMU writes and reads have been added to the debugger log. You now can see that the CPU actually finds COMMAND.COM, but after that I don't know what it's trying to do, except looping infinitely?

I've compressed it into a 7-zip file, which seems to do a better job at it than the default Windows ZIP compression. Now I can upload it here again:

Anyone knows what's going wrong?

There appears to be some memory corruption.
The loop that spans 0247:42bd ... 430b never exits, because it can't find the end of the segment list.
The 13th entry value (0b33) is wrong - should be 0b54, and the 14th entry (0b54) points to itself instead of holding 0ffff.

0:02:15:04.0.0000: 9DFD:0D97 (803E3F08FF)CMPB [DS:083F],FF
The value here depends on the BIOS. Since our BIOS files differ, execution diverges significantly, and I can't investigate further.
I'm using the BIOS from Bochs. It's freely available, and then we might be able to pinpoint the cause of the problem.

The value is overwritten at 048D:043A (REP MOVSW) as far as I can see (simply looking for the address). It writes 0xFF to the memory location you gave at DS:083F. Is this supposed to happen?

Btw I'm using my own BIOS (written for my emulator). The INT10 handler is partly copied from dosbox (adjusted video mode set from Dosbox-X, text mode fonts and font set from Dosbox SVN). For the rest handlers in my BIOS is a combination of my own internal calls and Dosbox's IRQ1&keyboard handler. The entry points for compatibility in the BIOS is filled too, as are the other compatibility entry points. I'll post a dump of my BIOS image for reference, although it won't work on other emulators because the internal calls aren't the same on other emulators. I do believe the final byte of the BIOS is set to 0xFF (IBM PC) when the BIOS ROM memory is generated, which explains the 0xFF?

Also will the BIOS even work? I can mount and POST from it, but will it run on my 8086/80186 processor with only IBM PC hardware (plus Adlib and MPU)? I do have a floppy disk controller with only read and write track&sector commands implemented atm (No seek or other command yet. Those other commands will just give an invalid command error).

Here's the latest version of my emulator, all set up to run. I've added the latest ROMS from Bochs for comparision. Just extract the files into a directory and run the emulator to get the full log.

The ROMS/BIOSROM.BIN (mapped at F000:(0000-FFFF)) is the latest BIOS-bochs-legacy and the ROMS/OPTROM.1 (mapped at C000:(0000-8000)) is the latest legacy VGA BIOS image for Bochs (VGABIOS-elpin-2.40).

It seems to fail/crash (although it's not crashing, as it keeps running): it runs dummy data commands (0x00) at the end.

When run, it creates a log directory with the full log of executed commands and memory addresses in logs/debugger.log.

It seems the legacy BIOS uses a 0F opcode, which doesn't exist on 80186 and is POP CS on a 8086 and #UD on 80186. It's currently running as a 80186.

If you want to run it the way I do, just enter the BIOS when starting the program and in the advanced menu change the execution mode to normal mode to run my own BIOS (BIOS will be dumped, when booting, to BIOSROM.DMP. This is FOR THIS EMULATOR ONLY. It's incompatible with other emulators, like Bochs and Dosbox. It will run, but all Internal Commands opcodes will have strange results, since they apply to my emulator only, and call different functions, nothing or strange functions when applied in Bochs or Dosbox (e.g. internal command #0 is the BIOS INT19/POST handler in my case, but can be anything in Bochs/Dosbox. DON'T USE IT WITH OTHER EMULATORS!)).

Simple usage manual:

Input buttons are mapped for the PSP and PC:
Mouse has no effect.
PC: PSP buttons.
Up/Down/Left/Right: Same buttons as the PSP.
4/8/6/2 (NUM PAD): SQUARE, TRIANGLE, CIRCLE, CROSS.
I,J,K,L: Analog Up, Analog Left, Analog Down, Analog Right.
Q,W: L trigger, R trigger.
Backspace: Select.
Enter: Start.
Ctrl: Home.
F12: Toggle fullscreen (PC only).

To enter the BIOS, press SELECT when on-screen (Both when the Normal mode is running it's POST and when starting execution (yellow text is showing).
Left/LTRIGGER and Right/RTRIGGER switch between menus.
Up/Down switch between options.
Cross confirms, Circle cancels, Triangle loads defaults, Square on disk toggles the readonly flag.
Place ROMS in the ROMS directory and disk images in the executable directory.