OK. Now, having implemented the 8042 AMI read keyboard mode(0xCA), command A1 returning 0x4E as a result, command 0xCB to make the next write set the keyboard mode byte(unused, except for the result of command 0xCA), it once again performs command 0xFF.
Now, having the 0xFF command give a result of 0x52(as the BIOS seems to expect for some reason), I now see it starting to copy the BIOS ROMs to 0x2000(copy of segment E000) and 0x4000(copy of segment F000), eventually jumping to code within segment 2000h and it jumping tox 4000h:0 to execute some weird DIV BX instruction infinitely(it's silled with 0xF7FF values or something like that)?
Edit: Interesting, searching for the original BIOS ROM filename(S728P.ROM) on google reveals this: https://ami.com/ami_downloads/Apollo_S728_Users_Guide.pdf
So it's apparently a AMI Apollo Pentium PCI ISA motherboard BIOS I'm trying to run? At least I now know what I'm dealing with 😁
Unfortunately it mentions nothing specific about the boot process(it does about the flashing of the BIOS in a normal user manual guide way, though). That's probably the source of the BIOS ROM I'm trying to use atm for testing(Said BIOS update floppy itself).
So said memory is filled with F7,F3 bytes following each other for at least 256 bytes or more.
Edit: I've made a log of the BIOS running after sending the 0xFF byte to port 64h:
It runs until reaching segment 4000h.
Edit: Hmmm... The interesting stuff starts at f000:0000efa5, where it will start to copy 64K of data from address e0000h(the start of the BIOS ROM) to adress 10000h, making a simple copy of it in lower RAM at f000:0000efa7.
That seems to be mostly zeroes?
So, looking at it running, f000:0000efa0 contains a simple routine for block copying 64K of data from ds:si to es:di.
So, having copied the full 128K of BIOS ROM to lower memory, it reaches f000:000071e6.
It then jumps to the BIOS copied to lower RAM, at 2000:000071eb, which is immediately past the RETF, but the BIOS running from segment 2000h instead and the BIOS ROMs having been relocated/copied to segment 1000h-2FFFh from segment E000h.
At 2000:000071ec, an PIT0 IRQ seems to have intervened.
Edit: Nope. That's just the previous RETF to segment 2000h.
It then returns for some more.
At 2000:00000b8e, it might be the start of the BIOS decompressing routine?
It starts by CLI(to prevent BIOS interrupts), then clearing 3E8 words at address 40000h, so a total of 2000 bytes.
AX is set to F3F7 just before (at 2000:000013f9), which is stored in said memory. So that's the cause of the invalid instructions that are executing. Now, why is such data left in that place or jumped to incorrectly?
It fills the next byte of RAM with a CBh value, so at 47D00, at location 2000:00001403.
It then restores AX to F3F7, decreases it for F3F6(opcode F6F3?) for 3E8 words(7D0 bytes again) at address 40800h with said value.
Perhaps it's some table of some kind?
So then it finishes it up with another CBh value at 40FD0.
It then reaches 2000:00001414.
It sets 4f804(data segment offset f804h) to the value of port 61h's read value(=20h).
It then clears bit 0&1 of port 61h(the PC speaker output line mask and gate).
It sets PIT timer 2(the PC speaker) to 18.2Hz and returns to the caller.
It then turns on the timer by setting the gate at port 61h to 1?
It then calls the just initialized 4000 segment directly?
Is it just some obscure way to set some timer in a weird way?
So it's deliberately executing DIV BX 2024 times and then performing an RETF to the calling segment? BX=FFFFh at that point, so it won't fault.
Said call happens at 2000:000014a2.
Edit: It indeed returns from said function, reaching 2000:000014a7.
It then stops the PC speaker gate(timer 2 gate) by clearing it again. And jumps to 2000:000014b0.
It stores the PC speaker counter after being negated using NEG(which was starting at 0h), becoming 18Fh, at address 4f800h.
It then stores port 61h's value(30h) at address 4F804h. It then does the same counter with address 4000:0800h(the second block it created, with the same size). This time returning to 2000:000014CD.
That block once again returns 18Fh as a result after negating the PIT2 timer's clock.
It then substracts that calculated value(18Fh) from the value stored at 4f800(thus clearing it).
It did something with segment F000h, after which it called the 4000h segment once again, timing it.
It's once again resulting in a value of 18Fh. And then calls the routine at 4000:800h again. It ends up at 2000:000014CD again?
So it seems to be pretty much infinitely calling the block of code again?
It seems to be comparing the timings between the two blocks of execution somehow? This seems to go on pretty much infinitely?
So it's comparing DIV BL timing (the higher block at 40800h) against DIV BX timing (the lower block at 40000h). And they always execute equally fast, causing the infinite loop?
It seems to store it in some table? It's looping around calculating the DIV BL vs DIV BX timing differences?
Edit: It seems to do some math on the calculated speed. At 2000:0000146f, it doesn't jump 10 bytes ahead(the comparison against some constant wasn't equal. SI=9D98).
It then clears the memory it just used with zeroes.
It sends 24h to port 80h. So it's reached the next step?
Edit: It fills the IVT with F000:5E40 entries and reaches 2000:0000719E.
It seems to be initializing the IVT, but doing so from segment 2000h still?
It seems to finish, then send 25h to port 80h(that's probably some kind of diagnostics port, like Compaq also uses)?
Edit: It sets the initial video mode to 3 in the BDA (at 2000:BC6). It then updates the POST code to 27h. Then some more calling, resulting in it becoming 28h.
Interesting: the first interrupt is called: interrupt 10h function 07h, from 2000:00000be1. That resolves to F000:F065, which is the BIOS video interrupt handler? Why isn't the VGA BIOS used?
Edit: The i430fx handles the video interrupt and returns.
It then requests video mode 01h to be set by the BIOS.
Edit: OK. It looks like it's somehow programming the ET4000 like a CGA for some reason? Why doesn't it use the ET4000 BIOS ROM?
Edit: OK. It copies the BIOS ROM from lower memory back to the mapped write(read=PCI) RAM at F000:0000.
It then switches it back to read=RAM, write=PCI(register 59h=1Fh).
It eventually returs to the BIOS at 2000:71F5 to F000:71F6. So the BIOS should be ready for use, with it being remapped to lower RAM.
It sets the POST to code 2Ah and reaches F000:00000C0A.