I'm running CuteMouse 2.1b4.

Mem already reports less than 640k of RAM on my EISA machine. The cause is the LBA option ROM on my IDE controller using the top 2k to store the drive parameters. DDOs like EZDrive install in memory using the same system. That note specifically refers to a MR BIOS, AMI and Award doesn't appear to use the EBDA as I have never seen a PS/2 mouse equipped machine report less than 640k.

Regarding Int 15h c2h, it would be nice to get a clear answer if all BIOS with PS/2 mouse support it. Some are doubting its available on all machines. It basically wraps all those i8042 commands in a neat easily accessible package. Well at least that is what it looks like gleaming over VirtualBox's source code: http://www.virtualbox.org/svn/vbox/trunk/src/ … BIOS/ps2mouse.c

Then there is ReactOS. I love the comment on the top, now I know why the keyboard magically re-enables itself after sending the "disable" command. Every step of the process involves flushing the input and output buffers. i8042MouseDetect() pretty much does what we have been trying to do in QBasic. It also doesn't involve the Int 15h functions or reading the equipment byte with Int 11h. Why? Because those services aren't available in protected mode. BIOS Interrupt services are only available in real mode. If anything, getting the mouse working in DOS is going to be harder than something like Windows NT or Linux.

<http://svn.reactos.org/svn/reactos/trunk/reac … 750&view=markup>

I'd say this is worth revisiting once you get an EPROM burner and try the AMI Enterprise III BIOS. At least it will provide a working mouse under all operating systems, not just DOS.

The IBM PS2 used the EDBA for the mouse. Int 15h seems worth looking into to me.

I tried cutemouse 2.1b4 just to be safe. Still nothing.

I think there are still some quirks in my adapter. It may be caused by lousy soldering. I am pretty busy this weekend, but when I get around to it I'm going to rebuild the circuit on breadboard and try the DTK system out again with my new weapons.

CuteMouse is definitely using Int 15h for detection. Older versions only used Int 15h to detect, but drove the mouse directly. According to the version history, it switched to using Int 15h for all operations with v1.72.

Also, do you have a parts list for the adapter? Specifically, what value capacitor and resistors did you use? I'd like to try building one myself.

You need two 47pf capacitors and two 10k ohm resistors, and a 7406 IC. It's a pretty simple circuit.

I recommend building on breadboard first.
If you can get it going, you can try building an adapter with prototype board, machine pin legs and a 40pin DIP socket. It's a real bitch to solder though.

What exactly is cutemouse doing with int 15h? It offers quite a number of services. I would guess Cutemouse uses it to check for the presence of the EBDA.

http://stanislavs.org/helppc/ebda.html

I wonder how the BIOS allocates the EBDA.

I found a hint: "The standard way of doing this is to lower the Free Base Memory pointer
at address 0x413 and keep a pointer in your ROM area"

Okay. If you run DEBUG and type e 0040:0013 7f it will set aside 1kb of conventional memory. Now we just need to figure out how to get int 15h to use it.

More useful information on int 15h:

http://www.ousob.com/ng/masm/ngbd820.php

After setting aside 1kb of conventional memory, I tried running Int 15h C1 to see what it said about EBDA. It did not find one. I wonder what we have to do to get it report a postive. Most likely the cutemouse driver is using the Int 15h service to check for the EBDA before loading.

I found this:

- word at BIOS Data Area 40:0E is segment address of EBDA

Perhaps if we write the address at this address we can get int 15h to see it.

I think the correct value should be FCh. I will try it and see what happens.

Here is a layout for EBDA specific to AMI BIOS as found here: http://oopweb.com/Assembly/Documents/InterLis … lume/MEMORY.LST

0040:000E

