VOGONS


Reply 460 of 501, by superfury

User metadata
Rank l33t
Rank
l33t
mr.cat wrote on 2022-03-24, 17:34:
Yeah these latest changes have broken booting for me (cdrom0 or hdd0, with Bochs BIOS). I went back to commit a3371a63 and that […]
Show full quote

Yeah these latest changes have broken booting for me (cdrom0 or hdd0, with Bochs BIOS).
I went back to commit a3371a63 and that one seems to work, but some minor patching is needed for Linux:

libserial.h: "termios backup" should be "struct termios backup" maybe?
libserial.c: some #ifdef trouble, as there are messages about undefined refs to SERIAL_xxx functions.
It seems LINUX is not defined, so need to use IS_LINUX instead?

The compiler also doesn't like the last parameter or tcsetattr() on line 312:
&port->backup should probably be &((*port)->backup) or something like that.

The Bochs BIOS(with the 8042 patch) seems to work somewhat. It detects the drives, but says it can't boot the CD-ROM in my case?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 461 of 501, by mr.cat

User metadata
Rank Member
Rank
Member

Man do you work fast 😁
For me it's the opposite now (with commit 35833c02, i430fx/i440fx, patched Bochs BIOS, clockingmode=1 and cpuspeed=1700):
CDROM boot is fine, but for hdd the boot fails with "FATAL: No bootable device.".

I've encountered this issue in my previous testing with clockingmode=1 and high cpuspeed values.
Setting clockingmode=0 and playing with different cpuspeed values didn't seem to have an effect this time.
However I did find that setting clockingmode to 1 and then lowering cpuspeed to a low enough value it does manage to boot from hdd0 too.

Reply 462 of 501, by superfury

User metadata
Rank l33t
Rank
l33t
mr.cat wrote on 2022-03-25, 15:24:
Man do you work fast :D For me it's the opposite now (with commit 35833c02, i430fx/i440fx, patched Bochs BIOS, clockingmode=1 an […]
Show full quote

Man do you work fast 😁
For me it's the opposite now (with commit 35833c02, i430fx/i440fx, patched Bochs BIOS, clockingmode=1 and cpuspeed=1700):
CDROM boot is fine, but for hdd the boot fails with "FATAL: No bootable device.".

I've encountered this issue in my previous testing with clockingmode=1 and high cpuspeed values.
Setting clockingmode=0 and playing with different cpuspeed values didn't seem to have an effect this time.
However I did find that setting clockingmode to 1 and then lowering cpuspeed to a low enough value it does manage to boot from hdd0 too.

That might be because of the Bochs BIOS not taking any timing like all supposed busy bits into account? So it writes a command while it's still not ready, which gets ignored by the drive? Same issue for drive select and IRQs I've noticed in the past(with the 8042). Bochs' incomplete hardware timings are to blame for that afaik.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 463 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... Looking at the BIOS source code, I see it's using some timer that's ticking at 65536000Hz?
Since IDE_TIMEOUT is 32000 which it documents as 32 seconds, so IDE_TIMEOUT=1000 should be 1 second.
Then, it times out if time, which takes 1 instruction time (INC together with the rest of the loop) shifted right by 11 bits (divided by 2048) exceeds the count. So if time(1 instruction time) divided by 2048 happens 1000 times, the timer should be running at an expected 1000*2048=2048000 loops per expected second, so 2048KIPS. Of course, that's lowered by the other instructions together with the INC (all those timings together until it reaches the INC again counts as 1/2048000th second).
So 2048000 divided by the amount of instructions per loop is the amount of IPS it expects for that.
Edit: It should be using INT 13h function 02h(Read sector(s)) for booting the hard drive...

Edit: Hmmm... It errors immediately after executing command A1(IDENTIFY PACKET DEVICE) on the master ATAPI drive? "FATAL: ata-detect: Failed to detect ATAPI device"

