I suspect that they are using a cpld , which is programmed to redirect the input pins to the various logic blocks. These logic blocks are set by the windows program. I do this currently with our own i/o boards.I'd guess that what gets downloaded is a little more complicated than a simple bit-map, since each pin can correspond to anything from a simple button to a 12-bit analog-to-digital voltage measurement.
Dinosaur wrote:1. Transaction Request shows DS:DX is required.
Is that the one and only time I need to advise the host of the Struct Address ?
Dinosaur wrote:2. When I use say
.I14RRequestType = 1
.I14RHostIndex = 255
and call the Int, where is the Host software Information placed ?
Is it in the Struct, or is it placed in another buffer.
If so where do I nominate the buffer for Data ?
EDIT: Found the answer to Question 2.
But perhaps you can give me an idea as to which fields of the Struc are essential to be filled in for a simple call like the one above.
I hadn't filled in the DataAddress or DataSize, but sofar this hasnt cured my GPF's
Dinosaur wrote:Have resolved the gpf problems, with the help of a FB Forum member.
Dinosaur wrote:Can you explain what happens to when the PC is powered up in the following manner.
PC Power
FreeDos boots
USBUHCIL installed but usb devices are already attached to ports.
Mouse driver installed, so now driver has ownership of interface
Other drivers installed (not usb)
Application using usb started but usb ownership is not requested immediatly.
-------------------------------------
Does usbuhcil do anything about devices attached that no "ownership has been claimed for".
Are these devices all "Device 0" ? or are they ignored until I register ownership of Device 0 ?
Issue "Find Unregistered Interface" API request
If correct Device/Interface exists, GOTO Done
Write message telling user to plug in the device, press <Escape> to cancel
Loop:
If <Escape> key has been pressed, GOTO Erase
Issue "Find Unregistered Interface" API request
If correct Device/Interface does not exist, GOTO Loop
Erase:
Erase message
Done:
USBDEVIC 0.05, (C) 2008, Bret E. Johnson.
Program to display information about Devices attached to the USB Host(s).
DEVICE ADDRESSES
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Host Index: 0 Host Type: UHCI Bus Type: PCI IRQ#: 10 Root Hub Ports: 2
Vendor: 1106h = VIA Technologies Inc Product: 3038h
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
DEVICES INTERFACES
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
L C I A O
ADRS o P o n l w
ÍÍÍÍ (hex) S o BUS n t t n
Test VEND PROD Sub Pro p USB HUB r POWR f f I e Sub Pro
RWak ID ID Cls Cls col d VER ADR t (mA) g c n DESCRIPTION d Cls Cls col
ÍÍÍÍ ÍÍÍÍ ÍÍÍÍ ÍÍÍ ÍÍÍ ÍÍÍ Í ÍÍÍ ÍÍÍ Í ÍÍÍÍ Í Í Í ÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Í ÍÍÍ ÍÍÍ ÍÍÍ
1 1106 3038 9 0 0 . 1.0 ... . s 0 1 0 0*Root Hub Y 9 0 0
VIA Technologies Inc
ÄÄÄÄ ÄÄÄÄ ÄÄÄÄ ÄÄÄ ÄÄÄ ÄÄÄ Ä ÄÄÄ ÄÄÄ Ä ÄÄÄÄ Ä Ä Ä ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Ä ÄÄÄ ÄÄÄ ÄÄÄ
2 D209 1502 0 0 0 . 2.0 1 1 500 1 0 0*USBSUPT1.COM!! . 3 0 0
Ultimarc? 1 0*USBSUPT1.COM!! . 3 0 0
2 0*USBSUPT1.COM!! . 3 0 0
3 0*USBSUPT1.COM!! Y 3 1 2
ÄÄÄÄ ÄÄÄÄ ÄÄÄÄ ÄÄÄ ÄÄÄ ÄÄÄ Ä ÄÄÄ ÄÄÄ Ä ÄÄÄÄ Ä Ä Ä ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Ä ÄÄÄ ÄÄÄ ÄÄÄ
3 D209 1501 0 0 0 . 2.0 1 2 500 1 0 0*USBSUPT1.COM!! . 3 0 0
Ultimarc? 1 0*USBSUPT1.COM!! . 3 0 0
2 0*USBSUPT1.COM!! . 3 0 0
3 0*USBSUPT1.COM!! Y 3 1 2
I'm not sure you can provide a physical memory address to USBUHCIL,
Dinosaur wrote:Firstly dont take offence at my persistent questioning.
Dinosaur wrote:After many years in design / R&D of machines and systems, I have learned that sometimes we are so familiar with a subject, that we cant see the wood for the trees. Not suggesting this is the case here, but bear with me.
Dinosaur wrote:1.If The device is attached to the bus, and usbuhcil mounts it, does usbuhcil KNOW the linear address. ? If so, then the problem is only letting my application know somehow, with a function call.
EDIT: Just reading your reply again, means this makes no sense.
Dinosaur wrote:2. When I communicate with a Device, my understanding is that it will always be through usbuhcil. I did not think that I would be communicating with the device directly.
Dinosaur wrote:3.Because I am in a closed environment, is there a third party tool that will show the addresses of all the devices attached to the bus. If the placement of these devices is predictable on every boot, then I can hard code these addresses.(or in a config file)
Dinosaur wrote:4.I have the option of using almost any dpmi , but with FreeDos I can also load their EMM386 equivalent.
Dinosaur wrote:In that process I discovered that after a call to get DvcStatus, it recorded an error in
that bit 0 was set (no other bits were set) but yet there was no error code in DX
although there was a Hex65 in CX for last completed stage.
Is the error code related to the last stage, or to the stage that caused the error ?
Edit: Will start a new post for software related questions, as this subject ends up to messy for others to read.Get Device Status Information
Class: Device
Return Type: Immediate
Entry:
I14RRequestType = 43h (I14RRTGetDvcStatus)
I14RHostIndex = Host Index (0-15)
I14RDeviceAddress = Address of Device to get Info for
Return (Success):
CF = Clear
AX = 0
BL = Current Configuration Value for Device
BH = Status Flags Bitmap
Bit 0 (01h) = Set if Device is "Bad" (a problem occurred
during the Reset/Enumeration Process)
Bit 1 (02h) = Set if Device supports Remote Wakeup Feature
Bit 2 (04h) = Set if Remote Wakeup Feature is Enabled
Bit 3 (08h) = Set if Test Mode is Enabled
Bits 4-6 = Reserved (0)
Bit 7 (80h) = Set if Device is currently in the middle of the
Reset/Enumeration process
CL = Last Completed Stage of Reset/Enumeration Process
CH = FFh
DX = Error Code Associated with Last Completed Stage of
Reset/Enumeration Process
6.7 VDS API
The following VDS functions (Int 4Bh, AH=81h) are supported in
protected-mode:
AL Function Comment
-----------------------------------------------------------------------
03 lock region routed to v86-mode with translation of ES:E/DI
04 unlock region routed to v86-mode with translation of ES:E/DI
05 scatter/gather lock handled by HDPMI. ES:E/DI must point to a EDDS.
06 scatter/gather unlock handled by HDPMI. Indeed it is mostly a No-Op,
just the parameters are checked for validity.
07 request DMA buffer routed to v86-mode with translation of ES:E/DI
08 release DMA buffer routed to v86-mode with translation of ES:E/DI
09 copy into DMA buffer routed to v86-mode with translation of ES:E/DI
0A copy out of DMA buffer routed to v86-mode with translation of ES:E/DI
VDS functions 02 and 0Bh-0Ch are routed to real/v86-mode without
translation.
Implementation of function 05 will allow linear-to-physical address
translation for any valid linear address. If an address space contains
uncommitted pages, bit 6 of DX must be set to return PTEs, else the call
will fail.
Functions which are routed to v86-mode with ES:E/DI translation will not
be able to handle linear addresses managed by HDPMI, that is, they might
work for address space 0-110000h only.
Please be aware that if DOS is running in real-mode (no EMM is loaded),
then calling functions other than 05-06 most likely will fail. Therefore
bit 5 at 40h:007Bh should be checked if VDS is available.
unless you can figure out a way to address the same piece of memory with both a segment:offset and a linear address
The other potential issue you'll have is with the "common" memory address used to actually transfer the data
The USB hardware requires a physical memory address, not a linear address
Based on what I've seen regarding DPMI, I'm not sure you can provide a physical memory address to USBUHCIL
You can also provide a segment:offset address to USBUHCIL, and USBUHCIL will translate it into a physical address before sending it to the PCI hardware
However, USBUHCIL can only do this if the CPU is in real mode or in VCPI
Dinosaur wrote:However, USBUHCIL can only do this if the CPU is in real mode or in VCPI
So here is the real question. We dont know if any dpmi will actually switch to real mode
for Int 14 or just emulate it.
The only other question I have then, is the area of memory important.
In other words any block in the first mByte will do ?
That means then, that I can load a small program prior to usbuhcil and reserve a block of memory.
Users browsing this forum: No registered users and 0 guests