If you can run in Linux or Android I would recommend Valgrind (http://valgrind.org/). It is the best tool for the job.

I've tried to place data breakpoints using Visual Studio, but the error still occurs during the PIT audio rendering(rendering the raw 44.1kHz audio stream to the double buffer). I've fixed some buffers to work properly(adjusting some of the 3 channel variables to support the full 6-channel array properly). Eventually, the error still occurs. Since it only seems to occur when emulating the Compaq Deskpro 386(with it's BIOS from the PCjs project( http://www.pcjs.org/devices/pcx86/rom/compaq/deskpro386/ ), converted from the .hex files on the repository), it seems to have something to do with one of the extensions of the Compaq Deskpro 386? The only things that currently come to mind are the memory modules(new memory schemes) and the EISA PITs(which seem to get used) at ports 0x48, 0x49, 0x4A and 0x4B. It's supposed to use the same scheme as the PC-compatible ports, just a second chip at I/O base 0x48? It shouldn't be connected to anything?

Confirmed: disabling the compaq's 6 channel PIT(two PITs actually), instead using the PC-compatible 3-channel PIT, makes UniPCemu not crash anymore. So there's a problem with the 6-channel PIT emulation itself it seems. I've already increased all the buffers to support 6 channels, but for some unknown reason, it's still crashing the application when used?

PIT source code: https://bitbucket.org/superfury/unipcemu/src/ … pit.c?at=master

Edit: Just found the bug: when writing port 0x48, 0x49 and 0x4A(PIT 3,4,5 timers), it was still incorrectly decreasing the PIT port number, making it 0x47, 0x48 and 0x49. Then, when determining the PIT to use, it was anding the value with 3(thus creating pit relative numbers 3, 0, 1) and adding the PIT base(3 in this case). Thus resolving to PIT 6, 3 and 4. Since only 6 PIT counters exist, it would result in a buffer overflow(only indexes 0-5 exist(6 PIT channels). Index 6 is invalid(causing a buffer overflow on some or any accesses using them).

Having fixed that, the Compaq Deskpro 386 BIOS continues running past the Tseng ET4000 BIOS, now resulting in a "303-Keyboard Controller Error".

Is the Compaq Deskpro 386 using a regular IBM AT-compatible 8042?

I've added and modified the 8042 to be Compaq-compatible when using the Compaq Deskpro 386 architecture. The command overrides have been added, although the speed commands are largely a mystery, as nothing is explained in the Bochs ioports.lst file? Anyone can explain them?

Also, what is the difference between a 9-bit and 11-bit keyboard? Doesn't the Deskpro have PS/2 mouse support(AUX bit 5 of the 8042 status register)?

What is your documentation for the Deskpro 386? BOCHS port list?

vladstamate wrote:

What is your documentation for the Deskpro 386? BOCHS port list?

That's correct(as well as the only source of documentation I have, besides the maintenance stuff found with google, which doesn't add anything useful). The ROMs used are converted from the .hex files on the PCjs repository.

Is there the second CMOS chip on the Deskpro 386? How much RAM does it have? The first contains up to 128 bytes(address 0x7F), but how much does the second at port 0x74/0x76 have? Is it just an 8-bit index at 0x74 and data read/write at 0x76? Does it contain 256 bytes of RAM?

What about those undocumented speed commands? What do they do on the 8042 by Compaq? It isn't compatible with a normal, seeing as it uses speed commands instead of password support commands? What about CMOS RAM address 0(the configuration byte)? Is it 8042-compatible?

I do not have the answers to these questions, I am sorry. I do not have a Deskpro 386 in my collection. And the information online seems sparse. Try asking at vintage computer forums (vcfed). There must be some owners there.

I've managed to fix the keyboard checks: apparently no 0xFA(acnowledge) is given on the Compaq 8042(it's given on the AT, though) 0xAA self test command. It now passes the keyboard/8042 check and hangs/stops at POST Diagnostic code 09h(according to http://ryan.servehttp.com/tech/hardware/bios/compaqbios.htm, it's the Reset code in CMOS byte). So there's a CMOS or reset problem?

These are the POST Diagnostics codes I'm getting with plain VGA emulation:

100:01:54:44.09208: POST Code: 00
200:01:54:45.00264: POST Code: 01
300:01:54:45.00288: POST Code: 02
400:01:54:45.00296: POST Code: 03
500:01:54:45.00304: POST Code: 04
600:01:54:45.00320: POST Code: 05
700:01:54:45.00336: POST Code: 06
800:01:54:45.00368: POST Code: 08
900:01:54:45.00536: POST Code: 09
1000:01:54:45.00592: POST Code: 0F
1100:01:54:45.00640: POST Code: 10
1200:01:54:45.00704: POST Code: 11
1300:01:54:45.01784: POST Code: 12
1400:01:54:51.05832: POST Code: 13
1500:01:54:51.06856: POST Code: 14
1600:01:54:51.06880: POST Code: 15
1700:01:54:51.06920: POST Code: 17
1800:01:54:51.06928: POST Code: 18
1900:01:54:51.06944: POST Code: 40
2000:01:54:51.07000: POST Code: 2F
2100:01:54:51.07040: POST Code: 41
2200:01:54:51.07072: POST Code: 42
2300:01:54:73.09048: POST Code: 43
2400:01:54:73.09072: POST Code: 44
2500:01:54:94.04088: POST Code: 45
2600:01:55:37.00248: POST Code: 43
2700:01:55:37.00272: POST Code: 44
2800:01:55:58.06176: POST Code: 45
2900:01:55:79.03064: POST Code: 46
3000:01:55:79.03088: POST Code: 19
3100:01:55:79.03104: POST Code: 30
3200:01:56:03.03608: POST Code: 31
3300:01:56:03.03720: POST Code: 32
3400:01:56:03.04008: POST Code: 33
3500:01:56:03.04032: POST Code: 34
3600:01:56:03.04656: POST Code: 36
3700:01:56:03.04664: POST Code: 38
3800:01:56:03.04704: POST Code: 39
3900:01:56:03.04768: POST Code: 3A
4000:01:56:03.04824: POST Code: 3B
4100:01:56:03.04968: POST Code: 52
4200:01:56:16.02720: POST Code: 53
4300:02:35:85.01088: POST Code: 8C
4400:02:35:85.01120: POST Code: 1A
4500:02:35:85.01136: POST Code: 50
4600:02:35:85.01136: POST Code: 51
4700:02:35:85.01200: POST Code: 52
4800:02:36:01.02864: POST Code: 1B
4900:02:36:22.04192: POST Code: 1C
5000:02:36:22.04208: POST Code: 90
5100:02:36:22.04752: POST Code: 91
5200:02:36:22.04768: POST Code: 1D
5300:02:36:22.04784: POST Code: 93
5400:02:36:22.05024: POST Code: 94
5500:02:36:23.00032: POST Code: 95
5600:02:36:23.00096: POST Code: 96
5700:02:36:23.00112: POST Code: 2D
5800:02:36:23.00112: POST Code: 0D
5900:02:36:23.00160: POST Code: 0E
6000:02:36:23.00240: POST Code: 1E

6100:02:36:23.00256: POST Code: 80
6200:02:36:23.00272: POST Code: 81
6300:02:36:23.00288: POST Code: 82
6400:02:36:23.00304: POST Code: 84
6500:02:36:23.00320: POST Code: 1F
6600:02:36:23.00352: POST Code: 75
6700:02:36:23.00368: POST Code: 76
6800:02:36:23.01200: POST Code: 77
6900:02:36:23.01232: POST Code: 78
7000:02:36:23.04464: POST Code: 00
7100:02:36:23.04496: POST Code: 01
7200:02:36:23.04512: POST Code: 02
7300:02:36:23.04528: POST Code: 03
7400:02:36:23.04528: POST Code: 04
7500:02:36:23.04544: POST Code: 05
7600:02:36:23.04560: POST Code: 06
7700:02:36:23.04592: POST Code: 08
7800:02:36:23.04960: POST Code: 09

So there's a problem returning from Protected mode? Since it goes from 78 to 00(reset vector)? Or is that supposed to happen? It eventually skips 07(which doesn't exist on the BIOS) and gets to 08(Initialize 8259,80287) and finally at 09(Reset code in CMOS byte)? Then something's going wrong?

So it at least gets to "xf78e: mov al,0x78 ; 0000F78E B078 '.x'", according to http://www.pcjs.org/devices/pcx86/rom/compaq/ … /1988-01-28.asm .

Then it sets the 8042 POST ready flag(reflected in bit 2 of the 8042 command byte(and Status register using that). It then proceeds to reset the CPU using the 8042 ending up at that point(POST Code 09). Then it seems to hang for some reason.

Do you know where it's supposed to end up now? I can't find the corresponding line in the disassembled code.

After looking and comparing the disassembly, it ends up at F000:0001, which throws itself into an infinite loop?

1xchg	bh,bl			; 00008000  86FB  '..'
2	xor	bh,bh			; 00008002  32FF  '2.'
3	shl	bx,1			; 00008004  D1E3  '..'
4	mov	dx,[bx+0x50]		; 00008006  8B975000  '..P.'
5	mov	[bp+0x2],dx		; 0000800A  895602  '.V.'
6	mov	cx,[0x60]		; 0000800D  8B0E6000  '..`.'
7	mov	[bp+0x4],cx		; 00008011  894E04  '.N.'
8	mov	word [bp+0x0],0x0	; 00008014  C746000000  '.F...'
9	ret				; 00008019  C3  '.'

CX being 1 and keeps being loaded with 1 from DS:060(word variable containing 1)?

This is the code causing it:

1;
2;   Verify that the CMOS SHUTDOWN byte is <= 0x0B (and if not, set it to 0x00)
3;
4;   NOTE: This test permits 0x0B, but there is no entry for 0x0B in the table at xf8e7.
5;
6	cmp	bl,0xb			; 0000F9F3  80FB0B  '...'
7	jna	xf9fa			; 0000F9F6  7602  'v.'
8	mov	bl,0x0			; 0000F9F8  B300  '..'
9;
10;   Dispatch according to the CMOS SHUTDOWN byte
11;
12xf9fa:	xor	bh,bh			; 0000F9FA  32FF  '2.'
13	shl	bl,1			; 0000F9FC  D0E3  '..'
14	mov	si,[cs:bx+xf8e7]	; 0000F9FE  2E8BB7E7F8  '.....'
15	mov	ax,0x40			; 0000FA03  B84000  '.@.'
16	mov	ds,ax			; 0000FA06  8ED8  '..'
17	jmp	si			; 0000FA08  FFE6  '..'

The value of BL is zero(00h). Thus the mov si,[cs:bx+xf8e7] should fetch ba95 from the table. But instead it fetches 0001h? So either the ROM is incorrect(which I doubt) or the fetch itself is incorrect for some reason(offset calculation failing).

Edit: Just looked at the BIU executing during that instruction. It DOES read 0xBA95 from the table. So there's something going wrong in the instruction parsing itself, for some reason?

Looking at the BIU again, I notice that during the first request (the first time it passes checkpoint 09h), it's request and response queue are empty. But when it reaches the second time, the response queue already has a response ready from a previous operation(which, not coincidentally, contains the value 1), which is immediately read by the instruction and loaded into SI. This causes the incorrect loop.

So there's an instruction(data handler) somewhere, that's not handling it's result phase after requesting data from the BIU, aborting before it reads the data from the BIU, causing the BIU to give the data to the next instruction that requests anything(whether read or write). So now it's a hunt for the instruction that's ending before it has the chance to give it's result.

Edit: Searched most modules, only GRP opcodes still might continue instruction execution without waiting for the BIU properly(afaik).

1*=checked
2CPU_PUSH8/16_BIU(finished) used by *CPU8086_PUSHb, *CPU8086_internal_PUSHb
3CPU_POP8/16_BIU(finished) used by *CPU8086_POP*b/*w, *CPU8086_internal_POPw
4* CPU_PUSH32_BIU(finished) unused
5* CPU_POP32_BIU(finished) unused
6
7*GRP opcodes: not needed(always terminates automatically, as defined by subfunction(nothing after the memory operations until returning to the CPU core)).
8
9CPU8086_internal_INC*/*DEC/*ADD/*ADC/*OR/*AND/*SUB/*SBB/*XOR/*MOV/*XCHG8
10CPU8086_internal_ADD*/*ADC/*OR/*AND/*SUB/*SBB/*XOR/*MOV/*XCHG16
11*CPU186_internal_MOV16
12modrm_write8_BIU==0(pending BIU to request)/1(pending result) used by *CPU8086_instructionstepwritemodrmb, *CPU8086_internal_stepwritemodrmb
13modrm_write16_BIU==0(pending BIU to request)/1(pending result) used by *CPU8086_instructionstepwritemodrmw, *CPU8086_internal_stepwritemodrmw
14* modrm_write32_BIU==0(pending BIU to request)/1(pending result) unused
15modrm_read8_BIU==0(pending BIU to request)/1(pending result) used by *CPU8086_internal_stepreadmodrmb, *CPU8086_instructionstepreadmodrmb
16modrm_read16_BIU==0(pending BIU to request)/1(pending result) used by *CPU8086_internal_stepreadmodrmw, *CPU8086_instructionstepreadmodrmw
17* modrm_read32_BIU==0(pending BIU to request)/1(pending result) unused

Looking at the POST codes reported, it now hangs with the BIU in a inproper state(having a result of the BUS(I/O) operation to port 0x84(The diagnostic output port).

Edit: Having fixed the BIU/EU emulation to wait to the start of the next instruction, which inhibits fetching instructions when resetting the CPU. It will then wait for the BIU to release the BUS. Once the BUS is released, the resetting of the complete CPU state will execute externally, from the emulator core. This will cause the BIU to start up at the correct cycle(first T1 cycle), leaving no running instruction data behind. That way, the CPU will continue to function properly, using the BIU without problems(since it's properly synchronized with the EU, instead of it remaining in a state waiting for any residual data(like results of memory/BUS accesses)).

It now properly gets past the reset checkpoint and displays an error on the mid BIOS ROM memory area(address 0xFE0000).

I've just checked the AT 80286 emulation: it's now working properly again too! So the problem with the CPU resetting was causing the BIU to get out of sync with the EU, causing a complete halt of execution in that case(the BIU having data left in it's buffers from previous operations, causing the EU to read incorrect data from memory or discarding data read from memory).

Edit: It does seem to go wrong with the BOUND instruction checks, for some reason.

I've modified the reserved memory to be the last 386KB on top of the memory that's detected. So 4MB will result in 386KB more memory. That seems to fix those memory errors. Now I'm getting a 301-Keyboard error? It finds 4480KB of memory.

The bug in the bound instruction that doubles the fault raising level(raised twice plus once each cycle) has been fixed. The AT BIOS works better now.

The diagnostic log resolves to: "Reset A20, set default CPU speed" as the final entry? Can you tell me anything about that?

Edit: This should be workimg, but it somehow doesn't? The 8042 does properly support the 0xD0/0xD1 commands and SHOULD execute them. But the code crashes instead?

1xbce9:	mov	al,0x24			; 0000BCE9  B024  '.$'
2	out	0x84,al			; 0000BCEB  E684  '..'
3	in	al,0x60			; 0000BCED  E460  '.`'
4	mov	al,0xd0			; 0000BCEF  B0D0  '..'
5	out	0x64,al			; 0000BCF1  E664  '.d'
6xbcf3:	in	al,0x64			; 0000BCF3  E464  '.d'
7	test	al,0x2			; 0000BCF5  A802  '..'
8	jz	xbcfb			; 0000BCF7  7402  't.'
9	jmp	short xbcf3		; 0000BCF9  EBF8  '..'
10
11xbcfb:	in	al,0x64			; 0000BCFB  E464  '.d'
12	test	al,0x1			; 0000BCFD  A801  '..'
13	jz	xbcfb			; 0000BCFF  74FA  't.'
14	in	al,0x60			; 0000BD01  E460  '.`'
15	and	al,0xfd			; 0000BD03  24FD  '$.'
16	and	al,0xf3			; 0000BD05  24F3  '$.'
17	mov	ah,al			; 0000BD07  8AE0  '..'
18	mov	al,0xd1			; 0000BD09  B0D1  '..'
19	out	0x64,al			; 0000BD0B  E664  '.d'
20xbd0d:	in	al,0x64			; 0000BD0D  E464  '.d'
21	test	al,0x2			; 0000BD0F  A802  '..'
22	jnz	xbd0d			; 0000BD11  75FA  'u.'
23	mov	al,ah			; 0000BD13  8AC4  '..'
24	out	0x60,al			; 0000BD15  E660  '.`'
25	mov	al,0x25			; 0000BD17  B025  '.%'
26	out	0x84,al			; 0000BD19  E684  '..'

8042 emulation: https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master

Can you see what's going wrong?

Edit: It seems like it's treating commands to the 8042 and data to/from the 8042 the same as normal keyboard input/output. Is that the same for all 8042 commands and I/O?

Is it correct that even communication with the 8042 itself results in the same input/output behaviour as the first PS/2 device(a.k.a. keyboard)? So bit 1 of the status register shows the transfer to the 8042(completed when emptied), with the same for data sent to the 8042 itself(e.g. new RAM data using commands 60-7F), while it looks like data from the keyboard arrives when the 8042 gives a result(like the result of the 0xAA command giving 0x55 from the 'keyboard')? So the keyboard uses much the same I/O methods as the 8042, with the only difference being bit 3 of the status port? Does it only change when sending data?

I do not think you can have same command number that means something both to the 8042 and the keyboard/mouse device attached. So based on the command you can figure out if it is for the keyboard or not.

I don't mean the command number or data itself. I mean the way data is transported. So things like Status port input being the same as keyboard, input data method using the same output buffer as the keyboard, sending command data(write to port 0x64) using the same input buffer as the keyboard, while data parameters(write to port 0x60) essentially works the same as for the keyboard.

Although you can replace keyboard above with connected device #1(First PS/2 port).

So it would probably increase compatibility to modify the 8042 to send commands/data and receive results in the same way as the keyboard data(although 8042 would have priority over keyboard)? That would probably fix the remaining problems with the 8042 chip emulation?

The data for keyboard and mouse devices are already timed in a roughly cycle-accurate way. I would simply have to add an alternative route for port 1(8042 having priority) input/output, while port 0x64 writes would be handled like some kind of Output this byte to the 8042(in much the same way a data byte is sent to the second PS/2(mouse) that's connected using one 0xDX(don't remember which one atm) command followed by a write to port 0x60 to send it to the second port. Although in this case, it's redirected to the 8042, with the data written to port 0x64 placed in the input buffer.

Btw, I'm using input/output buffers from the hardware perspective.

Would that fix those remaining I/O bugs?

So, essentially, the 8042 commands and data/results would be much like the keyboard and mouse, although it's using a third(invisible, acting like the keyboard) channel with highest priority and a seperate port(0x64) to send special data bytes using an override on the keyboard, which receives, acting as the keyboard(except different result bytes etc.) to act the same as a real chip.

Would that work?

I've implemented the 8042 using the input/output buffers to receive and send command/data of the 8042. But for some unknown reason, it now doesn't get past the reset point, or something related, correctly?

These are the changes I've made that hang the BIOS it for some reason:
https://bitbucket.org/superfury/unipcemu/comm … 4f2971b61740a27

Can you see what's going wrong?

I've improved the sending algorithm a bit(splitting special output cases 4 and 5 for sending to the input buffer of the first and second PS/2 devices), as well as reimplementing the "special reed", as documented in the ioports.lst to hide the buffer full bit when reading the buffer full bit(bit 0 of the status register).

This is the current log I'm getting:

100:00:11:67.04739: POST Code: 00
200:00:11:67.06088: POST Code: 01
300:00:11:67.09164: POST Code: 02
400:00:11:67.09172: POST Code: 03
500:00:11:67.09179: POST Code: 04
600:00:11:67.09209: POST Code: 05
700:00:11:67.09226: POST Code: 06
800:00:11:67.09258: POST Code: 08
900:00:11:67.09450: POST Code: 09
1000:00:11:67.09506: POST Code: 0F
1100:00:11:67.09560: POST Code: 10
1200:00:11:67.09599: POST Code: 11
1300:00:11:68.00614: POST Code: 12
1400:00:11:74.03774: POST Code: 13
1500:00:11:74.04745: POST Code: 14
1600:00:11:74.04776: POST Code: 15
1700:00:11:74.04814: POST Code: 17
1800:00:11:74.04840: POST Code: 18
1900:00:11:74.04866: POST Code: 40
2000:00:11:74.04943: POST Code: 2F
2100:00:11:74.04991: POST Code: 41
2200:00:11:74.05013: POST Code: 42
2300:00:11:96.06937: POST Code: 43
2400:00:11:96.06983: POST Code: 44
2500:00:12:17.03257: POST Code: 45
2600:00:12:60.00720: POST Code: 43
2700:00:12:60.00741: POST Code: 44
2800:00:12:80.08496: POST Code: 45
2900:00:13:01.06215: POST Code: 46
3000:00:13:01.06243: POST Code: 19
3100:00:13:01.06254: POST Code: 30
3200:00:13:26.01137: POST Code: 31
3300:00:13:26.01219: POST Code: 32
3400:00:13:26.01504: POST Code: 33
3500:00:13:26.01528: POST Code: 34
3600:00:13:26.02161: POST Code: 36
3700:00:13:26.02171: POST Code: 38
3800:00:13:26.02213: POST Code: 39
3900:00:13:26.02277: POST Code: 3A
4000:00:13:26.02335: POST Code: 3B
4100:00:13:26.02478: POST Code: 52
4200:00:13:38.09310: POST Code: 53
4300:00:44:93.09116: POST Code: 8C
4400:00:44:93.09144: POST Code: 1A
4500:00:44:93.09156: POST Code: 50
4600:00:44:93.09164: POST Code: 51
4700:00:44:93.09212: POST Code: 52
4800:00:45:09.07396: POST Code: 1B
4900:00:45:31.00552: POST Code: 1C
5000:00:45:31.00564: POST Code: 90
5100:00:45:31.01100: POST Code: 91
5200:00:45:31.01112: POST Code: 1D
5300:00:45:31.01124: POST Code: 93
5400:00:45:31.01368: POST Code: 94
5500:00:45:31.08832: POST Code: 95
5600:00:45:31.08880: POST Code: 96
5700:00:45:31.08892: POST Code: 2D
5800:00:45:31.08900: POST Code: 0D
5900:00:45:31.08944: POST Code: 0E
6000:00:45:31.08996: POST Code: 1E

6100:00:45:31.09004: POST Code: 80
6200:00:45:32.02308: POST Code: 81
6300:00:45:32.07100: POST Code: 82
6400:00:45:32.07112: POST Code: 84
6500:00:45:33.00884: POST Code: 1F
6600:00:45:33.00964: POST Code: 75
6700:00:45:33.00992: POST Code: 76
6800:00:45:34.06360: POST Code: 77
6900:00:45:34.06424: POST Code: 78
7000:00:45:36.01172: POST Code: 00
7100:00:45:36.01212: POST Code: 01
7200:00:45:36.01228: POST Code: 02
7300:00:45:36.01236: POST Code: 03
7400:00:45:36.01240: POST Code: 04
7500:00:45:36.01260: POST Code: 05
7600:00:45:36.01276: POST Code: 06
7700:00:45:36.01308: POST Code: 08
7800:00:45:36.01456: POST Code: 09
7900:00:45:36.01516: POST Code: 0F
8000:00:45:36.01576: POST Code: 10
8100:00:45:36.01616: POST Code: 11
8200:00:45:36.02200: POST Code: 12
8300:00:45:44.03424: POST Code: 13
8400:00:45:44.04452: POST Code: 14
8500:00:45:44.04484: POST Code: 15
8600:00:45:44.04528: POST Code: 17
8700:00:45:44.04540: POST Code: 18
8800:00:45:44.04552: POST Code: 40
8900:00:45:44.04616: POST Code: 2F
9000:00:45:44.04660: POST Code: 41
9100:00:45:44.04692: POST Code: 42
9200:00:45:72.09724: POST Code: 43
9300:00:45:72.09768: POST Code: 44
9400:00:45:99.02124: POST Code: 45
9500:00:46:54.06116: POST Code: 43
9600:00:46:54.06136: POST Code: 44
9700:00:46:82.00400: POST Code: 45
9800:00:47:08.06724: POST Code: 46
9900:00:47:08.06752: POST Code: 19
10000:00:47:08.06764: POST Code: 30
10100:00:47:40.06612: POST Code: 31
10200:00:47:40.06700: POST Code: 32
10300:00:47:40.06980: POST Code: 33
10400:00:47:40.07004: POST Code: 34
10500:00:47:40.07624: POST Code: 36
10600:00:47:40.07632: POST Code: 38
10700:00:47:40.07676: POST Code: 39
10800:00:47:40.07740: POST Code: 3A
10900:00:47:40.07820: POST Code: 3B
11000:00:47:40.07972: POST Code: 52
11100:00:47:57.05688: POST Code: 53

Anyone knows what's going wrong here?

When reading POST 53h, the cursor jumps down some, after which it seems to reset(it looks like a vertical tab is issued?)?