Edit: Managed to fix that issue! It was receiving not busy and not ready when completing the IDENTIFY PACKET DEVICE command, which takes a little bit of extra busy time after the command completes!
So the issue there was that it never reported being busy for that, while actually not yet receiving commands properly because a timer was running for the IDENTIFY PACKET DEVICE command completing.

Having fixed that, the Bochs BIOS seems to finish properly, having detected all devices. Although it still says "FATAL: No bootable device."
Perhaps it's trying to boot from CD-ROM only?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 464 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

This is what happens on the i430fx:
https://www.dropbox.com/s/14nnfxvsymhexv9/deb … Instead.7z?dl=0

Can anyone see why it's rejecting the PCI IDE and selecting the onboard only (and perhaps why it's giving the error of conflicting devices)?
Edit: Hmmm... At eb8e:00002f8f 80 FD 03 cmp ch,03
CH is the class code, CL is the subclass, both read from the PCI space of the PCI IDE controller.
It then tries to clear BAR0 by writing it with zeroes.
Then it arrives at:
eb8e:00002ffb 83 C7 04 add di,0004
So, f000:0000e008 AH=1D clears the BAR selected by DL.
That's at eb8e:00002ff6 9A 08 E0 00 F0 call f000:0000e008
Said calls all return at eb8e:00002ff6.
When it's processed all BARs, it arrives at "eb8e:00003003 BF 30 00 mov di,0030".
It clears bar at address 30(the ROM bar), then proceeds to call AH=1B on said function handler. DI=3C in this case.
That's at eb8e:00003012 9A 08 E0 00 F0 call f000:0000e008
OK. So function 1B writes CL to the byte register specified by DI.
Then, at 301A, it specifies function 1C instead. DI is set to 4.
It calls the function at:
eb8e:0000301c 9A 08 E0 00 F0 call f000:0000e008
OK. So that function writes CX to the specified 16-bit register specified by DI. BL seems to be device and function number in the second byte of the PCI CF8 register.
It then reaches:
eb8e:00003021 BF B9 32 mov di,32b9
I see it scanning some values 05,00,40h(it keeps matching 10h on this one) in memory, with a limit of 12 bytes being scanned?

Edit: So, so far, the following functionality of function f000:0000e008 has been found:
AH=0D, unknown. Checks some data and eventually returns giving AL=01h.
AH=18 read 8-bit PCI to CL BL=devfn, BH=busnr, DI=addr
AH=1A read 32-bit PCI to ECX BL=devfn, BH=busnr, DI=addr
AH=1B writes CL to the byte register specified by DI. BH=busnr, BL=devfn, DI=addr
AH=1C writes CX to the specified 16-bit register specified by DI. BL seems to be device and function number in the second byte of the PCI CF8 register.
AH=1D writes ECX to the specified 32-bit register specified by DI. BL=devfn, BH=busnr, DI=addr
AH=24 BL=-(BL-1F)
AH=26 Some internal logic? Selects devicefn 38(device 7 function 0), position 60 and writes 0Eh to it? Looks like some kind of IRQ assigning function? Sets the IRQ number to CL(0Eh), then sets said bit in the ELCR. and returns to the caller.
AH=28 AL=01 read F000:6B2E and compare with AL. If matches, give F000:6B20 and return on BX, with 8-bit flipped?

Function 26 is kind of complicated. It reads some tables and based on BL and DL, writes AH to PCI register 60 based on that and sets said bit in the ELCR. That might be the PCI INTA# setting that it's expecting somehow?

What I see it do with the AH=26 handler:
AH=26
AH=input AL(0F)
CX=BIOS 6B1D
BH=BL&F8, BL=BH.
6B20=BX? Then go to 6C8A
SI+=2
DH=DL=DL-1
DL<<=2
DL-=DH
DX&=F
SI+=DX
AL=F000:SI
DX=SI+1
AL(60h)? STC and jump to 6C6C if not. Not taken.
AL top 4 bits set? Not set, reaching 6c68. calls 6BDE.
DI=AL=60
CL=AH=0F
bus 0 offset 60 devfn 38 selected. 0F(input AL) written to it.
CL=input AH. Set said bit in the ELCR.

