Thank you,

That is awesome!

While I know the x86 arch gets a lot of flack for seemingly being an ugly duckling of a processor, there is a an inner beauty to it's design that you see when you write an emulator for it.

Just was working on getting my PS/2 mouse emulation working with the new testing OS. Oddly enough, the Y axis seems to be reversed(positive makes it move the mouse upwards)? With a serial mouse, it's moving down instead(with the exact same binary value)?

Edit: Looking at it's source code confirms that strange behaviour:

1    if ((mdec->buf[0] & 0x10) != 0)
2      mdec->dx |= -1 << 8;
3    if ((mdec->buf[0] & 0x20) != 0)
4      mdec->dy |= -1 << 8;
5    mdec->dy = -mdec->dy;

So the Y position of the PS/2 mouse is (in comparison with serial mice) reversed? Nothing about that is mentioned with the osdev documentation?

This is my currenty working mouse packet generation:

1	packetmovementy = -packetmovementy; //Y is reversed for some unknown reason!
2	
3	xoverflow = ((packetmovementx < -0x100) || (packetmovementx > 0x1FF)); //X overflow?
4	yoverflow = ((packetmovementy < -0x100) || (packetmovementy > 0x1FF)); //Y overflow?
5	xmove = signed2unsigned16(MAX(MIN(packetmovementx, 0x1FF), -0x100)); //Limit!
6	ymove = signed2unsigned16(MAX(MIN(packetmovementy, 0x1FF), -0x100)); //Limit!
7
8	switch (index) //What index?
9	{
10		case 0:
11			return (
12				(yoverflow?0x80:0)| //Y overflow?
13				(xoverflow?0x40:0)| //X overflow?
14				((ymove&0x100)?0x20:0)| //Y negative?
15				((xmove&0x100)?0x10:0)| //X negative?
16				0x08| //Always 1!
17				((packet->buttons&4)?0x04:0)| //Middle button?
18				((packet->buttons&2)?0x02:0)| //Right button?
19				((packet->buttons&1)?0x01:0) //Left button?
20				); //Give the packet byte!
21			break;
22		case 1:
23			return (xmove&0xFF); //X movement, lower 8 bits!
24			break;
25		case 2:
26			return (ymove&0xFF); //X movement, lower 8 bits!
27			break;
28		default: //Unknown index?
29			break;
30	}
31	return 0; //Nothing to process!

