VOGONS


Reply 140 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++
keenmaster486 wrote:

Try running some known-to-be-unstable software on Windows 3.1, like Titanic: Adventure out of time (requires Win32s).

Just tried installing and running the game on WFW 3.11. Installing went without noticable issues. Then running once again(what a surprise) crashes Windows straight back to the MS-DOS prompt. That happens almost immediately after pressing the play button on the setup.exe of the CD-ROM.

So the original underlying issue with the CPU that was causing that still isn't solved. Though I have no clue what's causing the crash?

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

Reply 141 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.... Just tried running test386.asm again on my lastest cpu emulation(80386). It seems to crash with POST 9? So that would mean some weird stack bug?
Edit: Apparently, 32-bit PUSH Sreg is expected to push 16-bits, leaving the remainder 16-bits undefined... But UniPCemu pushes 32-bit, writing those as zeroes instead.

So I changed the push 16-bit back to writing 16-bits instead of 32-bits to memory(only during the BIU processing stage, not during memory protection).

I tried patching the Overflow flag not to be affected by the Bit Test instruction(BT/BTR/BTS/BTC), but test386.asm hangs it's F0 CPU-specific test in that case. So apparently that wasn't the main problem.

I do notice that Windows 95C now somehow crashes with a BOUND exception(which hangs the CPU)?

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

Reply 142 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried installing and running the Pink Panther in Hocus Pocus Pink(which ran fine previously) in UniPCemu's WFW 3.11. It now immediately crashes WFW 3.11 to a black screen of death with a cursor blinking in the top-left(I don't think it's row #0, it's row #1 it seems)?

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

Reply 143 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried reinstalling Windows NT 3.1. It's back to the strange GUI on the ET4000(which is the graphics card that's emulated) with the message that the OS isn't entirely installed once again. Chkdsk says the volume is clean.

So why isn't everything that's supposed to be copied over, well, copied over?

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

Reply 144 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... I was just checking some paging checks, checking if there was somehow something going wrong with it... Eventually stumbled on the mov instructions themselves.
Then I noticed that when executing a MOV instruction from the accumulator(AL/AX/EAX) to a direct memory address(thus, opcodes A2 and A3 to be exact), it was setting a special flag for the MOV instruction to move between memory and accumulator, ignoring modr/m input.
BUT, when a fault occurs during said handling(e.g. a Page fault or protection fault for said address), it would abort(which should be fine) the instruction execution before actually making the access. But, when aborting it wouldn't clear the flag properly.
So when the flag isn't properly cleared and eventually a modr/m-based access is made through a MOV instruction(so, all MOV modr/m,modr/m instructions (opcodes 88-8B) referring to a memory address), it would use the last used MOV [imm16/32],AL/AX/EAX offset for that instead... Whoops! That's a big hidden bug!
So the following kind of instruction stream(as an example):
MOV ECX,32107654h
MOV [12345678],EAX ; Causes a page fault or other protection fault. Later resumed.
... no MOV from AL/AX/EAX to memory using opcodes A2/A3 successfully executed. Any kind of other instruction in the stream, or none(below following immediately after it, neither such a MOV successfully executed during the handler) ...
MOV [ECX],ABCD5555h

The following would actually happen:
MOV ECX,32107654h ; ECX=32107654
MOV [12345678],EAX ; Whatever is in EAX is written to 12345678 after the fault handler for this instruction restores the address. Instruction is then executed normally(clearing the flag). If skipped because of the exception, the flag remains set(causing the below instruction to misbehave).
MOV [ECX],ABCD5555h ; Uses address 12345678h instead.

So that's completely incorrect execution in that case. Although, if the fault handler would use opcodes A2/A3(without faulting of course) in it's processing without faulting, the bug is hidden from the instruction stream and won't show up.

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