Edit: Hmmm.... I see something interesting ther: devfn 38 is device 7 function 0. It doesn't match any existing hardware in the emulation. But guess what's related to the ELCR and matches said register 60h? The PIIX chip that's on said motherboard!
So instead of it's location on the i430fx is hardcoded at device 7 for the PIIX?
Edit: Hmmm... Said devfn 38h is from "cs:[d64f]"?
Edit: After scanning the PCI IDE's BARs, it arrives at eb8e:00003c1c...

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 465 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Looking at what the BIOS does after scanning the PCI BARs, it looks like it's performing some kind of filter based on the PCI device/vendor ID's? Probably the i430fx rejects the PCI IDE because it isn't one of the onboard ones? I see both the PIIX and PCI-to-ISA adapter IDs there, as well as a video card ID? After that, it's giving up on the parsing of the ID before scannning the next device, which is the PIIX IDE adapter(starting from device 31 down to reaching it at device 1)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 466 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

OK. So looking at what it's doing with the PCI IDE device:
After completed, reached eb8e:00003c16
Reaches eb8e:00003b42
Reaches eb8e:00003c39 when not parsed all BARs.
When finished, reached eb8e:00003c69
When no ROM BIOS in there, reaches eb8e:00003c7f
Then it just proceeds on to the next device, fully ignoring it?
So perhaps the PCI IDE device needs a ROM to function?