Format of Extended BIOS Data Area (AMI v1.00.12.AX1T):
Offset Size Description (Table M0004)
00h BYTE length of XBDA in kilobytes
01h 15 BYTEs reserved
17h BYTE number of entries in POST error log (0-10)
18h 10 BYTEs unused???
22h DWORD Pointing Device Driver entry point
26h BYTE Pointing Device Flags 1 (see #M0002)
27h BYTE Pointing Device Flags 2 (see #M0003)
28h 8 BYTEs Pointing Device Auxiliary Device Data
30h 13 BYTEs ???
3Dh 16 BYTEs Fixed Disk parameter table for drive 0
4Dh 16 BYTEs Fixed Disk parameter table for drive 1
5Dh 16 BYTEs parameter table for drive 2???
6Dh 16 BYTEs parameter table for drive 3???
80h 56 BYTEs? IDE drive 0 manufacturer/model string
B8h 41 BYTEs AMIBIOS copyright string
E1h unused???
102h WORD ??? flags
bit 15: ???
108h WORD offset of IntelIDECfgTbl (IDE configuration settings) within
segment F000h
10Ah 2 BYTEs ???
10Ch DWORD pointer to routine to call for language-specific error messages
110h WORD offset in segment F000h of end of currently-loaded optional
BIOS subsystems (language, APM, etc.)
112h WORD offset in segment F000h of end of area avaiable for loading
optional BIOS subsystems
1F0h BYTE APM status flags
1F1h 8 BYTEs APM power-state data for device classes 01h-06h
bits 0-3: current power state for devices 00h-03h in class
bits 7-4: current engaged state for devices 00h-03h in class
1F9h 4 BYTEs APM power-state data for device classes 01h-08h (four devices
per class)
1FDh 3 BYTEs ???
200h 10 WORDs POST error log
214h ???
SeeAlso: #M0001,#M0005

That memory is likely used by BIOS Int 15h mouse routines. The 06/06/92 core likely has a different map since it doesn't have things like APM.

I would guess that AMI probably did not move things around in the EBDA with each BIOS release. The 06/06/92 core is probably missing many of the things from the map I posted above, but the things it does have are likely in the same places (ie mouse scratch pad). Notice how the mouse stuff is the first to appear in the list? Probably they just kept tacking stuff on to the end with each BIOS release.

I tested my adapter again on the R418 PCI board, and as I suspected something went bad. The system no longer boots with it installed. I think I made a fatal error during the installation of the socket, so I'll have to build a second one (it's easier than fixing the old one). At least now I know the weaknesses in my design and can improve.

Secondly, I was reading that FreeDOS apparently relocates the EBDA on boot to the regular conventional memory area, and it suggested that other modern versions of DOS did the same. I wonder how to figure out exactly where it went.

My R418 board does not have an EDBA present at the top of conventional memory with PS/2 mouse support enabled. Obviously the mouse driver needs this scratch pad area, so it must exist somewhere.

Sometimes EBDA is referred to as XBDA or in Microsoft's case "EBIOS"

http://support.microsoft.com/kb/135481/EN-US

http://www.malinov.com/Home/sergeys-projects/sergey-s-xt

This guy built a PS/2 mouse into his XT board. Maybe we can ask him what to do...

This is from his BIOS source code:

;=========================================================================
; Extended BIOS data area variables
;-------------------------------------------------------------------------
ebda_size equ 0h
mouse_driver equ 22h ; 4 bytes - pointer to mouse driver
mouse_flags_1 equ 26h
mouse_flags_2 equ 27h
mouse_data equ 28h ; 8 bytes - mouse data buffer

;=========================================================================
; reserve_ebda - reserve EBDA (Extended BIOS Data Area) if using PS2_MOUSE
; Input:
; AX = memory size in KiB
; Notes:
; - Assumes that EBDA memory was cleaned
; - Does not reserve EBDA if PS/2 auxiliary device is not detected
;-------------------------------------------------------------------------
reserve_ebda:
%ifdef PS2_MOUSE
push ax
push cx
test word [equipment_list],equip_mouse
jz .no_mouse
mov ax,word [memory_size] ; get conventional memory size
sub ax,EBDA_SIZE ; substract EBDA size
mov word [memory_size],ax ; store new conventional memory size
mov cl,6
shl ax,cl ; convert to segment
mov word [ebda_segment],ax ; store EBDA segment to BIOS variable
push ds
mov ds,ax
mov ax,EBDA_SIZE
mov byte [ebda_size],al ; store EBDA size to EBDA
pop ds
push si
mov si,msg_ebda
call print
call print_dec
mov si,msg_kib
call print
pop si
.no_mouse:
pop cx
pop ax
%endif ; PS2_MOUSE
ret

setloc 8000h ; Use only upper 32 KiB of ROM

Looks like the BIOS only setups up the EBDA if it can detect a PS/2 mouse. That might explain why I can't see it on my R418 with modded BIOS with no PS/2 mouse installed (adapter is fuxated). Looks like I was more or less correct about where things should be though.

http://www.vintage-computer.com/vcforum/showthread.php?23740

He posts on VCF.

Some notes on PS/2 mouse compatible keyboard controllers: http://www.vintage-computer.com/vcforum/showt … 7310#post167310

Taking a look at the BIOS source, the EBDA is used by the PS/2 Mouse Int 15h function in the BIOS to store variables. Once the adapter is confirmed working, I see no reason why it wouldn't work with a protected mode OS like Windows NT without BIOS support.

I never doubted it would work with a protected mode OS. I just haven't tried because I have limited resources at the moment, and my interest is primarily DOS. I'll be ordering a new SCSI HDD shortly so that will give me a chance play around with other OSes. I think NT4 is next on the list.

It think I found one of the keys. It's in Int 15 C207h This points the device driver to the EBDA. We also need to point int 74h to the EBDA.

8042 interrupts systems on IRQ 12.
− IRQ 12 is handled by INT 74h ISR.
− INT 74h ISR collects data package, storing the information in the
CBIOS Extended Data Area. [EBDA[2]]
− INT 74h pushes pointing device data onto the stack and calls the
pointing device's device driver.
− The address of the pointing device's device driver must be stored in
the CBIOS Extended Data Area by Function C2h, Subfunction 07h Device

Subfunction: AL = 07h Device driver far call initialization =-

This subfunction stores the device driver segment address in the CBIOS
data area at 22h and the device driver offset address at 24h so that
the device may be accessed.

Input:
AH = C2h
AL = 07h
ES:BX = Device driver segment and offset address.
Output:
AH = 00h No error
= Error status (40:41h)

I'm not totally clear on how to set 74h, because I lack documentation. But we need to tell it four locations in the EBDA.

I've been going over the BIOs source code, and it seems like I already took all the right steps to enable the EBDA. however, I did screw up setting the segment address of the EBDA at 0040:000E. It's actually 2 bytes long, and should be 9F C0.

Here's what the procedure I'm using so far: (still not working)

-use QBASIC program to set KBC command byte to a value of 47h (bit 5 low, bit 1 high)
-[debug] E 0040:0010 67 (set equipment bit for PS/2 mouse present)
-[debug] E 0040:0013 7F (set aside 1kb for EBDA)
-[debug] E 0040:000E 9F (EBDA memory pointer)
-[debug] E 0040:000F C0 (EBDA memory pointer)
-[debug] E 9FC0:0000 01 (set EBDA size to 1kb)
-use QBASIC to call INT 15h C2H bit 0 (PS/2 mouse support present)
-use QBASIC to call INT 15h C2H bit 5 (initialize PS/2 mouse)
-Run MOUSE.COM /Z

I'm not 100% certain yet, but it seems like the PS/2 mouse driver is supposed to use INT 74H to set the mouse driver address in the EBDA.

--edit--

This is interesting. After I write to 9FC0:0000 something is undoing my entry. I wonder what it could be...

Is the BIOS responding to Int 15h,C2h commands? That would be my only concern, because if the code isn't there or enabled, setting the bytes isn't going to do much.

It *seems* to be responding. But I'm not sure how to check the carry flag yet.

Something unrelated but interesting. It seems EMM386 moves the EBDA to upper memory, and DOS7 IO.SYS moves the EBDA to lower memory. So, this might be why my writes to 9FC0:0000 are being invalidated.

http://www.rockymtncs.com/FAQS/mem_command_re … s_than_640k.htm

Additionally, this seems to imply that the two bytes that represent the EBDA address at 0040:000E should be reversed.

I wouldn't try editing memory in V86 mode, this stuff is real mode only. Its likely the MMU is trapping the writes as opposed to altering the bits.

I'm just running pure DOS (PC DOS 2K) with nothing being loaded in the system files.

I can't figure this one out. Any other theories on what's causing this behaviour?

I tried booting upwith MS-DOS 7.x, and there is no problem modifying 9FC0:0000. I'm not sure what's going on with PC-DOS 2K, but I'm intent on figuring it out.

So, with the EBDA size bit set to 1KB the EBDA is *STILL" not being picked up by INT 15h C1. I really need to figure out why, because the mouse driver likely calls INT 15h and checks for the EBDA and aborts if not detected.