I notice something interesting on the primary master: it issues a 0xEC command(Identify), but never reads the result after it's IRQ is fired(status register stays 0x48 from the point the IRQ is raised)?
The CD-ROM drive boots and detects without issues on the secondary ATA drive? I also only see the secondary drive accessing the alternate status register, but not on the primary? Is that maybe because of the"Resource Conflict" mentioned before the memory checking starts?
Anyone knows more about it? The PCI IDE is the only actual PCI hardware. All others are plain ISA(everything Dosbox has as well, minus 3D graphics cards and non-SB and only having plain SB2.0 hardware installed. ThenFDC is at it's legacy address(3F0-3F7(3F7 only bit 7)).
Just split the i430fx architecture from the Compaq Deskpro 386 with PS/2 extensions architecture(effectively making it use it's own CMOS RAM and disabling any Compaq-specific extensions to the AT architecture).
So the Compaq's special 1MB-2MB RAM addressing no longer applies(it now applies to all RAM, so A20 affects just A20, not just the 1MB-2MB memory area like the Compaq Deskpro 386 does).
The Compaq Deskpro 386-specific extensions(mainly, the Compaq Relocation registers and status register(the registers at memory address 80C00000h) are now disabled on said architecture (they would also conflict with said architecture and be unable to support both at the same time, mainly due to the low RAM area mapping without remapping it uses (from 640KB to 1MB)).
The same applies to the 80286 memory hole area(15MB-16MB), which is now managed differently, like a real 80286 does(the BIOS ROM being mapped there as well).
After having improved the ATA harddisk Identify command(0xEC) to set the Drive Seek Complete bit when giving it's results, the AMI BIOS no longer complains about it 😁
Now it just still complains about that "Resource Conflict" and "Cache Memory Error". The Resource Conflict is probably some conflict with IDE hard drives?
But what causes such a "Cache Memory Error"? Is it trying to do something special with the caches that needs implementation(and doesn't run well with uncached I/O)?
Edit: After some HDD autoconfiguration, the Windows 95 RTM HDD image boots without visible issues! It also detects the full 128MB RAM! 😁
Just found a little bug in the caching of the final byte (or addressing within that word or dword past the final byte of the ROM) of BIOS ROMs: When the byte past the final byte of the ROM was addressed, the cache would misbehave and return garbage read from memory, instead of properly terminating access to become it's proper other device or hardware when that happens(the next ROM, start of a RAM block or nothing being connected(0xFF response)).
I've implemented a simple define in the memory registration handler that disables the whole caching behaviour used by the MMU and all conntected hardware on the MMIO bus(so all device handlers but the input/output ports(IN/OUT instructions)). It doesn't seem to have any effect on the error message "Cache Memory Error" that's displayed at the end of the POST.
Anyone knows what this error means? What does it imply?
I noticed someting interesting with the i430fx motherboard BIOS. When I try to boot Hiren's boot CD for running diagnostic software, while the primary master and slave are a HDD (containing WIndows 95 RTM and the second hard drive containing a non-OS(probably not related)) and the secondary master/slave are the CD-ROM drives(The CD-ROM is in the secondary master CD-ROM drive), it will fail to boot the bootable CD-ROM, with a MS-DOS 7.1 error saying it can't locate Windows files for some reason? Isn't CD-ROM booting supposed to circumvent this?
Is this a real issue on said machine? Or is this perhaps an issue with UniPCemu's CPU or hardware emulation for some yet unknown reason?
Did find some bugs in the Keyboard controller chip emulation, though(For opcodes F4,F5,F6, which didn't properly give a result code).
I see one strange thing happening when saving BIOS configuration changes on the i430fx. When saving the changes, it does actually seem to save the changes, but it's supposed to reboot, which it doesn't? It just seems to hang?
The soft/hard reset functionality is already implemented (and it was working afaik), so why does it hang? Does it require triple faulting?
Also, it seems that booting MS-DOS 6.22 from the hard disk image on the primary master tries to read sector 0x3F(the volume boot record) and then aborts the booting process with an error message(the usual please insert a disk with an OS kind of message)? No IRQ is raised as the transfer completes, which it actually does (it seems the volume boot record is fully read by the MBR code?).
Edit: Floppy boots without issues, though? It's just the MS-DOS HDD boot that's failing on the i430fx machine?
Edit: Just confirmed. Windows 9x boots fine on the i430fx. Only normal MS-DOS (6.22 only, didn't check other MS-DOS versions) seems to fail booting(from the IDE HDD on the i430fx)?
Edit: OK. Found the reason why the boot fails. Reading sector at LBA 3Fh from the disk causes the INT 13h function 02h call to return with the carry flag set? So the interrupt 13h function 02h is failing(while it ran without issue when loading the MBR at sector #0)?
Hmmm... The interrupt returns to the interrupted procedure in the boot sector with the carry flag cleared, but the AL register(interrupt 10h function 02h) is cleared? So that would mean it's read 0 sectors from disk, while it should actually be 1 sectors read instead in AL?
Edit: It does actually seem to correctly read the data to the specified location in memory. So it continues executing the volume boot record from the hard disk at 0000:7c00(when arriving there at the second time).
Edit: So, the second time it reaches 0000:7C00, it will execute the boot record, but the boot volume is the hard disk(disk 80h in DL instead of a normal 00h/01h of the floppy disk).
The issue with it is, during the second time it reaching 0000:7c00, while executing the volume boot record(which is the same as a floppy boot sector), the disk is set to disk 80h. Somehow, the int 13h for function 00h(disk reset) with disk 80h seems to weirdly cause the result to set the carry flag, making the code abort and display the error message. That happens at 7.3.4, at address 7C70. Said interrupt will return with the carry flag set, which it shouldn't?
Edit: OK. The call sets SRST. It wasn't set before, so it activates the ATA/ATAPI SRST handling(resetting the drives). That sets the Drive Seek Complete flag and the drive should become busy.
Edit: Changed SRST and soft reset to change the status register back to 0x00 with the default poweron values in the registers when it's finished. (0x80 during busy, then becomes 0x40 once ready to receive a command).
Edit: Restored it to just setting the DSC bit for hard drives resetting(required to POST successfully).
There might be a little bug with jumping over INT instructions when in single-stepping mode using the emulator's internal debugger (Which I'm using to log the INT 13h call).
It's waiting for the interrupt's start EIP instead of the proper after INT EIP when skipped over using the square button.
OK. It does seem to become properly ready(0x50 in the status register from 0x90 during reset)...
That's read at F000:E745.
Edit: It reads the error register(0x00) after that?
Edit: It doesn't perform any reads/writes after that, aborting INT 13h with carry flag set?
Edit: At F000:8D03, it compares the error register to 1, which it doesn't find, thus reporting error and aborting the INT13 with carry set and AH=00h.
Edit: It seems that was the very cause of it being unable to boot MS-DOS: when resetting a drive (as the ATA-1 spec says) the error register should be 01h.
Although I do seem to remember having to make it 00h in some special case with booting debian Bo(some weird error checking when it's bits were set)?
OK. Found the root of the hard reset problem: A20 is somehow disabled when the reset is made, making the CPU fetch the instructions from FFEFFFFF, which are invalid opcodes (unmapped memory)!
Edit: Fixing A20 to be properly reset to their power on defaults when resetting the CPU in any way(depending on the required reset), it will now properly reboot the machine when a reset is requested, properly being able to reboot when saving BIOS settings changes in the i430fx BIOS.
Just found another small hardware bug when testing the PC Doctor software on the i430fx hardware. When the PS/2 controller was reset in some ways(other than a initialization), it would set the PS/2 mouse packet rate to 0 packets/second, which is invalid(it should actually be 100 packets/second). So the PS/2 mouse wasn't responding correctly if it was reset(not reporting anything anymore).
The ATA SRST still needs to have the drive stay ready(bit 6 set) when an ATAPI drive receives the SRST (still properly working with Device Reset(command 08h)).
If the BIOS notices that the device has the ready bit cleared, it won't actually send a ATAPI command to re-enable the registers, thus making it hang permanently on reading anything from the CD-ROM's mounted floppy disk image(which is mounted as logical drive #0)?
Just implemented the i440fx chipset based on Bochs' initial values and device IDs. Also implemented the DRAM memory chip detection based on Bochs' algorithm, but using UniPCemu's method of handling it.
It's basically the same as the i430fx chipset, as far as I can see, except the DRAM being populated differently(but having the same read/write effect) and some new PCI device IDs being used. Then just added a handful of new reset values.
That should theoretically be enough to get the i440fx running? So that means that 1GB of RAM can now be used on the i440fx?
Edit: Implemented the missing i440fx 93h register(Turbo Reset Control Register).
I once again look at the coreboot BIOS from Bochs running, but somehow I see it's waiting for the speaker PIT output to go high, while the PIT channel is actually waiting for a reload of the divider to start the timer? It's in mode 0(interrupt on terminal count)?
Now, just implemented and enabled the port 402h that coreboot always seems to use to log whether Qemu is present or not. This makes it quite a bit clearer what's happening (it's just redirecting said port to the porte9 log file(or whatever it's renamed as in software)):
100:00:33:83.05660: SeaBIOS (version rel-1.7.5-0-ge51488c-20140528_081134-morn.localdomain) 200:00:33:85.02252: No Xen hypervisor found. 300:00:33:94.04604: RamSize: 0x00100000 [cmos] 400:00:33:94.06808: Relocating init from 0x000dfbe9 to 0x0007eb70 (size 70700) 500:00:53:09.08996: CPU Mhz=33 600:00:55:92.02572: === PCI bus & bridge init === 700:00:55:92.03560: PCI: pci_bios_init_bus_rec bus = 0x0 800:00:55:92.05652: === PCI device probing === 900:00:55:93.02672: Found 3 PCI devices (max PCI bus is 00) 1000:00:55:93.04440: === PCI new allocation pass #1 === 1100:00:55:93.05860: PCI: check devices 1200:00:55:94.07816: === PCI new allocation pass #2 === 1300:00:55:94.08572: PCI: out of I/O address space
So apparently, it's trying to detect the PCI BAR sizes, which somehow seem too much?
Looking at the coreboot source code for that (src/fw/pciinit.c, function pci_bios_get_bar), I see it's using the normal detection method(write all ones, read it back, then and with mask, add 1 and mask again to 32-bits(the last one having no effect on x86, since all is 32-bit?)).
Edit: After checking the behaviour of the BARs, I've noticed 2 things:
1. The required detection of the PCI ROM addresses(PCI address 30h) was missing.
2. The required width of the PCI I/O BARs should actually be 32-bits instead of masked to 16-bits when the registers are updated.
Having fixed this, the coreboot BIOS ROM detects it correctly:
100:00:04:91.05093: SeaBIOS (version rel-1.7.5-0-ge51488c-20140528_081134-morn.localdomain) 200:00:04:93.02043: No Xen hypervisor found. 300:00:05:02.06135: RamSize: 0x00100000 [cmos] 400:00:05:02.08625: Relocating init from 0x000dfbe9 to 0x0007eb70 (size 70700) 500:00:05:19.09430: CPU Mhz=33 600:00:05:20.00327: === PCI bus & bridge init === 700:00:05:20.01190: PCI: pci_bios_init_bus_rec bus = 0x0 800:00:05:20.03352: === PCI device probing === 900:00:05:21.00046: Found 3 PCI devices (max PCI bus is 00) 1000:00:05:21.00981: === PCI new allocation pass #1 === 1100:00:05:21.02888: PCI: check devices 1200:00:05:21.09469: === PCI new allocation pass #2 === 1300:00:05:22.00196: PCI: IO: c000 - c017 1400:00:05:22.01239: PCI: 32: 0000000080000000 - 00000000fec00000 1500:00:05:22.03384: PCI: map device bdf=00:01.1 bar 0, addr 0000c000, size 00000008 [io] 1600:00:05:22.05249: PCI: map device bdf=00:01.1 bar 2, addr 0000c008, size 00000008 [io] 1700:00:05:22.07204: PCI: map device bdf=00:01.1 bar 1, addr 0000c010, size 00000004 [io] 1800:00:05:22.09117: PCI: map device bdf=00:01.1 bar 3, addr 0000c014, size 00000004 [io] 1900:00:05:23.00413: PCI: init bdf=00:00.0 id=8086:1237 2000:00:05:23.01691: PCI: init bdf=00:01.0 id=8086:7000 2100:00:05:23.02640: PIIX3/PIIX4 init: elcr=00 0c 2200:00:05:23.03771: PCI: init bdf=00:01.1 id=8086:7010 2300:00:05:23.04715: PCI: No VGA devices found 2400:00:05:23.09719: No apic - only the main cpu is present. 2500:00:05:24.02217: Copying PIR from 0x0008fd07 to 0x000f0fa0 2600:00:05:24.06600: Copying MPTABLE from 0x00006db0/769c0 to 0x000f0ec0 2700:00:05:24.08818: WARNING - Unable to allocate resource at smbios_legacy_setup:516! 2800:00:05:25.03929: Scan for VGA option rom
Just tried the BIOS ROM for the 86box's "[i440FX] ASUS P/I-P65UP5 (C-P6ND)" machine(just the nd6i0218.awd ROM). It seems to start up partially, displays the processor and then hangs itself(using a jmp to it's own address). This might be a good starting point?
How much of it's chipset is mandatory to boot? The northbridge, 'piix3'(straight adaption of i430fx piix atm) and ps/2 controller are already there. Are the remaining chips(Winbond W83877F Super I/O Chip, Intel 28F001BXT/28F002BXT Flash BIOS and I/O APIC) really necessary to POST and boot?
Edit: These are the POST codes logged:
100:00:07:64.05841: POST Code: C0 Turn off chipset cache 200:00:07:65.03013: Shutdown status: 00 300:00:07:65.03678: POST Code: C1 Memory presence test; OEM specific, test the size of on-board memory 400:00:07:76.06792: POST Code: 0C Initialize keyboard; Detect the type of keyboard controller 500:00:07:94.05641: POST Code: C3 600:00:16:83.07102: POST Code: C5 Early shadow; OEM specific, early shadow enable for fast boot 700:00:16:89.02246: POST Code: 03 Initialize chips; Disable NMI, PIE, AIE, UEI, SQWV. Disable video, parity checking, DMA. Reset math coprocessor. Clear all page registers and CMOS shutdown. Initialize DMA controller 0 and 1. Initialize interrupt controllers 0 and 1. 800:00:16:89.02684: POST Code: 04 Test memory refresh toggle 900:00:16:89.03352: POST Code: 05 Blank video, initialize keyboard; Keyboard controller initialization 1000:00:17:09.05130: POST Code: 06 1100:00:17:09.05550: POST Code: 07 Test CMOS interface and battery 1200:00:17:09.05720: Shutdown status: 01 1300:00:17:09.05862: Shutdown status: 02 1400:00:17:09.05994: Shutdown status: 04 1500:00:17:09.06122: Shutdown status: 08 1600:00:17:09.06248: Shutdown status: 10 1700:00:17:09.06398: Shutdown status: 20 1800:00:17:09.06522: Shutdown status: 40 1900:00:17:09.06646: Shutdown status: 80 2000:00:17:09.06782: Shutdown status: 00 2100:00:17:09.07216: POST Code: 08 Set up low memory; Early chipset initialization, memory presence test, OEM chipset routines, clear low 64K memory, test first 64K memory 2200:00:17:09.07576: POST Code: BE Chipset default initialization; Program chipset registers and power-on BIOS defaults. 2300:00:17:10.02140: POST Code: 09 Early cache initialization; Cyrix CPU specific, CPU and cache initialization 2400:00:17:10.03028: POST Code: 0A Set up interrupt vector table; Initialize first 120 interrupt vectors 2500:00:17:10.04562: POST Code: 0B Test CMOS RAM checksum 2600:00:28:95.04742: POST Code: 0C Initialize keyboard; Detect the type of keyboard controller 2700:00:28:95.05248: POST Code: 0D Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter 2800:00:28:95.05770: POST Code: BF Chipset initialization; Reserved 2900:00:28:95.07150: POST Code: 0D Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter 3000:00:36:20.05644: POST Code: 0E Test video memory; Write sign-on message to screen, setup shadow RAM 3100:00:38:21.03168: POST Code: 0F Test DMA controller 0; BIOS checksum test, keyboard detect and initialization 3200:00:38:21.03592: POST Code: 10 Test DMA controller 1 3300:00:38:21.04000: POST Code: 11 Test DMA page registers 3400:00:38:21.04348: POST Code: 12 Reserved 3500:00:38:21.04684: POST Code: 13 Reserved 3600:00:38:21.05080: POST Code: 14 Test timer counter 2