Looking at the 1216 BIOS more closely, it does look like PS/2 mouse support (INT 15h, AH=C2h) is in there, and it is guarded by the check that you found.
In this case, you would change BF to to FF (in addition to fixing the checksum)

Thanks for your help. Unfortunately, so far the mouse hasn't been working.

I disabled the checksum.
Offset: 819A
changed 74 to EB

Enabled PS/2
Offset: E2C0
changed BF to FF

Then I merged the EVEN/ODD BIOSes back together, wrote the 32 KB EEPROM chips with my Wellon programmer, booted the board, but it cannot find the PS/2 mouse. I tried two different keyboard controllers. I know the keyboard controller mod works because if I run the PS2SUPPC.COM TSR, the mouse will work. I'm trying to get away from the TSR. I tried the Logitech driver and a Microsoft driver, both of which always work with my Logitech MouseMan on all other boards I've BIOS hacked for PS/2 support.

Maybe the PS/2 Mouse support in this BIOS wasn't correctly implemented? Or I've made a small mistake somewhere...?

Attached are the BIOS files I edited.

Confirming that after changing byte 819A from 74 to EB (to bypass checksum check), and changing byte E2C0 from BF to FF, the PS/2 mouse works running your Biostar BIOS in PCem. I am using CTMOUSE if it matters.
So at least in this 04/09/90 AMI 286-BIOS, the PS/2 mouse support works.
Maybe there is some incompatibility with your keyboard controller and this BIOS with respect to PS/2 mouse support?

Also: Checked that the edited files you uploaded are identical to mine.

After making the edit, you might follow the BIOS mod guide again, except this time run

DEBUG
A
MOV AX,C204
INT 15
INT3

(then T your way through the code)
Note that the only difference is the added INT3, so the INT 15 handler has something to return to.
Stop running T when you hit the INT3. The last few instructions before hitting it will give a hint as to where it goes wrong.
Once you figure out about how many times you need, you can run DEBUG > out.txt
Then you will have to work completely blind, and Ctrl-Alt-Del after you've done enough T to get back to the INT3, and after rebooting, you should have an exact trace through the BIOS PS/2 handler that you can upload here.

The first thing I'll check is CTMOUSE. I don't usually test with this mouse driver. Which version of CuteMouse did you test with? It looks like I have v1.9, 2.0, 2.1, and 2.1b4. If you are using a version other than these, would you be able to upload your ctmouse files?

I used 1.9. I also just tested lmouse.com from Windows 3.1 (i.e., very old Logitech driver), and it works too.

I normally use Logitech Mouseware v7.2. I have attached it. Could you see if this works for you with PCem?

Yes, that works also. The DEBUG trace will be quite helpful in identifying what is wrong. If nothing else, maybe there is a KBC version check we can override.

OK, since the Logitech 7.2 works for you, there isn't too much value in me checking CTMOUSE. I will run through my PS/2 capable keyboard chips, then run the debug procedure you laid out. I should be able to get to this within 6-7 hours.

What KBC does PCem emulate?

Looks like a hodgepodge of commands. Each case: statement starting around this line is a possible command: https://github.com/sarah-walker-pcem/pcem/blo … board_at.c#L505
Some of them are conditional on the selected chipset. So it isn't emulating an exact KBC; looks like it's been tweaked until it works.

That's not terribly reassuring.

Do you think pulling the battery and clearing CMOS might help?

I haven't looked yet, but did you see anything in this BIOS about a hidden MOUSE OPTION? Maybe the default option is overwriting the BIOS hack.

I'll have to double check but I have two VLSI 200 based boards with ps/2 mods I think they may have this same AMIBIOS...

maxtherabbit wrote on 2025-03-08, 03:59:

I'll have to double check but I have two VLSI 200 based boards with ps/2 mods I think they may have this same AMIBIOS...

Does your board also contain the VLSI VL 82C100-QC chip (or pin compatible alternative)? Would you mind uploading your PS2-fixed AMI BIOSes?

The AMI BIOS CMOS setup on my board is a little different than all other AMI BIOSes I've worked with so far. It contains just one page with only a few options, as shown:

The boot and POST screens are also shown here:

Looking at the code for INT 15h AX=C204h, it goes:

1. use command=60h data=65h to set the KBC configuration byte to disable mouse clock, and disable mouse interrupt
2. use command=D4h data=F2h to issue the identify command to the mouse
3. wait for response byte FAh (ack) followed by 1 byte of ID data

It seems a 486 BIOS works similarly.
Are you sure your KBC is wired to be in PS/2 mode and not AT mode? (or the PS/2 TSR wouldn't work?)

Yes, it is wired for PS/2 mode. Definitely not in AT mode. The KBC-PS2 adaptor is the same adaptor I've used on dozens of systems. I tried my own prototype and Max's PCB. If it was wired for AT mode, then running PS2SUPPC.COM wouldn't work, and it does. I've attached PS2SUPPC.

I've run into a similar problem once when the default option for the BIOS "MOUSE SUPPORT" was hidden and set to disabled, even though the BIOS was modded correctly. Somehow the default kept overwriting the PS2 BIOS mod, if that makes any sense, I don't know. But unhiding the MOUSE SUPPORT and setting it to enabled resolved the issue. Did you notice any hidden MOUSE SUPPORT option? I am planning on looking for this in a few hours and to reset CMOS by pulling the battery.

Sorry I didnt mean to imply I had working BIOS support for ps/2, just that they were hardware modded. I'm using the TSR, as I assumed the BIOS didn't have support and never bothered to check

This BIOS is too old to have a mouse support option. And besides, that should have shown up in PCem anyway.

At this point my only idea is to try debug and give us back the AX= BX= and whether it says NC or CY:

DEBUG
A
MOV AX,C204
MOV BX,BEEF
INT 15
INT3
(leave a blank line here)
G
Q

Unfortunately, running DEBUG > out.txt would hang the system.

The result of:

1DEBUG
2A
3MOV AX,C204
4MOV BX,BEEF
5INT 15
6INT3
7(leave a blank line here)
8G
9Q

is shown here:

The result of:

1DEBUG
2A
3MOV AX,C204
4INT 15
5INT3
6
7(T your way through the code ... stop running T when you hit the INT3)

... Too many pages to take photos of. Debug > out.txt hangs the system. However, when I ran across:

I noticed that E2C0=BF. Didn't we change it to FF? Or is this a different incident?

Then I stopped when I hit INT 3:

Any hints as to the problem from these results?

feipoa wrote on 2025-03-08, 12:12:

I noticed that E2C0=BF. Didn't we change it to FF? Or is this a different incident?

this sure looks like the problem to me, did you dump and verify the ROM image after reprogramming?