Reply 145 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried running Privateer again. It still crashes like always(didn't change a bit there).

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

Reply 146 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

ENGINE1.EXE with CWSDPMI and HIMEM(loaded during boot) seems to give an interesting result. It gives a:

Page Fault CR2=00400002 in RMCB at EIP=6; flags=3016
eax=00000001 ebx=00000001 ecx=00465c10 edx=00029a90 esi=000200af edi=000022f4
ebp=00000007 esp=00465b7e cs=2b ds=af es=af fs=bf gs=bf ss=af error=0004

That happens on UniPCemu's Pentium emulation.

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

Reply 147 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Interesting that all the issues that I still notice with Windows 95 RTM have to do with interrupts(the interrupt flag to be exact)? When it's detecting the Sound Blaster card using the hardware autodetection(The Add new hardware wizard and the detection of the hardware during the setup wizard), it seems to enable pretty much all IRQs but the sound blaster IRQs(the hardware does raise the IRQ when requested using the Sound Blaster 1.0 request 8-bit IRQ command, which raises the IR bit in the IRR register to be set). But since the interrupt is never acnowledged (because the interrupt flag is never set during that phase) by the setup wizard or the hardware detection wizard it never knows what IRQ it is(because no interrupt is fired because of a cleared interrupt flag), it seems like? And of course the Interrupt Mask Register of the PIC also has the bit for IRQ5(the Sound Blaster IRQ) set, so it will never be acnowledged?

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

Reply 148 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried Debian 1.3.1(i386) again. It's now booting from the CD-ROM ISO image! 😁

But the hard disks were seemingly unaccessable during the partition detection part, it complains about the status being 0x50(Drive Ready, Seek complete)? Although that's normal behaviour for ATA harddisks?

Edit: OK... Further in the setup, it does seem to see the MS-DOS hard disk partition? Strange, but working?
Edit: Managed to at least create a partition on it with Linux 1.3.1(some 2.x.x bootdisk it identified itself as)?
Edit: It does give messages like "tray open or drive not ready" many times, followed by "tray open", "end_request: I/O error" something about sector 3, then proceeding to load normally?

Edit: Still working. Currently installing modules...
Edit: OK. Everything goes fine until installing the base system. Somehow, it's expecting the IRQ to be raised(it's raised and lowered alright, clearing and setting the IRR register in the PIC. The secondary PIC's IMR register is cleared, so it should get through???
Edit: Yup. The interrupt(2F for IRQ15) is triggering an interrupt to be raised and handled(also acnowledged in the PIC's ISR/ISR2(for parallel interrupts, which is only one in this case).
Edit: Another bug bites the dust! When executing an ATAPI PACKET command, it was writing the PACKET size(12 to be exact) to the cylinder high and low registers, which would later be read when the packet is fully written to hardware, causing it to use an incorrectly sized buffer size for transferring to the driver that's driving the CD-ROM drive! Oops!
Edit: Hmmm.... It doesn't like that the second CD-ROM drive has no disk in it? It keeps saying:

hdd : tray open or drive not ready
hdd : tray open or drive not ready
hdd : tray open or drive not ready
hdd : tray open or drive not ready
hdd : tray open
end_request: I/O error, dev 16:40, sector 3
.hdd: unexpected_intr: status=0x41
hdd: unexpected_intr: error=0x60

After that, it continues loading the next part of the Linux setup. This happens after each and every screen(only if there's no disc in the secondary slave)?

Edit: Managed to install Linux on the hard disk image without problems it seems(at least until the reboot). Didn't make a boot floppy(since I'm not sure it would work because of the FDC being set to 720k in the BIOS settings instead of the 1.44M the drive actually is, due to it having 18 sectors/track instead of 9 as the 720k BIOS setting implies).

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

Reply 149 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Debian 1.3.1 has successfully booted and reached the package selection.

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

Reply 150 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Rayman under MS-DOS 6.22 with Windows 95 RTM boot disk OAKCDROM.SYS+MSCDEX still complains about MSCDEX being corrupted? It runs fine under Windows 95?

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

Reply 151 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried the Windows 98 first edition first boot in UniPCemu. It flat out hangs loading vmm32.vxd(the first mention of the driver load)? Verifying it with Dosbox SVN Daum shows that it can boot without issues? So there's still some obscure booting issue related to the CPU in UniPCemu?

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

Reply 152 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. At least after the latest fix to make conforming code segments and non-conforming code segments DPL vs RPL vs CPL behave like data segment descriptors(with regards to those three, thus requiring MAX(RPL,CPL)<=DPL to be loaded, otherwise #GP(selector)), Titanic at least seems to install and run fine on Windows 95. Is that a good sign?

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

Reply 153 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a bug in the serial modem emulation. It wasn't properly processing "AT" and zero-length command strings(incorrectly parsing them, giving invalid results). Having fixed that, WinCheckIt Pro 4 now detects the modem and at least executes some ATI0(till ATI4) commands 😁

Edit: Having changed the DSR/CTS to behave accordingly, that should work now too.
Also, having changed the PnP detection to use the live dtr/rts lines instead of the delayed ones(setting in modem registers 25 and 26), the Windows 95 serial PnP seems to work now. It even detects the devices, but doesn't properly know what it is. 😁 That's some progress there!
Edit: Just noticed that the serial PnP checksum had an error in it: the PnP starting byte was included in the checksum, but it's actually supposed to take from after the start until the byte before the end character... Whoops!

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

Reply 154 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've been thinking... Is the serial modem PnP ID correct?

Currently, for the serial modem ID I use:
PNPC102 for the EISA/Product ID
,PNPC102 for the Device ID.

Of course, the product ID is prefixed with the start byte and 1.00 version code. And the device ID is prefixed by "\00000001\MODEM" and followed by "\ModemCC\x29", where CC is replaced by the checksum's high nibble(first byte) and low nibble(second byte), in hexadecimal.

Would that be correct?

Full PnP string generation code for the Hayes-compatible modem:

void MODEM_sendAutodetectionPNPmessage()
{
//return; //We don't know what to send yet, so disable the PNP feature for now!
//According to https://git.kontron-electronics.de/linux/linux-imx-exceet/blob/115a57c5b31ab560574fe1a09deaba2ae89e77b5/drivers/serial/8250_pnp.c , PNPC10F should be a "Standard Modem".
//"PNPC10F"=Standard Modem. Order is(in order of escapes: Version(two 5-bits values, divided by 100 is the version number, high 5-bits first, low 5-bits second) ID("PNP"), product ID(the ID), Serial number(00000001), Class name("MODEM", as literally in the Plug and Play Exernal COM Device Specification Version 1.00 February 28, 1995), Device ID("," followed by the ID), User name("Modem", this is what's reported to the user as plain text).
//The ID used to be "PNPC10F". Use PNPC102 for a safe Standard 28800bps modem.
char EISA_productID[] = "PNPC107"; //Product ID! Standard modem?
char DeviceID[] = ",PNPC107"; //Device ID! Standard modem?
char PNPHeader[] = "\x28\x01\x24"; //Header until EISA/product ID
char PNPMid[] = "\\00000001\\MODEM"; //After EISA/product ID until Device ID
char PNPFooter[] = "\\ModemCC\x29"; //Footer with checksum!
char message[256]; //Buffer for the message to be modified into!
memset(&message, 0, sizeof(message)); //Init the message to fill!
word size;
byte checksum;
char *p, *e;
//Start generating the checksum!
checksum = 0; //Init checksum!
//Copy the initial buffer data over(excluding checksum)!
safestrcat(message,sizeof(message),PNPHeader); //Copy the message over to the actual buffer!
safestrcat(message,sizeof(message),EISA_productID); //Copy the product ID over!
safestrcat(message,sizeof(message),PNPMid); //Copy the second part of the message to the actual buffer!
safestrcat(message,sizeof(message),DeviceID); //Copy the device ID over!
safestrcat(message,sizeof(message),PNPFooter); //Copy the footer over!
size = safe_strlen(message,sizeof(message)); //Size to send! Sizeof includes a final NULL byte, which we don't want to include! Taking sizeof's position gives us the byte past the string!
e = &message[size-1]; //End of the message buffer(when to stop processing the checksum(the end PnP character). This selects from after the start byte until before the end byte, excluding the checksum itself)!
p = &message[1]; //Init message to calculate the checksum(a ROMmed constant) to the first used byte(the byte after the start of the )!
message[size - 2] = 0; //Second checksum nibble isn't counted!
message[size - 3] = 0; //First checksum nibble isn't counted!
for (;(p!=e);) //Not finished processing the entire checksum?
{
checksum += *p++; //Add to the checksum(minus the actual checksum bytes)! Also copy to the active message buffer!
}
checksum &= 0xFF; //It's MOD 256 for all but the checksum fields itself to get the actual checksum!
message[size - 2] = ((checksum & 0xF) > 0xA) ? (((checksum & 0xF) - 0xA) + (byte)'A') : ((checksum & 0xF) + (byte)'0'); //Convert hex digit the low nibble checksum!
message[size - 3] = (((checksum>>4) & 0xF) > 0xA) ? ((((checksum>>4) & 0xF) - 0xA) + (byte)'A') : (((checksum>>4) & 0xF) + (byte)'0'); //Convert hex digit the high nibble checksum!

//The PNP message is now ready to be sent to the Data Terminal!

fifobuffer_clear(modem.inputbuffer); //Clear the input buffer for out message!
char c;
p = &message[0]; //Init message!
e = &message[size]; //End of the message buffer! Don't include the terminating NULL character, so substract one to stop when reaching the NULL byte instead of directly after it!
for (; (p!=e) && ((fifobuffer_freesize(modem.inputbuffer)>2));) //Process the message, until either finished or not enough size left!
{
c = *p++; //Read a character to send!
writefifobuffer(modem.inputbuffer, c); //Write the character!
}
//Finally, the CR/LF combination is sent!
writefifobuffer(modem.inputbuffer,modem.carriagereturncharacter);
writefifobuffer(modem.inputbuffer,modem.linefeedcharacter);
}

The value it's generating with PNPC107 is:

0x0000007c8230f530 "(\x1$PNPC107\\00000001\\MODEM,PNPC107\\ModemDC)"

Would that be a correct ID for PNPC107(Generic modem)?

This is what I can find in the registry with the PnP modem and what looks like the actual modem for said port that was manually added:

1223-What seems to be the modem thats installed.jpg
Filename
1223-What seems to be the modem thats installed.jpg
File size
133.82 KiB
Views
758 views
File comment
What seems to be the modem that's installed correctly.
File license
Fair use/fair dealing exception
1224-What seems to be the PnP detected device.jpg
Filename
1224-What seems to be the PnP detected device.jpg
File size
136.94 KiB
Views
758 views
File comment
What seems to be the PnP detected device.
File license
Fair use/fair dealing exception

Edit: So that error code (1c) means that the device drivers aren't installed?
https://docs.microsoft.com/en-us/windows-hard … -failed-install

I indeed did skip that step for the moment, but it's not even showing up in the device manager?

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

Reply 155 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

So there's currently two autodetection things in Windows 95 RTM goign wrong: Sound Blaster IRQ isn't detected(DMA and I/O ports are detected) and the Serial modem autodetection (needing to be a Hayes-compatible 56K modem) isn't detecting and installing drivers properly(because of misdetection?).

What's the difference between the productID and deviceID fields in the serial PnP packet? They look like they have the same format?

Edit: OK. The PnP device is in the System properties, just not in the normal view. When I enable the "View devices by connection" view, I see it listed under COM2.
Edit: It's being reported as the ID specified in the settings(PNPC107), but no drivers?
Edit: It says:

Device type: Modem,PNPC107
Manufacturer: None specified.
Hardware version: Not available

Edit: There is also a 28800bps modem driver installed on that UART? Is that an issue with Windows 95 driver installation for said port(conflicts installing drivers)?

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

Reply 156 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just changed the second part of the PnP ID a bit, changing the Device ID from ",PNPC107" to "\\PNPC107" (of course \\ being a single escaped character for the string value, it's just a plain single backslash)... Suddenly, Windows detects the modem correctly! So does that mean that the example for the ",PNP(...)" is faulty and wrongly documented?

But anyways, that just leaves the issue with programs closing without visible cause(no clicking etc. some software just close out of the blue) and the MPU-401/Sound Blaster IRQs not being autodetected somehow, when scanning for new/changed hardware(both during Windows setup and during the Add new hardware wizard)?

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

Reply 157 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Even with all those CPU bugfixes, PC-Check 6 and CheckIt! Diagnostics still generate a Divide by zero(Checkit) or Divide overflow(PC-Check 6) when starting them? Anyone knows what might be the cause in that? The last thing it says is that it's loading libraries?

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

Reply 158 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.... The issue with PC-Check 6(Divide overflow) even happens on the 80486 emulation?

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

Reply 159 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just trying to find the reason for the INT 00 crash at 30DB:43CE. It only seems to happen on the Pentium emulation and not on 80486 and lower CPU emulation?
Edit: That's called by a program at segment 24C2. This is at least somewhere within CheckIt itself.
Edit: Segment 24C2 is called by segment 1166. This is probably also inside CheckIt(at least after finishing to load the executable).
Edit: Segment 1166 is called by segment 35f7. 35F7 at least past the loading phase of the CheckIt executable.
Edit: Segment 35F7 is called by segment 1c32. Probably MSDOS.SYS? It's at least immediately triggered from the instruction executing at 0023:a0fe. So that's probably some MS-DOS kernel stuff being called. It triggers immediately after pressing the carriage return key on the MS-DOS prompt. So it's probably safe to say that it's the start of the EXE loader in the MS-DOS kernel? Or perhaps command.com?
Edit: Segment 1c32 is called by segment 23. That's probably IO.SYS or MSDOS.SYS? This is triggered immediately after executing the command?

Edit: Segment 35F7 starts (at location 35F7:0024) with a INT 21h call with AH=30h. So that's a Get DOS version instruction, according to Ralf Brown's interrupt list. Since I can't imagine that's actually done usually by the MS-DOS kernel, it should be the start of the software being executed(CHECKIT.EXE)?

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