Disables Power Button

[Nisse]

Hi, I just discovered that when I use Usbuhcil and Usbmouse the power button makes the system freeze and I have to shutdown the system by holding down the power button for 10 sec.
Sounds like a conflict to me, but I am not sure?
Please help if you have the time.
With best regards John

[Bret]

John:

Sorry I missed this post from a little over a month ago. Not sure what's going on with the power button. I'll try to lookng into it as I update things, but I'm not sure if I'll figure anything out or not. It sounds like it might be some kind of bug in your BIOS which normally monitors the USB hardware for power-related issues and when the DOS USB drivers take over the USB bus but don't take over the power management the BIOS gets confused. That's just a guess, though. BIOSs are used to having Operating Systems like Windows or Linux that take over everything that the BIOS normally does, but DOS can be selective and only take over certain things.

[Nisse]

Thanks for answering mate.
Would be great if you could in the future put in some lines in your code to fix it, Or maybe an option for a different shutdown method..
Anyways I have been testing your driver on old and new machines alot these recent weeks/months and the only thing that sometimes kills the purpose is that
the driver takes alot of memory, not compared to other drivers but still. Most never machines never have more than a few UMBS, like 10-20 kb depending of graphics cards installed etc..
On the BX motherboard I am left with around 70kb UMB, so on thoose your driver is great. But if I was your "god" =) It would be really nice to be able to store the driver in RAM or similair.
On most modern machines even with "trickery" one is left with 670 kb conventional with the RAM option in Emm386. I read in some document that you where thinking about it, hope you get around to it.
Hope all is well, cheers!

[Bret]

John:

Yes, I am working on reducing the memory requirements substantially, by leveraging EMS (Expanded memory) and DPMS (DOS Protected Mode Services) when they are avaialble. I should be able to get the drivers down to only a few kB of conventional or upper memory -- I'm not sure the exact requirements yet, but it should be quite a bit less than 10 kB.

All I can say is don't expect it to happen any time soon -- I have very little time these days to work on this.

[Nisse]

Sounds great, just what we need and then it would be complete, also damn impressive going from 30 to 10, but did you refer to the usbuhcil or the complete "set".
Could you perhaps release a beta version, just something a bit smaller than the current if possible ? doesnt matter if it's buggy.
Cheers

[Bret]

John:

I'm afraid that's not possible. I haven't actually been working on the UHCI host driver, but instead on the EHCI (USB 2) host driver. It's still got some big problems to troubleshoot, and way too buggy to even try to release. But it currently requires about 7.5 kB of conventional or upper memory and the rest goes into EMS or DPMS. I don't think the final version will be too much different than that. Once I get the ECHI working OK I will take what I've learned there and apply it to UHCI. The changes are substantial, so it will take quite a bit of time.

Depending on how many drivers you need (Host, Hub, Keyboard, Mouse, etc.) it won't be less than 10k total but will probably still be less than 25k total. Again, though, it's way too early to send you anything.

[Nisse]

oh ic so your onto the new one if I feel you right ? the uppgraded USB 2.0 you where talking about earlier ?

[Bret]

Yes, I'm concentrating on the newer (EHCI, USB 2) one right now, and periodically fiddling a little with the older (UHCI, USB 1) one. The new one has a completely different architecture internally which should make it much better overall, and I will be adding all that to the UHCI driver also. I'm also working on some of the specific device drivers, including at least one new one (for a USB Ethernet adapter). The changes I'm making in the specific device drivers are mostly related to reducing memory requirements, but of course there are some additional "features" being added to some of them as well. Reducing memory requirements is pretty important for USB in DOS, I think.

[Nisse]

Seems like your working your ass off
I totally agree with with you, the lesser memory it requires the better, and perhaps support for USB on a pci controller.
Would it also be possible to figure out what mouses work and dont work, so one can in advance know if the mouse from "ebay" is worth buying for the purpose.
It even seems like a newer mouse sometimes works better than an older one, my new roccat EMP works for instance which shocked me nothing to complain about there,
but then I tried with an older mouse Logitech G5 and it didnt work at all.

[Laaca]

The changed behaviour of the power button sounds like a some conflict between USB I/O ports and the ACPI I/O ports for power management.
Maybe the Bret't USB drivers assumess that certain ports belong to USB controler but they are occupied by ACPI system?
I could send you some short program which will try to switch the ACPI control off - maybe it could help.

