I've implemented a little delay between the 0xFF reset 0x00 0xFA result and it's 0xAA response. But even setting it to 100 milliseconds (as the code says 400 milliseconds), CX is still zero. BL is the correct 0xAA though.

8042 emulation: https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master
PS/2 keyboard and XT keyboard emulation: https://bitbucket.org/superfury/unipcemu/src/ … ard.c?at=master

Anyone can see why, even though the 0xAA response should be delayed (100us delay), CX is still zeroed, although BL is loaded with 0xAA(The result data)?

There must be a delay after the key is submitted through the input buffer, before the response is posted to the output buffer.
The code waits until the input buffer is empty so that it's safe to submit (xmitloop), submits the key and waits until the output buffer is empty (xmit1) if it wasn't already from the previous command (xmit2), and finally waits until the output buffer is filled for the current command (xmit3).
So if your code is posting to the output buffer faster than the polling can see that the buffer was empty before it was filled, then you'll see the error.

I've added little delays of 100ms between the processing of each command or parameter and their result byte(s). It will now wait 100ms between every byte written to the keyboard controller and the results (both with 0xFA/0xFE results for the command and before the following bytes if needed (like a parameter byte being sent and results being returned after a delay).

I've also added and improved the 80286's protected mode, now supporting call gates to be called to(with stack copying using a CPU-wide 32-bit FIFO buffer of up to 32 entries, which copies dwords or words from the source stack(based on the SS-segment's B-bit to read (d)words as dwords into the buffer) to the destination stack(Using the destination SS-segment's B-bit to write (d)words from the dword buffer, where the upper 16-bits are thrown away if it's writing as words). Is that correct behaviour?

Strangely enough, with the latest additions, Windows 3.0 crashes when mouse events are received(UART) on the NEC V20/V30 emulation? Either a black screen or full crash to the MS-DOS prompt? I've implemented improved UART timing, will that help?

Btw, the 80286 currently uses the very same 8086/8088 instruction cycle counts for both real and protected modes. 80186+ instructions and most 80286+ instructions(except LMSW, which uses many cycles, in order for the prefetch to fill for the following JMP instruction to be fully prefetched) use default(8) cycles.
The actual CPU frequency is exactly high enough, so that the outcome of the DRAM Refresh speed test matches it's documented(the parts mentioning that value with +/- 10% margin) speed exactly in 80(1/2)86 speed combinations currently used.

Anyone knows the correct response times of PS/2 Keyboards and mice?

superfury wrote:

Anyone knows the correct response times of PS/2 Keyboards and mice?

Try here: http://www.computer-engineering.org/ps2protocol/

It only says it's at 10 - 16.7 kHz. It takes 11 cycles to receive (Device to host) and 12 cycles to send(Host to device). So it doesn't say the exact rate?

What does the F1 instruction do on 80286- processors (80286, 80186, 8086 CPUs)? I've now implemented it as a simple NOP instruction, but doing so crashes Windows 3.0 when run in the new 80286 XT mode?

superfury wrote:

What does the F1 instruction do on 80286- processors (80286, 80186, 8086 CPUs)? I've now implemented it as a simple NOP instruction, but doing so crashes Windows 3.0 when run in the new 80286 XT mode?

F1 is an int1, which is a special kind of breakpoint, similar to int3. It is used for In-Circuit-Emulators (oldskool debugging tools): https://courses.engr.illinois.edu/ece390/arch … t-ref-int1.html
I suppose in an emulator you should just treat it the same as the regular int 1: jump to the handler routine for interrupt 1.
According to that page int3 should not get virtualized/redirected, not sure if that goes for int1 as well.
Edit: Some more background info here: http://www.rcollins.org/secrets/opcodes/ICEBP.html
It is unclear whether 286 actually supports this instruction, and if so, how it implements this... or if not, how it doesn't.
Perhaps you should just generate an invalid instruction exception? It could be a way for Windows to detect the system type?

I've implemented it as a simple one-byte INT 1 instruction. Now Windows 3.0's Program Manager help shows that it's in real mode without crashing halfway loading the window. Also 2MB extended memory is displayed (atm 6MB is installed). Trying to quit Windows 3.0 makes the entire OS crash(become unresponsive).

Anyone can tell me why the BIOS errors out with a 403 keyboard error? The keyboard response timings are currently adjusted to 5ms after the command is received?

superfury wrote:

Anyone can tell me why the BIOS errors out with a 403 keyboard error? The keyboard response timings are currently adjusted to 5ms after the command is received?

Error 304 instead of 403? Command E0 response bit 0 must be low.

Just looked at it again with the latest commit: 301-Keyboard error, 601-Diskette error, 161-System Options Not Set-(Run SETUP) is what I'm getting. F1 doesn't do anything.

I understand that 301 keyboard error: it's probably the reset command sent to the keyboard which is failing according to it. But why it gives the 601-Diskette error I don't know? I've emulated a generic NEC µPD765 and Intel 82072/7 Floppy Disk Controller (according to this article: http://www.isdaman.com/alsos/hardware/fdc/floppy.htm ). I have no idea why exactly it errors out. Although it doesn't apply timing (except for using the timed DMA transfers), it works without problems on the Turbo XT BIOS and original IBM PC XT BIOS. I see it emitting Sense Interrupt commands, Seek commands and Recalibrate commands. Of course the Seek command errors out (with ST0 containing "(FLOPPY.ST0.data & 0x30) | 0x18 | FLOPPY.DOR.DriveNumber" to indicate a drive without inserted media(there's no floppy in the floppy drives)). The other two commands normally complete without errors.

Edit: Just compared my code to Bochs' code. It seems Bochs indicates command successfully completed on Recalibrate, but non-present disk also sets bit 6(error executing command) and 4(track 0 not found after 79 pulses). My code always returned 0x20(which indicates success), after which the BIOS executes a seek that fails because there's no disk present.

Edit: Tried changing that resulting value with no disk inserted giving a ST0 register value of 0x70 (Indicates: error, track 0 not found, Seek Ended). But the BIOS still gives errors about the floppy disk controller?

As I already said, you will need to emulate the MC146818 with its CMOS. The BIOS will store configuration info there, such as which floppy and hard disk drives are installed.
That's probably why you see those errors.

The strange thing is: The CMOS (ports 0x70-0x71, as well as alternative timer source XT RTC at ports 0x240-0x249 and 0x250-0x257, which is mapped as an extension to the CMOS RTC(only thing that's extended is the microseconds time subdivision, which isn't supported on the plain CMOS RTC used in the AT and up)) is already emulated:
https://bitbucket.org/superfury/unipcemu/src/ … MOS.c?at=master

Also, when the emulator is terminated (doneEMU is called from the emulator core before the application is quit), it calls saveCMOS, which saves the CMOS in the Settings file(which is reloaded when the emulator is restarted or started for the first time). Thus the 'CMOS RAM' is virtual static RAM(it keeps it's values between sessions until cleared using the Settings menu option, or when the SETTINGS.DAT is deleted).

The CMOS data is copied from the emulator Settings file when emulation is started. It's saved back into the Settings file when the emulator is terminated (it's also flagged as present from that point on, until it's 'erased', which in the case of UniPCemu means setting a special flag in the emulator SETTINGS.DAT to zero (which causes the CMOS data to be invalidated)).

Btw, just tried to reinstall Windows 3.0 on the XT 286 configuration(With Turbo XT BIOS and XTIDE BIOS), but it eventually seems to hang when installing the applications. Looking using the debugger reveals it's in a infinite loop checking the head against the tail of the keyboard buffer? The head isn't the same as the buffer, and it only jumps back(JNZ) when the head and tail don't match, which is OK. But after that, it executes a STI and jumps back to the start of the handler, which in turn executes CLI and starts the head-tail check again. This results in an infinite loop?

Address 2047 is the flag indicating validity (1 for valid).
Immediately before that is the CMOS data itself, which consists of:
1. 128 bytes of static CMOS RAM.
2. Actual time divergeance in seconds (64-bit signed integer)
3. Actual time divergeance in us(64-bit signed integer). These two divergeances together create the time divergeance used by the emulator to get and set the virtual time.
4. 100th seconds, for the XT RTC (byte).
5. 10000th seconds, for the XT RTC (byte).
6. 8 bytes of extra RAM (Extra RAM data from XT RTC(UM82C8167), for 56 bits of extra RAM!).

So the complete CMOS data is 154 bytes large, starting at address 1893 in the Settings file(that location has the entire 128 bytes of CMOS RAM followed by the data mentioned at points 2-6).

The AT RTC is based on http://wiki.osdev.org/RTC and http://wiki.osdev.org/CMOS . The XT RTC (UM82C8167) is directly based on the datasheets of the chip itself.

Using a little hex editor (XVI32) to extract the CMOS data from it:

superfury wrote:

Edit: Tried changing that resulting value with no disk inserted giving a ST0 register value of 0x70 (Indicates: error, track 0 not found, Seek Ended). But the BIOS still gives errors about the floppy disk controller?

Seeks shouldn't fail this way. The only time track 0 not found should be returned is if there is no drive connected.

So Bochs (since it also seems to do this according to it's current source code on sourceforge) does this incorrectly? It sets bit 4&7 of ST0 when no floppy disk is mounted(during a recalibrate command).

superfury wrote:

alternative timer source XT RTC at ports 0x240-0x249 and 0x250-0x257

The XT doesn't have an RTC.

Strange: The ports.lst of Bochs lists those ports as a "XT RTC" chip. Also, the Generic Turbo XT BIOS v2.0 and higher (which are built for the IBM XT) detect that timer(XT RTC) and list it in the device list as "Timer"?

ioports.lst wrote:

0340-0357 ---- RTC (1st Real Time Clock for XT), (alternate at 0240-0257) (used by TIMER.COM v1.2 which is the 'standard' time […]
Show full quote

0340-0357 ---- RTC (1st Real Time Clock for XT), (alternate at 0240-0257)
(used by TIMER.COM v1.2 which is the 'standard' timer program)

0340 r/w 0.01 seconds 0-99
0341 r/w 0.1 seconds 0-99
0342 r/w seconds 0-59
0343 r/w minutes 0-59
0343 r/w hours 0-23
0345 r/w day of week 1-7
0346 r/w day of month 1-31
0347 r/w month 1-12
0348
0349 r/w year 0-99
034A
034B
034C
034D
034E
034F
0350 r status?
0351
0352
0353
0354 r status?
0355
0356
0357

Also: http://www.minuszerodegrees.net/rtc.htm

Apparently it was implemented in the XT clone "Samtron 88S" by Samsung.

superfury wrote:

Also: http://www.minuszerodegrees.net/rtc.htm

Yea, as it says: "for Various IBM PC Family Expansion Cards"
There were various cards that allowed you to add an RTC to a PC or XT system. Some XT clones even had one onboard.
However, as you can see, it wasn't standard on an IBM PC or XT, nor was it standardized. Various types of RTC chips were used, and installed at various base addresses.