Native PS/2 mouse implementation for 386/486 boards using the keyboard controller

[Anonymous Coward]

Okay, this is interesting. I found where the EBDA is moved on my PCI 486. It's at memory address 09A3:0000. That's in "low memory", aka the first 64kb of conventional memory. That's in PC-DOS 2K. That implies the OS is doing something automatically. Either that, or the BIOS is stuffing it there. I'm going to try MS DOS 7 and see what happens.

Can anyone else witha PS/2 mouse enabled dump memory location 0040:000E and tell me the two bytes you see there?

I get 0F 02 with MS DOS 7. That's 020F:0000 (the bytes are reversed for whatever reason).

In both of these configurations the first byte reads 01 (1kb) like it should. I think now it's just a matter of finding out WHY this location varies from DOS to DOS. Also, in this system INT 15h C1 properly identifies the location of the "EBDA"

[Anonymous Coward]

Hmm....I wonder where Int 15h C0h is getting the system parameters. Perhaps I should check out the ES and BX registers. Seems Bit 2 is a flag that needs to be set for C1h to correctly report the address of the EBDA.

AH = C0h Return system parameters
Exit:
ES:BX Pointer to System Configuration Bytes 1-2Length of table in bytes
(8)
Byte 3 Model (FCh = AT Byte 4 Sub model
(01h = AT)
Byte 5 BIOS revision level (0)
Byte 6 Feature information:
Bit 0 0 = Reserved
Bit 1 0 = ISA-type I/O channel
Bit 2 0 = EDBA not allocated
Bit 3 0 = Wait for external event
supported
Bit 4 1 = Keyboard intercept
(INT 154F) called by INT 09h Bit
5 1 = Real time clock present
Bit 6 1 = Second PIC present
Bit 7 0 = Fixed disk BIOS does not
use DMA channel 3
Byte 7 Reserved
Byte 8 Reserved
AH = C1h Return Extended BIOS Data Area Address
Exit:
ES Extended BIOS Data Area Segment Address
If Carry = 1
AH 86 = Invalid BIOS routine call (No EB

[Anonymous Coward]

Shit. It points to a ROM table. So...we either have to hack the ROM or intercept the int 15 EBDA check somehow.

On BOTH my EISA system and my PCI system, the ROM table is at F000:E6F5

The EISA system has a system config value of 70
The PCI system has a system config value of 74

The difference is bit 2, which is the EBDA bit!

NJRoadfan, would this happen to be the same bit you noticed that changed between the Enterprise III and Super EISA BIOSes?

Even the Sergey's XT BIOS has the table at the same location:

;=========================================================================
; configuration data table
;-------------------------------------------------------------------------
setloc 0E6F5h
config_table:
dw .size ; bytes 0 and 1: size of the table
.bytes:
%ifdef AT_COMPAT
db 0FCh ; byte 2: model = AT
db 00h ; byte 3: submodel = 0
db 00h ; byte 4: release = 0
db 01110000b ; byte 5: feature byte 1
; |||||||`-- system has dual bus (ISA and MCA)
; ||||||`-- bus is Micro Channel instead of ISA
; |||||`-- extended BIOS area allocated (usually on top of RAM)
; ||||`-- wait for external event (INT 15h/AH=41h) supported
; |||`-- INT 15h/AH=4Fh called upon INT 09h
; ||`-- real time clock installed
; |`-- 2nd interrupt controller installed
; `-- DMA channel 3 used by hard disk BIOS
db 00h ; byte 6: feature byte 2
db 00h ; byte 7: feature byte 3
db 00h ; byte 8: feature byte 4
db 00h ; byte 9: feature byte 5
%else
db 0FEh ; byte 2: model = XT
db 00h ; byte 3: submodel = 0
db 00h ; byte 4: release = 0
db 00000000b ; byte 5: feature byte 1
; |||||||`-- system has dual bus (ISA and MCA)
; ||||||`-- bus is Micro Channel instead of ISA
; |||||`-- extended BIOS area allocated (usually on top of RAM)
; ||||`-- wait for external event (INT 15h/AH=41h) supported
; |||`-- INT 15h/AH=4Fh called upon INT 09h
; ||`-- real time clock installed
; |`-- 2nd interrupt controller installed
; `-- DMA channel 3 used by hard disk BIOS
db 00h ; byte 6: feature byte 2
db 00h ; byte 7: feature byte 3
db 00h ; byte 8: feature byte 4
db 00h ; byte 9: feature byte 5
%endif ; AT_COMPAT
.size equ $-.bytes

[NJRoadfan]

If I'm reading this right, feature bit 1 would be at E6FAh in the BIOS image. On both the Tyan and the Enterprise III image it has a value of 70h, the same as the example above. Looking at the WInBIOS setup (I was playing around), looks like you can specify the location of the EBDA at 0:300h or "DOS 1K". The same option appears under the Tyan and NiCE boards as "Hard Disk Type 47 RAM Area".

[Anonymous Coward]

I would almost be willing to bet that if we change that F000:E6FA to 74 and have our VCF friend adjust the checksum we will have a working ps/2 mouse.

But I'm curious about the Enterprise III...it does have a working PS/2 mouse doesn't it?

[NJRoadfan]

There is no option for locating the EBDA at 0:300 or DOS 1K, I can only assume its hard coded to store at 0:300.

[Anonymous Coward]

On your Enterprise III with the PS/2 mouse plugged in, if you run debug and type D 0040:000E,what two bytes do you see?

Also, since the ROM BIOS is shadowed, there is a good chance we can disable the write protect and modify the shadow.

--edit--

I noticed Feipoa's post in which he said that on the Award BIOS two bits were changed to enable the PS/2 mouse. One is at F000:E6FA (we already know that is to indicate EBDA enabled and is in the same location on all systems). But what is this second byte at F000:FFEC?

[NJRoadfan]

I'm just running the BIOSes with PCEm. Running debug with the PS/2 Mouse enabled produces C0 9F at 0040:000E, while the Tyan just gives 00 00. Disable the mouse and the Enterprise III BIOS spits out 00 00 too.
F000:FFEC is 33 on both the Enterprise III and Tyan
F000:E6FA is 70 on both the Enterprise III and Tyan
The two above settings do not change with the mouse option enabled or disabled on the Enterprise III BIOS

[Anonymous Coward]

Now that we have an idea about how to defeat the AMI checksum, perhaps we should isolate which bits DO change and try creating a new ROM image.

So since your Enterprise three spits out 9FC0 at 0040:000E, wouldn't that imply that it is hardwired to the "DOS 1KB" option in the CMOS setup?

---edit---

I've been looking over the cutemouse source code. You are correct it doesn't check for the presence of an ebda. However, it does use EBDA to activate the mouse. Int 15 C200 is used to turn on the mouse interface. Probably it is not working and sending a negative result back to the mouse driver. I would guess that the int 15 service itself it checking for the ebda. My best guess was F000:E6F5, but since the enterprise III apparently doesn't set that byte it kind of blows my mind. Obviously EBDA is being used, because 9FC0 is being reported by 0040:000E. If possible I'd still like to try writing a value of 74 to F000:E6F5 to see what happens.

I checked the V2.0 b4 of cutemouse source code too. Despite claiming not to use the BIOS, it still uses int 15h services to enable the mouse. So unless we can get int 15h to report positive results we're not going to be getting anywhere unless there is a driver that doesn't use int 15h at all . Int 15 C2 returns code "86" on my systems, which translates as something like "mouse support not implemented". I'd really like to try NT4 to see if it can detect the mouse (assuming it doens't use int 15h at all)

[feipoa]

Hello world!

If anyone comes across a program named AMIBCP with version number 2.x or older, please respond to this thread.

EDIT: Actually, any version listed here

BCP14.EXE (for core BIOS 07/07/91)
BCP20.EXE (for core BIOS 12/12/91)
BCP21.EXE (for core BIOS 06/06/92)
BCP21A.EXE (for core BIOS 11/11/92 and 08/08/93)
WBCP33.EXE (for core BIOS 12/15/93 (and 06/25/94?))
WBCP40.EXE (for core BIOS 06/25/94 and 07/25/94)
WBCP42.EXE (for core BIOS 07/25/94)
WBCP511.EXE (for core BIOS 10/10/94)

Source: http://www.memotech.franken.de/NexGen/Bios.html

[Anonymous Coward]

If anyone is good at programming and can use the AMI BIOS source code floating around on the internet to make a small program to recalculate the CMOS checksums, please let us know.

[feipoa]

I have put the PS/2 mouse modification onto a removable socket so that I can more quickly test numerous 386 motherboards for PS/2 mouse BIOS support. I used surface mount capacitors and resistors, so you won't be able to see them in the photos. The green through-hole components shown are inductors (not resistors).

If I were to do this again, I think it would be easier to simply epoxy the inverter IC on top of the Holtek keyboard controller and forget about the inner DIP socket. The purpose of the DIP socket here is just to make the final product look cleaner and allows for changing the keyboard controller chip.

[133MHz]

It does look very clean & efficient I must say.
I've also hidden wiring under sockets for neatness but not entire DIP ICs, even though I've seen a similar arrangement on some motherboards.

[LeFlash]

Hello,

i did a quick look over the thread but wasnt able to find something ...

Is there any chance of getting the modded BIOS with ps/2 support and changed irq-routing?

Kind regards

[feipoa]

Are you looking for a BIOS for the DTK PKM-0033S which contains PS/2 support? If so, you still must do some hardware modification (adding an inverter and rewiring).

The BIOS which contains the altered PCI routing table is not needed for PS/2 mouse support. That BIOS is a hacked up Zida Tomato 4DPS BIOS, which can be used on the PKM-0033S, although it is not necessary. The 4DPS BIOS allowed the use of 64 MB SIMMs and some more modern graphics cards, however you will loose some CMOS control over the built-in IDE controller, which isn't very good to start with. On my system, I am not using the hacked 4DPS BIOS; I am using the PKM-0033S BIOS with PS/2 mouse supported added.

What are you trying to accomplish?

[Rio444]

Hi, friends!
I designed the driver to support PS/2 mouse instead BIOS.
You can download here the beta-version of the driver.
It is tested with 386DX-40, 486DX2-66, MS-DOS 6.22, Win3.11 and Win95.
I'll be glad to get feedback.

[feipoa]

Rio444: Could you describe a little how this driver works and what is needed for from the motherboard hardware for this driver to work?

I assume that everything must be setup correctly, hardware-wise, on the motherboard - e.g. the inverter circuit, IRQ12 connected, the clock signal, etc. What this driver does is make it so that you do not need to modify the BIOS to put the check in PS/2 support?

Have you tested this with AMI, AWARD, Phoenix, MR BIOS, etc? Have you tested it with KVMs? Are you able to provide an NT4 driver?

What 386DX-40 motherboard did you try it on? I haven't see any 386 motherboards with a PS/2 port, which did not already contain BIOS support for PS/2 mice.

[Rio444]

The driver needs the same hardware modification what was made by you or Anonymous Coward.
It include installation of the inverter circuit and connection Irg12.
The driver adds support PS/2 mouse without need to modify the BIOS.
It contains TSR module and the installation module.
TSR module include int 15h handler (services C2h and C1h) and int 74h handler.
The installation module does the following:
- check, whether there is already support for the mouse,
- adds mouse to the equipment list, at 40:10h address,
- unmasks Irq12 PIC,
- changes interrupt vectors 15h and 74h to its own.

I have tested with Award BIOS 4.50 (also it was tested with modified BIOS) and Ami BIOS 2.11 (1993).
386DX-40 motherboard is M326 V5.2 model. I did the same modification KBC, as you with your DTK PKM-0033S.

I have no NT4 driver. I suppose it is not needed.
You just need to enable the Irq12 at PIC and add mouse to the equipment list.
Everything else is already included in OS.

Added 26/01/18.
Last version of the driver, rev.1.0.2c, is here: https://yadi.sk/d/5ge32bgv3RoUHs

[Rio444]

I assembled the circuit using transistors MBBT3904 instead of chips 7406.
And I used SMD components.

[feipoa]

I'm not sure how I missed your post on 2017-12-02. Could you clarify some things.

1) Do we still need to wire the KBC to IRQ 12 on the ISA slot?

2) We can either modify the BIOS to allow for PS/2 mouse, or we can use your TSR program?

3) Have you tested this with a AMIBIOS on a 386 motherboard? Did it work?

4) Are there any motherboards which this hasn't worked with?

5) Did you include inductors on the mouse clock and mouse data lines? I've noticed that pretty much all 486 motherboards include the inductors. They are small, usually in the 1-4 uH range.

6) Do you have additional PCB's? I'd be very interested to test one.