[Bret]

An ACPI I/O port conflict is certainly possible. I know there can be several I/O ports related to power management (especially in laptops). The default I/O port range the USB drivers use is the one provided by the PCI controller itself. You can change it with a command-line option (which I doubt that anybody actually does), so if there is a conflict it is probably coming from the BIOS/UEFI configuration. If that is indeed the problem, changing the I/O port range of the UHCI controller with the command-line option may be a possible solution.

[Nisse]

Well I actually always have ACPI turned of in bios, it's strange tough beacuse it seems to happen more often when I use the DOS program MEM..
To me it also feels like some kind of conflict.. I have been searching the planet for updates to this Radisys Bios, but it seem near impossible to find (it's a 815 board with ISA and is very rare)
I would rather like to use my fujitsu 815 but it doesnt like power outlets that are ungrounded for some reason, but thats a different problem..

[Laaca]

And what happens if you set the ACPI on?

[Nisse]

Allready tried that Laaca, I think it may be conflict related tough.
It would be awesome if I could get a hold of a bios update, but that seems almost impossible..
The silly thing is that Radisys do have the bios but you must have a registered company with them as a partner or something to get updates
which is madness in my opinion due to fact that the board is like 20 years old.
So maybe like bret said I can perhaps try thoose adresses in the driver to see if that helps with the conflicts, but I am not really sure how to do it, but when he releases thoose new drivers things may change to the better =)

[Bret]

What you can do to try different I/O addresses is to simply use the /IOAddr:# option when installing USBUHCIL, something like like:

USBUHCIL /IOAddr:600h

You can see the current I/O address with USBHOSTS. The number after the colon can be any number between 100h and FFE0h that is divisible by 32 (20h). Usually higher numbers are better since they are less likely to cause conflicts, but any range not in use by something else is OK. The problem is, there is no easy way to tell what ports are in use by something else so you just need to experiment. I don't know if it will help or not, but it could.

A potential issue with this is that even if you tell USBUHCIL to assign an I/O address (which USBUHCIL in turns tells the PCI hardware to use), the PCI hardware may ignore it and use what it wants to anyway. That shouldn't happen, but I know on one of my computers the IRQ number stored in the PCI registers was a fake IRQ number and the real IRQ number was stored somewhere else. When I tried to change it, I was only changing the fake IRQ and not the real IRQ. I needed to keep experimenting until I found the real IRQ number. On that computer, the I/O address range in the PCI registers was OK though I suspect it may not have been real either (I never bothered testing further since things worked OK).

[Nisse]

Thanks mate, I will try that
Do you know of any program that can look for free I/O addresses in dos ?

[Bret]

Do you know of any program that can look for free I/O addresses in dos ?

No, I don't. And AFAIK there is no really good way to do it.

USBUHCI{L} has a way to do it if it needs to, but it is not 100% reliable. What it does is read a range of I/O addresses and see if they all come back with a value of -1 (FFh). If that's the case, it's probably an unused range. To verify, it then writes values to the same I/O range and see if the values are "remembered" by the hardware or not. If they are not, it assumes there is nothing at that I/O range.

Unfortunately, this is not a foolproof method. The biggest problem is that on some hardware reading an I/O port actually changes the configuration of the hardware. So, if you try to read from an I/O port where that is the case, you may have accidentally changed something that shouldn't have been changed. In regular memory (RAM), simply reading it never changes anything -- all you ever read is what was originally written to that memory address. Another problem is that some hardware requires specific I/O ports to be read/written as Words or DWords instead of a Bytes, so you may not be seeing the correct values coming from the hardware.

[Nisse]

I actually have a theory on these problems. I think they are perhaps related to the ISA bridge board that my two I815 use to enable ISA port, it seems to cause these conflicts..
It actually seems like when they made these 815 boards they where not made properly to handle the tasks they should in older software like dos and win 98, so for instance in win98 there is alot of "hidden" conflicts that I think most people miss if they dont dig deep.
Like bad implementation of IRQ sharing combined with these rare Bridge boards... Two of my 815 with ISA ports have these problems of locking in Dos with your drivers, happens all the time on the Radisys but not the Fujitsu one as often.
I would love to try it on a 845 or 865 chipset but one has to be almost rich to get a proper one of thoose, but I heard you are feeling generous and want to send me two
cheers