I have 27C256 eproms, but I don't have a tool for burning them. Plus, do you think it would pass checksum if you lopped the 128kb image in half? I am skeptical.

I think we should focus efforts on defeating the checksum.

For 128kilobyte bios you need an 27c010 1 mega bit eprom
The 27c256 is a 32 kilobyte rom and the 27c512 is 64KB à half megabit
But why not use eeprom?

JaNoZ wrote:

For 128kilobyte bios you need an 27c010 1 mega bit eprom
The 27c256 is a 32 kilobyte rom and the 27c512 is 64KB à half megabit
But why not use eeprom?

The board only takes 28pin 27C512 chips.

Anonymous Coward wrote:

I have 27C256 eproms, but I don't have a tool for burning them. Plus, do you think it would pass checksum if you lopped the 128kb image in half? I am skeptical.

I think we should focus efforts on defeating the checksum.

I don't think the HiFlex core is larger than 64kb. I just chopped the file down to 64kb and the image POSTed on PCEm without a problem, so it is passing the checksum test.

Ok i understand, but you will need to program and install a 27c512.
You cannot write 64KB to a 27c256 after you chopped the right part from the 128KB file.
The rest is just FF empty, you could cut it an just flash the bios, the checksum will be ok i figure.

I have 27c512 and 27C010 too. But still don't think I have a tool to burn. Can XTIDE do regular eproms, or can it only handle flash roms?

The XT IDE only handles flash.

I believe XTIDE can do 82512 flash roms. Maybe I should order a few and try it out.

edit

No. I checked with the VC people. Looks like I'm going to have to buy a proper programmer. Oh well, at least this way I can get some use out of my big box of eproms.

NJRoadfan wrote:

I pulled the BIOS for the PS/2 compatible AMI boards. I found a difference that is consistent between PS/2 and non-PS/2 boards involving the "Mouse Support" variable, but can't confirm that it actually works because of the checksum test.

Could you let use know exactly what you found that was different? Particularly, what addresses and what data values? Are you taking the packaged binary file which gets sent to the flasher, or are you extracting the code, like original.tmp, which omits stuff like the POST image?

This is what I determined for the AWARD boards,

So for whatever reason, if you do not use modbin or awdbedit to enable PS/2 mouse support, you will need to extract original.tmp and modify with a HEX editor 0x1FFEC to a value of 81h (10000001) and 0x1E6FA to a value of 74 (01110100). The non-PS/2 enabled values would be 01h (01 binary) and 70 (0110000) for 0x1FFEC and 0X1E6FA, respectively. This is probably only true for AWARD BIOSes. For AMI, you'd have to determine which location in the BIOS corresponds to enabling the PS/2 mouse function.

I should also compare the packaged binary addresses and data values.

The AMI HiFlex image look fairly simple compared to the Award Modular (key word there) BIOS. Its only 64k in size and doesn't appear to use extensive encoding/compression. There is a byte located after each menu setting (which is stored in plain text) that appears to control whether or not a menu item shows up in the setup program. I compared the PS/2-enabled AMI Enterprise III BIOS image with a few standard non-PS/2 Mouse images and spotted a difference. Without AMIBCP, its impossible to verify if that is indeed the only change needed, mostly because of the checksum test.

The next best thing (at least for EISA SiS406/411 boards) is to try the AMI Enterprise III BIOS on other boards with the same chip set and see if the adapter works.

I'm planning to grab an eprom programmer later this month to test the Enterprise III BIOS.

In the meantime, I think I have found useful information to modify the BIOS equipment list. It is stored in the 128byte CMOS RAM that is accessible by reading and writing to ports 70h and 71h. Bit 2 of byte 14h is what needs to be changed to enable PS/2 mouse. There may be a checksum on the 128byte RAM too, but since it's small it shouldn't be too hard to figure out.

I stopped using DEBUG because I don't know what I'm doing and nothing I tried seemed to work.

I instead used QB45 which I successfully used to read and change the bits in CMOS memory. Unfortunately the BIOS equipment byte value was 4F, which implies mouse support enabled since bit2 is set. I changed it to FF just to see what would happen, and it did indeed try to change the display type, but also threw up a CMOS checksum error. Perhaps the BIOS equipment list isn't what needs to be changed afterall.

You should be able to read the equipment list byte in CMOS RAM by typing the following in BASIC:

CLS
OUT &H70, &H14
PRINT HEX$(INP(&H71));
END

If one wants to force the mouse equipment bit to enabled run debug and type in "e 0040:0010 27". It will edit the byte in RAM and CuteMouse should pass its initial PS/2 mouse check (make sure the version you are running has PS/2 mouse support compiled in!). Hopefully it will communicate with the mouse after that.

Will do.

Nope. That didn't seem to work. Somebody else should try to verify. Maybe there is something hardwired into the BIOS ROM?

My board actually reports a value of 63. (I changed it to 67)

Now my big quesiton is why is the INT 11 BIOS Equipment byte (63) different from the CMOS RAM Equipment byte (4F)? Wouldn't it make more sense if they were the same?

Read this if you want to know about the CMOS RAM:

http://oopweb.com/Assembly/Documents/InterLis … Volume/CMOS.LST

By the way, running AMISETUP reports the location of the CMOS RAM checksums.

I still think the BIOS is doing something to the KB controller when you set the mouse option. The command byte on my system shows the mouse support on the kb controller is disabled. I wrote a quick basic program, and I still get 1C. I'm not able to change the bits for whatever reason though.

What does the command byte read on a system with a working ps/2 mouse?

Programming delays are required for reading and writing the KBC. Probably the value 1C is not the value of the command byte, but rather the controller status register.

This page explains the delay: http://www.computer-engineering.org/ps2keyboard/
But I haven't been smart enough to get it working yet.

Its likely the controller gets programmed to enable the mouse interface+interrupt by setting _EN2 = 0 and INT2 = 1. The 1C value is the status register.

What are these magical _EN2 and INT2 values you speak of?

*edit*, ah I see. These are the official names of the bits in the command byte. Alright. So how do we turn them on? I'm going nuts from playing with machine code and trying to get that stupid wait loop working. I'm getting really tired of coding my ass off and getting back "1C".

It is possible for me to tell the keyboard controller to enable the mouse interface without programming the command byte by sending A8h to port 64h. However, without being able to read the command byte I have no idea if it actually is enabled or not. That probably doesn't enable the mouse IRQ either. The only way I know of getting at that setting is by setting command byte bit 1 to 1.

One doesn't have to use ASM to do this, C or Pascal could do it too. I don't have any DOS development tools on hand though.

I tried to do this in QuickBasic 4.5. I don't have the exact code at the moment, but it looked something like this

10 CLS
20 OUT &H64, &H20
30 i = INP(&H64)
40 IF i AND &H2 THEN GOTO 30
PRINT hex(&H60)

I couldn't get a proper reading of the command byte. Probably something wrong with my use of the AND operator.

ASM version.
in al, 64h ; Read Status byte
and al, 10b ; Test IBF flag (Status<1>)
jz WaitLoop ; Wait for IBF = 1
in al, 60h ; Read input buffer

I played around with QBasic and reading/writing ports. I had enough of it since nothing seems to work right, even when flushing the output buffer. Just sending the AAh test command causes problems, the machine loses keyboard input! None of the other commands seem to work at all including the enable/disable keyboard commands.

Anyway, the steps an OS uses to detect a PS/2 Mouse are documented here.
http://wiki.osdev.org/%228042%22_PS/2_Control … .2F2_Controller