Otherwise, the OS is stable(it's not crashing itself). But any application that's executed will somehow try to load a NULL segment descriptor into CS(at EIP=00000F00)?

Edit: Just tried running the OS in Bochs and Dosbox. Bochs gives a black screen, while dosbox(boot program) flat out crashes?
Edit: Qemu doesn't crash, but some programs literally do nothing at all(empty row and back to prompt).
Also it's blazingly fast, you cannot even see the dir output except the final few lines.

Just took a good look at popping SS:ESP from the stack when returning to an outer privilege level using RETF. It was using the incorrect layer to process it's POP for loading said data from the stack (internal instead of instruction level), thus always skipping the whole POPs of SS:ESP and leaving them zeroed. Whoops! 😖

Having fixed that, as well as related problems(CPL not being restored to it's old value when pausing the instruction flow(due to waiting for the BIU to read (E)SP and SS from the stack), thus aborting in the middle of the progress as well as said pauses causing (E)SP to be incremented multiple times instead of only once during said breaks(one addition for each break)), the applications run without crashing now! 😁

Various programs run without error now(except hello1 to hello3, which apparently give a wrong HRB file format error).
All other applications that are installed on the disk image seem to work without problems(although, when comparing to QEMU, the star demos actually execute so fast on QEMU that you don't see it(since it's closing the window almost immediately after drawing).

So simple but big progress there! All the apps(except hello and hello2, which apparently are invalid hrb files) seem to run without problems!

Edit: Windows 3.0 still crashes with two page faults, though.

Congrats that is very nice!

With some more bugfixes I've also got Windows 3.1 running in Standard mode! Although for some odd reason, Windows 3.0 in both protected modes(standard and 386 mode) crashes on boot(386 enhanced mode returning to the MS-DOS prompt and Standard mode gives a black screen). Windows 3.1 in 386 enhanced mode crashes to an empty 80x25 text mode screen with cursor in top-left character directly after finishing to draw the logo.

So still some unknown instruction or protection bugs.

The 3.1 standard mode I finally got working by fixing RETF to lower privilege level(CS.RPL>CPL) to pop SS:ESP correctly(instead of leaving it zeroed and loading it in their registers, faulting. Also fixed a bug in the 32-bit LAR(and LSL) writing the wrong size(thus not writing anything to their destination at all when it's a register). Those two fixes finally got Win3.1 setup and booting(both use Standard mode). Although currently the /s parameter is required because due to the improved CPU detection support it tries 386 enhanced mode by default(at least Win3.1) because it finds a 80386 with 3MB RAM(4MB emulated in my case atm(using memorylimit.txt containing "4M" as it's contents(up to 4GB by default without the limit, depending on free RAM for the emulator)).

That reminds me,

While developing DOSBox-X I found out that Microsoft does something nonstandard in Windows 3.0 to detect 286 vs 386.

They don't do the Intel FLAGS test we all know and love.

Instead, it will detect a 286 vs a 386 by using SGDT to store the GDTR register to memory, and then check whether bits 31-24 of the base address are 0xFF.

Apparently the Intel 286 will only store bits 23-0 of the GDTR base, and will always return bits 31-24 of the base as 0xFF.

You will need to emulate that fact if you want to get Windows 3.0 to run properly in 286 standard mode while emulating a 286, because otherwise Windows 3.0 will start executing 386 instructions.

And then there's the nonstandard use of the "reset vector" that Windows 3.0 uses when running a DOS VM on a 286, that I can describe if you like.

You'll find that Windows 386 enhanced mode requires your emulator to support paging and I/O trapping.

The Windows 3.x environment could be thought of as user-space code that either talks directly to I/O ports or calls down to DOS and the BIOS to do what it needs, and 32-bit kernel code that traps and virtualizes interrupts and I/O ports to make it work.

So basically, Microsoft wrote Windows 1.x through 3.x to talk directly to things like a DOS program, and then they made the transition to 32-bit protected mode by wrapping it all under a 386 kernel that virtualizes it to make everyone get along.

Perhaps the funniest example is how the mouse driver works in Windows 3.1. It's really just a user-space DLL that calls to the BIOS through INT 15h to set up a PS/2 mouse interrupt callback, and then receives the callback from the BIOS (through the underlying DOS extender, of course). There's no support other than I/O virtualization for it at the 386 kernel level.

Windows 95 and later take it to some more extremes, where INT 10h and INT 13h will be run under virtual 8086 mode when it needs to call down to the BIOS.

Well, two things I notice:
- When Windows 3.0 crashes in 386 enhanced mode, I see it throwing two Page faults nested within each other. That might somehow be the cause of the crash?
- Windows 3.0 gives a black screen in 286-mode.
- Windows 3.1 in 386 enhanced mode crashes to text mode and hangs.
- The virtual I/O ports are already emulated. I know that EMM386 already works, which also traps some/all I/O ports and virtualizes them(only DMA afaik). EMM386 seems to run fine(even ran the EMS board tests from Lo-Tech to verify it and VIDE-CDD.SYS works. Both run successfully).
- Windows 3.0 uses either the EMM386.SYS it installs or the EMM386.EXE from MS-DOS 6.22. I think it was the latter. Is that an issue? Also no smartdrive is loaded(it is in 3.1). The same with HIMEM.SYS.

BTW latest test386.asm does not compile. It was broken in the last 5 commits or so. It is using a define (macro) for GPF which was removed.

I've currently managed to get it to compile by enabling the BOCHS configuration to be set to 1 instead of 0(although that disables the ARPL writeback test). That will make it able to compile again for now(Until hottobar fixes it).

Currently trying to install Windows 95(Dutch version) on a simple 100MB harddisk.

So far gotten (after about 2 hours) just past the licence agreement confirmation screen, doing some floppy disk accesses and having started the Wizard Windows 95 Setup. Currently at the collecting data screen(it's probably still running in 16-bit proteted mode or 32-bit protected mode without Paging).

Buttons work without problems.
Edit: Chose the C:\WINDOWS default directory.
Edit: Checking installed components 100%.
Edit: Checking available disk space 89%...
Edit: Installation method...
Entering key.
Edit: Aborted and continued on PC version only due to faster speed.

Edit: It seems scandisk under MS-DOS(before starting the installer) has the same keyboard issue as Jazz Jackrabbit? The Numpad Enter key has effect, but the normal Enter key does nothing(doesn't confirm the operation to click any button)?

Edit: Also at the same time performing the same installation(only with a different second harddisk image which is much larger(2GB vs 100MB)) on my i7 PC.
Edit: I' ll show the Android version updates above, the PC version updates below this.
Edit: Obviously the i7 is way faster emulating it(~1% speed on Android, ~20% speed on i7, so more than 20 times faster on i7).

Preparing wizard 100%.
Checking installed components 100%.
Checking available disk space 100%.
Entered key and user data...
System analysis 100%...
Choosing default Windows components.
No boot floppy.
Copy files. Preparing...

superfury wrote:

Currently trying to install Windows 95(Dutch version) on a simple 100MB harddisk.

Stupid question maybe, but why are you posting this in the thread about the test386.asm CPU tester? Wouldn't it make more sense to be in the thread about your emulator (er, wherever that thread has got to)?

Good point. I`ll continue on on the Windows 3.0-3.1 thread.

Just tried running Jazz Jackrabbit(MS-DOS). It crashes when ran(install.exe is unusable now, see below).

The installer's somehow worse: the keyboard enter(numpad enter to be exact) key still works, but the arrows don't anymore? It works fine running edit.com? The scancodes SHOULD be correct, according to specs on the PS/2 scancodes(in all known forms, even with modifier keys(like NumLock, Ctrl, Alt&Shift combinations).

So why is the input not working? Still some hidden CPU bug?

Well, one nice thing with the latest updates: Day of the Tentacle (286+ game) is finally running!

Sound recording and screen captures of it running:
https://www.dropbox.com/s/gqa0udl9mhhnluj/DOT … unning.zip?dl=0

Just added the 80286+ instruction length overflow fault(#GP(0) thrown when instruction length exceeds 10 bytes(286) or 15 bytes(80386+)).

Unfortunately, this causes the Compaq Deskpro to oddly crash into NULL instructions(instruction 0000h) on CS=A000) for some odd reason.

The counter is the same counter that's used to determine the amount of bytes in the current instruction for logging(e.g. 16-bit EAooooSSSS(o=offset, S=segment) will have it contain the number 9 after the last opcode byte is read fron the PIQ by the EU).

The only reason this fault might happen might be due to invalid clearing of said length value during new instructions or maybe repeated instructions(although it shouldn't add to said buffer))?

Hmmm... Was experiencing wrong BIOS settings on Android when copied over from the PC version.

After some testing I actually find out it was the ini file line-ending that was causing troubles. Android uses LF, while Windows read/writes in CRLF.

Simple fix, however: just change the file modes from "r" and "w" to "rb" and "wb".

Although that changes all line-endings to LF, thus requiring Wordpad on Windows to edit it, while becoming cross-platform ini files as a gain.

Edit: Just went the third path: reading can process all possible line endings(either CRLF(prioritize) or CR/LF(either one)). When a CRLF is found, it's parsed in that way, while just CR or LF also counts as a newline(So CR is a newline, LF is a newline, CRLF is a newline and LFCR are two newlines(first read as Unix-style newline, the second read as Macintosh-style newline)).
Writing the ini files still happens in the native format(either CRLF(Windows), CR(Macintosh) or LF(Unix)) for the current OS.

Edit: Also managed to fix the problem with the Sound Blaster that(according to old Dosbox source code) caused Windows 3.1 to hang when recording using 8-bit DMA(the first sample isn't read through Direct DAC).

The crash on the newly implemented instruction byte count limit was due to the counter&buffer being added during REP*eated instructions. Having fixed this, the counter won't (normally) trigger again and the POST succeeds 😁

Edit: Just tested cross-platform line endings by using the Android with Jota Text Editor to change to various line-endings(all three of them). It runs like a charm! 😁

Just tried the Supersoft/Landmark Diagnostics BIOS again. It immediately crashes incorrectly on loading segment 0x0018 into one data register using the opcode 8E MOV within the Protected Mode test? That isn't supposed to happen?

http://www.minuszerodegrees.net/supersoft_lan … dmark%20ROM.htm

It's the one for the 5170.