VOGONS


test386.asm CPU tester

Topic actions

Reply 160 of 178, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 161 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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:

    if ((mdec->buf[0] & 0x10) != 0)
mdec->dx |= -1 << 8;
if ((mdec->buf[0] & 0x20) != 0)
mdec->dy |= -1 << 8;
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:

	packetmovementy = -packetmovementy; //Y is reversed for some unknown reason!

xoverflow = ((packetmovementx < -0x100) || (packetmovementx > 0x1FF)); //X overflow?
yoverflow = ((packetmovementy < -0x100) || (packetmovementy > 0x1FF)); //Y overflow?
xmove = signed2unsigned16(MAX(MIN(packetmovementx, 0x1FF), -0x100)); //Limit!
ymove = signed2unsigned16(MAX(MIN(packetmovementy, 0x1FF), -0x100)); //Limit!

switch (index) //What index?
{
case 0:
return (
(yoverflow?0x80:0)| //Y overflow?
(xoverflow?0x40:0)| //X overflow?
((ymove&0x100)?0x20:0)| //Y negative?
((xmove&0x100)?0x10:0)| //X negative?
0x08| //Always 1!
((packet->buttons&4)?0x04:0)| //Middle button?
((packet->buttons&2)?0x02:0)| //Right button?
((packet->buttons&1)?0x01:0) //Left button?
); //Give the packet byte!
break;
case 1:
return (xmove&0xFF); //X movement, lower 8 bits!
break;
case 2:
return (ymove&0xFF); //X movement, lower 8 bits!
break;
default: //Unknown index?
break;
}
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.

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

Reply 162 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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!

haribote_apps.gif
Filename
haribote_apps.gif
File size
585.77 KiB
Views
1302 views
File comment
All Haribote apps that are valid running on UniPCemu!
File license
Fair use/fair dealing exception

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

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

Reply 163 of 178, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Congrats that is very nice!

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 164 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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)).

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

Reply 165 of 178, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by TheGreatCodeholio on 2018-08-20, 16:30. Edited 1 time in total.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 166 of 178, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 167 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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.

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

Reply 168 of 178, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

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.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 169 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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).

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

Reply 170 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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...

615-Windows 95 preparing to copy files during setup.jpg
Filename
615-Windows 95 preparing to copy files during setup.jpg
File size
144.41 KiB
Views
1201 views
File comment
Windows 95 setup preparing to copy it's files.
File license
Fair use/fair dealing exception
626-Windows 95 copying its files to the harddisk.jpg
Filename
626-Windows 95 copying its files to the harddisk.jpg
File size
122.45 KiB
Views
1198 views
File comment
Windows 95 setuo copying it's files to the hard disk.
File license
Fair use/fair dealing exception
629-more progress installing windows 95.jpg
Filename
629-more progress installing windows 95.jpg
File size
115.65 KiB
Views
1198 views
File comment
More progress
File license
Fair use/fair dealing exception
634-almost halfway.jpg
Filename
634-almost halfway.jpg
File size
131.66 KiB
Views
1198 views
File comment
Almost halfway
File license
Fair use/fair dealing exception
646-more progressing 84 percent.jpg
Filename
646-more progressing 84 percent.jpg
File size
121.29 KiB
Views
1195 views
File comment
More progressing slowly... 84%
File license
Fair use/fair dealing exception

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

Reply 171 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++
657-getting close.jpg
Filename
657-getting close.jpg
File size
129.36 KiB
Views
1194 views
File comment
Slosly but surely, getting closer to the finish... More than 12 hours later!
File license
Fair use/fair dealing exception

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

Reply 172 of 178, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
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)?

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 173 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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

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

Reply 174 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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?

Last edited by superfury on 2018-09-01, 23:03. Edited 1 time in total.

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

Reply 175 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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

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

Reply 176 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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))?

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

Reply 177 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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! 😁

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

Reply 178 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

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.

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