usb joysticks

[watlers world]

perhaps it might better to test some cheaper controllers first?
I would not be messing usb stuff if I had not had some given to me

is the int 14api api stuff of any use at all
to a protected mode program?

looks like I've got
AX,BX,CX,DX,SI,DI

dont know about CF....

turned on dosuhci
from win3x set regs as said and
called int 14 and got
ax=00000000
bx=00004221
cd=00005553
dx=000046AF
si=00003A5F
di=00000D30


will ctmouse use the 3 buttons?
as I recall the 3 button sw driver uses it

[Bret]

perhaps it might better to test some cheaper controllers first?

It certainly would. For my testing, I have purchased a few inexpensive gamepads & joysticks.

I would not be messing usb stuff if I had not had some given to me

Well, I must say I admire your ambition. I need to warn you that you're headed down a long, lonely, arduous road if WIN 3.1 is your target platform. Are you really sure you want to commit to that?

is the int 14api api stuff of any use at all
to a protected mode program?

I think you've answered your own question below -- you've correctly called the installation check and it responded just like it should.

looks like I've got
AX,BX,CX,DX,SI,DI

dont know about CF....

turned on dosuhci
from win3x set regs as said and
called int 14 and got
ax=00000000
bx=00004221
cd=00005553
dx=000046AF
si=00003A5F
di=00000D30

The USB INT 14h API currently only uses AX, BX, CX, DX, flags, and DS. It doesn't use DI, SI, BP, or any of the other segments (ES, FS, GS), though a future version might use ES. I think you can get by without the flags if you can't figure that part out, since it always returns error codes in AX so CF is somewhat redundant (but using CF allows the code to be smaller and more efficient).

Like I said earlier, the INT 14h part shouldn't be a problem. The real problems are going to be that you must be able to provide real mode (somewhere in the first MB) memory pointers for parameter passing and call-back addressing, and physical memory addresses for the PCI data transfers. If you can figure out how to do those things from within Windows, you can use the USB INT 14h API to do almost anything you want on the USB bus.

However, keep in mind that using the USB INT 14h API is MUCH more complicated than using BIOS interfaces for the devices (mice, keyboards, joysticks, printers, etc.). But, doing so allows you to use all of the capabilities of the device, rather than limiting it to the features supported by the BIOS.

will ctmouse use the 3 buttons?
as I recall the 3 button sw driver uses it

CTMOUSE supports three buttons, and also supports one wheel. There are other DOS mouse drivers besides CTMOUSE, but it is the only one that supports a wheel, and also the only one that is still under development and may eventually add additional features. The BIOS supports up to five buttons and two wheels, and CTMOUSE may eventually be updated to support that as well.

[watlers world]

I use delphi (T/B Pascal)

using win16 I know you can lock global memory to get pointers
you have to lock mem to let other win programs use it
think they are called long pointers
no idea if they are real or not

dynamicly loaded dll functions use them

the only thing I've found problems with were some mem[] commands
is the memory I need to get below pm (640k?)

if not...
would it be possible stuff the "protected" memory into int 15?

if win16 is talking via ints
then I can use any usb data you can give me this way

I'm using win3x in enhanced mode on win98 dos
really should test on some other setups

[Bret]

I'm not familiar with any type of Windows programming, so can't help you a lot. I'll tell you what I know about DOS, both from personal experience and what others have told me.

If you allocate an XMS memory block and then lock it, the XMS host will tell you what the physical address is.

VCPI will tell you the physical address of any block in the first MB, even if the physical address is "dynamic" (such as when using EMS).

DPMI has specific calls to allocate data and call-back memory blocks in the first MB of memory.

Most,if not all, DOS-based DPMI hosts will map memory so that physical addresses and linear addresses are the same, so you can many times assume that the linear addresses returned by the DPMI server are the same as the physical addresses. I'm not sure this is true under Windows, though.

**********

if win16 is talking via ints
then I can use any usb data you can give me this way

The issue isn't so much in getting the data from the USB driver to you, it's in getting it from you to the driver. There's simply too much information needed to issue a USB Request to fit in a few CPU registers, so you must pass a pointer (DS:DX in the first MB) when you call INT 14h to a structure that contains all of the appropriate details. When the USB driver issues call-backs (in the first MB) to inform you of something that has happened (e.g., a device was just unplugged), it just uses the CPU registers (AX, BX, CX, DX). AX contains a code that tells you what happened (e.g., "Device Unplugged"), and BX, CX, and DX contain specific details (e.g., the USB address of the Device that was just unplugged).