Edit: Hmmm... When it reaches "eb8e:00003c36 BF 10 00 mov di,0010", DX is set to 0201 when reaching eb8e:00003c16, especially DL seems to have some effect on it, being non-zero(01h with the onboard IDE, 00h on the PCI IDE device that's on the next slot)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 467 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Just forced the i430fx to use the PCI IDE card when performing PCIRST#. Now it should detect the IDE devices properly (although breaking PCIRST# specs on the PCI IDE to obtain compatibility).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 468 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

OK. With the new IRQ14/15 handling of the onboard and PCI IDE controllers, the POST of the i430fx now continues.
But it somehow still hangs on what seems to be a seek command or read sector(s) command?
IRQs seem to be working properly, as evidenced by it running properly on the i440fx chipset. It's properly booting there.

The i430fx still doesn't display the primary master's device name properly(displaying it as an empty string), even though it successfully seems to have completed the ATA Identify Device command(command ECh)? It looks like it's somehow hanging on that device, not proceeding on to the next device (the primary slave HDD(if present) and secondary master/slave CD-ROM drives(ATAPI))?

Improved the ATA errors to be having a bit of a delay when executing the invalid command byte though.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 469 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Just fixed some initialization issues for the reverse drive lookup (mounted drive to ATA channel and slave lookups).
It wasn't properly parsing the upper channels (channel 2&3 for the onboard channels), leaving the master/slave information for the drives themselves intact (making things succeed normally), but since the reverse tables were incorrectly setup(not setup at all for the onboard channels, leaving them to an unidentified value) stuff like the identify command data were marked as using a invalid and unmounted drive, thus not setting those up at all (causing the weird information to display on the screen).
It also affected the checks for LBA vs CHS conversion, causing the issues I saw happening when reading the boot sector from the drive by the BIOS (it displaying itself as not updating the CHS address at all when finishing reading a sector).

That's a big bug with the new onboard IDE channels fixed now 😁

Edit: That also fixed the booting issues on the i430fx that were happening! 😁
Edit: Although the i440fx is displaying some kind of issues right now?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 470 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Just implemented actual seek timings for the recalibrate, seek and sector read/write commands.
Now, the commands themselves take up a bit more or less time depending on the seek action that's required to get to the specified sector (for read/write commands) or track(for seek/recalibrate commands) instead of always taking the same time.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 471 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Managed to fix the i440fx booting again. There was a problem with the PCI configuration space's new method for member alignment in the space (for portability).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 472 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... Bochs 80386/80486 paging fault and the 80386/80486 manuals are at odds with each other?
It looks like the 80386 or 80486 without WP simply faults when not writable?

Then, the writable setting on both chips seems to be the logical AND of the two page tables.
But, without WP the kernel mode forces that result to be set to 1(writable).
And with WP enabled the kernel mode enforces the combined level like for user-mode pages instead?

Then, the determination of the kernel/user mode to use for those checks and the kernel mode check seems to be weirdly documented in Bochs?
The 80386 programmer's reference manual seems to agree with the Bochs 80486 on it's U/S behaviour?
But the i486 programmer's reference manual documents the Bochs 80386 way?

Have the folks of Bochs swapped the two behaviours for the 80386/80486 in that table (wrt the Supervisor/User bits and their R/W bits)? So the 80386 column is the 80486 column and vise-versa?
The combination of User and Supervisor obviously isn't an OR-operation(giving user pages priority over kernel pages), so the documentation of the 80386(and 80486 column of Bochs) is obviously the correct one?

Edit: Bochs' using the AND-method instead of what it documents(the OR-method) seems to prove which one is correct?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 473 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

OK. With those latest WP changes, the GUI part of the Windows NT 4.0 workstation setup finally starts without the OS crashing! 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 474 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

One interesting things this case shows: the 80486/Pentium programmer's reference manuals say that it applies to user-mode pages only. But the Pentium Pro and Pentium II System Architecture (2nd Edition) by MindShare Inc., Tom Shanley actually is correct on tihs one: it applies to all pages, not just user-mode pages (kernel mode pages are affected as well, if Bochs is correct on that one).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 476 of 501, by superfury

User metadata
Rank l33t
Rank
l33t
Ringding wrote on 2022-04-08, 07:57:

This is very surprising. Also I would not expect the behavior to have changed from 386 to at least Pentium 4.

Well, the 80386 official documentation (no WP bit or disabled_ and Pentium Pro/2 documentation (including WP behaviour) is correct.
It's so far just the 486 programmer's reference manual that's making huge errors(user+kernel=user for example, which clearly is incorrect). Also WP applies to Supervisor pages as well, not just read-only user-mode pages, which is evidenced by NT 4, which is for the 80486, crashing if that isn't the case.

NT4 setup proceeding smoothly now(last checked at TCP/IP setting up so far during GUI-setup).
Edit: Detected and installing the modem (autodetected)...
Edit: Setup finished! First boot...

1548-Windows_NT_4.0_first boot.png
Filename
1548-Windows_NT_4.0_first boot.png
File size
12 KiB
Views
122 views
File comment
It's... alive!
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 477 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

The latest bugfixes are now out on itch.io!

So now Windows NT 4.0 at least boots and runs.
Still have to check if 2000/XP now runs though.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 478 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

OK. So checking out Windows NT 4.0 with the packet server, I noticed it had some issues with IPX node number negotiation.
Managed to fix said issue now in the current commits.

Now Windows NT 4.0 can properly dial up the dial-up server with full automatic configuration (as long as it's setup correctly on Windows NT 4.0 of course).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 479 of 501, by superfury

User metadata
Rank l33t
Rank
l33t

Just improved the IP and IPX on SLIP and PPP to support full autoconfig.
So now it's both faster detecting those on the server, as well as preventing collisions between existing clients.
I've also added IP adress ranges support to the account support. So it will now hand out IP addresses from a pool instead of always the same IP address of an account. And of course when all of the addresses of a pool are used, any requests for an IP address on such an account are denied until an client logs out to free up such an address.
Still no DHCP though, but autoconfig through PPP and SLIP is now actually working. The same for the collision detection of both IP and IPX protocol addresses.
They're handed out from lowest to highest adress, collision checks being performed during the IPCP and IPXCP stages, while performed during login(forced disconnect as usual if it happens) when using SLIP.
Although for IP, it won't detect collisions outside the app's own pool, like a DHCP server on the network, but if you manage seperate ranges for those, it shouldn't cause issues.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io