Compaq Deskpro 386 CPU emulation issues?

[superfury]

Just tried the Supersoft/Landmark diagnostics ROM (1.2.0) from minuszerodegrees again. All seems to pass, but the U126 keybord controller test and Protected mode CPU test(usual cause, because of the IRET, giving #GP fault (when it apparently shouldn't) due to invalid segment register loading? Maybe task switching problem?)? The normal BIOS passes the PS/2 keyboard/8082 correctly. But this BIOS fails either or both of them?

Edit: I just see it using the 8042, no keyboard itself? So there's a problem with the 8042?

[superfury]

Oddly enough, sometimes dreams itself can find faults(if they're related!). In this case, the dream was about a problem with FDC port 3F4, which after some searching found out a bug in my emulation and the osdev.org article describing the BAR1/3 values of it's PCI IDE. The article describes values 0/1 becoming 3F6/376, while it's actually 3F4/374(according to https://forum.osdev.org/viewtopic.php?f=1&p=167798 ). So the osdev article has this little fact backwards(forgetting to substract 2 for that register!). Now implementing that into my emulation.

Edit: Implemented it, but no changes from software perspective(the end result is the same either way, just different unprecalculated base ports(n instead of n+2, with the +2(and -2 when decoding) part being moved to the port scanning/decoding part).

[superfury]

Just thinking about something... Could the reason the FDC worked somewhat on the AT before be because the FDC was properly preconfigured using GSETUP? I was trying to get it working with that(720K setting?)? That might help with the AT DIAGNOSTICS disks?

[superfury]

Just ran gsetup and rebooted into a 1.44MB Dos6.22 disk. Trying to seek to track 69 times out(resets)?

[superfury]

Booting from Dos 5.0a, running checkit 720K checks out properly during the read test. But trying the 1.44MB disks(B-drive) seems to fail?
It tells me cylinder 2&4 head 0 and 62 heads 0 and 1 and 68 head 0 fails with type MAJOR and Notes Drive Not Ready.
As far as I can see that can only happen due to the seeking taking too long(random sector reads moving the track for a too big distance to time, due to CPU timing issues?)?
So it's the same issue the AT had? Easily confirmed reading two tracks far apart after each other(e.g. first track 0 and then track 62(which times out))?

[superfury]

Didn't take much to create a simple program that for each track on a 80-track disk(tracks 0 to 79) executes a drive reset, then reads the first sector on said track. This is done for each of the 80 tracks and printed on screen if it had any errors. Since it's resetting the controller(thus recalibrating) before each read, a maximum distance is createn to seek, allowing FDC errors to be easily spotted.

https://bitbucket.org/superfury/unipcem ... ?at=master

[superfury]

Just ran my little program on the 1.44MB B drive(for which it's hardcoded) containing a simple testdisk(just some random 1.44MB MS-DOS 6.22 disk). All seeks(and corresponding reads of the first sector) check out correctly on the Compaq Deskpro 386 emulation!

So that actually means that the BIOS FDC handling is going without problems(at least concerning the basic first-random read of the first sector on said track). The application itself just performs a simple test: read all 80 tracks, reading sectors CHS C,0,1 from the disk after performing a disk controller reset for the B-drive(which resets the drive and recalibrates it to track 0) and then read one sector from the B-drive after that on the selected track. But if the CheckIt! Diagnostics software is failing it somehow, then why is that happening? Why do some of the random read accesses fail? It cannot be because the FDC times out, since it's still the BIOSes job?

[superfury]

Just tried a Dutch Dos 6.22 setup disk(disk 1) boot again. The setup seems to start without problems, but when detecting the hardware, it seems to once again crash into offset FFFF with an IRET? So there's definitely something going on there? That's not a FDC bug, but an actual CPU bug?

The problem is, are there any methods left to find the bug in the remaining CPU opcodes(ALL 80386 opcodes) not tested with the test386.asm testsuite?

Edit: It seems to crash at F000:EFE4?

[superfury]

Just found a little bug in the 32-bit popping of CS during a RETF, causing it to only pop a word instead of a dword. Thus two dword pops instead of a dword for EIP and a word for CS, resulting in an wrongly aligned stack.
Edit: It seems to have been correct before after all. It's thus restored to it's previous state.

[superfury]

I'm currently drawing a blank here on what's causing the odd jump during the different(Win95 as well as Dos6.22) setups. Earlier, it worked, but somewhere along the line, it started failing(might be due to who knows which commit). Since the last test on Dos6.22 setup was long ago, I also don't know what caused the bug to crash during setup. Anyone? Somewhere during "checking your system configuration", going into the bushes?

[superfury]

Just tried running the MS-DOS 6.22 setup on the XT NEC V30 configuration, which seems to end up in a "System error: 20<Newline>Continue?" from the Turbo XT BIOS v3.0, after which it performs an seemingly limited hardware reboot? So there's something awefully wrong there?

Edit: That error apparently is an Bad Expansion ROM Checksum after soft-reset?

Edit: I've made a little log of the setup detecting until it crashes into the Expansion ROM error: https://www.dropbox.com/s/c01sckr8vuo95 ... 46.7z?dl=0

Can anyone find the relevant errors? Jepael? Vladstamate? It's in the common log format, of course. It ends up back running in the Turbo XT BIOS v3.0 code, maybe part of the invalid jump? Maybe part of the cause?
Anyone? Jepael? Vladstamate?

Edit: At line 29544349 it seems to still be executing the program? Somewhere in there or near there the error occurs?

[superfury]

I've managed to track it down to line 29547644, where it's the final point that it registers to before rebooting? It seems to request a verify sectors instruction from the FDC and/or DMA controller? It's calling the interrupt 13h function from 2403:00000016, executing interrupt 13h function 04h(verify sectors). Maybe a DMA problem?

[superfury]

Reducing the machine to a 8088 XT seems to aggrevate the situation: it now reports error 65?
Edit: This seems to have been due to multiple keypresses during booting?

Edit: Since it's even crashing on the basic 8088 emulation, that means that there's probably a problem in the base 808X core? But what's going wrong?

https://bitbucket.org/superfury/unipcem ... ?at=master

Can anyone see what's going wrong? Reenigne? Jepael?

Edit: Just ran the 80186(actually originally ran on 80286 according to flags dumps) testsuite again. Three modules fail the tests:
- Shifts: All give 'incorrect' values on the low byte of the flags, on bit 7,6 and 3? test386.asm testsuite checks out on the 80386 emulation.
- BCDCNV: test386.asm checks out. 80286 fails on flags AAA(bit 7, 6, 4, 2), AAS(bit 7, 6), DAS(bit 11)?
- MUL: AAD 39h(bit 4, 11 set when expecting cleared), AAD 12h(bit 4, 0 set when expecting cleared)?

All other tests check out correctly?

[superfury]

Just tried the FreeDOS boot floppy version:

FreeDOS boot failing?

It seems to crash somehow, which does indicate a CPU bug somewhere? Does it use protected mode in any way? Or Virtual 8086 mode?

[superfury]

Just found a possible bug on the 80186+ LEAVE instruction. This was related to (E)SP being reset while popping (E)BP. This now works as it should.

Edit: Now FreeDOS seems to crash with an #UD exception? So there's now something going (else?) going very wrong?
Edit: Looking at the exception itself being triggered is actually an ARPL instruction executed from Real mode, causing a #UD exception because it isn't supported to be used in real mode? So maybe a problem regarding setting up protected mode in FreeDOS? The read instruction is 636520, which is a ARPL instruction?

Edit: Now dealing with the weirdness of the Compaq Deskpro accessing the FDC, regarding invalid track accesses and detection.

[superfury]

It seems to somehow seek to track 2, then proceeding to read a sector from track 1, which fails due to current track mismatch(would also happen on a real controller?). Is it somehow using double track seeking?

[superfury]

OK. So it's a 80386+ problem: Just tried the same on the AT configuration. It boots properly and seeks to cylinder 1 properly. Only the Compaq Deskpro 386 BIOS seems to somehow incorrectly seek to cylinder 2 instead of cylinder 1? Since it was working, only the ENTER and LEAVE instructions have been improved(80386+) and the FDC has been made more accurate regarding track management(seeks, recalibrates, disk access errors and physical vs controller's idea of the current cylinder).

[superfury]

Just looked at the int13h request that's being done in that case: It's requesting a read on cylinder 01h(registerCH), but seems to seek to cylinder 02h instead, for some odd reason? Thus probably a CPU bug?

This is what currently happens:

debugger-Dos5boot_CompaqDeskpro386-20180302_1623.7z

What happens when it's executing the int13 call seeking/reading the FDC track 1.

(332.79 KiB) Downloaded 20 times

Can anyone see what's going wrong? Vladstamate? I'm running the 1988/01/28 BIOS from the Compaq Deskpro 386-16.

[superfury]

Hmmmm..... Line 2170 loads the value 0x74 from the Drive 0,1,2,3 media state BDA entry at 40:90. That causes it to double step, multiplying the FDC SEEK track with 2(by shifting left 1) when seeking only. Thus it will end up at the incorrect track?

Code: Select all

f000:0000eeca 8A 27 mov ah,byte ds:[bx]   Physical(r):000FEED4=D0(Ð); Paged(r):000FEED4=D0(Ð); Physical(r):000FEED5=E0(à); Paged(r):000FEED5=E0(à)
Registers:
EAX: 00000101 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eeca EFLAGS: 00000206
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0a0P1c
   RAM(r):00007BB7=01(
); Physical(r):00007BB7=01(
); Paged(r):00007BB7=01(
)
   Physical(r):000FEED6=8A(Š); Paged(r):000FEED6=8A(Š); Physical(r):000FEED7=4F(O); Paged(r):000FEED7=4F(O)
f000:0000eecc 8A 46 05 mov al,byte ss:[bp+05]   Physical(r):000FEED8=04(); Paged(r):000FEED8=04(); Physical(r):000FEED9=32(2); Paged(r):000FEED9=32(2)
Registers:
EAX: 00007401 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eecc EFLAGS: 00000206
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0a0P1c
f000:0000eecf F6 C4 20 test ah,20   Physical(r):000FEEDA=E4(ä); Paged(r):000FEEDA=E4(ä); Physical(r):000FEEDB=3A(:); Paged(r):000FEEDB=3A(:)
Registers:
EAX: 00007401 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eecf EFLAGS: 00000206
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0a0P1c
   Physical(r):000FEEDC=C1(Á); Paged(r):000FEEDC=C1(Á); Physical(r):000FEEDD=74(t); Paged(r):000FEEDD=74(t)
   Physical(r):000FEEDE=5F(_); Paged(r):000FEEDE=5F(_); Physical(r):000FEEDF=88(ˆ); Paged(r):000FEEDF=88(ˆ)
f000:0000eed2 74 02 je 0000eed6
Registers:
EAX: 00007401 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eed2 EFLAGS: 00000202
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0a0p1c
   Physical(r):000FEEE0=47(G); Paged(r):000FEEE0=47(G); Physical(r):000FEEE1=04(); Paged(r):000FEEE1=04()
f000:0000eed4 D0 E0 shl al,1   Physical(r):000FEEE2=53(S); Paged(r):000FEEE2=53(S); Physical(r):000FEEE3=BB(»); Paged(r):000FEEE3=BB(»)
Registers:
EAX: 00007401 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eed4 EFLAGS: 00000202
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0a0p1c
   RAM(r):00000494=00( ); Physical(r):00000494=00( ); Paged(r):00000494=00( )
   Physical(r):000FEEE4=04(); Paged(r):000FEEE4=04(); Physical(r):000FEEE5=00( ); Paged(r):000FEEE5=00( )
f000:0000eed6 8A 4F 04 mov cl,byte ds:[bx+04]
Registers:
EAX: 00007402 EBX: 00000090 ECX: 00002300 EDX: 000003f7
ESP: 00007bac EBP: 00007bb2 ESI: 00007c2b EDI: 0000052b
CS: f000 DS: 0040 ES: 0000 FS: 0000 GS: 0308 SS: 0000 TR: 0000 LDTR: 0000
EIP: 0000eed6 EFLAGS: 00000212
CR0: 0000fff8 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 0000000f07300047 IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0n00odItsz0A0p1c

The double stepping shouldn't be used in the first place: The hardware uses single-stepping for all different FDC media types. So why does it detect so?

My notes:

Code: Select all

CALLER_AL   equ   0x00      ; [BP+0x00] = AL SECTORS TO READ
CALLER_AH   equ   0x01      ; [BP+0x01] = AH FUNCTION NUMBER
CALLER_BL   equ   0x02      ; [BP+0x02] = BL LOW PART OF DESTINATION OFFSET
CALLER_BH   equ   0x03      ; [BP+0x03] = BH HIGH PART OF DESTINATION OFFSET
CALLER_CL   equ   0x04      ; [BP+0x04] = CL SECTOR NUMBER
CALLER_CH   equ   0x05      ; [BP+0x05] = CH TRACK SELECTED
CALLER_DL   equ   0x06      ; [BP+0x06] = DL DRIVE TO USE
CALLER_DH   equ   0x07      ; [BP+0x07] = DH HEAD
CALLER_SI   equ   0x08      ; [BP+0x08] = SI
CALLER_DI   equ   0x0A      ; [BP+0x0A] = DI
CALLER_ES   equ   0x0C      ; [BP+0x0C] = ES DESTINATION SEGMENT
CALLER_DS   equ   0x0E      ; [BP+0x0E] = DS
CALLER_BP   equ   0x10      ; [BP+0x10] = BP
CALLER_IP   equ   0x12      ; [BP+0x12] = IP
CALLER_CS   equ   0x14      ; [BP+0x14] = CS
CALLER_FLAGS   equ   0x16      ; [BP+0x16] = FLAGS

ecc0: call 8fa4: Loads 40:8F(Combination hard/floppy disk card when bit 0 set)
x9190: Load media state address in BX based on [BP+06]. This results in [40:90] to be loaded for drive A(bit 0-2=media state, 4=drive established, 5=double step drive, 6-7=BPS rate(0=500k,1=300k,2=250k,3=reserved)).
xecf0: Start of the FDC operation
xca4f: Setup DMA for the transfer of data
:note opcode 86 has it's parameters reversed(two registers being switched around)? This has now been fixed(still reversed in the current log).
xc956: Enable the drive motors as required(and delay when started).

Edit: Looking at the occurrences of reads/writes to memory location 00000494(The byte containing the double step setting at bit 5(value 0x20)), I only see reads with the unchanged value. So the cause of the double step being set isn't caused during the current INT13h call, but some earlier INT13h call that causes it to detect a double step drive?

Edit: This seems to be established during the very first FDC access, reading the boot sector?
Edit: Looking at it again, the first time that bit(bit 5) is set(which stays set when set), is during the very first sector read operation of the FDC(C,H,S address 0,0,1; The boot sector). After that it remembers that it's supposed to be a 'double stepping' drive, thus multiplying all track numbers with 2 when seeking. This causes the current boot problem in some way.

Now the question: Why is it setting said bit? The drive isn't a double stepping drive, nor is it supposed to give any information to the CPU that should be identifying it as being one(reporting the same track as seeked to, as is detected by the IBM AT BIOS(which tries seeking and detecting the double stepping using a simple READ ID floppy command to verify it's on the right track, instead of a double stepping track).

Time for a dump of the boot sector being read...
Edit: This is the dump of the BIOS routine(interrupt 13h) executing (dumped in the common emulator format), which details what is happening when reading the very first FDC boot sector into memory(and consequently detecting that it's a 'double stepping' drive, which it isn't, causing all following track Seek commands to be doubled in size compared to their Read sector command counterparts, causing the FDC controller to error out with ST0=0x40).

https://www.dropbox.com/s/o5fob1o0rf79j ... 54.7z?dl=0
Warning: Since the text file is so large(1.5GB), it might crash/hang the OS(Like when using Notepad on Windows) due to the file being too large to process in memory. Use a large text file editor that is compatible with large files to read the log.

[superfury]

Looking for the changes to address 00000490 shows to me that at 000090A1, 0x61(300Kbps drive, double stepping required, media/drive not established, 360Kb diskette/1.2Mb drive not established) is loaded into the byte, which shouldn't happen? Or at least to be overwritten later? The block that sets this starts at (F000:)0000909B. Why is it ending up at that invalid location? Hmmm....

Edit: It seems the cause of it ending up there is the jump in the block at F000:00009072? So the cause starts at line 25817631?

Addition to my notes:

Code: Select all

F000:0000B544 Reads the CMOS register AL into AL.
The CMOS register that's read in the relevant block is register E of the CMOS(which is set to 0x44, being two 1.44MB floppy drives).
It tests bit 7(in this case, the second floppy drive's third bit, which is set), then jumps to the code that sets the invalid 0x61 value because the bit is set(the 0x40 bit in the floppy configuration byte in the CMOS RAM)?

Why would it set said bit(double stepping drive) when detecting the second floppy disk drive to be of type 4+(4=1.44MB and 5=2.88MB), thus 1.44MB or larger disks?

Edit: So, does that mean I have to set the second floppy disk to 720K at most(even though 1.44MB+ is theoretically supported by the BIOS) in order to keep booting properly?
Edit: Just changed it manually, since FDC booting fails. It will now seek correctly, but fail anyways?