[watlers world]

is the memory space directly used by usb
or info that your driver needs to redirect?

would it be better to have the rm driver create
the variables needed hand out handles
and just have the pm program fill the data in?

from a pm perspective its best to use all memory over 1mb

can your driver use xms?

[Bret]

is the memory space directly used by usb
or info that your driver needs to redirect?

Both. The physical addresses that you provide is how the data is transferred to and from the USB device itself, e.g. the button and movement/axis data from a joystick or a mouse.

There is also "control" data that goes to the USB Host, which is what the USB host driver handles for you. The INT 14h API provides a simplified interface, but the driver internally handles all of the complicated timing and scheduling and interrupt and error issues it takes to manage the USB Host Controller and bus. When you issue an INT 14h request, the driver extracts the data it needs from the structure (DS:DX), stores it internally, and then does what it needs to do. After the extraction has occurred, the structure (and the memory it uses) aren't needed any more, and your program can release the memory and go about doing other things. The bus transaction is managed entirely in the background, so you don't necessarily need to sit around waiting for it to finish. When the bus transaction is complete, the driver informs you (via the call-back address provided in the original structure) that it is done. If any data was transferred from the USB device, it will be in the physical memory address (another parameter that was provided in the original structure).

would it be better to have the rm driver create
the variables needed hand out handles
and just have the pm program fill the data in?

I considered that in the beginning, but decided it was a REALLY bad idea. That's what memory management specs are for (EMS, XMS, VCPI, DPMS, DPMI, etc.). In addition, even if memory blocks could be provided for data selectors, code selectors (call-back addresses) are much more problematic (write protection, switching in and out of PM, PM16 vs PM32, etc.). It turns into a big, ugly mess and I'm not going there.

from a pm perspective its best to use all memory over 1mb

True, but you can only do that if your environment (Windows) provides every service you will ever possibly need or want. If it doesn't, and you need to use a lower level service (BIOS or DOS), you must interact with addresses below 1MB. That's something you just need to learn to live with (like ASM) when you're working with device drivers and hardware. If you're writing applications instead of drivers, you usually don't need to worry about these kinds of things.

can your driver use xms?

Not directly.

[watlers world]

pci memory addresses are the only problem then?

and USBJSTIK is not just bios based support
but a driver?

[Bret]

pci memory addresses are the only problem then?

If by "pci memory addresses", you mean physical memory addresses, then from your perspective I think the answer is yes,

and USBJSTIK is not just bios based support
but a driver?

It is a DOS driver that emulates the standard BIOS INT 15h joystick support. I also added the I/O virtualization since, unfortunately, a lot of DOS programs don't use the joystick BIOS even when they should. There's an old rule of thumb that most people either never knew or forgot -- use the highest level service that provides the functionality you're looking for. If the environment (Windows) provides an API, use it. If not, and the OS (DOS) provides an API, use it, If not, and the BIOS provides an API, use it, Direct hardware access should only be used as a last resort.

The USB host drivers (USBUHCI & USBUHCIL) are also installed as DOS drivers (TSR's), but the API (INT 14h) is implemented as an extension to the INT 14h serial (COM) port BIOS. There is no USB API or any sort implemented by any actual BIOS I know of, which is why I developed one. If there was real USB support in the BIOS (some sort of API), programs like USBUHCI & USBUHCIL wouldn't be needed to use USB in DOS -- only programs like USBJSTIK.

[watlers world]

ok then I should use data from usbjstik?

as far as I know all hardware I/O ports are working
and most Interrupts look to work
and I can work with some memory directly

now I have to get memory from an exact memory range
would this be the same as the memory ranges that
Craig Harts dos pci program shows for each pci card?

I'm not to good with the jargon involved... perhaps this might help
http://books.google.com/books?id=F868yP ... dcw8&hl=en

[Bret]

ok then I should use data from usbjstik?

That is definitely be the easiest, but whether it's the right" thing to do or not depends on your ultimate goal. If you're really intent on doing a fairly complete implementation of USB, you'll eventually need to learn how to do all of this "hard stuff" anyway (including probably writing VxD's). If you're content to piggy-back on the BIOS- and DOS-level support that I'm trying to provide, then I think the only "advanced" function you need to figure out is call-back addresses, You'll need those for devices that really need to be interrupt-driven instead of polled, like mice. Eventually I hope to add support for other USB devices like network cards, serial ports, and CD/DVD's, Exactly what kind of interface (API) each will have depends on how it is generally used in DOS. A particular device may need virtualized I/O, a BIOS-level interface, a DOS-level interface, or some combination (e.g., serial ports probably need all three). If your scope is really limited to joysticks, and you really don't want to mess with mice or serial ports or whatever, then I think you're almost done.

