VOGONS


UniPCemu Windows 95/NT progress and issues

Topic actions

Reply 80 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Just tried the ITE drivers on NT 4.0 (first boot succeeds, then removing the old PCI IDE drivers for the new iteraid drivers to remain and rebooting again).

It fails booting with an 7B error there as well.
The ArcName path seems fine there as well. It reports "\ArcName\multi(0)disk(0)rdisk(0)partition(1)".

Before rebooting the system with the old drivers removed, it reported that the ITERAID drivers couldn't allocate the IRQ (0xE) because it was already used?

So there might be an issue with the driver?

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

Reply 81 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

I'm almost starting to wonder... Can the PCI IDE I'm emulating actually be booted from using said ATERAID.SYS driver?
The BSOD of NT 4.0 workstation shows it being loaded at 80019000.
But it will still throw an 7B error with it loaded.

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

Reply 82 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Just implemented PCI option ROMs using the Atmel flash ROMs. Now the PCI IDE cards can have their own PCI expansion ROMs mapped in memory.

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

Reply 83 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

OK. With the latest changes, the reads from the PCI IDE ROMs will properly succeed.
I now see the PCI IDE BIOS (the 8211F (identified as IT8212) one) running after POST.

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

Reply 84 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Flashing seems to work now.
The "Blank check" after "Erase" seems to fail though, although having no effect on the flashing itself (or the steps after the Erase step, other than the Blank check (which is ignored during flashing and programming the ROM after that)).

