usb joysticks

The intent of this forum is to discuss my DOS TSR programs (available at http://bretjohnson.us), how they work and don't work, new/missing features, status of updates, and anything else related to them that may need to be discussed.

Re: usb joysticks

Postby watlers world » Thu Mar 01, 2012 3:49 am

how does usbjstik provide support for 8 joysticks?

using the segment I get from globaldosalloc
lpRealModePtr := (segment shl 16);
or less simply put
lpRealModePtr := longint(MAKELONG(0, segment));

the 32bit DataAddress is supposed to point at...
a second 64 byte structure?

to get simple joystick data
will I have to provide a code address(function handle)?

Dinosaur gave me some example code
and said I could share it as I like
its mostly asm
would you care to host it?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Thu Mar 01, 2012 6:02 am

watlers world wrote:how does usbjstik provide support for 8 joysticks?


USBJSTIK allows up to 8 joysticks to be attached. However, because of the limitations in how the joystick BIOS interface works (max 4 axes and 4 buttons), you can't actually use all of the USB joysticks at the same time. You have to select which USB joystick axes and buttons (from each of the eight possible joysticks) you want mapped to which of the limited number of joystick BIOS axes and buttons, using the /M option in USBJSTIK. Like I said earlier, if there was an existing multi-joystick API that was adequate, I would support it. I've done a lot of research, though, and have never found an existing API that didn't have some MAJOR problems.

watlers world wrote:to get simple joystick data
will I have to provide a code address(function handle)?


To get "simple" joystick data, you can use the joystick BIOS, which is what you started out doing. But, in that case, you'll always be limited to 4 axes and 4 buttons, and will be forced to live with the USB-to-BIOS mapping as provided by USBJSTIK.

What you've been working on lately is bypassing the joystick BIOS and interfacing directly at the USB level. This is MUCH more complicated, but will give you complete control over as many USB joysticks as you want.

If you want to control a joystick directly using USB, you will need to go much further than you have so far. You will actually need to download several different pieces of data (called Descriptors) from each joystick, decode the data contained in the descriptors to determine the unique USB/firmware and physical characteristics of each joystick, register with the USB software (USBUHCIL) so it knows that you are the joystick "owner", and issue a periodic interrupt request so that the joystick will inform you automatically when something has changed (a button pressed or an axis moved). As stated earlier, the process that starts with "LookForNewDevice" in the source code for USBJSTIK provides an example that shows you how to do all of this -- and it's not trivial. Also FYI, it's when you download the descriptor data or the periodic interrupt data from the joysticks that the USB hardware needs physical memory addresses.

watlers world wrote:Dinosaur gave me some example code
and said I could share it as I like
its mostly asm
would you care to host it?


Send it to me in an e-mail and I'll look at it -- I'm not sure.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Fri Mar 02, 2012 1:13 am

then your description is misleading
usbjstiks does not support 8 joysticks.

looks like callbacks might work
still I have never done any before
so I am just guessing

the 64byte structure wants two words
I14RCallBackAddrOff:word;
I14RCallBackAddrSeg:word;

and what I have is

function AllocRealModeCallbackAddr(CallbackProc : Pointer;
var Regs : TRealModeRegs;
var Callback : Pointer) : Word; Assembler;
asm
push ds
lds si,CallbackProc
les di,Regs
mov ax,0303h
int 31h
jnc @@Exitpoint
xor cx,cx
xor dx,dx
jmp @@ExitPoint2
@@ExitPoint:
xor ax,ax
@@ExitPoint2:
les di,Callback
mov word ptr es:[di],dx
mov word ptr es:[di+2],cx
pop ds
end;


with the "Callback" pointer from this function
the segment would be the high word
and the offset would be the low word
that sound right?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Sat Mar 03, 2012 8:05 am

Yes, INT 31.0303 is the way to get a RM call-back address in DPMI -- that's what Dinosaur used. In memory, Segment is always the high word, offset always the low.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Wed Mar 07, 2012 3:26 am

found some on dpmi callbacks

http://support.microsoft.com/kb/67845

think there is any worry about VMs
or should that part be ok?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Wed Mar 07, 2012 4:12 am

You definitely will need to worry about which VM you are in when the call-back is issued. That's not something that you need to worry about in a simple DOS-based DPMI server (like what Dinosaur did), but it definitely is in Windows. This is somewhat similar to the situation with physical memory addresses: in a simple DPMI server, you can usually assume linear addresses and physical addresses are the same, but in Windows DPMI you can't.

Note that in the example, it talks about TSR code that needs to be installed before Windows loads. The USB drivers (TSR's), at least in their current implementation, don't have any of that code in them, since they are not specifically designed to work with the Windows DPMI implementation. That's something you would need to provide yourself.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Wed Mar 07, 2012 6:43 am

it does look like the the dos tsr has to make shure
that VM 1 (the Windows VM) is active

perhaps usbuhci cannot be used by a win16 dll while in enhanced mode
think win3x in standard mode might work?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Wed Mar 07, 2012 8:00 am

watlers world wrote:think win3x in standard mode might work?


Probably has a better chance of working than Enhanced Mode, though I know a lot of Windows programs (especially the more "modern" programs) required Enhanced Mode. It might also be possible to modify the USB API to accommodate Windows -- I'll have to think about it some more. It could be as simple as setting a flag when the call-back address is provided to indicate that it's a Windows call-back address.

I don't think it's possible for the the USB driver to detect this automatically. It can tell when Windows is running, but I don't think it can automatically tell whether a specific API request came from Windows or came from somewhere else (another TSR or another DOS program).
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Wed Mar 07, 2012 8:38 am

I'll set windows to start in standard mode

there might be some sort of support under standard mode
I get errors under the name of the windows dll

I'll take some time and test different possible callback functions

thanks for the help
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby watlers world » Fri Mar 09, 2012 1:29 am

figured out how to setup a callback that usbuhci likes

though I cant use windows memory or functions from the callback
it allows me to change port values
so I can make a beep or mess with the lpt port on the event

http://win31.no-ip.org/freeware/program ... pend~1.rtf
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Fri Mar 09, 2012 3:56 am

That's too bad. I think for what you're ultimately trying to accomplish you actually need to process some Windows functions during the call-back??
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Fri Mar 09, 2012 6:37 am

the same callback works in enhanced mode

if you switch to a windows dos box then the callback causes windows to shut down
looks like dos boxes are the other VM's

windows 3.1 uses a non-preemptive scheduler "cooperative multitasking"
it does not usually interrupt programs or drivers

none of my windows 3.1 joystick drivers are driven by callbacks
data is requested when needed

if I can send commands to usb
and I can allocate a dma buffer
can I still get usb joystick data?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Fri Mar 09, 2012 7:51 am

watlers world wrote:looks like dos boxes are the other VM's


That's exactly right. Only DOS boxes have VMID's other than Windows itself. Windows applications have the same VMID as Windows. From what I understand, a Windows application is sort of like an "extension" to the OS, not really a separate application. *nix does not work this way -- it provides a true isolated environment that the application runs in. Note that this is purely based on what I've been told -- I don't know enough to make such statements with any authority.

watlers world wrote:none of my windows 3.1 joystick drivers are driven by callbacks
data is requested when needed

if I can send commands to usb
and I can allocate a dma buffer
can I still get usb joystick data?


Yes, you can. Legitimate callback addresses are only REQUIRED when you register as an owner of a USB entity (e.g, a specific joystick interface). This will prevent other drivers from trying to manipulate the device at the same time you are using it. Even when you register, though, the callback address doesn't really need to do anything useful -- it can simply be a RETF OpCode. You can figure out everything you should need to know by polling rather than callbacks -- callbacks are must faster and easier, though.

You don't actually need to provide a legitimate callback address at all to simply request data from a USB device. When downloading (or uploading) data from a device, the USB driver will accept a "bogus" address (one with a segment of 0000h, or an offset of FFFFh, or both), but recognizes that the address is bogus and won't ever actually try to call it (which would likely crash the computer). You can provide a "legitimate" callback address that is simply a RETF OpCode in this case, also.

If you don't provide a callback address, though, you are not informed when the transaction has been completed (which will usually take at least several milliseconds, and possibly much longer than that). In the case of receiving data, the usual solution is to pre-fill the buffer with some bogus data that you know will not match the real downloaded data, then issue the transaction, then keep looking at the buffer to see when it's changed. If you're trying to send data to a device, there's no way to know when the transaction is complete without a callback.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Fri Mar 09, 2012 9:31 am

I have callbacks working
and perhaps you can do somthing other than I/O ports with them
but I dont know what mode the callback actually occurs in

Q67845 says its for 3.0 and 3.1
3.1 wont work under real mode
must have been some obscure use for it under 3.1

now to figure out if I can do dma
found an example (sound drivers use vds/vdma services)

and the packet functions are next I guess...
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Fri Mar 09, 2012 10:27 am

watlers world wrote:if you switch to a windows dos box then the callback causes windows to shut down
looks like dos boxes are the other VM's


I think we can work around this problem with the simple API addition discussed earlier. If you can get all of the other parts figured out (like DMA), you may have a generally viable solution for USB in WIN3.x.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Mon Mar 12, 2012 6:41 am

(using windows with virtual memory disabled)
ftp://ftp.microsoft.com/misc1/DEVELOPR/ ... 4/7/29.TXT
ftp://ftp.microsoft.com/misc1/DEVELOPR/ ... 3/9/37.TXT

think I have the M$ GlobalDOSAlloc quotes I need

"GlobalDOSAlloc() allocates memory within the first 1 MB range"
"the linear address can be programmed into a virtual 24-bit DMA controller"
"Memory allocated in standard mode is physically contiguous"

this is what is needed for DMA right?

thanks for the help
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Mon Mar 12, 2012 5:00 pm

It looks like that's the answer. It also talks about how to do it in Enhanced Mode, so you won't necessarily need to stick tod Standard Mode.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Thu Mar 15, 2012 2:11 am

as I try to figure out somthing I can test dma with...

I dont know much about asm
before I attempt to decipher anything
I'm trying to translate structures and variables that are used
let me see if I am anywhere close...

;----------------------------------------------------------------------------
;Get Report Descriptor
;----------------------------------------------------------------------------
GetReportDescrReq:
DB SRRTIn+SRRTTypeStandard+SRRTRecipInterface
DB SRRQGetDescriptor
DB ? ;Report ID
DB DescrTypeHIDReport
DB ? ;Interface Number
DB 0
DW ? ;Number of Bytes

blocks such as this one
fill in pointer structure data
at a pre set index ?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Thu Mar 15, 2012 4:10 pm

The data you are looking at is an 8-byte control setup packet. Control requests are one of the four types of requests that USB allows (the other three being Bulk, Interrupt, and Isochronous). Control requests always include an 8-byte setup packet. When you issue the request to the driver with a 64-byte request structure and the request type is Control (I14RRequestType = I14RRTDoControl), you must embed the 8-byte control setup packet in the 64 byte structure at the offset called I14RSetupReqData.

In my code, I copy an 8-byte request packet "template" into correct offset of the 64-byte structure, and then fill in the request-specific parameters of the control setup packet. In the example you show (to download an HID Report Descriptor for a Joystick), the request-specific parameters are the Report ID, Interface Number, and Data Size.

A Control request involves either two or three separate stages. In the Setup Stage, the 8-byte setup packet is sent to the device. You don't need to provide a physical memory address for this stage. If the data size (the last two bytes of the control setup packet) is not 0, the second stage is called the Data Stage, and is where additional data is sent to or from the Device. In the specific example you provided, this is where the actual HID Report data is transferred from the device into memory using DMA (and where a physical memory address is needed at offset I14RDataAddress in the 64-byte request structure). The final stage is called the Status Stage. The driver handles the three stages pretty much automatically -- you just need to provide the 8-byte control setup packet, and the memory address for the data stage (if there is a data stage).
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Sat Mar 17, 2012 1:11 am

RegIntfOwner
DoControl
CloseHandle
UnRegIntfOwner
(no errors at all)

after I setup an 8 byte packet

RegIntfOwner(no error)
DoControl(no error)
-call back occurs-
CloseHandle(invalid handle error)
UnRegIntfOwner(no error)

I made the callback set a port value so I can tell if it was called

with ?
"DB ? ;Report ID"
does not set the byte and is for placement?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Sat Mar 17, 2012 3:41 am

watlers world wrote:call back occurs-
CloseHandle(invalid handle error)


An error here is expected. CloseHandle is only needed when you are trying to shut down a request that is currently in progress. After a Control or Bulk or One-TIme-Interrupt transaction has completed (the call-back has occurred), the transaction is automatically closed. Periodic-Interrupt and Isochronous transactions are different, because they are periodic (they issue multiple, periodic call-backs) so must be closed manually. All transactions are also closed automatically when appropriate, such as if a device is unplugged or reset.

watlers world wrote:with ?
"DB ? ;Report ID"
does not set the byte and is for placement?


You usually put Report ID 0 in there -- 0 means "All Reports".
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Sat Mar 17, 2012 9:20 am

Being new to both DMA and USB
I'm uncertain if I have either setup properly...

What would be the simplest set of actions that should result in a data
transfer to the I14RDataAddress?

An example like usbdevic of USB using DMA would be usefull.

thanks for the help
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Sun Mar 18, 2012 3:26 am

Probably the simplest transaction would be a Get Device Descriptor control transaction. In the source code for USBJSTIK, this Get Device Descriptor request is initialized in the AltIntfSet: routine, and the call-back is handled by the GotDeviceDescr: routine. In the currently released version of USBJSTIK, though, the I14RDataAddress is Segment:Offset, not Physical. It doesn't need to be since the host driver (USBUHCIL) is able to translate the segment:offset address to a physical address. However, USBUHCIL can only do this if the calling program (USBJSTIK in this case) is installed before Windows. Once Windows comes into play, memory management is completely different and USBUHCIL can't do the translations any more.

The only difference between how USBJSTIK does it and you do it from Windows would be that you would put a physical address in I14RDataAddress and set I14RFlagAddrIsPhys.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

Re: usb joysticks

Postby watlers world » Sun Mar 18, 2012 6:46 am

windows 3.1 (running in standard mode with VM off)
requires no vxd files to run
and has no virtual memory
When windows starts it takes hold of all availible memory below 1mb.
Globaldosalloc gives out this memory sort of like dpmi would
(vds is version 1)

looking at http://win31.no-ip.org/freeware/program ... dosmem.zip
globaldosalloc only gives a segment
and from that I can create a linear 32bit address (seg,ofs)
(usbuhci can read/write this memory)

"
It is also possible for applications running in standard mode Windows to perform
DMA without using VDS. This is because in standard mode, the linear address is
the same as the physical address, the memory is contiguous, and memory
addressing is limited to 24 bits (the 16 MB address space limit of the 80286
processor). Also, there is no virtualization on the DMA I/O ports, or other I/O
ports in standard mode. The Windows-based application should obtain the linear
address of the DMA region and program the DMA directly.
"
this type of memory address is no good?
or you think 3.1 standard mode works differently?
watlers world
 
Posts: 113
Joined: Sat Feb 04, 2012 3:08 am

Re: usb joysticks

Postby Bret » Sun Mar 18, 2012 8:46 am

If what you are saying is indeed true (linear and physical addresses are always the same), you can simply do the calculation and tell USBUHCIL that you are providing a physical address. FYI, the way USBUHCI translates segment:offset to physical addresses uses VCPI, which doesn't work under Windows -- at least in Enhanced Mode. I do know that when EMM386 (or some equivalent) is running, the CPU is running in protected mode and the addresses above 640k (UMB's) are NOT linear = physical. Windows (even in standard mode) must "preserve" the memory mapping that was present before it loaded. I'm not exactly sure how Windows does this in standard mode.
Bret
 
Posts: 478
Joined: Fri Oct 10, 2008 3:43 am
Location: Rio Rancho, NM

PreviousNext

Return to Programs

Who is online

Users browsing this forum: No registered users and 1 guest

cron