now I have to get memory from an exact memory range
would this be the same as the memory ranges that
Craig Harts dos pci program shows for each pci card?

Yes, the memory addresses associated with PCI are physical addresses. In order to access PCI devices, you must be able to somehow map a linear address to a known physical address.

[watlers world]

my original intention was to gain control of more joysticks under win3x

the mmsystem joystick api is limited to x,y,z and b all of word(per joystick)
the new api I setup to handle multiple joysticks
just basicly expands on the classic windows joystick structures(longint buttons)
I'm open to change though

I dont object to making usb drivers if I can figure out how
most stuff likly would not fit old standards though

I used the pci unit from usb4pas to make a test program
if you set register 4 to 6H it stays

I've no clue what I can do
think I'm lacking some reading on subjects

[watlers world]

this sounds like what you were talking about
(int 4Bh)
am I close?

[Bret]

I used the pci unit from usb4pas to make a test program
if you set register 4 to 6H it stays

I have no idea what you're talking about here.

this sounds like what you were talking about
(int 4Bh)
am I close?

Locking memory with INT 4B.81xx (VDS) is another way of obtaining physical addresses, similar in many respects to locking XMS memory. I'm not sure either method will work from inside Windows, though (but I could be wrong about that).

[watlers world]

the jargon I come up with is VDS and VDMAD
I dont know much about either

an old VDS text file from MS
http://www.gaby.de/ftp/pub/win3x/archiv ... pw0519.exe

it says to check bit 5 of $0040:$007B
to see if it is enabled

[Bret]

I've never heard of VDMAD before, but it appears as though that is/was the solution (or at least a solution) Windows provides to get around the problem of determining physical addresses.