Probably because the flash ROM isn't returning FFh values anymore after the "Erase" stage?
But how would that Erase command work exactly? I see it executing a 10h command (which I'd assume is the Erase command), but nothing is written during that? Or is a read operation providing the address to erase?

I see it executing command 80h, followed by 10h during the Erase step?
Although I don't have any documentation on those commands?
Edit: Hmmm... Said BIOS doesn't detect any of the IDE devices? Perhaps it's something related to the Windows 2000 issue with the card?

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

Reply 85 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

OK. So the PCI BIOS that's flashed seems to expect the PCI device to be in PCI mode?

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

Reply 86 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Anyone knows what the Primary/Secondary decode bits in register 41h do?

15 R/W 0h IDE Decode Enable for Primary Channel (PDE) 1: Enabled. 0: Disabled. 14 RO 0b Reserved 13 R/W 0h IDE Decode Enable for […]
Show full quote

15 R/W 0h IDE Decode Enable for Primary Channel (PDE)
1: Enabled.
0: Disabled.
14 RO 0b Reserved
13 R/W 0h IDE Decode Enable for Secondary Channel (SDE)
1: Enabled.
0: Disabled

Edit: Hmmm... Perhaps it forces a channel into PCI mode?
Edit: If forcing the channel into PCI mode when said bit is set, the BIOS detection of that controller succeeds (although CD-ROM drives don't seem to be detected somehow?).
It's left at 0xA0 after the BIOS finished.
Register 50h is left at 0x18?

Edit: OK. This is what I'm seeing from the hardware and display perspective:

Normal BIOS POST first, detects the drives (and initialized PCI BARs) and checks the drives (PCI is still disabled on the card. Reg 50h=00h).
This finishes with commands E3h on the hard drives.
Then it sets the option ROM to E7FF0000h.

PCI 5C>=00h
PCI 5D>=00h
PCI 5E>=01h
PCI 5F>=00h

Option ROM starts executing...

PCI 50h>=written 80h
PCI 51h>=written 00h
PCI 52h>=written 00h
PCI 53h>=written 00h
PCI 50h>=written 00h
PCI 51h>=written 00h
PCI 52h>=written 00h
PCI 53h>=written 00h
PCI 04h>=written 47h
PCI 05h>=written 00h
PCI 06h>=written 00h
PCI 07h>=written 00h
PCI 40h>=written 00h
PCI 41h>=written A0h
PCI 42h>=written 00h
PCI 43h>=written 01h
PCI 4Ch>=written 04h
PCI 4Dh>=written 02h
PCI 4Eh>=written 04h
PCI 4Fh>=written 02h
PCI 40h>=written 00h
PCI 41h>=written A0h
PCI 42h>=written 36h
PCI 43h>=written 01h
PCI 0Ch>=written 00h
PCI 0Dh>=written 00h
PCI 0Eh>=written 00h
PCI 0Fh>=written 00h
PCI 50h>=written 04h
PCI 51h>=written 20h
PCI 52h>=written 00h
PCI 53h>=written 00h

"Please wait for IDE scan"

command EC to channel 0 drive 1
command EC to channel 0 drive 0
command A1 to channel 1 drive 1
(takes a long time here)
command A1 to channel 1 drive 0
(takes a long time here)

PCI 40h>=written F0h
PCI 41h>=written A0h
PCI 42h>=written 06h
PCI 43h>=written 01h

command EF to channel 0 drive 0
command EF to channel 0 drive 0
Show last 20 lines

PCI 50h>=written 08h
PCI 51h>=written 00h
PCI 52h>=written 00h
PCI 53h>=written 00h

command EF to channel 0 drive 1
command EF to channel 0 drive 1

PCI 50h>=written 18h
PCI 51h>=written 00h
PCI 52h>=written 00h
PCI 53h>=written 00h
PCI 54h>=written AAh
PCI 55h>=written 00h
PCI 56h>=written 31h
PCI 57h>=written 00h

Detection finished. Results are displayed.
Expansion ROM is removed from memory.

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

Reply 87 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

So, making UniPCemu do the following seems to restore booting:
- Writing register 41h bit values 80h/20h enables the PCI mode for the primary(80h) and/or secondary channel(20h).
- Writing register 54h or 58h disables both channels PCI mode. This is re-enabled by the generic updating in the 50h register, which is done when these registers are written.
- Writing register 50h with bit 7 set clears PCI mode for both devices.
- Writing register 50h with bit 1 set (or 54h/58h while this bit is set) puts both controllers into PCI mode.

I see the same things happening mentioned in my previous post, but now the IDE controller returns to legacy mode after that (because of the register 54h write at the end).
So that way it can properly boot the devices on the IT8211F bus.

Didn't check with the ITE drivers yet though.

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

Reply 88 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Booting Windows 2000 Pro setup with it from the bootable CD-ROM shows the following text:

Windows 2000 Setup
===============


Disk I/O error: Status = 00000101








(lots of blue here until the bottom screen row)


Setup is starting Windows 2000

The BIOS ROM seems to be unmapped still, the disk isn't in PCI mode.
The PCI command register is 0x47.
Register 41h is still 0xA0.
Register 50h is 0x08.
It's basically unmodified from boot. So the booting process left it in IDE mode, while the driver probably expects it in PCI mode?

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

Reply 89 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... Just wondering...
Could it be that the bits in register 41h actually add a mirror (aliasing) of the PCI IDE controller primary/secondary address to the legacy addresses? So they add the legacy addresses on top of the PCI addresses being responded to?

Edit: Just modified the channels to be in legacy mode(port addresses and IRQ) when byte 41h has it's channel bit set and byte 50h has it's bit 0 (cleared to set IDE mode according to documentation) cleared. All other cases make it into PCI mode (port from the BARs and using PCI INTA# instead of legacy IRQs).

Edit: Hmmm... The IT8212F 0.3 manual tells a bit more information:
http://www.digchip.com/data/226/it8212F_v0-3.pdf

This bit is used to reset the related PCI circuit when IT8212F enters the PCI transparent mode.

And bit 0 of the register

This bit is used to select the PCI transparent mode or CPU firmware mode. 1: CPU firrmware mode, 0: PCI transparent mode

So they don't seem to select between PCI native and legacy IDE mode? Unless "PCI transparent mode" = "PCI native mode" and "CPU firmware mode" = "legacy IDE" mode (non-PCI mode with default IRQs and I/O ports defined by the ATA-1 standard)?

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

Reply 90 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Or is the register 41h bits 5&7 actually the "native mode" toggle for the primary and secondary channels?

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

Reply 91 of 91, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... OK. With the latest changes I get the error 101 as well, but before the boot loader of the CD-ROM starts (Setup is inspecting your hardware configuration thing being mentioned before the blue screen starts for Windows 2000 setup)?
That's after changing the ATAPI Identify Packet Device command to not become busy after completing a Identify Packet Device command's reading of all data from the sector buffer.
Edit: It errors out with that 101 error both when starting setup's hardware detection (when starting to boot the CD-ROM) and later fatally crashes on the Windows 2000 setup starting itself after loading all drivers (with the exact same error code)?
It doesn't give a 7B error in this case though (it doesn't reach that stage anymore).

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