I read somewhere (don't remember where) that checking 0040:007B is not a fool-proof method of testing for VDS. In my programs, I just check INT 4B.8102 to see if VDS is installed. That probably won't help you from Windows, though.

Code: Select all

;------------------------------------------------------------------------------
;TEST AND SEE IF VDS ARE INSTALLED (VIRTUAL DMA SERVICES)
;Inputs:
;Outputs: CF = Clear if installed
;            = Set if not installed
;Changes:
;NOTE: Bit 5 at 0040:007Bh is supposed to be set if VDS is supported, but
;        not all systems set this.  INT 4B.8102 is the only certain
;        verification.
;      Int 4B.8102 returns a bunch of information about VDS manufacturer
;        and versions and such, none of which we care about in the program.
;------------------------------------------------------------------------------
TestVDS:
  PUSH AX,BX,CX ;Save used registers
  PUSH DX,DI,SI ;Save used registers
  MOV  AL,4Bh   ;Is Int 4Bh
  CALL TestInt  ;  even installed?
  JZ  >V70      ;If not, VDS can't be installed
  MOV  AX,8102h ;Function 8102h (VDS Install Check)
  XOR  DX,DX    ;DX = 0
  STC           ;Preset the error flag
  INT  4Bh      ;Do it (returns all kinds of stuff)
  JNC >V80      ;If it's installed, jump to set the installed flag
V70:            ;VDS is not installed
  STC           ;Set the not installed flag
  JMP >V90      ;We're done
V80:            ;VDS is installed
  CLC           ;Set the installed flag
V90:            ;We're done
  POP  SI,DI,DX ;Restore used registers
  POP  CX,BX,AX ;Restore used registers
  RET

;------------------------------------------------------------------------------
;TEST AND SEE IF AN INTERRUPT VECTOR HAS A VALID ADDRESS (other than 0)
;Inputs:  AL = Interrupt number to test
;Outputs: ZF = Set if invalid address (all zeroes)
;            = Clear if valid address (anything other than zeroes)
;Changes:
;------------------------------------------------------------------------------
TestInt:
  PUSH AX,BX,ES ;Save used registers
  MOV  AH,35h   ;Function 35h (get Interrupt Vector), AL = Int # to get
  INT  21h      ;Do it (returns ES:BX)
  MOV  AX,ES    ;Put the segment in AX so we can test it
  OR   AX,AX    ;Is the segment valid (set the return flag)?
  POP  ES,BX,AX ;Restore used registers
  RET

[watlers world]

looks like windows vxds use INT 20
VDMAD is a VXD
I found the source code for it in the windows 3.1 ddk
heh its a masm mess

Virtual DMA Specification (VDS) - GET VERSION
works from windows 3.1x

the version is
0003h for Windows 3.x WIN386.EXE

then I guess the windows VDS is similar to
EMM386.EXE (DOS VDS?)

this paper on windows VDS has a bit more
http://gaby.de/ftp/pub/win3x/archive/softlib/vds.exe

now I have a vague idea about VDS
(after about 3 readings)

sofar its mostly cut and paste
thanks

[Bret]

then I guess the windows VDS is similar to
EMM386.EXE (DOS VDS?)

Dunno for sure -- maybe.

now I have a vague idea about VDS
(after about 3 readings)

FWIW, I don't actually used VDS for data transfers. I just use the VDS lock and unlock functions to "translate" a segment:offset to a physical address, and then pass the physical address to the PCI hardware. PCI actually does the DMA in my case, not VDS. Since I'm dealing with addresses in the first MB (segment:offset, not selector:offset), I also use VCPI to determine the physical addresses as a "backup" in case VDS isn't available for some reason.

[watlers world]

the only file I can see
that use the int 4b
is the VDMAD vxd

your int21 code worked for testing int vectors
looks like windows has an api for selectors

Presto Chango Selecto!

UINT WINAPI PrestoChangoSelector(UINT sourceSel, UINT destSel);
UINT AllocSelector(UINT);
UINT FreeSelector(UINT);
UINT AllocDStoCSAlias(UINT);
DWORD GetSelectorBase(UINT);
UINT SetSelectorBase(UINT, DWORD);
DWORD GetSelectorLimit(UINT);
UINT SetSelectorLimit(UINT, DWORD);

Think I found one thing I need
it allocates global memory below 1mb guaranteed

GlobalDosAlloc(Bytes: LongInt): LongInt;
GlobalDosFree(Selector: Word): Word;

[Bret]

I figured there had to be a way to do these things. Good luck with your future testing!

[watlers world]

1.
all right this sounds like what I'm doing
ftp://ftp.microsoft.com/misc1/DEVELOPR/ ... 5/5/45.TXT

2.
and I guess I can use INT 31h DPMI
http://www.experts-exchange.com/Program ... 12878.html

3.
VDS is supposed to be the better method
as it can be used from dos programs(under windows)
and works on win95
cant find any good examples though

[watlers world]

the REAL pointer I create is of LONGINT type

and registers are 16bits
do I have to use 2 of them?

DS:[DX] = Pointer to 64-byte request structure (see below)

humm... looks like....
before an windows 3.1 int is called

86 mode drops to protected mode
http://en.wikipedia.org/wiki/Virtual_8086_mode
and the DS, ES, FS, and GS registers are cleared...

then PM mode drops to REAL mode...
http://courses.engr.illinois.edu/ece390 ... rupts.html

[Bret]

and registers are 16bits
do I have to use 2 of them?

Based on the documentation, Windows returns two integers (words). One is a Selector to use while in PM, the other is a Segment to use while in RM/V86, that both point at the same physical memory (though you don't know where that physical memory is). The size of the memory block is 64k -- it doesn't look like there's a way to allocate a memory block any smaller than that. The first byte of memory in the block will be offset 0, the last at offset FFFFh.

DS:[DX] = Pointer to 64-byte request structure (see below)

So, you can use the 64k block allocated to store the 64-byte structure and pass the segment (not selector) address & offset to INT 14h. This memory block doesn't need a physical address. However, if what is requested in the 64-byte structure involves passing data between your application and a USB device, one of the pieces of the data you put into the 64 byte structure will need to be a physical address.

The other piece you're still lacking is a real-mode call-back address, though you _can_ get by with what you already have. When a "legitimate" call-back address is called by the USB driver (or PS2 mouse BIOS or DOS mouse driver or whatever), this automatically "triggers" a call to a PM subroutine in your application. That way your application is effectively interrupt-driven, and is notified automatically when something happens (e,g., the mouse is moved or a USB device is inserted or removed), Depending on the situation, you can get by without these notifications and simply poll things periodically. You may even be able to get by with that for a mouse, but it certainly isn't optimum. Joysticks are not inherently interrupt-driven anyway, so polling should be fine for them.

If you don't need to be automatically notified when something happens, you can use the same 64k structure you set up to pass the 64-byte structure in. You can, e,g,, use the first 64 bytes for the data structure, and simply put a RETF op-code at offset 65 and use that as the call-back address. In this case, the call-back address doesn't actually do anything useful, but the USB drivers don't care about that. I should also point out that not all USB requests need a "legitimate" call-back address, but some do. If they don't require a legitimate" call-back address, you can set the segment of the call-back address to 0 or the offset to FFFFh (or both), The call-back address for a request is another piece of data provided inside the 64-byte structure.

humm... looks like....
before an windows 3.1 int is called

86 mode drops to protected mode
http://en.wikipedia.org/wiki/Virtual_8086_mode
and the DS, ES, FS, and GS registers are cleared...

then PM mode drops to REAL mode...
http://courses.engr.illinois.edu/ece390 ... rupts.html

Whenever an INT is called, whether from RM or PM, or an IRQ (hardware-generated INT) is issued, the hardware simply calls the PM handler. The PM handler can either process the INT itself and never involve the RM/V86 handler (including virtualization), simply call the RM/V86 handler and let it do everything, or do some pre= or post=-processing before/after it calls the RM/V86 handler. The RM/V86 handler isn't necessarily always called.

[watlers world]

now that I finally have some of the right words to describe the stuff
I found some examples
http://win31.no-ip.org/freeware/programi/dpmi/
now to try and figure them out

with the bios joystick method
when you call INT $15 the second time and get the buttons
MOV DX, $0000
INT $15
MOV btns, AL
is it possible to use more than 4 buttons?







thanks

[Bret]

with the bios joystick method
when you call INT $15 the second time and get the buttons
MOV DX, $0000
INT $15
MOV btns, AL
is it possible to use more than 4 buttons?thanks

You only have 4 bits of data to work with on the buttons, so you can either have 4 independent buttons (any or all of them can be pressed at the sane tine), or you can have as many as 15 buttons, but only one at a time can be pressed. You can enable the /F (Fifteen-button) protocol in USBJSTIK if you want it to use 15 buttons, but then your program needs to interpret the data the same way that USBJSTIK presents it. Unfortunately, there's no way under the current BIOS spec for USBJSTIK to "tell" you which button protocol it's using (4-button or 15-button), Even MULTJOY, at least as discussed in RBIL, doesn't address this.

Like I said earlier, a new flexible and extensible BIOS spec really needs to be developed. It needs to support multiple joysticks, different "kinds" of input (buttons, axes, hat-switches, various kinds of body appendage and joint movements, etc.), and two-way communications to allow for force-and tactile-feedback Unfortunately, it's probably not worth the effort it takes to do that since there will be few (if any) applications that do anything with it.

[watlers world]

looks easy in the gdosmem example
This little piece of code is all there is

void TSR_Request()
{
_asm{
mov ax, 899ah ; Signature
mov bx, 1 ; issue request
mov cx, wSegment ; pass in segment address
xor dx, dx ; offset zero
int 60h
}
}


dpmi-int.zip;
"dpmi.pas"
the delphi example does use the ds register but it before the int 31 call and then
pushes and pops it after the call
and it looks to use cx and dx to pass the address also

"Interrupts section" of this document
http://en.wikipedia.org/wiki/Virtual_8086_mode

can I just use DX,
or do I have to use DS?

since most old uhci computers only have 1 or 2 ports
on those you only need to make the call support a few joysticks
my usb joystick has 7 button inputs
AH is 8 bits right?

how many VR suits do you have?
and how many buttons does your average old used usb controller have?

thanks for the help